Re: [boost] [geometry] view_as concept casting

Subject: Re: [boost] [geometry] view_as concept casting
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-01-09 17:52:37

>>>refinement:
>>>
>>>           +-- p <------+
>>>          /              \
>>>  pwh <--+                +--  p45 <---+
>>>          \              /              \
>>>           +-- p45wh <--+                +-- p90
>>>                         \              /
>>>                          +-- p90wh <--+
>>>
>>>Ja?
>>
>> Ja, that's the one that crashed the compiler when I tried to take out
>> the virtual keyword.

>Which 'piler is this?

I think it was gcc 3.4.2, but it might have been gcc 3.2.2.  I don't clearly remember.  I pretty much stopped worrying about it when I found that it isn't a problem with current compilers and I was no longer planning to do it anyhow.  No need for bug report.

>That's in boost/type_traits/is_convertible.hpp; I didn't have to
>implement it!

Nice.  Good to know.  How does it work?

>If you use SFINAE in the traditional way, you can't take advantage of
>any refinement relationships and you need to explicitly exclude all the
>other cases.  Of course, you could use SFINAE with an is_convertible
>test on the tags, which would get around that problem.  But I would
>still do that on the dispatch function and use tags to select the
>implementation.

Yes, saves some typing of SFINAE meta-logic.

>Then Rectangles aren't immutable but Polygons are.  Odd asymmetry.

Well, if the number of points in the polygon is changed by the modification you will pay O(n) wrt. points to modify it one way or another, might as well just set it.  If I were going to fix the asymmetry I'd probably make all types immutable.  It is really a bad idea to modify one coordinate of a polar point through a Cartesian view and then modify the other coordinate in the very next line.  If I know the data type at compile time I can use its non-generic interface to partially modify it, of course.

>> In some cases it might take me more code, but in others not.  If I add
>> triangle to the mix I can specialize is_polygonal and give the
>> triangle polygon-read-only traits to work with the existing overloads
>> of assign.
>
>You lost me.

I can view a triangle as a polygon.  My polygon_traits is for read only access.  I have another polygon_mutable_traits for writing to a polygon.  I can specialize polygon_traits for any object that models triangle and it will become a legal RHS of the polygon assign functions.  I still need to write the assign for triangle as LHS, however, which would require SFINAE guard that your tag dispatch function would not.

>> Tag dispatching could help cut down on the number of SFINAE protected
>> overloads of functions, which would save some typing, but the number
>> of functions in the library would be about the same.

>It's not about the number of functions; it's about having to hit a whole
>bunch of unrelated implementations when a new concept is introduced, to
>make sure they don't match it.

That would be bad if it were the case.  By splitting the traits into read-only and mutable and looking up by meta-function whether an object models the read-only or over writable concept I've done essentially the same thing as tag-inheritance concept refinement accomplishes, but through meta-functions.  Updating those metafunctions is about the same work as adding a new tag into the hierarchy, and much less than adding the interfaces required by the traits, which would be necessary in either case.

> Right now I have 314 SFINAE overloads of various function names.
> Having to modify all of them to deal with a limitation in the way the
> MS compiler parses SFINAE really is a chore.  I'd have only 200 or so
> to do if I implemented things the way you propose, but that is a
> difference in degree, not order of work.

>are you arguing that a 35% reduction in the size of your job is
>insignificant?

No, just that I'm not going to change the design for that reason alone.  I expect I'll rewrite it again in the future for other reasons, and I can incorporate this change at that time.

Respectfully,
Luke