Interviews: Ask Bjarne Stroustrup About Programming and C++

In addition to being the creator of C++, Bjarne Stroustrup is a Managing Director in the technology division of Morgan Stanley, a Visiting Professor in Computer Science at Columbia University, and a Distinguished Research Professor in Computer Science at Texas A&M University. Bjarne has written a number of books and was elected a member of the National Academy of Engineering. He will be doing a live Google + Q & A within the C++ community on August 20th, 2014 at 12:30pm EST, but has agreed to answer your questions first. As usual, ask as many as you'd like, but please, one per post.

Comments

Just Wanted To Say One Thing

[Anonymous Coward]

Even though I'm an unemployed programmer since the banking crash, I still believe in C++. I can't fathom programming in any of those interpreted languages.

Re:Just Wanted To Say One Thing

[Anonymous Coward]

Really? You feel good now there behind your keyboard writing such a mean and stupid thing? Must be great to be you.

Re:Just Wanted To Say One Thing

[Anonymous Coward]

Oblivious troll is oblivious

Re:Just Wanted To Say One Thing

[Anonymous Coward]

...I'm an unemployed programmer.

I can't fathom programming in... interpreted languages.

Do you feel that it is your inability to recognize evident causal relationships or your unwillingness to learn new skills which holds you back?

Re:Just Wanted To Say One Thing

[Anonymous Coward]

Hello! Unemployed python programmer who dropped out of university here. I would only program in C++ if there was a good cross-platform interpreter for it. The way it is, it's just not safe enough.

Re:Just Wanted To Say One Thing

[kwbauer]

Like Anonymous Coward is a better name!

USP

[Anonymous Coward]

Your language has become one of the most popular in history. If you were launching it today, how would you "market" it? What do you think is the unique selling point?

Ideal team size and composition

[Anonymous Coward]

If you had to create a new language and compiler from scratch, what would be the ideal size and composition of the team? From what fields would you try to recruit people?

Do you think the H1B system is a joke?

[Joe_Dragon]

Do you think the H1B system is a joke? and they are useing it to get cheap work out people chained to the job?

Re:Do you think the H1B system is a joke?

[Richard Dick Head]

This question is a little US-centric. Let me try to iteravely improve on this...

From your perspective, how is the globalization of commerce and specifically programming affecting you and those you know? Are the new high level scripting tools available to programmers since C++ became popular pushing the profession towards a more "commoditized" state, where people are easily replaceable and where the related skills and specialization eventually offer no better benefits and compensation than other less skilled professions?

Re:Do you think the H1B system is a joke?

[Anonymous Coward]

Why ask this of Bjarne Strousup? Is he an H1B immigrant? Is he chained to his job, or do you expect his work to be rather cheap?

Re:Do you think the H1B system is a joke?

[Orestesx]

It's a fair question, he lives and works in the United States at an international that no doubt employs many H1B's.

Re:Do you think the H1B system is a joke?

[Anonymous Coward]

He's an prof nowadays, the academic word has different visa's (L1, not H1 IIRC). Much less controversial since /everyone/ is underpaid in academia.

Cutting features and old syntax?

[Katatsumuri]

Sometimes well-established languages keep adding new features and syntactic constructs until most developers are not even aware of all the possibilities, and use maybe 20% in their usual daily work. The old features and syntax are kept around for compatibility and to keep the old guard content, even if cutting them would lead to faster compilation, more elegant language and less confusion.

This may be part of the reason for the constant introduction of new trendy languages with radically simplified syntax and libraries... Which then follow the same pattern. Few languages are introducing new paradigms, many are trying to be a "better" C++, Java, LISP, JavaScript or Perl.

Do you think this cycle is inevitable, or could it be a good idea to sometimes clean up the syntax and the obscure features in new specification versions, to keep the established languages more competitive?

Re:Cutting features and old syntax?

[Anonymous Coward]

Are you asking in a roundabout way if inheritance and overloading should be deprecated in favor of templates and lambdas? Because that's nasty

Re:Cutting features and old syntax?

[Immerman]

Why would you assume such a thing? C++ is rife with old, rarely-used "cruft". Meanwhile templates and lambdas are great, but they provide advantages largely orthogonal to inheritance. I'll grant you that purely on merit overloading is potentially a legitimate "cruft"candidate as it adds essentially no functionality while potentially increasing confusion, especially operator overloading, but it's so pervasive within the standard libraries that extracting it would likely drive away most of the developer base.

Re:Cutting features and old syntax?

[Wootery]

Reminds me of of a blog-post I stumbled across a while ago: Heat Death Of Programming Languages

Other than a select few (C and Scheme spring to mind), programming languages get more and more bloated and incoherent over time. We certainly see this in C++, which is probably the 'best' example of the ugliness that arises through backward-compatibility. There are 4 different languages in C++ now: C++ proper, the preprocessor, the template system, and the compile-time-friendly subset.

I suspect the D language may be growing too big for its own good. They're much less concerned with backward-compatibility, which I suspect helps with the ugliness problem, but doesn't help with, say, high-barrier-of-entry-to-reimplement, or high barrier until you're able to read real-world D code.

Re:Cutting features and old syntax?

[Megane]

I'll grant you that purely on merit overloading is potentially a legitimate "cruft"candidate as it adds essentially no functionality while potentially increasing confusion, especially operator overloading

But it does add functionality! It lets people show off by creating stunt code like iostreams, where the bit-shift operators can be abused for I/O functions!

Re:Cutting features and old syntax?

[angel'o'sphere]

You don't sound as if you know what orthogonal means ...
How can a lambda that is orthogonal to inheritance be s bad thing?

Re:Cutting features and old syntax?

[david_thornley]

Overloading is useful in general, and very useful when combined with templates. Templates produce code that is identical but varies in data types. Without operator overloading, it's awkward to use complex numbers, and really awkward to use them with a template that should work on numerical data types.

The confusion I've seen with them is in code that nobody in my shop would approve in a code review. Stroustrup historically hasn't been averse to language features that are useful when used properly and confusing when used badly.

My top-of-the-head cruft nomination is C-style casts. Too easy to slip in, and too hard to pick up with grep.

Re:Cutting features and old syntax?

[david_thornley]

What is the compile-time-friendly subset?

The preprocessor should not be used for things that affect code, like constants or function-like macros. Those should be const declarations and templates, respectively. Its primary remaining use is conditional compilation. That hardly counts as a language.

It's unfortunate that the template system isn't closer to normal C++ (in Common Lisp, the macro, which does more or less what templates do, is written using normal Common Lisp), but it's not that bad.

Re:Cutting features and old syntax?

[Anonymous Coward]

No thanks, keep all of the syntax, please. Not because all of it is great, but because it is used in a hell of a lot of existing code that nobody wants to rewrite. When C++ 98 was under standardisation, the mantra was that "most of the C++ code is yet to be written". That isn't the mantra anymore. There exists several metric shitloads of C++ all over the place. Removing features would grind the development of this all to a halt. It would almost halt the entire tech world while everyone spends time rewriting code that already exists.

There already exists several solutions for you. Just use another language. Or create your own and call it C+++ or whatever you like. Because what you suggest would be the same as creating a new language. In that case, why insist on even calling it C++ ?

Re:Cutting features and old syntax?

[Immerman]

They're absolutely not. Perhaps I could have phrased that more clearly: Orthogonal functionality is the best kind of functionality, maximum flexibility and with minimum learning curve. Why would you want to deprecate inheritance in favor of something else rather than letting them amplify each other?

Re:Cutting features and old syntax?

[Immerman]

Ooh, casts, good one.

And an excellent point with templates and overloading.

As for operator overloading - I partially agree. Vector and matrix math likewise become far less awkward thanks to operator overloading, I really miss it when working in languages without it. But the functionality is unchanged, I just need to type more without it. And I have noticed that as the number of overloaded complex numerical types increases the odds of an unexpected interaction arising increases rapidly, especially thanks to implicit casts being invoked. You're just asking for trouble when "a=b+c" can invoke an implicit chain of a half-dozen functions to become a syntactically valid statement.

Re:Cutting features and old syntax?

[serviscope_minor]

That's an interesting take on things.

The C standards people have resisted adding much to the language. This is good, but it's been a long time since I've reached for C for a new project. The main reason is that that the language is quite primitive and does very little automatically. For those reasons it won't go, but there's little reason to use it in new projects.

And LISP always did everything anyway but personally I like the last 60 years of parsing theory and find it much easier for the compiler to parse things for me rather than me having to write out an AST by hand. I think many people agree. I love the idea of a programmable compiler, ESPECIALLY when you can program it in the same language you write in (looking at *YOU*, C++), but it's still LISP.

The thing is it's only worth giving up the nice things for the bad syntax when there's a compelling advantage in new features. Other languages must either bolt these features on (e.g. C++ from C), or new languages replace old ones.

LISP being the eternal thing it is never needs replacing, but it's never quite as easy to do the latest thing as the latest purpose designed languages.

Re:Cutting features and old syntax?

[Wootery]

What about Clojure?

Also, I'm not sure it's true that there are no good reasons to start a new project in C. If Linus started the kernel today, I'm sure he'd still go with C. I'm sure there are plenty of embedded programmers who think the same way. C compilers are almost guaranteed to exist for whatever your target platform may be, and there's no shortage of C programmers.

C is much simpler than C++, and that will always be an advantage to C. Static-analysis, or writing your own compiler, are much simpler with C than C++. (OpenCL uses C rather than C++, for example.)

Re:Cutting features and old syntax?

[Wootery]

What is the compile-time-friendly subset?

constexpr. The subset was grown considerably in C++14.

Its primary remaining use is conditional compilation. That hardly counts as a language.

Well, no, it does count as its own language, because... it is. If you grant that the preprocessor is, at least. It's clearly separated from the C++ 'core' language, and it's something non-trivial that a C++ programmer needs to know about. Much like the preprocessor.

There are plenty of neat tricks to be had with the template system that aren't really just conditional compilation. Type traits, static-asserts, Boost.Function and Boost.Bind spring to mind.

Re:Cutting features and old syntax?

[serviscope_minor]

OK, I admis my view was a bit extreme. There are few good reasons for starting a new project in C rather than C++.

What about Clojure?

Good point.

Also, I'm not sure it's true that there are no good reasons to start a new project in C. If Linus started the kernel today, I'm sure he'd still go with C.

Almost certainly, though he clearly doesn't understand C++ and has some very odd ideas about it. I don't see how having constructors instead of manually calling macros and virtual functions built into the language (much better dcache performance than the C version) would do anything but be an improvement.

I'm sure there are plenty of embedded programmers who think the same way. C compilers are almost guaranteed to exist for whatever your target platform may be, and there's no shortage of C programmers.

To an extent, though C++ is in a lot of places now. Even little 8 bitters like the arduino run C++ happily. There are still some ones out there with C only support.

The thing is though the ones with C++ support often use GCC and the ones that don't use GCC have those dreadful proprietary venduh compiles that segfault if you look at them wrong and only ocasionally produce flat-out incorrect code.

C is much simpler than C++, and that will always be an advantage to C. Static-analysis, or writing your own compiler, are much simpler with C than C++. (OpenCL uses C rather than C++, for example.)

True that writing a compiler parser is much easier for C than C++. However even given C++ that's probably the easy bit these days. Any compiler worth a damn has to have a decent optimizer and those are phenomenally hard to write a good one even compared to a C++ front end.

Though these days, to write a static analysis tool, one would reach for LLVM, I expect, or a GCC plugin. Even writing a proper ANSI C11 front end is a pain in the ass.

Re:Cutting features and old syntax?

[Wootery]

he clearly doesn't understand C++ and has some very odd ideas about it

