Boost logo

Boost Users :

From: Andrew Holden (aholden_at_[hidden])
Date: 2007-08-08 10:18:56


In general, templates (like serialize) should not be defined in cpp
files. The compiler must have the definition available when you call
the function so that it can specialize it. If the definition is in a
different cpp file than the call site, then the compiler can not
specialize the function. It will simply try to call it and hope it got
specialized elsewhere; linker errors result.
 
Your best option whould be to define serialize in the header file, like
[gs]etSequenceNumber.

________________________________

        From: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Oliver Kania
        Sent: Wednesday, August 08, 2007 9:48 AM
        To: boost-users
        Subject: [Boost-users] Subject : [Serialization] linker
problem,serialization method cannot be found.
        
        
        Hello and thanks for the help I received so far.
        here is my current problem:
        
        The class I try to serialize is:
        
        class LIBPALO_NG_CLASS_EXPORT CubeCache : public CUBE_INFO {
                public:
                    friend class boost::serialization::access;
                    CubeCache();
                    ~CubeCache();
        
                    void setSequenceNumber( unsigned int sequenceNumber
) {
                        m_SequenceNumber = sequenceNumber;
                    }
        
                    unsigned int getSequenceNumber() const {
                        return m_SequenceNumber;
                    }
        
                private:
                    unsigned int m_SequenceNumber;
                    template<class Archive>
                    void serialize( Archive &ar, const unsigned int
version );
                    
                };
        
        the cpp file looks as follows:
        
        #include "CubeCache.h"
        #include <boost/serialization/base_object.hpp>
        namespace jedox {
            namespace palo /* palo */
            {
                template<class Archive>
                void CubeCache::serialize( Archive &ar, const unsigned
int version ) {
                    // save/load base class information
                    ar & boost::serialization::base_object<CUBE_INFO>(
*this );
                    ar & m_SequenceNumber;
                }
                
                CubeCache::CubeCache(){;}
                CubeCache::~CubeCache(){;}
            }
        } /* jedox */
        
        The CUBE_INFO structure serializes just fine. There are no
linkage problems with the following code:
        
        int main( int argc, char* argv[] ) {
              CUBE_iNFO* const c = new CUBE_INFO();
            std::ofstream ofs("filename");
            // save data to archive
            {
                boost::archive::text_oarchive oa( ofs );
                // write class instance to archive
                oa << ( c );
                // archive and stream closed when destructors are called
            }
            return 0;
        }
        
        However, when I use CubeCache instead of CUBE_INFO in the above
code, i get a linkage error:
        
======================================================================
        libpalo_ng.obj : error LNK2019: unresolved external symbol
"private: void __thiscall jedox::palo::CubeCache::serialize<class
boost::archive::text_oarchive>(class boost::archive::text_oarchive
&,unsigned int)" ...
        
======================================================================
        
        There are no linkage problems with the library when i do not use
boost::serialization. I guess this happens
        when the linker tries to link with the serialization library.
LIBPALO_NG_CLASS_EXPORT is defined as:
        # define LIBPALO_NG_CLASS_EXPORT __declspec(dllexport)
        Regards, Oliver
        
        
        
        
        



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net