[kde-edu]: Templates or not ?

[Vladimir]

Hello Benoit !

On Monday 19 November 2007 22:21:16 Benoît Jacob wrote:
> 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.
Yes, but in my case the library has only a small number of internal 
classes that can be moved to private headers. Basically there is a World class 
which acts as a container for many (public) classes that represents physical 
entities such as bodies or forces or some utilities such as solvers and that 
should be created and inserted into World by the user. And almost all logic 
is implemented as public or private members of user-visible classes. Now I 
want to have World2d and World3d containers that can contain 2d or 3d 
versions of objects respectively.

>
> > 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.
Yes, I'm going to follow your suggestion here.

> 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.
No, Step has no pluggins for now. I've planned them in the beginning but now 
I'm getting more and more confident that for Step pluggins would not be 
useful. Oh, I can't have everything...

>
> > 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.
I like the idea with DEFINE_STATIC_MEMBERS. But firstly I have to find a way 
to combine it with my own macro-based introspection system ;-(

>
> Cheers,
>
> Benoit (very busy right now but will happily spend the weekend on such
> issues with you in Paris.
Ok, so lets postpone this discussion till the meeting. You have already helped 
me a lot, now the problem looks quite clearer for me. Thanks a lot !

> Hope your visa stuff works out!) 
Thanks !

-- 
      Best Regards,
        Vladimir