Sign in to follow this  
Matt Green

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

Recommended Posts

Matt Green    152
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
jdhardy    469
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
jdhardy    469

#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
Sneftel    1788
which is weird, because we already have std::for_each. If only they'd chosen to add lambdas instead.

Share this post


Link to post
Share on other sites
SirLuthor    364
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
Sneftel    1788
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
SiCrane    11839
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
Washu    7829
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   
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
SirLuthor    364
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.

Share this post


Link to post
Share on other sites
doynax    850
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
Sneftel    1788
Quote:
Original post by Anonymous Poster
m$

Ho HO! The subtextual irony is so fresh, so biting! My hat is off to you, Sir!

Share this post


Link to post
Share on other sites
Arild Fines    968
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
doynax    850
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
snk_kid    1312
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
Promit    13246
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
Matt Green    152
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

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