Re: [Boost-users] [GIL] does gil::variant<mpl::vector3<A, B, C> > constructor accept instances of gil::variant<mpl::vector2<A, B> > ?

Subject: Re: [Boost-users] [GIL] does gil::variant<mpl::vector3<A, B, C> > constructor accept instances of gil::variant<mpl::vector2<A, B> > ?
From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2010-05-11 16:51:09

These were experiments I did five years ago so I don't remember all the
details, but my recollection was that if I used boost::variant with many
types (a dozen or more gil::image or gil::image_view types) into more
elaborate computations, especially binary functions (which require
evaluating every possible pair of types), it would take minutes to compile
and it would sometimes fail to compile at all. That prompted me to create my
own variant class which, at the time at least, had much better scalability
and compile performance. It is possible that gil::variant does not have all
the features of boost::variant but it was serving its purpose well. There
might have been other reasons to use gil::variant instead of boost::variant
(some generic operations were easier) but I don't recall the details.

I am all for code reuse where it makes sense. In this case gil::variant is
very small and we are not duplicating much code. If someone feels strongly
about using boost::variant instead and is willing to take a stab at redoing
the experiments, and they show acceptable performance (things may have
changed over the past 5 years), I would be ok with switching to
boost::variant.

Note that gil::variant is not typically used directly. It is a base class
for gil::any_image and gil::any_image_view. You would need to deal with
gil::variant only if you are a pretty advanced GIL user.

Lubomir

On 5/11/10 5:05 AM, "Larry Evans" <cppljevans_at_[hidden]> wrote:

> On 05/10/10 20:33, Lubomir Bourdev wrote:
> [snip]
>> As for why we don¹t use boost::variant, I recall that I was able to
>> switch to boost::variant at some point (it wasn¹t that hard) but there
>> was a severe compile time penalty.
> [snip]
> Did you figure out the reason for the compile time penalty.
> Looking at boost/gil/extension/dynamic_image/variant.hpp
> around line 94, I see:
> 
>      typedef struct { char data[MAX_SIZE]; } base_t;    // empty space
>         //equal to the size of the largest type in Types
> 
> So, I assume no alignment calculations are made.  Would the alignment
> calculations be the main cause of the compile time penalty?
> The alignment calculations I'm talking about are those done by
> make_storage in boost/variant/variant.hpp at around line 218.
> I assume gil doesn't need any alignment calculations because all
> alignments required by the gil variant components are 1.  Is that
> right?
> 
> TIA.
> 
> -regards,
> Larry
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users