3

I have a container library that initializes elements only if they are not "is_trivially_default_constructible". In principle, I use the std::is_trivially_default_constructible trait to determine this.

I think this should work if the trait reflects reality, for example ints and doubles are left uninitialized in effect.

1. Is it ok to do that, should I expect some undefined behavior? (Assume that elements are eventually formed by assignment.)

There are plenty examples like that where it is suggested that one uses a special allocator in which the construct function is a no-op.

If the answer above is positive, what can it be said about the following more complicated case:

In turn, I also use the mechanism and "overwrite" the behavior for std::complex<double>. That is I treat std::complex<double> as if is_trivially_default_constructible were true. (It is not true, because the default constructor of std::complex is stupid.)

2. Is it ok if I don't initialize the memory for a type that technically is not trivial to default-construct? Should I "bless" somehow this memory with std::launder or something like that?

alfC
  • 14,261
  • 4
  • 67
  • 118
  • 1
    Only since C++20 do we have implicit lifetime types which `std::complex` is not so the only way to create one is with an initialization (a definition / new) – NathanOliver Feb 11 '23 at 04:56
  • On that topic: `std::complex* cp = std::malloc(elems * sizeof *cp);` - tadaaa? – Ted Lyngmo Feb 11 '23 at 05:56
  • @TedLyngmo. That’s exactly the question. Is *cp a bonafide std::complex for the compiler? – alfC Feb 11 '23 at 06:12
  • @alfC I think that it is since passing a pointer to `complex`s into libraries wanting `double*`s is actually defined to work. I'm hoping for someone more language-savvy to post an actual answer though. If that doesn't happen in a day or two, I might give it a go. – Ted Lyngmo Feb 11 '23 at 06:15
  • std::complex is supposed to be compatible with C complex, so yeah I would say it is pretty safe. – n. m. could be an AI Feb 11 '23 at 06:38
  • @TedLyngmo, so do you think that the special rules that apply to `std::complex` (reinterpretable as T[2]) are saving me? makes sense. – alfC Feb 11 '23 at 06:52
  • @alfC I think it does but since I find the standard hard to read so it usually takes me hours to come to any conclusion (if any) - and I haven't even started looking at it. Perhaps you should add the [language-lawyer] tag on this one? I have a feeling it will come down to a language lawyering answer in the end anyway. – Ted Lyngmo Feb 11 '23 at 08:34
  • Yes, I think the lawyering is what made them write some special rules for complex, see the section "Array-oriented access" in https://en.cppreference.com/w/cpp/numeric/complex. – alfC Feb 11 '23 at 08:36
  • 1
    @alfC Yes, that part I find clear. It's the "object" part that you mentioned above I'm not 100% sure about. C++20's implicit lifetime types that Nathan mentioned is one thing but my gut feeling is that it was defined before that too via piling up a bunch of paragraphs. Just a feeling right now. – Ted Lyngmo Feb 11 '23 at 08:49

0 Answers0