Always thought it was strange that fptan also pushes 1 to the register stack. It now makes sense it’s so existing code for the 8087 which was expected to do y/x to get the actual tangent could keep working by doing y/1 on newer processors.
One of the reasons I dislike boost is in the first code sample. What’s the point of implementing what boils down to a 10 line function (as shown in the decompiled output) like this
This is called template-based compile-time programming.
By making 3 instances of linear_feedback_shift_engine class template ( and 2 of xor_combine_engine ), you are forcing the compiler to expand the code exactly as-is 3 times, each with different parameters.
The parameters to the template are constant, therefore the compiler can easily look at how they are used and you are guaranteed ( even in a 1999 c++ compiler ) that the compiler will look at the copies of the code and merge them as much as possible into a single piece of code... which is the one that you see when you decompile the code.
So in summary, it means that you get to write fairly readable code while the final binary is fully optimized as-if you had spent the time merging all the variants as needed for the specific constants.
My point is that the straight-line non-templated function presented later in the article is significantly more readable, it’s like 8 lines of code with a few shifts and xors.
I completely agree. Every time I remove boost from projects the build times drop dramatically and it usually doesn't take much work to swap the boost code for something else that isn't template fetish art.
To do it in almost-plain C, you'd need fairly complex macros that are more difficult to write correctly.
To do it in plain C without macros, or plain C++ without templates... you'd need to work out the combination of the template expansion yourself and write down a piece of code that is more likely to have bugs and more difficult to understand.
I'm not quite sure: you could probably use plain C functions, and a reasonably smart compiler could see through it all and inline and duplicate and merge the code as necessary.
EDIT: I just had an AI agent run the experiment. At least for my version of clang, they produce the same assembly for x86_64 (modulo using slightly different registers).
> Base84 distinguishes uppercase and lowercase letters, so different encoded names can compare equal on a case-insensitive filesystem.
I understand for the authors particular application the probability of collision is small, but this makes this encoding completely impractical for filenames generally.
> Perhaps surprisingly, the ZIP file puts the central directory - which lists the content of the ZIP file - at the end of the file
This is very common for archive files. It lets you easily append a file to the end of the archive (overwriting the directory) followed by the updated directory. If it were at the start, you’d have to rewrite the entire contents of the archive to grow the directory.
I always assumed you could work around this by pre-allocating a large enough header space to hold a reasonable sized directory tree. You could even then append a supplementary directory if you run out of space and just stick a pointer in the first one. I'm pretty sure that's just reinventing an actual filesystem, but if it works...
Losing the back half of the achieve doesn't lose your directory list. (Truth be told, I prefer the approach of sticking a copy on the front and back for redundancy, but I appreciate that that's a very specific tradeoff)
Maybe. But Unix types have always been all-in on tar. They love tar. They continue to use some form of tar to this day.
This was actually a 'cultural issue' back in the day, because Sun Java JAR files were just ZIPs. For good reason. But that wasn't the blessed holy unix archive format.
I'm curious, is there a reason why you can't incrementally prepend to files? I haven't seen a filesystem that allows prepending to a file without rewriting the entire file. Is it just because it's not traditional, or is there any particular technical reason why it would be too expensive, or etc?
In a world long accustomed to "append only" files, use cases would be relatively few.
Vs. the folks creating and testing filesystems would have to do a whole lot of work to add that feature. Followed by the folks doing higher-level software, most of which which need to handle files being prepended to.
In short - interesting idea, not worth the effort.
the size of the prepended data would rarely be an exact number of blocks such that it became purely a metadata update (see also: inode small file optimisation), and thus you would have a small "hole" in the file between the new data and the existing data, which would have to be bookkept safely.
Do you really need a central directory? The tar and cpio file formats basically append files serially with a small header preceeding each one, and for most use cases this is sufficient.
I think this is no longer true. C++26 implemented a change to make trivial loops like these defined behavior (and therefore will loop endlessly as you'd expect). And this example was always defined behavior in C.
Both languages continue to have examples of slightly more complicated loops that can be assumed to terminate in the absence of side effects, but `while(true)` isn't one of those any longer.
My Kia Soul has a version of this, but it doesn't integrate with Carplay, and the maps that came with the car are already outdated enough to bother me.
It's a non-fix if I have to do that every year (or every however-often-I-notice-an-error, the first error I noticed was within a year). Google Maps is constantly updated. Not to mention that Kia aren't going to be supplying updates in 10 years, while Google probably are (and if they aren't, I can still use Carplay and a different set of maps).
Carplay's a better fix for the map issue, since then I don't have to update them whenever I find an error. With Carplay, errors instead don't happen.
The directions being shown in the gauge cluster via carplay is still not a thing on later Kias from what I can tell, so that problem is unfixed no matter what.
The only errors I find are opening hours and similarly trivial things; things that my car's built in nav doesn't even have. A road not being there or it having been moved or whatever has never happened to me while using Google Maps, so while it's not perfect when you're browsing, for actual navigation, it's been perfect for me.
I understand this logic, but at some point it makes sense to design the system for the millions of people on macs rather than make compromises for the sake of dozens of Vision Pro users.
