[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