New C++ Features Voted In By C++17 Standards Committee (reddit.com)

New submitter lefticus writes: The upcoming C++17 standard has reached Committee Draft stage, having been voted on in the standards committee meeting in Oulu, Finland this Saturday. This makes C++17 now feature complete, with many new interesting features such as if initializers and structured bindings having been voted in at this meeting.

An [audio] interview with the C++ committee chair, Herb Sutter, about the status of C++17 has also been posted.

Comments

Sweet

[Kohath]

C++ needed more features. Some C++ books aren't even 1000 pages long.

Re:Sweet

[Longjmp]

C++ needed more features. Some C++ books aren't even 1000 pages long.

I agree! And more use of the "const" keyword.
I want to write something like
const int const foo(const*(const) int const a) const: const {}
and
for (const i = 0;const i(const)++; i and finally:
const return const 1 (const const const)

Re: Sweet

[Anonymous Coward]

Not enough const

Re:Sweet

[NotInHere]

Sane languages have their stuff const by default, and you write mut if you want something changeable.

Re:Sweet

[110010001000]

You mean Rust. Rust is a terrible hipster language that won't last 5 years. C++ is going on 40.

Re:Sweet

[pedz]

C++ needed more features. Some C++ books aren't even 1000 pages long.

I agree! And more use of the "const" keyword. I want to write something like const int const foo(const*(const) int const a) const: const {} and for (const i = 0;const i(const)++; i and finally: const return const 1 (const const const)

Replace const with spam and you would have yourself a Monty Python skit.

Re:Sweet

[NotInHere]

I disagree with you. Rust has many friends in the haskell community. And haskell has survived for a long time, despite not becoming very popular.

Re:Sweet

[ffkom]

Just because you are unable to cope with C++'s richness of features does not mean it is a bad thing.

After all, C++ is the one language that

• supports a large selection of programming paradigms, and does not declare just a single one to be "the only one you need".
• does not depend on one company or organization, but is truly a federated effort, with many compilers to choose from.
• allows you both low-level / hardware-level programming as well as very-high-level programming just using some ready made class library / run time environment (like Qt).
• has a responsibly acting committee doing a good job overlooking the long-term language evolution. So much unlike many other programming languages, were inexperienced people have introduced the same mistakes over and over again, because nobody was there to question them.

Re:Sweet

[murdocj]

The problem is that some C++ still rely on runtime. The ideal C++ program only relies on compile-time templating.

Re:Sweet

[Anonymous Coward]

supports a large selection of programming paradigms, and does not declare just a single one to be "the only one you need".

I thought we had Perl for that.

Re:Sweet

[ffkom]

No Perl is for those who insist that every possible sequence of bytes shall be a valid program, because otherwise there is unnecessary redundancy in the code.

Re: Sweet

[Anonymous Coward]

I may have caught your point, but apparently
I is just a flesh wound.

Re:Sweet

[__aaclcg7560]

I haven't bought a door stopper (technical book) in over ten years. Mostly because up-to-date information can be found on the internet. If I buy a technical book these days, it's a used copy of an older book that is out of print, unavailable as an ebook, or cheaper than the current edition.

I recently picked up "Writing Compilers and Interpreters: An Applied Approach" by Ronald Mak (1991 edition), which uses an ancient dialect of C and Pascal as the target language. I know a smattering of C and nothing about Pascal. Should be fun learning experience.

Re:Sweet

[Hognoxious]

trump int trump foo(trump*(trump) int trump a) trump: trump {}
and
for (trump i = 0;trump i(trump)++; i and finally:
trump return trump 1 (trump trump trump)

FTFY

Re:Sweet

[Dutch Gun]

You need to divide C++ into two sections: Stuff that's useful for applications, and stuff that's mostly relevant to library writers. A lot of the really hairy stuff is mostly for the library writers. Moreover, a lot of the complexity of C++ (and corresponding slowness of its compilers) comes from compatibility with C and with older versions of itself. If you strip away all that, the core language that most people deal with isn't quite as daunting.

That being said, nobody is claiming that C++ isn't a difficult language to master. Scott Myers has made a career of pointing people away from it's darkest corners, after all.

But really, C++ programming took a quantum leap forward with C++11, and C++14 just filed away some of the rough edges. It's hard to explain to non-C++ programmers what a transformation it was. I'm not expecting nearly as much with C++ 17, but I look forward to seeing if any of the proposed features will be useful in my day-to-day work.

Re:Sweet

[Anonymous Coward]

has a responsibly acting committee doing a good job overlooking the long-term language evolution

They still say this with a straight face after std::vector[bool]?

Re:Sweet

[Anonymous Coward]

"C++ is going on 40"

Really? If you look at the subset of it you use, or at least should use, is that really 40? C++ has been rebuilt and extended so extensively over the years, I find that 40 years claim a bit specious.

Re: Sweet

[Anonymous Coward]

I've got a fever, and the prescription is more const

Re:Sweet

[Anonymous Coward]

Agreed, I actually hated the language before C++11, but now it's quite nice. Much more readable and consistent, clever reuse of the auto keyword.
The only thing I still miss is modules.
I'm a scientist, not a programmer, but the code I write is not suitable for Fortran, except perhaps the core computations. I was using C, but I'm gradually switching to C++, exactly since compilers started to implement well core C++11 features (mostly auto and uniform initialization).

Re:Sweet

[NotInHere]

So you say that isn't a good choice? Do you prefer having to put const everywhere?

Re:Sweet

[Anonymous Coward]

I agree. Some of the features added in C++11 really let you write more concise, clearer code. Just in the past 6 months, I got permission from management to upgrade our compiler version and turn on the flags that enable C++11 and C++14 features. (Some of the code we maintain was written in 2012 and 2013, at which time compiler support for C++11 was not ubiquitous.) My whole team has quite happily been taking to the new language features. The new code I'm seeing in our code base is more readable and more maintainable, as people make use of things like unique_ptr and shared_ptr (good-bye memory leak bugs), 'for' loops over collections, language-native thread and mutex support (good-bye bugs due to forgetting to unlock a mutex), lambda functions (really useful for a lot of stuff in the library), "futures" (good-bye to "roll-your-own" inter-thread communication - that never ends well). C++ is finally feeling like a "modern" language.

Re:Sweet

[ShanghaiBill]

So you say that isn't a good choice? Do you prefer having to put const everywhere?

You don't have to put const "everywhere". Most const values are defined in header files, where you write them once and rarely look at them again. For the code that you spend 90% of your time writing and maintaining, most variables are non-const.

Re:Sweet

[geezer nerd]

I always thought SNOBOL was that language where every string meant something to the compiler. When I was writing code in Perl, I did not feel as though that were true of Perl.

Re:Sweet

[Anonymous Coward]

You need to divide C++ into two sections: Stuff that's useful for applications, and stuff that's mostly relevant to library writers.

Yeah, this was really apparent with C++11. Basically it's like they said, "Well we basically want to add tuples to the language. But instead of adding tuples to the language we'll add variadic templates so tuples can be added to the standard library. Because variadic templates themselves might be a little much for people to use day-to-day but someday the metaprogramming messiah will come along and use them to create the singularity."

Re:Sweet

[gweihir]

For pretty insane values of "sane". Actually nobody sane does it that way. Breaking convention has no place in solid engineering, and only communities that misidentify "different" as "better" will ever accept such a moronic design.

Re:Sweet

[Lotana]

WTF is std::vector[bool]?

Don't you mean std::vector<bool>? Or am I missing something? Are booleans really being used as index these days?

Re:Sweet

[Anonymous Coward]

Don't forget
const auto&
because auto ain't auto

Re:Sweet

[DougReed]

This made me laugh. Having written programs in most of the languages living people have heard of, Perl is the one language I can write something in and 15 minutes later can't figure out what it does! I always called Perl the perfect write only language.

Having said that... I could write a Perl program in 5 lines that I would spend HOURS trying to figure out how to do in just about anything else. ... but if it's obscure I better add a comment to say what it is supposed to do. Because given problem 'x' I would be like 'I can do it like this' but a year later with no context it's ... 'What the hell is this supposed to do??? It's worse if it involved Perl's RegEx extensions and you don't remember what the incoming string contains. Just looking at the line makes you want to jump off of a bridge instead of trying to parse it in your head.

Re:Sweet

[Anonymous Coward]

Or F#, which is an amazing language.

Re:Sweet

[Anonymous Coward]

"C++ is going on 40"

Really? If you look at the subset of it you use, or at least should use, is that really 40? C++ has been rebuilt and extended so extensively over the years, I find that 40 years claim a bit specious.

C is 40 years old, C++ , which came later is not that old, it is closer to 25 years old.

Re:Sweet

[Dutch Gun]

The C++ committee (rightly so, I think) tends to prefer library-based solutions whenever possible, because there's less chance of disruptive changes when you add new libraries. Only when a library solution won't work do they turn to new language features. You'll also notice they really don't like adding new keywords at this point.

A lot of people seemingly don't understand how important this backwards compatibility is (presumably because they're always rewriting stuff using the latest new-and-shiny tech), but there are many places that have code that's decades old. It's a terrible idea to go and tinker with robust, well-tested code just because it's not the latest new-and-shiny. The careful attention to backwards-compatibility causes a lot of issues (like slow compile time / language complexity, etc), but it's also one of C++'s greatest strengths. People know that an investment in C++ code will be working just fine for decades to come. I mean, they're just now depreciating trigraphs, for pete's sake. Apparently IBM still has code that uses those and opposed their removal in the last standards round, but they're a tiny minority and couldn't sway the committee this time. No one else even knows what the hell they are.

Look how much of a rift the Python 2 to 3 change caused. Even if it's good for the language, incompatible changes that occur too quickly can cause real problems for a programming community. Even after 8 years, a significant percentage of Python programmers are still using 2.x instead of 3, mostly because of dependencies holding them back.

Nothing would kill new C++ features faster than incompatibility with legacy code. And in fact, one of the nice things about C++ is that it typically allows programmers to start adding those new features piecemeal as they get more familiar with them and as they get compiler support.

Re:Sweet

[Cassini2]

The beauty of C++ is that std::vector[bool] can be almost anything. See below:

#include
#include #define bool 2 #define vector vector test int main() { std::vector[bool]; test[0][0] = 1; test[1][0] = 2; printf("%d %d\n", test[0][0], test[1][0]); return(1); }

Re:Sweet

[Cassini2]

The beauty of C++ is that std::vector[bool] can be almost anything. See below:

#include <stdio.h>
#include <vector>

#define bool 2
#define vector vector test // Insert almost anything here, use trailing \ if necessary

int main() {
std::vector[bool];

test[0][0] = 1;
test[1][0] = 2;
printf("%d %d\n", test[0][0], test[1][0]);

return(1);
}

I wish I didn't know enough of C++ to write the above ...

Re:Sweet

[sconeu]

TECO command strings.

Re:Sweet

[NotInHere]

Are you so sure: https://stackoverflow.com/ques...

Re:Sweet

[Cassini2]

Try 3 at that demo program:

#include <stdio.h>
#include <vector>

#define bool 2
#define vector vector<int> test // Insert almost anything here, use trailing \ if necessary

int main() {
std::vector[bool];

test[0][0] = 1;
test[1][0] = 2;
printf("%d %d\n", test[0][0], test[1][0]);

return(1);
}

Re:Sweet

[Pseudonym]

C++ needed more features.

C++ needs more features to fix all the problems with the previous round of features.

Re:Sweet

[Pseudonym]

Haskell's unofficial motto is "avoid success at all costs", which is how it has remained pure and hipster. Haskell will always be the language of the future, in the sense that unless you work for a European bank you won't be using it yourself, but the new features in your favourite language will probably come from Haskell.

Avoiding success is a lesson that Rust has not learned.This is why Rust will become obsolete and Haskell will not.

Re:Sweet

[Anonymous Coward]

Look how much of a rift the Python 2 to 3 change caused.

Uh, there's no rift. Python 2 users can continue to use Python 2. Those who want to use Python 3 for new development can use it right off the bat. Those who want to convert their Python 2 code to Python 3 can use the 2to3 tool, and typically get the conversion done automatically. There's no rift at all.

Even after 8 years, a significant percentage of Python programmers are still using 2.x instead of 3, mostly because of dependencies holding them back.

If that's what you think, then your knowledge is about 7 years out of date. The major libraries typically support both, or if they only support Python 2 it's because Python 3 offers a superior alternative, typically within the standard library. Nearly all new Python development is done using Python 3, and this has been the case for many years now.

You don't know what you're talking about.

Re:Sweet

[Anonymous Coward]

It's also the one language that:

> supports a large selection of programming paradigms, and does not declare just a single one to be "the only one you need".
Manically replaces "evil" C features with far worse C++ idioms, without ever actually removing the supposedly offending interface.

> does not depend on one company or organization, but is truly a federated effort, with many compilers to choose from.
Has a myriad of incompatible ABIs to match every possible vendor and version combination.

> allows you both low-level / hardware-level programming as well as very-high-level programming just using some ready made class library / run time environment (like Qt).
Adds layers of insanely complicated features to keep programmers from hurting themselves, but still forces programmers to deal with those same low level issues when problems inevitably occur.

> has a responsibly acting committee doing a good job overlooking the long-term language evolution. So much unlike many other programming languages, were inexperienced people have introduced the same mistakes over and over again, because nobody was there to question them.
TONS of people have questions the sanity of the C++ language development, but nobody was there to listen to them. For an actually good example of restraint within a language, perhaps you should look at C?

You also forgot:
- Defines "object oriented" in so narrow and perverse a method so as to not exclude itself from the definition.
- Produces nearly incomprehensible compiler messages at the simplest of errors (no fault of the compiler, though).
- Produces myriad of "programming fads" arising from its victims, who are really just insisting on how nice the C++ emperor's clothes look.

C++ is a horrible, brain-damaged language. I'm not saying there are NO good ideas behind it, but it fails so miserably as a C replacement and forces so much pain upon its users, it would really be funny if it were just not so sad.

Re:Sweet

[Xtifr]

Yeah, C++11 was a major improvement; much of the extra "complexity" actually ended up making a lot of things much simpler. The new "auto", the new lambdas, and the new "smart" for loops, between them, allow writing simple, straightforward code to do things which would have required a tangled, opaque, and fragile mess of barely-readable code in older versions of C++.

Rvalue-references and std::move are a little trickier to understand, but fortunately, they can provide benefits even if you don't use them directly, since they greatly improve the performance of the standard library container classes and such. Even if you don't change your code!

Re:Sweet

[Dutch Gun]

Well, actual data say otherwise. If you've got some data that points to contrary trends, I'd be happy to take a look. The good news is that it's trending in the correct direction, albeit slowly.

If that's what you think, then your knowledge is about 7 years out of date.

You're telling me that only a year or so after Python 3 was released, most people were using it? Funny, that's not how I seem to recall things. Yes, there are tools like 2to3 (and even 3to2), but automated tools aren't magic, and can't fix everything.

Nearly all new Python development is done using Python 3, and this has been the case for many years now.

Well, yeah, no kidding. You don't have to worry about legacy code when writing something new.

Look, I've got nothing against Python - it's a great language. I'm certain Python 2 will be phased out completely at some point, but the point I was making was that the transition was a lot slower and more painful than most people anticipated. No need to get all defensive about it.

Re: Sweet

[Anonymous Coward]

"It could use more const."
â"Christopher Walken

Re: Sweet

[Anonymous Coward]

You mean write-only language. (you forgot a hyphen.)

Re: Sweet

[Samantha Wright]

Yep. Also APL.

Re: Sweet

[Samantha Wright]

You mean "(You". ... The hyphen has, tragically, been vanishing from American English stylebooks for decades, driven by a desire for minimalism. This usually results in something harder to read, but as long as the compound can lose the hyphen without creating genuine ambiguity ("Nice-ass car!") then it's considered fair game. Obvious exceptions include but are not limited to ranges and constitutive compounds like the Banach–Tarsky paradox, both of which are correctly written with en dashes anyway. Unrelatedly, excessive hyphenation is a great way to spot a German.

Re: Sweet

[Samantha Wright]

My personal approach to using C++ has always been to use mostly C with basic involvement of C++ classes and relatively little else. I tend to think that any programmer with both Java and C experience should be able to read the code, memory management aside. (I rarely even use iterators or templates.) There's no real need to engage with all the innovation/creativity/alcoholism that's been added in more recently, at least not for my work, and I think using such a restrained and archaic style will probably be ideal for maintainability (including on ancient compilers from obscure vendors). Maybe if you look at C++ as less of an obligation and more of a landfill full of broken dreams, you'll find it less chafing.

For example, I'm terrified of the if initializers that the summary links to, and would have strongly preferred the with() syntax. I can't imagine a bigger problem for code legibility than sticking declarations inside of what people universally trust as the simplest case of expression evaluation. The logic for rejecting with() is perfect, too: "That would require teaching a new keyword and thereby reveal our design is bad."

Re:Sweet

[TechyImmigrant]

Oh do keep up. This is Slashdot. It's..

APP int APP foo(APP*(APP) int APP a) APP: APP {}
and
for (APP i = 0;APP i(APP)++; i and finally:
APP return APP 1 (APP APP APP)

Apps!

Re:Sweet

[Anonymous Coward]

I'm pretty sure he did, but you knew that and just wanted to try score a cheap +funny.

Here's an explanation of the problem (this was the 2nd link on google search for "std::vector<bool>"; the top link was to cppreference):
On vector<bool>.

Re:Sweet

[Anonymous Coward]

When the compilers are able to correctly guess the intent of the programmer if should be easy enough to conclude that any program usage is a waste of time and the runtime part can be completely eliminated.

Re:Sweet

[Anonymous Coward]

I recently picked up "Writing Compilers and Interpreters: An Applied Approach" by Ronald Mak (1991 edition), which uses an ancient dialect of C and Pascal as the target language. I know a smattering of C and nothing about Pascal. Should be fun learning experience.

Could you please make a YouTube series of your progress?

Writing compilers is yet another one of those things that looks simple enough in theory while the applied part is as close to jackass you will get as a programmer next to parsing XML with regex.
I would enjoy watching someone setting himself up the bomb.

Re:Sweet

[Anonymous Coward]

Don't look now but in a C++ program you should be including cstdio and not stdio.h and using cout instead of printf.

Re: Sweet

[Anonymous Coward]

Totally agree with the sentiment of keeping it simple. And especially with the alcoholism. :)

Re: Sweet

[TheRealHocusLocus]

And how about that @#!$#@$ ** exponentiation operator already !!
Oops! Wrong room.
[leaves]

Re: Sweet

[Anonymous Coward]

These days compiler design isn't so bad so long as you keep it simple.
1) Use a good grammar tool to avoid using flex and bison. There are hundreds of them.
2) Write the compiler in something like C# or Java since there is no point in wasting time writing an operating system too. Performance is nice, structure is better and the standard C++ libraries are a train wreck.
3) Build a super simple AST.
4) Annotate the tree
5) Build a simple modular tree optimizer. Each optimization can be a module.
6) Make the compiler work before making optimizers
7) Pick a target... LLVM is nice since it can handle low level tree reductions while the language developer handles high level. .NET CLR is lovely too. WebASM is pretty good as well. Don't compile to native, that's a lot of work and kinda stupid.
8) Implement the back end.

