Comparing 'Classic C++' and 'Modern C++' Ways to Solve Programming Tasks - Roger Orr - ACCU 2023
Vložit
- čas přidán 28. 05. 2024
- ACCU Membership: tinyurl.com/ydnfkcyn
Sponsored By think-cell: www.think-cell.com/accu
accu.org
Are the Old Ways Sometimes the Best? Comparing 'Classic C++' and 'Modern C++' Ways to Solve Programming Tasks - Roger Orr - ACCU 2023
Slides: accu.org/conf-previous/accu2023/
A look at some of the places where C++ now offers multiple ways to do the same thing, examining some of the strengths and weaknesses of each approach.
C++ has undergone many changes since the first ISO version was published in 1998.
Some of the features that have been added to the language provide a replacement for existing idioms.
In this talk I will look at some of the trade-offs involved in such replacements and examine some of the strengths and weaknesses of the different ways we have in the current language of achieving the same end.
The set of issues involved include:
- readability and expression of intent
- the likelihood and consequences of things going wrong
- the cost of change
The talk will be based on features of C++, although many of the principles have a wider application.
---
Roger Orr
Roger is an experienced C++ programmer interested in the variety of ways to express ideas in code.
Roger has many years of experience in IT, using a variety of languages and platforms, working for a number of different companies over the years, mostly in the financial sector. His recent work has mostly been in C++, on both Windows and Linux.
Roger is one of the organisers of this conference and also runs the Code Critique column in ACCU's "CVu" magazine.
He is chair of the UK C++ panel and has represented the UK at C++ ISO standards meetings since 2010.
He is a member of the five-person 'Direction Group', that recommends priorities for the ISO C++ standardisation committee.
---
www.accuconference.org/
CZcams Videos Filmed, Edited & Optimised by Digital Medium: events.digital-medium.co.uk
#accuconf #programming #cpp - Věda a technologie
Wonderful talk. I will recommend this to my students who are struggling to learn C++ in the midst of these fluidic standards paradigm shifts. Not for any particular detail, but as a wonderful overview of the situation from a learned perspective.
A brilliant talk, very well delivered, thanks Roger!
So very pleased to hear from you regarding how much you appreciated Roger Orr's presentation.
Great talk! Very clear, unpretentious and informative. and are our new best friends. Raw loops are 90's technology 🙂
With DPDK PMD coding, said code runs on a pinned CPU core and has to be absolutely non-blocking and deterministic.
For loops are explicit and hold no surprises. And do not present a research project that would involve taking (precious dev) time to verify that some library abstraction doesn't harbor any problematic behaviors vis a vis this said programming domain.
24:00 - it shouldn't work with a collection of complex numbers, because result has type int, and std::complex doesn't implicitly convert to int. I tried compiling this in godbolt, and the compiler rejected the *= operation, as expected:
int product(const std::vector& xs) {
int result=1;
for(auto& x: xs) {result *= x;}
return result;
}
I would be interested in the stories between the two hands up who found bugs in std::accumulate.
Thanks for the great talk Roger Orr. The talk was well presented and helped to solidify existing understandings and even shone the light on somethings which I didn't know.
Thank you for your appreciation of this presentation.
What I'd like to see with regard to iterators is something like what I've added to my language where you can designate the return value as completely discardable so the compiler can optimize iterators and not have it++ perform any differently to ++it, regardless of trivial construction. As far as string logging, I personally detest the separated construction of a string to then be converted to another format and then finally be logged. This is why logging functions should be in a similar format to the *printf() family of functions, so you can make a single function call to log a whole mess of data in one call.
I've never liked the format for constructor initializer lists either, especially that it requires duplicating names and using parentheses when a simple equal sign would be better, and then you still have to use braces to signal that its a function definition and that it should do something even if everything it does is initialization that's already been defined. It's not like the compiler can't optimize initialization without using this special syntax, or even that I would advocate specifically for doing it in the function body, but when there's nothing to be done but copying values taken by the constructor it'd be nice if instead the compiler could fill in the boilerplate for you. Although, I very much doubt the standard committee would want to adopt my methodology, so this will likely never get resolved to my satisfaction in C++.
11:51 This is one of the most confusing things about C++ (and there are many) since I started learning it (kinda-sorta at the announcement of C++11, but mostly the last five years). I read some years ago that ++idx was preferred (it runs faster/is more efficient) over idx++ for some arcane reason that I couldn't follow at the time, but it made no sense. I've been using i++ in for loops in C since 1986, but NOW I gotta change. I've since seen Godbout's compiler talk that showed me some amazing optimizations that compilers do, why can't a compiler see that the "returned value" of this expression isn't used, so it makes no difference how it's incremented or whether it needs a temporary to hold the preincrement value. As the speaker says, yes it does figure that out with an int, but an object makes it complicated ... this is a gotcha with C++, it's supposed to be a "higher level language" but it's remarkable how much lower-level detail one has to know about the compiler in order to write the most efficient or "best" code.
"why can't a compiler see that the "returned value" of this expression isn't used"
Basically that is always the case - "i++" and "++i" will be compiled to the same assembly unless you either have all optimisations turned off, or the type you are using has some sideffects from being constructed/Destructed (and of course if you are actually using the returned value)
But just for simple loop-indices or iterators - no there is no difference. use whatever you find more readable.
If you use C++ as a higher level language, you're going to get a higher level language performance. If you want a close to the metal performance, you need to write close to the metal code. C++'s strength is the ability to do both, but it's simultaneously its weakness.
This is not specific to C++, all languages with this operator has to make a copy, increment and return the copy to perform thing++.
thing++ without taking care of the temporary tells me that you don't care. ++thing, is deliberate (if that is what you want ofc). Always code like you mean it! Ofc you can (probably should) assume that the compiler can optimise this, not making a temp if you are not using it, I guess in most cases.
That's definitely one piece of advice I've always hated. Using ++it just looks stupid in that context, and if the iterator has no side effects and/or is super trivial to construct, as it should be, then it shouldn't matter which you use and the compiler should optimize the difference away in this circumstance. I would even argue that at -O0 that it should still automatically convert it++ to ++it in the case of using it in a loop, but that would require a constraint that they're otherwise completely the same, and that might not be true for some non-trivial iterators and undoubtedly a change to the language to allow it with ease would be fought against by many people.
27:31 Sean Parent’s “No raw loops” talk: czcams.com/video/qH6sSOr-yk8/video.html
55:56 the call to log function changed from
log(oss.str()); //oss is std::ostrstream
to
log(std::move(oss).str().c_str()); //oss is std::ostringstream
they should've just provided a c_str() method for std::ostringstream so it would just have been
log(oss.c_str()); //oss is std::ostringstream but changed
I wonder why they went with approach in P04087 instead of just doing this
How I do reverse loops:
int i = my_max_value;
while (i--->0)
{
// do stuff
}
The problem will most modern programming languages that have a large "market share" is that they're not driven by engineering or science anymore, but by mere competition.
C++ gas grown into this monster only in an attempt to keep its market share, or even grow it. (Call that user base if you prefer.) Any newer language that would introduce some new paradigms or even just some new sugar coating would become an inspiration for the next iteration of C++. Just to prevent developers from moving away.
That's just plain marketing. And marketing does infect everything it touches.
That loop from 15:32 could be written with idx--> 0. It means the same (loop when idx-- is not zero), but it looks like a nice cute arrow and for that reason is often mentioned as a "secret arrow operator" in C, and that jocular exposure makes it idiomatic for a small, but not insignificant number of programmers.
This also has the doubly secret feature that a longer arrow speeds up the loop.
idx-->0; // okay I guess
idx---->0; // 2x faster!
In my opinion demonstration of how simple loop can be implemented in 100 different ways demonstrates the fatal genetic illness of C++. And lack of will of C++ community to disavow backwards compatibility and solve them once and for all.
Nah, that is not the problem. Being able to write it in a way that suits your project is, if anything, a benefit.
What is bad is if you are just a troll and intentionally write unreadable code.
The staunch refusal to break backwards compatibility is a strength, not a weakness.
There's no reason to outright ban older idioms and stop them working entirely when they can (and do) happily live alongside newer idioms.
It would be madness to completely break decades of perfectly good code and libraries for no reason other than "that's not how we prefer to do things these days".
It's perfectly fine to come up with better idioms and use them without forcing all previously written code to change to fit the new idiom or die.
I don't know anyone in the C++ world that would encouraging teaching or learning the old idioms or using them in new code, but that doesn't justify breaking old code. I want the C++ I write today to still compile 20 years from now just as much as I want the C++ I wrote 20 years ago to compile today, and there's literally no good reason for that to not happen.
Backwards compatibility is a blessing
Indeed, this sort of madness is why I use C over C++ whenever I get to make the decision these days. There are soooo many more useful things to spend your time and brain cycles on than what flavor of loop to use. These days I practically only write for-loops in C even when a while loop would have sufficed. That's because while loops often end up rewritten as for loops anyway and it gives me one less thing to think about. When I want a loop I automatically type "for" and never think about irrelevant stuff like the one million ways I *could* express this loop. This problem in C++ extends far beyond loops. Consider how many ways to initialize a variable in C++. I don't know whether to laugh or cry when I think about it.
Bro I guess you are wrong
In the strangest way, C++ forces you to learn more about low level stuff more than you need compared to C. You suppose to use the "high-level" zero-cost abstraction and features, but it always has a "gotcha". It is more troublesome than useful. I can see it slowly "evolving" into a legacy language, what an oxymoron.
"modern C++" shouldn't be called C++ anymore, the people who wanted so many changes in the language, effectively subverting this pretty good language, could've, at least, had the decency to change the name, let's say D++ or C+++ or something else, like when they added OOP to C and changed the name
Yep. That's exactly why the modern one sucks.