$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [variant] Warning: variadic templates in boost::variant
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-12-10 08:54:08
On Tue, Dec 10, 2013 at 8:36 AM, Matt Calabrese <rivorus_at_[hidden]> wrote:
> On Mon, Dec 9, 2013 at 12:28 PM, Peter Dimov <lists_at_[hidden]> wrote:
>
>> Steven Watanabe wrote:
>>
>>> The difference between tuple<> and variant<> is that tuple<> has exactly
>>> one possible value, but variant<> has no possible values.
>>>
>>
>> Not conceptually. tuple<X,Y> is struct { X x; Y y; }. variant<X,Y> is
>> union { X x; Y y; }. tuple<> is struct {}. variant<> is union {}. All are
>> valid.
>>
>> It's not that important though. The current variant doesn't support this
>> case, so there's not much reason for the variadic one to do so. Sorry for
>> bringing it up.
>
>
> I'm going to have to back you up here that a variant<> does sometimes make
> sense and I don't think we'd lose anything by supporting it. In real,
> non-hypohetical code, I've encountered a place where I had a 0-element
> variant come up and had to special-case my code so that it would work as
> expected. The way it came up was I had a variant of several types (the type
> list was the result of some metaprogramming) and a visitor of that variant
> that returned the result of a member function call on the currently stored
> object, whichever one it was (each type in the variant had the same named
> function but the return type wasn't necessarily the same). I constructed
> the return type based on the return types of the functions in question,
> eliminating any duplicates. If one of the functions returned a void type,
> no type was added to the list. I stored this result and later on did things
> with it (such as display it).
I think that case would better be handled by variant<blank>. I.e. you
can replace void return types with blank and the rest of the code can
be left intact.