Date: Thu, 3 Sep 2020 14:58:25 +0300
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 *
>
>
(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 *
>
>
Received on 2020-09-03 07:02:00