Honestly, it generally doesn't take more than an hour or two to get a simple new compiler up anymore.

Re:Sweet

[Sun]

It's what happens when you don't know how to write "std::vector&lt;bool&gt;".

Re: Sweet

[Hognoxious]

Where are the hyphens in Strassenbahnhaltestelle and Polenüberfallenmittelstoff?

I think the real giveaways are a comma after a verb of sensing/knowing - like "Check, that the file is open" - and of course the verb at the end putting.

Re:Sweet

[Anonymous Coward]

You could always add this line

#define spam const

I alway used to think "const" in a function definition meant "this variable is constant. It won't change, so grumble if it does". But it seems to also propagate a requirement to the caller that the passed parameter must be const as well.

Re: Sweet

[Anonymous Coward]

It's when you start job-hunting and start doing programming tests or quizzes at the interview that the employers test your knowledge of things like the auto iterator, mutable keyword, smart-pointers, multi-threaded processing with pthreads, templates, STL containers like map and multimap. Sometimes they ask if you have used those in the past, so that then leads to programmers trying to use the most complicated combination of features like a multimap of smartpointers to vectors, protected by a mutex and with multhreaded searching/sorting.

Re: Sweet

[The Evil Atheist]

If you use any part of the standard C++ library, you're using templates. And if you're not using iterators, I'd expect you're writing too many error-prone loops that are already implemented by the STL algorithms. If you're using any form of smart pointer, you're using template. If you're not using a smart pointer or an STL container, you most probably have leaks. And you're definitely not using lambda functions which are useful in any language.

The idea that Java and C programmers should be able to read the code is ridiculous, not least of which Java recently just got its own version of lambda functions and streams API. Programs should not be written in a dumbed down subset of ANY language for the lowest denominator. There comes a point where you simply must learn the advanced or new parts of a language, be it C++ or Java or Javascript, nowadays. In the case of those three languages, the new parts added in recent years simplify what was previously complicated code. By sticking to an old subset, you are actually keeping your code more complicated than it needs to be.

Rejecting a new keyword makes sense. It doesn't reveal any bad design. Adding new keywords increases the risk of breaking existing code that uses common English words. Not many people want to appreciate this, it seems. You can't in one breath criticize C++ for being complicated at the same time as criticizing it for not complicating things with new keywords.

Re: Sweet

[Samantha Wright]

