[libcxx-dev] Providing custom template specialization for std::optional?

[Eric Fiselier via libcxx-dev]

On Thu, Mar 7, 2019 at 10:18 AM Владимир Гончаров <dev.zelta at gmail.com>
wrote:

> Can you explain what your specialization does differently? And why it's
> needed?
>
>
> I have a class which is a C++ interface for an object defined in a C
> library. Internally, it is a pointer which can never be null (if C
> interface returns null, the class constructor throws).
> I want to use this fact to optimise optional's storage. That would allow
> shrinking optional's size to eight bytes. Since we store a lot of optionals
> of this class, this change would reduce memory usage by about five percent
> (I've done some testing).
> I really don't want to invent a new optional specifically for this case. I
> also don't want to allow storing null pointers inside of the original class
> because this would require an assert before almost any usage of the class.
>
> I think the standard is being too permissive here.
>
>
> Maybe it is. But again, if I can provide a more efficient specialization
> which would utilise some knowledge about the wrapped type, why shouldn't I?
>
> `<variant>` is a good example.
>
>
> By the way, providing custom specializations for variadic templates is
> forbidden =)
>

Where does the standard say that?


>
> Kind regards, Vladimir Goncharov
>
> On 7 Mar 2019, at 08:39, Eric Fiselier <eric at efcs.ca> wrote:
>
>
>
> On Wed, Mar 6, 2019 at 5:41 PM Владимир Гончаров via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
>
>> Hello!
>>
>> I'm implementing a specialization for std::optional for my
>> program-defined type.
>>
>
> Can you explain what your specialization does differently? And why it's
> needed?
>
>
>> As I understand *[namespace.std]*, nothing forbids me from doing that.
>>
>
> I agree that you've interpreted the standard correctly. But I think the
> standard is being too permissive here.
> Implementing a complex component may necessitate knowledge of the
> internals. `<variant>` is a good example.
>
> I would like to know what other library maintainers think.
>
> /Eric
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190308/d046655d/attachment.html>