From: Eric Friedman (ebf_at_[hidden])
Date: 2003-10-07 01:01:16
E. Gladyshev wrote:
> --- Eric Friedman <ebf_at_[hidden]> wrote:
> [...]
>
>>Do you mean you need to ensure allocation of some user-provided type occurs
>>only via some user-provided allocator?
>
> Yes.
>
>>If so, variant unfortunately does not
>>support such functionality at this time.
>
> Any plans to support it?
Not at the present time, no. Of course, one solution is to return to
using the double-storage technique, but I don't think this would be
desirable for the vast majority of use-cases.
I don't know if it consoles you or not, but the heap-allocated backup is
deleted before the end of the assign operation and is *not* stored in
the variant (unless the operation fails, of course).
>>However, as I noted in previous messages, allocation on the heap can be
>>avoided entirely for any type Ti in variant<T1, ..., TN> if T1 is nothrow
>>default-constructible. I would suggest then that, if none of your types are
>>guaranteed to have a nothrow default constructor, you work with
>>variant<boost::empty, T1, ..., TN>. Even if you never make direct use of
>>boost::empty, this will ensure all allocation will be via placement new and
>>never on the heap.
>
> Is there any guarantee that this internal behaviour won't change
> in the future?
This behavior will remain supported. If yet another solution (not
double-storage, not heap backup) is found, it may in fact become moot.
> It is kind of annoying that I can use almost nothing from boost
> in my policy based library.
> I cannot use boost::shared_ptr, boost::signals;
> and boost::variant has a kludgy workaround.
I'm sorry to hear this.
> If there are plans to fix it(?), I can live with this kludge for now.
Again, I have no proposals as of yet. Personally, I'm more interested in
other areas of variant and related libraries.
> Anyway I like 'variant', thanks for the great library.
If you do decide to use it, I'd appreciate feedback.
Thanks,
Eric