VS8 adds for each as a nonstandard unmanaged C++ extension

Started by
18 comments, last by snk_kid 18 years, 4 months ago
I think it sucks that m$ build all this non-standard stuff (ie. keywords for clr stuff) in C++, so that it will become a m$-C++ :(

I think this stuff could also be done with "normal" C++ coding, no need for new m$ keywords
Advertisement
And now loads of people will be using something non-standard, because it's easier. Those words rarely denote something good in the making. Hurray for even less portable code.
Free speech for the living, dead men tell no tales,Your laughing finger will never point again...Omerta!Sing for me now!
Quote:Original post by Anonymous Poster
I think it sucks that m$ build all this non-standard stuff (ie. keywords for clr stuff) in C++, so that it will become a m$-C++ :(
'M$' are hardly the only ones at fault here, GCC has an enormous amount of useful proprietary extensions.

Sometimes I wonder whether it's really worth the effort to continue writing portable code..
Quote:Original post by Anonymous Poster
m$

Ho HO! The subtextual irony is so fresh, so biting! My hat is off to you, Sir!
Quote:Original post by Anonymous Poster
I think it sucks that m$ build all this non-standard stuff (ie. keywords for clr stuff) in C++, so that it will become a m$-C++ :(


C++/CLI Language Specification Standard

In September, 2003, Ecma Technical Committee TC39 created Task Group 5 (TG5) to create a standard for the language C++/CLI, based on a submission from Microsoft.

When TG5 has completed this specification, it will be submitted to the Ecma General Assembly (GA) for consideration as an Ecma standard. Once it has been adopted as such, the specification will be submitted to ISO/IEC JTC 1 via the latter's Fast-Track process.


Quote:
I think this stuff could also be done with "normal" C++ coding, no need for new m$ keywords

You could do it with assembly as well. Adding expressiveness to a language isn't about "being able to do" something.
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
This is the way new features have historically been introduced into standard. Compiler vendors are supposed to try out the new features as proprietary extensions first, not just pull new ones out of thin air and hope they're useful and implementable. Just consider the whole exported template fiasco..

There are a few counterexamples, such as C89's function prototypes, but they're the exception rather than the rule.
As far as i'm aware no other C++/CLI keyword/component is leaked/available into VC++ 8.0's std C++ mode when CLR switch is off.

Take note that C++/CLI is a separate initiative from std C++ not solely owned by MS and the C++/CLI team work closely with the C++ standard committee some of whom are actually members of the C++ standard committee (notably Herb Sutter) so even though they are separate standards (of-course C++/CLI depends on C++) they will and already are beginning to influence each other (for instance nullptr).

[Edited by - snk_kid on December 3, 2005 5:21:00 PM]
For the morons complaining about VC/MS adding language extensions, just realize that EVERY compiler does it. GCC is a major offender, with things like variadic macros, the long long data type, and nested { } blocks that can return values.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
Quote:I think this stuff could also be done with "normal" C++ coding, no need for new m$ keywords

Except for the fact that the standards board moves at a glacial pace.

Other useful nonstandard unmanaged extensions in MSVC 8:
* __declspec(dllexport)/__declspec(dllimport)
* __declspec(selectany)
* __declspec(property)
Quote:Original post by Matt Green
Other useful nonstandard unmanaged extensions in MSVC 8:....


Just as if not more useful Compiler Support for Type Traits for implementing TR1 or boost type traits.

This topic is closed to new replies.

Advertisement