The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
While I use lambdas in my C# code, I don't consider them especially 'advanced'. Most of the time I'm actually averse to using such features in any language, because they tend to encourage writing clever code rather than maintainable code. Since I have code in the field older than some of you folks reading this, maintainable wins.
I sporadically read news about new C++ features. None of them inspire me, as they whiff strongly of compiler weenies saying "look what I can do!". They are also overly-reliant on templates, and I find the syntax clumsy and verbose. I consider myself well-skilled in C++, and look for productivity-enhancing changes to the language. They're few and far between.
C# is somewhat a different story. Most of the features I read about seem designed to improve productivity and code quality, even when they are dismissed as 'syntactic sugar'.
I find it interesting that many seem to think 'var' is such a bad thing. In C++, there's the auto keyword, and there's even the complementary keyword decltype which is particularly useful when you want the result type of an expression, or the return type of a function.
As I understand it, auto fills a similar role as var does in other language(s?), and there's actually a coding guideline promoted by Herb Sutter, no less, to 'aaa', or 'almost always [use] auto'. One of the main reasons is to help enforce type safety, which of course is outstandingly important in C++, probably more than in any other language. Another reason is maintainability: every use of auto probably doesn't need to be changed when you change some type in your code later.
That said, I often deliberately don't use auto, for one (or both) of two reasons: helping with autocompletion (the editor sometimes won't know what member variables and methods to suggest when dereferencing an auto variable), readability (provided the type name is easy enough to read, rather than a nested<type>::with<template_arguments>), and disambiguation (when I want the value to remain unchanged - i. e. const - rather than modifiable). I suspect the former will no longer be a reason when we finally manage to switch to a newer IDE version later this year, that's why I said two reasons
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
I guess I don't have to explain myself
The customer always does an export at the end of the day, at least according to the customer.
They can't even not do it because their business depends on it.
Needless to say, that's not how they work at all and I just got a month worth of exports all at once
Of course, my code can't handle this because of reasons (mostly because of a ridiculously complicated pre-XML format that I have to use).
The project is over budget and I can't spend any more hours on it.
Sometimes I think I've chosen the wrong profession
Yes, there is a translation step necessary when dealing with customers and those terms. Never means more like in around 10% of cases. Always is more like 75% of cases. Exceptions are definitely the rule.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"