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@technion.ac.il> 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@lists.isocpp.org <mailto:std-proposals@lists.isocpp.org>>
> wrote:
>
>     On Wed, 2 Sep 2020 at 22:35, Steve Hearnden via Std-Proposals
>     <std-proposals@lists.isocpp.org
>     <mailto:std-proposals@lists.isocpp.org>> 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@lists.isocpp.org <mailto:Std-Proposals@lists.isocpp.org>
>     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 *
>
>