LWN: Comments on "GCC 5.1 released"

GCC 5.1 released

jwakely — Tue, 19 May 2015 11:05:51 +0000

Sesse gave the proposal that explains the std::string changes.

Rationale for changing list::size() can be found in http://howardhinnant.github.io/On_list_size.html

The actual change was proposed by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n...

GCC 5.1 released

jwakely — Tue, 19 May 2015 10:54:54 +0000

Thanks, they should be fixed on trunk now and I'll do the backport for 5.2

GCC 5.1 released

ikm — Mon, 27 Apr 2015 20:47:30 +0000

> Especially the list thing seems downright ridiculous. You could just track the length yourself, if you need constant time access to it, couldn't you?

Tracking the length yourself is error-prone, so you'd really have to implement your own list. Regarding the decision, the cost of splice() is now O(n) instead of O(1), and the cost of size() is O(1) instead of O(n). Since the latter is used much more, it seems like a fair trade.

GCC 5.1 released

Sesse — Sun, 26 Apr 2015 01:04:27 +0000

FWIW, there are tons of new semantics prescribed for everything, it's just that std::string and std::list are the two primary examples where you can't implement the new semantics without an ABI break. In particular, there are a lot of new demands around multithreading, since C++11 for the first time actually includes threads and all the associated machinery to make safe multithreading possible.

The standard does not say “copy-on-write is not allowed”, it just outlines a number of constraints (mostly related to threading) that are effectively incompatible with COW std::string. Of course this was done knowingly; see

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n...

GCC 5.1 released

Cyberax — Sat, 25 Apr 2015 20:40:40 +0000

The problem was already there. GCC used CoW for strings and MSVC used copying with small-buffer optimization. So something HAD to be broken anyway.

AFAIR, both MSVC and GCC had O(N) complexity for std::list::size but it definitely made sense to fix it.

GCC 5.1 released

magila — Sat, 25 Apr 2015 17:02:27 +0000

I'm not going to defend the decision to mandate O(1) size for std::list, but prohibiting COW for std::string seems pretty reasonable to me. In the years since C++98 was published a consensus has emerged that SSO is generally superior to COW, and AFAIK GCC is the only major C++ implementation still using COW. Being able to rely on all implementations using SSO makes it easier to write optimal code using std::string.

GCC 5.1 released

lsl — Sat, 25 Apr 2015 13:43:18 +0000

Can someone tell what the hell the C++ standard committee members where thinking when prescribing new semantics for std::list and std::string, in full knowledge that this is going to break ABI for most implementations?

I mean, this is C++, not Ruby or Node.js. People expect compatibility concerns to be taken seriously here.

The things enabled by this change seem very minor, compared to the mess it has caused, despite the GCC developers' heroic efforts to ease the situation. Especially the list thing seems downright ridiculous. You could just track the length yourself, if you need constant time access to it, couldn't you? That's what people that actually needed it were doing all along, I guess. It doesn't enable anything that wasn't already trivially possible before.

Now, I assume the C++ committe members are smart guys, probably smarter than me. So why did they do it? I can't seem to find a convincing rationale for it.

GCC 5.1 released

ncm — Fri, 24 Apr 2015 22:17:34 +0000

I noticed the hash containers seemed to be missing lots of constructors.

GCC 5.1 released

jwakely — Thu, 23 Apr 2015 10:35:10 +0000

I might have missed something, but I think it's complete :-)

GCC 5.1 released

mcatanzaro — Thu, 23 Apr 2015 02:06:47 +0000

Well he says "the Standard C++ Library has full C++11 support and experimental full C++14 support" so it seems clear enough to me :)

GCC 5.1 released

ncm — Thu, 23 Apr 2015 00:14:16 +0000

It probably should say it has full core-language support for C++14. I don't think the standard library is there yet.