Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-10-03 22:01:19

Simonson, Lucanus J wrote:
>>>> Suto, Gyuszi wrote:
>>>>> The biggest issue is agreeing on fixed vs. floating precision.
>>>> If it's going to be a template library why not both?
>>> The floating point has high resolution near zero and very low
> resolution
>>> at high values.
> Joel de Guzman wrote:
>> Ok, but then again, there are also problems with fixed point.
>> So, again, why does the library have to choose and not the
>> user, since we have templates?
> You are asking me what my rationale was for not templating the
> coordinate data type. That is a good and useful question to ask. It
> was a conscious decision I made based upon the benefit it would provide
> vs. the cost of adding an additional template parameter to each and
> every geometric class. Just because "we have templates" doesn't mean
> that we don't incur a cost in using them. The cost I was concerned with
> was ease of use, primarily.

What cost? Typing? You can default to fixed point. There's no cost
AFAICT. Use typedefs for typical template instantiations. This is
how GIL did it, or even std::basic_string and std::string.

> Similarly I didn't template the
> dimensionality of geometry types because the benefit (primarily saves me
> typing) wasn't justified by the added complexity and difficulty using
> the library that choice would have caused. Instead I chose to pay the
> costs of templating to get much bigger benefits from ease of
> integration. Incidentally, I do have a typedef for the coordinate data
> type, and you can easily change it to double, but the code wouldn't
> work. The built in equivalence operator is effectively meaningless in
> floating point and a lot of the code would become nonsensical.

Generic programming techniques take care of that dilemma.

There is
> a big difference between fixed point geometry and its application
> domains and floating point geometry and its application domains. I am
> skeptical that a generic geometry library could successfully bridge that
> gap by templating the coordinate data type. Someone working in a
> floating point application domain should feel welcome to contribute the
> floating point library.

I disagree. Generic programming techniques can be used to sort out
the data-type idiosyncrasies. See GIL for instance: a library that
is so flexible as to what component types should be without
sacrificing speed and ease of use.


Joel de Guzman

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