Sign in to follow this  

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

This topic is 4390 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Try it! The syntax is for each(type declaration in collection). I'm not compiling with /clr at all, and it works just fine. I've been using BOOST_FOREACH for awhile now (macro'd to foreach()), but it will be very hard to avoid this in the name of portability. :)

Share this post


Link to post
Share on other sites
I'll be damned, it does work.


#include <vector>
#include <cstdlib>
#include <algorithm>
#include <iostream>

using namespace std;

int main(int argc, char* argv[])
{
vector<int> numbers;
generate_n(back_inserter(numbers), 10, rand);

for each(int i in numbers)
{
cout<<i<<endl;
}

return 0;
}




EDIT: MSDN.

Share this post


Link to post
Share on other sites

#if _MSC_VER >= 1400
#define foreach(var, container) if(false) {} else for each(var in container)
#else
#define foreach(var, container) BOOST_FOREACH(var, container)
#endif



Now it's portable.

EDIT: ...as long as you only iterate over standard containers, since Boost.Foreach also supports iterating any Boost.Range.

[Edited by - jdhardy on December 3, 2005 3:21:16 PM]

Share this post


Link to post
Share on other sites
Now that's just plain messed up. I mean, everyone knows there is no such thing as a for each construct in C++, so, WTF? Adding obviously non-standard things like that is, in my opinion, not a very clever thing for Microsoft to do..

Share this post


Link to post
Share on other sites
Huh, that does look intersting. Still, I'd prefer real lambdas built into the compiler, rather than brittle template hacks which produce 200-line error messages.

Share this post


Link to post
Share on other sites
Quote:
Original post by SirLuthor
Now that's just plain messed up. I mean, everyone knows there is no such thing as a for each construct in C++, so, WTF? Adding obviously non-standard things like that is, in my opinion, not a very clever thing for Microsoft to do..


It's probably just an artifact from the C++/CLI for each construct. Basically it was already in the compiler anyways.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Quote:
Original post by SirLuthor
Now that's just plain messed up. I mean, everyone knows there is no such thing as a for each construct in C++, so, WTF? Adding obviously non-standard things like that is, in my opinion, not a very clever thing for Microsoft to do..


It's probably just an artifact from the C++/CLI for each construct. Basically it was already in the compiler anyways.


Exactly. The for each, in construct was designed for C++/CLI, however in building it they also added support for arrays and standard C++ containers.

Share this post


Link to post
Share on other sites
Guest 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++ :(

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

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites

This topic is 4390 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this