Re: [boost] peer review

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-04-29 18:46:35

>I'm not entirely convinced that it should be possible to treat a prism 
>as a rectangle
>without an explicit conversion of some kind.  contains for a prism 
>should treat it as
>as prism.  The general solution to this kind of problem is tag
dispatching.

Yes, I can see how defining a prism_tag and rectangle_tag in traits
classes would allow
        template<class T, class T2> 
        bool contains (const T& r1, const T& r2) {
                return contains_dispatch(r1, r2, traits<T>::type_tag);
        }
to disambiguate through the added layer of abstraction.
 
>How important is it to not make a copy of the prism?
>Alternately, how important is it to be able to copy the
>whole prism while treating it as a rectangle?

It is important for performance considerations, but also becomes
increasingly important as the size of the object increases.  For a
polygon which may have anywhere from 4 to 4 million vertices requiring
copy conversion simply to satisfy type requirements when viewing it as a
polygon with holes vs. polygon without holes the issue is cast in a
different light.

It is somewhat less important to copy the whole prism when viewing it as
a rectangle, but I do use this feature of the design pattern, for
instance, to generically treat polygons and polygons with holes as
polygons and allow holes to copy through automatically.  Otherwise I
would need two functions is places where I now have only one.

> I'm looking for the boost community's feedback on what approach to
> rewriting the library they find preferable, and a sort of final
decision
> on whether the generic inheritance/static_cast/mimicry design-pattern
I
> came up with is unacceptable for acceptance into boost, implying that
a
> complete rewrite is truly needed.  Is the requirement that code never
do
> anything the standard doesn't guarantee is safe, or is the requirement
> that code be portable and functional?

>The absolute minimum requirement is that it should work on several 
>platforms.
>I think that to the extent that is possible, code should only rely on 
>what the standard guarantees.
>I believe that if you rely only on non-member functions and
>reinterpret_cast back and forth, it is possible to make the mimicry
legal.

Can you explain that last part about relying on non-member functions and
reinterpret_cast making it possible to be legal?  Do you mean what I am
already doing with non-member functions providing the interface?  What
exactly to you mean by legal?  Do you mean legal syntax according to the
compiler, or standard compliant syntax?

The code compiles (and runs correctly) with gcc 3.2.2, 3.4.2, 4.2.2 and
4.3.0, icc 9.0 and 10.0, VC7 and VC8 and runs in ia32, EMT64 and itanium
machines in Windows and linux.  Other compilers, architectures and OS's
should be for the most part OK, but I lack access to them to check.  

Is this is sufficient to meet the minimum requirement for portability?
I would be very happy to keep the broader design as is and focus on
naming conventions and more minor improvements such as using output
iterators for results of algorithms instead of the less generic method
of passing std container by reference.  I also have a lot of work to do
to bring the documentation up to date.

Luke