Date: Sat, 17 Sep 2022 14:25:08 +0200
Please note that in my implementation referenced in my previous post, as
well as in the referenced blog post there is a small buffer optimization
which avoids the allocations of the original polymorphic_value. I also
intend to include a trait which disallows allocation and thus makes
instantiating too large subclass objects a compile time error. This
takes the solution closer to a std::variant based approach without
having to enumerate all the subclasses you may want to use at the point
of declaration.
This leaves only use cases where you explicitly want to exclude some
subclasses by enumerating the allowed ones. This seems to be an
anti-pattern to me and not warranting an addition to the std::variant class.
Bengt
Den 2022-09-17 kl. 13:33, skrev std-proposals-request_at_[hidden]:
> Send Std-Proposals mailing list submissions to
> std-proposals_at_[hidden]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> or, via email, send a message with subject or body 'help' to
> std-proposals-request_at_[hidden]
>
> You can reach the person managing the list at
> std-proposals-owner_at_[hidden]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Std-Proposals digest..."
>
>
> Today's Topics:
>
> 1. Re: [DRAFT PAPER] std::variant with std::specify_base
> (Bengt Gustafsson)
> 2. Re: [DRAFT PAPER] std::variant with std::specify_base
> (Zhihao Yuan)
> 3. Re: Generic code, not the API you are looking for
> (?????? ????????)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 16 Sep 2022 14:47:44 +0200
> From: Bengt Gustafsson <bengt.gustafsson_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] [DRAFT PAPER] std::variant with
> std::specify_base
> Message-ID: <476040c7-efb6-f3bb-ce34-b81903fb2334_at_[hidden]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> I feel that it is a kludge to use variant for this purpose, where the
> aim is to store an instance of a subclass in a potentially open set of
> subclasses.
>
> This is better served by something like polymorphic_value as described
> here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0201r1.pdf
>
> Reference implementation is here: https://github.com/jbcoe/polymorphic_value
>
> Furthermore I made a SBO enabled implementation as I think
> polymorphic_value should have the small buffer optimization. This is
> more of a demonstration than a real reference implementation (lack of
> test cases, noexcept, etc). This is available in the zip file in this
> issue: https://github.com/jbcoe/polymorphic_value/issues/124
>
> A similar idea was posted here recently:
> https://pvs-studio.com/en/blog/posts/cpp/0983/
>
> Bengt
polymorphic_value is for an open set
of subtypes, and the std::variant
solution here is for a closed set of
subtypes. They are of different purposes.
The latter is a kludge, but the codes
in transition are physically divergent,
while a design is meant to work well in
a complex environment.
well as in the referenced blog post there is a small buffer optimization
which avoids the allocations of the original polymorphic_value. I also
intend to include a trait which disallows allocation and thus makes
instantiating too large subclass objects a compile time error. This
takes the solution closer to a std::variant based approach without
having to enumerate all the subclasses you may want to use at the point
of declaration.
This leaves only use cases where you explicitly want to exclude some
subclasses by enumerating the allowed ones. This seems to be an
anti-pattern to me and not warranting an addition to the std::variant class.
Bengt
Den 2022-09-17 kl. 13:33, skrev std-proposals-request_at_[hidden]:
> Send Std-Proposals mailing list submissions to
> std-proposals_at_[hidden]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> or, via email, send a message with subject or body 'help' to
> std-proposals-request_at_[hidden]
>
> You can reach the person managing the list at
> std-proposals-owner_at_[hidden]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Std-Proposals digest..."
>
>
> Today's Topics:
>
> 1. Re: [DRAFT PAPER] std::variant with std::specify_base
> (Bengt Gustafsson)
> 2. Re: [DRAFT PAPER] std::variant with std::specify_base
> (Zhihao Yuan)
> 3. Re: Generic code, not the API you are looking for
> (?????? ????????)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 16 Sep 2022 14:47:44 +0200
> From: Bengt Gustafsson <bengt.gustafsson_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] [DRAFT PAPER] std::variant with
> std::specify_base
> Message-ID: <476040c7-efb6-f3bb-ce34-b81903fb2334_at_[hidden]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> I feel that it is a kludge to use variant for this purpose, where the
> aim is to store an instance of a subclass in a potentially open set of
> subclasses.
>
> This is better served by something like polymorphic_value as described
> here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0201r1.pdf
>
> Reference implementation is here: https://github.com/jbcoe/polymorphic_value
>
> Furthermore I made a SBO enabled implementation as I think
> polymorphic_value should have the small buffer optimization. This is
> more of a demonstration than a real reference implementation (lack of
> test cases, noexcept, etc). This is available in the zip file in this
> issue: https://github.com/jbcoe/polymorphic_value/issues/124
>
> A similar idea was posted here recently:
> https://pvs-studio.com/en/blog/posts/cpp/0983/
>
> Bengt
polymorphic_value is for an open set
of subtypes, and the std::variant
solution here is for a closed set of
subtypes. They are of different purposes.
The latter is a kludge, but the codes
in transition are physically divergent,
while a design is meant to work well in
a complex environment.
-- Zhihao Yuan, ID lichray The best way to predict the future is to invent it.
Received on 2022-09-17 12:25:24