Re: [boost] Preview 3 of the Geometry Library

Subject: Re: [boost] Preview 3 of the Geometry Library
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-10-21 12:24:25

Hello,

Luke, I come back to you about this point from you:

> Also, your get function returns a reference to coordinate.  It should
> return by value.  Many legacy point types may have a public API that
> prohibits direct access to their members because that is what good
> little C++ programmers were taught to do in school.  Those point classes
> could not conform to your concept.

If you are talking about using the getter for read access, this way of
writing traits specialization is not an obligation and the user can
always return by value in his own one.

If you are talking about using the getter for write access (that is:
get<0>(p) = value) it's more problematics. We've discussed about that
with Barend and it appears that as you say, a legacy point without
direct access to its coordinates will never be adaptable to such
traits. I hadn't thought about that before.

The problem is that this approach (value = get<0>(p) for read access
and get<0>(p) = value for write access) has been chosen after having
been advocated by some people on this list. The argument was that it
is a very common approach in Boost, for Tuple and Fusion. And this
argument was quite convincing.

Must I deduce that the Boost.Fusion approach is not totally generic
and that a structure with unreferencable private members couldn't be
adapted to it?

And what would finally be the best way to handle point write access if
the Boost.Fusion one is wrong?

Thanks
Bruno