Hi William,

so just to clarify, this isn't a prototype for any kind of technology,
or switching mechanism, or anything like that.

As stated it's a guide for people trying to clarify which container they
should be using based on performance characteristics (based on usage).

It's not limited to the standard library, which is why plf:: and absl::
and tsl:: containers are included (as they are better for certain
scenarios).

It's well-acknowledged that for example the std::unordered_map
specification prevents optimal implementation for most scenarios, which
is why the absl:: equivalents are used.

Thanks for the input regarding the non-static nature of non-std::
libraries though, that is a good point. But it's also a point in their
favour, as non-std:: libraries can more easily adapt to changing
architecture, should architecture change significantly enough that the
specification needs to change to maintain performance - which has
happened over the past 20 years. Whereas std:: libraries can't - by
definition, once defined, unalterable. Pros and cons there.

Thanks,
M@


On 19/12/2021 11:38 pm, William Linkmeyer wrote:
> I’m freshly new to the SG’s, so please do take my commentary with
> caution.
>
> 1. Great work on the theory, definitely provides a structured way to
> choose containers.
>
> 2. Seems rather tool-dependent. The PLF container library you
> reference will change and is not part of the standard. Shouldn’t the
> efforts here be focused on improving the standard?
>
> 3. Would this be implemented at compile-time, run-time, or as a build
> tool?
>
> 4. If compile time or run time, would this be a language feature or a
> library feature (can this be done with templates and type traits?)
>
> If this can be done with templates and type traits and I haven’t
> misunderstood anything else, how would it be implemented? Surely this
> should be a feature akin to an “auto” container, right? And surely you
> wouldn’t mind sticking to std features strictly (no pfl).
>
> WL
>