Re: [Boost-users] [serialization]polymorphicportablebinaryexamplenot working.

Subject: Re: [Boost-users] [serialization]polymorphicportablebinaryexamplenot working.
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-03-16 12:41:12

Mostafa wrote:
>> Mostafa wrote:
>>
>>> I'll query the dev list on the pros/cons of explicit instantiations
>>> with seperate template .ipp files vs. header only template files,
>>> right now I'm leaning against the former.  If there is a general
>>> consensus that explicit instantiations are not needed, then I'll
>>> open a trak item to do away with them in the serialization/archive
>>> libraries and add what researched results I've come up with.
>>
>> I used *.ipp files to factor out common code.
>>
>> I used explicit instantiation for the library supported archives
>> to minimize code bloat, and build times.
>>
>> I don't see any conflict here.
>>
>> Robert Ramey
>
> I see how explicit instantiation minimizes build times, I don't see
> how it minimizes code bloat.  In fact, it may lead to more code bloat
> since it's generating code for all possible combinations of template
> parameters the client *might* use.  Where as with implicit
> instantiation, code is only generated for which ever combinations of
> template parameters the client actually uses.

Remember that this instantiation is in the library.  If one builds with
the static library, ONLY the instantiations which are actually used
take up spece in your program.  If you use the DLL, all are included
in the DLL.  BUT, if you could have multiple executables all sharing
the DLL so even in this case, "pre-instantiating" all the archive
implementations could actually save a lot of memory.

> The only reason I was harping on explicit instantiation was that in
> order for me to get the portable library examples working I had to
> figure out what to do with the explicit instantiations that weren't
> compiling. (Eventually it turned out that they weren't needed.)

Sorry for the confusion.  If you want to turn you're frustration
(which I'm very sympathetic to), feel free to suggest an
improvement to the documention. The current version of the
documentation doesn't actually describe portable_binary_?archive
since the original purpose of that demo was over taken by
events.

> Generally speaking, one has to manually keep track of explicit
> instantiations (making sure that there's one and only one
> instantiation for all relevant template parameters), which leads to
> maintainability problems vis-a-vis refactoring, like the portable
> library examples that weren't compiling. That's why I broached the
> alternative of having all template definitions "includable" by
> clients and having no explicit instantiations.  But it's your call. I'm 
> just broaching an alternative ...

I'm understand the argument and the trade offs.  For me personally
I hate the idea of haveing the same code being instantiated in different
modules.  In my personal development, I make a project with a
separate library project.  Then I make the "real" project dependent
on the "library".  The helps automatically eliminates code which
turns out not to get called.  When one has a large project, its sooooo
easy to stop using a function, but leave it in as dead space.  Using
the library technique makes automatic management a reality.  I
use MSVC with function level linking turned on.  (the serialization
library is built this way also).   So it means that no code is included
unless it's actually being called.  This is my way of doing things and
the serialization library reflects that.

>
> Thanks,
>
> -Mostafa