[kde-edu]: Templates or not ?

Benoît Jacob jacob at math.jussieu.fr
Mon Nov 19 20:21:16 CET 2007


On Monday 19 November 2007 19:00:42 Vladimir wrote:
> In my case I have only two specializations, but I can't hide the templates
> inside the library because:
> - the interfaces should be specialized too, for example
> Particle2d::position() should return Vector2d but Particle3d::position()
> should return Vector3d; 

I don't see why this prevents you from specializing!

> - currently I don't use d-pointers and for some 
> classes I think its good (for performance reasons), so private members are
> declared in headers.

Again I don't see why this prevents you from specializing!

> Probably I can instantiate all classes for 2d and 3d in sources so that the
> library will contain binary code for this two versions ?

Yes, that's what I was suggesting. That is, IF you go for specialization.

> But will it be 
> meaningfull taking into account that almost all code will be in headers
> anyway ?

It will be in *internal* headers and that code will be specialized and 
compiled into your library's binary. Afterwards, the user only sees the 
binary. The public headers don't have to contain any templated code, they 
only need to contain declarations of the types (like Vector3d) which may be 
templates, but that's not an issue, the bigger part of the code is in your 
shared binary library, only a lightweight part remains in your headers.

>
> Now I'm thinking that headers-only library is not so bad: at least I can
> forget about problems with binary compatibility ;-) And as you suggested I
> can use templates to implement optional features.

Indeed, it has its advantages. Note that I didn't say that you should go for 
specialization: I just mentioned specialization as a possible way to address 
the issues you were raising about templates.

I would advise starting with templates, and only later decide whether you want 
a binary library or not. It'll always be time to specialize your templated 
code into a binary library. Also note that as long as Step is the only 
application using this library, there is no difference at all between the 
headers-only approach and the binary-library approach! So I think that's one 
more reason to go for templates and headers-only for now, and only later 
ponder binary issues.

One thing though -- if (I don't know if that's the case) Step is split into 
multiple binary entities (plugins...) each of them using your headers-only 
library, that might be a very good reason to make a shared library -- 
otherwise, I don't know if the specialized code will be shared among them.

>
> The problem with the static data members is that they should be declared in
> only one source file so that there will be only one copy of them when
> linking (AFAIK). So I do not know where should I declare them in
> header-only library. Are there any workaround ?

Ah, I see the problem. Maybe they could be defined in main.cpp? Maybe your 
headers-only library could provide a macro DEFINE_STATIC_MEMBERS that would 
do that jobs, and would be called from main.cpp. Well, that's just a random 
thought, maybe it is bogus for some reason.

Cheers,

Benoit (very busy right now but will happily spend the weekend on such issues 
with you in Paris. Hope your visa stuff works out!)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-edu/attachments/20071119/ce4fb590/attachment.pgp 


More information about the kde-edu mailing list