From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-10-05 06:43:05
Simonson, Lucanus J wrote:
> The important thing about the library is not so much *what* it does
> but *how*. As a library writer in an industrial setting I am faced
> with a challenge of how to overcome the complexity created by an
> explosion of C++ geometry types in numerous legacy applications.
> Integrating a superior library capability into pre-existing applications
> is a challenge due to type incapability. The important thing about
> my library is that I have solved that problem by applying C++ Concepts,
> inheriting my types from the template parameter, to allow a minimal
> concept map to provide the interface between my algorithms and the
> legacy system's geometry data types.
Yes, we should focus on this. What do people think about the balance
between (a) supporting legacy code that uses its own types and (b)
simplifying the case where you're developing new code? Are there other
examples in the standard library or Boost where this has been an
issue? Is this a false dichotomy?
My fear is that this "compatibility layer" could obfuscate the
interface for new users with no legacy issues.
I'm unclear about how symmetric the GTL or Fusion methods for
adaptation are from the point of view of the library user vs. the
library author. As I understand it, in both cases a library user can
invent their own types and adapt them to work with the library. But a
library author must always use the fusion get<n>(X) or equivalent GTL
syntax. Is this true, or is there some way of using my choice of .xyz
or [n] in the library code that I write?
Regards,
Phil.