On Sun, Mar 16, 2025 at 11:53 AM Giuseppe D'Angelo via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> Il 16/03/25 15:48, Jason McKesson via Std-Discussion ha scritto:
> > If that's how [[indeterminate]] is expected to work, if it's something
> > that most programmers most of the time won't need to think about, then
> > I don't think these disadvantages really apply. That is, it is not up
> > to the implementer of any particular class as to whether or not
> > [[indeterminate]] is appropriate for the class; it's up to the final
> > user of that object on a case-by-case basis. They are the ones looking
> > for that performance benefit, so they are the ones who get to say when
> > to get it.
>
> Well, there are classes that are entirely made to reap extra performance
> benefits; the prime example are the "std::vector<T> with SOO" that exist
> in pretty much every codebase. A user chooses those classes instead of
> std::vector<T> precisely because they're looking for extra performance.
> It's weird to ask them to _also_ annotate such usages with
> [[indeterminate]] (... assuming that they're even using such classes
> directly. If they're wrapped by another class (class Foo {
> SmallBuffer<int> buf; }), then the situation is even clumsier).

Using SOO is primarily about memory allocation performance. That is,
not allocating heap memory unless you go over a certain size. So while
filling those bytes with known values would lower performance relative
to not doing so, the performance lost to that completely different
level from saving a memory allocation. After all, we're talking about
stack memory, which is likely in the cache already.

That is, failure to use [[indeterminate]] isn't going to make using
such types ineffective as performance optimization tools. That doesn't
mean that they may not want to use [[indeterminate]] as well, but I
don't think it's something people have to do in order to get
acceptable performance?