On 11/4/2012 5:57 AM, Olaf van der Spek wrote:
On Sun, Nov 4, 2012 at 2:43 AM, Paul Mensonides <pmenso57@comcast.net> wrote:
I disagree with the view that it's categorically wrong for compiler vendors to implement extensions, as long as there is a way to turn them off, and as long as the standard library works in a std-compliant way when they're off.
To be clear, I understand the need for compiler-specific things like pragmas (and maybe even things like __stdcall and __cdecl). I do have a problem with feature extensions of any kind, however. The reason is not because I believe the language to be sacrosanct so much as that it breeds lack of portability.
Does it? If the goal is portable code, you compile the code on multiple platforms and compilers, and unintended use of extensions is easily detected. Lack of full support for standard C++ or C++11 and bugs are a much bigger problem IMO as they sometimes require non-trivial workarounds that complicate the code.
Yes, it does. Taking aim at GCC instead, a huge amount of GNU code will not compile without --std=gnu++11 instead of --std=c++11. Even more of it won't compile without a POSIX environment--even ignoring the build system and autotools. The point is that, in many cases, portability should be accidental. I.e. with relatively few platform-specific exceptions (which should be isolated and generalized) programming is done against the abstract machine specified by the C++ standard. That's the compiler user's part of the contract. The compiler developer's part of the contract is to implement a compiler that compiles the language specified by the C++ standard. Sure, lack of full support for the language and the presence of bugs are a huge problems. However, towards the end of 2012, I'm not particularly irrated by the current state of C++11 conformance. I am irrated by set in stone "won't fix" responses to bug reports and broken, mis-implemented features.
If compilers implemented 100% of the language (allowance being made of course for features recently added to the language) and did not provide extensions (which by their very existence encourage their use), then libraries can be developed to generalize platform-specific details (not compiler-specific details) (e.g. Boost.Filesystem, Asio, etc.) and a hierarchy of portable libraries *can* be developed.
Some libs should be part of the standard to lower the barrier to start using them.
Of course. However, I consider that to be a means to guarantee that the presence of those libraries included in the "price" of the compiler and support of that compiler. There is no way that every useful library in every useful domain can be added to the standard library. For C++ software development to really flourish, libraries from outside the standard need to be portable and reusable. Take file system and networking libraries, for example. I can use those libraries regardless of whether the standard contains equivalent libraries because Boost contains them. I think adding networking support and file system support to the standard library is a good thing, but I can do those things now and fairly easily because Boost developers tend to bend over backward to make things as portable as possible. But it should not be so difficult to write portable code. We should not need to have a Boost codebase that is saturated with workarounds. Whose fault is that? The presence of those workarounds is a symptom, but what is the root cause? Compilers. And Boost is just one collection of libraries. Yes, some libraries like Filesystem and Asio have to contain platform-specific code (i.e. alternate implementations for different platforms), but they encapsulate and generalize the platform differences. In some ways, that is their most important function.
Building/using a (C++) library on Windows is also far less than ideal, which IMO is a big problem for C++ on that platform.
Well, we all know Windows is fundamentally broken and getting worse. If you use VC++ on Windows, yes. I use one of the MinGW ports of GCC on Windows or a cross-compiler, and other than over-reliance on --std=gnu++XX and piss poor support for some of libstdc++ where its implementation is heavily dependent on POSIX (e.g. threading), it appears to work well. I use Boost a lot and don't have trouble building it except altering the jam file every time to replace mingw with gcc. I also use Qt for UI-related stuff, and building that is not terribly difficult either. It gets more difficult with other libraries because when libraries "support" Windows, that tends to imply VC++--which is a problem. We need to get to a point where one doesn't target *compilers*. Instead one targets C++ and some platform. From there, we can generalize the platform-specific parts with libraries such that everything else can target C++. OTOH, Linux has its issues also such as its massive assumption of a system-wide particular version of GCC with no C++ ABI encoding in the shared object versioning. The Linux package management models (i.e. apt-get, rpm, emerge) are also fundamentally broken because they don't scale (many-to-one-to-many vs many-to-many). Regards, Paul Mensonides