Boost logo

Boost :

From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2006-10-08 18:24:08


Robert Ramey said: (by the date of Sat, 7 Oct 2006 17:12:18 -0700)

> > Jeremy Pack wrote:
> >
> >> It is, basically, a library for building plugins.
>
> Note the serialization library contains code which handles essentially same
> problem domain. Its under extended_type_info. It even has
> its own documentation. However some of the functionality
> is mixed into the serialization library.
>
> It has the following features:
>
> no common base class required for objects created by factory
> registration by GUID
> usage of rtti optional
> object don't have to be default constructible
> class definitons can be DLLs, - static templates
> refer to DLLS as necessary only if the derived class GUID
> is explicitly referred to.

So I have examined the extended_type_info docs, first a note about few
typos there, then a real question :)

1. a typo? I can't understand this sentence in
Miscellaneous/extended_type_info/features:

"The first is a global type table. it and has with an entry for each type used."

2. missing A,B,C ;) in Miscellaneous/void_cast:

 "void_cast_register();
  void_cast_register();
automatically derives the fact that A can be upcast to C and vice-versa."

3. "case studies"/shared_ptr revisited:

"... of serializing a moderatly compiicated class structure. "
                                   ^^^^
;)

4. please emphasize your example, by adding a subsection "Example" in
the doc about extended_type_info. I mean, add subsection title just before:

"The test program test_no_rtti implements this function in terms of the
extended_type_info...."

I had clicked it ( http://www.boost.org/libs/serialization/test/test_no_rtti.cpp )
the first time when I was reading from top to bottom, but later I couldn't
find it, as I did not remember where I clicked :)

5. if I use extended_type_info with rtti, will my binary files be
portable between various platforms? (I assume that without rtti they will be)

6. a bit related question: does binary serialization take care of
endianess and different sizes of fundamentals across various platforms?

                 (size in bytes)
Type ia32 PowerPC amd64
-----------------------------------
long 4 4 8
unsigned long 4 4 8
long double 12 8 16

7. the real question: is it possible to use extended_type_info for the
class factory purposes without actually using serialization, for example
like that below (with or without rtti). It's just your example, slightly
modified:

class polymorphic_base
{
    friend class boost::serialization::access;
    template<class Archive>
    void serialize(Archive & /* ar */, const unsigned int /* file_version */){
    }
public:
    virtual const char * get_key() const = 0;
    virtual ~polymorphic_base(){};
};

BOOST_IS_ABSTRACT(polymorphic_base)
BOOST_CLASS_TYPE_INFO(
    polymorphic_base,
    extended_type_info_no_rtti<polymorphic_base>
)
// note: types which use ...no_rtti MUST be exported
BOOST_CLASS_EXPORT(polymorphic_base)

class polymorphic_derived1 : public polymorphic_base
{
    friend class boost::serialization::access;
    template<class Archive>
    void serialize(Archive &ar, const unsigned int /* file_version */){
        ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(polymorphic_base);
    }
public:
    virtual const char * get_key() const ;
};

BOOST_CLASS_TYPE_INFO(
    polymorphic_derived1,
    extended_type_info_no_rtti<polymorphic_derived1>
)
BOOST_CLASS_EXPORT(polymorphic_derived1)

const char * polymorphic_derived1::get_key() const {
    const boost::serialization::extended_type_info *eti
        = boost::serialization::type_info_implementation<polymorphic_derived1>
            ::type::get_instance();
    return eti->get_key();
}

int main( int /* argc */, char* /* argv */[] )
{
// the most important line:
// this function takes 'const char* class_name' (or GUID ?) as an argument.
    polymorphic_base* p=please_somehow__create_an_instance_of("polymorphic_derived1");
}

-- 
Janek Kozicki                                                         |

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk