C++11 (aka C++0x) officially approved

[TheBuzzSaw]

http://www.phoronix.com/scan.php?page=n ... &px=OTc4OA

I didn't pay a ton of attention to this while it was developing. I mostly skimmed over the wiki page and thought, "Hmm, that'd be nice. Oh well." Well, it actually got approved! GCC has already implemented large chunks of it. I guess it is safe to start learning now. :P

Thoughts on this? I'm fairly excited. I hope the native thread support is actually good.

[Kyosaur]

http://www.phoronix.com/scan.php?page=n ... &px=OTc4OA

I didn't pay a ton of attention to this while it was developing. I mostly skimmed over the wiki page and thought, "Hmm, that'd be nice. Oh well." Well, it actually got approved! GCC has already implemented large chunks of it. I guess it is safe to start learning now. :P

Thoughts on this? I'm fairly excited. I hope the native thread support is actually good.

Is it sad that i dont care and am not excited for this new standard?

[TheBuzzSaw]

Psh. Go back to your C#, heathen!

[Nokurn]

I am fucking stoked for this. I was seriously considering porting my engine to GCC 4.7 just to get an early run with the new features.

• The changes to initialization are a pleasure to work with.
• The new for-loop syntax is wonderful for some more lengthy types, ie:

  Code: Select all

  for (std::map<uint, std::vector<uint>>::const_iterator it = items.begin(); it != items.end(); ++it)

  vs:

  Code: Select all

  for (auto const& curr : items)

• Lambda functions are quite nice for simplifying code where you're repeating yourself a lot but don't necessarily need an entirely new function.
• Constructor delegation is something I've been wanting for a while (I don't like creating regular functions to share code between constructors).
• The changes to member initialization are very nice as well.
• I quite like the changes to enumerations, especially enums being their own namespaces. That will improve readability a lot, IMO.
• I was excited for unrestricted unions, until I messed around with them a bit and found that my Vector*D classes are still not considered simple enough to be included in a union. Still no hope for improving the organization of my Event class without sacrificing memory.
• Explicitly declared default constructors will help me resolve some ambiguity in my code. Deleted functions will be nice, too.
• STL threads are going to let me cut out some of the code I've written for doing cross-platform threading (I don't use things like Boost).
• STL regular expressions! These are going to be nice for doing quick bits of parsing that don't really warrant the inclusion of a whole 'nother library just for regex.
• STL random numbers will effectively eliminate the need for my MT19937 implementation and the supporting uniform distribution code.

These are just the reasons that I personally like C++11, though. I feel like it's going to make my code a lot more readable, a lot more concise, better organized, and add some features that I've thought STL has been lacking for some time now.

[Kyosaur]

Psh. Go back to your C#, heathen!

lol im not a C# coder. Im just not excited for this new standard really. I know i probably SHOULD be, but its just whatever to me - nothing jumps out and excites me (i'll of course learn though).

[MadPumpkin]

:D hash tables <3

EDIT: I was just reading through a bunch of it, skimming the rest. It looks like 50-50 on features I'm excited for, versus not/don't care much. I love the new random generator and many other things though. Looks great I never would have known so thanks for the link.

[Rapid Cube]

Does anyone know of a better explanation of how lambda expressions work than the one on Wikipedia?

[Nokurn]

Does anyone know of a better explanation of how lambda expressions work than the one on Wikipedia?

I might be of assistance, if you were to describe exactly what you need more information on.

[ismetteren]

Does anyone know of a better explanation of how lambda expressions work than the one on Wikipedia?

They are just functions without a name. You often use them to pass to functions that take other functions. (higer order functions). I don't really know if this explanation is better though..

[Rapid Cube]

Does anyone know of a better explanation of how lambda expressions work than the one on Wikipedia?

They are just functions without a name. You often use them to pass to functions that take other functions. (higer order functions). I don't really know if this explanation is better though..

I understand the basic concept, its just the syntax that confuses me.

[Nokurn]

A lambda function is declared in three parts:

• Closures - These are variables that you want to be present in the lambda at all times. Consider closures as being like... defining the local scope for the lambda function. These exact variables will always be present in every call to the lambda, unlike parameters, which must be passed every time.
  Closures are placed at the beginning of the lambda declaration, within braces, in a comma-separated list. Variables without prefixes are passed into the lambda by value, meaning that a copy of the variable is created just for the lambda. Variables prefixed by an ampersand (&) are passed into the lambda by reference, so that what you get is a reference to the variable rather than a copy. If an equal sign without a variable is given as a closure, all variables that aren't explicitly named in the closure will be passed to the lambda by value. Likewise, an ampersand without a variable will cause the same effect, but passing the variables by reference.
• Parameters - If I need to explain this part, you shouldn't be thinking about lambdas yet.
• Return type - This functions largely the same way as specifying the return type of a function, with two exceptions: it comes after the parameters, and it isn't always necessary. If you have an extremely simple lambda, ie. "return something;", you can omit the type declaration, and the compiler will use its fancy new type inference to decide what the function's type should be.

So it goes like this:

Code: Select all

[closures](parameters) -> type { code }

Or if you want to use type inference,

Code: Select all

[closures](parameters) { code }

I think that Wikipedia sufficiently explains the specifics of storing a lambda function, so I won't write about that unless you need it explained as well.
Hope this clears some things up.

[Falco Girgis]

Nothing really excites me either, just because I spend all of my time at work and play on embedded platforms whose compilers will probably never support these features.

It's almost worthless to me, to be honest.

[qpHalcy0n]

It's one of those things that language acolytes get wet over.

...It will take years to a decade or never before it sees any widespread usage in the industry.