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

From: TOL: Emmanuil Tsagarakis (mtsagara_at_[hidden])
Date: 2006-05-08 23:52:15

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 ...

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)

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?

template<class T, int SZ>
class CPropRepository
{
public:
        //uniform typedefs used in STL algorithms and containers
        typedef T           value_type;
        typedef T*          iterator;
        typedef const T *   const_iterator;
        typedef T&          reference;
        typedef const T&    const_reference;
        ...

private:
        value_type  _t[SZ];
        friend class boost::serialization::access;
        template<class Archive> void serialize(Archive & ar, const unsigned
int /*version*/)
        {
            ar & BOOST_SERIALIZATION_NVP(_t);
        }
};

Used like this:

class A
{
        CPropRepository<int, 2> m_intProps;

        friend class boost::serialization::access;
        template<class Archive> void serialize(Archive & ar, const unsigned
int /*version*/)
        {
            ar & BOOST_SERIALIZATION_NVP(m_intProps);
        }

public:
        ...
};

Thank you again,

Emmanuil Tsagarakis

Manos Tsagarakis wrote:
>> Hello Robert,
>>
>> Thank you for the quick response.
>>
>> I'm glad you liked the title ...
>>
>> A) I did replace all BOOST_CLASS_EXPORT with BOOST_CLASS_EXPORT_GUID, 
>> but the problem with xml persists. It is really difficult for me to 
>> figure out what is wrong with xml, as both txt and bin versions are 
>> ok. Actually what worries me, is the possibility that the problem 
>> with xml somehow will show up in other formats too ...

I not sure that the exported name can have a ':' in it without tripping up
XML If that's not it I'm not sure what it is.

>> B) I don't use the version numbers at the moment but I added it just 
>> for future use. I actually have a couple of questions here.
>> 1) BOOST_CLASS_VERSION has to be in the header file? Can I place it 
>> in the cpp file?
>> 2) Please correct me If I'm wrong: I don't use BOOST_CLASS_VERSION so 
>> that all classes have version number assignment set to 0. I also 
>> don't use BOOST_SERIALIZATION_SPLIT_MEMBER for now. Later on, I add 
>> some members, so that the class version must change. I simply add 
>> BOOST_CLASS_VERSION(..., 1) and split serialize to save/load at that 
>> time. Previously saved data files are not affected as long as version 
>> info is handled correctly by my code. Is that correct?

Correct - BTW you don't necessarily have to split but in many cases it would
be the easiest  thing to do..

>> C) I avoid using templated code in CTCDataBase for as long as the 
>> core data that must be serialized evolve, in order to avoid 
>> frequently modification of the most included header file 
>> TC_database.h. That meens almost recompile all, and that takes time.
>> Thank you for the suggestion any way. I'll keep it in mind. To be 
>> honest, I did try to use export feature of templates bug no luck ...

The way to do it is to leave the template definition in a header and an
explicity instanticiation in a *.cpp file.  That is how the serialization
library diminishes compilation.

>> D) I re-attach a couple of header files to this post and I kindly ask 
>> you to take a look at the implementation and tracking level for 
>> template class fem::CPropRepository implementation_level<
>> fem::CPropRepository<T, SZ> > and     tracking_level<
>> fem::CPropRepository<T, SZ> >, and one utilization of it at the other 
>> header. Should it be so? Do I need it? And also is it possible that 
>> using this CPropRepository stuff (especially with MFC CString) breaks 
>> the xml code?

A fundemental problem here:

//either use macro definitions:
//BOOST_CLASS_IMPLEMENTATION(nvp<T>,
boost::serialization::level_type::object_serializable)
//BOOST_CLASS_TRACKING(nvp<T>, boost::serialization::track_never)

the arguments can't be templates but must be expanded types.  This is
described in the manual
- I forget where.  If you need this functionality, you can't use the macro. 
You have to copy
the original definition and make the substitution by hand.  If you look at
the macro definition and "expand it by hand" you'll see that it won't result
in valid code.

>> E) After adding all headers of the serialize library compilation 
>> takes a lot more time. Are there any guidelines by you on that?

Here's what I recommend.  Look at the demo/example/test demo_pimpl. This
shows how one can separate the instantiated serialization code into a
separate *.cpp module.  This will mean that its only compiled when the
serialization changes.  In fact the best way is to add all the *.cpp modules
for all archives in a library. 
That way
they are almost never compiled and executables only contain the stuff
actually used.

Robert Ramey

_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users