C++17 Is Here: Interview with Herb Sutter
infoq.com
infoq.com
Is there a C++17-exclusive compiler-flag? Or linters that inform you about outdated concepts? Some way to get rid of the backwards compatible cruft when writing new things.
I stopped following Python regularly around 2.2 timeframe and only use it occasionally as better shell scripts when on UNIX like systems.
If I was to actually build an application with it, I bet my code wouldn't be very up to date with 3.7 Pythonic code.
https://github.com/isocpp/CppCoreGuidelines
For those that aren't aware, actually some of the input from Microsoft side was based in the work done with Midori and having System C# ideas applied to C++.
VC++ with the code checkers and clang with clang-tidy.
Not sure about the current state of gcc or other commercial C++ compilers.
But apart from that, languages have “cultural dialects”. So for example I essentially always loop with for(;;) and so a while (or do while!) looks alien to me. Likewise, a destructuring bind is not the only way to unpack a loop variable, so no compiler would mandate its use.
It’s a large system programming language so it will take a while to learn a lot of nuances...but you can get a ton of great code written without learn8ng that stuff.
I'd be very surprised if there was any difference in terms of the generated code. Personally I use while(true).
A strange choice by the committee I'd be interested in reading more about.
Coming from an embedded background, the form "while (true) { // do nothing of interest }" is seen a lot in embedded code. If your code is interrupt driven, or running certain RTOSes, you would usually see this at the end of main(), since everything happens in interrupts. You might also see this in error handlers, and "unimplemented" interrupt handlers during development, as a way to trap the program without halting / resetting the system completely. If this kind of loop was optimized out / you returned-from-main on your embedded system, interesting and unintended things may happen.
While I've never had problems with these particular loops being optimized out (that I can remember!), I do remember having to do other vary silly hacks to try and tell the compiler not to optimize things out, because something is happening in hardware that it wasn't aware of, so I wonder if this is just a practical way of making sure that this kind of code keeps working with newer compilers, even in the face of aggressive optimization.
LLVM has since added a new intrinsic: https://reviews.llvm.org/D38336
This will allow us to fix the bug.
Example: https://godbolt.org/g/md86qX
while(true) // infinite loop! Red flag!
repeat // I have no idea what this will do.
And it's not like I don't use 'while' -- in a bash script it looks normal to me -- it's just I would never even think to use one in C or C++. And when I read it it looks weird to me.
Likewise do...while is in retrospect, a mistake, because it documents the control strategy in a bad place from a humans-understanding-code point of view.
Thanks gumby.
I simply didn't catch that they were referring only to infinite loops. I though they were debating the usefulness of while versus for, in general.
- 'for' is simply my only looping construct. Now that C++ supports 'for(auto x : some_container) x.blahblah();' this is especially true.
- the old 'for(init; test; increment)' syntax put all your control right up front so as you read the code you already have in mind the range of when the body will run. A 'while(not_exit) { ... }' doesn't tell you that you're, say striding over the even elements or whatnot -- it's really just the equivalent of an open loop with an 'if(...) break;' somewhere in the body. And let's not get into the botch of 'do..while'
Don't worry about not taking the time to properly learn C++ . It is a huge huge language and trying to learn it all at once from first principles will take you forever. Just try to do things in the most memory safe way possible.
If you want to catch up on C++11 and parts of C++14 I recommend Stroustrup's A Tour of C++.
I'd probably read the other Effective C++ books (even though they are dated now) before cracking open Effective Modern C++.
clang-tidy might be the closest thing you're looking for:
http://clang.llvm.org/extra/clang-tidy/
There is another language that always gets mentioned in C++ posts and that languages has a tool called clippy which does what you want. It's dreamy.
You can write a kernel in C++, or you can do high level UI, or a game engine, and these will be very different, you can almost say you are using a different language.
For example, to allocate an array, you can use a vector, array, new, or malloc. Most people will tell you to use a vector, but a vector uses a bit more memory than an array, so you might want to use this instead, but you may not want to link with the STL at all, so you go with new, but if you don't want to deal with exceptions or just want a block of raw memory, you may want to go with malloc instead.
Just use the new features if it makes life easier for you, that's the idea. As for linters, I know that cppcheck can warn you of C-isms (ex : C-style casts) but I don't know any of them that target modern C++ variants.
How do you think the std::vector is implemented under the hood ?
Also, `new`/`delete` aren't unidiomatic when strictly adhering to RAII and
- Writing exception-safe code (with the `new (std::nothrow) T` form).
- Writing custom smart pointers or data structures, or high-performance containers (especially with C++17 aligned `new`/`delete` and C++14 sized `delete`).
- Using memory pools (with placement `new`/`delete`).
`[std::]malloc`/`[std::]free` aren't necessarily unidiomatic either, such as
- When using a C API (or one in pre-standard C++ or a third language) which is incompatible with `new`/`delete`.
- When you need `[std::]realloc`, and for whatever reason a `std::vector` isn't an acceptable substitute.
- In embedded or other environments that don't provide a STL.
Also shared_ptr's make the ownership relation harder to understand. (Also there's additional synchronization cost for copying pointers.) Of course there are situations where you need them, but in general, I think it's better to avoid them.
I am now back into high-performance scientific computing, and I am glad to see C++ has evolved much, in pretty good ways. However, is it worth getting back into C++ when things like Julia and Rust are around? Or are these still too immature?
For me, as native companion to Java and .NET stacks, Rust still cannot take C++'s place regarding mixed debugging experience, IDE integration, GUI designers support, distribution of binary binaries and most important making team mates or customers (specially their IT) accept yet another tool into the projects.
For other people Rust is already mature enough and they are delivering production code with it.
In any case, until Julia and Rust stop using LLVM as their backend, being confortable with C++ is a good idea.
Julia seems ideal in some ways, as performance can be quite close to C / C++ / Fortran, while the code is more high-level. I don't care about GUIs, distribution, teamwork or maintenance.
Julia seems promising, and there are some nice usage stories already:
https://www.intel.com/content/dam/www/public/us/en/documents...
I am quite proficient with JVM-based stacks (Java, Scala & Clojure). But the level of performance, especially in terms of memory usage, cannot come anywhere close to C++.
There are, however, definitely wrong ways of doing things in C++. There's quite a few things in the STL that should have long since been deprecated if not outright removed.
Simple example is std::map. Absolutely horrible data structure. std::unordered_map is what you actually want, but to a beginner nothing really tells you that. You just think "I need a map, oh hey there's a std::map, perfect!" and go about your day completely unaware of how awful a data structure you just chose.
Another example that's a mistake made in C++ hello worlds of all things is std::endl. std::endl does not mean "end line", it means "\n + flush" (specifically '\n' - it does not do '\n\r' or '\r\n' conversions at all, the underlying file system does that). And flushing on every new line only makes sense for line-buffered things like std::out, but std::out already flushes on '\n' character. So std::endl in practice just leads to a ton of unnecessary & unexpected flushes.
> so you go with new, but if you don't want to deal with exceptions or just want a block of raw memory, you may want to go with malloc instead.
There's actually very little reason to ever use malloc. If you globally don't want exceptions just use -fno-exceptions. If you don't want exceptions in the small scope you're working in then use std::nothrow, eg: "new (std::nothrow) int[1024 * 1024]".
As for why you do this over malloc the reason is simple - it avoids overflow bugs. new int[size_t] never overflows. malloc(size_t * sizeof(int)) - well that overflows trivially, and that overflow results in security bugs.
Raw malloc would arguably be another case of "this is just wrong C++" rather than "this is a perfectly valid alternative". Raw free would belong in this case except for calloc, which is still very useful (and avoids the common overflow bug that malloc has). malloc's only saving grace is realloc, but now you're pretty deep into a specific edge case.
Also not sure what you mean when you say operator new never overflows. Can you elaborate?
It would be nice if C++ gave an operator new/allocator that put the object on the end of a page boundary so that the hardware could catch any overflows. Sort of like how the atomic operators are cross platform but hardware specific.
std::map is a red-black tree. It will have among the worst cache coherence of anything. Do you have any supporting benchmarks?
And if you have a small enough data set then std::vector will run circles around any map anyway.
> Also not sure what you mean when you say operator new never overflows. Can you elaborate?
size_t mySize = ...;
int* myptr = (int*) malloc(mySize * sizeof(int));
int* myptr2 = new int[mySize];
Hint: the malloc version has a security bug, the new one doesn't.
In any case, it's the multiplication that has a bug, not malloc (though I agree that the usage you mention is unfortunately common).
I challenge you to find a single correct use of std::map to begin with.
Is this severe enough to be worth breaking programs? No. But was it a mistake? Yes, absolutely. And deprecation is how mistakes are fixed over time, so why not fix the mistake? Old things can stay on their old STL and live with the old std::map. Maintained things will get warnings that they can go address in their own time. And new things are guided to the proper choice.
Before C++11, you only had std::map, so every use was correct. After C++11, you may still care about iterator invalidation or actually maintaining ordering. These properties are too useful to be deprecated.
As for beginners, their priority should be learning the core language and making a habit of browsing the std documentation to see what's there. Then they'll stumble upon unordered map too.
EDIT: as for cache coherency, std mandates use of separate chaining. If you really care about cache, you'll have to implement open addressing yourself.
There's no shortage of 3rd party map implementations. Nothing forced you to use std::map pre-C++11, so it still isn't correct to use std::map prior to C++11 it was just easier to use std::map prior to that.
If you need ordered access a hashmap + key list is a superior implementation to red-black trees, so std::map still loses there.
The only thing std::map does have is iterators stay valid during inserts, but this doesn't really seem useful and indeed it's something most maps in most languages don't have. Heck, Java's red-black java.util.TreeMap doesn't even bother to keep iterators valid during inserts even though it could. How is this a useful property in practice much less one "too useful to be deprecated"? Do you have any examples?
Superior in what way?
> Do you have any examples?
It's a couple of years since, but I remember having relied on both ordering and iterator stability in certain algorithms related to topological meshes. Basically, I'd traverse a map and delete some elements during traversal.
Could I have done it in some way with a hash table? Yes. Would it have been more complicated? Yes.
Superior in performance, and you can pick if you want to optimize for iteration (put the keys in a sorted vector) or insertion (linked list). Either way you'll trivially beat traversing, inserting, and removing elements from a red-black tree in runtime.
> Basically, I'd traverse a map and delete some elements during traversal.
That works fine with unordered_map, too. You can keep the iterator when you remove. It's only inserts where map's iterators stays valid but unordered_map's doesn't.
I mean, I wouldn't complain if with C++23 we introduce std2 and make things better. While we're at it, we could also try to fix std::list and std::deque which are nearly useless too.
which is the default in python, you get awesome effects, where the order of the unordered dictionary is dependent on the random seed.
where library implementor are serializing a dict into a serial structure (and are not sorting by key). running the same code and same data twice, will get you potentially different results.
now here comes the best. most of the time in python you don't see the difference. the output is exactly the same but never the less the order is not guaranteed.
so I believe having an ordered by default data-store will help the ecosystem.
Calling it unordered explicitly helps, to make sure that anybody serializing the structure will need to make a choice how to sort it.
It's not a question of ordered vs. unordered, it's a question of red-black trees vs. a hashed array of some sort.
As for outdated stuff in the standard library, that's something that affects every language as it ages. `map`/`set` aren't, IMO, the worst offenders; they were misleadingly-named (like `std::endl` and `std::move`), but RB-trees are a useful data structure, and while they are slower than hash tables (`unordered_map`/`unordered_set`) for the typical map/set use case, it's not like they're buggy.
The one that IMO most cries out for replacement is `[std::]rand` (inherited from the C standard library), whose RNG is abysmally low quality/predictable, very slow, and thread-unsafe. C++11 did introduce a new RNG API[1], but it's quite cumbersome and verbose to use, when they really need to introduce a simple API like BSD/Mac `arc4random_uniform`[2] so people will stop using `rand`.
Edit: I see that this is being addressed, although it didn't make it into C++17.[3]
While not buggy, iostreams are also getting a bit long in the tooth and could stand to be replaced with a more modern API, the iterator APIs (in the <algorithm> and <numeric> headers, etc) should also be methods on STL types, and `std::string` isn't quite deprecation-worthy, but it would be nice if the STL were augmented with a state-of-the-art encoding-aware string implementation like Swift's. And it would be nice if the STL acknowledged the existence of the internet (with high-level libcurl-like functionality in addition to the very low-level Networking TS).
[1] http://en.cppreference.com/w/cpp/numeric/random
[2] https://www.unix.com/man-page/freebsd/3/arc4random_uniform
As a longtime hater of C++, I do want to point out that this is one of my big issues with it. Every time I mention my various gripes with C++, I get the same response from the apologists: "Well, if you just do C++ the right way, that's not an issue"
Fine! Great! Then just tell me what the right way is! But no one can (or if they do, then someone else comes along and immediately tells them they're wrong). If there were some agreed-on idiomatic subset of C++ that avoided all the pitfalls, or even just a book that everyone agreed was "good", that would go a long way toward warming me on the language. But so far as I can tell, no such thing exists.
The core guidelines are working to be precisely that.
As a C++ programmer I'm quite happy to see the language keep improving in quite a good pace, but I'm wondering if anyone can shine some light on how this evolution compares with other widely used languages.
Of course newer languages can change drastically quite fast (Swift comes to mind), but I don't follow more accomplished languages (PHP, Java, JavaScript, Python, Even C, ..., sorry if I didn't name your language) close enough to get an idea.
My impression of C++ is that is evolves fairly quickly, but also includes everything, the kitchen sink and the highway, making for an expansive and complex language. Scala gets some of the same flak.
Java evolves glacially, and outside of very rare large improvements (e.g. lambda's in 8) it's still the same (verbose) language and will remain for a long time.
PHP evolves fairly quikly, but the API's aren't consistent leading to a bit of the "flavor of the week" feeling for new additions. I don't know how this has been since PHP 7+
Javascript is evolving at a rapid pace, but despite that they seem to move toward a clear goal with nice functional API's and constructs being added to the language.
I'd say half the reason to call it a quick evolution is how fast it's being adopted compared with the glacial progress from 5.2 to 5.6, or Python 2 to 3.
Also a third half of the freshness has been adoption of packaging and coding standards.
These days, C++ on Windows is great.
Just look at how Python ended up if you want to see what happens when you try to backwards-break a language. And C++ is oh so much worse at that - if you make a non-compatible language iteration it would also (probably) break the ABI, which means "new" C++ cannot link old C++. It would make two languages. And nowadays, you really only have one of three reasons to write C++:
* You already have a C++ project.
* You need to use a C++ library / supporting code / integrate with C++ directly (and not through a C API).
* You want a feature only a C++ construct / library can provide. Qt is a great example of this, because there really is nothing comparable to it on any other platform in terms of a cross platform native UI toolkit, and using bindings can work but introduces a lot of build system complexities.
So C++ has all the reasons to adopt new paradigms to make life easier for those who have to use C++, but breaking backwards compatibility defeats all the core reasons you want to use the language. A prettier language is useless if you cannot get real work done in it.
But it will be an up-hill battle if not working alone, unless one is working in high-integrity related industries.
[1] By which I mean the languages themselves and minimally-conforming standard libraries rather than ecosystems or quasi-standard libraries like J2SE (Java), Cocoa (Swift) or the browser DOM (Javascript). C++ has a fairly slow-moving (but mature) ecosystem and its "quasi-standard" libraries (Boost, common compiler extensions, Windows and POSIX APIs) aren't as tightly-coupled to the language as the previous three examples.
[2] Both hindered by standards-body bureaucracy and the need to keep backwards compatibility with mistakes, but both popular enough that bigcorps are incentivized to keep things moving along; Javascript is more popular but that's offset by C++'s more efficient de facto process for standards-tracking library improvements (get them into Boost first).
Javascript actually probably moves a bit faster but Internet Explorer compatibility (still likely to be relevant for another 5 years or so) is an even bigger drag on adopting bleeding-edge features than waiting for (your company adopting) new Visual Studio/CentOS GCC/[Some embedded architecture] GCC versions is for C++.
Please!
Are there beta version of compilers, would it be GCC, clang, MSVC?
Earlier, I made some notes and walked away from the problem, because it was getting frustrating. Then, while I was checking this out, I started thinking "Imagine how complex this would have been if I had done it in C++" Then the immediately following thought was "Well, in C++, I would instead build it like so, because it needs to be thread safe." Problem solved, obvious-in-hindsight solution.
Even though my problem wasn't caused by a low level threading mistake, thinking about the problem in the context of a more primitive tool helped me to better understand how my own tools are working.
It'll be interesting to see what gets in next.
https://izzys.casa/posts/millennials-are-killing-the-modules...
Modules without buy-in from build tools (or a fresh build tool) will probably be DoA as Isabella says.
"Meta: Thoughts on generative C++" - https://youtu.be/4AfRAVcThyA