C++ Daddy Bjarne Stroustrup outlines directions for v17

Calm yourselves, readers. The Spring 2015 C++ Standards Committee Meeting takes place next week in Lenexa, Kansas. And at that meeting much of the discussion is expected to consider C++ 17, a major revision of the programming language due in 2017. C++ is currently in version 14, which was released last year, but last week C++ …

[Voland's right hand]

Direction number one

Put the poor thing out of its misery. Let's face it - it now looks like the creature from The Fly.

Do the C++ and Java fans like it or not, a lot of the modern stuff like functional programming constructs heavily depend on late evaluation and runtime type checking. Trying to fit this square peg into the round hole of the strict compile time type check has resulted in a horryfying generics and lambda syntax in both. C++ (and Java) were not the most easy to comprehend language before that. With that, they are almost as bad to read as sysadmin (not professionally written) Perl.

Just taking one look at the C++ (and Java 8 for that matter) shenanigans to implement any of the recent "must have" programming language features is enough. This thing has outlived its time, it is time for it to be put into maintenance mode instead of having new features grafted onto it.

[Anonymous Coward]

Re: Direction number one

I am quite sad I can only downvote your post once. There's not a single thing in your I agree with, except your criticism of Java (that thing needs to be taken out back and shot - with a rifle).

[Anonymous Coward]

Re: Direction number one

@martijn, I'm happy to have Java taken out and shot, but if this is to happen, it's only fair that Java is allowed to stand behind your beloved c++.

[Anonymous Coward]

Re: Direction number one

Languages evolve… the problem C++ was trying to solve in the early 90's is somewhat different to the problem being solved today.

I recently started doing some serious C++ work using Qt and I was pleasantly surprised just how much the language had evolved and how much there was that made it truly feel like "managed code" languages such as C# and Java, but without the Windows-isms of C# or the quirks of Java.

It has got to be by far one of the most universal programming languages, second only to C, as it will run on all kinds of platforms, not just general-purpose operating systems but real-time kernels and bare-iron too.

[Michael Wojcik]

Re: Direction number one

I recently started doing some serious C++ work using Qt and I was pleasantly surprised just how much the language had evolved

The problem isn't C++ the language, which can indeed be very good if used judiciously by someone dedicated to the craft. (That sort of programmer is rare, true; but then the other sort will write crap in any language.)

The problem is the vast corpus of existing C++ code. I've seen tens of thousands of lines of C++, in more than a hundred projects, from perhaps a few dozen organizations / teams / individuals. Nearly all of it is horrible: inconsistent, nearly unreadable, ill-conceived, and dangerous. Most of it fails to use even constructs from the '98 standard when it should, much less newer features. I don't know how many classes I've seen that muck up things like basic memory handling, for example by using default copy constructors and assignment operators when the class contains dynamically-allocated storage.

Most of the decent C++ source I've seen is in textbooks - Stroustrop's own, Meyers' Effective C++, etc. But those models aren't adopted by most C++ programmers, it seems. C++ provides far too much freedom to an undisciplined development team, and most of them are undisciplined.

So working with an existing C++ code base - and greenfield projects are relatively uncommon - generally means a three-way Hobson's choice: a huge refactoring effort, copying the broken style of the old code, or writing new code in a better but inconsistent style (and increasing surprise for later maintainers).

There's no way for C++17 to fix that, though. Stroustrop's plans for it are reasonable. But as with previous updates, they'll help the good programmers much more than the bad ones, and they can't fix existing code.

[John Lilburne]

Re: Direction number one

Indeed C++ has lost its way. It was once a language for developing major applications that could be maintained over a long period. No more. Software development has become more concerned with thin apps running in a browser on top of a back end database. Which get thrown away after a couple of years. I know a number of people that say that hardly any of the code they wrote 5 years ago exist any more. Either the website they wrote it for has gone, the company has gone, or the UI has been replaced.

In such an environment the trend is to bash out code and move on. Languages have evolved to aid that hack and trash development process. So we have people coming out of CompSci courses that have little understanding of writing systems that can be maintained and repurposed for two decades or more. All they want to do is get a working prototype as quickly as possible, and move on.

The C++ committee has spent the last several years pandering to short-termism.

[Anonymous Coward]

Re: Direction number one

Ah, Agile development.

As for C++, it was always, after the first couple of iterations (when programs had to be rewritten for each release) over-complicated and far too fond of black boxes. There seem to be endless class libraries for this handling and that handling, each with a massive book that makes the bible look short and concise. Every developer seemed to choose their own subset as few can keep the whole language in their head, usefully, at one time (unlike C) and not a few resort to writing straight C with a few C++ handy extras. The result is expense, complexity, inconsistency, lack of long term maintainability and frequent inefficiency plus some very obscure bugs.

I'm sure there are beautiful, intelligible and efficient C++ applications. I just have not seen (at a code level) very many, well, none actually.

I suspect we could all have been saved a lot of pain if Modula 2 or even Ada had taken over.

[joeldillon]

Re: Direction number one

The other guy kind of covered this, but what do you think that web browser and back end database are written in? People writing stuff in high level languages that don't require deep understanding isn't exactly a new thing, it's just a couple of decades ago it was Visual Basic. There will always be 'hard' systems languages and 'easy' scripting languages because they address different areas of development.

[Ian Joyner]

Re: Direction number one

joeldillon >>The other guy kind of covered this, but what do you think that web browser and back end database are written in? People writing stuff in high level languages that don't require deep understanding isn't exactly a new thing, it's just a couple of decades ago it was Visual Basic. There will always be 'hard' systems languages and 'easy' scripting languages because they address different areas of development.<<

No - C and C++ are full of accidental complexity not essential complexity. C++ exposes all of this accidental complexity. Some people mistake this for being comprehensive and 'deep understanding'. It's quite the opposite - those with real deep understanding of computing realise what a horrendous mess C++ is. Those with deep understanding keep things simple, elegant, and complete without resorting to the mess of C++.

[Anonymous Coward]

Re: Direction number one

"a lot of the modern stuff like functional programming constructs heavily depend on late evaluation and runtime type checking"

Well for a start functional isn't that modern , its been around for decades and if it was really that good and really brought anything useful to the table beyond a few non essential fancy features it would have caught on years ago like OO did.

Secondly, late evaluation and run time type checking requires lower level code to do this - its not done by the OS. What do you think this runtime/interpreter code is usually written in? Languages like C and C++ exist so high level fluffy coders like yourself don't have to do the hard stuff and can have the ironic luxury of whining that the hard stuff no longer needs to be done.

[Kristian Walsh]

Re: Direction number one

"a lot of the modern stuff like functional programming constructs heavily depend on late evaluation and runtime type checking"

Actually not even this is true - runtime type-checking is not essential - it only makes the task easier for the compiler/runtime authors, but if you look at a typical dynamic/late program using functional patterns, you'll see that in most cases the type of data being worked on is actually known, or can be defined, just by looking at the code.

The type-agnostic statement of "An object with a field called X which I treat as an integer, and a method Y that I pass a Timestamp to" is another way of saying " class FooInterface { public: int X; void Y(Timestamp& t) }; ". If the compiler can do that intermediate step for you, then you can be just as expressive in a statically-typed language, while retaining the other advantages of static typing.

This is the approach that Microsoft took with C# - it looks like you're writing "late-binding" code, but the compiler is generating specific template instantiations and interfaces behind your back to make things work. It's quite surprising to see how seldom you actually have to resort to real late binding.

C# is an example of a language that, like C++, and unlike Java, has evolved steadily over the years to adapt to the needs of developers - what started out as a bad copy of Java is now a very nice language for developing applications, with some very nice syntactical features, like the "async" keyword.

[Michael Wojcik]

Re: Direction number one

Well for a start functional isn't that modern , its been around for decades and if it was really that good and really brought anything useful to the table beyond a few non essential fancy features it would have caught on years ago like OO did.

I find it difficult to conceive how anyone with any significant programming experience could believe that software development is a meritocracy. Do they not have critical thinking where you live?

[John Savard]

Re: Direction number one

This is an argument for putting "the modern stuff like functional programming constructs" in some new language, and not trying to graft it on to C++. It is not an argument for abandoning a language which is still very useful. Of course, if that "modern stuff" becomes so important that interest in C++ declines, then one can talk about "maintenance mode" - but at the moment, languages which produce efficient executables without the overhead of runtime type checking are still very much needed.

[h4rm0ny]

D

I wish D had achieved greater uptake. It was (is?) essentially C++ done again but "knowing what we know now".

[Herby]

Will anyone really understand the language?

As the language grows, it (by nature) becomes more complex. The C language (for example) is described (an older version) in a book by the originators (K & R) that is only a 1/2 inch thick (I just measured it!). C++ in its originator book (from a bunch of years ago, I don't have it in front of me, but Bjarne DID sign my copy) is about 1.5 inches thick. Given this the language is at least three times as complex, and getting more so. Most "modern" languages (I include C++ here) are getting more complex by the minute, and they are getting too complex for one person to "know" without propping open some sort of reference. The problem is that the complexities are getting ignored and people use a "known subset" and fake the rest of it.

Of course it gets worse when you need to link against some library, and (in C++) everything gets redefined because the author that it would be "cute". Then you attempt to learn another set of exceptions just to get your "simple task" done. It is a never ending task.

Of course it gets worse. A book on python (Programming Python by Mark Lutz) is even thicker (a good 3 inches) and learning the language is even more difficult. It is a never ending task.

As mentioned before "The nice thing about standards is that there are so many". To which I add: "and they are getting more complex!"

I long for the Fortran 66 (an improvement over Fortran II) days, but that is just me.

Yes, I did program a machine with Fortran II as its most complex language. It was a while ago!

[Dan 55]

Re: Will anyone really understand the language?

There's the time you take in learning a known subset and faking the rest of it (also known learning the parts of the language you need when you need to and having that knowledge on hand for future projects) vs. the time you take in programming everything laboriously by hand like in a language which you can know completely like C.

C++ gives you powerful tools and doesn't actively get in your way and stop you trying to do something. Other languages like Fucking Java just stop you doing things unless you rubber-stamp data through three or more classes.

[Bronek Kozicki]

Re: Will anyone really understand the language?

"learning the language is even more difficult. It is a never ending task."

Good, that's how it should be.

[Ian Joyner]

Re: Will anyone really understand the language?

Software development is an essential complexity. The complexity in C++ is self-inflicted accidental complexity.

[Anonymous Coward]

Re: Will anyone really understand the language?

"C++ gives you powerful tools and doesn't actively get in your way and stop you trying to do something. "

True, But there comes a point when its time to say "Enough - any further changes should be put in libraries". There's been enough fucking around with the language - personally I've only just grokked C++ 2011 , never mind 14 and it seems to be a law of diminishing returns wrt functionality.

"So what?" you might say, "just use the bits you need/know." Thats fine, except its getting to the point where everyone knows a different subsection of C++ and just uses that subsection for everything, which means when someone elses come to debug/update/maintain that code the odds are getting shorter that the maintenance coder won't understand a lot of it and it becomes a maintenance nightmare with knock on repercussions for the project.

[Kristian Walsh]

Re: Will anyone really understand the language?

In C, everyone knows the core language and standard library (well, they think they do...), but everyone goes about every data structure problem in their own, unique way. You get landed with maintaining that code, you need to learn the peculiarities of this one guy's hybrid linked-list/b-tree data structures and his unique take on string storage.

In C++ everyone knows the core language, and a subsection of the standard library, but at least they know that there is stuff in there that they do not know, and may have to learn in future if needed. However, everyone's "unique subset" is still a subset of an agreed whole. Once you're forced to learn that subset to maintain someone's code, it can be of use in other tasks. ( Like replacing someone's unique take on a particular type of container with a proven and maintainable version from the standard library)

[Anonymous Coward]

Re: Will anyone really understand the language?

"You get landed with maintaining that code, you need to learn the peculiarities of this one guy's hybrid linked-list/b-tree data structures and his unique take on string storage."

And in C++ instead of yet-another-b-tree-implementation you get landed with another guys idea of what a templated abstracted inheritence tree should be. Normally involving endless factory methods and 10 levels of inheritence. In C it simply would be too much work to implement anything close to that so people are forced to simplify their mental designs.

Thats not an argument for C over C++, I'd be the first to admit that some standard things in C are just too painful - but C++ offering more standard functionality simply means it'll be abused in a higher level way than C.

[Adam Inistrator]

Re: Will anyone really understand the language?

"Any new feature should be put in libraries". Like any developer you long for simplicity ... but you seem to forget the famous saying that everything should be as simple as possible BUT NO SIMPLER. There are relatively few C++ programmers so the average comment here is from programmers who dont use and dont really understand C++ and instead conceitedly grandstand their ignorance to mostly more of the same. bleh!

[Christian Berger]

Re: Will anyone really understand the language?

"There's the time you take in learning a known subset and faking the rest of it ,,, vs. the time you take in programming everything laboriously by hand like in a language which you can know completely like C."

In my experience typical problems in IT are easier to solve than reading into the library that does it, then finding out it won't work and trying to find out what you did wrong before finding out that you either misunderstood the interface of the library, or the library has a bug nobody found before.

[Tom 7]

Re: Will anyone really understand the language?

The more you understand about programming the more you will understand the language. And possibly other languages too.

The number of times I, and many colleagues, used to say 'Why would anyone want to do that FFS' only to later on another project going 'Wow! That's beautiful'.

[Phil Endecott]

Scribd

Commenting only to say how awful Scribd, on which the linked presentation is stored, seems to be.

I am allowed to view 3 of te 5 pages (on my iPad), at which point I am told that I must download their "free mobile app" in order to read the last two. FUCK YOU SCRIBD. I will not install some app just to view this! Bjarne, is this what you wanted? If not, maybe try Google Docs? Or just host it on your own website FFS!

</rant>

[Dan 55]

Re: Scribd

It wasn't Bjarne that put it on Scribd. Really El Reg should also host the PDF and put a plain link to it in the article, they do that for the podcast.

[Anonymous Coward]

Re: Scribd

I thought it was something broken on their site and left it at that. Perhaps I am right in a way…

[JLV]

Re: Scribd

@Phil - upvote.

Ha, ha, you're better off than me - I've NoScript'ed scribd a long time ago, on the basis that it is unnecessarily obnoxious and intrusive even on a regular webpage. Hate that site.

Either you make your contents available publicly, or you do not. Either way is fine.

Putting it on scribd === FAIL

So this nice writeup appeared as a blank rectangle for me. Yeah, yeah, I could temp allow scribd.js on Noscript. But... it's scribd, that buzzard's not worth feeding.

</curmudgeon>

[jake]

Whatever.

I've never seen anything that C++ can do that I can't do in K&R more easily.

[Alfred]

Re: Whatever.

Maybe you've got your eyes closed. I have found many, many things that are much easier to do in C++ than in C.

[Anonymous Coward]

Re: Whatever.

Perhaps he meant resource leaks and bugs?

[Brewster's Angle Grinder]

Re: Whatever.

Unfortunately, I'm old enough to remember assembler programmers saying the same things about C.

[jake]

@Brewster's Angle Grinder (may I call you BAG?) was: Re: Whatever.

K&R is, to all intents & purposes, assembler. It's just easier to type/read across multiple platforms. Which is/was kind of the point of the language.

[Brewster's Angle Grinder]

Re: @Brewster's Angle Grinder (may I call you BAG?) was: Whatever.

@jake I found it got in the way, wasn't flexible and didn't give much back if you didn't need portability. (And I did do some K&R) And back then, most humans were better than compilers, especially on the register-starved, segmented x86.

Strong typing, overloading (*cough* C99 tgmath abomination), and references helped make up for that.

[Kristian Walsh]

Re: Whatever.

I've never seen anything a Japanese speaker can write that I couldn't write in English more easily.

Or, to elaborate: 正直なところ、私は日本語を話す方法を知っていません。私はオンライン翻訳ツールを使用してこのテキストを生成するいた。

[James 47]

asio

I::was::never::a::big::fan::of::boost::asio

string_view? is that what's now string_ref?

[Moonshine]

C++ haters: What about performance?

I don't think C++ is going down the pan any time soon, simply because of one thing: If you have performance-critical systems then C++ is a sound choice. There's no interpreter, unpredictable JIT or garbage collection. It has proven success record, excellent support (paid and free) and huge developer community.

OS development, real time systems, network software and drivers: Without C++ they would slow your whole system down and instead people would be complaining about "too many layers of cr@p, inefficient software, I remember when..., etc).

C++ is here to stay and keeps doing its job.

BTW I'm not a C++ evangelist, I like Python too.

[Brewster's Angle Grinder]

Re: C++ haters: What about performance?

There are no "haters", merely those who can program C++ and those who aren't smart enough to. (Mobile Users: Joke Icon)

[jake]

Re: C++ haters: What about performance?

"OS development"

Define "OS". Do you mean the kernel/monitor, or do you mean the massive amounts of shovel-ware that Cupertino and Redmond seem to think makes up an Operating System?

"real time systems, network software and drivers"

All K&R and/or assembler, not C++.

[Moonshine]

Re: C++ haters: What about performance?

Define "OS"

By OS I mean Kernel, Monitor, Hardware drivers, UI Shell, plus a bit of the "shovel-ware" such as browser, editors, whatever. Performance is everything on these components, it can make-or-break. C++ can give you this and allow some OOD implementation. Absolute no-brainer.

All K&R and/or assembler, not C++.

By K&R you mean C? Why not say just "C"? It's less to type. Yes, that would be a good choice also, but why choose it over C++? That does not make sense, it just smacks of personal choice, idealism, stubbornness and missed opportunities.

Assembler? What, your joking right?, lots of development time, no portability, hard to maintain.

[Dan 55]

Re: C++ haters: What about performance?

"C" could be taken to mean C89 which is far too newfangled with stuff like type checking the function parameters and the POSIX spec. With "K&R" you know that the reader will be in no doubt that you're talking about the late-70s version of the language where stack overflows were real stack overflows and if they are in doubt then you will also have the opportunity to correct them which is even better.

[Moonshine]

Re: C++ haters: What about performance?

Apologies, I didn't realise I was addressing K&R Fundamentalists. I respect that some feel compile-time Type Checking be the work of the Devil, also that the K&R blessed holy syntax checker is sacred.

[Anonymous Coward]

Re: C++ haters: What about performance?

> "C" could be taken to mean C89 which is far too newfangled with stuff like type checking the function parameters and the POSIX spec.

I don't think the "far too newfangled" qualifier reasonably applies to C89. The C Standard is currently at C11. C89 is 26 years old. Maybe it's time to retire it.

[Michael Wojcik]

Re: C++ haters: What about performance?

C89 which is far too newfangled with stuff like type checking the function parameters and the POSIX spec

POSIX and its successors (SUS) are not, and have never been, part of the C specification (ISO 9899).

With "K&R" you know that the reader will be in no doubt that you're talking about the late-70s

Technically "K&R" C goes all the way up until 1989, for the US, and 1990 for the rest of the world. (And, of course, K&R implementations continued to be used, and even produced, well after 1989, since it took a while for people to catch up to the standard. And similarly with later standards. Does Microsoft have a conforming C99 snprintf yet, for example? The Visual C docs suggest that no, they still just have _snprintf with incorrect, and stupid, return-code semantics. Sigh.)

But, yes, I take your point. Jake seems to be using "K&R" to show his disdain for function prototyping and the like. Well, I've been writing commercial C since before standardization too, and I'm quite glad to have the C89 / C90 innovations, and some of the C99 ones as well. (I have no use for C94, but then who does?)

He's also wrong about the "portable assembler" rubbish - even K&R C was hugely different from the assembly language of any major processor family, in concept, structure, abstraction, etc - but clearly that canard will never die. Programmers do love their category errors.

[Anonymous Coward]

Re: C++ haters: What about performance?

"Assembler? What, your joking right?, lots of development time, no portability, hard to maintain."

Compilers can't do everything. Some specific operations have to be done in assembler even if that assembler is wrapped up in a C function. Eg: interrupt calling, processor ring level switching

Buy yourself a ticket on the clue train sometime.

[Ian Joyner]

Re: C++ haters: What about performance?

Blotter: >>"Assembler? What, your joking right?, lots of development time, no portability, hard to maintain."

Compilers can't do everything. Some specific operations have to be done in assembler even if that assembler is wrapped up in a C function. Eg: interrupt calling, processor ring level switching

Buy yourself a ticket on the clue train sometime.<<

Assembler is only needed on machines with flawed architectures that expose implementation details like CPU registers. Everything you might want to in assembler could be built into a HLL and compiler. But on the best machine I know, there is no assembler - all system software is built in ALGOL-based languages with interrupt handling, event handling for multiprocessing, etc. There is a special language for OS (NEWP), which provides specific constructs for specific instructions like context switching, but that is still ALGOL-based and never low-level like assembler or even C.

It's time for the computing community to think different and challenge the very foundations and assumptions on which it is built.

[Dexter]

Re: C++ haters: What about performance?

Jake wrote:

"real time systems, network software and drivers"

All K&R and/or assembler, not C++.

--------------------------

I must have been imagining all the real time systems and network software I've written in C++ over the last 20 years (device drivers I'll agree with, never seen one of those in C++). Many of those would have been exceedingly painful to do in C and would have resulted in unmaintainable code.

C++ is a solid systems language which gives the same performance as C but is much easier to write and maintain.

Just because you can't conceive of it, don't assume nobody else can.

[Anonymous Coward]

Re: C++ haters: What about performance?

I don't think C++ is going down the pan any time soon, simply because of one thing: If you have performance-critical systems then C++ is a sound choice. There's no interpreter, unpredictable JIT or garbage collection. It has proven success record, excellent support (paid and free) and huge developer community.

It'll linger around, but I don't see many new projects using it. As for unpredictable, take a look at the varying behaviour of STL implementations. Support isn't great either - I so love C++ compiler errors and stacktraces.

OS development, real time systems, network software and drivers: Without C++ they would slow your whole system down and instead people would be complaining about "too many layers of cr@p, inefficient software, I remember when..., etc).

Looking at the OS I'm using, the kernel is C and a little assembler, the drivers are C, the windowing system is C. All the real time systems I've worked on? C and a little assembler. Even the RDBMS (PostgreSQL) is C. As for speed, C is lighter and more predictable. For higher level stuff, Java runs rings around it unless you can waste many magnitudes more time fine tuning your C++ code.

C++ is here to stay and keeps doing its job.

What job, annoying people who have to maintain older codebases like Open/LibreOffice and giving Stroustrup the opportunity to foist more of his bad language design on us?

BTW I'm not a C++ evangelist, I like Python too.

How's that significant whitespace working out ;-)

[Moonshine]

Re: C++ haters: What about performance?

As for unpredictable, take a look at the varying behaviour of STL implementations

STLs vary across implementations, but each implementation is predictable in itself. However, a single implementation of a JIT, garbage collector plus other runtime management routines is unpredictable and uncontrollable by its very nature. You cannot have it both ways.

C is lighter and more predictable. For higher level stuff

C it's just as predictable as C++, because both compile into machine code executables (not bytecode), and are consistent at runtime; there's no comparison to be made here.

Java runs rings around it unless you can waste many magnitudes more time fine tuning your C++ code.

No, the opposite is actually true. C++ is compiled into machine code and runs, end-of. Java is compiled into bytecode which needs a JVM at runtime, which cannot hope to optimise to the same degree as a compiler. For evidence, google "performance c++ vs java" or see:

http://benchmarksgame.alioth.debian.org/u64q/java.html.

[Anonymous Coward]

Re: C++ haters: What about performance?

STLs vary across implementations, but each implementation is predictable in itself.

Then I respectfully suggest you've not used many implementations. The standard(s) leave an awful lot of leeway for implementers to do things differently.

C it's just as predictable as C++, because both compile into machine code executables (not bytecode), and are consistent at runtime; there's no comparison to be made here.

Really? You think the class hierarchy complexity of a typical std::string implementation compiles to something as simple and predictable as glib's string abstraction?

C++ is compiled into machine code and runs, end-of. Java is compiled into bytecode which needs a JVM at runtime, which cannot hope to optimise to the same degree as a compiler.

That C++ has to be optimised at compile time. A "hotspot" JIT virtual machine can progressively optimise at runtime. Most studies show that while C++ code can be hand tweaked to outperform the Java equivalent, the degree of skill and time involved are extremely costly. For most typical programming tasks a language such as C# or Java is a better bet.

[Ian Joyner]

Re: C++ haters: What about performance?

>>If you have performance-critical systems then C++ is a sound choice.<<

Performance is not an excuse for C++'s complexity. Good clean languages can also be compiled to perform very competitively with C++.

[Hi Wreck]

#pragma?

Surely there must be a #pragma to force Fortran IV, er, gcc 2.95 mode?

[Anonymous Coward]

please fix the ambiguities in the existing Standard DR's

There are many ambiguities in the existing Standards - C++11 and C++14 - many of which have been reported in the Standard DR's.

Could these be clarified, please?

I understand that, sometimes, condensing a complex concept into Standardese English can be very dificult, and is inherently fraught with problems and/or ambiguities. But clarification of these ambiguities would go a long way in helping C++ compiler front-end developers, such as myself. Many of us - myself included - spend a lot of time trying to divine "what did they mean by this?". Or we need help from a Language Lawyer[tm].

Thank you.

[Anonymous Coward]

Map to hardware = LOL

That little line-item in their roadmap is going to present some unresolvable problems - the root cause being that hardware is inherently concurrent, and C++ is inherently sequential. No amount of hacks like threads, templates, or bolt-on frameworks like OpenCL will ever make that fact go away.

It is time to recognize that C++ is a dead branch in the language tree - any further hacks will only make the language even more obtuse.

Ask yourself why hardware engineers are able to design devices with billions of components that all operate in unison in a highly reliable and performant way - it's because they use this old language called VHDL which has concurrency at its roots.

It is time to put these computer 'scientists' out to pasture, recognize that they have failed to capture reality, and start thinking about languages beyond von Neumann, using concurrency from the bottom up. There are cool new tools like Cryptol that can be used to try out ideas that would be impossible in C/C++.

[Andrew Tyler 1]

VHDL

I'm not sure I'd call what VHDL does concurrent so much as semi-randomly sequential.

[no-one in particular]

Re: Map to hardware = LOL

> There are cool new tools like Cryptol that can be used to try out ideas that would be impossible in C/C++.

That sounded interesting, so I had a look - domain-specific languages can be interesting. Ooh, look:

http://www.cryptol.net/downloads.html

this is implemented on top of CVC4 for solving constraints and guess what CVC4 is implemented in? Yup, C++

http://cvc4.cs.nyu.edu/doc/classCVC4_1_1ExprStream.html

[Andrew Tyler 1]

C++

I like the C++ I write, I just hate having to understand the C++ other people write. If you pick a limited feature set that does what you and your team wants and stick to it for the most part (re-evaluating as necessary), C++ is great. It's when you start going mad and doing things just because you can and the language supports it that things go terribly, terribly wrong. Even though it's anathema to many, I find just using it as "a better C" is usually the way to go. To be fair though, my projects are usually smaller in nature (<<1 million LOC), developed by a small team, and most of the actual function is firmware written in C/assembler, so I'm not an expert. I do know that Bjarne's book, "The C++ Programming Language," is one of the most infuriating texts on the subject of programming languages ever written. It's hard not to read that and get the impression that Bjarne had aspirations of academia (or maybe even politics), whereas K&R just wanted to get things done.

[James 47]

Re: C++

Couldn't agree more... the best C++ programmers are those who know what parts to leave out.

Templates are quite cool, but they're a fucking disaster in the hands of fools. It's inexcusable that a missing 'const' can lead to pages and pages of compiler errors (I'm looking at you boost)

[Andrew Tyler 1]

Re: C++

I used Clang++ to test compile modules on the side for a project for precisely that reason, even though the project itself was ultimately compiled with GCC. Clang gives lovely error messages in color and can parse through all the template crap. Instead of the wall of text indicating errors in header files nested ten deep, it prints the text and line of your own code and is even pretty good at guessing what the actual error is, even indicating where with a little caret (it would spot constness errors for sure). I'm not sure what the most recent versions of GCC do (this was 4.7.x), but Clang saved me massive headaches for that one reason alone. It's an ugly kludge hopping between compilers like that and probably not practical in most organizations, but the way template errors are handled in GCC is intolerable. I think Visual Studio might produce reasonable error messages too, but I haven't used that in a while.

[Anonymous Coward]

Re: Clang

Yes Andrew,

We should all support clung because those poor execs at Apple don't have enough money for hookers and blow

[Andrew Tyler 1]

Re: Clang

If you judge tools based solely on your personal feelings about a company involved in their development then I pity your employers and co-workers. And, um, also Clang is free (as in beer, so not supporting anyone), and open source under a BSD-like license (forget which, exactly, but it's GPL compatible). It's a reasonably good bit of work, actually, though not without its caveats.

I do hate Objective-C passionately and probably hold a not totally justified prejudice against it, though. So it does go to show that nobody is perfect.

[Tim99]

Re: C++

Now all we need to do is take that object-oriented stuff out...

[Long John Brass]

Re: C++

> Bjarne had aspirations of academia (or maybe even politics), whereas K&R just wanted to get things done

And therein lays the rub

C is a language built by engineers for engineers; to get things done

C++ is a langues designed by comp sci profs, for comp sci students; to appeal to an ideology

You know who I mean ... Dijkstra and the reset of the evil language elves.

[Ian Joyner]

Re: C++

>>C is a language built by engineers for engineers; to get things done<<

Software development is not engineering. It is abstraction. K&R built C on very limited hardware with very limited compiler technology. We have moved way past that. We don't need the deficiencies of C or C++ any more.

Way before C there was ALGOL and ALGOL is still a far superior language (and the first used for high-level OS development in an OS that still survives and is still the best in the industry).

[Moonshine]

Re: C++

Software development is not engineering. It is abstraction.

Well that's killed of 1000,0000+ software engineers in one stroke!

[Ian Joyner]

Re: C++

I said: "Software development is not engineering. It is abstraction."

Moonshine replied: "Well that's killed of 1000,0000+ software engineers in one stroke!"

That's a lot of software developers who are calling themselves 'engineers' falsely. Software development is not engineering. There are some things that can be borrowed from engineering to help run projects, but mostly not - that's what Agile is about (although flawed itself, test-centred development rather than axiomatic development (contracts) for e.g.).

The wish to apply 'engineering' to software development is to give software some 'credence'. But it is false credence. Software needs it's own discipline (what I call AMAR analysis for Abstraction, Manipulation, Axiomatization, Representation - a technique espoused by Tony Hoare in Structured Programming).

Even David Parnas (one of the greatest software people of the 20th century, and a qualified engineer) when he was asked to teach software engineering said he really didn't understand what the term meant and he was sure it was not right.

Software is a fundamentally different entity to hardware. Hardware needs long design cycles and then the design is fixed. Software is what it is because it is not fixed and flexible. That makes it a very different process.

Thus software development is NOT engineering.

[Ian Joyner]

Re: C++

Long John Brass: >>You know who I mean ... Dijkstra and the reset of the evil language elves.<<

What a silly thing to say. Your complete ignorance is on display for everyone. The rest of your posts is just the usual platitudes swallowed by the gullible trying to justify their own existence and narrow-minded approach to computing. It is why the profession of programming is in such a mess now.

[Moonshine]

Re: C++

C++ is a langues designed by comp sci profs, for comp sci students; to appeal to an ideology

By "ideology" i think you mean "methodology". Well... Perish the thought that we should be using the proven OOD methodology to successfully develop increasingly large and complex applications over the last 20 years.

[Christian Berger]

The problem are different sensible subsets

Yes, the best way to deal with C++ is to throw out everything but a small sensible subset of it. The problem with this is, that different people will choose different subsets. This happens with many standards and usually is a sign that the standard is _way_ to complex to be useful.

[Ian Joyner]

Re: The problem are different sensible subsets

Christian: >>Yes, the best way to deal with C++ is to throw out everything but a small sensible subset of it.<

That's what Java did. A lot of the garbage of C and C++ gone. But did they end up with the best subset? I don't think so.

[Anonymous Coward]

Life imitates art?

This thread reads very much like a certain interview: http://www-users.cs.york.ac.uk/susan/joke/cpp.htm

[Christian Berger]

Re: Life imitates art?

Good satire highlights the core of the truth in a different light. :)

[Ken Hagan]

First glances differ

"At first glance, Stroustrup's suggestions appear to be concerned with ensuring C++ remains relevant to the “cloud-native” application crowd, without losing its soul along the way."

I didn't see *anything* in the presentation that looked remotely cloudy. In fact, the absence of some throwaway sop to appease those with their heads in a cloud was quite refreshing. It was straight down to business with stuff that will make it easier to write large and strongly typed software running on the bare metal.

[Matt Collins]

New Keywords

I'd like to see some new keywords added to help express human concepts. For example:

"consider" - this block is taken into account while the program runs.

"occasionally" - the following block sometimes runs, sometimes not.

"eventually" - the block runs, but not right now.

"tentative" - the block runs but can be reneged upon later if it turned out to be a bad idea.

Anyone have any others?!

Matt

[h4rm0ny]

Re: New Keywords

>>"Anyone have any others?!"

Manifesto - This block of code is omitted at compile time.

[Bleu]

Re: New Keywords

Are these #pragmas or just comments?

I'll throw in 'perhaps' and 'wish_and_prayer'.

[Matt Collins]

Re: New Keywords

heheheh nice ones! I mean proper keywords - like 'if' and 'switch' etc...

How about 'briefly' - a momentary aside in the program flow?

Matt

[Ken Hagan]

Re: New Keywords

Some of those sound like Prolog, others like aspect-oriented programming. None of them actually sound too ridiculous for the committee to consider.

[Michael Wojcik]

Re: New Keywords

"tentative" - the block runs but can be reneged upon later if it turned out to be a bad idea.

Stroustrop did say they'd be considering transactional memory.

Hey, where'd everybody go?

[Ian Joyner]

Writings on C++

http://ianjoyner.name/Files/ACritiqueOfC++.pdf

http://ianjoyner.name/C++.html

http://yosefk.com/c++fqa/defective.html

http://users.jyu.fi/~sakkinen/publ.html

[Bleu]

C++ is the knees of a bee

for sheer sumptuousness of ways to write unintelligible code.

Sure, you can do even better with Perl, but those folks do it for the pure art of play, and it's in a different dimension of languages (translated, not compiled, meant for the quick fix, natter, natter).

Stroustrop likes to imagine that his book is up there with K & R's.

It is not, it is an opaque mess, his attitude is to talk down to the lowly reader.

Anyone unfortunate enough to have worked with early C++ will know that half the stuff in the book that isn't C JUST DID NOT WORK for years.

Since they finally made most of it work, there has been a never-ending effort to pile on more and more ways to write unreadable code.

[Ian Joyner]

To really understand OO

People should look at Eiffel:

https://www.eiffel.com

and read any of Bertrand Meyer's writings:

http://www.amazon.com/s/ref=nb_sb_ss_c_0_11?url=search-alias%3Dstripbooks&field-keywords=bertrand+meyer&sprefix=bertrand+me%2Caps%2C864

especially Object-Oriented Software Construction:

http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?s=books&ie=UTF8&qid=1430269534&sr=1-3&keywords=bertrand+meyer

Your mastery of software development will improve out of sight.

Of course for functional (reactive) programming you should look at Haskell.