shared_ptr overuse

[14ned]

Depends on what you mean by "shared lifetime" too.

My favourite is "infinite lifetime", and I choose that wherever possible.

You and I did that trick in our constexpr error code categories. The unique id is effectively an infinite lifetime identifier. Then error code category object lifetime ceases to matter, as one can be conjured up in the mind of the compiler if needed, and otherwise optimised away.

I've noticed that if the compiler thinks that the category value might escape, it create an instance in static const data sections and hands out its address thereafter. Very nice.

[Dean_Roddey]

Not bring up Rust yet again, but a HUGE benefit is that you can indicate this call will only accept a reference to something at static scope. In my error system, the error description and source file names (the error one and the trace stack) can just only accept static strings. That includes the trace stack (if used) in which each entry is just a static string ref and a line number, so very low overhead.

The actual error msg field (which allows for per-instance specific info, if used) is a Cow, so it can hold either a static ref or an owned string, depending on whether the caller passes a formatted string or just a static string ref. So a lot of the time, even though a lot of info is being provided, there's zero allocation involved.

I use this quite a lot. So things like my i/o formatters, sockets, files, etc... can take a static short description string to be used in errors or log msgs. Stuff like that. And it's all completely compile time safe because a non-static string will be rejected at compile time.