This is great information.
Sounds like it is ready for use, but perhaps it is best to use a subset of features first. Perhaps r-values, lambda and auto (although it does seem strange for a strictly-typed language paradigm).
In your experience, where would you suggest one go for tutorials? From the comments I gather that it's not just the mechanics that need to be learned, but the conceptual aspects too. It could change the way that C++ is used. It kind of reminds me of the C++ evolution from 'is-a' to 'has-a' thinking (ie inheritance v composition). Also, has anyone experience of native threads, and are they portable?
[Edited by - random_thinker on November 5, 2010 5:58:24 AM]
C++0x Opinions: ready to be used in projects?
Quote:Original post by visitor
More meaningful use cases would be such where there is something to infer:template <class Range, class Value>auto find(Range& range, const Value& what) -> decltype(range.begin()); //returns Range::iterator or Range::const_iterator depending on constness of Range
I suppose the argument gets pedantic at this point, but the type inference in that example is accomplished by the decltype operator. That is, the result of decltype is a concrete type, so auto is still really only acting as a placeholder for the concrete type which is evaluated later on the line.
EDIT: I guess you could put it this way: in your example, decltype means "deduce the type of the following," but auto doesn't--you can have a function signature which uses type inference without auto, but not without decltype.
[Edited by - Shinkage on November 5, 2010 5:35:02 PM]
Quote:Original post by random_thinker
Sounds like it is ready for use, but perhaps it is best to use a subset of features first. Perhaps r-values, lambda and auto (although it does seem strange for a strictly-typed language paradigm).
The 'auto' keyword doesn't give you dynamic typing or loose typing -- the types are still as strong as they always have been, 'auto' just tells the compiler to figure it out itself. If you do 'auto i = 10;', then 'i' is then and will always be an 'int'.
Now, 'auto' in the context of, say, a template argument (as in Visitor's example) or a resultant type (as in my earlier example, which should have read 'decltype' also, instead of 'typeof') uses the the type-inference mechanism to provide something which appears to be more than static typing, but which is really just the natural extension of type inference applied to the multiple resulting contexts of template instantiation. In the past, you would likely create a number of typedefs for your class to define what these dependent types are, but 'auto' can do that now, and a lot more conveniently to boot. 'decltype' expands 'auto's reach even further by allowing types to be calculated at compile time. The application of 'auto' to function signatures is especially significant, as there was previously no way to accomplish the same before C++ 0x.
Author
The compiler support is greatly varied, but it seems that GCC, MSVC, Intel and a few others from time to time, support the following:
auto
decltype
lambda
long long
right angle brackets
rvalue references
built-in type traits
There are a few other things that I would like to use but I can't find anything about compiler support. These are:
range for statement
initializer lists
and STL improvements:
thread
new pointers
new containers
time utilities
TBH, I'm using boost to do the things that are new in the STL. So that's not so critical. But the other stuff looks very beneficial.
Since I'm using GCC 4.4 under Fedora (GCC seems to be the early adopter of C++0X), then I don't expect that I'll have trouble using any of these. I would expect that the Apple OS would also be easily ported, and that MS Windows Vista or 7 would too. For other platforms I just don't know.
There appears to be a huge range of actual proposed features, but these features (other than the above) are some ways away from widespread adoption, it seems.
I'd be interested to see what the views are on the approach I'm proposing, that is to take the above subset of features and begin applying them in my work.
auto
decltype
lambda
long long
right angle brackets
rvalue references
built-in type traits
There are a few other things that I would like to use but I can't find anything about compiler support. These are:
range for statement
initializer lists
and STL improvements:
thread
new pointers
new containers
time utilities
TBH, I'm using boost to do the things that are new in the STL. So that's not so critical. But the other stuff looks very beneficial.
Since I'm using GCC 4.4 under Fedora (GCC seems to be the early adopter of C++0X), then I don't expect that I'll have trouble using any of these. I would expect that the Apple OS would also be easily ported, and that MS Windows Vista or 7 would too. For other platforms I just don't know.
There appears to be a huge range of actual proposed features, but these features (other than the above) are some ways away from widespread adoption, it seems.
I'd be interested to see what the views are on the approach I'm proposing, that is to take the above subset of features and begin applying them in my work.
Quote:Original post by random_thinker
There are a few other things that I would like to use but I can't find anything about compiler support. These are:
range for statement
initializer lists
GCC Support
So GCC supports both of these, but the version you're using only the second of them. If you're using GCC, I can't think of any reason NOT to go ahead and start bringing C++0x into your project, unless there are others working on it who might object.
Actually, I think the latest MSVC supports a very nicely chosen subset of features to start using immediately. This particular subset is unlikely to undergo changes before finalization.
Author
Quote:Original post by ShinkageQuote:Original post by random_thinker
There are a few other things that I would like to use but I can't find anything about compiler support. These are:
range for statement
initializer lists
GCC Support
So GCC supports both of these, but the version you're using only the second of them. If you're using GCC, I can't think of any reason NOT to go ahead and start bringing C++0x into your project, unless there are others working on it who might object.
Actually, I think the latest MSVC supports a very nicely chosen subset of features to start using immediately. This particular subset is unlikely to undergo changes before finalization.
Thank you for your help and the link. GCC 4.5 seems to be a really major upgrade with the inclusion of the MPC library and profiling. Looking forward to that.
We use GCC exclusively except at times under Windows where MSVC has some advantages.
Quote:Original post by random_thinkerQuote:Original post by ShinkageQuote:Original post by random_thinker
There are a few other things that I would like to use but I can't find anything about compiler support. These are:
range for statement
initializer lists
GCC Support
So GCC supports both of these, but the version you're using only the second of them. If you're using GCC, I can't think of any reason NOT to go ahead and start bringing C++0x into your project, unless there are others working on it who might object.
Actually, I think the latest MSVC supports a very nicely chosen subset of features to start using immediately. This particular subset is unlikely to undergo changes before finalization.
Thank you for your help and the link. GCC 4.5 seems to be a really major upgrade with the inclusion of the MPC library and profiling. Looking forward to that.
We use GCC exclusively except at times under Windows where MSVC has some advantages.
The latest version of MSVC supports the following features. If you have VS 2010 you can use this.
Author
Thanks for the link to MSVC 10. Looks like the way to go in Windows.
Just discovered that GCC 4.4 does not support lambda. [sad] Have to upgrade to 4.5 for that, it seems.
Also investigating Windows cross-compile environment within Fedora.
Just discovered that GCC 4.4 does not support lambda. [sad] Have to upgrade to 4.5 for that, it seems.
Also investigating Windows cross-compile environment within Fedora.
Just occurred to me...
void one() { }
void two() { }
void three() { }
void four() { }
int main()
{
decltype(&one) f[] = {one, two, three, four};
for(int i = 0; i < 4; ++i)
(f)();
return 0;
}
Gotta love decltype. :-)
void one() { }
void two() { }
void three() { }
void four() { }
int main()
{
decltype(&one) f[] = {one, two, three, four};
for(int i = 0; i < 4; ++i)
(f)();
return 0;
}
Gotta love decltype. :-)
Quote:Original post by keinmann
auto str = "Hello world!";
Did you intend const char* or std::string?
There is no ambiguity. The right hand side is of type 'char*'. If you intended str to be an STL string, you should have explicitly written 'std::string("Hello world!")', but that obviously defeats the whole purpose of using 'auto'.
That said, 'auto' wasn't really meant to be used for simple types. It's especially useful when composing complex templatized types. So it is recommended to always avoid using 'auto', unless you really determined it's the most elegant solution with minimal drawbacks.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
