On Aug 1, 2013, at 4:03 AM, Krzysztof Kosiński wrote:
Then we want to get rid of any function bodies in the header, as that locks us into promising a certain implementation. We want to hide the details inside of the .cpp and not let anyone know what is going on:
If you put the body of a class member function in a header, it is equivalent to putting it in a .cpp file, except the function is automatically marked as inline. Putting the function body in the header does not lock us into anything, since this is an internal Inkscape object and does not have a stable ABI.
There are actually many issues here with bodies in headers. A stable ABI is just a minor one. A very important factor is compilation and development time. If a method body is in a header and needs to be changed, then every single .cpp that includes the header or that includes some other .cpp file that includes something else that eventually includes that first header will be recompiled. Keeping the headers clean also improves base compile times, as less processing is done when the fie is included or pulled in elsewhere where inclusion is needed.
Another general problem with bodies in headers is that if they are not trivial then they need to pull in other includes to be able to do their job. That 'contaminates' consumer .cpp files with more includes than absolutely necessary. Compile times for the project then go up.
By the way, the "SP" of "SPPoint" is something we want to avoid for any new classes. That stands for "SodiPodi" which was the project Inkscape was forked from years ago.
The SP prefix should be kept for the time being, for the sake of consistency. Removing it should be a separate task.
Yes... I was explicitly calling out to not *add* to new classes (hence my inclusion of "for any new classes")... not for removing it if it already was present.