What if anything have we learned from C++? [video] | Hacker News Reader

What if anything have we learned from C++? [video]

youtube.com

46 pointsrdudekul54 comments

I started programming in C++ in the late 90's and I used to be confused about what features to use and found it easy to make a mess.

But I am happy I stuck with it as it opened up opportunities to work in a lot of different and interesting domains like games, mobile apps, interactive art installations, trading systems and video and film processing apps. Also, most of my code is platform independent and very efficient.

There are a few interesting alternatives at the moment, namely Rust and Swift, but for now C++ does everything I want and since C++11 it really feels like a much more modern language.

This is also something that I like. In my opinion, the programming languages environment is ridiculously fragmented, and one has to learn new tools constantly in order to keep up, without gaining any real benefits.

I would prefer it if we had several strong, open langauges that are complements to eachother and which would own the market so developers could focus on solving problems, not learning syntaxes and APIs. Instead we have C# and Java, Python and Ruby, etc.

https://xkcd.com/927/

I'd rather see greater interoperability to enable parts of a project to be written in different languages. The C# ecosystem (F# etc) is closest to this, although see also Scala.

"most researchers prefer an inefficient language because it's easier to get a paper to improve an inefficient language... I've seen dozens of papers on getting lisp almost as fast as C++, on getting Java almost as fast as C++. You can't do that with C++".

A paper from the man himself on getting a type switch in C++ almost as fast as what you get in OCaml. http://www.stroustrup.com/OOPSLA-typeswitch-draft.pdf

Lot's of other places where he's omitting things because he wants to plug C++.

Also, he also seems to be confused between "an efficient language" and "a language that allows you to create something that runs efficiently".

It appears according to the abstract that it beats other languages while being implemented as "just a library":

"Our library-only implementation (...) For many uses, it equals or outperforms equivalent code in languages with built-in type-switching constructs, such as OCaml and Haskell"

In my opinion major weakness of C++ is just that the linker features more or less remained out of the language design. Turbo Pascal already shown eons ago the advantages of having modules instead of obj files. The slowness of compilation is still the major problem of C++ compared to the languages like Turbo Pascal and more recently Go.

figure 5 in the paper.

I really wish there was a "syntactic-sugar-on-top-of-C++" language that would compile down to C++ and have 100% compatibility with the existing C++ ecosystem (so that you can just directly use a class from any C++ library).

Something like TypeScript is to JavaScript, or like Kotlin is to Java. Would make the experience much nicer without having to wait on the slow C++ standardization process or deal with all the backwards compatibility baggage from the past (to a degree).

Nim targets compilation to C and (I presume C-flavored) C++: http://nim-lang.org/

In terms of playing nice Rust is doing great (no GC, and can create static libraries linkable by C/C++ compilers), but unfortunately requires going through plain C interface.

Compiling to C would be better. Using C++ libraries from anything outside C++ compiled by the same exact compiler and same exact version of it as the library was is a royal pain.

On the other hand using C libraries is super easy from any language and something compiled 10 years ago still works today.

We could call it cfront: https://en.wikipedia.org/wiki/Cfront

You only get ABIstab in C if you never change the size or layout of your structs, or completely hide everything behind pointers and allocate everything on the heap (maybe a little on the stack if your library is amenable to using callbacks - blargk!). The rules[0] for C++ aren't really any different, you just notice it more. When you start shooting for ABIstab, without putting in a lot of extra work, you start losing the nice semantics and APIs you're used to. In the C world, because of the limited capabilities of the language, library developers have never been able to do better, so application developers are used to suffering crappy APIs and working extra hard to get stuff done.

C++98 code out of GCC has been ABI stable for over 10 years now btw, and we also have some pretty great tools for detecting ABI breakage now, like abi-compliance-checker[1]

[0] https://techbase.kde.org/Policies/Binary_Compatibility_Issue... [1] http://ispras.linuxbase.org/index.php/ABI_compliance_checker

>>C++98 code out of GCC has also been ABI stable for over 10 years now btw

