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.
@pedromiguelareias Жыл бұрын
Great talk! Very clear, unpretentious and informative. and are our new best friends. Raw loops are 90's technology 🙂
@TheSulross10 ай бұрын
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.
@russCoding Жыл бұрын
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.
@ACCUConf Жыл бұрын
Thank you for your appreciation of this presentation.
@MelodiousThunk Жыл бұрын
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; }
@IrfanButt4 ай бұрын
A brilliant talk, very well delivered, thanks Roger!
@ACCUConf4 ай бұрын
So very pleased to hear from you regarding how much you appreciated Roger Orr's presentation.
@Roibarkan Жыл бұрын
27:31 Sean Parent’s “No raw loops” talk: kzfaq.info/get/bejne/p65mpraA15Pdm2w.html
@anon_y_mousse7 ай бұрын
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++.
@TranscendentBen Жыл бұрын
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.
@ABaumstumpf11 ай бұрын
"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.
@vytah11 ай бұрын
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.
@OlaInTheClouds10 ай бұрын
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.
@anon_y_mousse7 ай бұрын
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.
@szaszm_11 ай бұрын
I would be interested in the stories between the two hands up who found bugs in std::accumulate.
@Dazza_DooАй бұрын
You can see The Churno's channel code review on a PHD implementation of Ray tracing with in a weekend. Benchmarks were done and it was painful.
@abhinavk0929 Жыл бұрын
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
@RockTo1110 ай бұрын
How I do reverse loops: int i = my_max_value; while (i--->0) { // do stuff }
@vytah11 ай бұрын
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.
@superscatboy11 ай бұрын
This also has the doubly secret feature that a longer arrow speeds up the loop. idx-->0; // okay I guess idx---->0; // 2x faster!
@sergeiborodin9254 Жыл бұрын
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.
@ABaumstumpf11 ай бұрын
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.
@superscatboy11 ай бұрын
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.
@yarmgl16139 ай бұрын
Backwards compatibility is a blessing
@jadetermig20858 ай бұрын
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.
@aftalavera7 ай бұрын
Bro I guess you are wrong
@celalergun2 ай бұрын
I hate putting the ampersand and asterisk signs left-aligned. I teach newbies by asking this: int* a, b; and then I ask the type of variables. Most of them say they are both pointers. No, they are not.
@joseoncrack5 ай бұрын
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.
@rashshawn779 Жыл бұрын
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.
@sejtano10 ай бұрын
"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