Re: [Boost-users] [serialization] I can't figure out whatI'mdoingwrong with xml_oarchive - please help

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-09 21:36:27

TOL: Emmanuil Tsagarakis wrote:
> Hello Robert,
>
> Thank you again for your help ...
>
> I did follow your suggestions especially with explicitly
> instantiation in a *.cpp file. Your example demo/example/test
> demo_pimpl helped a lot.
> On the other hand, I still can't save in xml format. I don't get any
> exception. Do I have to have any specific xml parser installed or not?
>
> Anyway I think I'm staying to text format for now...
>
> The most severe problem at the moment is that I keep experiencing in
> multiple files a compiler error (MSVC 7.1):
>
> fatal error C1055: compiler limit : out of keys
>
> It turns out that the cause, is the macro defined at the top of each
> cpp file:
>
> #ifdef _DEBUG
> #define new DEBUG_NEW
> #endif
>
> And also some macros like ASSERT or even CRT assert causes the above
> error.
>
> According to ms help:
> "The source file contains too many symbols. The compiler ran out of
> hash keys for the symbol table.
> Possible solutions
> Split the source file into smaller files.
> Eliminate unnecessary header files.
> Reuse temporary and global variables instead of creating new ones."
>
> But the error occurs even in a file with a single function!
>
> Cancelling the above macros bypasses all such errors. Any ideas on
> that? Diagnostic messages that DEBUG_NEW gives at program exit are
> useful for locating memory leaks ...
> But I guess that as long as I don't use raw pointers and stick to
> boost::shared_ptr I don't need the above macros ...
>

I think a better strategy is to separte you source code in more modules.
You can have one header class.hpp an several implementation modules
class1.cpp, class2.cpp etc.  The DEBUG_NEW can be excluded from
those modules which don't use MFC.  Personally I would be wary
of mixing MFC and boost without taking the above precautions.  It
will make your projects compile and build much faster since not
all the modules need include windows.h and all the mfc stuff.

> One more question, that's probably irrelevant to the library. So far
> with MFC I'm used to use macros like _T("...") or _TEXT("...") for
> string literals and character constants ...
> Aren't such macros needed with std::string? The following are copied
> from Microsoft's <tchar.h>:
>
> // Generic text macros to be used with string literals and character
> constants.
> // Will also allow symbolic constants that resolve to same.
> #ifdef  _UNICODE
>    // ++++++++++++++++++++ UNICODE       ++++++++++++++++++++
>    #define __T(x)   L ## x
> #else   /* ndef _UNICODE */
>    // ++++++++++++++++++++ SBCS and MBCS ++++++++++++++++++++
>    #define __T(x)   x
> #endif
> #define _T(x)       __T(x)
> #define _TEXT(x)       __T(x)

you could use the above - I think it would work but you might have to
include some extra sauce to generate stringw objects rather then CString, 
etc

> Finally again with question (D) below: the real question is: do I
> need the functionality of BOOST_CLASS_IMPLEMENTATION and/or
> BOOST_CLASS_TRACKING for a class like this one?

Generally should should need the above only in special cases.  I would
expect very few users - maybe 1 percent to ever need either of these.