cppan VS abseil-cpp

When I discovered vcpkg I waq very disappointed and started to look for alternatives. I found cppan (https://github.com/cppan/cppan) which was exactly what I was looking for (A bit like npm but for C++). It became sw and I don't really like that name but it's still the best thing I've found for handling dependencies on Windows.

Looks similar to absl::NoDestructor

https://github.com/abseil/abseil-cpp/blob/master/absl/base/n...

Which is basically the only usage of std::launder I have seen

You'll see a fairly even split amongst S-tier, "possibly headed for standardization" level libraries. I'd say there's a skew for `#ifndef` in projects that are more "aspires to the standard library" and for `#pragma once` in projects that are more focused on like a very specific vertical.

`#pragma once` seems to be far preferred for internal code, there's an argument for being strictly conforming if you're putting out a library. I've converted stuff to `#ifndef` before sharing it, but I think heavy C++ people usually type `#pragma once` in the privacy of their own little repository.

- `spdlog`: `#pragma once` https://github.com/gabime/spdlog/blob/v1.x/include/spdlog/as...

- `absl`: `#ifndef` https://github.com/abseil/abseil-cpp/blob/master/absl/base/a...

- `zpp_bits`: `#ifndef` https://github.com/eyalz800/zpp_bits/blob/main/zpp_bits.h

- `stringzilla` `#ifndef` https://github.com/ashvardanian/StringZilla/blob/main/includ...

abseil's "StatusOr" is roughly like Rust's Result type, and is what is used inside Google's C++ codebases (where exceptions are mostly forbidden)

https://github.com/abseil/abseil-cpp/blob/master/absl/status...

Maybe you’d like ABSL_PREDICT macros?

https://github.com/abseil/abseil-cpp/blob/master/absl/base/o...

Their justification is here https://github.com/abseil/abseil-cpp/issues/720

However, I personally disagree with them since I think it's really important to have _some_ basic reproducibility for things like reproducing the results of a randomized test. In that case, I'm going to avoid changing as much as possible anyways.

abseil.io

From the looks of it Rust [1] uses a constant branching factor based on number of items whereas ABSEIL generally uses a target of 256 bytes for branching and fits however many elements fit within that. Rust’s approach seems to be more primitive as ABSEIL is optimizing for cache line usage (not sure why it’s several multiples of a cache line - maybe to help the prefetcher or to minimize cache line bouncing?)

[1] https://github.com/rust-lang/rust/blob/master/library/alloc/...

[2] https://github.com/abseil/abseil-cpp/blob/74f8c1eae915f90724...

[3] https://github.com/abseil/abseil-cpp/blob/74f8c1eae915f90724...

From the screencast:

> implement also for Days

This fails to recognize that this is a bad feature that the Abseil library would explicitly reject (hence the existence of absl::CivilDay) [0], and instead perpetuates the oversimplification that 1 day is exactly 24 hours (which breaks at least twice every year due to DST).

Which is to say: it'll tell you how to do the thing you ask it to do, but will not tell you that it's a bad idea.

And, of course, that assumes that it even makes the change correctly in the first place (which is nowhere near guaranteed, in my experience). I have seen (and bug-reported!) cases where it incorrectly inverts conditionals, introduces inefficient or outright unsafe code, causes unintended side effects, perpetuates legacy (discouraged) patterns, and more.

It turns out that ML-generated code is only as good as its training data, and a lot of google3 does not adhere to current best practices (in part due to new library developments and adoption of new language versions, but there are also many corners of the codebase with, um, looser standards for code quality).

[0] https://github.com/abseil/abseil-cpp/blob/bde089f/absl/time/...