On Sun, Nov 4, 2012 at 9:21 PM, Paul Mensonides <pmenso57@comcast.net> wrote:
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
If gnu++11 is used, the goal of the authors isn't portable code, is it? Basically you'd like to 'force' them to use c++11 by taking away the extensions?
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.
I agree
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
For an app it's easy to depend on another lib. But for a lib, depending on another lib that might not be easily available / installable can be problematic.
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).
They could be better but I don't think calling them fundamentally broken is fair. -- Olaf