if i could have function overloading, operator overloading (particularly (), ++, --, *) and i could auto-convert my existing codebase to C, i'd move right now to C. i stay with C++03 and thats enough.
https://clang.llvm.org/docs/AttributeReference.html#overload...
Write new code the new way, and leave old code that works alone. There will never be a case where you wonder why old code looks like old code. Continuing to write new C++03 is just masochism.
You might find reasons to switch some old stuff to use move semantics, eliminating reference counts, which is a small job. Leaving alone stuff that doesn't need to change needs only discipline, not time. Discipline builds with use. I recommend it.
disagree. this keeps things simple, readable and maintainable. beyond STL i havent found need for any new data structures or algorithms. i roll my own for domain specific (audio/graphics).
> Discipline builds with use. I recommend it
sure daddy. perhaps if the c++ committee had discipline they wouldnt have added these crazy things to the language too and made it a mess that it is today. however we masochists are pleased with the concession offered by stroustrup's one-liner: 'if u dont use it, u dont pay for it'
Unique pointers pre C++11 are fundamentally broken, and smart pointers are the poster child for modern C++. Other features like nullptr, enum class, range based loops, and constexpr provide huge gains in readability too.
> i havent found need for any new data structures or algorithms
That's great - however the unordered contains are for many people a drop in replacement with a performance boost that came in C++11 .
Along those lines, I think the real disconnect in the argument here is in terms of what kind of problem people are programming for. For many applications, advanced C++ is solving problems they don't have. The above poster mentioned audio. The data there is in single (or perhaps few) big buffers with a very simple and regular structure determined by international standards. They only need a few simple pointers. Or maybe just std::vector. Similarly just a few types also with real-world meanings. Debugging may require them to check the processing in ways that abstraction, type-checking, etc. will only get in the way of. And new features may not work within whatever abstractions had been put into place for previous features anyway, because the features relate to the underlying data.
If you need to iterate over an iterable xs and discover you need the index as well, in Python you shouldn't switch to a loop over the index, you should switch from:
for x in xs:
...
for idx, x in enumerate(xs):
... for (std::unordered_map<std::string, int>::const_iterator it = some_map.cbegin();it != some_map.end(); ++it)
for (const auto& keypair : some_map)
> For many applications, advanced C++ is solving problems they don't have.
No-one here is talking about advanced c++, we're talking modern c++.
> The above poster mentioned audio. ... They only need a few simple pointers...
And we all know that audio is immune from massive security vulnerabilities, right? [0]
"New" features like nullptr (instead of NULL), unique_ptr, move semantics as examples can just flat out avoid classes of bugs that come up in low level programming, and features like constexpr and static assert can make runtime checks compile time checks instead. All these features can be escape hatched if you really really need to just cast to a void pointer to fill a buffer at the end, but the surface area for nasty bugs is significantly reduced if you do so.
[0] https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
Are you saying the creation of security vulnerabilities has decreased in the last ten years.
edit: and as for: "No-one here is talking about advanced c++, we're talking modern c++."
I am. Reconsider your examples in ternms of not just whether someone needs the improvement, but also whether someone actually needs the preceding alternative you are complaining about.
I deliberately made it not work - calling cend instead of end fixes the issue (one which isn't possible possible the range based loops)
> Your second one hides almost everything from me. If the second one fails to compile and gives me a paragraph-long encrypted complaint, I need to somehow half-comment the thing out and create a bunch of test code so I can go in the debugger and figure out what you are actually doing.
And I disagree here. In practice the only issue I've ever seen with range based for loops at compile time is no iterator support. The error on clang and msvc is incredibly clear here. Chances are the compiler error message about comparing a const iterator to a non const iterator is going to be more obtuse
> also whether someone actually needs the preceding alternative you are complaining about.
I cannot think of a _single_ situation where the NULL macro is required where nullptr wouldn't be an improvement. I'm not saying don't use the fundamental constructs when they're needed, I'm saying use the modern alternatives when they're suitable. Unique_ptr and move semantics alone eliminated practically every use after free bug I've seen in the last decade, for example. Enum class is another great example - legacy enums are absolutely chock full of foot guns and I have found countless bugs where someone just passes garbage through. Again those bugs just don't exist with the modern replacement.
Without these the complexity in your example disappears, and every word has direct intuitive meaning. Except for the ugly type expression on the left (which is kind of thing one must love if you endeavored to be a C++ programmer in the first place, though personally I do agree it's increasingly hard to read beyond the most basic cases). Nonetheless, using auto is the cause of the problem I was referring to. This eliminates the remaining half of the ugliness, but now if the code inside the loop chokes in your inputs, I have no idea why. Maybe if I'm lucky the compiler will give me a paragraph that I can try to parse descriing the mess that the object was compiled into, or maybe it will just say "Can't find a suitable template. Have a nice day".
thank god for that. and also thank god that it is not a proprietary language/platform. eg., Apple otherwise we would be mandated to write in the latest C++.
>That you have failed to learn to understand those reasons is not a fault in the >Standard. Blaming your own failure to to learn on the committee does not fool >anybody
what you call as my failure to learn is not remotely unique to me. many others more eminent and eloquent than me (and you too) have said more unkind things about C++, least being the phrase 'cognitive load'.
the 'trouble' with software is it its impossible to leave it alone. an 'update or perish' sword hangs above it. and C++ has swallowed the bait totally. it has competed with the joneses all the time: oh Java has garbage collection, why cant C++ have that too?..oh well cant cos...our users write imperative, sequence critical software that we cant have unpredictable, behind the back GC...so hah smartpointer, nullpointer kludges. oh LISP has lovely lambdas, why C++ has no lambdas?....well we give u lambdas but please close ur eyes to that horror-syntax; hey we can give static const variables values in the struct/class declaration, why not other variables?...sure that isnt a big problem! and the horror of all...C++ so proud of be a type-safe language yet modern programming is all about type-free so hah lets give u auto! what if i used auto as a var name in my code. tough luck. gotta change it dumbo. u are a bad programmer to make a variable name with just 4 letters.
C++ is so thorny, every symbol impregnated with meaning. walking on egg-shells, no wonder they call it 'cognitive load'.
Then you had a syntax error. This is a historic keyword that played a useful role in Dennis Ritchie's B and NB languages, predecessor to C. It was retained as a reserved keyword in C, and into C++.
The use of auto in relation to type inference in modern C++ is a repurposing of the existing useless keyword that has always been there.
but i like to see the types im working with. auto like another poster has said though makes it readable kinda hides the type which idiomatically / stylistically i'm not comfortable with.
Every argument you can cobble together against learning the modern language applies as much to C++03, or '98, or, indeed, C itself. And to programming at all. Ultimately, though, it all amounts to laziness.
So the final position is to stop writing any code, and leave the work to those willing to do the work.
i'm done with learning further in C++. C++03 is enough for my purposes. for other features of C++, id use a scripting language integrated into my C++ app say Lisp, TCL, Python or Lua, a lot cleaner altho a bit slower.