For instance, if you want to avoid unnecessary copy operations when returning a string, just return it in variable that you pass by reference (eg. void doSomething(string& str);)
likewise avoid the vector class making unnecessary copies, simply by creating the objects on the heap and use a vector of pointers instead of values.
It's a bit more ugly, but it works, and you don't need to read a 24 page blog to understand all the corner cases where it can go wrong.
modern c++ is all about syntactic suger.
Agreed that c++03 was much simpler, but that doesn't change the fact that there are useful things that are possible in modern c++ that simply were not possible before.
Like if I have a vector<std::string>, in c++03 when it resizes it must copy every string from the old storage to the new storage. For a vector of size N, that's up to N+1 allocations (allowing for the possibility that std::string uses the small string optimization).
Granted, std::string doesn't have to allocate when copied if it's a "copy on write" implementation. IIRC, there were some implementations that used that technique when c++03 was the latest, but I don't think there are any that still do, due to other problems with COW.
In modern c++, that same vector resizing operation requires exactly one allocation (for the new vector storage), because all the strings can be moved from the old storage to the new.
Yes, you could have a vector of pointers to std::string, but now you've got yet another allocation (and indirection on access) for every string. In practice that tradeoff almost never makes sense, unless perhaps the strings have shared ownership (e.g. vector<shared_ptr<string>>).
Ultimately, I think there's really no question that the vector resizing optimization described above is useful in certain scenarios. Having said that, I do agree that the associated complexity is annoying. Therefore, the real question is whether it's possible to have these benefits with less complexity, and I personally don't know the answer to that.
Tanks don't really make any sense. MBTs are designed to fight other MBTs. Out of the thousands of tanks that have been taken out in Ukraine, 99.999% has been by drones, artillary or ATMs. You can count the tank versus tank battles on the fingers of your hand. Wouldn't make more sense to evenly distribute the weight of the armour, so the back and top are reasonably armoured, rather than have foot thick armour in the front to stop rounds from other MBTs - a scenario which literally never happens.
MBTs make plenty of sense even if tank on tank fighting is rare. Having a big cannon that can fire high explosive rounds with a laser rangefinder in an armored enclosure is pretty useful even if you're not fighting tanks. Many western tanks have also been retrofit with additional armor against chemical rounds and mines, or have active protection systems.
Being in a T-72 with an armor configuration from the 80s and a carousel auto loader in the middle of the crew compartment in a war where your enemies have top attack atgms with tandem warheads would suck a lot though.
I'm surprise people say it had gory videos. I've being watching Liveleak for the last year. There were hardly any videos with violence and gore. The videos could be classified into 4 categories: traffic accidents, drunk/stoned people doing stuff, police cam recordings, industrial accidents (cranes, ships crashing etc.)
My HP Pavillon with windows hibernates reliable today,
my very old netbook acer with Ubuntu/LXDE did so, too (but that was years ago).
Nowdays I gave up with linux laptops to even enable it, as it is quite complicated to set it up when you dual boot and use encryption. And after I did set it up, it failed over 50% of times on various devices so I did not bother anymore.
Same, the main instabilities come when I go out of hibernation with changed hardware, ie. haven't plugged back the mouse or changed the display from desk to meeting room
OpenAI actually burnt $12B in just one quarter (not for the entire year as he claims)
https://www.thurrott.com/a-i/openai-a-i/329108/openai-lost-1...