C++11 features

[bnoordhuis]

Filing the issue here because node-forward/node is currently private and I want this to be a public discussion.

Per the upgrade to V8 3.29 in commit node-forward/node@6bcea4f, we are now building the project with -std=gnu++0x. (Coincidentally, that means VS 2013 is now required on Windows.)

The question: what C++11 features do we want to use and why?

Chromium follows these guidelines. That's a good if perhaps somewhat conservative starting point.

/cc @indutny @piscisaureus @trevnorris

[bnoordhuis]

NB: I filed node-forward/node#30 ("src: replace NULL with nullptr") earlier today. Replacing NULL with nullptr seems like an uncontroversial and unequivocally good change to me.

[indutny]

I would vote for none. But nullptr sounds reasonable indeed.

[dshaw]

@bnoordhuis Do we also need to consider embracing anything from the Blacklist too? http://chromium-cpp.appspot.com/#blacklist

[bnoordhuis]

@indutny I added more commits that introduce other C++11 features so you can see for yourself what it would look like.

Taking override as an example, it makes the compiler yell at you when you change a base class in an incompatible way. It helps you catch bugs and that's undeniably a good thing, right?

@dshaw Most of those features are blacklisted because of a certain crappy compiler... That's also an important reason of why C++11 library functions are verboten. I'm afraid we'll have to restrict ourselves as well, for now at least.

Things that are under consideration, like move semantics or whether or not to use C++11 STL features, don't really affect node because we are not heavy users of containers anyway. (Though I could probably make a case for things like std::atomic and std::unique_ptr, I can see us using those.)

[bnoordhuis]

@indutny Also, when you say "I would vote for none", you should at least try to argue your case. :-)

[trevnorris]

Usually "more features" is inevitably followed by "more overhead". Though the ones you've discussed so far don't seem to fall into that category.

Though, now that Node requires C++11 does that also mean libuv can start using C99?

[bnoordhuis]

Regrettably, no. The reason libuv stuck with C89 is that MSVC doesn't really support C99 and never will. You could perhaps carve out a common subset but that's it. I move that we do libuv2 as a from-the-ground-up rewrite in C++11. :-)

[piscisaureus]

I wonder if we could move to use clang on every platform.

[bnoordhuis]

Probably. According to the compatibility page, it's not 100% compatible with MSVC yet but it's probably good enough for our purposes. With clang HEAD from a few weeks ago, I was able to compile a non-trivial add-on and load it with a node.exe built with MSVC.

[sam-github]

Using clang on every platform would even the field, both linux and windows users would usually lack the tools to compile addons.

[bnoordhuis]

You've got that wrong, Sam. This is about building node with clang, not add-ons.

The key is ABI compatibility. Clang emits code that is compatible with the platform's ABI on the Unices and it's getting there on Windows. That means users can build their add-ons with the compiler that suits them best and the result should Just Work(TM) with clang-compiled node.

[kkoopa]

Can't you hold off until M$ releases Visual Studio 14? I refuse to upgrade from 2010 until the menus STOP SCREAMING AT ME.

[sam-github]

@bnoordhuis I was lead astray by this:

With clang HEAD from a few weeks ago, I was able to compile a non-trivial add-on and load it with a node.exe built with MSVC.

Depending on clang head is a bit of a barrier to entry to node dev, aptitude install build-essential is not too bad, but svn cloning and building clang is a bit time consuming. Hopefully building on windows isn't too epic.

Perhaps depending on clang can wait until clang has binary releases for the platforms node supports, or recent linux distros package a useable version.