On Sun, Nov 4, 2012 at 3:55 PM, Paul Mensonides <pmenso57@comcast.net>wrote:
On 11/4/2012 1:14 PM, Andrey Semashev wrote:
I'd say you idealize too much. Surely, a lot of code can be written in a
platform-agnostic way, relying on the standard C++ only. But there is a significant range of tasks that benefit from compiler extensions, and that's not only OS-dependent things. Take manual vectorization for instance, this is a CPU-specific thing which by definition cannot be fixed in the standard. Generalized implementations are possible but IMHO they will never be as efficient. Or multi-module interfaces - the differences between OS implementations are too deep. Or for how long the "long long int" type was an extension?
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. E.g. MS's AMP extensions:
parallel_for_each( sum.extent, [=] (index<1> idx) restrict(amp) { sum[idx] = a[idx] + b[idx]; } );
This should be:
parallel_for_each( sum.extent, [=] (index<1> idx) _Pragma("restrict(amp)") { sum[idx] = a[idx] + b[idx]; } );
I.e. for necessary extensions, pragmas should be used so that 1) the language itself isn't modified, and 2) the code would work correctly (if not terribly efficiently) if the pragma was ignored.
The extensions for C++/CX and C++/CLI are even worse because they actually subvert the entire language by forcing the limited .Net runtime model on the language which is a massive regression.
C++/CX is sugar for building and using Windows RT COM objects. It does not involve .NET _at all_. Not in your code and not hidden in the runtime background. Furthermore, both of them are intended for use as a bridge into the Windows platforms at the outer edges of otherwise portable, standards-compliant code. You're not supposed to use them as your primary language. Resume (slightly more informed) venting. -- Cory Nelson http://int64.org