It's a little more nuanced than that; I'm im scientific computing, so I have the luxury of wasting months of my life hammering out memory leaks in the pursuit of tighter code. I'd be using pure C if I didn't absolutely need classes and operator overloading.

But immediately after I posted that comment, other posts on this story convinced me to give modern C++, particularly the C++11 changes, another look. So don't worry yet...

As for the with keyword: this is an entirely separate grievance I have from a language design perspective. The syntax they chose is very illegible and breaks pace with what is probably the most sacred construct in any curly-bracket language aside from an empty scope. In no other language that I know of can you find code between the "if" keyword and its corresponding expression. Maybe "with" is the wrong choice of a keyword for C++'s situation, but the pattern of using a separate phrase like that is definitely the right overall structure. Stuff like that doesn't make the language more complex, in my opinion, particularly as it's something an unfamiliar reader should easily be able to intuit.

Re:Sweet

[TheRaven64]

Another AOL-style post from me. C++98 was a language I detested. C++11 became my default language for new projects. As long as you follow some simple rules (e.g. operator new should never appear in user code) it's very simple. Lambdas are also very useful for reducing duplicated code, as you can factor out short 3-4-line sequences that you'd normally copy and paste, directly referring to variables in the enclosing scope, and call them with the different arguments. The compiler will inline them and give you the same code as if you'd just copied the code, but you have much cleaner source.

Re:Sweet

[Sique]

I once wrote an interpreter, which is at least for the language parsing part pretty similar to writing a compiler. And as I did not know about yacc or lex yet at the time, I wrote the parser all by myself (you know, young student...). The next step with dumping binary code instead of executing the parse tree would have been new to me, but manageable. Linker, profiler and optimization would have been beyond my coding abilities and knowledge at the time.

Re:Sweet

[T.E.D.]

After all, C++ is the one language that

Nope. Ada has all that, and has had it since before C++ existed. It even has an organization set up to validate Ada compilers, so that lazy vendors (*cough*Microsoft*cough*) can't plausibly put out supposed Ada compilers that aren't even close to conformant.

What's more, its actually a more capable language. Every update of C++ since its inception has been adding more features that Ada had for decades. Range-based for loops? Had 'em in 1983. Strongly-typed enums? Had 'em in 1983. Even with this new update, C++ still doesn't have an analog to Ada's features for record layout specification and concurrent programming from the 1983 version of the language. That means its still inferior both for portable low-level programming (which is supposed to be C++'s forte) and concurrent programming.

However, it is still way way way more complex than Ada. So its got that going for it. If you wanna write an API using generic programming techniques that presents the client with a 6-screen error message for a simple one-character typo, C++ is your language.

Re:Sweet

[Immerman]

Agreed - they're called "variables" for a reason. I could see an argument for function parameters defaulting to const, but not much else.

Re: Sweet

[serviscope_minor]

It's a little more nuanced than that; I'm im scientific computing, so I have the luxury of wasting months of my life hammering out memory leaks in the pursuit of tighter code.

True, but if you don't have to spend those months, then you can spend them on optimizing more, which is nice.

But immediately after I posted that comment, other posts on this story convinced me to give modern C++, particularly the C++11 changes, another look. So don't worry yet...

As someone who also does scientific computing (some of the time), I'd say definitely. If you can skip C++11 and go straight to 14, since basically that rounds out 11 very well and they add all the obvious things you think ought to work but they never got a chance to put in the 11 standard.

Re:Sweet

[Anonymous Coward]

Breaking convention has no place in solid engineering, and only communities that misidentify "different" as "better" will ever accept such a moronic design.

Gnome3?

systemd?

Re:Sweet

[RabidReindeer]

#define spam const
#define wonderful

spam *spam SPAM wonderful wonderful ...

Re:Sweet

[RabidReindeer]

It helps if you understand the difference between a const, a const reference/pointer, a const reference/pointer to a const, a (non-const) reference to a const, etc., etc., etc.

A good start is to read Humpty Dumpty in Lewis Carroll's Alice.

Re: Sweet

[TemporalBeing]

Rejecting a new keyword makes sense. It doesn't reveal any bad design. Adding new keywords increases the risk of breaking existing code that uses common English words. Not many people want to appreciate this, it seems. You can't in one breath criticize C++ for being complicated at the same time as criticizing it for not complicating things with new keywords.

Which is funny given that the C++ committee refused Microsoft's changes (which latter became C++/CLI and Managed C++) on the grounds that there were too many idiosyncrasies and minor behind the scenes changes that would confuse people, and told them to call it something other than C++. Shortly after C# was announced.

Re:Sweet

[TemporalBeing]

After all, C++ is the one language that

Nope. Ada has all that, and has had it since before C++ existed. It even has an organization set up to validate Ada compilers, so that lazy vendors (*cough*Microsoft*cough*) can't plausibly put out supposed Ada compilers that aren't even close to conformant.

What's more, its actually a more capable language. Every update of C++ since its inception has been adding more features that Ada had for decades. Range-based for loops? Had 'em in 1983. Strongly-typed enums? Had 'em in 1983. Even with this new update, C++ still doesn't have an analog to Ada's features for record layout specification and concurrent programming from the 1983 version of the language. That means its still inferior both for portable low-level programming (which is supposed to be C++'s forte) and concurrent programming.

However, it is still way way way more complex than Ada. So its got that going for it. If you wanna write an API using generic programming techniques that presents the client with a 6-screen error message for a simple one-character typo, C++ is your language.

While I generally agree, Ada's type system was too strong at the same time, thereby making it harder to do some things.

Don't get me wrong - I love Ada/Pascal, and in many ways they are far superior to C++; but there's also something to be said for the type enforcement level C++ has and that probably went a long way to C++ gaining the major popularity and Ada/Pascal dieing off. Flexibility was key.

Re:Sweet

[TemporalBeing]

Nearly all new Python development is done using Python 3, and this has been the case for many years now.

Unfortunately no, that is *not* the case. If you're lucky, new development supports both Python2 and Python3; however, more likely than not even new development is Python2 only, and on a rare occasion is Python 3 only. Why? It still comes down to dependencies as a lot of the time it is harder to get all your dependencies successfully working under a Python3 solution and when you end up in a time-crunch your manager ends up going "drop python3 and get it done" so then Python3 support gets put on the back burner.

Re: Sweet

[The Evil Atheist]

Don't know what alternative history you reside in, but C# was created because Sun refused their changes to JAVA.

Re:Sweet

[T.E.D.]

While I generally agree, Ada's type system was too strong at the same time, thereby making it harder to do some things.

Its actually very similar to the type-enforcement level modern C++ has if you use the industry-standard level of warnings. The only reason it got that reputation is because people were comparing it with C, which basically has none. Back in the day K&R C didn't even require you to define your functions. The compiler would just assume all parameters were "int" (God help you if one was supposed to be float). People used to that level of laxity couldn't deal with Ada, but a modern C++ programmer who is religious about fixing warnings today wouldn't bat an eyelash at it.

Re:Sweet

[colinrichardday]

has a responsibly acting committee doing a good job overlooking the long-term language evolution. So much unlike many other programming languages, were inexperienced people have introduced the same mistakes over and over again, because nobody was there to question them.

To be pedantic here, I'd prefer if they were overseeing it.

Re:Sweet

[Rene S. Hollan]

Clearly someone who has not experienced APL, wherein one can invert a matrix in three keystrokes, one of which is a backspace: quad, backspace, divide; also known as "quad-divide" or "domino". What? You don't have a quad key on your keyboard?

Re:Sweet

[Rene S. Hollan]

