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.
I'm starting to grudgingly think the same. Although I like some aspects of C++, the feature set and evolution over the years bothers me, C++20 seems almost like a different language from C++11, like C++11 was to C++03 but with none of the joy for me, with a lot of features that seem to over complicate things over time detrimental to the improvements they bring.
i write/maintain solo this software for 15 years and just dont want to start doing autos in for loops. then i have to go and change all the loops otherwise it would bother me. i dont want to go back and start messing with code that is pretty solid all these years.
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'
> disagree. this keeps things simple, readable and maintainable
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 .
How hard is it to read a "for" loop? Even when programming in python, half the time I find myself switching to a simple loop over an index because I realize I need the index. Often it's for debugging, because that index has a real meaning I can interpret when I see it.
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.
for (std::unordered_map<std::string, int>::const_iterator it = some_map.cbegin();it != some_map.end(); ++it)
is pretty damn unreadable (and for bonus points it doesn't compile) compared to
for (const auto& keypair : some_map)
Which doesn't have the possibility of the issue in the previous snippet (cbegin != end rather than cbegin != cend)
> 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.
Your examples might fit the discussion better if you made unreadable C++03 code that worked. But nonetheless, I don't agree. I can directly read what your first attempt at a loop is trying to do. 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.
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.
> Your examples might fit the discussion better if you made unreadable C++03 code that worked.
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.
I could be wrong but all the fancy stuff you are doing to impose constants, including your bug, look like c++11 to me.
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".
Your loop body code is choking probably because you have imagined that the loop induction variable is still an iterator. It's not. It is a direct reference to a container element. So, keypair.second, not it->second.
> Even when programming in python, half the time I find myself switching to a simple loop over an index because I realize I need the index.
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:
C++03 is Turing-complete, implying nothing in any newer Standard is "necessary". Yet, many things were added, for reasons. 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.
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'.
Arguments from ignorance always fall on their own sword.
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.
the work is not about the number of programming language features used. its about imagination, addressing a users's need etc.
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.
Yes, it would be better for you to write in those other languages than to continue producing crappy C++ code that others must then maintain at extra expense.
wow, bro i dont remember peeing into your cornflakes this morning :) u know nothing about my work and i dont have to prove it to you. go sell your c++xx (even this naming convention is ugly) to linus. u will get a warm reception :)
It is no crime to think nothing new is worth learning. Still, bragging about it on the internet invites well-deserved scorn. Don't like scorn, don't advertise.
More like, Wirth's Pascal from 1970 has broken, downward-funarg only local functions? So does GNU C. Why can't C++ have some similarly lame local functions? And then make them anonymous like lambda? Only we can't introduce a lambda keyword. I called static's agent, but evidently static is tied up playing five roles already. I know, let's use the array brackets: they have not had a good diddling.
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.