Maybe, yes. (I'm quite pro-C++ myself, at least compared to C; I clearly think nothing like Torvalds.)

I don't see how having constructors instead of manually calling macros and virtual functions built into the language (much better dcache performance than the C version) would do anything but be an improvement.

How would the cache performance be different? Also, there are things not to like about C++ constructors, error-handling being one of them.

Agree that any sane developer wanting to write a new C++ compiler (backend) or static-analysis tool would almost certainly be unwise to do anything but use an existing frontend (Clang, EDG... g++ maybe, I guess).

Re:Cutting features and old syntax?

[serviscope_minor]

How would the cache performance be different?

The idiomatic C technique is to have one function pointer per virtual function in the class as a member. The C++ version has a single pointer to a global VTable. The result is that for any class with more than 1 virtual function, the C++ version is smaller than the idiomatic C version.

As for handling errors in construction, RAII I happen to like. You get the condition that all code you look at can assume the class is in a vaild state. It makes code much simpler to read and write. I'm not sure that exceptions in kernel code are a terrible idea. People have implemented it and I've yet to see a convincing argument against them.

Even without that in C, you have to remember to call that macro to initialise things every time. Each time is an opportunity to forget and there's another bug.
As for the yosefk FQA, it's mostly FUD and misinformation. If you want to not use exceptions, you can add a validity flag to the struct which you have to test and/or add a .init() method which runs any code that might fail on construction. It's more verbose and possibly slower than using C++ properly.

Re:Cutting features and old syntax?

[Wootery]

The idiomatic C technique is to have one function pointer per virtual function in the class as a member.

Is that how GObject works?

I admit I never really 'got' vtables. How they handle multiple inheritance still doesn't make sense in my head.

You get the condition that all code you look at can assume the class is in a vaild state. It makes code much simpler to read and write.

I'm a fan of that. I'm not a huge fan of being forced to use exceptions, though. The fact that the LLVM coding standards forbid them on performance grounds has to count for something.

Even without that in C, you have to remember to call that macro to initialise things every time. Each time is an opportunity to forget and there's another bug.

Indeed, unless you macro-horror your way out of the chance to forget.

If you want to not use exceptions, you can add a validity flag to the struct which you have to test and/or add a .init() method which runs any code that might fail on construction. It's more verbose and possibly slower than using C++ properly.

Vaguely related: the rather neat Boost.Optional library. There's no way to make it 'safe' and implicitly check against use of uninitialised objects, annoyingly (though you can query it manually), but the machinery seems to be there.

Re:Cutting features and old syntax?

[serviscope_minor]

Is that how GObject works?

I'm not 100% sure. GObject is so large and complex it's more of its own language built in C than idiomatic C. I was more thinking of the VFS in the kernel.

I admit I never really 'got' vtables. How they handle multiple inheritance still doesn't make sense in my head.

Well for single inheritance, a VTable is essentially a struct of only function pointers. In C, you'd have the function pointers in the main struct. In C++, you have the function pointers in their own struct and a single pointer to that. So, you need a double indirection to call a function. That also used to be a performance penalty in C++, but on moder CPUs it isn't.

So in C, you'd have
struct a_class{
    void (*foo)();
    void (*bar)();
    int data;
};

In C-like-C++, you'd have:

struct a_class_vtable_ {
    void (*foo)();
    void (*bar)();
} a_class_vtable = { func1, func2);

struct a_class{
    a_class_vtable_* vtable;
    int data;
}; //with minor abuse of C

To call, you do in the first case:

a_class_instance.foo();

in the second case, you do:

a_class_instance.vtable->foo();

For multiple inheritance, my understanding is that you just concatenate the two structs, so you have:

struct MultipleInheratance{
      struct a_class first;
      struct b_class second;
};

Now, if you want to pass a pointer to MultupleInheritance to a function expecting a b_class, you have to add on sizeof(a_class) bytewise to the pointer.

The fact that the LLVM coding standards forbid them on performance grounds has to count for something.

I'm not sure why they do this. Exceptions are free unless they're called, so you should only use them for rare events. Nonethelss a standard which restricts a major language feature due to "performance" IMO falls very badly foul of "premature optimization is the root of all evil".

It's much better to write correct code first as quickly as possible then go back and optimize any hot paths.

Indeed, unless you macro-horror your way out of the chance to forget. :o

Vaguely related: the rather neat Boost.Optional library. There's no way to make it 'safe' and implicitly check against use of uninitialised objects, annoyingly (though you can query it manually), but the machinery seems to be there.

I've never delved into Boost.Optional. I'll have to check it out.

Re:Cutting features and old syntax?

[jbcksfrt]

... increasing confusion, especially operator overloading, but it's so pervasive within the standard libraries that extracting it would likely drive away most of the developer base.

I used to think operator overloading was unimportant, but I recently have been working with a C++ geometry library (CGAL). Having asterisk mean scalar product, plus mean vector addition (depending on arguments, etc)., as is customary in the field, has been surprisingly helpful and made the code much more readable and writable in my opinion.

Re:Cutting features and old syntax?

[Wootery]

What I don't get is this: suppose Dog inherits from Eater and Walker. If I have a vector of pointers to Eater objects, and I add a pointer to a Dog instance to that vector, and I call eat(dogFood) via that pointer, how can the vtable handle both the Eater and Walker member-functions? Surely they each have an idea of which member-function pointer belongs in which index of the vtable. If we have two vtables, surely we mess up the offsets for one of them. Or do we just bounce all the calls for Eater through a trampoline to handle the offsets?

Looking at Boost.Optional...

Boost.Optional's is_initialized() is now deprecated, presumably you're meant to just implicitly cast to bool now.

Apparently there are some pretty major compiler-compatibility issues with Boost.Optional, including the latest Visual Studio compiler, and GCC 4.5 (but not newer GCCs, happily).

Some StackOverflow discussion and toy examples.

Re:Cutting features and old syntax?

[Wootery]

( Just realised the irony in What I don't get is this :P )

Re:Cutting features and old syntax?

[Wootery]

Something I got wrong: looks like the replacement for is_initialized() is to explicitly cast to bool, using static_cast.

Re:Cutting features and old syntax?

[angel'o'sphere]

Good, then I misunderstood you :)

Re:Cutting features and old syntax?

[david_thornley]

I don't count constexpr as a language of its own, and the preprocessor can be largely disregarded.

The fact that the template system is Turing complete in a really weird way, and is programmed almost nothing like C++, is a real problem. One of the fascinating things about C++ is how much people kept figuring out about the language after the Standard was finalized. From a mathematical point of view, it's good, because of all the stuff you can derive from relatively simple rules. From a developer point of view, it's different.

Re:Cutting features and old syntax?

[david_thornley]

As far as the implicit casts are involved, "explicit" is your friend. Do a lot with your friend here. I know it would be too big of a breaking change, but if I could magically change it without hurting anything I'd have "implicit" as a keyword, making constructors explicit by default.

Re:Cutting features and old syntax?

[M2tM]

Python 3 was an attempt to do precisely this. 5 years later, they have a 2.5%-3.5% adoption rate.
http://blog.startifact.com/pos...

You cannot deprecate old language features without risking lock-in on older versions and lack of adoption.

The reason C++11 and C++14 has been a successful movement so far is precisely the ability for old code to continue running on new compilers!

Re:Cutting features and old syntax?

[serviscope_minor]

What I don't get is this: suppose Dog inherits from Eater and Walker. If I have a vector of pointers to Eater objects, and I add a pointer to a Dog instance to that vector, and I call eat(dogFood) via that pointer, how can the vtable handle both the Eater and Walker member-functions?

It effectively has two vtables. One for the Eater part and one for the Walker part. A multiply inherited class is (to my understanding) literally the concatenation of the two base classes, including the vtable pointer.

Surely they each have an idea of which member-function pointer belongs in which index of the vtable. If we have two vtables, surely we mess up the offsets for one of them. Or do we just bounce all the calls for Eater through a trampoline to handle the offsets?

I don't think there's a trampoline.

Let's say you have (C style)

class A_vtable{
        void (foo*)(); //A function pointer. We only have function poionters here.
};

class A{
        A_vtable* vtable; //A trivial class with one virtual function and nothing else
};

class B_vtable{
        void (bar*)(); //See comment for A_vtable;
};

class B{
        A_vtable* vtable;
}; //Some double inheritance:

class C{
        class A parent1;
        class B parent2;
};

The compiler knows which base class each function belongs to because of static typing, so it knows whether to use parent1.vtable or parent2.vtable. So that's OK.

Casting from C to A is trivial, since a pointer to the first element is equivalent to a pointer to the struct. Casting from C to B is simplytaking &c_instance.parent2.

I think it's simpler if you think in terms of cross compiling to C rather that straight in terms of offsets etc, because I think the mapping from C++ to C is more obvious.

In practice, of course the VTables will just be untyped arrays, and the VTable for C will be one long enough to hold both sets of pointers. It's possible to translate directly between that and the c style representation provided that one controls where the allocated structs go in memory. Also the compiler knows this and knows that the sizes are fixed and knows that therefore the two vtable pointers point to a fixed offset relative to each other so it can just tweak the offsets.

However, it doesn't have to be like that. Also the second pointer has to exist otherwise it would be impossible to cast down to a pointer to B.

Re:Cutting features and old syntax?

[Wootery]

class C{ class A parent1; class B parent2; };

The compiler knows which base class each function belongs to because of static typing, so it knows whether to use parent1.vtable or parent2.vtable. So that's OK.

I don't see how static typing solves things. If we had a vector of pointers to B objects, and we added a pointer to a C instance (C being a subclass of B), how would the compiler know to offset for the 'parent1' member when it comes to finding the vtable (in the parent2 member) for that instance?

Re:Cutting features and old syntax?

[serviscope_minor]

I don't see how static typing solves things. If we had a vector of pointers to B objects, and we added a pointer to a C instance (C being a subclass of B), how would the compiler know to offset for the 'parent1' member when it comes to finding the vtable (in the parent2 member) for that instance?

Well the memory layout of C is the concatenation of the layouts of A and B in sequence, so C has 2 vtable pointers, one for A and one for B. You convert a C* to a B* by finding the pointer that points ot the chunk of B within C. So the VTable pointer is already just sitting there.

When you have a vector of B*, the compiler must first cast the C* to the B* before inserting it, and it does this by offsetting the pointer.

Once you have a B* pointer to a C*, you cannot access the A members of the C* without doing some additional explicit casts. So, you can never access a parent1 member of a C* when you only have a B* pointing to it unless you cast. When you do the cast the compiler gets to do the offsetting.

Re:Cutting features and old syntax?

[Wootery]

When you have a vector of B*, the compiler must first cast the C* to the B* before inserting it, and it does this by offsetting the pointer.

But how? The vector is full of pointers. You have no way of knowing whether the pointed-to object is a B instance or a C instance.

Re:Cutting features and old syntax?

[serviscope_minor]

As far as the compiler is concerned, you only have a:

std::vector v;

If you do v.push_back(some_C_pointer), it knows it has to cast down because the pointers are of a different type, one beig a C*, the vector containing B*. The pointers in v only every point to things which are a B.

Remember: multiple inheritance is the aggregation of the two parent classes. So a C contains both an A and a B. The pointers in v only point to the small chunk of the C class which is a B. That's why the compiler has to adjust the pointer so it points to the B bit.

so going back to struct C which has parent 1 and parent2:

vector vec;

struct B some_B;
struct C some_C;

vec.push_back(&B); //this works trivially.
vec.push_back(&C); //compile error! //However, this does work:
vec.push_back(&C.parent2);

The thing is in C++, if the classes are different, the compiler can check the parent classes and all their parents until it finds a type that matches. It then knows the source and destination type and can do the adjustment.

Re:Cutting features and old syntax?

[Ateocinico]

In physics simulations, cad, rendering, etc, C is too low level and lua is too slow. High complexity is inherent to those fields and you can not foretell what abstractions you need in your language. That is the reason for classes and templates. Complex numbers and arrays are simple to implement as native types, they have been native to fortran for decades. Also writing fast and parallelizable number crunching applications that work over complex and dynamic data is one of the reasons for languages like C++. The sole comparison of gnu numeric library to eigen or armadillo is enough evidence.

Re:Cutting features and old syntax?

[Wootery]

That makes sense. So we essentially have several different 'this' addresses depending on how we're treating our instance. Crazy.

Does that mean a pointer equality comparison might behave unexpectedly, if the two pointers are of different types but refer to the same object?

Morgan Stanley

[Anonymous Coward]

Why work for the vampire squid?

Is the complexity of C++ a practical joke?

[Anonymous Coward]

C++ is one of the most complex, inscrutable computer languages ever created. When I read about C++11, I was surprised that it layered more complexity and inscrutability on top of what was already there (like the weird lambda syntax). I wonder if C++ has become an over-the-top example of how not to do a programming language. Is that by intent, or did it just happen? In future versions of the language, will any cosmetic changes be made to create a more understandable language that doesn't overload a small set of symbols and keywords, so that normal programmers have a chance to figure out the language? The language seems to have reached the point that C++ gurus design it for other C++ gurus, and everyone else ignores it. C++ was once the up and coming language of choice, but it has become so difficult that programmers have considered it damage and routed around it. Are you comfortable with this fate for C++, as a niche language for insiders, or do you want to use your influence to rehabilitate the language so that more programmers will use it?

Re:Is the complexity of C++ a practical joke?

[UnknownSoldier]

This needs to be modded +10.

C++ has become a clusterfuck of engineering.

Some of the most painful moments of my life were working on a professional C++ compiler. Almost everyone uses the EDG front end to minimize the pain of parsing C++ into an AST.

Re:Is the complexity of C++ a practical joke?

[narcc]

C++: Is It Really a Cruel Joke?

Re:Is the complexity of C++ a practical joke?

[just_another_sean]

A practical joke? Are you joking? C++ is not designed so that every feature must be learned and used. It's complexity derives from the fact that it supports OOP, functional programming, generic programming and I'm sure others that Bjarne would happily describe to you and the reasoning behind supporting features being included in the language. Those that are confused by C++'s complexity are doing it wrong. As with Perl it's OK to use only what you're comfortable with, no one is going to make fun of you for not using advanced features and if you like you can keep a C++ program pretty basic.

But it supports all these features to give people what they need to get their jobs done. Lambdas looked a little strange to me at first too but as I studied the examples in Bjarne's book they became clear and I think they are quite expressive, easy to use and worth looking into, especially when you combine them with the types and algorithms in the STL.

Look, I'm a Bjarne fanboy, have been since I started programming in the 90's so maybe my bias is showing through but I never thought I'd come to an article about C++ on /. and find the only comments above a 3 were people whining about how complex a programming language is. Programming is complex, system's programming doubly so and C++ is designed to help reduce that complexity, while at the same time remaining resource efficient, when it's used correctly. If it's too hot to handle for you there is always Visual Basic.

Re:Is the complexity of C++ a practical joke?

[gbjbaanb]

actually, I agree with this too - some of the stuff added to C++ is just not pleasant. Its like someone wanted a relatively specialised addition, got it in the standard, and there it is - for all to see and think "did we really need this?!".

I'd like to think the language should be 2-tiers, the easy stuff and the "advanced, specialised" stuff, but maybe that's just promoting the C++ style of "C with classes" that some people code. (not that its necessarily that bad a thing, C is good, RAII is good, together with some pre-rolled STL bits they're great).

Maybe a better question is to ask how much of the C++11 features he expects will actually be used by the majority of C++ developers. I can see for ranges being used a *lot*, but delete functions (ie you put =delete after a declaration to stop it being accessed, like you do with pure virtual functions set to =0), ro some of the other things. What about move operators - good idea, but it'd going to take a long time to get all the documents about C++ updated to include the 4 default constructors for example (ie ctor, dtor, copy ctor, move ctor), not to mention the nasty syntax for using them.

Re:Is the complexity of C++ a practical joke?

[Katatsumuri]

it's OK to use only what you're comfortable with

...until you have to read, debug, maintain and extend someone else's code.

Re:Is the complexity of C++ a practical joke?

[micahraleigh]

Java added lambda's.

C# pioneered lambda's.

Java and C# have individually higher adoption than C++:

https://sites.google.com/site/...

Seems like lambda's are an ascending trend.

On the other hand ... so are murders in Chicago.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

This needs to be modded +10.

C++ has become a clusterfuck of engineering.

Some of the most painful moments of my life were working on a professional C++ compiler. Almost everyone uses the EDG front end to minimize the pain of parsing C++ into an AST.

What's happened to C++ is the antithesis of engineering. Engineering involves planning and design.

It's more like building an upside-down doghouse in your attic, then forcing beavers to build a damn inside it.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

This is a well-thought out post, but it could be *really* good if it didn't attack the author's motives by implying that they intentionally made their work bad. That is just a form of ad-hominem attack. Paraphrasing here:

Don't start with:
Did you intentionally create the biggest piece of garbage possible, or did it happen by accident? I was surprised that it layered more complexity and inscrutability...

Instead, start with:
C++ started as a simple set of extensions onto C, but today I was surprised that it layered more complexity and inscrutability...

Re:Is the complexity of C++ a practical joke?

[Immerman]

And? Life is a learning experience, so break out the reference manuals and learn something new. Unless you've been thrown in way over your head it's unlikely you'll encounter more than one or two new methodologies in any given codebase, and it'll probably be pretty glaringly obvious when you run into a language feature you don't understand.

Re:Is the complexity of C++ a practical joke?

[smaddox]

C# pioneered lambda's.

Whaaaaaat? C# was created in 1999/2000. Lisp, which was based on lambda calculus, was first specified in 1958.

Re:Is the complexity of C++ a practical joke?

[jopsen]

A practical joke? Are you joking? C++ is not designed so that every feature must be learned and used.

Agree... if someone wants to use STL to create a DSL, I say we let them shoot their own foot :)

Re:Is the complexity of C++ a practical joke?

[kthreadd]

C# pioneered lambda's.

(get (off) (my lawn))

Re:Is the complexity of C++ a practical joke?

[mark-t]

In my experience, most corporations where extending or maintaining code that another person has written, coding styles are generally adopted so that the code is uniform. Adoption of such styles does not, in general, limit the expressive capability of the language, it just means that when you write code, you will be writing it in a way that other people will be able to read and maintain. Of course, this is not a specific issue for C++... it is equally applicable to all programming languages, and the real-world problems which arise in this regard are generally reflective of poor programming skill, not a poorly designed programming language.

Re:Is the complexity of C++ a practical joke?

[mark-t]

C# pioneered lambda's.

Uh...no

Re:Is the complexity of C++ a practical joke?

[Katatsumuri]

Just to make it clear, I was not judging the design of C++. I only made a counter-point to the "use your own subset" argument. I agree that coding standards reduce this problem, but they also cannot solve it completely.

Re:Is the complexity of C++ a practical joke?

[Katatsumuri]

I agree, there's always new things to learn; in some languages more than in others. Some people find it exciting, others find it annoying. I currently don't use C++ daily, so I am not frustrated with it. In fact, I like many of the new features. But I can understand why some people complain.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

Posting as AC because of moderation.

To add to this, it's also useful to have a copy of the standard (a PDF can be picked up from ANSI for around $40), and become familiar with it's layout. You don't need to read it cover to cover, but be comfortable enough to locate relevant sections when necessary.

Re:Is the complexity of C++ a practical joke?

[dentin]

This is a very good set of observations, and I also feel that C++ has become a 'niche language for insiders'. The syntax is difficult; it's remarkably easy to shoot yourself in the foot in unobvious ways; and porting can be problematic, as no two compilers compile the same code the same way. Trivial mistakes such as pointer aliasing are often compiled -silently and without error-, producing different results at different optimization levels, and -this is considered normal-. Over the years, you learn these things and you figure out which things to avoid, but for new people coming into the language, it's a huge barrier to entry.

If the goal is to really get a lot more programmers to use it, the base syntax almost certainly needs to be improved. Rather than providing some obscure syntax to do some obscure library feature, make it easy to do simple things and make the language as idiotproof as possible. Make compilers either strictly produce well defined output as per the spec, or throw an error. Do -something- to improve template syntax.

Pretty much all of the new features I've seen in the C++11 spec are niche features, things used by high-end library writers with 20 years of experience to do complicated library things. That's good, libraries are important. But libraries will not translate into users if normal users cannot use them, and libraries will not translate into users if the language itself is the bulk of the learning curve.

Re:Is the complexity of C++ a practical joke?

[UnknownSoldier]

You're right!

I should of said: over-engineering.

Re:Is the complexity of C++ a practical joke?

[Kjella]

C++ is one of the most complex, inscrutable computer languages ever created. (...) Is that by intent, or did it just happen?

Yes and no, depending on how you look at it. Once upon a time like 40+ years ago there was C. While there was others, C was massively successful in the 1970s because it was a very good but really thin abstraction layer over assembler, which was very common at the time. That means you could write C and it'd run on many different kinds of machines, conversely if your platform wanted to go anywhere it had to have a C compiler. It was imperative and procedural, which was fine but computer scientists also wanted an object oriented language. How do you do that when you don't have a massive staff and budget? You extend C. Early C++ compiled down to C which then compiled on every platform with a C compiler. All the other very low level C-isms just came along for the ride. And any behavior that wasn't defined in C, well it couldn't be defined in C++.

A lot of it is simply the result of C++ paving the way, it was often the first C-derived language to do it and a lot of it turned into ungodly kludges, but you were pretty much committed to keeping that syntax working. So you keep adding and adding but never subtracting, never cleaning up. It's easy to say "lets start over and do a clean rewrite" but hard to achieve the necessary momentum, many have tried and failed. And with locked down devices it's now the device manufacturers that control if a given language will be available, you can make UltraC but if you can't make an iOS app in UltraC then the value is more limited. Outside Apple, Google and Microsoft I don't see who can pull it off, Sun could once but Oracle could never make a new language. Not counting web server languages like Perl/PHP/RoR, but local end user software.

Re:Is the complexity of C++ a practical joke?

[dentin]

Further, in my opinion, we should look at the most common coding conventions and consider adding pieces of them to the compiler and language specification if it makes sense to do so. Naming of functions almost certainly doesn't make sense; but requiring braces after all conditionals very well might (and may make compiler parsing of other constructs easier to handle.)

The most common coding styles almost always touch on what would be 'best practices' in the field. Adding those 'best practices' to the core language specification seems like something that should at least be considered.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

I don't have time to break out reference manuals and learn new shit, I have a job to do.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

You're right!
I should of said: over-engineering.

You should of said: I should have said.

Re:Is the complexity of C++ a practical joke?

[Megane]

I suggest you read D&E to understand how various parts of the language came to be. Then read Google's C++ coding style standards so that you can realize that you are not alone, and other people think that many of the features of C++ are inscrutable crap, too.

I mean, I understand the need for templates, but that doesn't mean I have any love for using them. C++ did a good job of adding OOP on top of C as a systems language (class methods are so much cleaner than tables full of pointers to functions), but I'd rather use a language with more dynamic OOP as an applications language. (such as Objective-C, even with it's odd little mishmash of syntax)

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

Wow, you couldn't make a more misinformed statement if you tried.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

You should have said: You should have said: I should have said.

Re:Is the complexity of C++ a practical joke?

[Tailhook]

C# pioneered lambda's.

Ridicule of this has not been sufficient.

Your geek cred has been zeroed. Please turn in your membership card and leave the premises.

Before you go, please note that JavaScript, almost 10 years older than C#, has had lambdas from day one, and I don't believe any other language that has done more to expose the common programmer to lambdas. Eich took some if his design inspiration from Scheme, in which lambdas are central. Scheme, a LISP dialect, goes back to the mid seventies, perhaps before you were born.

C# is a fine Microsoft language, but it had nothing to do with pioneering lambda.

And the index you cite is a laugh. It had Apple's brand new Swift language floating around in the type 10 last month, gone this month. Search engine query frequency is not a terribly meaningful measure. All it means is that those interested in a given language have done a lot of searches, and that fluctuates with events such as press releases.

Over here is a little more comprehensive study of programming language popularity. As you can see, C/C++ give up nothing to C#. Not a damn thing.

Re:Is the complexity of C++ a practical joke?

[angel'o'sphere]

You can write iOS Apps in any language you want.
The limitation to C/C++/Objective C is long long long gone.
And now we have Swift anyway ... get your head out of the sand!

Re:Is the complexity of C++ a practical joke?

[angel'o'sphere]

Class methods, that are those 'defined' with the keyword `staticâ in front, don't need tables of function pointers, nor do non virtual member functions / object methods ;) just nitpicking, sorry.

Re:Is the complexity of C++ a practical joke?

[david_thornley]

C++11 programs can avoid some complication. In general, it's a considerable improvement. It does introduce new concepts, but makes some older ones obsolescent. Any change to an established language has to be an addition (the only exception to this I know of being removing "export" in C++11), so while it's impossible to remove old features it is possible to avoid using them.

The problem with modern C++ is that it is very often ineptly taught. Anybody teaching a C++ class that does more than mention C-type arrays and strings needs to be forcibly retired.

Re:Is the complexity of C++ a practical joke?

[david_thornley]

Look, people are going to write crap code in any language. If you've got to figure out exactly what that yo-yo was trying to do, a few quick manual references aren't going to be much of an additional burden.

Re:Is the complexity of C++ a practical joke?

[david_thornley]

Require braces around all conditionals, and you (a) break immense amounts of code, and (b) make a lot of code harder to read.

Re:Is the complexity of C++ a practical joke?

[david_thornley]

What stuff is unpleasant to use? The syntax of rvalue references is a bit odd, but not much, and you get all sorts of neat things with move constructors and move assignment operators, not to mention std::unique_ptr which works a whole lot better than std::auto_ptr did. "= delete" won't be used much, but it's not much of a cognitive burden either.

The problem with "C with Classes" is that you're abandoning a whole lot of extremely useful things, primarily in the standard library. You don't have to write a template yourself to have your code become much simpler and more reliable by using templates in the library.

Re:Is the complexity of C++ a practical joke?

[serviscope_minor]

Almost every except GCC which is probably the most popular compiler in the world, and LLVM which certainly has a decent following. I don't believe Visual Studio uses EDG for the main compiler either.

Re:Is the complexity of C++ a practical joke?

[serviscope_minor]

Pretty much all of the new features I've seen in the C++11 spec are niche features,

I strongly disagree. It certainly has library-only features like move semantics and variadic templates. However it has a lot of good stuff:

closing templates with >> which is nice.
auto, which I use a lot.
range based for which I use a lot especially with auto.
efficiently returning stuff from a function
bigger faster better standard library including such things as:
* hash tables (finally)
* tuples and multiple return values from a function
* much more efficient vector>
* sane PRNG finally
lambas, which makes the STL algorithms much more useful
better constructors

all this makes writing normal code just much more pleasant and easier and less verbose.

Re:Is the complexity of C++ a practical joke?

[shoor]

"Life is a learning experience, so break out the reference manuals"
That's fine if you're a student. I've been in situations where I was working for a small company and I had to fix problems for the company quickly so they could bill their client and make payroll. If C++ is supposed to be a bunch of languages rolled in to one, then, the code should be flagged, "This is C++ as a functional language, only people who know all the functional stuff should use it, or be hired to maintain it in the future, and don't stick in anything of exotic flavors X, Y, or Z from C++ in it". Or, if the company was serious about doing the product in a functional way, one could use Haskell or Scheme or whatever in the first place."

Re:Is the complexity of C++ a practical joke?

[Garen]

They do use it for Intellisense though, because C++ code is so difficult to process that Microsoft couldn't manage to re-use their own (presumably it'd be too much work to re-architect).

Which means that there are essentially only two truly robust, re-usable C++ front-ends in the world: Clang and EDG. This is bad for everyone, because it hurts portability.

(So I totally emphasize with the OP's comments. I wish there were some way to version the language, so that we wouldn't have to be saddled with backwards compatibiliy cruft for eternity.)

Re:Is the complexity of C++ a practical joke?

[Just Some Guy]

Programming is complex, system's programming doubly so and C++ is designed to help reduce that complexity, while at the same time remaining resource efficient, when it's used correctly. If it's too hot to handle for you there is always Visual Basic.

Or Go, which looks a lot like C Done Right, was designed for systems programming, and has a positively minimal learning curve compared to C++. I get why C++ exists and what problems it aims to solve, but I don't think I'd want to have to use it to solve those problems when there are more programmer-friendly alternatives.

Re:Is the complexity of C++ a practical joke?

[Imbrondir]

Best. Comment. Ever :D

Re:Is the complexity of C++ a practical joke?

[GiganticLyingMouth]

Might I ask what you feel to be unpleasant about C++11's additions? Do you have any specific cases in mind?

A lot of people will (and do) use the =delete syntax. Prior to that you would have to declare the method as being private, but this wasn't perfect. Class friend and member functions could still access them, and the errors would only be detected at link time. Alternately you could use boost noncopyable, but you can't always use boost. With the =delete syntax, errors are detected at compile time, and provide some semantic information about your code to anyone reading it.

Also, it's actually 6 implicit functions that compilers generate; you forgot about the copy-assignment and move-assignment operators.

Re:Is the complexity of C++ a practical joke?

[Coryoth]

It's not the features that you stare at with no idea what they do that cause a problem. As you say, a quick look at the manual can help to sort that out (though it does add to the overall cognitive load). It's all the potentially subtle things that you don't even realise are features and so never look up and don't realise that, contrary to first inspection, the code is actually doing something subtly different to what you expect.

Re:Is the complexity of C++ a practical joke?

[mark-t]

(a) is definitely true. (b) is not necessarily true. (a) is entirely sufficient on its own to not do it, however.

Re:Is the complexity of C++ a practical joke?

[Greyfox]

Having to maintain a bad programmer's code is bad in any language. If the programmer is breaking the problem down, reducing coupling, and writing unit tests for his class APIs then maintaining his code will be easy. If he's writing a ton of spaghetti code where ever class inherits from every other class and nothing is documented or tested, you're going to have a bad time. The difference between C++ and Java or Ruby is that you're more likely to discover you have a problem at compile time with C++. Your java code will probably quietly sit on a web server somewhere, quietly shitting exceptions into a log file no one looks at for a decade.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

What stuff is unpleasant to use? The syntax of rvalue references is a bit odd...

Well, the choice of angle brackets for templates isn't exactly pretty, but that ship sailed long ago...

More seriously, the new style C++11 function declaration syntax is needlessly annoying. The committee could have chosen to introduce a new keyword "function", and not much production code would have been broken (though probably much, much more if they had chosen "func"). Altering C++98/C++03 code containing "function" as an identifier doesn't seem like a herculean burden compared to inflicting this choice of syntax on every C++ programmer, forever (for reasonable values of "forever"). The closely related lambda syntax doesn't massage the eyeballs either, IMHO. I'm aware of the committee discussions around the new function/lambda syntax, but simply disagree with the outcome.

I say these things as someone who strongly prefers C++ for most of the tasks I encounter, but even well-crafted C code can look like symbol soup, and it's a little worse for C++98, even more so for C++11. Of course, the new syntax will become second nature soon enough as it has before, but it will remain less than pleasant.

- T

Re:Is the complexity of C++ a practical joke?

[aaaaaaargh!]

Those that are confused by C++'s complexity are doing it wrong.

Wait a minute ... shouldn't you be using Objective-C or Swift???

Re:Is the complexity of C++ a practical joke?

[dentin]

Oh yeah, (a) is definitely true, but that's no reason to blackhole it immediately, especially if it does something good at the parsing layer. There have been plenty of instances of 'deprecated' features being used for several years with compiler switches to allow it.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

I'm interested in that. Can you recommend a LISP system or a good Ada compiler for iOS?

Re:Is the complexity of C++ a practical joke?

[penguinoid]

Practical, yes. Joke, no.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

Mod up +1Million: Hilarious and never gets old.

Re:Is the complexity of C++ a practical joke?

[technosaurus]

1 example:
Rather than incorporating the typeof() extension that almost every compiler supported, Bjarn decides, nope, we'll call it decltype()

WTF, WTFWTF, WTF...
Its stupid shit like this that fucks up the whole damn language _extension_.
Use syntax that programmer's already know/use and compilers support rather than making up insane new ones.
At least we have C and Objective C.

Re:Is the complexity of C++ a practical joke?

[technosaurus]

Oops, misspelled Bjarne, but not by as much as he misspelled typeof.

Re: Is the complexity of C++ a practical joke?

[Anonymous Coward]

You're a moron. I work with C++ every day and it's no more esoteric than any other language. In fact i find it to be quite elegant. If you can't understand the language it's probably more your failure than the language's..

Re:Is the complexity of C++ a practical joke?

[Jeremi]

The language seems to have reached the point that C++ gurus design it for other C++ gurus, and everyone else ignores it.

I think this is very close to true -- in particular, many new C++ features are there mainly so that the STL can 'magically' do the right thing in more cases. Mere mortals are not expected to make use of the new features directly; rather they are expected to use the improved STL and benefit from its smarter behavior.

Re:Is the complexity of C++ a practical joke?

[juancnuno]

If a separate, Turing-complete programming language emerges from your Turing-complete programming language, it's probably too complex.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

A practical joke? Are you joking? C++ is not designed so that every feature must be learned and used. It's complexity derives from the fact that it supports OOP, functional programming, generic programming and I'm sure others that Bjarne would happily describe to you and the reasoning behind supporting features being included in the language. Those that are confused by C++'s complexity are doing it wrong. As with Perl it's OK to use only what you're comfortable with, no one is going to make fun of you for not using advanced features and if you like you can keep a C++ program pretty basic.

In the real world programmers have to be able to read each others code. We don't get to learn just a subset we like and leave all the yucky stuff. Does your mother still remove the crust from your sandwiches too?

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

Welcome to system programming languages, whose goal is NOT to ;et more programmers to use it - it's to give software developers who know EXACTLY what they need (at an assembler level, and sometimes lower - at an RTL level on a system with irregular clocks and fun memory systems), the tools to do it.

Sounds to me like you're complaining because you think C++ is an applications language, wrong tool wrong job buddy.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

Visual Studio does use EDG. Just Google it.

Yes, clang added C++ support. But look at how long it took them to get even close to 100% syntax coverage. C++98 support wasn't declared feature complete until version 2.8 (October 2010). The first public release was July 2007. So it took them at least 3 years, but considering that clang was always intended to support C++, you should go back to when the project was started, circa 2005. And they had the benefit of GCC's early missteps.

So more realistically it took them 4+ years just to implement C++98! And they were using C++ to write the dang library. Compare that to C. Countless people have put together C compilers with full syntactical coverage in less than a year.

Most experienced engineers can download the C standard, even the new one, and understand the language syntax backwards and forwards rather well in a matter of days or weeks. C++? I'd be surprised if there were more than 100 other people in the entire world with Stroustrup's comprehension of the language.

Re:Is the complexity of C++ a practical joke?

[Katatsumuri]

The problem discussed was not the bad code in general. My only point was that you cannot easily avoid the language features you don't understand or like by "just using your subset of language" in many real-life projects.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

All these people complaining about the complexity of C++ is giving me a huge ego boost.
You are blowing this way out of proportion, C++ is not that much more difficult than other languages, if at all, once you have had some experience with it.
I program in C++ daily for a living and I love it, it's a great language and I think all you haters just need to level up.

Re:Is the complexity of C++ a practical joke?

[serviscope_minor]

The famous google C++ coding standards are awful. They restrict C++ to basically being C with a bunch of weird features tacked on. It means you can't write in Stroustrup Style, which is basically the sane way of using C++ where you write what you *need* to and the compiler does everything else for you automatically.

Which is what a compiler ought to do.

Re:Is the complexity of C++ a practical joke?

[serviscope_minor]

Yep, and this is an example of why C++ is ultimately a success not a failure.

The thing is typeof() was a GCC thing, some other compilers had similar ones but with slightly different names and different semantics and besides the GCC semantics had some flaws.

There are also billions of lines of C++ out there and one of the biggest features of C++ is to never break old conformant code with a new standard if at all possible. So they found decltype as something reasonably descriptive yet present almost nowhere in the world oc C++ code pre '11. The result was that adding it broke almost nothing.

It's a blessing and a curse. The curse is that the new versions are never as clean as they could be because they must necessarily only add features and in odd places at that. It's a blessing because the upgrade to C++11 was exceptionally smooth.

One day I switched the compiler flag, and started writing new code in C++11 and never looked back. Everything including some very extensive and complex C++98 libraries work perfectly without a single error in hundreds of thousands of lines of code. Some of the code in those libraries was last recorded as modified in 2005 (when the library was put into CVS, so there is no record as to when it was actually modified) apart from license headers and yet it still works perfectly.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

you forgot "will you have fries with that?".

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

"I wonder if C++ has become an over-the-top example of how not to do a programming language."

C++ is far from perfect, but I think it is a great example of _how to (do) grow a programming language_. It got something right that most languages today still don't get: never break backwards compatibility.

Seriously, C++ is 30 years old (or even older if you consider that it started with C). It's major accomplishment has been integrating _major_ new language features (parametric polymorphism, lambdas and functional programming, OOP, metaprogramming...) without breaking backwards compatibility (which is a _huge_ constraint). Most of C++ quirks and complexity is a direct result of backwards compatibility with both C and C++ own mistakes. But it is still one of the most successful non-company-baked languages that exist and are in use _today_ . The whole Python 2 vs Python 3 situation that we have had for years and will have for years to come is a result of people not learning what C++ got right. So I don't know if we will still be using Python in 20 years but I'm pretty sure we will still be using some evolution of C++.

So yes, for a language without company support, I really believe C++ is a great example of how to grow a language over an extremely large period of time under extreme constraints and in an extremely fast evolving industry. Tons of new C++ projects are started every day on github (which is not true for, e.g., Fortran).

So to those that wonder if C and C++ are examples of how not do do a programming language, do you have a better example? (Note that even C has not evolved as much as C++, it has still evolved quite a bit without breaking backwards compatibility over the last 30-40 years).

Re:Is the complexity of C++ a practical joke?

[Alioth]

C# is a fine language but it pioneered nothing at all. Especially not lambda expressions.

Re:Is the complexity of C++ a practical joke?

[rdnetto]

A practical joke? Are you joking? C++ is not designed so that every feature must be learned and used. It's complexity derives from the fact that it supports OOP, functional programming, generic programming and I'm sure others that Bjarne would happily describe to you and the reasoning behind supporting features being included in the language.

I disagree. D has feature parity with C++, but is significantly simpler and easier to learn. (This is supported by the fact that their eponymous books, The C++ Programming Language and the D Programming Language, are 1368 and 460 pages respectively.)
C++'s complexity arises from a combination of legacy features and inconsistency.
For example, it has two different kinds of enums - plain/C-style enums and enum classes. Enum classes were created because adding scoping to existing enums would have been a breaking change.
Inconsistency can be seen in things like the runtime initialization rules, where the contents of int x[10]; is uninitialized, but the contents of vector y(10) are initialized to zero.
Essentially, poor decisions were made in the long history of C++, and while it's easy to say that hindsight is 20-20, the reality is that those bad decisions are constraining the direction the language is taking and increasing its complexity.

There is an excellent talk here by Scott Meyers discussing how inconsistent C++ is. These inconsistencies are responsible for the vast majority of the unnecessary complexity in the language.

Re:Is the complexity of C++ a practical joke?

[gbjbaanb]

Ah, but the "won't get used much" means "will be quite a surprise when you see it being used". I guess a smaller language with fewer features is a good thing, because you just can't remember all the bits n bobs that are possible.

I agree rvalue references are not pretty - but maybe they could have used the ^ symbol and screwed Microsoft's C++/CLI over :-)

C with classes - I haven't got a problem with this, but many people do. You see some code written like C and some people shout out "write it in C++" meaning use stl algorithms and suchlike. I think C with classes is a good thing as it introduces the best bits of C++, but then I also think it means learning the better bits won't get done as people will have learned to think in a procedural way, rather than the more functional way the best STL aspects provide.

Maybe its all an intractable problem, and only solvable by removing the few ugly bits around the edges. Things that you can say "but that's only a small problem" but add upto being a mess in the whole.

Re:Is the complexity of C++ a practical joke?

[soccerisgod]

If someone is hell-bent on writing shitty, unreadable code, it doesn't matter what language they're writing it in. Sure, C++ will give you a few extra tools to commit crimes with, but just using C's preprocessor, you can so massively obfuscate your code so as to make it entirely incomprehensible even without malicious templates and impishly overloaded operators. Is any of that the fault of the language, or are you just blaming it for offering many powerful tools? And have you ever tried debugging or understanding a messy java project with 5000 files that does little more than a properly written C++ project with 20 files? I have. The language doens't matter. In conclusion: blame idiotic programmers, not their tools.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

The problem with modern C++ is that it is very often ineptly taught. Anybody teaching a C++ class that does more than mention C-type arrays and strings needs to be forcibly retired.

What tutorials/books do you recommend for learning C++?

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

the reasoning behind supporting features being included in the language

And furthermore those features are not designed to destroy the performance of your software if you choose to use them.

Re:Is the complexity of C++ a practical joke?

[david_thornley]

"Won't get used much" goes much better with "does a simple and obvious thing". (Or, alternatively, with "obviously big thing that you probably should have a clue about", like, say, the regex library.)I think that if somebody who didn't know about "= delete" ran across it, that person would have at least a clue what it does. That the programmer didn't know about it beforehand, and did the old declare as private and don't define trick, doesn't seem to me to be a problem.

While screwing over C++/CLI is always tempting, it's probably overall not the right thing to do.

We disagree on the "best bits" of C++, I see.

C++ is indeed always going to be needlessly complex. If we could yank out much of the older parts of the language, including much that came over from C, we could construct a much better language. I believe that's what D is trying to do, but I haven't really looked into it. (It's not something I currently find necessary for projects or work, and I don't think that learning it would teach me nearly as much as learning Haskell or Erlang.) If we could redo the syntax, we could make it much easier to compile and clearer to read and write. (One of my gripes with Java is that, having broken compatibility with C, they kept the broken switch statement semantics.)

So, there will come a time when adding stuff onto C++ is going to be impractical, not that using the language will be difficult, but that understanding old code is going to become something only a true expert will be able to do. (Currently, it isn't that hard for somebody with a good grounding in C.) I don't know when that will happen.

Re:Is the complexity of C++ a practical joke?

[david_thornley]

As far as (b) goes, sometimes putting more braces in will make code more readable, and sometimes it'll just take up vertical space without clarifying things enough to compensate. I'd say that's a good (if not necessarily sufficient) reason to not make them required.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

If I have to read, debug, maintain, and extend someone else's code, I'm going to have to invest time and effort into understanding it anyway. I'd like as much of that effort and understanding as possible to go toward standardized, well-thought-out tools -- the knowledge of which I can actually take away and apply elsewhere -- than spend it all trying to grok some B-list programmer's attempt at hacking together a fascimile of .

This argument is nonsense, and it always has been. Not using C++ does not magically absolve your code of the need to implement things that would be well-served by the features of C++. All it does is raise the bar of understanding from "learn how to use virtual functions" to "learn how to use the tag-based dispatch mechanism Bob wrote fifteen years ago," and lower the bar of code quality accordingly.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

That should read, "a fascimile of (insert language feature here)."

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

A practical joke? Are you joking? C++ is not designed so that every feature must be learned and used...

Hmmm, I wonder if the engineers who come up with the most arcane C++ interview questions know this...

Re:Is the complexity of C++ a practical joke?

[Salgat]

I've just started learning C++ and C++11 makes things so much easier and they add desperately needed features such as threading and smart pointers which reduces the need for including more libraries. If anything, C++11 simply expands the standard library to include more functions that you'd otherwise have more difficult solutions for or have to include libraries for (such as BOOST, from which many features come from). I love what they are doing with C++11 and hope that the next major update includes even more features to make it an even more complete language (such as Python, which has countless standard libraries, far more than C++, that no one seems to be complaining about).

Re:Is the complexity of C++ a practical joke?

[micahraleigh]

Right. I didn't say lambda's were born/invented with/etc C#.

When I think of Lisp I think of a lot of government forgotten-ware.

Not something that is going to reveal the hidden value of lambdas.

Re:Is the complexity of C++ a practical joke?

[micahraleigh]

That is exactly what I think the s-expressions are trying to say to me.

I thought Java and C# were more of a winning case for lambdas.

Re:Is the complexity of C++ a practical joke?

[micahraleigh]

No one was successful with lambdas until C#.

Unless you count the government/university software revolution that never happened.

Re:Is the complexity of C++ a practical joke?

[micahraleigh]

You are right, although not on the level you perhaps intended.

To me there are the people who make software that contribute to people's lives and receive funds roughly commensurate to that.

And then ... there are the software afficionados. The people who blow smoke around about what such-and-such a version of gcc used to be like and how they would never commit a faux pas like calling Application.DoEvents() or not return a method immediately when the answer is arrived at.

These are the people who polish their publicly funded government forgotten-ware and then bloviate to their students about their arcane little successes that have some kind of inherent meaning disclosing their intelligence to the universe but really don't do anything for, well, you know, ordinary human beings ... who don't know about all the SW ettiquettes and posturings, etc.

Yeah, I've spent a lot of time with scheme people. I don't think it's a persuasive case for lambdas. It was part of the reason I quit my job and started doing C#.

Getting rich is a sad goal that devours peoples' entire lives, but at least you can say it involves doing something people will pay money for (at least in the private sector). The index you mentioned is interesting. I've looked at a few, and I'll have to check it out, but here's another one: dice.com. If a language is on a job posting it means people are paying money for it, and the only people getting rich off schemes are the ones who are into the government/university's back pocket.

All of that is to say ... yeah, I can't give you my geek card because I never had one. So, on some level, you are correct.

JavaScript is a pretty good example (not very polished, I might add). I should have brought that up since it is older.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

You can also get draft standards from the WG21 website for free. They're technically non-normative, but the biggest difference is probably the cover page.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

If you're working with someone else's code, your job IS to learn new shit, namely THEIR CODE. If their code leverages standard C++ features to accomplish its goal, your job is made easier by an entire Internet full of reference material, and you need only work out how they used construct X, not how they used AND implemented construct X.

And just what aspect of C++ is it that you think is going to take more than three minutes to look up? If it's just a matter of you not even knowing templates, that's not C++'s fault, that's the fault of the idiot who hired a non-C++-programmer to do a C++ programmer's job. It would be like hiring someone to write C who's never used pointers or arrays. Don't go blaming the language for having things you haven't bothered to learn how to use.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

No, this needs to be modded -10. Have some respect by not posting insulting questions b/c you couldn't be bothered to obtain proficiency in the language the man created.

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

" Are you joking? C++ is not designed so that every feature must be learned and used." [...] "But it supports all these features to give people what they need to get their jobs done."

As a result, every C++ programmer knows 40% of C++, just not the same 40%.

Is it just me or does that not defeat the purpose of having a language in the first place --- you know, something that enables and promotes communication and comprehension?

Re:Is the complexity of C++ a practical joke?

[Anonymous Coward]

"And? Life is a learning experience."

Correct, if you have to learn C++, then life is a (one) learning experience, namely, C++.

Re:Is the complexity of C++ a practical joke?

[suy]

Any practical example to back it up? Probably there are some cases of that, but the contrary is IMHO more common. One of the most popular C++ library out there, Qt, doesn't make you learn exceptions, and templates are only used for containers, so you rarely see one of those scary compilation errors.

That means that in practice, you see large C++ codebases that are very easy to grasp. At my current workplace, all C++ developers barely understand C++ outside the C subset, and projects work fine from the customer perspective. Do they understand that each time they pass a value to a function they are copying it, and that it can be costly? No, but luckily they are doing that with QByteArray, which is implicitly shared. They don't have to understand the feature. Besides me they don't even know it exists, but it works, and saves the day.

Re:Is the complexity of C++ a practical joke?

[Megane]

Sheesh. I didn't mean Class Methods[tm](R)DoNotSteal, I meant methods attached to the class.

Re:Is the complexity of C++ a practical joke?

[euroq]

You are what is called a "C++ apologist". You are comparing C++ to nothing except itself and abstract complexity (and offhandedly VisualBasic), instead of actually coming to terms with the real problems of C++.

Let me offer you a few pieces of evidence of C++'s failures.
* C++ has a text preprocessor. A solution to engineering constraints of fucking 1970. No one has or will ever do that since 1975. Everything is and should be resolved symbolically.
* C++ is meant to be able to compile C code with no to minimal changes. This really makes
* D. Read http://dlang.org/cpptod.html which is a description of how another systems-level language dealt with perceived drawbacks of C++. I don't think D is perfect by any means, but there are many thoughtful improvements to C++.
* Read http://yosefk.com/c++fqa/defec... for a bunch of valid complaints about C++ (granted, many of those can be argued).

Re:Is the complexity of C++ a practical joke?

[euroq]

The difference between C++ and Java or Ruby is that you're more likely to discover you have a problem at compile time with C++.

Totally not trolling here - can you explain that? It seems to me that any statically-typed language is equally capable of finding problems at compile time.

Are you referring to the fact that it's possible to typedef integers in C++ and not in Java/Ruby? So using an int incorrectly in Java/Ruby wouldn't cause a compile error? That seems like a big stretch to me, that that's actually a quantifiable boon to C++.

Quietly shitting exceptions into a log file is actually better behavior than crashing (unless there's data corruption involved), and in fact, sounds like expected behavior.

Web Friendly

[gunner_von_diamond]

Are there any future plans to gear c++ more towards the increasingly popular web development, or will that depend on 3rd party libraries, etc.?

On the evolution of C++

[stox]

How do you feel about the evolution of C++ since it was first implemented with Cfront? What began as a pretty straightforward language has been expanded to significant complexity. Has this evolution been positive, or has it been an attempt to make the language apply to too many possible applications?

Favourite programming language

[Bugamn]

What is your favourite programming language that isn't C++ (or C)?

Re:Favourite programming language

[Anonymous Coward]

Probably Malbolge.

Re:Favourite programming language

[jbcksfrt]

No mod points, but would +1. Very good question.

Re:Favourite programming language

[Anonymous Coward]

I'm voting it's going to be Simula.

Re: Favourite programming language

[Anonymous Coward]

Check it oot

http://en.m.wikipedia.org/wiki/Malbolge

Re:Favourite programming language

[rccorkum]

asm hands down been since I started coding on the mostek in 1984. elegant clean fast and does exactly what you want when you want.

Re:Favourite programming language

[Anonymous Coward]

null

Do you ever feel bad?

[slashdice]

Maybe the premise of this question is wrong... but I seem to recall reading somewhere that you hate C but built C++ on top of it because it was popular. Is that true and if so, do you ever feel bad about the bait and switch?

Re:Do you ever feel bad?

[dentin]

Further, since C++ is often called 'a better C' and is not backwards compatible with C compilers, will there be specification changes to sanitize and improve the lower level C aspects that are problematic? Examples would be strict parsing of the language without compiler dependent ambiguity, removal of duplicate constructs such as the ternary operator, requiring braces after all conditionals, strictly defining the bit width of standard types (int = 32 bits, short = 16 bits, char = 8 bits), etc.

Re:Do you ever feel bad?

[david_thornley]

If you read his "Design and Evolution of C++", which is a great book, you'll find that he really liked the classes from Simula 67, and found it painful to translate all that into C when he actually had to run a large-scale simulation. The original "C with Classes" was a language that compiled to fast code and was heavily portable, but had Simula 67 classes.

If you're going to ask about a "bait and switch", could you be specific about what you think that is?

also:

[slashdice]

Has everyone responsible for the std::vector<bool> tragedy been kicked in the nuts until they are no longer at risk of reproducing?

Re:also:

[micahraleigh]

More routine promotion of eugenics at slashdot.

And the qualitative difference between this and the 3rd Reich is ..?

Re:also:

[david_thornley]

Similarly, are we stuck with that particular idiocy forever, or do you think we can get it out of the standard and into the garbage heap where it belongs?

Remember, kids, almost all things in the container libraries are good STL containers, except for that one abortion that's easy for somebody to use and confusing if they fall into the trap?

Re:also:

[Just Some Guy]

Trigger warning: butthurt.

Re:also:

[Anonymous Coward]

Could you explain the tragedy? How people have been using that wrongly?

Re:also:

[slashdice]

std::vector is specialized to compress/store the values as bits rather than bools (basically a variable length std::bitset). operator[] returns a proxy object rather than a boolean&. It's a clever trick but it should be a separate class, not a specialization, since it violates their own rules for containers and can break your code (how do you take the address of a bit? Oh, you can't). One of Scott Meyers's (Effective C++, Effective STL, etc) rules is: Dont use it.

Regrets

[Anonymous Coward]

What do you regret most in C++ and how would you like to change it?

Re:Regrets

[david_thornley]

I don't have mod points, but if I did I'd mod the above up. Great question.

Replacement for iostream

[tepples]

The general consensus as I understand it is that the <iostream> wing of the C++ standard library is hairy, convoluted, time inefficient, and space inefficient in implementation. What's the better solution? <cstdio>? Is Boost.Format, as shutdown -p now suggested, any good?

Re:Replacement for iostream

[david_thornley]

cstdio is way type-unsafe and nonextendable*. Other than that, it's more readable (to me, anyway), and easier to implement. I'd like a different solution.

*There is no way to specify a format for size_t in C that will work in all official standards. "%z" wasn't introduced until C99, and "%ul" is not guaranteed to work on any standard with "long long", even with a cast.

Future of C++ Standard Library

[DaphneDiane]

One of the recent concerns raised with C++ compared to other popular languages is the breadth of the standard library. I know that the C++ standard committee was looking at adding a C++ transformed version of Cairo to the standard. And of course their is boost. What else do you see coming to address the perceived API shortcomings?

Re:Future of C++ Standard Library

[serviscope_minor]

This is certainly true: the C++ standard library is not very extensive.

However, when I program in other languages I also amazingly miss the C++ standard library.

It seems that the C++ library is heavily focused on writing algorithmic code and so misses all the things like images, files (except a tiny bit), parsing, sockets and so on. Other languages focus on those and ignore the algorithmic side.

Precious few languages have things like heaps in the library. Fewer still have things like a linear time nth_element.

Designing a Language and not a Compiler

[dasacc22]

With so many new languages writing a spec and then a standard compiler to conform to the spec, I'm curious how you feel about writing a spec and not a compiler.

How do you think this compares to other efforts? Do you enjoy this aspect or do you occasionally get your hands dirty with a particular compiler source? etc.

Hour of Code

[Orestesx]

What is your opinion of the the "Hour of Code" as promoted by CSEdWeek? Does it trivialize computer science education?

On syntax

[Anonymous Coward]

When are you going to recant your decision that types are more impotant then syntax clarity and tell everyone you made mistake putting the * next to the type instead of next to the variable where it belongs?

ABI

[gbjbaanb]

Do you think that one thing holding C++ back is the lack of a standarized binary interface?

Currently if I want to make a module that can be consumed by others (whether than is others using a different language, or a different C++ compiler, or even just to use a pre-built module without sources) I have to export everything as C and use its (de-facto if nothing else) binary standard.

I think an ABI for C++ would increase its "real world" attractiveness considerably with little, if any, overhead. Do you agree, or are there issues around this that make it a significant challenge (apart from vendor adoption of course).

Re:ABI

[MouseTheLuckyDog]

Let me add to this, do you think an ABI plus a specified subset of C++ to be used in the creation of script interpreters and REPLS which can use binary modules created by C++ is a good idea?

Re:ABI

[Anonymous Coward]

I'm pretty sure the proposal for a stable C++ ABI has been more or less well received. IIRC there were some complaints about having to maintain two ABIs (one stable, one modern), but people are working on it as far as I know.

Re:ABI

[Anonymous Coward]

Do you think that one thing holding C++ back is the lack of a standarized binary interface?

[...]

I think an ABI for C++ would increase its "real world" attractiveness considerably with little, if any, overhead.[...]

ABI is the visible barrier that everyone sees, and thus, the apparent problem that everyone believes needs solving.

But the truth is that there are others.

Allocators, for one: If your two different libraries link to different runtimes, memory allocation and deallocation cannot cross library boundaries. In fact, you would have the same problem with all global variables (like the console I/O). In the end, I guess, in addition to the ABI, an unique runtime for each OS.

Then, you would need to make sure compatibility would be respected, both forward and backward. Because if not, then your two libraries compiled with different versions of the runtime would not even correctly start.

You should read Herb Sutter's proposition for more information on the subject:

https://isocpp.org/blog/2014/05/n4028

Re:ABI

[serviscope_minor]

Ah but the quesion is *which* subset?

I can think of very few features of C++ which I could remove that would have little impact on my code.

Re:ABI

[Anonymous Coward]

Note that C has no standard ABI either.

ABI compatibility is a "platform" responsibility (Windows/MacOS/Linux/...). Under Linux the gcc guys try really hard not to break the ABI. Microsoft breaks their C++ ABI every year.

So I don't know what a better question would look like. If I had to try it would be something like: "Hey Microsoft folks, if I had to target windows I would hate you for making me pay for different versions of windows and visual studio every year while forcing me to maintain a collection of all the older ones such that I can support my customers. So How is the business plan of screwing your developers by breaking the C++ ABI every year going? Is it successful?"

diversity?

[slashdice]

Workforce diversity is a big issue these days. What steps has the c++ working group taken to increase the numbers of female and minority contributors? C++ (perhaps unfairly, due to the popularity) is often criticized in feminist circles for being a patriarchal programming language. Will you be taking steps to address those concerns?

Re:diversity?

[angel'o'sphere]

I'm actually mainly concerned about females of asian+black ancestry or asian+caribbean ancestry. Well, considering the caribbeans are already a melange, I guess you get my drive.

It would be so cool to have a few of such girls around in my office ... I would not mind if they only do C# or Java ...

Re:diversity?

[technosaurus]

What, is the '++'  a replacement for 'ox'?

Re:diversity?

[Anonymous Coward]

That comma is horribly misplaced.

AI writing code?

[Katatsumuri]

Do you think AI will start replacing junior programmers in the foreseeable future, similar to car drivers and call center operators?

Re:AI writing code?

[Marginal Coward]

Do you think AI will start replacing junior programmers in the foreseeable future, similar to car drivers and call center operators?

Why ask Dr. Stroustrup and wait for an answer? Siri could tell you now...

Re:AI writing code?

[Katatsumuri]

I appreciate the humor, but actually Siri is another example of a human job (personal assistant) going partially obsolete. Not that the current implementation is good enough to answer questions like this one.

Re:AI writing code?

[Greyfox]

That's a funny question. In order to write a program, you have to understand your requirements. Most people with their meatputers are not capable of this. Given that they have no hope, how is an AI supposed to do anything?

Re:AI writing code?

[Katatsumuri]

That's a funny question. In order to make real-time decisions in a life-critical task like driving, you have to understand the requirements (written traffic rules, conventions and real-world limitations), stay aware of the current road situation and weather conditions, guess the intentions of the other traffic participants, and keep your concentration for long periods of time. Most people with their meatputers are not capable of this (see traffic incidents and deaths statistics). Given that they have no hope, how is an AI supposed to do anything?

Memory Allocation

[Anonymous Coward]

Why doesn't C++ have in language support for memory allocation?
And don't give me that baloney about it being a library feature: We all know that memory allocation of variables on the stack is not handled manually by the programmer.
If you don't add it C# and Java with their GC awfulness will continue to eat C++'s lunch.

Multiple Return Types?

[UnknownSoldier]

When is C++ going to natively support multiple return types?
i.e.

float sin, cos, angle;
    sin, cos := SinCos( angle );

Right now we can use a struct hack, but native support would be appreciated.

_When_ are pragmas going to be standardized instead of relying on brain-dead proprietary extensions where MSVC does things one way and GCC another way? i.e. I'm specifically talking about the idiotic verbose

__attribute__((always_inline))
 
    __inline
    __forceinline

intead of having a native way to hint the compiler about how hot or cold a function is.

inline = 100 void Foo(); // function is 100% hot, always inline
 
inline = 0 void Foo(); // function is 0% cold, never inline
 
inline = 75 void Foo(); // function is 75% hot, inline most of the time

Lastly, C++ has been extremely complex. When is C++ going to simplify the total over-engineering of the language?

Re:Multiple Return Types?

[tepples]

One question per post please.

When is C++ going to natively support multiple return types?

You refer to the struct or tuple hacks. PHP and Python use a tuple hack similar to C++'s to return multiple values. Perhaps what you really want is readable syntax for assignment of multiple variables from a std::tuple. And now my own question for Bjarne: When are we getting that?

Re:Multiple Return Types?

[angel'o'sphere]

Either you want to inline a function or not. You hotness makes no sense at all. Considering that compilers inline aggressively anyway if they can, you proposal is nonsense.

Re:Multiple Return Types?

[dentin]

The last thing C++ needs right now is another complex feature which adds more syntax and fundamentally new operation.

Re:Multiple Return Types?

[dentin]

Hopefully, not for a long time. C++ doesn't need more complexity at the moment. It needs less.

Re:Multiple Return Types?

[david_thornley]

FWIW, I've returned a std::pair on occasion. It's a bit like the struct hack, but cleaner to write.

Re:Multiple Return Types?

[david_thornley]

_When_ are pragmas going to be standardized....

Pragmas are specifically intended to be compiler dependent. They're never going to be completely standardized.

BTW, you usually don't want to specify a function as inline or not inline, since it's usually better to choose at the point of use, depending on a whole lot of things the programmer simply isn't going to know. If you really need it inline for some weird reason, use a template.

Re:Multiple Return Types?

[GiganticLyingMouth]

When is C++ going to natively support multiple return types? i.e.

float sin, cos, angle; sin, cos := SinCos( angle );

Right now we can use a struct hack, but native support would be appreciated.

You could always just return a tuple, then use tie on the caller side. To use your example,

std::tuple SinCos(float angle) {
...
return std::make_tuple(sin, cos);
}

float sin, cos;
std::tie(sin, cos) = SinCos(angle);

Also, your last question isn't really a question, is it?

Re:Multiple Return Types?

[Anonymous Coward]

std::tie is not readable enough for you? It's under the link you've given.

Re:Multiple Return Types?

[tepples]

I admit I didn't read the entire page. That syntax looks like PHP list(). Problem solved; thanks for pointing that out.

Re:Multiple Return Types?

[UnknownSoldier]

Do you understand profile-guided optimization ?

You feed the results of the profiler BACK into the compiler so it can adjust inlining as necessary.

If you don't understand a concept, ASK.

Re:Multiple Return Types?

[angel'o'sphere]

So you want to inline it depending on its usage, depending on a profiler.
Does still not make sense. The cost for a particular function is the exact same regardless where you call it.
And furthermore defining some hotness inside of the function or class is the wrong concept anyway.
If you have a smart idea how to use a profiler for optimizing, then you should be equally smart and write the "how to optimize" definition in an external language, and not inside of the C++ code.
Java and C# and co got that already wrong when they introduced annotations.

Regarding concept ... which I did not grasp ... and should ask about: you nowhere in your post said "profiling profile". You simply said "profile" which may mean anything, like an UML profile.

However the approach of semi dynamic optimization using a profiler is interesting, after all that is how the JIT in modern VMs does it ... at runtime.

Re:Multiple Return Types?

[UnknownSoldier]

> Does still not make sense. The cost for a particular function is the exact same regardless where you call it.

Do you even understand what an Instruction Cache is?? And the importance of locality?? Too -much- inlining can be worse then not enough inlining. If had actually worked on a C++ compiler on consoles then you would understand.

On PS3 some games can have a performance delta upto ~10% depending on a) the DISTANCE away non-inlined functions are, and b) HOW MANY functions are inlined. I'm talking from real world experience not from your theoretical clueless assumptions of how CPUs work.

In theory every memory access has the same cost (time), in practice the 3 levels of cache show a wildly varying performance difference.

You really should read: "What every programmer should know about memory"

http://www.akkadia.org/drepper...

Before continuing to spout off your ignorance.

Re:Multiple Return Types?

[angel'o'sphere]

Dude, you started it. Please don't jump from one point to the other and claim all the time I had no clue.
You wanted to use a single numeric value as hint to the compiler if it should inline or not ... obviously that does not work.
As you now gave several complications that can occur.
So why are you nitpicking on me instead of admitting that a single 'hotness' value (or however you called it) or a few of them _inside_ the class definition does not make sense?

Boost ASIO

[Rob Riggs]

When will Boost ASIO make in into the standard library? C++ really needs something of this magnitude for networking and asynchronous event handling. I have not heard much on N3360 since it was proposed.

Re:Boost ASIO

[simula]

In the WG21 meeting, the networking technical specification group voted to adopt Boost.ASIO as a starting point.

They have been working on low-level details, so this is a surprising turn-around and it is wonderful news.

I'm not sure if it will make it into C++17, but my fingers are crossed.

Darl McBride says SCO owns C++

[DickBreath]

How do you feel about the fact that Darl McBride said that SCO owns C++?

Source 1
Source 2
Source 3
Source 4

Re:Darl McBride says SCO owns C++

[Anonymous Coward]

Daddy wants his balls scratched a little. Go now!

new and delete; viral disposability

[tepples]

Why doesn't C++ have in language support for memory allocation?

C++ has the new and delete operators, whose low-level operation a class can customize. Could you clarify what you're asking for?

If you don't add it C# and Java with their GC awfulness will continue to eat C++'s lunch.

The problem with tracing garbage collection as implemented in Java, C#, and the like is that it tends to break the Resource Acquisition Is Initialization (RAII) idiom seen in C++, where an object's destructor is responsible for freeing non-memory resources held by the object, and the language supports calling this destructor automatically in many cases. Instead, GC languages have what I call "viral disposability": a conventional name for an explicit destructor method that an object's owner must remember to call, and anything holding a disposable object must also be disposable.

Re:new and delete; viral disposability

[angel'o'sphere]

That is nonsense.
RAII concepts work on plain objects, which enter scope and leave scope, like in a function, and call the constructor on 'allocation' and the destructor when the scope is left. Either via an exception or a return.

A GC works on pointers/references, and works seamlessly together with RIAA, constructors/destructors.

Worst case is, a GC stumbles over some memory that is already flagged as being freed due to a 'delete' in a destructor.

Re:new and delete; viral disposability

[0123456]

Garbage collection solves many memory allocation bugs by introducing new bugs, and other issues like massive memory bloat. It's just another magic solution to poor programming which allows poor programmers to screw things up in new and creative ways.

Re:new and delete; viral disposability

[angel'o'sphere]

If you think so, you are likely a poor programmer yourself.
I have never seen a C/C++ application with no memory errors. Even I had once one, a third party library deleted the pointer I handed to it ... pretty bizarre.
Your conceptions/perceptions about GC are simply wrong, I suggest you work with a GCed language once.

Re:new and delete; viral disposability

[Anonymous Coward]

Sorry I wasn't clear in my OP; what I meant to ask was:
"Why doesn't C++ have in language support for allocating and deallocating variables automatically on the heap."
C++ handles allocating and deallocating variables automatically on the stack, why not the heap?
Having to use RAII for heap memory allocation is a language FAIL.
GCs are also a FAIL; at the minimum they screw up predictability.

Re:new and delete; viral disposability

[Anonymous Coward]

No, he's right. You are an amateur.

Re:new and delete; viral disposability

[david_thornley]

With a smart pointer, RAII works just peachy on memory, as well as any other form of resource. std::shared_ptr is reference-count garbage collection - not the best, but I think it's worth it to have a uniform method of resource management.

GC does not work with destructors, since it's usually not even guaranteed that a destructor or equivalent will be called. Some languages have separate basic/primitive types and pointer/reference types, but that's not the case in C++.

Re:new and delete; viral disposability

[Anonymous Coward]

No... just NO.

shared_ptrs pretty much solve all the crazy exception-case memory leaks.
Move semantics fixes other edge cases by letting use detect temporaries.

I *only* produce code that has 0 "definitely" and 0 "possibly" output from Valgrind. A single commit that adds a leak is not allowed.

I'm talking about a huge code base that takes over 5 minutes to compile on a decent machine with well over 100,000 lines. Yet my code is 100% leak free and will remain so.

Plus when you deal with big data like I do, manually freeing memory is a godsend. I do some strange stuff like pass pointers to other threads in a lock-free fashion if I know I have uniform memory layout and no modifications while all the threads access the object. With GC in the picture I no longer get those guarantees and it's hard to know if I can send some object to a bunch of threads without each making a copy or killing my performance with mutex locks.

C++ is *perfect* for big-data coding. I've yet to see a Java program that read these terabyte plus files and hold them in memory while allowing many threads to work on that data without races/crashes/memory issues. Let alone toying with JVM memory settings for a tool that thinks it's too smart for what it is. Just say no.

Re:new and delete; viral disposability

[tepples]

Probably because unique and shared pointers, added to the C++ standard library in 2011, make the feature not so necessary in the language itself.

Re:new and delete; viral disposability

[angel'o'sphere]

Using a smart pointer in a function is something completely different than using a plain object for RAII.

GC does not work with destructors, since it's usually not even guaranteed that a destructor or equivalent will be called. That is either plain wrong or a misconception. Java or C# has mo destructors, but uses GC, so claiming anything about them is pointless. Managed C++ has destructors AND finalizers AND GC, and the destructor is called if needed ...

Perhaps you mix up the fact that no one guarantees that the GC is collecting your object, hence the finalizer may not be called e.g. in case the program exits before a GC ever occurs? That however has nothing to do with the calling of destructors per se.

Re:new and delete; viral disposability

[fnj]

OP AC is a moron. He's not gonna get it.

Re:new and delete; viral disposability

[Anonymous Coward]

Try to work with Delegates on C#, or their equivalent in Java (listeners and anonymous classes) and you'll see it is easy to have an object registered somewhere, and then never collected, despite you having forgotten all about it.

That's a leak.

With a GC.

Suck it up.

Re:new and delete; viral disposability

[david_thornley]

In C++, it would be dangerous to add differences between some sort of resource-controlling object on the stack vs. on the free store. They are the same object, allocated differently. They are not completely different.

The GC I'm familiar with doesn't work well with destructors. RAII depends heavily on destructors. I'll have to see what Managed C++ (or C++/CLI or whatever) does with them. If it just differentiates between stuff that will have destructors and stuff that will be garbage collected, it's got real problems.

Imagine some sort of resource that really should be released promptly when not needed, and is needed in two separate functions, so that there's really no place in the code where it definitely should be freed that happens anytime near when it should be freed. Currently in C++, I'd make an RAII object and allocate it using a std::shared_ptr. Even in cases where I might forget there's resources (like a std::vector, which may or may not own some allocated memory), this works. I'm definitely not interested in cases where I'd have to change anything outside the class definition if I add a std::vector to the class.

Re:new and delete; viral disposability

[angel'o'sphere]

Sigh ... you are half right and all wrong.

GCed objects are allocated with new. Standard allocated objects are managed with new/delete.

RAII objects are statically/automatically initialized, that means they 'are not on the heap'! That means the GC won't even see them and would definitely not interfere with them.

Even with a GC below your belt using smart pointers still would work.

You simply don't get that all this 'constructs' are not even orthogonal but parallel concepts that easy fit together.

Especially in C++ where you could simply require that all GCed classes implement the new() operator in a specific way.

I'm definitely not interested in cases where I'd have to change anything outside the class definition if I add a std::vector to the class. If you had GC, what would you need to change? Nothing ofc ... (* facepalm *)

Re: new and delete; viral disposability

[Anonymous Coward]

after reading thru this thread and many others. I've come to the conclusion that angel is a huge asshole. he is conceded,
big headed, ignorant, and a fucking wArt on this->industry. he always downs other people and trashes everything he is not a fanboi of. instead of talking to people politely and working with them, he mocks them and criticizes their train of thought because it doesn't resemble his. it's a shame to because angel you really are a smart person, we get that. you could add so much to this industry if you would just get your head out of your ass.

fuck typos, punctuations, etc. I'm chatting on ./ using a phone and not writing a fucking thesis or term paper or documentation. so to all the grammar nazis, suck a dick and get a life, go grade papers if you want to point out grammar mistakes. I type in a way that makes it fast and gets the point across.

(mC) Saving mods

Re:new and delete; viral disposability

[Anonymous Coward]

I have never seen a C/C++ application with no memory errors. Even I had once one, a third party library deleted the pointer I handed to it ... pretty bizarre.

That isn't much different from a third-party C# library improperly using your IDisposable object in a using-block[1], thereby unexpectedly calling its Dispose method. In Java, a third-party library could erroneously free one or more objects of an object array passed to it, or (as of Java 7) problems could arise from multiple calls to AutoClosable.Close, which is not guaranteed to be idempotent.

In short, buggy third-party libraries in any language can impact even pristine code.

- T

[1] I encountered this once with a third-party .Net library which wrapped ADSI/LDAP on Windows Server 2003; might have been fixed for later Windows Server versions.

Re:new and delete; viral disposability

[david_thornley]

RAII objects are constructed. This can very definitely be on the heap. If, for example, I want an RAII object for something shared in several places, I would probably put it into a shared_ptr, and that does mean on the heap. Consider "make_shared(new DatabaseConnection);". That would work just fine. Where did you learn C++?

You simply don't get that RAII practice in C++ isn't what you expect. Are you more familiar with languages like C# or Java? In those languages, there's a distinction between stack data types and heap data types, which is completely lacking in C++. Nothing wrong with not knowing C++ as well as I do, but it means you really shouldn't tell me I'm wrong in fairly simple things.

As far as the vector....a class may or may not control or access external resources. If not, then there's no problem with garbage-collecting it, since either it's still in use, the space is not yet needed again, or it can be removed cleanly. If it does, then there has to be some way to deal with the resources. If it's memory, then it can be scooped up (my example of adding a vector turns out to have been wrong), and there's no problem. If it has a smart pointer or something pointing to something that really should be released promptly, then standard garbage collection is likely to leave that object sitting around, undestructed, for a long time. The idea of having GCable and non-GCable classes introduces more complexity, and offers a really obscure way to get resource management wrong.

Re:new and delete; viral disposability

[angel'o'sphere]

RAII objects are constructed. This can very definitely be on the heap. If, for example, I want an RAII object for something shared in several places, I would probably put it into a shared_ptr, and that does mean on the heap. Consider "make_shared(new DatabaseConnection);". That would work just fine. Where did you learn C++?

Erm, where did you learn C++?
The DatabaseConnection is not a RAII object ... the shared_ptr is!

Everything you allocate with new is on the heap or wherever your self programmed operator new() puts it.
Everything you allocate with new is not a RAII object.

To have RAII objects you have to allocate them statically or on the stack. A no brainer.

Wrapping pointers into any kind of helper template makes that helper template the RAII object. And ofc. that object can delete the pointer it is holding.

The idea of having GCable and non-GCable classes introduces more complexity, and offers a really Obscure way to get resource management wrong no it does not :D that is only your perception.

Re:new and delete; viral disposability

[angel'o'sphere]

Oh, I oversaw this:
Are you more familiar with languages like C# or Java? In those languages, there's a distinction between stack data types and heap data types, which is completely lacking in C++

Wrong in all cases, most importantly it is not a data type, except in C#, but a storage class:
Java does not distinguish, as it can't. You can only create objects on the heap, even loaded classes are objects on the heap. The exception are primitive data types that are "defined" inside methods and parameters passed to such methods (primitive or references), those are on the stack. In other words you neither have a "static area" nor can you place a single int onto the heap.
C# does distinguish, but in a bit hard to grasp way, hence half the posts on stackoverflow regarding value objects are wrong ;D. In C# you have so called value objects (besides the classical objects on the heap), those objects behave a bit like C++ objects. The "non value" objects are always on the heap, references to them are everywhere (stack/heap depending on usage).
The value objects are either analogous to nested flat allocated classes/structs inside of other classes (not declared as pointer or reference) or to C++ objects that are passed around as well, values. E.g. a method argument, that is not a reference. Then they get copied, just like in C++.

Nothing wrong with not knowing C++ as well as I do Is that an attempt to make a joke? If so it is pretty lame, I doubt there are more than 10 people on /. that know more about C++ than I do ... the saying is: I forgot more about C++ than you ever will know.

Anyway, back to the first topic. You are completely wrong that C++ does not have that distinction. And I really wonder how you come to that strange idea. C++ is the mother, or rather C, of different "storage classes".

Every variable that is defined outside of a class in a simple C++ file has static linkage, does not matter if you write "static" in front of it, or not. Exact meaning of "static" varies on usage, I assume you know that, so I don't dig into it. Such a variable comes into the so called data segment and usually they are referred to as "static variables" (regardless if you declared them static or not, that only changes the visibility for the linker).
Now, everything that is passed to a function is passed via the stack, if it is a plain object it is copied (via copy constructors or oerator = or if none of them exists by a simple memcpy())
Finally everything you allocate with new/malloc is on the heap. Unless you overwrite operator new and have a neat trick to allocate the instances elsewhere.
In C/C++ you can btw fully control where "variables" are allocated by either prepending them with static or auto. E.g. function parameters and local variables are by default "auto" (and that has nothing to do with the "new usage" of the keyword 'auto'), auto means: they are on the stack. You can also declare "global variables" as auto, then they are allocated before main is called on the stack (I guess most C/C++ compilers don't really support this and ignore the auto keyword in tis case). Finally you can put every function argument or local variable explicit into the "static" area by writing static in front of it.

Hint: read about storage classes before you make yourself look like an complete idiot. "not knowing C++ as well as I do," my ass. You can repeat that sentence when you are fluent in C++14 ... as I likely won't use that in the foreseeable future.

Re:new and delete; viral disposability

[david_thornley]

Where did I learn C++? Primarily on the job over fifteen years ago, supplemented by reading extensively. I'm not claiming to be a real expert, but I do have reasons behind what I say.

In what sense is a DatabaseConnection not an RAII object? Assuming the constructor allocates the connection, and the destructor gets rid of it, it's an RAII object. It's frequently true that the destructor is at the end of a block, but it could also be due to being owned by another object that deletes it on destruction, or it could be explicitly deleted itself. The Wikipedia article expressly notes (in the third paragraph) that RAII doesn't have to be scope-based. I'm not making this up myself. If I were to do something like "static shared_ptr foo; ... foo = make_shared(new DatabaseConnection);" I'd get an object that allocates on construction, deallocates on destruction, and has nothing to do with the stack.

So, where do you get this idea that an RAII object has to be on the stack? It's new to me, and I've done quite a bit of reading and seen all sorts of opinions.

Re:new and delete; viral disposability

[david_thornley]

Interesting post. First you claim that I'm wrong in saying that, in Java, some data types are stack-only and some are heap-only. Then you claim that object types are heap-only and primitive types are stack-only.

Basically, I'm trying to figure out what sort of reasoning got you to think that RAII objects are stack-based only. One common confusion for people who write Java and C# is that C++ has no concept of stack- and heap-based data types, and I was wondering if you were confused by that. Evidently, I was wrong, since you are correct on how those types work. You are wrong in thinking I don't know about storage classes, of course. (Also, we're not going to get anywhere with claims of C++ expertise. I assumed your expertise was on a par with the accuracy of your claims.)

Because I'm annoyed, I'm going to point out that function arguments can also be moved, not copied, in some cases, and that your use of "auto" is not only obsolete (in C++) but also highly idiosyncratic. The committee decided "auto" could be repurposed because approximately nobody ever used it as a keyword, based on a very large survey of source code.

And where did you get that thing about putting "static" on function arguments? "static" can be used on member variables and functions (meaning they're class-based and not tied to any object), non-class variables (giving them static storage duration), or it can be used to specify internal linkage. It's not something that goes on function arguments.

What do you think about beta.slashdot.org?

[slashdice]

Would it suck less if they used c++?

Re:What do you think about beta.slashdot.org?

[Anonymous Coward]

Slashdot beta is the F# of Microsoft. It is there but doesn't serve any real purpose. Another ill thought idea for the scrap heap.

C++ is an over bloated monster

[Jay Maynard]

I learned C++ the hard way: by hacking on a million-LOC program. It's taught me to loathe the language. It's big, complex, and incomprehensible. I once spent three days chasing a bug through a twisty little maze of templates, all different. I routinely struggle with the implications of static vs. not, member variables vs. globals vs. statics, functions that are part of a class vs. those that aren't... Getting code to even compile is often an exercise in trying something, running the build process, then trying something else, lather, rinse, repeat. It's left me frustrated enough to want to drive to College Station and scream at the walls.

All of this has left me wishing for the days of C, in which I'm quite fluent.

Nevertheless, the world seems (perhaps overly) enamored of C++, and I'm probably going to have to deal with it. How do I learn to at least tolerate it, if not like it, instead of actively hating it?

Re:C++ is an over bloated monster

[Anonymous Coward]

"How can I learn to tolerate your creation" is not a valid interview question unless you are interviewing Uwe Boll.

Re:C++ is an over bloated monster

[Marginal Coward]

Back in the old days, when there used to be book stores, I used to marvel at the girth of the C++ books on the shelf. After having programmed C++ for many years, did I really know all the stuff in one of those fat books? Probably not...

Re:C++ is an over bloated monster

[dentin]

Personally, I do a lot of the following:

- learn the minimum aspects of the language needed to navigate your specific codebase, and learn them very well
- copy/paste of terrible syntax to avoid compiler failures
- avoid using templates if at all possible
- create strongly typed specific-use classes that export only the minimum functionality of the underlying libstdc++ classes without using templates
- keep all pointer casting to well defined, central locations
- all production code runs with asserts on all the time
- thou shalt never use multiple inheritance. Ever.

Regarding managing inheritance and figuring out inheritance trees and which classes own what functions where, I'm still basically at a loss and I've been fighting that problem for years. The best advice I can give is try to keep your inheritance trees as shallow as possible; but for real world systems, it often doesn't make sense. I have a set of socket libraries which pretty much has to be 4-5 levels deep in spots to do what it needs to do properly, and it's disconcerting to have to look back to for example layers 1 and 3 to try to figure out what's going on.

Re:C++ is an over bloated monster

[angel'o'sphere]

Avoiding templates has two sides:
a) not crafting your own, where a misplaces bracket causes 2000 lines of a compiler error message or
b) using already existing templates

If you don't use templates of the STL or BOOST, sorry ... no way to get hired, that is braindead!

You rather write a C macro spanning 500 lines? Wow ... shake heads ...

Re:C++ is an over bloated monster

[david_thornley]

Realize that people can write crap code in any language. You probably wouldn't have appreciated a million-LOC program in crap C, except that C isn't as expressive as C++, so it might be a 2 million-LOC program.

If you have problems with member functions vs. independent functions, then you need to learn the fundamentals of the language. I pay absolutely no attention to people who complain about a language without learning some simple basics.

Re:C++ is an over bloated monster

[david_thornley]

For number 3, I'm going to suggest using templates freely, but never writing one. You're missing far too much of the power of the language if you throw away most of the standard library. The templates in the standard library are generally easy to use, but you don't want to write one like that unless you're an expert.

For number 5, I'm going to suggest sticking to C++ casts and avoiding C-type casts. Not only are they much easier to find, but they tell the reader what they do, and they are sufficiently annoying to write that people are less likely to abuse casting.

Multiple inheritance can be very useful, but requires some skill to use safely. For what you're doing, it's best not to use it.

Re:C++ is an over bloated monster

[Anonymous Coward]

If you have such a deep inheritance hierarchy, then you can blame it on the "thou shall never use multiple inheritance. Ever." and the "avoid templates if at all possible" motto you so religiously observe. You are trying to use your hammer to solve the screw problem, and complaining about the ugly result.

In your specific case, try to code with policies instead of trying to map everything in OOP-style code and your hierarchy could well end flattening itself into one or two levels.

BTW, I'm curious about how you would have coded your socket library in Java or C#... My guess is you would have exactly the same hierarchy.

Re:C++ is an over bloated monster

[Jay Maynard]

As I said, I learned about it by hacking on it. That's my point: you can't discover that kind of thing by hacking. With that said, got any suggestions about where I pick up what you think are the basics?

Re:C++ is an over bloated monster

[Jay Maynard]

Don't get me started on Boost. It's caused me more than a little headache all by itself...like, say, trying to build a specific version against a specific version of OS X.

Re:C++ is an over bloated monster

[Anonymous Coward]

"I routinely struggle with the implications of static vs. not, member variables vs. globals vs. statics, functions that are part of a class vs. those that aren't"

Then your issues are wrt OOP, not C++.

Re:C++ is an over bloated monster

[Jay Maynard]

It's not? Interviews aren't supposed to be full of nothing but softball questions.

Re:C++ is an over bloated monster

[david_thornley]

The problem with introductions to C++ are that they vary widely in their approach. Normally, I'd suggest something like Stroustrup's "Programming: Principles and Practice using C++", but if your main interest is that megacodebase, you may want an older one. You're not complaining about templates, after all, and this sounds like bad code using the C with Classes approach.

Are you familiar with C? Static variables really didn't change between C++ and C, and you may benefit from studying C. Kernighan & Ritchie is a great book if you're already a good programmer, and I seem to remember a book by King being recommended as a good introduction. I'd suspect that learning C and finding a decent old introduction to C++ might help a lot.

Re:C++ is an over bloated monster

[angel'o'sphere]

You have a blog about it?
As I just need to do stuff like this next months :)

Re: C++ is an over bloated monster

[Anonymous Coward]

and therein lies the problem with C++. all beginners start out by writing crappy code. I can almost guarantee that you did not start out with the vast knowledge you have today. everyone has a starting point unless your a rock star programmer, and those are few and far between.
that's how you learn and grow as a programmer, by making mistakes.

with c++ it almost forces beginners to write crap code because of how complex it is. they write code without understanding what it really does or why. and you can't blame them, they are just starting out, this is a language issue, not a programmer issue. I'm tired of people saying don't blame the language blame the programmer. in terms of c++ this is completely bogus. it is almost entirely the fault of the language until one has spent years learning it in and out and not just the parts they need.

Re:C++ is an over bloated monster

[Jay Maynard]

I'm fluent in C. I understand C statics fine. What gets me is their interaction with classes and instances and...

I'm not complaining about templates mainly because I'm keeping my fingers the hell out of them!

One of my favorite quotes

[Anonymous Coward]

"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone". Do you still feel this way, or are you more comfortable with modern smartphones than the phones that were available at the time of your statement?

Re:One of my favorite quotes

[Anonymous Coward]

They aren't smart enough to have a compiler!!

How do you feel about the haters?

[BenSchuarmer]

The comments and questions here look overwhelmingly negative. On the other hand, all of this passion only exists because people are using C++.

Re:How do you feel about the haters?

[DickBreath]

> . . . all of this passion only exists because people are using ${SOMETHING}.

I feel passionate about SCO (in a strongly negative way), but not because they are important, popular, or their products widely used. I feel passionate about Clojure (in a positive way) despite that it is not presently one of the top programming languages. How many people use something can be irrelevant to the legitimate reasons people feel passionately about it.

Re:How do you feel about the haters?

[Anonymous Coward]

In the C++ case, this is jealousy and bitterness.

You only have to search for reactions of the developers' (of any language) reaction at Herb Sutter's suggestion to take inspiration from Cairo's interface for a C++ standard 2D graphics library.

Everyone and their mother cried this was the end of the world. That C++ was stealing/corrupting Cairo. That this decision was dumb anyway because Cairo was already available in C so the C++ developers could already use it, etc. etc..

All the ridiculous outcry that purposely missed the point of Sutter's suggestion:

1. Cairo wasn't going to change. The C++ 2D graphic library would *never* affect non-C++ programmers, who would always be free to use whatever they want, including Cairo.
2. The C++ community would gain a new standard library extension (and a much needed one), following C++ design (RAII, exception safety, type safety, etc.).

So, why all the C++ haters out there were crying out loud?

Because a C++ standard 2D graphics library would make C++ more relevant.

And it bothered those who weren't interested in having C++ becoming more relevant, because it would make their own technology a bit less relevant, relatively speaking.

Imagine what would happen should this C++ 2D graphics library outperform the original both in efficiency and safety? Did everyone forget how std::sort outperforms the venerable qsort?

And when the competition is become as good as you in domain A, and you are not even close of become as good as them in domain B, then you have a problem. Jealousy and bitterness follows...

Re:How do you feel about the haters?

[Anonymous Coward]

I think you're quite mistaken. The "haters" are just right. C++ is a shitty language and has always been. Everybody who knows a little bit about programming languages knows that. It's not rocket science, you know.

BUT: Many C++ compilers create damn fast executables, only surpassed in execution speed on common PCs by C and Fortran. That's why the language is still in use.

Re:How do you feel about the haters?

[suy]

Well, he has given that answer several times. On his FAQ, he says:

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". Yes. Again, I very much doubt that the sentiment is original. Of course, all "there are only two" quotes have to be taken with a grain of salt.

Templates all over again

[Marginal Coward]

I'm a fan of C++ overall, but it seems to me that C++ templates are a bit of a disaster. They're so complex that I doubt that anybody but you and P. J. Plauger *fully* understands them. Also, when they're actually used, they often result in bloated, slow code - as I recently experienced when stepping through some STL string functions. Further, they bring on a lot of portability issues, evidently due to the difficulty that even the compiler folks have had in understanding and implementing them. Therefore, many programmers minimize their use of templates, both in their own code and in their use of templated library code.

Compared to the complexity of C++ templates, the C macro preprocessor provides a rudimentary form of templating via its very simple and powerful paradigm of text substitution. I've had some success implementing a limited form of generic (type independent) programming in C using just the C preprocessor. I've had much less success doing generic programming via C++ templates.

If you had templates to do all over again, what would you do differently? Was all the complexity of C++ templates (e.g. "partial specialization") really necessary to achieve its goals? Were the goals maybe too ambitious?

Re:Templates all over again

[Imagix]

Uh, have you seen the stuff that Andrei Alexandrescu does with templates?

Re:Templates all over again

[Anonymous Coward]

>Uh, have you seen the stuff that Andrei Alexandrescu does with templates?
Nothing anymore because he moved on to D ?

But yes, Andrei Alexandrescu knows his shit and he's clearly good. Too bad D has a more or less forced GC (without it you're pretty much freestanding, no library will work without).

Re:Templates all over again

[angel'o'sphere]

Same as everyone else does.
Waking up in the morning with a bright idea.
Having it hacked in till lunch.
Does not work for all corner cases for about 4 months.
Losing interest as I wake up in the morning with a new bright idea. Working on it for another 6 months.
Falling back to idea 1 and 'finishing' it ... getting excited about reviews in the 'C++ journal' and 'Dr. Jobbs' and Andrew Koenigs review in some odd other magazine. Getting mails why the thing still not works in odd corner cases. Asking for source code to confirm it and get some MVC++ sources (sigh) and some for Borland 2001s C++ compiler and an old Aztec or Symantec ... who knows, can't tell from the pragmas.
Now after I have spend 13 months to finish that f*****g template, I'm tired of telling people how much time it saves if you actually only use it:
typedef MyTemplate(yourstuff) tGenialStuff; // sorry, to lazy to place in proper spiky bracers, had enough of templates for now

Oh, actually I love templates, and hare Java generics ... just tried to show how hard the life of a template meta programmer actually is ;)

Re:Templates all over again

[angel'o'sphere]

Sigh ...
Idiocy all around ...
How can a template end up,in slow bloated code if it only is a template, hence the word, for something you would have to write EXACTLY the same way by hand?
So magically your hand written code would be less bloated, how so?, and less slow, how so?
Sorry, such claims are nonsense ... they absolutely make no sense.

Re:Templates all over again

[Anonymous Coward]

The C macro preprocessor is a great way to generate incorrect code; textual substitution is not a viable way to produce type-generic code.

The biggest problem with C++ templates is the insistence on compile-time resolution of template expressions. This means that, in order to actually use templates as a type-generic mechanism, we have to place them in header files, which increases compilation times. More importantly, the practice of instantiating large numbers of heavily-specialized compiled templates means that anything you write in a template is guaranteed not to fit in the instruction cache of any modern CPU.

Re:Templates all over again

[david_thornley]

First, there's a considerable skill difference between being able to use somebody else's templates and being able to write good templates. Second, the compilers and libraries I'm familiar with do a good job now. Third, your complaint with std::string isn't templates, it's with std::string. The most praise I've seen for it is that it's better than having to write and maintain your own string class.

Re:Templates all over again

[Marginal Coward]

So what if you used a set of powerful templates to create a complex layered system rather than writing a simple one by hand? For an example, compare the STL string class to C's string library. It's not about the use of templates, per se, it's about the design of the systemthat the use of templates may lead you to. In effect, the major benefit of templates - their ability to create large, reusable systems - is a major drawback if you're looking for something fast and small.

Re:Templates all over again

[Anonymous Coward]

The irony of defending the alleged complexity of one aspect of a computer language by being able to name all the people in the world who have actually got a decent grasp of it is quite telling ...

Re:Templates all over again

[Marginal Coward]

To be fair, my complaint about portability was due to a very bad experience I had over 10 years ago. Maybe it's gotten better since then. ;-)

Re:Templates all over again

[GiganticLyingMouth]

Sorry but this is nonsense. Templates aren't any slower than hand-written code. Compilers may have had problems with templates a decade ago, but template support among the major compilers nowadays are very solid and consistent.

You say "many programmers minimize their use of templates, both in their own code and in their use of templated library code" -- are you saying "many" programmers writing C++ don't use boost or the standard library? Because that too is nonsense. Many bad programmers perhaps?

Lastly, partial specialization is very convenient for performing compile time recursion, which is pretty essential to template metaprogramming.

Re:Templates all over again

[angel'o'sphere]

If you believe templates are slow and big in relation to fast and small you are mistaken.
Std::string is certainly in the same par as the C library equivalents.

Re:Templates all over again

[Marginal Coward]

Thanks. Please forgive my idocy. I think I got fooled the other day when I stepped through several std:string functions that were involved in passing a std:string parameter into a function. Then I replaced the parameter with a char *, and there was nothing to step through anymore. Apparently, though, all that std::string stuff would magically disappear in the release version. I forget whether the string parameter was passed by reference or not - somebody else wrote that part.

Re:Templates all over again

[Marginal Coward]

"I'm not bad. I'm just drawn that way." --Jessica Rabbit

Gee, Wally, if I use as many templates and template libraries as possible, do ya figure I can become a *good* programmer like you? ;-)

Re:Templates all over again

[Anonymous Coward]

Getting mails why the thing still not works in odd corner cases. Asking for source code to confirm it and get some MVC++ sources (sigh) and some for Borland 2001s C++ compiler and an old Aztec or Symantec ...

Are you telling us about something that happened almost 15 years ago?

Are you seriously implying that template's support is shaky, and justify that claim by using compilers that were two or three years old after C++98 went out?

Re:Templates all over again

[GiganticLyingMouth]

Not as many as possible. Use the right tool for the right job, as always. But don't rule out libraries because they use templates -- that's downright silly. Templates are made for writing generic code, which maps very well to libraries. Lastly, I don't claim to be a *good* programmer, but I do at least make an effort to understand the language that I'm using.

Re:Templates all over again

[Marginal Coward]

...but I do at least make an effort to understand the language that I'm using.

Unlike us "bad" programmers...

My basic point in the original point was that C++ templates are so complex as to be nearly impossible for most of us to *fully* understand. Don't you think that implies at least some sort of effort to understand them? In retrospect, though, my failure to fully understand them can only be attributed to my own abilities, not to the design of templates themselves. My bad...

Re:Templates all over again

[angel'o'sphere]

Hm, don't get what you mean right now.
I thought you talked about the std::string implementation itself. Which should be very performant.
If one of your coworkers passes a std::string by value, he likely does/did something wrong, and in that case you ofc. have to step through copy constructors and what ever they call ... if you really want to :)

Re:Templates all over again

[Marginal Coward]

Thanks for your comment. FWIW, here's what really happened. The function took a std:string as a parameter. The nominal use of it was to put in a char * literal which would get automatically converted to a string, so the parameter couldn't be passed by reference. While trying to step into the function, I stepped through the string constructor, which made several small function calls. When I replaced the parameter declaration with "char *", all that went away, and I was able to step directly into the function.

To be fair, the actual runtime overhead of the std:string constructor might be minimal, and could potentially be avoided by using a reference in many cases - though not this one. So, my concern about bloat when using template classes was anecdotal and might be overblown. As with any tool, you should use the right one for the job, and the string class does have some advantages, notably the ability to magically grow as needed. In this case, though, a char * would have worked just fine, so I contend that the original programmer didn't choose the right tool for this job.

I've used STL classes over the years, primarily vector and string, but I've had many experiences like this where something that C provided was a better fit for what I was trying to do. For example, a file name parameter probably doesn't need to magically grow, so a char * works just fine for that. That sort of experience, combined with having to repeatedly consult the documentation about STL functions because they aren't very intuitively named, has led me to prefer C constructs when I could potentially use either. That's what I meant in my original post when I said "many programmers minimize their use of templates".

Then again, I'm from the "less is more" school of programming. Some folks like to impress themselves and/or their friends by using as many fancy constructs as possible, in order to be judged a "*good* programmer" - as another commenter in this thread evidently does.

Though my original post was perhaps a bit overstated (for your entertainment), I actually do use the STL, but only at a very basic level, and only where it explicitly solves a problem. I think I would be a lot warmer to it if C++ templates and the STL itself were better designed. For example, I much prefer Python's string functions and MFC's "CString" class to std:string.

But even if templates and the STL were better, good-old-fashioned C still can meet most such needs very nicely. And as Tim Peters said, "Beautiful is better than ugly." (BTW, I wonder if Dr. Stroustroup thinks his template baby is beautiful? - maybe he'll tell us. ;-)

Re:Templates all over again

[GiganticLyingMouth]

Don't you think that implies at least some sort of effort to understand them?

Well apparently not, because you stated multiple points that are, as of today, patently false. Perhaps it was different in C++98, but (in case you didn't know), it's not 1998 anymore.

Re:Templates all over again

[angel'o'sphere]

Well, point is: all that has not much to do with the fact that std::string is a template :). The same would happen with any 'ordinary' class where assignment operators or constructors lead to type conversions.

Well, my only hint to make stuff less ugly is to use _always_ a typedef. So even a list of simple std::strings can be a tEmailList or a worst case tLines (lines of a file).

If your classes and functions are not cluttered with nested template types but the argument types are simple typedefs it is much easier to read and much easier to use either a pointer or a reference here and there, and also throwing in the occasional const, if appropriated.

If you have coding guidelines, that would be the first thing I would add/change.

If

[Anonymous Coward]

if (condition) statement;

or

if (condition)
    statement;

or

if (condition) {
    statement;
}

Re:If

[Anonymous Coward]

if (condition)
  {
    statement;
  }

Re:If

[Anonymous Coward]

if (condition) goto forward
statement;
forward:

Re:If

[Anonymous Coward]

Shouldn't there be !condition?

Defining subsets of C++

[tepples]

Lastly, C++ has been extremely complex. When is C++ going to simplify the total over-engineering of the language?

The same way you simplify any other multi-paradigm language: Learn a subset and use it. PNG, SVG, and the like have "profiles", where an implementation can choose to leave particular sets of features unimplemented and declare this in its profile. Now my own question for Bjarne: Do you plan to implement anything like these profiles in C++ to make well-defined subsets easier to learn?

Re:Defining subsets of C++

[UnknownSoldier]

We _already_ went through the "mistake" of Embedded C++ in the 90's -- a subset of C++ with no RTTI and Exceptions turned off.

We don't need sub-sets of languages. We _already_ have those when programmers don't use all the complicated and over-engineered parts of C++.

Re:Defining subsets of C++

[DickBreath]

> We don't need sub-sets of languages. We _already_ have those when programmers don't use all the complicated and over-engineered parts of C++.

We don't need sub-sets of languages. We already have them when compilers don't fully implement the entire language. (Rewind to mind 1990's.)

Re:Defining subsets of C++

[dentin]

No. No no no no no. No.

Just, no.

Having lived through the embedded C/C++ debacle, I can't stress 'no' hard enough.

Re:Defining subsets of C++

[dentin]

Even when they do fully implement the entire language, the 'compiler dependent' aspects of the language allow compilers to produce arbitrary results.

Re:Defining subsets of C++

[Anonymous Coward]

This is why programmers need to read the specification. Grabbing some code online and changing it to suit your needs is a great way to screw yourself over.

Re:Defining subsets of C++

[DickBreath]

While I personally like to deeply understand the languages I program in, I don't think it should be necessary for an average programmer to have to understand the entire language specification in order to use the language.

If you can't just grab some code online and expect it to work on your compiler, then this is a major design fail in the language.

I can understand a language having unspecified aspects, poorly specified aspects, or things that are well specified to act in a compiler defined manner. However those should be extremely obscure features that an average programmer, and average code would never use.

Even better, don't have any compiler dependent behavior in a language. Compiler extensions should be okay -- and they, by design, should cause a compile time error on a different compiler -- or alternately have a way of being ignored so you can stack compiler specific blocks together in a single source file. Although having a source file that only supports a specific list of compilers also seems like a bad idea.

I'm glad it is not an issue in the languages I use.

Re:Defining subsets of C++

[UnknownSoldier]

This 100x times.

I'm so tired of my C++ programs breaking from one version of the compiler to another or from compiler flags. /glares at gcc and clang ...

Will there ever be a breaking change ?

[Anonymous Coward]

With C++ standardization picking up steam, and C++'s backward compatibility being a feature, I'm wondering, will there ever be a non backward compatible version of C++ ?
Not as in purposefully making all those millions of lines of code written in the past decades not compile, but using all the hindsight to fix those choice that turned out to be not so good in practice and allowing a "cleaner" language to come out of what looks more and more like a mess of accepted proposals.

I see lots of people complaining about C++ being "Too big". I personally don't mind, nothing is stopping me from using that simpler and maybe more modern subset of the language I want, but aren't you worried that all those old features might hold C++ back and slow down standardization and "innovation" in the future ?

C++ is the most powerful tool I've had the chance to use, and I'm glad to see it being actively improved again, but I'm not sure how long it can keep being at the same time all the languages it used to be and wants to become.

Re:Will there ever be a breaking change ?

[Anonymous Coward]

I think you need to list some specific features that you would change in order for this to be modded-up. Without that, it sounds like "Will you ever fix all those things that you did wrong?" which sounds more like a veiled insult. Perhaps something more like "If you had templates to do over again, would you make any syntax changes to make it more approachable?"

Re:Will there ever be a breaking change ?

[david_thornley]

The new use of "auto" in C++11 would have been a breaking change if anybody had ever used that keyword since the dawn of C. The "export" facility was removed from C++11, and that actually was implemented in one compiler (Comeau). I think you'd be better off listing specific features, misfeatures, warts, and abominations and asking about them.

Given that

[maroberts]

C++ is more or less a superset of C (give or take a few minor issues), why has regular C continued to thrive?

Re:Given that

[Marginal Coward]

Having used both extensively, I can tell you that it is much more difficult to write slow, bloated, overly complex code in C than in C++. It keeps you honest in that way. Also, most of the good things of C++ such as object-oriented programming and templating can be done at a basic level in C. For example, in C++, a class function is just an ordinary function with a hidden pointer to a (class) structure. Why not just pass in a pointer to a class structure in C? And class member privacy can easily be a matter of naming convention rather than something the compiler enforces.

C++ has its value, and may be better suited for building large, complex, systems such as GUI frameworks, but C is a great choice for cases where speed and minimal size are paramount, such as most embedded code as well as the Linux kernel. In principle, it's possible to write fast, small code in C++ by using its features selectively. However, if you do that, you're left with mostly just the features you could have emulated in C anyway.

Oh, and did I mention that in its current form C is the "perfect" programming language? Other languages have their own goals, but judged in terms of its own goals, C does what it's trying to do better than just about any other language - far better than C++ meets its goals. There's a reason that changes to C over its many years have been very minimal, and virtually always for the better.

Re:Given that

[Anonymous Coward]

>For example, in C++, a class function is just an ordinary function with a hidden pointer to a (class) structure. Why not just pass in a pointer to a class structure in C?

GNOME does this. It's great for everything except writing concise, readable C code. They have a language on top of this called Vala, which uses GNOME's type system (and in fact compiles to C) but without having to write complex object and type initialization code. But AFAIK not a lot of people use it.

Re:Given that

[maroberts]

It's been ages since I read Stroustrup or Kernighan & Ritchie, as I have largely moved on from embedded/Unix programming into Web based systems but I seem to recall one of the arguments for using C++ was that it could always do things as efficiently as C and possibly more so.

Re:Given that

[Marginal Coward]

Likely true, but the benefit of C that I'm highlighting is that it gives you very little rope to hang yourself with in terms of creating a system composed of layer-upon-layer of classes. In contrast, I once worked with someone who loved to create class-upon-inherited-class for the simplest things in C++. Everyone who looked at his code wondered "where's the beef?", that is, the part that did something useful. The code worked, so the useful part must have been in there somewhere. But it sure wasn't easy to locate. I think he had tiny bits of useful stuff cleverly hidden in most of his classes. As best I could tell, though, some did nothing at all.

Basically, I regard C's inability to create a large complex hierarchy of objects, together with its ability to support objects in a basic way via pointers to structures, as a primary selling point that explains its persistence in a world where a "better" superset has long been available. That's not to say that the C++ approach of layering inherited classes is bad or wrong, just that its lack in C can prevent a certain category of problems.

Re:Given that

[Anonymous Coward]

Bercause C adopted a lot of what made C++ a superset.

Re:Given that

[Anonymous Coward]

Less is more.

C++ allows makes it very easy for projects to end up in abstraction hell where the main function essentially is a one-liner and the rest is layer upon layer of abstractions that just re-defines the language.
Programming C++ requires a LOT of discipline from everyone involved to not end up in unreadable mess.
For a very long time C++ was considered to be unsuitable for safety critical application. MISRA C++ haven't been around for more than 5 years or so.

compilers touted as early form of A.I.

[peter303]

Compiliers allowed you to move from brutal machine-language numbers to language-like or math-like statements; from number to problem-domain concepts. Compilers were complex pattern recognition, rule-base translators that implemented this. I've seen some early ads touting COBOL as programming in "almost English" (har har). As with most soft-A.I. results, once you did it, it wasnt really considered A.I. anymore.

Re:compilers touted as early form of A.I.

[Katatsumuri]

Agreed, I was also considering this when I was asking this question. Perhaps I should have elaborated further.

The advances in software engineering tools so far made programming more efficient and more accessible, so more people can do it now, and some people can achieve much more in small teams. But still, it is a skill that qualifies as a profession, and people who do it part-time also need a lot of learning.

The point of my question is, will it get to a degree when instructing the computers even for custom, unique tasks will no longer be a complex skill? Will we see a decline in the number of people specifically hired as programmers?

I understand we will not literally hire some Bender-like robot, or maybe even get any actual code. More likely, it's just that the generic software will become more interactive and functional. But still, it will displace some human labor. That's what I'm talking about, and I'm curious about other people's opinion when that turning point may come in this industry.

Re:compilers touted as early form of A.I.

[Boronx]

Right. Before they wrote compilers, the concept was considered possibly a hard AI problem. Now they have you write a compiler as an undergrad.

Re:compilers touted as early form of A.I.

[Jeremi]

Right. Before they wrote compilers, the concept was considered possibly a hard AI problem. Now they have you write a compiler as an undergrad.

To be fair, it's a lot easier to write a compiler (or any other program) if you have an existing compiler on hand to help you do it. Writing a compiler using only assembly or machine code is well beyond most undergrads' capacity.

Re:compilers touted as early form of A.I.

[Boronx]

Only in the sense that it would take too long and they aren't required to know assembly.

Which feature would you add to C++?

[jonwil]

If you could add one feature to C++ (either the language or the standard library) and have it adopted in the C++ standard and supported by all the compilers etc, what would it be and why?

Re:Which feature would you add to C++?

[dentin]

It would be better if you asked along the lines of "If you could change any aspect of C++ and have it immediately adopted/supported" - you never know, his preference might be to change template syntax or something similar instead of adding something new.

Re:Which feature would you add to C++?

[Anonymous Coward]

Arbitrary Precision Integers, and that would give Intel a boost...

Auto & Concepts to replace Templates ?

[Anonymous Coward]

Couldn't auto & concepts replace templates in those simple use cases where you don't want compile time Turing completeness, but just a simple generic function working on anything with an operator+ or maybe with an argument matching the concept of a container.

I want auto as a type for function arguments. Wouldn't that be simpler, easier to read, beautiful ?

Why is C++ such an utter pile of shit?

[Anonymous Coward]

Seriously.

Re:Why is C++ such an utter pile of shit?

[DickBreath]

There are optimizations you can use to improve your experience with C and C++.

Just insert these into your header files for both time and space improvements in your compiled code.

#define struct union; // uses less memory
#define while if; // makes code run faster

Now how can you say bad things about a language that is so easily improved?

Re:Why is C++ such an utter pile of shit?

[Anonymous Coward]

http://stackoverflow.com/questions/21579974/define-struct-union-and-define-else-still-compiles-any-c-program

Such bad advice I assume you're joking/trolling.

Absolutely NO to using that.

Re:Why is C++ such an utter pile of shit?

[angel'o'sphere]

Besides the erroneous semicolons this is actually pretty funny :)

Re:Why is C++ such an utter pile of shit?

[DickBreath]

Yes, I should have put a smiley. And as another poster points out, I should not have put the semicolons. But It's been awhile since I used C / C++.

Re:Why is C++ such an utter pile of shit?

[Anonymous Coward]

love it.

the defines should remove the semi-colons though

C++ without the C

[kthreadd]

Apple recently introduced a language they call Swift or Objective-C without the C. It is technically a completely different language from Objective-C though. When C++ started out it had the major benefit that it was (mostly) compatible with C which at the time was immensely popular, making it trivial to mix new C++ code with existing C code. Today C is still a popular language but not as widely used as it once was. Assuming that C++ could drop C compatibility, how would you take that opportunity to improve C++?

Re:C++ without the C

[Anonymous Coward]

Isn't Swift that ridiculously slow language that managed to end up *SLOWER THAN PYTHON* on benchmarks even though it used LLVM ?
Or maybe you're talking about the *other* Swift language, since Apple apparently picked a name that was already taken.

Re:C++ without the C

[Anonymous Coward]

We already have that language. It's called D. And the popularity of D compared to C++ is probably telling. C++ has all those ugly warts because it's used so widely, in too many different application areas. D isn't that compatible to everything that has a C API.

Re:C++ without the C

[Anonymous Coward]

The question is, would Bjarne Stroustrup make D?

Legacy

[Anonymous Coward]

A lot of C++ complexity comes from trying to maintain compatibility with legacy code. Many of the new features could have been implemented more cleanly if the legacy support was dropped.

What part of C/C++ legacy has been the most troublesome to overcome?

Seriously

[Anonymous Coward]

How bad does it hurt when kicked in the Bjarne's?

EST? or EDT?!?

[GNious]

The linked G+ post says "August 20th, 2014 at 12:30pm EST to 2:30pm EST", but August 20th, 2014 is during Summer Time/Daylight Saving Time ...

So, is is 12:30pm EST, or 12:30pm EDT ??

Re:EST? or EDT?!?

[Anonymous Coward]

There's a good chance they mean EST. But I suspect that Google Plusers are living one hour in the past. I mean, you got to in order to use Google Plus, right?

Re:EST? or EDT?!?

[Anonymous Coward]

Sorry, typo. I meant EDT. There's a good chance they meant EDT and typed EST as force of habit. Kind of like what I just did.

Complexity

[dentin]

"Are there any plans for future c++ specifications to focus on readability and debugging at the source level, as opposed to adding new features?"

As everyone well knows, maintenance and debugging are by far the most time intensive aspects of software engineering. Over the years, I and many of the others I work with have evolved various 'personal standards' in our use of C and C++; these personal standards are almost entirely to aid in debugging and readability. A few examples from the C side:

- pretend that the return type of the = operator is void, disallowing both "a=b=c" and "if (a = b)" constructs
- all 'if', 'while', 'for' etc statements must be braced
- certain types of simple arithmetic operations, for example a signed 16 bit integer multiplied by an unsigned 16 bit integer, may only be handled by dedicated macros to ensure proper operation. These macros must be manually tested and verified on each platform the software is ported to.

Many of these things seem trivial, but they add up. I have seen many hours lost to unbraced 'if' statements; I have seen five different compilers require five different sets of casts to ensure that a 16x16->32 bit integer multiply produces the correct results. There are many holes in the language specification which allow compilers to silently generate arbitrary code, requiring extensive debug and testing time when porting to new platforms.

Both porting and maintenance would be eased by truly looking at the lower layers and making some difficult decisions to improve parsing and deprecate dangerous or confusing constructs. Are there plans in future specifications to do this?

Re:Complexity

[cerberusti]

I have the same habits. One of the first things I do on a new compiler is go find the warning for assignments within conditions and turn it on. It produces errors which can be hard to find, and do not always come up in testing (since it effectively makes it always take one code path, and sometimes this is the far more common case anyway.)

I think pretty much every C compiler has that option, some issued a warning by default.

I like my braces to line up vertically as well, so the brace gets its own line indented a space from the prior line. I sometimes go without braces if it is going to be a long block of conditions I want on single lines and I cannot use a switch, but this is very rare.

I tend to make casts explicit and group everything myself, but do it inline (most of the time the type is the same anyway.)

assuming int is 16 bit and long is 32:
int a;
unsigned int b;
long int c;
c=((long int)a) * ((long int)b);

Or do you have a compiler which does not give the expected results there?

Re:Complexity

[Bent Spoke]

"unbraced ifs" is a classic example of blaming the symptom instead of the disease. The actual problem is misleading indentation. The actual solution (particularly in a multi-developer project) is to use a code formatter.

Adding library support for graphics (Cairo)?

[snake_case_hoschi]

Hello! I december 2013[1] Herb Sutter has written about adding a graphics library to C++. As far as I know Cairo is a well written und usable library and in fact my complete desktop is using it (GNOME/GTK+ on GNU/Linux). But I shy away from the idea to see a graphics library within the standard, because drawing graphics is not part of the base requirements like Input/Output, String-Handling or Containers. What do you think about that? Is Cairo, as an low-level graphics library, also agnostic enough for the long-term future of C++? In my eyes Java only suffered from the integration of AWT/Swing as toolkit into the JRE. But AWT/Swing is a high-level toolkit and merely based on the paradigma of "runs anywhere". Thank you [1] http://lists.cairographics.org...

Re:Adding library support for graphics (Cairo)?

[angel'o'sphere]

AWT and Swing are two different beasts.
If 'in your eyes' Java suffered from having Swing, I suggest an Eye doctor. Or is it the pain from your teeth forcing you to keep your eyes shot? Then perhaps a dentist is more appropriated. (* facepalm *)

Personal programming projects

[kthreadd]

Apart from work, do you have any personal programming projects going on? Which type of programming do you like most and is there a particular project that you would like to implement?

More features

[Anonymous Coward]

What features do you think are missing that would make the language utterly incomprehensible, as opposed to almost completely incomprehensible, such as it is already?

Fizz Buzz

[kthreadd]

In C++ how would you write the most elegant solution that prints numbers from 1 to 100, replacing any number divisible by three with the word "fizz", and any number divisible by five with the word "buzz"?

Re:Fizz Buzz

[twistedcubic]

How do you replace numbers divisible by both?

Re:Fizz Buzz

[Anonymous Coward]

for(int i = 0; i 100; ++i) // Perhaps not elegant (is C++ ever elegant?), but it's succinct.
        std::cout << (i%3==0? "fizz" : (i%5==0? "buzz" : std::to_string(i))) << std::endl;

Re:Fizz Buzz

[Anonymous Coward]

//Come on, that's easy.
#include
for( int i = 1; i <= 100; i++ ) {
    if( (i/3)*3 == i ) printf("fizz\n");
    else if( (i/5)*5 == i ) printf("buzz\n");
    else printf("%3d\n", i);
} //I'm sure there's some boost templaty way to do this in 2 pages of code, but I'd rather keep it simple...

Re:Fizz Buzz

[Katatsumuri]

With the word "fizzbuzz".

Re:Fizz Buzz

[Anonymous Coward]

Oh please. It's been done -- at compile time:

http://rosettacode.org/wiki/FizzBuzz#C.2B.2B

What features if any would you remove?

[anarcobra]

Is there any syntax in C++ that you would want to change, or remove, if you didn't have to worry about compatibility with previous version?

Worst C++ development threat?

[qrwe]

According to you, what is the worst thing that could happen to the C++ development, i.e. what nightmare would you never like to see happen to an upcoming standard?

What would a do-over look like?

[Anonymous Coward]

C was/is a unique language.
    It brought us portability and performance in a language suitable from low level system stuff to apps.

C++ manages to keep these traits and add objects, an impressive feat.
    This may even be a unique feat.
      Given it's compatibility with C, C++ may be the only game in town for systems programming in objects?
    But this does not come without loosing a great deal of the simplicity of C.
    I think the situation is that C++ is a bit like gasoline. It's powerful and can be used for good or bad.
    With C++, it seems to require quite a bit of discipline to stay in the good camp.

For C, I think it is possible for many folks to be familiar with most of the features in the language.
    For C++ I continue to find new stuff. Some neat, some only things only a mother could love.

Having seen how the transition from C to C++ proceeded,
      given the chance to drive it again, what would you do differently?

Is C++ really the only game in town for doing large, high performance systems programming in objects?

Re:What would a do-over look like?

[david_thornley]

You could use Common Lisp for large, high performance systems with objects. It will be harder to find developers, and it doesn't interface with the rest of the system nearly as well as C and C++, but aside from that it would work well.

Objective-C is simply an object-oriented system added on to C, so if it's suitable for writing in C it'd be suitable for writing in Objective-C.

Seriously

[Anonymous Coward]

How bad does it hurt when kicked in the Bjarne's?

   

Quite a kick in the Bjarnes

[Anonymous Coward]

#include
#include
#include

class Cpu {

    public:

        virtual int dummy( int, int ) {}

    private:

        virtual int add_( int a, int b ) { return a + b; } /* A */

        virtual int sub_( int a, int b ) { return a - b; } /* B */

        virtual int mul_( int a, int b ) { return a * b; } /* C */

        virtual int div_( int a, int b ) { return a / b; } /* D */

        virtual int mod_( int a, int b ) { return a % b; } /* E */

        virtual int and_( int a, int b ) { return a & b; } /* F */

        virtual int or_( int a, int b ) { return a | b; } /* G */

        virtual int xor_( int a, int b ) { return a ^ b; } /* H */
};

int main( int argc, char* argv[] ) {

        typedef int (Cpu::*Memfun)( int, int );

        union {

                Memfun fn;

                unsigned char ptr[6];

        } u;

        Cpu cpu;

        u.fn = &Cpu::dummy;

        assert( argc == 4 );

        int p1 = atoi( argv[ 1 ] );

        int p2 = atoi( argv[ 3 ] );

        char op = argv[2][0];

        assert( op >= 'A' && op = 'H' );

        u.ptr[0] = 1 + 4 * ( op - 'A' + 1 ); // Don't look here!

        std::cout "The answer is " ( (cpu.*(u.fn))( p1, p2 ) ) std::endl;
}

Re:Quite a kick in the Bjarnes

[Anonymous Coward]

Have you tried compiling that on a 64-bit CPU?

GC won't always call destructors

[tepples]

A GC works on pointers/references, and works seamlessly together with RIAA, constructors/destructors.

Assuming you meant RAII and not the record industry, popular GC environments don't even guarantee that an object's destructor or finalizer will ever get called. So in a fully GC environment, without using the dispose pattern, how can you ensure that the non-memory resource that an object owns will get released?

Re:GC won't always call destructors

[angel'o'sphere]

When I combine a RAII and a GC I ofc, program the GC in calling the destructor AND the finalizer, a no brainer. Or likely I let the finalizer decides if it needs to call the destructor (because it might already have been called).

If you are interested in this, look how .Net managed C++ does it, they have GC, RAII and destructors as well as finalizers.

Re:GC won't always call destructors

[Anonymous Coward]

OK, so you have to call the destructors and finalizer instead of explicitly freeing.
So in essence the garbage collector doesn't work and you still have to keep track of your resources and free them accordingly. Great, you get all the bad things from both paradigms.

The great benefit you get from garbage collection is that the actual freeing of the memory can be postponed to when the program execution ends with the added penalty of needing about three times more memory to not get random performance penalties when garbage collection has to step in at inconvenient times.
The thing is that memory GC shouldn't even be implemented in the programming language. The operating system can just add the freed memory to a list and join the blocks together when it needs to or when system load is low. The OS knows more about this than the application.

Trying to manage resources on your own instead of leaving it to the OS is a bug, not a feature.

Other languages?

[Anonymous Coward]

How do you feel about Rust, Go and D?

Find Replace Templating....

[Anonymous Coward]

I always thought the whole template logic was more complex than it had to be.

I seem to always want a simple way to enumerate what fields are on some class at compile time..... Without a PhD level template mess of meta-programming and unreadable code.

It's simply amazing to me that this more basic use case was never really formalized. I'm not asking for runtime reflection or even full reflection at compile time.

I also wish there was a more basic "find-replace" type of template. Where I can have it change strings and such inside quotes for static compile-time messages. (For instance for error messages about parsing where I want the field name in the error). Currently I have to make a class or pair to store the "name" of the variable which then complicates all uses of that variable. Usually my desire is again to just write a compile-time template that automatically builds a parser/serializer by looking at a class.

Rarely am I going beyond those use cases when I decide to template something. It's almost always for a parser, protocol layer, or a "framework" that I wish to simply change a few variables around and reuse my code.

Otherwise I feel C++11 was a step in the right direction and with standard thread support, my clients are not nearly as frightened by it. However the linux folks with glibc decided to "partially" implement std::regex such that it kinda-works but breaks if I try a non-capture group or an optional character class. That led me to totally distrust C++11 Regex since I cannot detect whether it's partial or not until the regexes fail to compile at runtime.

How would you plan to fix those issues when it comes to people poorly implementing the standard library extension to C++11 without the language itself having a way to check the "compliance level"?

I'd like a way to #IFDEF around some variable that tells me if I have full std::regex support, partial(crappy) support, or none at all so I can fallback to . That's currently a pain point of mine which I understand is the toolchain's upstream issue and not yours. (But they will derail you if you let them, so let's find a way to check compliance in the future)

Re:Find Replace Templating....

[david_thornley]

Thing is, if glibc has crappy regex support, do you think a compile-time indication would warn of this? I think you might be better looking for a preprocessor symbol that would mean you're using glibc.

And comment that sucker. That way, if the glibc people ever do get their regex act together, your successors will know why you did what you did.

What has led to the recent improvements in pace?

[Anonymous Coward]

Hi Mr. Stroustrup,

I love C++ and really liked what C++11 brought. I now see that there is C++14, then 17. What has led to this sudden change in pace at which the language standard is being updated?

Also, what are your thoughts on moving the standard library towards something pythoneseque where the language comes 'batteris included'. This is really the one thing that sometimes keeps me from thinking of using C++ sometimes.

Again, many thanks for bringing C++ forward.

new operator

[Anonymous Coward]

It is exceedingly difficult to track freestore usage with the new operator. You cannot easily or generally associate counters with it with macros or functions.

love/hate relationships with templates

[godrik]

Dear Prof. Stroustrup,

Writing templated C++ code has become one of my favorite way to write abstract algorithms in an efficient (runtime wise) way mostly because it not alone allows to know types at compile time, but also some values. Yet programming templates is nightmare because the template system is compile-time duck-typed. How can that system be made better? Concepts were proposed for integration in the C++ norm but got pulled back. Yet it seems they are essentially what is required. Will template programming ever improve?

Best,

Will C++ Continue to be verbose?

[Prien715]

My main criticism of C++ is that it's overly verbose. There are many issues resulting from it (difficult to write, overuse of old school pointers, etc). Let's take the simple for loop (I'm using { in place of "less than" since /. code is retarded):

// C
int myVec[100];
for (int i=0; i { 100; i++) myVec[i]=i;

//Now, let's look at C++ (not 11):
std::vector{int} myVec(100);
for (std::vector{ int }::const_iterator i=myVec.begin(); i != myVec.end(); i++)
{ myVec[i]=i; } // When did you decide this ^^ was a good idea and how drunk were you?

With C++11, it's slightly better:
for (auto i=myVec.begin(); i != myVec.end(); i++) myVec[i]=i;
 
...but it's amazing that C style (1970's) syntax is both the more concise and readable -- but still loses to C:
for (int i=0; i { myVec.size(); i++) myVec[i]=i;

Aside from the addition of auto, do you ever plan on admitting and addressing the language's problems with verbosity -- which hurts readability, learning curve, etc. -- or just keep introducing increasingly arcane features?

Re:Will C++ Continue to be verbose?

[serviscope_minor]

Well, no. The C++ and C code are not equivalent.

Your C code is fixed size, your C++ code is not. In C++, you would do:

for(size_t i=0; i > vec.size(); i++)
        vec[i]=i;

which is marginally longer and more flexible. If it's fixed size, then the code is the same as for C.

If you want to do other things, there's always the range based for:

for(const auto& i: vec)

which is shorter than the C code and safer and more flexible.

Re:Will C++ Continue to be verbose?

[Anonymous Coward]

std::iota(std::begin(myVec), std::end(myVec), 0);
I actually find this way simpler to understand than "C" version and achieve your demends. I think most of the problem people have with C++ "verbosity" comes from not knowing the standard library well enough. People keep re implementing standard algorithms over and over again when they should just use what is provided.

Re:Will C++ Continue to be verbose?

[Anonymous Coward]

No you missed the C++11 for-each syntax.

for (int i : myVec) {

}

Re:Will C++ Continue to be verbose?

[Anonymous Coward]

std::iota (myVec.begin (), myVec.end (), 0);

:D

Re:Will C++ Continue to be verbose?

[fnj]

Look, if you want a language that is elegant and simple yet powerful and complete - but slow - IMHO, use Python.

However, in your C++11 example it would help if you actually leveraged C++11:

    vector<int> myVec(100);
    iota(myVec.begin(), myVec.end(), 0);

Here is an actual complete program:

    #include <iostream>
    #include <numeric>
    #include <vector>

    int main()
    {
        std::vector<int> myVec(100);
        std::iota(myVec.begin(), myVec.end(), 0);
        for (auto x : myVec) {
            std::cout << x << '\n';
        }
    }

even in your own C++11 example, the sensible way to use auto would have been:

    for (auto x : myVec) myVec[i]=i;

A lot less of that cursed verbosity, no? So in fact, in your picked example, C is not more concise and readable, after all.

Re:Will C++ Continue to be verbose?

[fnj]

Sorry; brain leaped to alternate reality in that last line. It's gonna have to be a BIT more work, but not much:

    int i { 0 };
    for (auto x : myVec) x = i++;

Re:Will C++ Continue to be verbose?

[Prien715]

...but funny thing, here's what your program prints:
0 0 0 0 0 0...etc.

It should read for (auto& x : myVec) x = i++;

The C example I typed without even thinking -- I'm guessing you could too. You've revised the C++ example once already, which happened to be wrong. I spotted your error immediately -- but then again, I have years of experience.

Re:Will C++ Continue to be verbose?

[fnj]

You're right of course. You can use either auto& or int&. But you'd better be sharp :-) It's the only one I didn't test (until now).

But don't you agree that using iota to dispose of the init loop entirely is the best choice?

Re:Will C++ Continue to be verbose?

[slashdice]

close, but no cigar.

std::iota(std::begin(myVec), std::end(myVec), 0);

That works if myVec is a std::array or a int[100]. And many compilers will generate vector code for it (much faster!) whereas it's less likely with the manual loop.

Re:Will C++ Continue to be verbose?

[Prien715]

I don't think so. The simple "for" loop with auto is easily understood by someone with a passing familiarity with any programming language.

I've been programming (mainly in C++, mainly scientific applications) for ~10 years and I had to look up std::iota -- it's a neat construct but it's really obscure and the question is, does it make code more readable? My answer would be no. For the same character count, it's a wash.

That's my main issue with language philosophy really. They're expanding the language quite a bit while some constructs have negligible value -- and entirely avoiding constructs that fit 99% of use cases. Would it have really killed them to not force one to use iterators, for example? Who doesn't sort a whole list (std::sort(myVec) ought to work...we can both agree what that ought to do right? The language tools to do it are there. Is there any other language that is that uselessly pedantic?)?

Re:Will C++ Continue to be verbose?

[Anonymous Coward]

Your examples are misguiding.

//this works in any C++
for (size_t i = 0; i < vec.size(); i++) vec[i] = i;

Other thing to look at is a new for cycle
//C++11
for (int& val : vec) val = rand();

and that is finally shorter and more readable than your C equivalent (provided you don't need index which in most cases you don't)

There are other additions to C++11 which address verbosity like initializer lists. I suggest you to update your C++ knowledge before you start posting misguiding code samples

Re:Will C++ Continue to be verbose?

[fnj]

Thank you. It is a very tenable objection. I am not fully persuaded, but it is food for thought.

My counterpoint is that iota, used in the context of std::iota rather than the evil "using std" at the top, is something that is easily looked up. OTOH, I wouldn't suggest C++ programmers could be expected to know about iota and a million other standard library resources.

The problem with having a std::sort(std::vector) template is that then you need one for all other applicable containers, and if a new container is written, then you have to write a new std::sort template as well. I think that is the reason it is expressed using iterators, which is really very powerful. The template approach is something you have to buy into whole-heartedly.

I've programmed C for a little over 30 years and C++ off and on since a little over 20 years ago. While the basics of C are long completely ingrained, doing it right does still take a little concentration - like using snprintf instead of sprintf - C does have its own useless backward-compatibility cruft nobody should ever use any more. C++ is a whole different story. Doing anything at all properly with it requires enormous concentration and constant reference. There are a very few masters of C++ who make it seem like it is easy for them - but not for me :-)

I was really serious when I recommended python.

Re:Will C++ Continue to be verbose?

[Prien715]

I still program in C++ but I have to use Qt as an SDK initially for UI and now just because it makes the language much more concise. Whether it's qSort(anySTLcontainer), QString (which supports unicode, regex, etc), or foreach(int& item, myVector) being legal -- and this is all pre C++11 and still works today (in addition to being just as portable). Having a perl-like circular list which supports O(1) prepends, appends, etc. is really nice too. And don't even get me started on why boost::signals are inferior and lead almost inevitably to instability;) Like any other language however, it's only as good as the people who use it so it's no guarantee of readable code.

I really do need to check out Python some more. I'm fluent in Perl and it's served me well over the years, but I've heard nothing but good about Python.

Re:Will C++ Continue to be verbose?

[Anonymous Coward]

array{int, 100} myArr;
iota(myArr.begin(), myArr.end(), 0);

And the .begin() is from Stepanov, not Stroustrup.

Re:Will C++ Continue to be verbose?

[Anonymous Coward]

int i = 0;
for (auto &value : myVec) value = i++;

How is this worst than "C" version ?

Douche

[Curunir_wolf]

In addition to being the creator of C++, Bjarne Stroustrup is a Managing Director in the technology division of Morgan Stanley

So first he screwed us with that god-awful bastardization of C, then screwed us again with convoluted derivatives that no one could figure out were worthless, ushering in the worst global economic recession since World War II.

Pitchforks and torches are too good for this guy, I say. String him up on the yard arm.

Re:Douche

[Anonymous Coward]

He doesn't create models for the derivatives products group. Vlad does.

Re:Douche

[MouseTheLuckyDog]

Much of the theory and practical applications was worked out a long time ago. Mistly by physicists out of jobs when the SSC was canceled. Just another reason to keep funding the sciences.

programming languages

[Anonymous Coward]

What modern programming language that is not C++ you recommend to learn as first?

Concepts (Lite?)

[serviscope_minor]

Concepts in some form or another have been one of the major promised features for a while now and have the potential to be transformative. Based on the papers, you appear to be one of the major driving forces behing them. It must be exceptionally hard to design a major new feature of a major language without being able to standardise something already out there and in use.

There have been a few experiemental implementations of concepts (first) and then concepts lite. Have you made use of these much? In other words have you done any real programming with concepts and started to gain experience of what concepts are going to feel like in practice? And the important thing following on from that is are you liking what you're seeing?

Also, as a related point, are we likely to see these in C++17? I still look forward to being able to do:

sort(some_vector_of_some_struct);

and having it either work or tell me that operator is missing for that struct.

Further development

[david_thornley]

How long do you think C++ will continue to be actively developed and changed? When will there just be too much crufty backwards compatibility to warrant improving the language? Do you think we're close to pretty much all the language features we're going to need, so further standards will be almost exclusively library changes?

int stroustrup()

[Impy the Impiuos Imp]

If your last name were to be made into a C library string function, what would it do?

I'm Baba Wawa and this............ is Twenty Twenty.

Re:Is the complexity of C++ job security?

[shoor]

I'm not a C++ programmer. But I have come across situations where people seemed to deliberately use weird, obfuscating stuff just so nobody else could take their place, (I particularly remember a company where somebody had convinced management to use UUCP instead of FTP for internal data xfers because it was more secure. When I was being interviewed on the phone they asked me what I thought of UUCP, and I think I was one of the few people they interviewed who had even heard of it.)

So, if C++ is as complicated and full of stuff as I keep reading about, I can see how somebody might deliberately cultivate for themselves a set of esoteric off the wall constructions that they'd throw in their code just so nobody else could work with it, all the time selling management on how 'good' it was.

Signed integer overflow and security holes

[Myria]

Signed integer overflow is undefined. That is, in C++, overflowing a signed integer is considered to be equally bad as dividing by zero. Combined with modern compilers, this is resulting in exploitable security bugs in many programs.

Programmers have been taught for decades about two's-complement integer arithmetic and how it overflows. As a result, many of us who don't know about signed integer overflowing being undefined are making "mistakes" like assuming that it wraps as we were taught.

The reason that C++ considers signed integer overflow to be undefined is because of non-two's-complement machines. Such machines pretty much don't exist anymore. Why does C++ insist upon keeping such requirements around, when it is wreaking security havoc on everyone else?

Re:Signed integer overflow and security holes

[serviscope_minor]

Even with 2's complement, quite a few DSPs have saturated add instructions so that overflow does not occur. The MMX unit also has this.

Re:Signed integer overflow and security holes

[iggymanz]

what about Google's Protocol Buffer's Zig Zag encoding (sign on lsd)?

C compatiblity

[Anonymous Coward]

C++98 is almost a superset of C89. C99 brought many incompatible changes to C, some of which were reconciled by C++11, but some of which weren't (restrict, VLAs, designated initializers, etc.). To a certain degree, this is understandable and unavoidable (although personally I've decided to stop using C++-incompatible features in C). Worse, in my opinion, are the new features that were added to both C and C++, but in a source-level incompatible way. I'm talking about thing like multithreading and complex numbers.

Without using either an external library or ugly preprocessor hackery, I can't write a program using multithreading or complex numbers that's valid as both C++ and C. Do you think these incompatibilities can be reduced? It's probably too late to do any thing about complex numbers (and C++ got them before C anyway), but is it reasonable for me to expect a future C++ standard containing a cthreads/threads.h header that duplicates C11's thread.h header in a completely compatible manner? Or am I simply being forced to make a choice between C++ and C?

Backward compatibility at all cost?

[eminencja]

1) You said on multiple occasions that backwards compatibility is an important feature of C++. That feature comes at a cost, however (e.g. in language size and complexity). Do you think that at some point the cost of backward compatibility will outweigh the benefits? To put this in a context - several recent languages try to go into the system programming domain (D, Rust, Go). All quote dissatisfaction with C++ as (one of) the primary motivations (primary reasons being language complexity, poor support for parallelism, and long compile times). Can we hope the committee will be more aggressive in obsoleting old/broken features?

2) When will size_t be replaced by a signed type?

3) Your take on increased throughput of the committee and planed standardisation of many new libraries (graphics, asio, fs, etc.)

Code rejuvenation

[SansEverything]

You speak alot about code rejuvenation and bringing old code to new standards. As you are working on C++14, many compilers do not fully support C++11 yet. In the past, it was even worse. Don't you think that this lack of feature support from compilers is a major problem and the biggest obstacle to code rejuvenation?

Re:Code rejuvenation

[Anonymous Coward]

The C++14 have some must-haves, which is why selected sets of C++14 features may have been implemented in a compiler before fully achieving C++11 compatibility.

is auto a mistake in C++11

[poached]

The auto keyword in C++11 makes writing code a hair faster but makes maintaining code much harder. It was seen as a great feature so programmers don't have to write out long and messy template class declarations, but I feel that it makes code maintenance a nightmare. Instead of knowing exactly what is being returned, the code that abuses "auto" makes the maintainer have to track down the function signature and then find the return type. Coupled with less than perfect (and much worse compared to C# and Java) IDE support for source code, it kills productivity. What is your view on the auto keyword?

Re:is auto a mistake in C++11

[Anonymous Coward]

What are you talking about, just hover your mouse over the "auto" and any decent IDE will show you the real type(see Visual Studio)

C++ without exceptions

[Anonymous Coward]

I like many things about C++ and would like to use them. Unfortunately I'm seeing many new library features being implemented in such a way that I can't get around the use of exceptions. An example if C++11's new threading libraries. For reasons that are beyond the scope of this question, I will not use exceptions in my code. This means I can't use C++11 multithreading and have to keep using the less portable (on paper, anyway) pthreads. Why aren't the interests of those who want to use C++ without exceptions being taken into account more specifically?

LOC

[StripedCow]

By approximation, how many lines of code have you written in C++?
And what were the types of software you worked on?

Why is there no lambda keyword?

[Anonymous Coward]

You, and the committee, are reluctant to add keywords. Thats why the sematics of keywords like "delete" are overloaded and theres no "lambda" keyword. Presumably this is to avoid breaking compatiblity with c++03 code, but gcc, clang, and many others need -std=c++11 to enable c++11 anyway. Any thoughts?

And seriously, can we just deprecate or remove trigraphs? I expect people who still use them also use gcc 2.95 or VS6.

Header files

[StripedCow]

Many programmers (including me) are flat out annoyed by the need to maintain header files (they are useful for documentation purposes only, but there are automated tools for extracting this type of information). Also, there seems to be no technical necessity to use header files (other than helping compiler/linker implementors).

Why are header files still (a non-optional) part of the standard?

Re:Header files

[Greyfox]

Header files are totally optional. You can write all your code in one big file if you want to. You just need to make sure no function calls any function that hasn't been defined yet. No problem!

Re:Header files

[GrahamCox]

Header files are great when you are writing code to be used by other people (i.e. most oft he time, for a professional). They allow you to separate the public parts of your blob of code from all the private nasty bits you'd rather they didn't see or use. Headers define your code's contract with the outside world, the rest is implementation detail. I'd hate to have to link against code that didn't use them - it would massively increase the learning curve for arbitrary libraries.

Re:Header files

[flargleblarg]

Header files are totally optional. You can write all your code in one big file if you want to. You just need to make sure no function calls any function that hasn't been defined or declared yet. No problem!

FTFY.

Re:Header files

[gbjbaanb]

all true, and if you look at alternative languages *such as C# for example) you'll find developers are creating their own version of header files (I refer to file containing an Interface that is to all intents and purposes close enough to the concept of a C++ header to make little difference).

However, C++ headers also contain private stuff. I think a good advance would be to allow private declarations to the cpp file instead, but doing that would mean the public stuff could also be moved too and so headers would become obsolete. Maybe this would be a good thing, but then you'd need some way to extract the public definition from your binaries (as today to compile a shared C++ dll you need a lib/so to link, and the header to compile). So this would have to be changed too, and as C++ doesn't have an ABI, you pretty much can't do it.

I suppose it might be nice to have the IDE generate the headers, but then, you'd be restricting your coding to those IDEs that support this- no more writing a bit of C++ in notepad or vi. So I guess that's out too.

template metaprogramming

[StripedCow]

Personally I find it often easier to write code that uses template meta-programming, than to read it.
Do you share this opinion, and don't you think this is exactly contrary to how it should be?

multi-stage compilation

[StripedCow]

In a multi-stage compilation process, libraries could generate readable C++ code based on (type-)requirements of a user-program.
This could be an alternative to template (meta)-programming, which would (I suppose) result in much easier to read programs and possibly better understandable error messages.

Have you considered such a compilation model? And if so, why do you consider templates to be a better choice?

Standardizing pimpl classes?

[Anonymous Coward]

I've been using the pimpl pattern lately, and enjoy the benefits of separating the API from the implementation.
The main down side is the extra overhead of writing the separate public and private classes, and forwarding the public implementation calls to the private implementation.

What are your thoughts on making pimpl part of C++ as a new class type?

What about a C++ compliance test like Acid?

[Anonymous Coward]

The Web Standards Project published three compliance tests called Acid1, Acid2 and Acid3 to measure the compliance of a specific browser.

Is it possible/desirable to give access to free-to-use C++ sources to measure the compliance of a specific C++ compiler?

(It could be, for example, published on isocpp.org)

Multiple Return Types?

[slashdice]

c++11 added attributes which is kind of what you want, I think. Except there are only 3 standard ones and compiler-specific ones are namespaced.

Running out of operators?

[Sigvatr]

There are a ton of unused characters on a standard keyboard that could be useful and/or fun to use as part of core language feature additions or more operator overloaders. Is there a reason that we don't use them?

What about open multi-methods in standard C++?

[Anonymous Coward]

As a C++ developer, C++11/14 brings me a lot of features that, indeed, makes C++ feels like a new language (my pet feature is the move semantics).

A few years ago (2007), you proposed open multi-methods (http://www.stroustrup.com/multimethods.pdf)

What are the reasons (technical, or otherwise) open multi-methods are not part of the current C++ standard, or even proposed for the next iteration?

OO design inspiration

[karijes]

I was always curious, why did you choose Simula as inspiration for OO design? Many, including Alan Kay himself, are believing this is wrong approach for original object oriented design in languages, which are followed by Java, C# and many more. Why didn't you used Smalltalk or even CLOS as basis for more dynamic and introspective system (Common Lisp compilers are proving CLOS dynamism doesn't have to be barrier for creating fast and optimized code) and do you think Objective C did the right thing?

Heap Variable lifetime management.

[Anonymous Coward]

What I meant to ask in my OP was:
"Why doesn't C++ have language support for allocation and deallocation of variables on the heap. C++ manages the lifetimes of stack variables, why not heap variables?"

About your "two kinds of languages" comment

[J. J. Ramsey]

You've said, "There are only two kinds of languages: the ones people complain about and the ones nobody uses." Why does this tend to happen?

Re:About your "two kinds of languages" comment

[Anonymous Coward]

Think a little bit more. You can answer this one yourself.

Fair questions?

[Anonymous Coward]

It's sad to see so many "questions" on here like from the person who hates C++'s lambda syntax but didn't even bother to suggest a syntax or a language that they do like for comparison..I don't see how anyone can easily answer such non questions or should have to without a basic starting point.They are less than lazy. I understand it even less why these people don't get on the C++ Standard website and make their suggestions there so their ideas can be standardized and they could learn something.

I think more can be done to encourage people like the lambda poster to participate on the C++ Standard website forums in a positive way and I think there is a lot more to get excited about C++ in the future like Concepts, Multi-methods, type safe switch, etc. and maybe even a new STL down the line.

Do you see the ISO Standard C++ website being extended further with more tools and communications options to make collecting ideas on those proposals easier so the feedback can be more organised and do you intend to talk about these specific features I mention soon on here or that site and not just Concepts, to continue stirring up interest?

Thanks for C++! It's been an enduring success.

Loki

[Anonymous Coward]

What do you think about Andrei Alexandrescu's Loki library, with the idea of many template parameters allowing users to customize common utility classes?

Signed integer overflow being defined.

[Myria]

Screw ancient architectures and minor compiler optimizations. I'd rather have my binary math work like all of us were taught in discrete math classes. Not to mention not have my machine pwned by the mob because a programmer didn't realize that their security check was removed for being undefined behavior.

feature selection

[Anonymous Coward]

I'm writing a new security library in c++11 as an esperiment, and I choose to avoid exceptions and rtti. There are stories that you have done similar choices with some of your projects, for example to be able to use some proof of correctness.
Do you have any recommendations on a specific set of features for my (or other) use cases?

Fizz Buzz

[Anonymous Coward]

Well, considering that you said "numbers" and not integers and that any number is divisible by 3 or 5, the output of such a program would be a never ending repeat of "buzz" or "fizz" or "buzzfizz". Since you did not specify whether "buzz" or "fizz" takes precedence, all three choices are valid. Here is a sample of your program's output: ...buzzfizzbuzzfizzbuzzfizz...

What do you think about Rust?

[Anonymous Coward]

Do you think Rust is a good replacement for C++?

Feature Cut

[BlackHawk-666]

Are there any features of the language that you wish hadn't been added or could now be removed?

Re:Feature Cut

[jbcksfrt]

No mod points but would +1.

Redesign

[Anonymous Coward]

If you had to design a new programming language from scratch today, unencumbered by backwards compatibility, what would it look like?

templates

[Anonymous Coward]

Any comments about the fact that the template metaprogramming is Turing Complete?

The solution is simple:

[Anonymous Coward]

Pass by const reference.

(Btw, std::strings may have their warts, but at least they TRACK THE FUCKING LENGTH OF THE STRING correctly. Not so for C "strings".)

Remme aska you something

[Anonymous Coward]

Where do you see the programming sector move both geographic-wise and usefulness

Operators

[Anonymous Coward]

Why won't we get new operators like *>, >=> or &&& ? Haskell allows defining an infinite number of arbitrary operators, which is very useful.

Crystal Ball

[serviscope_minor]

C++ is has turned 30 and you're one of the most recognised names in computing. What does your fuzzy, scratched and cloudy crystal ball tell you about C++43 and what computing will look like then?

const auto

[Anonymous Coward]

If we have begin, end and cbegin, cend, why don't we have cauto? Please don't say you do not want to break legacy code. That argument appears to be the killer of all innovation.

Big problems from a little seed.

[Ungrounded Lightning]

Bjarne: There really is a question at the end of this, but it takes some setting up. Please bear with me.

In the late '80s I came to Silicon Valley for a startup, which was using C++ for a major project. I learned the language then and got over the "doing it the object-oriented way" hump. In the process I analyzed what cfront was producing and got a good understanding of what was under the hood (at the time).

The project was very ambitious. Much of it was creating a data base engine for a complicated indexing mechanism. The result was that transactions occurred by creating a transient structure. The bulk of the work occurred during its construction, and errors during this stage had to be unwound carefully.

In those days C++ didn't have exception handling - "catch" and "throw" were reserved words, to be defined later. (So I built a set of exception handling classes that unwound even errors thrown from deep in construction and destruction correctly.)

Some of the architectural types had come to OOP via Xerox PARC and Smalltalk, and didn't want to be "slowed down" by getting "manual" memory management right. So we built a set of classes (incluing "smartpointers") and a preprocessor (to automatically generate pointer-identifying virtual functions) and got garbage collection working just fine. (We did a similar thing for remote procedure calls, and so on. We may still hold the record for layers of preprocessing between source and object...)

C++ WOULD have been the ideal language for it. But we found a little hole in the spec that caused BIG problems. The language got it SO ALMOST right that it was painful.

Consider construction of a subclass with virtual functions. Suppose the base class exports a pointer to itself (say, putting it into an external list). Then suppose that, at some time during the execution of the constructor of a member object of the derived class (or other initialization of the derived class), something gets hold of that pointer and calls a virtual function of the base class that is overridden by the derived class. Does it get the base class or derived class version of the function?

IMHO it should get the BASE class version during the initialization of the derived class UP TO the execution of the first user-written statement of the constructor, and the derived class version once the constructor's guts are executing. Getting the derived version before the constructor proper is entered means attempting to use functionality that has not been initialized. (Before the constructor is enetered you're still initializing the component parts. During the constructorf you initialize the assembly, and the author can manage the issue.) Similarly, during destruction it should get the derived version through the last user written line of the destructor, the base class version after that (as first the object-type members, then the base class(es), are destroyed).

Examples of how this would work in real problems:
- Object represents a an object in a displayed image. The base class is a generic displayable object, which hooks the object into a display list. It has a do-nothing "DrawMe()" virtual function. The derived class adds the behavior. When the display finishes a frame the list is run, calling the "DrawMe()" methods of all the objects. If one is still under construction and the derived class overriding is clalled, uninitialized memory is accessed (including pointers containing stack junk).
- Object is heap-allocated. Virtual functions are the "mark()" or "sweep()" pointer enumerator for the garbage collector. Base classs is the generic "I'm a heap allocated object" substrate, hooking into an "allocated objects" list with do-nothing virtual functions. At each level of object derivation the new version of the function enumerates, for the mark and sweep phases, the member variables that are pointers (and calls the base class version to also enumerate the pointers at the more baseward layers. The pointers' own initialization

exceptions

[Anonymous Coward]

When will c++ lose external exceptions and stack so that all events and state are programmable. E.g. mail home a stack dump on a null pointer. Lisp/SNOBOL/,,, can do this.

Static initialization order problem.

[morto]

Hi Mr. Stroustrup, Thank you for C++. It is my language of choice.

Why the static initialization order problem was not addressed in recent reforms of the language ?

It does not seem very hard to fix. Although I am aware of the workarounds I do not like them. In my opinion we need to fix what is broken before adding more features. Thank you for your attention, Mauricio Gomes.

Modern features

[Anonymous Coward]

When I code in C++ I really miss things like algebraic data types, pattern matching, and type classes.

  boost::variant exists, but requires too much syntax.

The lack of type class like functionality is also pretty irritating, emulating this in C++ requires far too much boilerplate--

  Could you get the committee to step on it with adding features? The pace seems glacial:(

Data representation and initializer list question

[david_thornley]

An initializer list is supposed to provide parameters for a function call. At least in VC++, I can use it as brace initialization instead of parentheses; for example, given a function that takes an integer and a pointer to const char, I can initialize it as either F(1, "two") or F{1, "two"}. There is no requirement for a function to take any sort of homogenous types as parameters.

However, a std::initializer_list, which is also values between braces, and is intended to provide parameters to a function, is a template of type T. Since I know of no T that would represent both an int and a const char *, I don't see how std::initializer_list could be used for the above parameters.

Is there any plan to make std::initializer_list more versatile, so it can actually do what it was apparently intended to do? How likely are we to get more of these "almost works" features in further standards?

Teaching C++

[Anonymous Coward]

You bought a cowboy hat when you tried to teach C++ at Texas A&M University. What did you do with the hat after they fired you ?

What is the ideal size of an Object?

[NewYork]

What is the ideal size of an Object?

Re:What is the ideal size of an Object?

[JustNiz]

The smallest possible to effectively and elegantly implement its class, and to also remain reable and supportable.

C++11 is the standard now

[tepples]

There is no way to specify a format for size_t in C that will work in all official standards. "%z" wasn't introduced until C99

C99 is a decade and a half old. It's time to pull a new compiler from your publisher's repository:

sudo sh -c "apt-get update; apt-get upgrade"

Though the official inclusion of its types in C++ is only three years old, dating to C++11, compilers have provided the C99 types as an extension to C++ for as long as they've implemented C99.

C Compatibility

[Anonymous Coward]

In your interview with Emyr Williams for CVu magazine you mention that, with hindsight, you "would not have chosen the C declarator syntax or two-way conversions between fundamental types, but to fix those, you would need to take the time machine a few years further back for a chat with Dennis."

Including the two issues mentioned, what are the design decisions/mistakes made in C which you had to carry forward to C++ due to the decision to remain largely compatible with C?

What was your thinking?

[JustNiz]

Why did you think adding the "friend" keyword to C++ was a good idea?

Do you still think it is good?