I was specifically picking on Visual Studio and vendors who decided to distribute C++ dlls. Sometimes they provide several versions depending on which Visual Studio version you have installed at the moment.

> You only get ABIstab in C if you never change the size or layout of your structs

Well, and you can append new elements to a struct and are guaranteed that the initial sequence of common elements is identical. This is not mentioned explicitly in the C language standard, but it follows as a corollary from point 6.5.2.2.5 of the language standard:

> One special guarantee is made in order to simplify the use of unions: if a union containsseveral structures that share a common initial sequence (see below), and if the unionobject currently contains one of these structures, it is permitted to inspect the commoninitial part of any of them anywhere that a declaration of the complete type of the union isvisible. Two structures share acommon initial sequenceif corresponding members havecompatible types (and, for bit-fields, the same widths) for a sequence of one or moreinitial members.

Consider

a.h

    struct a { char aye; short bee; int cee; long dee; };

a.c

    #include "a.h"
    int aye(struct a a) { return a.aye; }

b.h

    struct b { char aye; short bee; int cee; long dee; double eee; };

b.c

    #include "b.h"
    int bee(struct b b) { return b.bee; }

Now if we add c.h

    #include "a.h"
    #include "b.h"

    union ab {
        struct a a;
        struct b b;
    };

The language standard warrants, that the common initial sequence of both structures can be used interchangeably in that union. Since however compilation units a.c and b.c are processed individually without knowledge of union ab this enforces the compiler to use the same memory layout for an initial sequence of member elements for either struct. Hence it is legal to extend structs without out altering the memory layout of the previous elements.

You get the same guarantee in C++, as well as a language mechanism to exploit it (inheritance). You still can't pass structs by value across library boundaries in either language without fixing your ABI though. This isn't a language intrinsic problem: it boils down to the linker model, which only C and C++ share.

> This isn't a language intrinsic problem: it boils down to the linker model, which only C and C++ share

The linker coudln't care less about this part of the ABI (calling conventions). For example passing a function pointer to a different library (callback) the linker is completely oblivious to. Heck, the functions which pointers are being being passed around could have been compiled at runtime (JIT).

Calling convention ABIs are a compiler thing, as it's the compiler that emits the machine code that's responsible for setting up the frame in which a function executes. And calling conventions is, where C and C++ differ. On the language level there are not calling conventions (how could there be, as those strongly depend on the machine architecture). However for the various operating systems out there you can find detailed calling conventions for C, but seldomly for C++. And these platform specific C calling conventions usually tightly control both how function (stack) frames are created, which registers may be clobbered, but they also control the memory layout that a C compiler for that platform shall apply on structs. For example the SysV AMD64 ABI strictly nails down the specifics of aggregate type memory layout and function parameter passing. All compilers following that spec will produce code that's compatible with each other, even across library boundaries.

Have you tried Haxe?

http://haxe.org/

It's called "C++11."

After twenty years of using it? That I was wrong, that plain-old C really is better.

The C that you call "really is better" is not the C which existed before C++. It is "K&R C", which looked like this:

  foo (a, b, c)
  char *a;
  int b, c;
  {
     /* do something cool here */
  }

And there were no "function declarations" (who needs argument type and cardinality checking anyway), no "slash slash" single line comments, no need to declare a return type as int was implied, say goodbye to const and volatile qualifiers, any char array is mutable (including those defined in double quotes), plus be sure to use function pointers thusly:

  (*some_pointer) (insert, args, here);

Instead of:

  some_pointer (looks, like, a, function);

Oh yeah, and say adios to struct initialization using the C89 syntax. And it's a no-no to try and initialize a local array along the lines of:

  char *strings = {
    "this", "is", "convenient", "isn't", "it?"
    };

So if you wish to assert (pun intended) "that plain-old C really is better", then be sure to acknowledge where a non-trivial amount of what is known as "plain-old C" stems from.

by plain old, i think infradig was implying that C was plain and old compared to C++, and not about an older standard of C.

Yes, plain-old C like plain-old vanilla ice cream, as compared to C++ like swirly rainbow vanilla chocolate strawberry template macro class inherits from a waffle cone with generic unique pointer functor sprinkles ice cream.

