What's important is you know the trade-offs you are making.
You can't have a bounded queue that is always non-blocking because slow consumers can block producers.
You can't have a global FIFO order + multiple producers without slow producers blocking consumers.
You can't have a global FIFO order + have have non-atomic reserve and commit without a interrupted/de-scheduled producer thread being able to block the consumer
If you want atomic commit then you lose separate reserve which means either unbounded memory or atomic fixed-size data with sentinel values, ABA problems etc.
There are trade-offs everywhere, and it's best to pick the data structure that fits your needs just like any other problem.
Theres no technical reason one should look better than the other.
Both should use multipass ahead of time compression with a rate control algorithm, and both should have enough slack streaming bandwidth to handle complex scenes with buffering
In well thought out C++ software lifetime rarely becomes an issue because deciding on ownership and object lifetime is unavoidable as part of the design process.
You still need to send a digital image from the id, signed by an authority, saying "this person is 18"
You then still need a trusted ID service or algorithm to capture an image of the user _at the time of use_ to compare that to.
Just having access to your digital ID credentials proves nothing
The zero knowledge proof only helps prevent tracking between the ID service and the website you're logging into. This is valuable but requires standardisation and client side support, which doesn't exist.
All the time the client side is implemented by JavaScript served from the server side you're just trusting these parties to behave and not snoop
But to be effective you need to prove that the person presenting the ID is the person the ID belongs to.
In person that falls to a human being, and it's an easy and intuitive task that takes seconds.
On the internet this involves some kind of video recording being sent to some agency somewhere being paid a fee, who may later be asked to prove the efficacy of their service. This agency needs a digital copy of the photo from your ID for matching purposes. They'll be tempted to store this for auditing purposes... they'll also be tempted to store correlation IDs etc if the architecture allows.
The issue is trust. You just can't trust these first and third parties not to collaborate for commercial gain or at government demand or request.
And ultimately you're still exchanging verification at registration for a shareable credentials: I could use my ID to sign up to pornhub premium and then sell the username and password to a 16 year old if I wished, just like those buying alcohol can go and give it to the underage. A black market for digital credentials is even easier to establish than material goods
> However, I've heard that in HFT, they don't do that because the overhead itself is too costly.
I've worked at several HFTs and 2 had independently settled on 64bit signed fixed point with a implied 10^9 scaling factor between internal systems.
However in-process one just used 'double' for all FX conversions, scaling etc. With 15 digits of precision and careful rounding choices it's fine.
Dealing with the outside world you'd obviously just convert as cheaply as possible - and there are some crazy fast algorithms doing fast binary float -> correctly rounded decimal conversions these days
I worked on a trading system dealing with transaction limits expressed in USD but trading in many currencies.
FX rates and prices were expressed in fixed point because it was more efficient to handle in FPGA. A lot of thought went in to making the system accurate enough based on real FX rates while falling on the right side of the limit
My goto these days (and afaik the state of the art) is boost::unordered_flat_set paired with rapidhash for hashing (since the GNU std::hash functions based on murmurhash are ridiculously slow)
The cacheline performance is pretty hard to beat (SIMD optimised linear scan before hopping), which is where all the wins come in the real world.
But basically any of the faster hash maps from absl, boost or folly are going to wreck the standard library in terms of perf