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++ …

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