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@suddenlink.net> 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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users