[boost] Re: unions

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