I'm a C programmer, and I'm considering trying C++ in the future. Can you elaborate?

What I've learnt is that if you start writing C++ as a plan-old C, you quickly find yourself reaching for this and that feature from C++ that makes your job easier and your code more readable. Knowing where to stop is the tricky part.

I like to call that "C with std::vector"

Coding in plain C99 with some discipline can actually get you most of the benefits of C++, without any of its quirks.

The "object-orientedness" of C++ really boils down to implicitly passing the this pointer to member functions, inheritance + virtual functions, and namespaces. All of these can be emulated in what I would call "C with discipline". Just be consistent in your naming conventions, always use a common prefix for globally visible functions and types, and use structs of function pointers whenever you really need virtual functions.

What about templates? For some reason, C programmers only seem to comment about the OO parts of C++ and never talk about templates. When you bring variadic templates into the mix, it's just more awesomeness.

And, before you mention it, use clang to avoid getting the page long templates related errors.

I haven't seen much template wizardry in the C++ codebases I've worked on. It can generally be seen in the standard headers.

Type-generic data containers can still be implemented with void pointers and very little runtime overhead, for example: http://lxr.nginx.org/source/src/core/ngx_array.h

You cannot implement cache efficient data structures using void pointers.

C99 is nice, but C still lacks generic. I am not talking about C++ template nonsense, but not having to write max element search for every primitive type.

I am working in DSP project which was started with typical C++ OO BS, finally with ended up with C compiled as C++ + some simple templates for cases as above.

Using statement expressions and the typeof extension, you are able to write function-like, type-generic, scope-insensitive macros like this one:

    #define MAX(a,b) ({ \
        typeof (a) _a = (a); \
        typeof (b) _b = (b); \
        _a > _b ? _a : _b; \
    })

The inability to write template functions can be compensated by designing your function so that it takes a function pointer where the type-specific action occurs.

Typeof is not standard and many DSP compilers do not implement that. Secondly I meant max search in array, not between to scalar values which is trivial. I really don't want to have for(...) inlined everywhere.

Your MAX has no respect for namespaces or scopes. A real world macro is probably going to be called MYLIBRARY_MAX to avoid this. Secondly the C++ lambda solution is just easier to read.

    auto max = [](auto a, auto b) { 
        return (a > b) ? a : b;
    };

    max (3.1415, 42); // returns double
    max (42ul, 78u); // returns unsigned long
    max (17, 16); // returns int

I am not talking about C++ template nonsense, but not having to write max element search for every primitive type

How is it template 'nonsense', when those templates do exactly that?

Template metaprograming is nonsense, not simple type substitution. C++ templates are just too much, especially when mixed with substandard developers.

C has a generic: "void *". It just doesn't have any type safety.

It also has bad performance if you need to pass function pointers around.

Is this noticeably worse than calling through the vtable?

In C++ generics don't involve calling through a vtable.

C11 has type generic macros. You can build your own with the _Generic statement.

    int maxi(int, int);
    double: maxd(double, double);
    ...
    #define max(x) _Generic((x), int: maxi, double: maxd, ...default: maxi)

Yeah, but you still need to write those maxi, maxd :-(

I hold the exact opposite opinion, and would never want to work on a plain C project. It is so low level that one has to write a lot of plumbing code to take care of error handling and resource management. It's also missing pretty much all higher-level concepts that are fast and can make code easier to write, read and less error-prone. Overall, it's simply not fun to write C code, there's a lot of tedious manual work, and even if you do everything according to the book you might oversee something and have problems. Well-written C++ completely eliminates some classes of problems, just like Rust's type system can eliminate even more issues.

C is so tedious to write that even if I didn't have access to C++ I would try something else first when the need to write cross-platform/performant code would come.

The point is: it's not appropriate to evangelise C (or any other language) without pointing out some of its major disadvantages. This is simply spreading misinformation.

Stroustrup gave talks where he explained how to cherry pick c++ elements to decorate simple C code with just enough abstraction to get done safe and fast. I find it's an old timer skill to be able to use languages as suggestions rather than law and to strip it using only the bits that will really bring value to the project.

>plumbing code to take care of error handling

This becomes much simpler once you learn how to write your own variadic functions (it's not that hard, though I do admit it could be prettier). Then you just write one single logerrf function or whatever, which 9 times out of 10 you can carry with minor modifications to your next project. Java does try/catch better in the sense that with checked exceptions you can force library users to at least acknowledge exceptions. Without checked exceptions, try/catch just hides the extra int *err argument under the rug, actually increasing the risk of library users not acknowledging edge cases.

>and resource management

I don't like C++ malloc'ing things behind my back. I see it as trading maintainability for instant gratification. The problem is compounded by the way C++ doesn't play nice with gdb/valgrind. Memory leaks and other memory errors are much easier to fix in C than C++.

>C is so tedious

It really isn't, though, if you use it right. Whatever syntactic tedium it has is more than compensated for by the lightning-fast compile time and the infinitely simpler compiler errors (due to no overloading, no templates...)

"I don't like C++ malloc'ing things behind my back. I see it as trading maintainability for instant gratification."

I agree and I want to add that for a language "with a bias towards system programming" C++ makes strange assumptions about the memory. It assumes that there is only one kind of memory available for every operation (and it does its thing with that by default). Then it goes and further assumes that there is only one way (no finer further details whatsoever) of getting that one and only type memory. It's exactly the one boot fits all kind of thinking that Mr. Stroustrup suggests that C++ hasn't.

I've spent most of my career writing C++ in the "C with classes and containers" style. Apart from the compile times and library issues, this really is better than just standard C. You can automate much of the memory management.

Don't leave it forever to introduce a proper module system. Textual inclusion and manual header file maintenance is bronze-age programming.

Lua is my C++. If I need speed - I'll just write it in C and interface to the Lua environment.

That introducing kids to programming using C++ will ensure they never want to try again.

I was introduced to C and then C++ when I was 10 years old. I found the book on C by Arthur Chapman very confusing, particularly pointers. I then started reading a book on Pascal in the same series and that was confusing too.

But I stuck with it and have found that learning C++ has meant that I think in C++, and transfer this to other languages when I have to write them.

Additionally, the second thing I found was that all other languages I have come across (Obj-C, Java, Swift, JavaScript, PHP, C#) all have enough commonalities in syntax and thought processes that working in them is easy. In some cases, you get to consider them "dumbed-down" C++, and it makes working in them easier (and means approaches to things are different).

So it isn't a bad language after all. Particularly with the changes in C++11, it feels like an entirely new language.

I went the other way. I was introduced to programming at university, although not in a computer science degree. The professor believed in the hard way, so using some old Unix machines (it was in the 2000s), writing C++ in the equivalent of a notepad, and "debugging by printf".

Though I was keen on getting into coding, I was like many other students put off by this approach and only went back to programming many years later with visual basic.

I appreciate that one gets a better understanding of computer science by going really low level (assembler, etc) but I question whether this is the right approach if one wants coding to be more mainstream.

I think coding should be taught in high school like latin or physics, not because kids will all become programmers, or historians or scientists, but because having a basic understanding and culture will help in everyone's life and it gives kids a taste for what a career in that field may look like. And I don't think C++ is the right tool for that.

Languages I learned as an early teen, in the oder I learned them: Commodore BASIC 6502 Assembly Pascal C C++ etc...

I think you severely underestimate kids.

This video was more engaging than I was expecting. To the point that I am not sure what I was expecting.

There did seem to be too much apologizing for how other people messed up the original idea of C++. Same for patronizing much of the industry. I can't claim it was unwarranted, but a lot of patronizing.

I still hope someone will do transcript for it. Slides are missing some parts from talk.

No matter how elegant things are, the garbage collected, the pointers untoucheable, the libarys all optimized and readymade and the code jit-compiled to get near C - on the day your C ustomer demands that one feature too much - you want to have C ontroll.

Reply on news.ycombinator.com