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.