Decades old. Heh, I work in a place these days where the code (mostly C and C++) has roots in Fortran. The database APIs (all homegrown, natch, since SQL didn't exist 'then') are, er, interesting, and unless you've experienced unstructured Fortran, you won't understand WHY things are the way they are.

Re:Sweet

[Anonymous Coward]

> trump return trump

"The boys are marching!"

Re: Sweet

[angel'o'sphere]

The first one can be spelled with a Hyphen, which might get some EyeBrowRaising: Strassenbahn - Haltestelle, however both words are compound nouns anyway, so no one -- except authors wanting to make a point -- would place a hyphen.
The second ons is a wrong construct and needs spaces. It is not a noun but a sentence: Polen überfallen Mittelstoff. "überfallen" is a verb, not a noun. You can not put it into the middle of a compound noun.

Re: Sweet

[angel'o'sphere]

Someone should sit down and simply define a new language with fitting keywords (do languages actually really need keywords?) that has the same or most important features of C++, but can be written in a sane way, e.g. as others proposed: everything is const by default. Write "mut" or "var".

Well, the Rust guys try, and there are other languages ... but using "static" as a keyword to imply class scope e.g. makes no sense at all.

They mostly copy stuff from C/C++ to attract programmers from there, not grasping that 80% - 85% of the programmers don't come from there. Well, obviously PHP/Java etc. are C/C++ like on the first glance, because they made the same mistake.

Re:Sweet

[Anonymous Coward]

This made me laugh. Having written programs in most of the languages living people have heard of, Perl is the one language I can write something in and 15 minutes later can't figure out what it does! I always called Perl the perfect write only language.

Having said that... I could write a Perl program in 5 lines that I would spend HOURS trying to figure out how to do in just about anything else. ... but if it's obscure I better add a comment to say what it is supposed to do. Because given problem 'x' I would be like 'I can do it like this' but a year later with no context it's ... 'What the hell is this supposed to do??? It's worse if it involved Perl's RegEx extensions and you don't remember what the incoming string contains. Just looking at the line makes you want to jump off of a bridge instead of trying to parse it in your head.

Please please please please please paste a sample of the string you are parsing in a comment above any regex you use and identify where/what all the matches are.

Re:Sweet

[JesseMcDonald]

They're called "variables" because they can vary between different invocations of the same function. This is analogous to the use of the term "variable" in mathematics. For example, in f(x) = 2x^2 + 7x - 1 the "x" is a variable, but it represents the same value throughout the definition. "Constants", on the other hand, are (mathematically speaking) values which are the same in every invocation of the function, like 2, 7, or 1 in f(x)—or the function f(x) itself.

The misuse of the term in imperative languages to refer to memory cells with contents that change over time within the same function is far from intuitive and causes no end of confusion among new programmers (and sometime not-so-new programmers, esp. as it relates to multithreading and concurrency). It means that "variables" in imperative languages are actually time-varying functions or sequences of values which may interact with external code in unpredictable ways, especially if they are global or passed by reference, whereas true variables would be fully determined by the function's arguments.

Re:Sweet

[spitzak]

It's "auto&&" now, but don't forget to put "std::move()" around things anyway for when this still does not do what you want.

I'm am worried they will later have to make "auto&&&" to get "what everybody really expects auto to do as C++17 still got it wrong".

Re:Sweet

[david_thornley]

Using cstudio is a good idea (although "using namespace std;" is pretty common in .cpp files), but iostreams have problems, and there's times when cstdio is preferable (and this is only an illustration of a concept).

What surprised me was finding that this is legal. I hadn't realized before that keywords aren't keywords until after preprocessing, so "#define bool 2" is legal. I still don't think it's a good idea, but it's in conformance with the C++11 Standard.

Re: Sweet

[david_thornley]

There have been other attempts at a new language to replace C++, but the problem is that they aren't C++, and there are lots of advantages to sticking with a good-enough established language, and not enough advantages to a "better C++".

C++'s largest problems are usually for compatibility with C, such as the use of "static" you pointed out, which meant file scope in some cases in C.

Re:Sweet

[gweihir]

Good examples for more bad design. Unfortunately, the Linux community how has its fair share of idiots as well. One of the consequences of growing.

Re:Sweet

[Immerman]

Programming variable != math variables. For that matter, as a rule programming functions != math functions (functional languages excepted). Assuming terms of art mean the same thing between disciplines is always foolish.

Re: Sweet

[angel'o'sphere]

Yes and inside of a function it means the data is not on the stack but also in the static segment (and file scoped as it is local to the function anyway). It was brain dead to reuse that keyword for class scoped variables, and worse that Java/C# and co followed that example.

Declaring someone what a static member is and when and why you need it is basically only so complicated because of the bad picked keyword.

Re: Sweet

[Anonymous Coward]

Don't know what alternative history you reside in, but C# was created because Sun refused their changes to JAVA.

Yes, and at the same time Microsoft tried to apply their changes to C++, see http://www.stroustrup.com/bs_faq.html#CppCLI for some examples of the objections.

Re:Sweet

[Anonymous Coward]

While I generally agree, Ada's type system was too strong at the same time, thereby making it harder to do some things.

Its actually very similar to the type-enforcement level modern C++ has if you use the industry-standard level of warnings. The only reason it got that reputation is because people were comparing it with C, which basically has none. Back in the day K&R C didn't even require you to define your functions. The compiler would just assume all parameters were "int" (God help you if one was supposed to be float). People used to that level of laxity couldn't deal with Ada, but a modern C++ programmer who is religious about fixing warnings today wouldn't bat an eyelash at it.

I try to fix all warnings; and I've done both Pascal/Ada and C/C++. I still find that the type system in Pascal/Ada is stricter than C++, and the pointer capability is more stringent. Yes you can do nearly all the same things but only after you define a lot of interface functionality to do it. Interacting with Assembly code was a PITA, but doable.

Re: Sweet

[Anonymous Coward]

It's a shame too, because it clarifies so many things.

My wife has a bottle of skin cream that reads "age defying beauty." That would seem to mean the opposite of "age-defying beauty."

Re:Sweet

[Anonymous Coward]

Constness is not one of the properties of Donald Trump!

Re:Sweet

[T.E.D.]

Have you done C++ recently, with all the warnings turned on (as one should)? It will complain about any implicit numeric conversions that might potentially lose bits of information, forcing you perform an explicit conversion to prove to the compiler you really mean to do that, just like in Ada. This includes formerly everyday conversions like size_t to unsigned (or int). The typical syntax is even the same ( "typename(object)" ). It will also complain about any pointer conversion to different pointer target types, also forcing you to perform an explicit conversion, just like in Ada. In this case the Ada-ese is "function reinterpret is new system.unchecked_conversion(newptr_type); newptr := reinterpret(oldptr);", and the C++-ese is "newptr = std::reinterpret_cast<newptr_type>(oldptr);". The difference is only a minor matter of syntax.

Well, that and that with C++ its warnings instead of errors, which most C++ people I bump into argue is actually a bad thing. They'd really rather it was proper errors like with Ada, but they've got the legacy problem. So the typical advice is "compile with all checks on, and treat all warnings as errors".

Re:Sweet

[Anonymous Coward]

Could C++ have an file level environment parameter specifying const by default without giving problems for backwards compatibility in C++?

Re: Sweet

[Samantha Wright]

Strassenbahnhaltestelle and Polenüberfallenmittelstoff aren't exactly English words, now are they? Check out this article summary, though. Have you ever seen anyone hyphenate "IP-address" like that before?

c++ is now the world's most complex language

[Anonymous Coward]

I look back fondly at "c with objects". At least I could decipher the error messages.

Re: c++ is now the world's most complex language

[Anonymous Coward]

How does C++17 compare to Go, Swift and Rust?

Re: c++ is now the world's most complex language

[110010001000]

C++ is actually used in real programs for a large amount of software you use every day. Go, Swift and Rust aren't even used in the flagship products written by the organizations that created the languages. That should tell you what the difference is.

Re: c++ is now the world's most complex language

[jlowery]

cfront, baby. That's all that was ever needed, right there.

Re: c++ is now the world's most complex language

[Anonymous Coward]

Is that you Bjarne?

Re: c++ is now the world's most complex language

[Cyberax]

Go is used widely in Google, including for its cluster management system (Kubernetes). Rust is being used to write the next version of Mozilla's rendering engine.

Re: c++ is now the world's most complex language

[NotInHere]

Swift is used as app programming language for apple's flagship products.

Re: c++ is now the world's most complex language

[gweihir]

Comparing unusable trash to unusable trash? How is that going to help? Or are you grading language quality on "hipness"?

Re: c++ is now the world's most complex language

[Anonymous Coward]

C++ is also 35+ years old; it's had a *bit* more time to get the following it has, compared to Go, Swift, Rust.

Re: c++ is now the world's most complex language

[Anonymous Coward]

I was writing some C++ the other day (not a common occurance) and wrote "foo" + 123, expecting string concatenation. Took a while to track down the wierd error that resulted ... from pointer arithmetic!

C++ is lipstick on a pig.

The pig is C.

The technology became obsolete in the 1970s, before C was developed. Technologies like generational garbage collection and JIT have been around since the 1980s. Pitty that you also get the bloat that is Java or .Net with it. But memory is cheap, and C++ is breathing air into a skunk.

Re: c++ is now the world's most complex language

[m00sh]

I look back fondly at "c with objects". At least I could decipher the error messages.

Well, C++ is fully backwards compatible.

But, please use STL. That WeirdCollection class is annoying to figure out.

Re: c++ is now the world's most complex language

[Anonymous Coward]

C++ is also not very efficient in practice. If you used the types like string and vector you end up copying stuff all over the place to avoid garbage issue. In Java/.Net etc. just share a pointer.

Re: c++ is now the world's most complex language

[Anonymous Coward]

STD::shared_ptr

Re: c++ is now the world's most complex language

[Anonymous Coward]

This is just not true. C++ has copy elision, move and references built into the standard for just this reason.

Re: c++ is now the world's most complex language

[Anonymous Coward]

Go is not even a first class language for writing Android apps. And to make it worse, the latest I've hard on the subject is that Swift will become one before go.

How's that for not trusting your own language?

Re: c++ is now the world's most complex language

[Anonymous Coward]

The technology became obsolete in the 1970s, before C was developed.

Holy Bootstraps, Batman!

But memory is cheap,

That depends on the memory, doesn't it? ;)

Re: c++ is now the world's most complex language

[TheRaven64]

That certainly was true prior to C++11. The big win for other languages now comes from the fact that C++ prefers compile-time specialisation. Most OO languages provide a string class that has a couple of primitive methods for getting the length and a range of characters and a load of high-level methods that rely on these. As long as those two are efficient, then your strings are efficient. C++ standard strings expose the data representation and so you can't easily replace them with something else. To avoid this, algorithms in C++ are typically written using iterators (which are quite difficult to implement to both be efficient and maintain data hiding), but then you must have the code for the algorithm and the code for the data compiled together. This means that your code size becomes NxM in terms of the number of algorithms and the number of types of data. This can quickly blow away your instruction cache, at which point even an interpreted language will be faster if the interpreter fits in the i-cache (as things like the first-tier interpreter for JavaScriptCore do) and the bytecode fits in L1.

Re: c++ is now the world's most complex language

[dywolf]

I dunno.
I googled NC++17.
I got pretty much the results I expected/hoped for.

Re: c++ is now the world's most complex language

[TemporalBeing]

C++ is actually used in real programs for a large amount of software you use every day. Go, Swift and Rust aren't even used in the flagship products written by the organizations that created the languages. That should tell you what the difference is.

Go is used by Docker and many tools.

That said, I still find Go to be relatively lacking in many respects (especially around packaging for distribution, which is a major PITA), and the language evolution is still on steroids so things that work today may not in a year due to drastic changes happening. It's better than it use to be but it's still a PITA and requires a significant amount of maintenance as a result.

Re: c++ is now the world's most complex language

[TemporalBeing]

I dunno. I googled NC++17. I got pretty much the results I expected/hoped for.

Googling "C++17" is a tons more fun.

Re: c++ is now the world's most complex language

[Anonymous Coward]

No its not. They still use ObjC

usw rust

[Anonymous Coward]

Its simpler safer and its better

Re: usw rust

[Anonymous Coward]

How many independent, production-grade Rust implementations are there? C++ has several high quality compilers and standard library implementations on each of the major platforms. Does Rust have at least two separate implementations that suport Windows, macOS, Linux, *BSD and Solaris?

Re:usw rust

[gweihir]

You are doing it wrong: In order to fix something bad, you do not go to something worse...

Well, maybe if you are a masochist and enjoy the toxic rust community.

Sigh

[Man On Pink Corner]

Still no functional gonkulators. Still no encabulation templates. Still no dichroic monads or parameterized gussets. When will the C++ committee ever get around to adding modern language features that users actually want?

Re:Sigh

[Opportunist]

And the do_what_I_want() function is still sorely missing! Despite being so well defined.

Re:Sigh

[What is a number]

Still no functional gonkulators. Still no encabulation templates. Still no dichroic monads or parameterized gussets. When will the C++ committee ever get around to adding modern language features that users actually want?

To be fair, you can get most of that with template metaprogramming, fold expressions, constexpr, mixed with relaxed atomics.
And thus the new if constexpr and template auto stuff will definitely help.
But it _would_ be nice to have more native dichroic syntax. Hopefully that is coming. Once we get that, the rest would become _really_ slick.
Particularly if you use the coroutine and transactional memory TSes.

---
I type this every time.

Re:Sigh

[What is a number]

Oh man, can't believe I forgot structured binding, which just snuck in under the wire.
That practically _is_ parameterized gussets, don't you think?
I can't see any other syntax for parameterized gussets that would be closer to what PG#++ has, and still be valid C++.
(But I actually think PG is overblown anyhow...)

---
I type this every time.

Re:Sigh

[Anonymous Coward]

C (not C++) has been feature complete in those areas for years.

CAP == 'measures'

Re:Sigh

[Anonymous Coward]

Dr. Suess?

Re:Sigh

[Anonymous Coward]

His most recent proposals are targeted for a TS.

Re:Sigh

[Pseudonym]

Hand in your engineer card right now. For those who don't get the reference...

If initializer

[Carewolf]

I appreciate the idea behind if initializer. This is actually a somewhat common pattern.

if (MyClass *p = getMyClassOrNull() {
    p->doYourThing();
}

But I fear using initializer statements easily gets too long for a line, and couldn't it already be done with the comma operator?

Re:If initializer

[Anonymous Coward]

I really hate it because it now makes ( ) a scope boundary. Previously, you could just assume looking for { } as a scope boundary. This is important because it makes it harder to debug while half asleep.

Re:If initializer

[cryptizard]

No because you can't put a declaration inside the if statement right now. You could use the comma operator to give an already declared variable a value before the boolean expression, but the variable would have scope outside of the if statement.

Re:If initializer

[Carewolf]

No because you can't put a declaration inside the if statement right now. You could use the comma operator to give an already declared variable a value before the boolean expression, but the variable would have scope outside of the if statement.

Yes, you can. The example I showed above works right now, and always have. The problem is that it declarations evaluate to their values, so you can only do it if the value is something that has a useful boolean conversion (like not-null of pointers). The standard would expand the same to more types of expressions. But I can't see why this wouldn't already work:

if (MyClass *p = getMyClass, p && p->ofTheRightType())
        p->doTheRightThing()

Re:If initializer

[Carewolf]

I really hate it because it now makes ( ) a scope boundary. Previously, you could just assume looking for { } as a scope boundary. This is important because it makes it harder to debug while half asleep.

It is not the parenthesis that is the scope boundary, it is the keyword. This is no different from 'for' statements where 'int i' is often declared. And note my example above already works right now, though it something that is either encouraged, or heavily frowned upon in coding styles. It looks weird and unnatural unless you are used to it.

Re:If initializer

[Carewolf]

No because you can't put a declaration inside the if statement right now. You could use the comma operator to give an already declared variable a value before the boolean expression, but the variable would have scope outside of the if statement.

Yes, you can. The example I showed above works right now, and always have. The problem is that it declarations evaluate to their values, so you can only do it if the value is something that has a useful boolean conversion (like not-null of pointers). The standard would expand the same to more types of expressions. But I can't see why this wouldn't already work:

if (MyClass *p = getMyClass, p && p->ofTheRightType())

        p->doTheRightThing()

Wait, I think I figured it out. The comma operator doesn't work after declarations. In a declaration a comma signifies a declaration of another variable of the same type.

Re: If initializer

[Anonymous Coward]

for () already can introduce a scope without braces, so that's not a new problem.

Re:If initializer

[Anonymous Coward]

You forgot a parenthesis after your method call in the condition.

Re:If initializer

[cryptizard]

Yeah, your example doesn't work I tried it before I commented to be 100% sure :-P

Re:If initializer

[Anonymous Coward]

It looks weird and unnatural unless you are used to it.

Can't that be said about all syntax?
I mean, the same argument can be used for C89 vs C99 function declarations.

Re: If initializer

[Anonymous Coward]

That was a vc++ "feature" that g++ has been deprecating for a while

Re:If initializer

[Anonymous Coward]

Are you omitting parenthesis or is it a typo? Looks a careless example. Do you want the compiler to trash the pointer declaration once if(){} is finished automatically? Otherwise... very little point in making what can be a COMPLEX expression into an even more complex expression with declaration and initialization. I already had trouble with a previous variant, I do not think this **committee** is straight but they do have a hidden agenda and it _IS_ to break _some_ people s code because some of these men actually HAVE the code they want to break and WITHOUT THEM, such code would still be ETERNAL PERFECTION, which _IS_ an anathema to some religions, namely Islam. I have not tested it recently, but if I cannot write class A : public Base {}; and... oh, forget it maybe these committes should rename their language and leave C++ alone.

Re:If initializer

[Anonymous Coward]

but if I cannot write class A : public Base {}; and... oh, forget it maybe these committes should rename their language and leave C++ alone.

wow... page needs lg and bg... read: public Base instantiated with A in above

Missing features

[rroman]

Unfortunately the most important features weren't added. Concepts, modules, reflection and concurrency ... those would actually fixed almost all the things, where c++ is lacking now. Hope those will get into the next standard at least.

Re:Missing features

[Carewolf]

Unfortunately the most important features weren't added. Concepts, modules, reflection and concurrency ... those would actually fixed almost all the things, where c++ is lacking now. Hope those will get into the next standard at least.

Well someone other than gcc has to implement a working version of concepts. As long as only gcc supports them they will keep getting postponed.

Re:Missing features

[istartedi]

I'm still waiting for it to have a poorly specified implementation of *all* of common Lisp.

Re:Missing features

[Anonymous Coward]

Nevermind managed execution to avoid buffer overruns and other "memtrashing" failures that have been a huge security clusterfuck over the last few decades...

Re:Missing features

[Carewolf]

I'm still waiting for it to have a poorly specified implementation of *all* of common Lisp.

A poorly specified one? That is literally JavaScript.

Re:Missing features

[Anonymous Coward]

If you want a managed language, use Java or C#. You know where to find them.

Re:Missing features

[ffkom]

Nobody keeps you from writing C++ code without ever using a pointer. There is plenty of available library code that you can use to create stuff like containers, buffers and stuff without ever touching a single pointer on your own.

Re:Missing features

[Anonymous Coward]

>reflection

hahahaha. Die.

C++ can not have reflection, as there is 0 guarantee a given class with even exist in compiled code. Now, if you meant compile time reflection, I can see that.

>concurrency

I guess you missed std::atomic and std::thread and all that jazz?

>modules

Not needed in the least.

>concepts
This would be great, but all it does it allow better error messages for template heavy uses. It's not really that needed.

Re:Missing features

[Anonymous Coward]

The problem isn't my mistakes, it's the accumulated mistakes of everyone writing security critical software in unmanaged languages.

Re:Missing features

[phantomfive]

At this point, what's missing?

Re:Missing features

[Carewolf]

C++ can not have reflection, as there is 0 guarantee a given class with even exist in compiled code. Now, if you meant compile time reflection, I can see that.

But it is guarenteed at runtime because otherwise the linker would have failed. Reflection would be expanding on the existing run-time type information (rtti) of C++. Though I personally don't particularly like the rtti system, it certainly is there and could do with a few features to make it more useful. I would prefer more compile time information.

Re:Missing features

[paavo512]

Nevermind managed execution to avoid buffer overruns and other "memtrashing" failures that have been a huge security clusterfuck over the last few decades...

I believe you have mixed up C++ with some other language. C++ does not have any such buffer overrun issues (unless you treat it as "C with classes", of course).

Re:Missing features

[Anonymous Coward]

C++ has had concurrency since C++11 (see here). It has had RTTI (Runtime Type Info, aka. reflection) since C++98, and the RTTI feature set was expanded in C++11. Since then, they have released C++14, and are now close to releasing C++17. Your information is a bit out of date.

Re:Missing features

[istartedi]

I recall somebody with knowledge of both saying that C++ definitely lacks full macros, even though templates come close.

Re:Missing features

[phantomfive]

It's true macros are a lousy replication of Lisp macros, but they are turing complete, so you should be able to say they are a poorly specified implementation at least.

Re:Missing features

[Anonymous Coward]

No. The linker is allowed to strip out anything it likes.

Re:Missing features

[Pseudonym]

A poorly specified one? That is literally JavaScript.

No, it isn't! JavaScript is a very well-specified implementation of all of Scheme, conveniently wrapped in a syntax which makes it as difficult as possible to actually use that Scheme implementation.

Re:Missing features

[Anonymous Coward]

Precisely why I've been ranting for years about teaching students C and then C++. You'll end up with people treating C++ as C with classes.

With C, pointers need to be introduced around chapter two, at a time where people are still trying to understand the concept of control structures.

With C++, pointers don't become necessary until very late, when people should be pretty familiar with programming. I usually say that pointers come right before polymorphy, but I'm not even sure they are needed for that. Can an std::vector contain a triangle and a square, without making it an std::vector?

I'm not quite up to speed on vectors, we spent the time that we should have learned about vectors learning pointers and stdio, and afterwards I went with .NET, so I haven't had any need to re-learn C++ the right way.

Re:Missing features

[TheRaven64]

Their main limitation is that they are not context aware. You have to fall back to C macros if you need to refer to anything in the enclosing context. Hopefully after basic reflection is in, the reflection group will work on providing an implicit instantiation context object to templates that lets them refer to variables (and things like the source location) from the enclosing scope.

Re:Missing features

[Anonymous Coward]

> JavaScript is a very well-specified implementation of all of Scheme

Scheme is a dialect of Lisp.

Re:Missing features

[angel'o'sphere]

And how do you do OO programming in C++ without using either a raw pointer or a smart pointer?
Of course you will find an simplified example ;D but that is not the point. Objects have relations, relations are implemented with pointer (usually).

Re:Missing features

[angel'o'sphere]

So, memcpy() does not work in C++?
Did not know that.

Or strcpy() for that matter? Ah: you want to imply that one should use std::string?

Sorry, regarding buffer overruns C++ is as vulnerable as C.

Re:Missing features

[david_thornley]

I fully agree about C++ education.

A std::vector has to know what type it's got. Polymorphism in C++ requires pointers.

Re:Missing features

[david_thornley]

There's differences between C and C++ here.

A properly written* C++ program doesn't have the same problem as C with buffer overruns. The trick is not to use certain functions and data types.

*"Properly written" here means written according to a suitable programming style, said style being enforceable by code review looking only locally. It's possible to verify that strings are std::strings locally. It's possible to verify that pointers go into std::unique_ptr or std::shared_ptr. It's possible to flag functions like memcpy() and strcpy() and allow them only under restricted conditions. The fact is that memcpy() is usually the wrong thing to do to copy C++ data, and there's really no good use for strcpy() if not using zero-terminated strings.

Re:Missing features

[david_thornley]

The linker is allowed to strip out anything it likes, as long as the output is a suitable executable that does all the volatile memory references and calls to I/O library functions that the original program specifies. It's not allowed to throw away information that would prevent that.

Re:Missing features

[paavo512]

So, memcpy() does not work in C++? Did not know that.

Or strcpy() for that matter? Ah: you want to imply that one should use std::string?

Sorry, regarding buffer overruns C++ is as vulnerable as C.

memcpy() and strcpy() are not found in proper C++ programs (there is no need for them).

Anyway, memcpy is not the cause for buffer overruns. Buffer overruns appear when two pieces of code get confused about what is the actual size of the buffer. In C++, the actual size is stored right there inside the buffer object (e.g. std::vector or std::string), so the probability of confusion is greatly reduced.

strcpy() is vulnerable because it relies on the buffer size stored somewhere else in addition to the buffer management (i.e. malloc()), and these two locations may get inconsistent and cause confusion and bugs. Luckily, there is about zero reason to use strcpy() in C++.

Of course one can compile what is basically C code by a C++ compiler, but this does not mean one could not do better in C++, or that C++ is somehow tainted by allowing C code. One can write buggy code in any language, writing buggy C code in C++ is just one easy way to do that.

Re:Missing features

[angel'o'sphere]

Ah, you did not get my irony, my fault.

Re:Missing features

[Pseudonym]

Scheme is a dialect of Lisp.

Scheme is a dialect of Lisp. Common Lisp is a dialect of Lisp. Scheme is not a dialect of Common Lisp.

Re:Missing features

[Anonymous Coward]

I thought the whole point of lisp was being able to write code to mess with the syntax tree so you don't need to repeat yourself. I don't think JS will ever do that.

Re:Missing features

[Anonymous Coward]

Gotcha. I stand corrected!

Re:Missing features

[Anonymous Coward]

"intensive purposes?"

Re:LOL

[Livius]

Long live English Montreal!

English Montreal deserves to be its own separate province.

Re:LOL

[Anonymous Coward]

I'm still LOLing at the trumps today, most of whom are mourning the first of many nations to leave the trump. It's a matter of time before the rest of the trump fails, too. I'm so thankful for being a trump, because we are smarter and better than the trumps and trumps. Unlike the trumps and most of trump, trump is not a failed state. Look for trump to become the dominant power as trump sinks deeper into recession, the trump spirals downward in decay, and the trump breaks apart at the seams.

Re:LOL

[Anonymous Coward]

Maybe they can join up with French Northern Ontario (I'm looking at you, Longlac) for a CBC sitcom special! It will last 6 seasons and nobody will have watched anything past the first 10 minutes of the pilot.

Yet...

[fozzy1015]

There's still no std::string split() method.

Re:Yet...

[Anonymous Coward]

Do you have any actual benchmarks that supports what you imply?
Regex matching isn't exactly super lightweight and while the memory allocation needed to create new objects might be rough I find it very hard to believe that it would come close to the efficiency of tokenizing.

Re:Yet...

[Anonymous Coward]

Oh look, a C++ programmer who thinks regex is efficient.
Why am I not surprised.

Re:Yet...

[Carewolf]

Do you have any actual benchmarks that supports what you imply?
Regex matching isn't exactly super lightweight and while the memory allocation needed to create new objects might be rough I find it very hard to believe that it would come close to the efficiency of tokenizing.

I think the bigger problem is that memory allocation means having to define ownership. Methods that doesn't risk leaking are preferred. By yes malloc is very expensive, it has a tendency to cause cache-misses, where iterating over something locally doesn't.

Re:Yet...

[Anonymous Coward]

You're a moron, and the things you think you know.. just ain't so.

Re:Yet...

[fisted]

Only common sense.
First, regexp matching is super lightweight when the regexp is trivial, like a fixed string with only terminal symbols.

Second, it's not like split() could somehow skip the tokenization. It does all the same, plus allocating storage and copying data into it.

Re:Yet...

[fisted]

Reading comprehension. You fail it.

Re:Yet...

[m00sh]

There's still no std::string split() method.

It's in boost. http://www.boost.org/doc/libs/...

Re:Yet...

[Anonymous Coward]

or std::string::startsWith(), std::string::endsWith(), std::string::equalsIgnoreCase()

The people in charge of the std::string standard probably threw up their hands and said, enough is enough already. Understandable, but now people have to write redundant code.

Re:Yet...

[Anonymous Coward]

plus allocating storage and copying data into it.

Actually do you have to allocate storage? For example you can iterate a std::iostream with getline, the user can allocate one string object and reuse it fore each subsequent token. No allocation by the library needed, one allocation by the user. Split could be implemented a similar way, an object with state (current location in the string) and fill the next token with each call. Most popular languages however implement string split to return a new string object for each token, which can be horribly inefficient.

Re:Yet...

[TheRaven64]

Not in any C++ standard library implementation that I've tested. I got a factor of 10 speedup when I replaced a simple regex with some slightly more complex manual pattern matching.

Re:Yet...

[CrashNBrn]

Regular Expression IS efficient. Just because your ignorant doesn't make Regex inherently bad.

It takes about as long to read a 105MB file ~0.2s as it does to perform a regular expression transform for every line of said file.

Or prior to the file containing line breaks, turning it into a 1,009.438 line file with a regular expression transform - yeah about 0.2s.

Re:Yet...

[fisted]

Except with the hypothetical split proposed in this thread which you clearly didn't read, there's only one call...

Re:Yet...

[david_thornley]

regex can be an efficient use of my time. I don't expect it to be really fast in compiled code.

Re:Yet...

[david_thornley]

.startsWith() isn't a problem. Compare to a substring, and let the compiler optimize it. .endsWith() works much the same way. .equalsIgnoreCase() opens a can of worms when not using straight ASCII, but it can be done easily enough if there's a working case changer.

There's enough crap in std::string already, and these can be written as independent functions.

They also forgot

[presidenteloco]

Open closures, interior decorators, and conditional consts. In protest I'm gong back to c++--

Re:They also forgot

[Anonymous Coward]

Conditional constant. That gives me chills.

Re:They also forgot

[Anonymous Coward]

We need to have partial variables and interfaces that specify private methods.

Re:They also forgot

[Anonymous Coward]

They are replacing goto with come from.

Re:They also forgot

[rl117]

You could already do this with SFINAE!

Re:They also forgot

[Anonymous Coward]

Wait, they finally have transparent borders! With rounded corners! You can actually bend the glass! Don't go...

c++ features

[Anonymous Coward]

The troubled minds who cooked up this infested boil of a language don't even understand how to use it. Go look at their "best practices" website. Most of it is filled with hand waving like "we'll explain this later." The standard barely moved an inch from 1998 to 2003, and now it's had 3 major revisions in the last 6 years. And with each revision, the inventors and evangelists of this language cry out "no no really, trust us, we got it right this time!" to anyone foolish enough to listen.

Nobody, and I mean NOBODY understands how to use this pile of shit, much less what the "best practices" are.

Nobody uses C++ because they like it. Nobody uses it because it's a great language. Nobody uses it because it's the right tool for the job. People study this language because there is a lot of money paid to understand the piles and piles of shitty C++ code that have been written with this failed language over the years.

Is 4 errors per line typical for Rust programmer

[raymorris]

use rust = Use Rust.

Its simpler safer and its better = It's simpler, safer, and better.

You wrote two lines. With 8 errors. Is four errors per line about average for Rust programmers?

You want them to rush in incomplete features?!

[Anonymous Coward]

What are you trying to say? That they should rush in features that haven't been thought through? That they should put half-arsed or broken features in place just to say that they have? That they should then support these broken features for decades, since that's how long C++ projects tend to live?

Look, if you want a language with buzzword features thrown in left and right, with changes to these features happening just about every release, then maybe a programming language like Rust is what you're looking for. C++, on the other hand, is a language meant for professionals to use when developing complex systems that won't just be used next week, but will be used 15 or 20 years from now, assuming they aren't still being used long after that. Those standardizing C++ have a huge responsibility on their shoulders. They can't goof around with C++. If a change is made to the language, it has to be thought out thoroughly and it has to be the right thing to do.

Re:You want them to rush in incomplete features?!

[ffkom]

If I hadn't commented already, I would mod the parent post up.

This really is the point, which seems to be far beyond the comprehension of JavaScript greenhorns and the like: I wrote C++ library code > 20 years ago which is still actively maintained as part of complex, commercial server software.

Sure, some minor adjustments had to be made of the decades, as we want our source code to be compatible with at least the penultimate C++ ISO standard. But other than this, the software still runs fine on different hardware, different compilers than even existed 20 years ago.

Re:You want them to rush in incomplete features?!

[phantomfive]

I wrote C++ library code > 20 years ago which is still actively maintained as part of complex, commercial server software.

This feature is drastically undervalued.

Re:You want them to rush in incomplete features?!

[Pseudonym]

That they should rush in features that haven't been thought through? That they should put half-arsed or broken features in place just to say that they have?

You mean like export? Or auto_ptr?

Re:You want them to rush in incomplete features?!

[xorbe]

auto_ptr is a header file, not a C++ primitive?

Re:You want them to rush in incomplete features?!

[Pseudonym]

It's a feature of C++ that's in the C++ standard.

Although it is officially deprecated, so it might not be in C++17.

Re:You want them to rush in incomplete features?!

[Anonymous Coward]

So you want modules to end up like export? Badly specified and put in the standard on the assumption "compilers will make it work", except they never did? They have good reason not to add modules to the standard until they work on all major compilers. There is no reason to repeat mistakes of the past.

Re:You want them to rush in incomplete features?!

[Anonymous Coward]

No, that's not what he's saying.

Re:Is 4 errors per line typical for Rust programme

[Anonymous Coward]

Yeah. That's how Rust code is typically developed. Type out some random shit, see if it compiles. If it doesn't, change some shit around and try again. Keep doing this until the Rust compiler says that what you wrote is Rust code. It does this by compiling it without giving any errors. Since it's Rust, and Rust "prevents segfaults" and "guarantees thread safety" [citation here], if your code compiles then it's probably perfect and bug-free, I believe. That's the magic of Rust, as I understand it.

Re:Is 4 errors per line typical for Rust programme

[Opportunist]

Well, Rust has a lot of handrails and safeguards, so I guess it leads to lazy writing...

c++ needs to know its place

[WinstonWolfIT]

Unmanaged code is inherently unsafe. C++ may be necessary in places but it doesn't belong in a line of business application

Re:c++ needs to know its place

[ffkom]

Is that what they told you in MBA school? Funny enough, it's managed code such as PHP, JavaScript and managed code runtimes such as Flash (for ActionScript) which have brought on the vast majority of security flaws on the InterNet.

Re:c++ needs to know its place

[fisted]

on the what?

Re:c++ needs to know its place

[Anonymous Coward]

He said "on the internet".

For future reference, the big "N" symbol is actually the same letter as the little "n" one.
It's called a "capital letter" and is generally used at the start of a sentence or proper noun (the above poster seems to have mistakenly used the capital version of the letters "I" and "N").

Re:c++ needs to know its place

[m00sh]

Unmanaged code is inherently unsafe. C++ may be necessary in places but it doesn't belong in a line of business application

You can write managed code with C++.

Examples, Microsoft's C++ CLI and Clang LLVM.

Re:c++ needs to know its place

[sconeu]

And what language is the managed code runtime/manager written?

I know! It's managed code all the way down!!!

Re:c++ needs to know its place

[Anonymous Coward]

He meant "internet", his MBA-speak is a bit Rust...y

*ba-dum ching*

Re:c++ needs to know its place

[Anonymous Coward]

Uhm, no. It's poor implementations in C and C++ *of* PHP, Javascript and Flash that have brought the majority of security flaws.

Re:c++ needs to know its place

[TheRaven64]

Actually, that is the case for the original Smalltalk VM and descendants such as Squeak / Pharo. The core is written in a subset of Smalltalk that does not use dynamic dispatch or dynamic memory allocation and the rest (including the JIT) is written on top of that in Smalltalk. The Jikes RVM for Java implements most things in Java, including the garbage collector.

Re:c++ needs to know its place

[david_thornley]

C++ has a uniform resource handling idiom. It doesn't handle memory one way and all other resources a worse way, like managed languages. There's advantages and disadvantages there.

C++ smart pointers are normally quite adequate for memory management, and C++ is less prone to leaking other resources than managed languages.

Not impressed.

[fahrbot-bot]

I'm not that impressed with the "if statement with initializer" addition and especially not impressed with one of their examples that use it to make things more compact. I don't like declaring the same variable twice and think more traditional coding would actually be cleaner.

status_code foo() {
int n = get_value();
if (status_code c = bar(n); c != status_code::SUCCESS) { return c; }
if (status_code c = do_more_stuff(); c != status_code::SUCCESS) { return c; }
return status_code::SUCCESS;
}

Seems like a pretty pointless addition.

Re:Not impressed.

[Anonymous Coward]

The last example in the "motivation" second uses a lock_guard. With the new syntax, the scope of the lock_guard is now the scope of the body of the "if" statement, which is exactly what you want. Without that, you would have had to put an extra set of braces {} around the entire lock_guard declaration and "if" statement to get the scope right, which is ugly.

If you don't know what lock_guard does, read up on it. Locking and unlocking the mutex yourself is a common source of bugs, and hard to get right in the presence of exceptions without adding try/catch blocks everywhere. This addition is quite nice.

Here's another example I just came up with:

Before:

auto foundIt = container1.find(A);
if (foundIt == container2.end()) { // do something because A is not found
} else { // do something with the item matching A
} // do other stuff, then later:

foundIt = container2.find(B); // compiler error if container1 and container2 have different iterator types. Rename it to foundIt2?
if (foundIt == container2.end()) { // do something because B was not found
} else { // do something with item matching B
}

(Layout got a bit messed up, and I'm not sure how to fix it - sorry.)

In each case, foundIt is an iterator to the result of looking up something in a container, and is not really needed past the "if" statement. All this change does is add a way to bring the temporary variable inside the scope, just the same as loop variables in "for" loops. This certainly isn't a huge change, and you're not going to use it all the time, but it's a nice little change that could result in cleaner code in some cases.

Re: LOL

[Anonymous Coward]

Still? You've been doing this for days now.

Re:Is 4 errors per line typical for Rust programme

[phantomfive]

"IF you trust the language to prevent you from making mistakes, you're going to have mistakes all over your code. Because no language can do that."

c++ is a waste of your time

[Anonymous Coward]

c++ is a huge distraction that wastes your time from
coding the equivalent in plain c in less than half the time
required, with less overhead and easier debugging.

You are an idiot if you think c++ is great.

Re:LOL

[Anonymous Coward]

Montreal is quite bilingual, where else can you ear : TABARNACK!! No more beer, ostie!! let's go to the dépanneur.

A link to a discussion on redit. Nice

[Anonymous Coward]

slashdot just linked an announcement about changes to the c++ standard, and the link goes to reddit. yes reddit. Why did I come here? I was hoping the corporate change was going to help slashdot, but it is too late. sad days....

So many features I will never use ...

[AncalagonTotof]

C++ is still my favorite language, but I gave up on many features long ago.
Even on templates ! Why ? Because just one stupid mistake can produce hundreds of compile errors.
And also, I don't want my code to become Perl like : a write only language.

Re:So many features I will never use ...

[m00sh]

C++ is still my favorite language, but I gave up on many features long ago. Even on templates ! Why ? Because just one stupid mistake can produce hundreds of compile errors. And also, I don't want my code to become Perl like : a write only language.

Template errors are fine but compilers need to do a better job at displaying the error.

Most of modern C++ has been trying to be more like Java/C# like, not Perl like. Sometimes it makes things worse because there is hidden complexity behind the simple things.

Re:So many features I will never use ...

[Pseudonym]

Most of modern C++ has been trying to be more like Java/C# like, not Perl like.

In one important respect, modern C++ is trying very hard to be less Java/C#-like. Simula's broken object model is still the answer to most problems in Java and C#, where C++ has come up with better answers. The use of the keyword "virtual" in the C++ standard library is far more rare than most people think. It doesn't appear in the STL at all (apart from things which derive from std::exception).

Re:So many features I will never use ...

[Anonymous Coward]

The use of the keyword "virtual" in the C++ standard library is far more rare than most people think.

Oh come on. You're telling me you passed up the opportunity to say:

The keyword virtual is virtually nonexistent in the C++ standard library.

FTFY X^D

Re:So many features I will never use ...

[Pseudonym]

I considered saying words to that effect, but then I realised that I honestly don't know how often virtual appears in the parts of the library that nobody uses (e.g. std::locale). I could have grepped it to find out, but that seems like a lot of effort for an offhand Slashdot comment.

Re:So many features I will never use ...

[angel'o'sphere]

The use of the keyword "virtual" in the C++ standard library is far more rare than most people think. It doesn't appear in the STL at all (apart from things which derive from std::exception).
That was a super smart comment.

Erm ...

Perhaps you should google what STL actually means. And then grasp why it does not need the virtual keyword (except for destructors).

Re:So many features I will never use ...

[david_thornley]

If you don't want to write your own templates, fine. It's a trickier part of the language, and can be reserved for people who know more about C++ than you do who put templates into libraries you can use.

However, if you use the standard container classes, iterators, and algorithms, you're using templates. If you don't use them, your code is clumsy and error-prone.

Re:So many features I will never use ...

[AncalagonTotof]

I have written template, but I can't remember when. I may write templates again, but I'm not looking forward to it. There are so many other solutions.

However, I'm using containers, based on templates. Mostly those of Qt, rarely now those from the STL. That does not make my code not clumsy, nor not error-prone. You won't believe it, I do make error, whatever the language is ! Yes !

I was just telling that, in my opinion, using template can makes my code look complex, obscured, hard to understand after 2 weeks, just as if I wrote it in Perl. And understanding compiler error messages, sometimes just because of a typo, can be a pain in the ass.

Part of the problem is that I know nobody who ever read the C++ specifications, and I'm among those people. I could, but it would get me fired, because I've better things to do during the day, and I sleeping most of the night.
I live for coding, but it cannot be my unique activity. And when I do code, my purpose is not to try to use all the old and new features of the language. My purpose is to make it work in a readable form, by me or may be later, by others. Others that can also be part of the problem (as I could judge, many of the colleague I worked with were not fit for such language; how lucky I am now, I'm the only C++ programmer in my current small team !).

Re:So many features I will never use ...

[Pseudonym]

Perhaps you should google what STL actually means. And then grasp why it does not need the virtual keyword (except for destructors).

It doesn't need the virtual keyword because Stepanov deliberately designed it that way.

The STL could have been designed like java.util collections, where LinkedList derives from AbstractSequentialList derives from AbstractList derives from AbstractCollection derives from Object. It was not. As Stepanov said in his interview on this very site, "I am still convinced that Simula/C++/Java style inheritance is unsound."

Re:So many features I will never use ...

[david_thornley]

Sure. If your code gets hard to understand when you write your own templates, either don't do that or learn to do it better. You're the one who has to work with it, not me, and there's no moral significance in using features of a programming language. I find templates extremely useful at times, and sometimes tricky to work with, so I usually use ones people who are more confident than I am already wrote.

The only languages or frameworks that make it impossible to make errors are the ones that stop you from doing anything. Real life is messy and error-prone.

Re:So many features I will never use ...

[Anonymous Coward]

Actually the awful standard I/O library (yes, I'm talking about the abominations known as the overloaded > operators, cin, cout, cerr, clog and related streams, make use of virtual base classes). I much prefer C level printf and friends, thank you, they are not the problem purists make them to be when the compiler checks the validity of the argument list.

Re:So many features I will never use ...

[Pseudonym]

Indeed. Formatting numbers in iostreams is just painful.

Nonetheless, that stuff is old. I stand by my claim that C++ is trying to be less Simula-like as time goes on. I interpret it as a tacit admission from the C++ standards committee that maybe some of that early "C with classes" stuff was a mistake in retrospect.

Re:So many features I will never use ...

[angel'o'sphere]

Sorry,

you don't grasp it ... but no problem. If you continue to use c++, you will at some point figure what the T in STL means and why having anything "virtual" in it makes no sense at all (and would be optimized away by modern compilers/linkers in most cases anyway).

The interview statement has nothing to do with the matter ...

Re:So many features I will never use ...

[Pseudonym]

you don't grasp it ... but no problem.

I got exactly what you were trying to say. Many people do use inheritance in their template libraries. One common use case is to inherit a template class from a common non-template base class. Stepanov did not, because he believes that Simula-style inheritance is a mistake.

Re:So many features I will never use ...

[angel'o'sphere]

Sorry,

we are not talking about inheritance.

We are talking about virtual member functions (in the context of templates).

And please stop misquoting Stepanov. He never said in any way that avoided inheritance in the STL for a particular reason. His statements about Simula/SmallTalk like inheritance is from different talks/topics.

You brought the STL as a very very very bad example. Point is: in the STL there is absolutely no need for inheritance. So: why the funk would anyone use inheritance there? Secondly: virtual member functions only would still be virtual if you would do pretty advanced stuff with templates. Which you certainly are not doing. In other words: as soon as you have templates and use on top of that virtual member functions you have virtual member functions that never get overwritten, hence virtual is pointless. Or you have virtual member functions that are never called virtual: because from the context of usage they can be statically resolved: again, using virtual member functions is pointless

So back to the initial quote: no, you don't grasp it. And perhaps if you want to dig into it, try to grasp the difference between public and private inheritance (protected and virtual you won't need a long time).

You want to argue that because of Stepanov said something the STL is so superior because it does not use virtual member functions. And that is simply plain wrong. The STL does not use virtual members because it is pointless and would make no sense (and uses inheritance only to describe contexts).

You are using a fact that is as an argument that there is that fact ... circular logic.

Freedom, horrible freedom!

[archatheist]

C++ aficionados, your vexing problem has been solved! That is to say, your complex language has added a new "if" structure with more side-effects to enhance the impenetrability and opportunity for obscurantism that we all value so much.

Re:Freedom, horrible freedom!

[m00sh]

C++ aficionados, your vexing problem has been solved! That is to say, your complex language has added a new "if" structure with more side-effects to enhance the impenetrability and opportunity for obscurantism that we all value so much.

Not a big deal. A simple code analysis tool should easily identify the problem.

Re:Freedom, horrible freedom!

[serviscope_minor]

"if" structure with more side-effects to

You mean less, right? The new structure prevents an unnecessary variable from leaking outside the scope in which it's actually needed.

Re:Freedom, horrible freedom!

[archatheist]

Certainly, because nesting the declaration and if statement in curly braces to use the existing scoping rules of C and not pollute the syntax space is completely impractical. Much better to solve a specific instance of a problem than to use the existing simple solution that solves the entire class of problems.

Re:Freedom, horrible freedom!

[serviscope_minor]

Certainly, because nesting the declaration and if statement in curly braces to use the existing scoping rules of C and not pollute the syntax space is completely impractical.

Where did I say that? Oh that's right, I didn't say anything of the sort, so well done on slaying that strawman.

You can of course double up on the curly braces, but people don't because it looks ugly and non idiomatic which actually matters for maintainability and introduces visual noise. It's also a more general tool in that the variable persists to the end of the block, not the end of the inner block, so you have to check after to make sure it's not re-used.

The new syntax is very much like the accepted for-loop declaration which you don't seem to complain about and the specification of scope is more precise than using the general tool of curly brackets.

Much better to solve a specific instance of a problem than to use the existing simple solution that solves the entire class of problems.

When it comes to programming, actually, life is a lot more complicated. Take for instance range based for, rather than standard for. The former is pretty much specified in terms of the latter with a simple transformation. The former is precisely for solving a specific common case when a more general tool exists.

Well actually, the for-loop is solving a specific case where a more general tool (while) exists.

Well actually actually, the most general tool is goto plus curly braces for scoping. Those literally solve every possible looping problem plus many extras, so there's no need for do, for, range for, while, break or continue.

So why bother with any of those? Because we tend to do the same sorts of thing again and again, and life is more pleasant for both the compiler, programmer and person reading the code if you can specify the intent (e.g. range-for) rather than trying to deduce the intent from the mechanism (goto).

MORE overloaded keywords ?!

[Anonymous Coward]

Which old keywords have they overloaded with completely new meanings now ?

Do "static" and "const" still mean about 20 different things ?

Sometimes backwards compatibility just ain't worth the mess it causes.

Re:MORE overloaded keywords ?!

[david_thornley]

Sometimes backwards compatibility just ain't worth the mess it causes.

Speaking as someone out in the real world, writing software that actually gets used, backwards compatibility is vital. If we had to rewrite our applications every five years or so, we'd never get much of anything useful done.

But in the real world ...

[140Mandak262Jamuna]

Our IT and Build team still don't permit us to use C11 features because some ancient archiac module originally used mainwin to port from windows to linux.

Re:But in the real world ...

[Anonymous Coward]

That's not C++'s fault. That's the fault of you and your team for not having the balls to tell these IT and Build fools to get their shit in order.

Re:But in the real world ...

[TheRaven64]

C++14 support is far more widespread than C11 support. I'd have no hesitation using most C++11 features in portable code, but even C99 can be problematic if you want to run on Windows.

Scott Myers QUIT!

[Anonymous Coward]

He threw in the towel and is now living in Hawaii with his middle finger in the air, saying, "SUCKERS!".

17 means more compile time to 99.99%. The waiting kind, not the saves-me-time!

Slashdot 3

[Anonymous Coward]

Finally, my kind of news!

Still a bad language

[gweihir]

And ironically, one of its most severe shortcomings is that it is far too complicated. Seems they are hard at work on making things worse.

Personally, I have moved back to C for anything that needs efficiency and use Python for anything that does not. The two also combine well.

Re:Still a bad language

[Anonymous Coward]

# Personally, I have moved back to C for anything that needs efficiency

haha, LOL troll

Re:Still a bad language

[The Evil Atheist]

C++ is only complicated for the implementers. C++ is easier now for the users.

Re:Still a bad language

[gweihir]

Nice! Even more of an idiot than the average AC. Have a look at the Wikipedia page for C to find out how massively, badly wrong you are.

Re:Is 4 errors per line typical for Rust programme

[Anonymous Coward]

Ah, now I get it -- it's sort of like agile!

Proposal: stop "foo" and "bar" inanity

[Anonymous Coward]

Proposal:

Remove the references to "foo" and "bar" in code examples. ...Sadly something I'll never live to see, even if I live 50 more years.

Obligatory video

[apilosov]

All you need to know about C++17 is here: https://www.youtube.com/watch?...

Why foolishly chosen names?

[Futurepower(R)]

Why do technically-knowledgeable give their work self-defeating names?

Rust: Happens with iron as iron becomes useless red dust.

Gimp: (1) a derogatory term for someone that is disabled or has a medical problem that results in physical impairment.

LaTeX: Use two different alphabets to write a name! Inspired by the Greek word ÏÎÏ. Sorry, Slashdot can't display those characters.

Re:Why foolishly chosen names?

[Immerman]

A subconscious attempt at truth in advertising? I mean Gimp at least was pretty "gimped" compared to it's "competition" for a long time. Even today it's not exactly user-friendly. I tend to use it, but let's be honest - it's a graphics program for computer programmers - I generally wouldn't recommend it to non-computer geeks, despite the fact that it's functionality is largely technically on par with Photoshop. It is, in a very real sense, gimped by it's atrocious user interface.

Lol. +1 funny

[raymorris]

+1 funny

In those immortal words

[Anonymous Coward]

The nice thing about "standards" is there are so many!

Re:LOL

[ChrisMaple]

I doubt that a nation with a population of 36 million will "become the dominant power." The world will have to become much more messed up before that tail can wag the dog.

Re:LOL

[Anonymous Coward]

So how's NAFTA working out for you?

Yours sincerely,
Australia

Re:LOL

[Anonymous Coward]

Checked that Canadian to US dollar exchange rate lately, Mr. Canadian Dominant Power? Better hope the price of crude oil goes back up before Alberta becomes the next of the world's collapsed petrostates.

Did they finally fix calling a virtual function ..

[Ungrounded Lightning]

Did they finally fix calling a virtual function of a containing class during the constructor or destructor (or other initialization) of a member object of a derived class that provides a new overriding for the virtual function?

It should be strongly defined to get the base class version of the virtual function until the first line of the derived class constructor is executing until the last line of the derived class destructor has executed.

I have been asking for this since the first round of standardization.

Re:Did they finally fix calling a virtual function

[Ungrounded Lightning]

It should be strongly defined to get the base class version of the virtual function until the first line of the derived class constructor is executing

then the derived class version

until the last line of the derived class destructor has executed

(except when further overridden by additional layers of derived classes, of course).

Rats!

[Hognoxious]

Goshdiggettydarn! I haven't got round to learning C++11 yet.

How do you design a programming language?

[Anonymous Coward]

How does one design a programming language?

I would hope that with every iteration that every bad thing about it is fixed.

Is anyone in particular overseeing problems that revolve around security and bugs with any programming language, or is it a shit product like most software?

No.

[rjh]

I started programming in C++ in '89. Templates were still new, but most of the language was stable. C++ code I wrote in '89 is still readable and compilable today. I know people who started with C++ in 1981, when it was still Bjarne's skunkworks project. The first public release was '83, making C++ 33 years old -- closer to 40 years old than 25.

So

[Anonymous Coward]

Is it
C++ ++++++++++++++++
or
C++ CCCCCCCCCCCCCCCCC
?

Here Come the Haters

[Anonymous Coward]

I can always tell the sh*t programmers. They are the ones that complain about C++ and promote toy languages like Java, C#, Python, Ruby, etc.

Re:Sweet, but even more useless

[gestalt_n_pepper]

All software development must be seen in a greater context of economics and human neurophysiology.

Writing code is a business, not an artistic pursuit.

Efficiency in coding means taking into account the average, affordable programmer. If C++ had to go through a human factors analysis before adoption, it would fail miserably.

As C++ becomes "richer." it also becomes more error prone, and less economically viable from an economic standpoint.

If someone asked you today, to make a business case for any of these new features, could you do it? With real data?

Re:Did they finally fix calling a virtual function

[serviscope_minor]

I have been asking for this since the first round of standardization.

Do you have a link to the proposal? I'm interested in reading about potential fixes. I'd also be interesting in why it's been rejected up to now as well.

Re:Sweet, but even more useless

[david_thornley]

As C++ becomes richer, it becomes less error-prone. STL containers and std::string have done a lot to eliminate buffer overflows, for example, and smart pointers have wiped out large categories of memory-handling errors. Lambdas make declarations more local, which helps avoid errors. Adding "override" to our inheritance hierarchies chased out a significant number of bugs.

Sample Code is often unimpressive

[IBitOBear]

They didn't declare the same variable twice. They declared two independent variables with the same purpose to use the same name. If the second one said "d" instead of "c" it wouldn't break the pattern but it _would_ confuse the point that the two ifs create two scopes with no bleeding through.

Your comment seems to miss that point.

The real goal is to create an initializer that is valid for both the "then" and the "else" part but that DOES NOT introduce variables beyond the scope of the liftime of the if. That's why the full comparison text include the outer braces {thing c=stuff(); if (some_status(c)) okay(c); else no_bueno(c); } implies printf("%p",c) error because C is out of scope.

Using the same variable name twice was exemplary of the common closure of scope in the suggestion.

Alos note that the particular example was to bring it into line with the okay=complex_function(); if (!okay) return error; okay=next_complex_function(); if (!okay) return error;

Programmers _suck_ at stringing conditionals and making sure that the whole stop and exit at first error paradigm is met. The above monad can already be done as a number of graceful or degenerate cases.

if all your success states are boolean true, and failure is boolean false then a simple "return co1() && co2() && co3();" series continues until one fails or all succeed. But larger cascades from less boolean series can get "interestingly decorative" depending on how the programmer likes to arrange this sort of thing.

Of course the "Real Answer" is exceptions, but only if you don't then screw that up...

So the solution is a "not bad" attempt to deal with the horror that is "in-band error reporting", a horror that most languages make us blind to due to ubiquity alone.

Re:Did they finally fix calling a virtual function

[What is a number]

Uh, doesn't it already work that way? And hasn't it been that way for years?

---
I type this every time

Paging Mr. Stroustrup...

[Smerta]

"Within C++, there is a much smaller and cleaner language struggling to get out."
- Bjarne Stroustrup (from the excellent book, "The Design and Evolution of C++")

I use C++ for embedded systems, not a hater at all, but I feel that the language is becoming bigger, with more features, more keywords, larger libraries, and over-ebullient language nerds who aren't building stuff that powers the world (PC-centric Herb Sutter: "Hey, let's add a 2D graphics API! Because PC and Windows and Microsoft!") How is that useful to my embedded implantable medical device? Why does this need to be part of the core language specification? (Well, really the standard library, which is part of the language specification, let's not get pedantic here.) )

Look, I think some of the newer stuff is OK, but enough is enough... plus, and I know I'm in the minority here, but many of the platforms I work on don't use a compiler with C++11 (let alone C++14) support.

This makes my job as a "C++ evangelist" even tougher; organizations that are already scared by the size & complexity of the language are terrified by the "every 3 years, more stuff!" tendency.

I know some of you will say, "If you don't like it (C++11, C++14, etc) , just don't use it." or "these new features make the language /less/ complex." I don't have the time to debate that, but I'll just say that in my (working) world, those arguments don't work.