Boost logo

Boost :

From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-04-29 17:56:33


Simonson, Lucanus J wrote:
> Joel also expressed the opinion that generic programming could allow the
> library to use floating point or integer arithmetic for coordinates. I
> remain skeptical of that. Also, because the coordinate type template
> parameter would go on practically everything, I fear it would become
> onerous to the user (and me.)

How about giving a coordinate type template parameter to everything, but
also providing typedefs for all the specializations with the default
coordinate type?

> I generally don't like to place a requirement on the template parameter
> that it provide specific functions, and instead prefer to go through
> adaptors, but I do see your point. In my work, I rarely have the
> freedom to modify a class in legacy code to conform to the requirements
> set forth in a generic library I want to use (or write.)
> One of the things I like about my current design is that it allows the
> function prototype to disambiguate for the compiler (and the user) what
> concepts the arguments are supposed to model.
> For example:
> template <class T>
> template <class T2>
> bool RectangleImpl<T>::contains(const RectangleImpl<T2>&
> rectangle);
> requires the T and T2 both provide RectangleInterface adaptors.
> (Obviously Impl is a mis-nomer and would be changed, but if I throw away
> the unorthodox design pattern then it doesn't much matter.)
> I also like that is isn't ambiguous to the user which rectangle is doing
> the containing vs:
> template <class T, class T2>
> bool constains(const T& containing_rectangle,
> const T& contained_rectangle);
> where the user will remember that there is a function that takes two
> parameters, but have to check the header file or documentation to remind
> themselves what the order means, since it is somewhat arbitrary. I
> would need to come up with a convention for ordering and be consistent.

If I need another function that you have not provided, I would need to
implement it
as a non-member... Another disadvantage is that if I only need one
piece of the rectangle
functionality, I still need to include everything because it's all in a
single class.

> The other unfortunate thing that happens is overloading of free
> functions becomes problematic when types are generically polymorphic:
> template <class T, class T2>
> bool constains(const T& containing_prism,
> const T& contained_prism);
> because a prism should provide both rectangle and prism adaptors and two
> prisms should satisfy both functions the result in a compiler error even
> when enable_if is used.

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.

> If we could induce it to compile, the user is
> left with no way to call the rectangle version on two prisms whereas
> with my library they would currently just do:
> bool containment = prism.mimicRectangle().contains(prism2);
> to view the prism as a rectangle to get access to the rectangle version
> of contains.

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?

> The only solutions I can see are to embed the conceptual types into the
> function name such as rectangle_contains(a, b) and prism_contains(a, b)
> or better still, make them into namespaces:
> namespace rectangle {
> template <class T, class T2>
> bool constains(const T& containing_rectangle,
> const T& contained_rectangle);
> }
> namespace prism {
> template <class T, class T2>
> bool constains(const T& containing_prism,
> const T& contained_prism);
> }
> which is workable.

That doesn't work well because it ought to be possible to write code that
deals with either a rectangle or a prism, as long as it only relies on
the common
properties--such as contains.

> 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

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.

> Are there other considerations
> that make what I'm doing objectionable?

In Christ,
Steven Watanabe

Boost list run by bdawes at, gregod at, cpdaniel at, john at