Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-12-14 13:43:35

Hi Gennadiy,

sorry for jumping in here. But I believe this post might need a bugfix.

Gennadiy Rozental wrote:
> "John Maddock" <john_at_[hidden]> wrote in message
> news:006401c71f85$12d1a8b0$20570252_at_fuji...
>>Weapon Liu wrote:
>>>I personally very like this fancy facility, and that's why I present
>>>these mumbles here to annoy you guys( if so, my apologies go here:-))
>>>Any comments?
>>I can give you one use I have for tuples:
>>I have a piece of boilerplate code that accepts a tuple (of any size) and
>>prints out either a csv file or a boost::array C++ code conaining the data
>>It allows me to output data for graphing, or matrixes of test data very
>>quickly just by creating a short function that returns a tuple, and then
>>passing that function to my boilerplate. If I want more columns of data I
>>just increase the size of tuple by 1.
>>I suppose I could have used a vector instead, but it's less elegant
> How the std::vector<boost::variant> is less elegant?
> 1. It's could be implemented in cpp file. Your tuple based solution is in
> header right?

Right. It can be both an advantage or an disadvantage depending on what you're up to (modularity vs. genericity).

(Sidenote: If you know how the tuples will look like you can instantiate them explicitly and toast them into a cpp file, but I'd probably go for vector<variant> in case I need a translation boundary for the sake of convenience).

> 2. It allows dynamically sized entries, so you could skip some of the
> default values
> 3. It's as fast of could be even faster since we don't need to pass big
> structures around

AFAIK Boost.Variant calculates the storage size based on the largest object (just like a union does). It also has good reason to do so since heap allocation is an expensive operation.
IOW if we have vector< variant<some_huge_class,int,int> > and most of the variants in the vector are ints we're wasting memory.

> The only drawback is that you need to know set of types ahead of time. But
> this is minor IMO and it's quite easy to add an extra type whether a need
> arise.

Here's another drawback: Say we want to visit every entry in the sequence and use an appropriate function for each type of thing we find. With vector< variant<...> > we need a) a loop and b) to choose the function at runtime. Both can be eliminated with Fusion and it even takes less code to emphasize it.



Boost list run by bdawes at, gregod at, cpdaniel at, john at