C++17 Is Near, A Look At The New Features

[pipe13]

This reminds me too much of Perl, Python, and D. Okay, I have little insight into the design process of Perl and D, but they're both languages which have pretty much one single interpreter/compiler.

For at least some ISO standards, there's a policy that an implementation must exist before it can go into the official standard. I thought that was true for C++, as well. Of course, having an implementation vs. having a community with years of usage experience are two different things.

It is true for C++ as well.

Anyway, I like most of the additions in C++11, but I feel like they really needed to draw a hard line that any additions or enhancements must make the language: easier to use safely, enhanced portability, or address some major, practical limitation or hurdle involved in using C++03. If they'd done that, I think it would've had more benefit for the long-term health of the language than larding it up with crap like if-init and structured bindings (to pick on the new standard).

Seriously, you can write C++11 that's almost incomprehensible to a knowledgeable C++03 programmer and boost user. That's a problem, IMO.

But not in mine. Look, I'm all in favor of coding standards. Every project should have one. And if you feel it appropriate to add "--std=c++03" to your CXXFLAGS for every build as part of yours, that is certainly your prerogative and more power to you.

However, you at least appear to feel it's the C++ Standards Committee's duty to embrace your personal coding standard -- whatever that is -- and inflict it upon the rest of Known Space. But there are software tools that have the same effect, are readily customizable from the safety and convenience of your own home, and can be integrated into IDE's such as Eclipse and run automagically if such is your desire.

Seriously. I worked an ISO 90001 medical project once where that is exactly what we did: The IDE's editor and it's formatting standard were required, and every line of code was required to pass our customized Parasoft Eclipse static analyzer. It wasn't rocket science. And although I prefer the "Latest and Greatest" C++ standard (and emacs...) for my personal projects, I'll likely be starting some more esoteric external work shortly and will fersure incorporate some sort of static analysis tool if I do. See https://en.wikipedia.org/wiki/List_o..._code_analysis -- there's something there for everyone.

[coder]

Look, I'm all in favor of coding standards. Every project should have one. And if you feel it appropriate to add "--std=c++03" to your CXXFLAGS for every build as part of yours, that is certainly your prerogative and more power to you.

However, you at least appear to feel it's the C++ Standards Committee's duty to embrace your personal coding standard -- whatever that is -- and inflict it upon the rest of Known Space.

Lol! wut?

Wow, that's entirely not what I was talking about. I mean that an update to a language standard probably shouldn't change it so drastically that expert practitioners in the old standard can be virtually reduced to the level of newbies.

IMO, the goal of updating a language standard shouldn't be to make a language into something it wasn't, but rather to fine-tune it to be a better version of the tool it already is. So, the mere suggestion of features like garbage collection really get my hackles up. If I want a garbage-collected language, I'll use something else, thank you. C++ does not need to be all things to all people.

[pipe13]

Lol! wut?

Wow, that's entirely not what I was talking about. I mean that an update to a language standard probably shouldn't change it so drastically that expert practitioners in the old standard can be virtually reduced to the level of newbies.

Oh. Okay. And as an ossified Fortran IV relic I know exactly what you mean.

IMO, the goal of updating a language standard shouldn't be to make a language into something it wasn't, but rather to fine-tune it to be a better version of the tool it already is. So, the mere suggestion of features like garbage collection really get my hackles up. If I want a garbage-collected language, I'll use something else, thank you. C++ does not need to be all things to all people.

You sound like some kind of embedded programmer. Maybe even a driver hack. But dragging in garbage collection changes your subject. It will indeed be "interesting" to see if and where it goes. Presumably gc would remain optional, if you can wrap your head around the concept. (I haven't.)

[tinko]

Lol! wut?

Wow, that's entirely not what I was talking about. I mean that an update to a language standard probably shouldn't change it so drastically that expert practitioners in the old standard can be virtually reduced to the level of newbies.

That is not, what's happening. The C++-experts I know, are still experts, even though some features of C++14 are new to them. I've looked at the list of expected C++17-feature and I fail to see anything that looks like it would change the code it is used in, to something that would be harder to understand for me, based on my experience with C++. Also, being an expert requires to learn new stuff in ones area of expertise. Please point to some examples of features, that make code incomprehensible for experts of the previous C++ standard.

IMO, the goal of updating a language standard shouldn't be to make a language into something it wasn't, but rather to fine-tune it to be a better version of the tool it already is. So, the mere suggestion of features like garbage collection really get my hackles up. If I want a garbage-collected language, I'll use something else, thank you. C++ does not need to be all things to all people.

That's a straw man argument because the people developing future C++ standards are not making C++ into all things to all people and nobody is seriously suggesting to have a non-optional garbage collector. I still control what memory I use, even though shared_ptr (which I haven't needed yet, thankfully) and more importantly unique_ptr allow me to express certain aspects of that in a safer and more expressive way that allows me to make better use of tool support and catch more bugs with the compiler, without adding any overhead (I would only use shared_ptr in cases, where I would do reference counting anyway).

