what I had in mind, one must do some well tested "things" like std::vector
with reserve, and avoid std::optional for the moment.

alternatively he / she needs to implement the questionable "thing" himself
/ herself.

This is only if performance is really important.

Current construction can be done:

1. std::vector
2. array of std::optional *
3. array of std::unique_ptr *
4. array of pointers to dynamic allocated objects *
5. static_vector (C++20 suppose to have one)
6. selfmade solution.

I would avoid solutions with *

regards

On Thu, Sep 3, 2020 at 2:58 PM Eyal Rozenberg <eyalroz_at_[hidden]>
wrote:

> That is an interesting point. Can you elaborate on what about the
> (typical) implementation causes performance issues? The link you gave is
> about not noticing a noexcept, and is resolved as a clang bug.
>
> Eyal
>
> On 02/09/2020 23:19, Nikolay Mihaylov via Std-Proposals wrote:
> > To be honest, std::optional is not the most performant code, see
> > following for std::varian, which is similar.
> >
> >
> https://stackoverflow.com/questions/62404209/why-does-clang-handle-exceptions-for-this-trivial-stdvariant-code
> > <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F62404209%2Fwhy-does-clang-handle-exceptions-for-this-trivial-stdvariant-code&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7Ce80ac1516fad444d93aa08d84f7d95de%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637346748100280955&sdata=FJXtWgQEv2mbpPuDaByqVfNFcrYOmtm6GgNsgeYGGr0%3D&reserved=0
> >
> >
> > but you can always use a char / byte array and use placement new - will
> > be more difficult to code, but in this way you will be able to know
> > "what happens" all the time.
> >
> >
> >
> > On Wed, Sep 2, 2020 at 10:43 PM Ville Voutilainen via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> > wrote:
> >
> > On Wed, 2 Sep 2020 at 22:35, Steve Hearnden via Std-Proposals
> > <std-proposals_at_[hidden]
> > <mailto:std-proposals_at_[hidden]>> wrote:
> > >
> > > Thanks for your replies. I think that std::optional is similar to
> > what I was thinking about, but was requesting an extension to C++ to
> > produce different behaviour.
> > > The implementation of std::optional with my Microsoft compiler has
> > a union which is something like....
> > > union {
> > > char _Dummy;
> > > T _Value;
> > > };
> > > This is an excellent example of my use-case. The code in the
> > library has to side-step the behaviour of the compiler of
> > constructing items, and would be replaced by my proposal with ....
> > > [[unconstructed]] _Value;
> > > We would simplify implementations of std::optional, focusing on
> > the behaviour we require, rather than hiding from the compiler the
> > use cases.
> >
> > Well, anecdotally, at least one maintainer of std::optional doesn't
> > need another way to spell "union". The same maintainer
> > calls into dispute the suggestion that this facility simplifies the
> > implementation of std::optional, because the pre-c++23 versions
> > of it would need to use a union anyway.
> >
> > Having a core language attribute with semantic effects seems like a
> > very poor way to support something as uncommon
> > as this, especially when it's just another way to spell
> > already-existing ways to implement the same thing.
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden] <mailto:
> Std-Proposals_at_[hidden]>
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> > <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7Ce80ac1516fad444d93aa08d84f7d95de%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637346748100290948&sdata=UmxhFmg%2FxoAQwQfvg1Hx%2FLVhrNXMnGhnJ%2Bl%2Bk%2FjMZPQ%3D&reserved=0
> >
> >
> > *This email is from an external mail server, be judicious when opening
> > attachments or links *
> >
> >
>