[Boost-users] Re: Serialization and source code organization

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-24 23:47:24

The pimpl example demonstrates pretty much all I know about the issue.

Advantage: saves lots and lots of compile time.
Disadvantage: requires explicit instantiation - a slight pain in the neck.

Possible idea. I've seen this used to good effect with other projects - one
upto 500K lines long!!!

make another project - a static library for ALL the serialization
instantiations.

Link against the Other project library.  Only the code actually used will be
included in the final exe.

Actually I used this method when I have to work on something moderatly large
even when serialization isn't being used.  It helps keep things organized so
I can understand it better.

Robert Ramey

"Malte Clasen" <news_at_[hidden]> wrote in message
news:co3bqn$2ii$1_at_sea.gmane.org...
> Hi,
>
> I'm currently trying to use the new Boost 1.32 serialization library to
> save the state of a medium complex program (about 10.000 lines of code).
> The problem is that the serialization lib seems to require very close
> source code coupling: The translation unit that contains the load/save
> functions for the application has to see all serialize() method
> definitions (as they are templates). That means that I cannot rely on
> forward declarations, so I always have to include the respective header
> file. This slows down the compilation noticably and results in errors
> such as "C1204: compiler limit : internal structure overflow" and
> "C1055: compiler limit : out of keys" (VC++ 7.1), as more or less all
> significant headers are included in this translation unit.
>
> The documentation is aware of this kind of problem and recommends manual
>   instantiations of the serialize() methods (in the PIMPL section). Do I
> get something wrong or is this the only solution? I don't really like
> manual template instantiations, but in this case I can't imagine another
> way to deal with it, except waiting for the next VC++ release and hoping
> for the best.
>
>
> Malte