Very happy with C++11
-
I've been using the auto keyword, lambdas and move constructors so far and all seems very cool. If the only thing they added was the auto keyword it would still be worth upgrading. This is just awesome... auto it = someCollection.begin(); ...but of course the downside is we now need cbegin() as well
-
I've been using the auto keyword, lambdas and move constructors so far and all seems very cool. If the only thing they added was the auto keyword it would still be worth upgrading. This is just awesome... auto it = someCollection.begin(); ...but of course the downside is we now need cbegin() as well
This might help in lot of cases, but I really wonder if C++ 11 can reduce the pain of memory mangement. In my experience, auto variables are hardly I needed for my development. but really got tired of several gotchas and memory corruption and management with C++
-Sarath.
My blog - iSpeak code
Rate the answers and close your posts if it's answered
-
I've been using the auto keyword, lambdas and move constructors so far and all seems very cool. If the only thing they added was the auto keyword it would still be worth upgrading. This is just awesome... auto it = someCollection.begin(); ...but of course the downside is we now need cbegin() as well
_Josh_ wrote:
auto it = someCollection.begin();
[puts on curmudgeonly old git voice] A total abomination which will lead to lazy programmers (as if there weren't enough already), and unreadable code.
One of these days I'm going to think of a really clever signature.
-
I've been using the auto keyword, lambdas and move constructors so far and all seems very cool. If the only thing they added was the auto keyword it would still be worth upgrading. This is just awesome... auto it = someCollection.begin(); ...but of course the downside is we now need cbegin() as well
you've come a long way, "void *"
-
I've been using the auto keyword, lambdas and move constructors so far and all seems very cool. If the only thing they added was the auto keyword it would still be worth upgrading. This is just awesome... auto it = someCollection.begin(); ...but of course the downside is we now need cbegin() as well
Hasn't
autoalways been a part of the C language? Maybe it has a new meaning these days?"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
-
Hasn't
autoalways been a part of the C language? Maybe it has a new meaning these days?"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
auto will "automagically" derive the type of the expression. For normal simple types it does not add much, but more complex types it can make things easier.
auto i = 0; // kind of useless.
std::vector::iterator iterator = myVector.begin();
auto iterator = myVector.begin(); // much usefull, unless you use badly named variables.It makes things easier when working with lambdas (and I have not use them yet, current project is still VS2008).
Nihil obstat
-
_Josh_ wrote:
auto it = someCollection.begin();
[puts on curmudgeonly old git voice] A total abomination which will lead to lazy programmers (as if there weren't enough already), and unreadable code.
One of these days I'm going to think of a really clever signature.
Don't get me started. Today's object spaghetti makes the old C spaghetti pale in comparison. C++11 advocate: Look, I made the code more awesome. Me: It's slower, more complicated than it needs to be and much harder to find bugs. Why not just use C#? C++11 advocate: But, it's more awesome! (I actually heard someone today advocate that all pointers must be wrapped in shared_ptr, no matter what. I'm even working on some code that did that for absolutely no apparent reason--the delete happens within three lines and there is a catch around the call to which the pointer is passed AND the pointer is not actually shared. Yet, they not only used a shared_ptr, but spent time creating a factory to instantiate the only instantiation ever of the object to which the pointer is passed.)
-
_Josh_ wrote:
auto it = someCollection.begin();
[puts on curmudgeonly old git voice] A total abomination which will lead to lazy programmers (as if there weren't enough already), and unreadable code.
One of these days I'm going to think of a really clever signature.
-
you've come a long way, "void *"
-
Hasn't
autoalways been a part of the C language? Maybe it has a new meaning these days?"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
yep, it has a new meaning. because why clutter the language with a new keyword when you can assign a new meaning to an existing keyword ? efficiency!
-
But the variable is still typed. There is not much in c++ that can't be abused. I think used well auto will make life better.
-
_Josh_ wrote:
I think used well auto will make life better.
I don't see how writing
autorather than a type will make life better.One of these days I'm going to think of a really clever signature.
Just easier. At first I was quite sceptical, anything that looks like it might break c++'s type safety is bound to raise suspicion but after reading and playing with it a bit it's actually harder to shoot yourself in the foot than I'd first thought. The rvalue references are a much bigger change but we've seen some good performance benifits from that.