Most CPU's has signed and unsigned right shift instructions (left shift is the same), so yes it works (You can test this in C by casting a signed to unsigned before shifting).
The biggest caveat is that right shifting -1 still produces -1 instead of 0, but that's usually fine for much older game fixed-point maths since -1 is close enough to 0.
However, there is a quirk of the hardware of most CPUs that has been inherited by the C language and by other languages.
There are multiple ways of defining integer division when the dividend is not a multiple of the divisor, depending on the rounding rule used for the quotient.
The 2 most frequently used definitions is to have a positive remainder, which corresponds to rounding the quotient by using the floor function, and to have a remainder of the same sign with the quotient, which corresponds to rounding the quotient by truncation.
In most CPUs, the hardware is designed such that for signed integers the division instruction uses the second definition, while the right shift uses the first definition.
This means that when the dividend is a multiple of the divisor, division and right shift are the same, but otherwise the quotient may differ by one unit due to different rounding rules.
Because of this, compilers will not replace automatically divisions with right shifts, because there are operands where the result is different.
Nevertheless, the programmer can always replace a division by a power of two with a right shift. In all the programs that I have ever seen, either the rounding rule for the quotient does not matter or the desired definition for the division is the one with positive remainder, i.e. the definition implemented by right shift.
In those cases when the rounding rule matters, the worrisome case is when you must use division not when you can use right shift, so you must correct the result to correspond to rounding by floor, instead of the rounding by truncation provided by the hardware. For this, you must not use the "/" operator of the C language, but one of the "div" functions from "stdlib.h", or you may use "/" but divide the absolute values of the operands, after which you compute the correct signed results.
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.
reply