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.
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. Building/using a (C++) library on Windows is also far less than ideal, which IMO is a big problem for C++ on that platform. Boost appears to have the tools to partly solve this, maybe we should look into that too. Olaf