321–330 of 334 posts
Earlier quoted context omitted.
A fresh build of a large C++ project taking 1 hour does not sound strange at all. If that's an incremental build though (i.e. simply rebuilding after changing a few files), there's something very wrong.
Your org needs better distributed build caching if you can't get that number lower. All builds should be "incremental" with appropriate caching.
Earlier quoted context omitted.
You can construct the vector with a given size. As long as you don’t push_back, beyond capacity, these should be o dynamic allocations. If you want to get f cy you can also give it a custam allocator and throw an exception if you do this by mistake
> As long as you don’t push_back But that's the point. You _can_ push_back, or resize, or reserve, etc. etc. My claim is that the more common use case is the one where this _cannot_ happen. > If you want to get f cy you can also give it a custam allocator And then nobody will want to use it, because that's not interchangeable with containers vector with the default allocator, and also difficult to understand. I mean,…
Also, do I understand correctly that you want both the capacity and the size fixed, i.e., the container's elements have to be pre-constructed and supplied to the constructor via an initializer list?
Earlier quoted context omitted.
> Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming. Why, exactly, is the c++ std::sort "wrong"? There are tradeoffs both ways. You happen to prefer stable sorting to speed, but that is a preference not an objective fact.
> Why, exactly, is the c++ std::sort "wrong"? It's silently an unstable sort, which is surprising, and then to add insult to injury it's also slower. Yeah, I know, the C++ unstable sort is so slow it's slower than Rust's stable sort. YMMV for input types, sizes etc but generally that's what the numbers look like and though it's not universal it's actually quite common. "I bet the C++ is faster" is the wrong instinct,…
Earlier quoted context omitted.
> Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming. Why, exactly, is the c++ std::sort "wrong"? There are tradeoffs both ways. You happen to prefer stable sorting to speed, but that is a preference not an objective fact.
> Why, exactly, is the c++ std::sort "wrong"? It's silently an unstable sort, which is surprising, and then to add insult to injury it's also slower. Yeah, I know, the C++ unstable sort is so slow it's slower than Rust's stable sort. YMMV for input types, sizes etc but generally that's what the numbers look like and though it's not universal it's actually quite common. "I bet the C++ is faster" is the wrong instinct,…
Sort stability does not matter when the sorting key is the only thing in your data being sorted. E.g. When I sort my M&Ms by color, I never keep them in the same order, because it doesn't matter. A red M&M is a red M&M. Nobody expects their red M&Ms to remain in the same order after sorting. I do tend to expect my M&M sorting to happen in-place. I expect to not need to provide additional candy holding bowls to later clean up that were used for temporary storage while my M&Ms were getting sorted. But I'll optionally grab additional bowls when I'm in a time crunch it if it speeds things up...
Now, if we're sorting all the cars on a parking lot by color, it may be more important to keep all the red cars in the same order where they started, for example if they were previously already sorted by brand, it /can/ be useful if that is preserved. But it's not guaranteed to be important or useful. Maybe the rich owner just want to torch all their red cars all together. I typically won't have access to additional temporary parking lots only used during sorting, or maybe the owner is coming with a flame thrower at 1PM and it has to be done as fast as possible whatever the cost. There is a tradeoff, rent additional parking lots during sorting, or take more time and do in-place stable sorting, or jumble up the car brands.
So what I want is control. That's all. Whether or not the ambiguous term 'sort' is stable or unstable, or in-place or not is just semantics. The only way to get clarity is to either use prior agreement, or to not use ambiguous names. Maybe a language should ban 'sort', and only allow 'foo_sort_bar' names with stability of memory usage postfixes or prefixes to 'inform' the developer. Neither choice is ideal and will satisfy everyone. It's like being a DJ at a high school party.
I'm not saying that the STL is great in practice, since it appears to optimize for usage flexibility with defined algorithmic and memory complexity at the big-O level, and mostly disregards actual real-life metrics. Arguing, however, that a language or library is better because an objectively ambiguous choice was made differently than your expectations is like arguing for fundamental superiority of either endianness over the other.
Ken Thompson's criticism of C++ as incoherent, complex and garbage heap of ideas still resonates with me; C++98 was the last version I used for work although I've dabbled in 11/17/20 out of curiosity. IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use, but then, that's its main identity which limited it in ways that C++ was not willing to change; It is highly irritating to…
> IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use Obviously. C++ was a "better C" in that you could keep a lot of your "legacy" C code while improving your codebase piecemeal with C++ features. Your management didn't even have to care, in that C/C++ was accepted as a valid descriptor even by people who should have known better. It's a wonder Java/C# and Perl/PHP never c…
Earlier quoted context omitted.
Many browser rendering engines are built in C++, so C++ is parsing the HTML. My general point is that many web/internet techs that web devs interact with have C++ one abstraction level below for actual implementation.
All widely used HTML engines are C++. Of the up and coming ones, Servo is Rust and Ladybird is C++ potentially moving to Rust. In any case, Rust is basically C++ 2.0 to me because it is very much in the spirit of C++.
It is kind of ironic that Rust will outlive Firefox as Mozzilla's legacy.
Earlier quoted context omitted.
It may not be an abstraction of a real machine. But the C abstract machine is very close to the foundational idea of how a computer work. And it’s quite easy to bootstrap.
Importantly my work involves me often being able to look at C and think about the assembly and back and I regularly work on ESP32, ch42(riscv) and atmega avr8. I couldn't do that with mciropython on any platform. C is a thin abstraction, python isn't.
Earlier quoted context omitted.
> Why, exactly, is the c++ std::sort "wrong"? It's silently an unstable sort, which is surprising, and then to add insult to injury it's also slower. Yeah, I know, the C++ unstable sort is so slow it's slower than Rust's stable sort. YMMV for input types, sizes etc but generally that's what the numbers look like and though it's not universal it's actually quite common. "I bet the C++ is faster" is the wrong instinct,…
You are failing to make an argument for why stable sorting is objectively the correct choice. Just because something doesn't match your expectations doesn't make it wrong.
It's surprising that C++'s development trend continues. When a game or program is made with C++, it's usually nice because performance is mostly guaranteed. But if someone told me to write C++ myself, I'd cry. There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult. I'd be happy if som…
Earlier quoted context omitted.
Wow is this just a shitpost (it was funny!) or do your builds actually take about an hour? That's nuts, if so.
A fresh build of a large C++ project taking 1 hour does not sound strange at all. If that's an incremental build though (i.e. simply rebuilding after changing a few files), there's something very wrong.