Re: [boost] C++ announcements coming tomorrow

Subject: Re: [boost] C++ announcements coming tomorrow
From: Cory Nelson (phrosty_at_[hidden])
Date: 2012-11-04 17:14:07

On Sun, Nov 4, 2012 at 3:55 PM, Paul Mensonides <pmenso57_at_[hidden]>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