
What if anything have we learned from C++? [video] - rdudekul
https://www.youtube.com/watch?v=2egL4y_VpYg
======
yeureka
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.

~~~
blub
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.

~~~
pjc50
[https://xkcd.com/927/](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.

------
toolslive
"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](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".

~~~
acqq
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.

~~~
toolslive
figure 5 in the paper.

------
realharo
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).

~~~
bluecalm
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.

~~~
nly
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...](https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#The_Do.27s_and_Don.27ts)
[1]
[http://ispras.linuxbase.org/index.php/ABI_compliance_checker](http://ispras.linuxbase.org/index.php/ABI_compliance_checker)

~~~
datenwolf
> 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.

~~~
nly
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.

~~~
datenwolf
> 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.

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

~~~
blub
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.

~~~
xamuel
>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...)

~~~
restalis
"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.

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

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

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

~~~
72deluxe
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.

~~~
cm2187
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.

------
taeric
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.

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

------
louithethrid
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.

