Repository navigation
C++11 features #13
Description
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.
Activity
bnoordhuis commentedon Oct 22, 2014
NB: I filed node-forward/node#30 ("src: replace NULL with nullptr") earlier today. Replacing
NULLwithnullptrseems like an uncontroversial and unequivocally good change to me.indutny commentedon Oct 22, 2014
I would vote for none. But
nullptrsounds reasonable indeed.dshaw commentedon Oct 22, 2014
@bnoordhuis Do we also need to consider embracing anything from the Blacklist too? http://chromium-cpp.appspot.com/#blacklist
bnoordhuis commentedon Oct 22, 2014
@indutny I added more commits that introduce other C++11 features so you can see for yourself what it would look like.
Taking
overrideas 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::atomicandstd::unique_ptr, I can see us using those.)bnoordhuis commentedon Oct 22, 2014
@indutny Also, when you say "I would vote for none", you should at least try to argue your case. :-)
trevnorris commentedon Oct 22, 2014
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 commentedon Oct 22, 2014
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 commentedon Oct 22, 2014
I wonder if we could move to use clang on every platform.
bnoordhuis commentedon Oct 22, 2014
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 commentedon Oct 22, 2014
Using clang on every platform would even the field, both linux and windows users would usually lack the tools to compile addons.
bnoordhuis commentedon Oct 23, 2014
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 commentedon Oct 23, 2014
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 commentedon Oct 23, 2014
@bnoordhuis I was lead astray by this:
Depending on clang head is a bit of a barrier to entry to node dev,
aptitude install build-essentialis 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.
rvagg commentedon Oct 23, 2014
FYI, re Microsoft, they have new options for Visual Studio versions (as they do with every release ...), to successfully compile Node with the latest V8 you need "Microsoft Visual Studio 2013 Windows Desktop Edition" plus the Windows SDK 8.1. It's pretty specific now, I'd love for clang to be a viable alternative, that'd likely radically simplify things, particularly for native addon builds which is just crazy for the average Windows Node developer.
The fact that C++11 is going to be mandatory will mean that it opens up interesting possibilities for addon developers too, unless they want to ensure 0.10 (and prior) support where addon consumers don't have to have such modern compilers. But still, all documentation and recommendations will shift to C++11 compilers anyway so even people using 0.10 are likely going to have modern toolchains that enable C++11 features.
rmg commentedon Oct 23, 2014
Ignoring the platform SDK requirements.. the idea that clang binaries could be distributed via a node-gyp like module would awesome.
kkoopa commentedon Oct 24, 2014
This is going to open up an avalanche of spurious issues along the lines of "Installation Error With Turbo C++ 3.0 / GeOS"