I still know exactly which types all my values are, even though "auto" makes the code easier to read than some long class name, easier to change types and so on, while losing no benefit of static typing, producing no runtime-overhead and losing no tool- and compiler-support. "auto" makes stuff easier to use, more readable and more flexible, without pulling any unpredictable, black magic runtime type trickery, that some interpreted languages have, into C++.

With ranged-based for-loops I can write down 95% of the for-loops in a more readable way with equivalent functionality, that is closer to the way I think about the algorithm and the code tells everything important about the iteration in the first line. What better way is there, to tell the reader, what might and what might not happen to the elements than for(const auto& item : list), for(auto item : list), for(auto& item : list)? Certainly not the almost zero-information for(long_iterator_class_name item_it=list.begin();item_it!=list.end();++item_it ) type_i_know_from_the_list_anyway item = *item_it; which says almost always the same thing, except when one got used to gloss over it and misses it, when it would actually say something meaningful, or mistypes it at the end of a day in a rarely visited code path and have it blow up at runtime much later.

These are just some examples. They provide convenience and more safety at zero cost. They do not change there scope of the language. They do not change what happens in memory (that would affect the performance). If you think, C++ is trying to become all things for all people, please point out some new features that are the reason you believe that.

[liam]

I guess, until you share with everyone something you would describe as "a reliable language comparison tool".

Meanwhile, the performance section of the Rust FAQ points to…

https://www.rust-lang.org/en-US/faq.html#performance

It also points to https://github.com/kostya/benchmarks

[cj.wijtmans]

vectors in C++ cannot use realloc,

Ever heard of custom allocators? And you dont HAVE TO use STL. And STL is not really an internal part C++. Just as you did not understand that STL strings are not the same as a C++ string(which are basically literals or pointers to a null terminated block in memory).

You should seriously be banned for your bs.

[pipe13]

Ever heard of custom allocators? And you dont HAVE TO use STL. And STL is not really an internal part C++. Just as you did not understand that STL strings are not the same as a C++ string(which are basically literals or pointers to a null terminated block in memory).

You should seriously be banned for your bs.

FIFY. Us programmers are serious stuff. Or seriously stuffed. But not that seriously stuffed

[mmstick]

Ever heard of custom allocators? And you dont HAVE TO use STL. And STL is not really an internal part C++.

It's very much a part of C++, and it's imported in C++ projects through the std namespace: `std::string` and `std::vector`.

If you want vectors in C++, the STL is where you go. Likewise, the same applies to strings.

STL strings are not the same as a C++ string(which are basically literals or pointers to a null terminated block in memory)

What you're referring to is not a `C++ String`. That is a byte/character array, basically a `C String`.

An actual string is a structure that handles UTF-8/16 text and supports reallocation / shrinking / growing. Basically, an actual string type is in the form of `std::string`.

Reducing yourself to byte arrays for all your string handling is simply bad design. No one should allow you to code in their codebases.

You should seriously be banned for your bs.

So you're admitting that you're twelve?

[pipe13]

Well... not to be argumentative or anything, but for vectors STL is not the only place I go. Depends what they're vectors of, and what I want them for. Likewise std::strings are nice, but QStrings are frequently nicer. And not that I'd stoop so low myself (unless I'm forced to by MPI), but coder could possibly lend an example (or two) where byte arrays were in fact very good design...

[cj.wijtmans]

It's very much a part of C++, and it's imported in C++ projects through the std namespace: `std::string` and `std::vector`.

This i believe is changing in new C++ standards. But NOTHING is imported in C++. STL is just c++ code that is included. STL is as the name describes just a standard library that platforms/toolchains can have its own implementation of to do whatever optimization they like. Including using realloc if they wish.

If you want vectors in C++, the STL is where you go. Likewise, the same applies to strings.

Not really. STL can be very inefficient and sometimes it would be better to turn to a different library. Which is one of the reasons for accelarated standard releases in the first place as the limitations caused STL implementations to be slow and make to many copies.

What you're referring to is not a `C++ String`. That is a byte/character array, basically a `C String`.

They are the same. C++ is designed to be C compatible. STL string is something else.

An actual string is a structure that handles UTF-8/16 text and supports reallocation / shrinking / growing. Basically, an actual string type is in the form of `std::string`.

Says who?

Reducing yourself to byte arrays for all your string handling is simply bad design. No one should allow you to code in their codebases.

Nevertheless it is what a string/literal is in C++ and C and it will remain as such as long as there are string literals in the binary. Same for Rust or any language for that matter.

So you're admitting that you're twelve?

Projection.