Re: [Lib2geom-devel] Templates

[Krzysztof K. <twe...@gm...>]

2014-06-16 0:01 GMT+02:00 Johan Engelen <jbc...@sw...>:
> Hi all,
>    I am reading Modern C++ Design by Andrei Alexandrescu and already
> after the first few pages, I want to start work on 2geom that I've been
> thinking about for a while. Would like to hear your thoughts,
> encouragement or otherwise :-)
>
> The idea is to add template parameters to, e.g., Point.
> Right now, we hardcode the coordinate type Coord as double. But why not:
>      template<typename Coord = double>
>      class Point { ... };
> :) ?
> This will allow people to choose what precision they want. Perhaps this
> allows code sharing between Point and IntPoint. Note that with templated
> stuff, you can write methods that would not work with certain types
> without breaking compilation (unless you call such a method); this would
> allow exposing optional functionality depending on the template argument
> type.

I thought about this when I worked on the Point class and decided
against it, because expressing all the operations we need on point
classes in templates would require loads of arcane boilerplate. For
example, the conversion from IntPoint to Point should be implicit, but
the conversion from Point to IntPoint should be only possible through
functions such as round, ceil and floor. Also many operations, such as
normalization, don't make sense on IntPoint.

Furthermore, this would require changing many functions that take
Point to template functions taking Point<Coord>. We would effectively
need to lift most of 2Geom code into headers.

> Point<double> is just the start. My endgoal is to be able to choose
> Path<CubicBezier>: a path for which all functions know that it is just a
> vector with CubicBeziers, allowing SIMD optimization of many operations
> on it. Instead of the Path<Curve> that we have now, that does not allow
> for any of that.

This would be interesting. Path could also have a second parameter
specifying the underlying structure: vector, list or an
order-statistic tree.

Another interesting area of improvement would be to put the node-based
path representation from the node editor in 2Geom, though this would
need extra effort to decouple it from the display and event handling
code.

Regards, Krzysztof