Re: [boost] C++ announcements coming tomorrow

Subject: Re: [boost] C++ announcements coming tomorrow
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-11-04 17:38:05

On November 5, 2012 1:55:42 AM Paul Mensonides <pmenso57_at_[hidden]> 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.

> E.g. MS's
> AMP extensions:

[snip]

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.

> > 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.