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]>
>> 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
> 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
>> > 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk