Re: [boost] Proposal/InterestCheck: Boost.Geom

Subject: Re: [boost] Proposal/InterestCheck: Boost.Geom
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-01-29 15:58:26

Barend Gehrels wrote:
> We left SFINAE, it worked but tag dispatching worked much better for
> us (thanks Dave!)

I thought Dave's suggestion was to combine static assert with tag dispatching, but could also be accomplished by combining SFINAE with tag dispatching.  The difference between the two would be error msgs and name collisions.  Write a generic distance(T t1, T t2) function and try to compile with gcc 3.2.2 while using std::sort on a vector and you'll quickly see why static assert isn't always sufficient.  Even with namespace protection around your function you can't be sure someone else won't define a generic function with the same and you can get a collision due to Koenig-lookup.  I'm not sure I prefer the error that failure of static assert gives over "no function foo that accepts x y z" that you get with SFINAE.  No function area() that accepts point_type is pretty much clear and descriptive enough for the user, and very concise.  Of course, it doesn't help me when I make a metaprogramming mistake and a function won't instantiate as I intend, but I've always managed to figure out which function I intended to be called and debug why substitution failed.  

I recall you said you ran into compiler problems with SFINAE and switched to using static assert for that reason.  I know I ran into my own compiler problems.  I have to use SFINAE for generic operators, though, so I didn't find it too painful to extend it to cover the other functions once I was able to cover the operators.  Moving the condition of the static assert to an enable if on the return value should be pretty easy since you've already implemented all the meta-logic.

> Following is from the headerfile you can use to register (= specialize) 
> a any-sized c-array as a point (2D 3D 4D etc). 

Oh, I thought you were somehow detecting the presence of operator[] or something like that.  I agree with you, however, that arrays aren't really that useful for geometric entities.

> By the way, Luke, I appreciate all your comments and discussions on the list!  

Thank you for saying so.  I've really appreciated all the feedback I've gotten from boost developers, and from you.  Using enable_if on traits turned out to be a real help to me in conditionally defining traits for refined concepts, and I think you were the one who showed me how that works.  I'm still amazed that it works, because it looks like duplicate definitions since the specialization eventually resolves to be the same as the default.

I'm looking forward to your next preview.

Luke