On Mon, 17 Mar 2025 at 00:49, Jason McKesson via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> 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?

The problem is that when people do want the best performance (why
using C++ if one does not need performance?), the current approach
feels hacky and viral (instead of being principled). Imagine I have an
efficient implementation of BigString, which includes an uninitialized
buffer, and I have:

struct A {
  BigString s[10];
};

struct B {
  A dataA;
  int anotherValue;
};

struct C {
  B dataB;
  char someThingElse;
};

…

Efficient use of all A, B, and C objects will require the use of
[[indeterminate]].

It would be a punishment to people who want to implement Small Object
Optimization....

SOO implementers never want their users to worry about marking
objects. They should not need to.

The intention of having erroneous behaviour is not to penalize SOO,
right? Is erroneous behaviour so good that we do not mind the
collateral damage to SOO and performance?

-- 
Yongwei Wu
URL: http://wyw.dcweb.cn/