Re: [Lib2geom-devel] Templates

[Johan E. <jbc...@sw...>]

Attempt at rebuttal:
(please read as if replying to overall more templetization, not just 
Point<...>)

On 16-6-2014 12:22, Nathan Hurst wrote:
> On Mon, Jun 16, 2014 at 01:57:26AM +0200, Krzysztof Kosi??ski wrote:
>> 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 :-)
> ...
>> 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.
> Yes, I thought about this when we started, and mental and I discussed
> this at length.  Here are the reasons against:
>
> * as Krzysztof says, templates mean everything must be on the compile
>    path for everything.

Yep. But, our current design could be changed to alleviate this issue 
somewhat, by splitting out some functionality in different header files. 
Things like Path::toPwSb(), Path::allNearestPoints, ... should not be 
member functions.

> * More complex methods for everything

True.
So? ;)

> * Ugly error messages

clang has *much* better error messages than gcc (up to the point where I 
am considering using clang on windows, even though the binaries do not 
work 100% yet). Plus, we could add checking code to improve error messages.

> * Minor performance cost

You made a typo: minor performance boost. ;-)
(serious question: I'm curious to see an example where using templates 
makes the code slower)

> * Slower compiles (a big issue for me - the slower the compile the
>    slower the development)

lib2geom compilation at the moment is pretty fast, you really notice 
this now?
(splitting things in more headers would shave off some compilation time)

>
> I couldn't think of any other compelling reasons for (especially when you
> consider that D2<T> does what you want).

If that were true, we would not need Point at all.
But you are right, Point<float> would not be worth it. Point<int> would 
be much better; but mind caveats noted by Krzysz.
So I'll give up on this one for now.
(how about IntPoint<int>, <unsigned>, <short>, etc, Krzysz?)

>>> 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.
> I suspect it would be hard to get useful optimisations this way.

On transform, I was able to get several times performance improvement 
without much effort if you remember. Our implementations for some basic 
operations are not all that fast and I feel improvement is possible. If 
only the code would compile-time decide on using a vector of shared 
pointers, or a shared vector of data; don't know how much it would 
improve performance, but it will I'm quite sure.

The target is being able to do powerstroke-like stuff *super-fast*. Most 
of this is using Pw D2 though, so that is already much faster than Path 
(not reallocating new memory on just about every operation). I'm not so 
familiar with S-basis, would a fixed number of coefficients make sense 
there? (like it would for beziers, where e.g. having all cubic beziers 
is fine).

Hmpf... well, reading on in the book. When release is out, we've 
switched to C++11, got proper testing in place, some profiling, and time 
is left, perhaps... :-)

>> 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.
> Jaberto is thinking about this a little bit.  Perhaps he could say
> something to this.
>
> njh
>