Boost logo

Boost :

From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2001-05-23 17:44:28

Paris (U.E.), le 24/05/2001

--- In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
> on 5/21/01 10:39 PM, Hubert HOLIN at Hubert.Holin_at_B... wrote:


> > Well, let them incarnate and then only see if there actually is a problem.
> The review process should let us find and fix potential problems in advance
> of them coming up. We don't want to redesign this part (the only real
> problem) of the package after someone else gets "screwed over" by it.
> --
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com

        I agree with you on this. However the formulation I have adopted
solves the problem for the remainder of my proposed libraries, and
works with complex as well, which is beyond the reach of users. So we
have actual wins, and only the potential for loss. If I move the
definition to the quaternion and octonion files, we lose the win for
complex, and only gain the potential for some future avoidance of some
problem. I feel the current tradeoff is better, though it is of course
a tradeoff. As a side note, I feel it more robust to have the functions
defined and implemented in files other than that of variable types
definitions (what I mean is that we first define sets, and then only
functions on these sets (save of course for some; no integers without
increment!)). In a redesign of C++ (C++-0x?) we should have a better
factoring (and defining a new namespace for special functions where we
could have, say, a "sin" for which the syntax "sin<float>(x)" is valid,
alongside the current C-inherited grab-bag).

                Hubert Holin

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