Date: Wed, 22 Dec 2021 10:07:54 +1300
You're welcome, and thanks for you thoughts-
On 20/12/2021 11:45 am, William Linkmeyer wrote:
> 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
>>>
On 20/12/2021 11:45 am, William Linkmeyer wrote:
> 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
>>>
Received on 2021-12-21 15:08:00