
GCC is C++17 Complete - gpderetta
https://gcc.gnu.org/projects/cxx-status.html#cxx1z
======
webaholic
Congratulations! Clang is almost there too
([http://clang.llvm.org/cxx_status.html](http://clang.llvm.org/cxx_status.html)).

I love seeing free compilers get advanced features years ahead of proprietary
compilers like MSVC and Intel Studio.

~~~
Salgat
The folks working on the Microsoft compiler have done a fantastic job lately
keeping up with features, so I wouldn't call them years behind.

[https://blogs.msdn.microsoft.com/vcblog/2016/01/22/vs-2015-u...](https://blogs.msdn.microsoft.com/vcblog/2016/01/22/vs-2015-update-2s-stl-
is-c17-so-far-feature-complete/)

~~~
astrodust
The level of coordination here in the C++ space is astonishing and
commendable. This stuff used to take over a decade to trickle in and now it's
all falling into place right on schedule.

~~~
zanchey
It's quite amazing to see the degree of change; unfortunately, as C++
compilers are so integral to the system, shipping newer code for older
platforms is proving quite difficult. We recently went to C++11 and have to
drop binary builds (through OBS and PPA) for a number of still-maintained but
older platforms, sadly.

~~~
lallysingh
Shame there isn't a 'C' target for modern C++ compilers.

~~~
makapuf
Sure, I like many of the new features of C++ that could be compatible with or
adapted to C (constexpr, auto, typed enums, or even (gasp).. templates for
generic programming) and I'm jealous of the level of innovation in C++ (which
would't be that difficult to backport to C since the features already are on
C++), especially for embedded.

~~~
vopi181
Why wouldn't you just use c++ then? Almost all c++ is valid C, no?

~~~
khedoros1
Almost all C is valid C++, but the reverse isn't true.

~~~
makapuf
Almost but not all. Restrict keyword, by example.

~~~
dangerbird2
Also modern features like atomics and complex numbers are implemented as
language features in C, but with template libraries in C++. Likewise type-
generic math in C11 uses the C-specific _Generic keyword, but uses templates
and function overloading in C++

------
ramzyo
What does "complete" here mean if the standard itself isn't yet complete? Or
are complete and finalized not necessarily the same?

"Because the final ISO C++1z standard is still evolving, GCC's support is
experimental. No attempt will be made to maintain backward compatibility with
implementations of C++1z features that do not reflect the final standard"

~~~
gpderetta
It is complete... so far. The standard is in "feature freeze", bugfixes only.
Although technically new features can still be added in response to National
Bodies comments, in practice everybody expects the feature set to be set in
stone.

Also that page only tracks pure language features, standard library
conformance for libstdc++ is tracked elsewhere, although the standard library
is equally part of the language.

The status for libstdc++ is here:

[https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#...](https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.201z)

which in fact shows a few missing features.

~~~
ramzyo
Got it, thanks for the clarification!

------
radialbrain
As cool as this, libstdc++ is still missing a few things, including parallel
algorithms (which I'm most excited about!).

[https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#...](https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.201z)

~~~
gpderetta
I didn't realise that the parallelism TS was merged into the standard.
Excelent.

I'm still eagerly waiting for the Concurrency TS to be merged. As it is,
without 'then', std::future is pretty useless.

~~~
ot
And with coroutines, futures are useless again :)

~~~
gpderetta
Ah, that's a common misconception. Even with coroutines you still want
explicit async calls and futures, otherwise if you restrict yourself only sync
calls, you either have to artificially serialize operations or have to spawn
artificial coroutines.

What do you do not want are explicit uses of 'future::then' and the required
manual CPS transform. Instead you want a wait-for-{any,all} future operations.

~~~
ot
Yes, that's what I meant, futures for control flow.

------
chamakits
I'm not familiar with C++ at all, but I'm always amazed at how quick gcc is to
get updated to implement what I imagine are complicated feature updates to the
language.

Do they have a lot of very active contributors that communicate to efficiently
split the work, or do they have a small but very dedicated group of people who
spend the bulk of their time on implementing these features?

Regardless, kudos.

~~~
saurabhjha
I also think there is some corporate backing in C++ compilers. Like a few
internal company people are getting paid to fix this kind of stuff.

Regardless, it's great to see C++ compilers incorporating latest standard
features. For comparison, check JavaScript standards implementation in
browsers (not sure if it's a fair comparison).

~~~
gpderetta
It is a very fair comparison actually, with similar compatibility pains in the
past due to both differing interpretation of the standard and plain non-
compliance. Things are getting much better lately.

------
shanemhansen
Am I reading this right? They are implementing transactional memory support in
C++?

[https://gcc.gnu.org/projects/cxx-
status.html#tses](https://gcc.gnu.org/projects/cxx-status.html#tses)

[http://www.open-
std.org/Jtc1/sc22/wg21/docs/papers/2015/n451...](http://www.open-
std.org/Jtc1/sc22/wg21/docs/papers/2015/n4514.pdf)

~~~
wahern
Yes and no. Traditional software transactional memory as imagined in the 1980s
and 1990s is still imaginary. The hardware is still too limited.

Instead, it's more akin to something like the "synchronized" method and block
attribute in Java, where the compiler transparently acquires and releases a
mutex. Except in Java the mutex is on a particular object, whereas in C++
it'll be on a per-block hidden global mutex.

For small enough blocks, and if the stars are aligned just right (i.e.
regarding alignment, cache-line locality, etc), the compiler might be able to
optimize away the mutex in favor of a series of LL/SC, CAS, etc statements.
But then, so could the JVM for synchronized methods.

It basically makes multi-threading easier, but won't automagically make it
possible to build lock-less data structures, except that maybe the compilers
will be smart enough to optimize something as simple as a singly-linked list
construct into atomic instructions.

This approach to "transactional memory" was mostly fleshed out years ago in
proofs-of-concepts by Intel, GCC, etc developers. And the approach has driven
Intel's design of their "transactional memory" instructions, which basically
move aspects of traditional synchronization approaches (speculative mutex
acquisition, dirty flags) into the microcode.

~~~
gpderetta
As far as I understand the mutex is not per block but is logically a single
global mutex (synchronized blocks) or actual transactions with full rollback
(atomic blocks).

It really is transactional memory and it is meant to be implemented using
hardware acceleration like that available in recent server class x86, power
and sparc CPUs.

GCC, I belive, supports both a pure software based implemenation and an hibrid
one.

~~~
wahern
I guess we interpret the phrase differently. I interpret software
transactional memory to mean being able to build complex lock-free, wait-free
data structures. That doesn't require hardware transactional memory, but does
require some strong hardware primitives.

Here are some good links which explain how TSX works and how Intel might have
accomplished it.

    
    
      http://www.realworldtech.com/haswell-tm/
      http://www.realworldtech.com/haswell-tm-alt/
    

TL;DR: one way or another they're piggy-backing on the mechanisms needed to
maintain x86's strong cache coherency. Fundamentally it's just speculative
operations on a small amount of data--if conflicts are detected, or if you
manipulate more than a couple of cache lines (because the processor will only
be able to track and buffer a very limited number of cache lines for
conflicting operations during the pendency of the transaction), the code
generated by the compiler will either take a lock or loop.

So, yes, it will make much existing code faster. But it's not going to provide
the ability to develop highly-concurrent lock-free data structures. If there's
any serious contention (i.e. more than 2 or 3 threads), or your transactional
blocks access more than a few words of shared state, the transaction will
invariably abort. Which is why all software transactional implementations,
including recent ones which make use of TSX, are typically _slower_ than
similar lock-based approaches in real-world scenarios.

STM-light is still conceptually elegant from the programmer's perspective, but
deep down there's much less magic then you'd think. That's because it's _very_
expensive to track conflicts in a fine-grained manner in hardware. LL/SC
operations were proven in the 1980s to be universal primitives that could be
used to implement arbitrarily complex lock-free, wait-free algorithms. And
chips like ARM and POWER have LL/SC opcodes. But they're pale shadows of the
constructs studied in the 1980s because trying to actually implement them in
hardware is just too costly. So TSX, while cool and useful, is something of a
hack (and I mean that in both the positive and pejorative senses).

The real speed gains from Intel's new architectural support come from hardware
lock elison, and doubtless both GCC and LLVM will lean heavily on this as
it'll be easier to work with. Like with VLIW and then auto-vectorization,
don't put too much stock in promises that compilers will be able to transform
typical application code into a form that's suitable for use by the
specialized hardware instructions. Like with AVX2, for example, to really make
good use of TSX programmers will still need to meticulously organize their
data structures and code flow, and will need to be mindful of the hardware
constraints from the very outset. And in most cases they'll be far better off
using intrinsics or assembly in the critical sections of their code.

~~~
bonzini
You can touch a lot of cache lines in a transaction. On POWER it's several
hundred.

I totally agree that TSX works best with specialized data structures. But it's
powerful enough that you can, for example, malloc() or free() a block of
memory inside a transaction.

~~~
wahern
Interesting... according to this paper

    
    
      http://www.gsd.inesc-id.pt/~salaa/wttm2015/html/abstracts/Hasenplaugh.pdf
    

it's the opposite. The maximum reliable transaction write capacity if
contiguous and well-aligned is small on POWER (63 cache lines) and high with
TSX (400 lines). TSX is using L1 cache to buffer writes, and so the number of
concurrent transactions only scales with cores. Whereas POWER uses a per-
thread buffer which can scale linearly with the number of hardware threads (8
threads per CPU, 80 in their test).

So if I'm understanding this correctly, TSX has better capacity but poor
concurrency, and POWER has poor capacity but better concurrency.

That's very cool.

~~~
valarauca1
Quick Side as the two commenters in this thread seem knowledge.

I assume xbegin is a memory barrier. But is it a full fence like mfence or
lock prefix?

I see a lot of benchmarks using TSX for locking, but one of the nicer features
of lock compxchg or lock xchg is they carried an implicit mfence this was nice
because it forced reads/writes before the instructions to be completed.

I know xbegin/xend do _more_ then an mfence for reads/writes within the RTM
region but do they provide fencing for instructions _after_ their execution?

~~~
gpderetta
No idea and don't want to dig into Intel docs right now, but I would be
surprised if they were full fences as I think xbegin/xend would only require
acquire/release semantics.

xacquire/xrelease can be used as modifiers to existing lock prefixed RMW
instructions which are already full barriers, giving them optimistic locking
capabilities.

~~~
valarauca1
Okay so I asking around on the intel forums. They fences for instruction
ordering, and cache load/flush.

But not for load/stores. If you load/store from data within an RTM region
(after _xend()) you have no atomic protections.

------
gpderetta
... or at the very least those parts of c++17 that already made it into the
draft standard. The final version will only be published sometime this year
but feature-wise there shouldn't be any major surprise.

------
lacampbell
What are the big new features of C++17? C++11 seemed like the last big change
- I think the only reason I bother using "-std=c++14" is for "make_unique".

~~~
gpderetta
The major user visible features of C++14 were polymorphic lambdas, generalized
lambda capture, proper constexpr, member initializers and return type
deduction. I use most of these everyday.

For C++17 the biggest features are structured binding, which is the first step
toward pattern matching, and deduction of template parameters for class types.

Other features like fold expressions are realy meant for library writers.

The standard library did get variant and optional whixh arw pretty cool.

~~~
ot
The lack of generalized lambda capture was one of the biggest idiosyncrasies
of C++11, given its focus on move semantics.

~~~
gpderetta
Even in with the last draft it still not possible to easily move-capture a
variadic parameter pack; it is a fairly esoteric feature and there are
workarounds, but it is still annoying.

------
shangaslammi
Is there a good, terse primer on the features and coding idioms/best practices
of C++17 for someone who was proficient in C++98 but hasn't touched the
language in years?

~~~
eej71
Unfortunately it's not terse but Effective Modern C++ by Scott Meyers is a
good resource.

[http://shop.oreilly.com/product/0636920033707.do](http://shop.oreilly.com/product/0636920033707.do)

~~~
72deluxe
Note that this book covers C++11 and C++14. C++17 wasn't on the scene much at
this point so there is no mention at all of it in the book.

Having said that, C++17 was a minor update (much to Stroustrup's displeasure)
and I can heartily recommend this book.

It was Meyer's last book as he is now retired (but will happily reply to
emails; I love that about the C++ community - I've emailed Sutter, Stroustrup
and Meyers and they will all reply).

------
CptMauli
Can somebody shed some light on it, why embedded companies (speak Microchip
etc) have not switched to clang/llvm? It must cost them quite a bit to
maintain their own compiler stack and it is not very good.

Fun example: a customer of mine initialized a variable within a loop and that
resulting program just didn't work as expected (which it did with the same
code on my desktop with gcc). As soon as he moved the variable out of the loop
the program worked as expected.

~~~
gumby
gcc and llvm weren't designed for the constraints of 8-bit (or 16-bit)
targets. The support for 32-bit machines is quite good (and these days some of
Atmels ARM parts are cheaper than some of their AVR ones!).

Also, for the extremely low cost parts (small AVRs, PIC etc) the margins on
the parts is very low which doesn't fund a lot of software development. And
hardware companies often don't have much software development resource.

------
stargrazer
does that include the 'export' word for templates, which was supposed to be
available many c++ versions ago (don't think it ever got implemented in msvc).

~~~
arximboldi
That was removed in C++11, precisely because compilers could not afford to
implement it.

[http://en.cppreference.com/w/cpp/keyword/export](http://en.cppreference.com/w/cpp/keyword/export)

~~~
gpderetta
Even the authors of the only compiler that had ever implemented it (EDG) said
that it was a lot of work for little benefit and pushed for outright removal
without deprecatation.

Modules eventually, more than 20 years later, might be a better solution.

~~~
wyldfire
That seems very selfless of them. If they acted like other competitive
markets, they'd want their competition to suffer the challenge that they did
and they'd create a message that they were the first ones to satisfy the
standard. They must really have the best interests of the language in mind.

~~~
gpderetta
They are! EDG is a tiny company but is extremely highly regarded and its
founders (Stephen Adamczyk, John Spicer, Daveed Vandevoorde) are considered
legends in the community.

At a time where GCC was still catching up, MSVC was in the dark ages and clang
still not existent, EDG used to be _the_ standard compliant C++ front end. It
is still the front end for a lot of proprietary compilers (Intel, MSVC
intellisense, Comeau) and I hear it is a very high quality codebase.

------
gradstudent
Getting a bit tired of these constant updates to the language. I still haven't
properly absorbed C++11!

~~~
stinos
_I still haven 't properly absorbed C++11_

In that case, skip to c++14 immediately and try your best to use as much from
it as possible as that will erradicate a bunch of unpleasancies you've become
accustomed to. Really it's almost like a new language (and yes that comes with
it's pros and cons) compared to pre-c++11. Once I realized that I've tried
keeping the mindset 'first check if c++14 added something for dealing with
this, before writing any code' for nearly everything I write (in practice:
search, land on cppreference.com and/or stackoverflow.com, read). In the
beginning that costs time but I'm pretty confident I gained that back already
because the knowledge it gives you enables to write better code, faster.

------
devmunchies
Why do most C/C++ projects never use CSS in docs?

(I acknowledge that many high level projects use too much CSS)

~~~
omeid2
Why should they? That document seems pretty legible, in fact, I would say its
readability is excellent; specially in contrast to all those fancy fonts with
#333 on #EEE that many "modern" websites use.

Further more, that page is responsive! and doesn't require 5mb of JavaScript
and a high pref cpu to work.

~~~
devmunchies
I know your question was rhetorical but I'll answer it.

Its actually terrible to read on a wide monitor. If you were to give the
content a max-width with some gutters its easier for your eyes to follow the
lines. I always start reading a line that I just read! I'm talking about
adding less than 10 lines of CSS, nothin major.

~~~
jlarocco
Protip: You can resize the browser window.

~~~
mcbits
And then resize it again when you switch to a different tab. Or I guess you
could pop every tab out to its own window like it's 2003.

------
nom
Awesome! And just in time, too :D

