On 11/4/2012 2:38 PM, Andrey Semashev wrote:
On November 5, 2012 1:55:42 AM Paul Mensonides <pmenso57@comcast.net> wrote:
On 11/4/2012 1:14 PM, Andrey Semashev wrote:
I am not against all extensions. I am against *feature* extensions. There is a place for *necessary* extensions, and, in those cases, lack of the presence of those extensions should easily fallback to the actual language. Hardware vectorization is one example of that. If it exists, it should exist as a compiler-specific pragma which can be ignored. Further, no feature extension to the language is good if the feature could be implemented via library--i.e. it should not have language extensions solely for the purpose of syntactic convenience.
IMHO, pragma-controlled compiler-generated vectorization is a utopy, except for the very trivial things. Real benefit is provided by extensions like __m128 and intrinsic functions. Also remember the mentioned typeof and long long. Some things cannot be implemented on the library level efficiently, and pragmas are not the silver bullet.
WRT typeof, something like decltype would have come around without GCC's typeof. WRT to long long, nothing in the standard says int == long. Similarly, lambda comes around without a vendor implementing an extension due to heroic efforts of library developers whose task was made drastically more difficult due to lackluster compilers. In the theoretical case where all C++ compilers implemented the standard and were bug-free, how does one write portable code in C++ without it being a mess of #ifdefs for every processor architecture and platform? If that is a pipe-dream, then C++ is dead. With something like hardware vectorization, there will be some cases where architecture/platform/compiler-specific code is necessary. However, the majority of code does not require it--even when performance matters. The majority of code does not require the compute potential of the LHC.
I agree, some things could have been done differently. I don't really understand why that CLI extension is needed, so I didn't ever use it. Guess what, I couldn't care less it's there. And since it's not in the core language and I haven't seen it in the public code yet, I'd say the industry largely rejected it.
Maybe so, but my primary concern is not about C++/CLI, C++/CX, etc., or even extensions. My concern is about MS saying one thing and then doing another in such a way that I consider it to be purely marketing driven, misleading and unethical if not outright deceptive, and actually attempting to cause client code to be MS-specific regardless of what MS representatives are saying. WRT to language extensions, it may not be avoidable in all cases, but it is avoidable in most cases. Every single extension branches the language and makes it more difficult to write portable code, more difficult to write tooling that has to interpret the code, and has the overall effect of stunting technological growth.
Look at extensions from another perspective. They are often a playground to test new features that may eventually, after usage experience is gathered, go into standard as a new feature. Only extensions are available here and now and not in a few years when the new std paper rolls out. This is pretty much like how it goes with libraries.
And they are used in production code, not playground code, and then go on to interfere with standardization because of attempts to be backward compatible with things that never officially existed.
That's the way the field experience is gathered. Someone suggests an extension, the industry tests and refines it. If it proves to be useful, it goes to the standard. There are downsides but that's how the progress works.
If an extension is targetted at standard C++ and the purpose is actually to gather field experience, that's one thing. It is another when it is simply a vendor abusing their power to get their way in spite of the committee. Regards, Paul Mensonides