Date: Sun, 19 Dec 2021 17:45:16 -0500
I see! Wonderful guide, then and thank you very much for distributing this. I’m sure to use it.
WL
> On Dec 19, 2021, at 5:07 PM, Matt Bentley <mattreecebentley_at_[hidden]> wrote:
>
> 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
>>
WL
> On Dec 19, 2021, at 5:07 PM, Matt Bentley <mattreecebentley_at_[hidden]> wrote:
>
> 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
>>
Received on 2021-12-19 16:45:21