Elysian Shadows

TheBuzzSaw wrote: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.

• 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.

TheBuzzSaw wrote:Psh. Go back to your C#, heathen!

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

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

ismetteren wrote:

Rapid Cube wrote: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..

• 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.

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

[closures](parameters) { code }