Re: [boost] C++ announcements coming tomorrow

Subject: Re: [boost] C++ announcements coming tomorrow
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-11-04 16:55:42

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.

Sorry, but this is crap:

Foo^ foo = ref new Foo();

> 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 is not to say that particular feature extensions aren't useful. 
That is not to say that they can't be implemented and deployed faster 
than the C++ standard release cycle.  However, the minor gains of 
feature extensions are drastically outweighed by the lack of portability 
that results.

Regards,
Paul Mensonides