Re: [boost] C++ announcements coming tomorrow

Subject: Re: [boost] C++ announcements coming tomorrow
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-11-04 18:08:31

On 11/4/2012 2:38 PM, Andrey Semashev wrote:
> 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.

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