Should the C++ compiler run in C++11 mode by default?

[pchapin]

The build of the C++ library is failing for me (SuSE Linux) in the cpplib/iostream library with the message: "Error! E938: col(10) 'auto' is no longer a storage specifier in C++11." This is in the file cpp/iofoutfl.cpp on line 73.

I don't see any particular reason for 'auto' being used there, and it could be removed. However, I'm concerned that this error might be appearing when the compiler is running in default mode. Are we compiling the C++ library in C++11 mode (i. e. with -za0x)? I wonder if, for the sake of compatibility with legacy software, 'auto' should remain a storage class specifier when compiling for the older standard. Perhaps its use should elicit just a warning in the default mode.

I'm actually fairly open to the idea of abandoning the earlier standard. I just want to make sure that is, in fact, what we intend to do. If it is, then maybe we should drop the -za0x option and compile in C++11 mode all the time.

[pchapin]

I removed all uses of 'auto' in the C++ library since they weren't needed anyway. The question of if we want to use C++11 mode all the time remains open. I'm inclined to go for it!

[jmalak]

I am not sure if it is good idea for now. Existing C++ compiler have missing important feature that compile something in C++11 mode could be danger if we implement more C++11 features, but not full C++11 feature set. We should define minimum C++ standard which we want to support. Now OW C++ compiler is not compatible with any standard.

[bmanga]

I think we should consider that after we have rvalue references, which I would say are the main game changer for the c++11 standard library

Edit: You seem to say that the auto error message pops up when no -za0x flag is passed. If that's the case, it is a bug. It should only be diagnosed if you enable c++11 .

[bmanga]

This also brings up the fact that we should starting considering a multi-standard c++ library

[pchapin]

I'm not sure, @bmanga, if the -za0x flag was present or not, to be honest. All I can say is the error was coming up when the C++ runtime library was being built (I have since removed 'auto' from that code). I'm going to guess we aren't using -za0x then, but I admit that didn't dig through the various layers of makefiles to check.

As far as supporting multiple standards go, I question if we have the developer resources to do that. I can understand trying to support a purely standard mode versus a mode with extensions enabled, but keeping multiple standards distinct might be more trouble than it's worth to us. Just a thought.

In any case, I don't feel worried about having a partially standard compiler; Open Watcom has been that way for years. So I tend to favor the idea of enabling whatever C++11 functionality we have by default and moving forward from there. It shouldn't introduce any incompatibilities of significance aside from the new reserved words. Programs should be "encouraged" to not use the new reserved words anyway!

[bmanga]

By multi-standard library I meant creating the macros for

#ifdef LIBOW_CXX11_AND_ABOVE
// ... move constructors and new features
#endif 

as I am not sure what kinds of macros the compiler injects when compiling in different modes.

Enabling c++11 will work until we implement something that breaks old code. I guess this is another point in favor of creating release tags. We can then progress more freely and give users the choice of picking whatever version they need.

[jmalak]

I changed OW compilers that include _preincl.h file (you can specify different name) per compilation unit. This way is now handled __STDC_LIB_EXT1__macro for this CRTL feature. This functionality could help with various standard C++ run-time library build.

[pchapin]

I believe there already is a macro that is enabled with C++11 mode is turned on (Jiri, does that sound right?). If so, could we use that macro in the library to select the C++11 material without introducing a LIB... macro as well?

As someone who has worked on the C++ library this topic interests me. I've added some (largely empty) header files for the C++11 library; at this point it wouldn't be difficult to qualify any new library components with a macro. If we think that's a good idea, what macro should we use?

BTW, I solved the mystery of the unknown -za0x option... It turns out I had a WPP386 environment variable set in my login script that included that option so it was automatically being applied everywhere. Should the setvars scripts override any externally applied environment variables? I don't know. Anyway, I can work around the issue here now that I know what it is.

The good news is that now everything builds in the C++11 mode supported by Open Watcom (I'm using Open Watcom as my bootstrap compiler).

[jmalak]

The macros which depend on language standard must be defined by compiler which handle language standard version. But not all things are related to language standard, by example some features related to run-time implementation that it is what I mean where this special header file can help.

[revelator]

I hope not, its has been a royal pain in the ass since gcc took that step to compile sources that do not follow c++11 standards :S. And there is also still problems if you try linking stuff that is not c++11 standard with stuff that is. Firebird sql is one such example, it has not been buildable with any compiler from gcc past 5.3.0 and no flags trying to circumvent c++11 has ever worked. C++11 would be a nice addition though but i would prefer that the compiler defaults to c++89 standards with switches for c++11.