Also just FYI: Maybe this is already in the bug list, but on my OSX 10.3.6 box with the latest apple-distributed gcc, we seem to hit some fatal compiler bug when building xml_grammar.o in release mode only: the compile never exits, load stays high, and the compiler's memory usage grows steadily and without bound... Debug mode builds fine and in a reasonable amount of time. -t Jeff Flinn writes:
Robert,
"Robert Ramey" <ramey@rrsd.com> wrote in message news:cn1lk0$ail$1@sea.gmane.org...
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:cn0cmq$ja8$1@sea.gmane.org...
...
I've read the Serialization documentation, but haven't used it yet. I've noticed it takes a long time to build, but this is probably because of the various combinations of threading, debugging and linking options.
This is most probably due the compilation of the xml_archives class which uses spirit to parse XML input. Not that it matters as its just a one time cost in any case. If fact, this is the very reason that its a library rather than a header.
User program which use serialization library generally compile quite fast. No one has reported that serialization adds a disproportionate amount to compile time. I did get one reporte from one user with 80 classes that he was starting to get ICEs from VC 7.1 . But that's it.
FYI.
I've hit VC7.1 "internal structure limits" with much fewer than 80 classes ( about a dozen) in a single translation unit. I use both xml and binary archives to support serialization to disk and clipboard/drag/drop respectively. In particular I have separate compilation units with only 2-3 BOOST_SHARED_POINTER_EXPORT calls. Any additional calls exceed VC7.1 limits.
----------------- Jeff Flinn Applied Dynamics, International
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost