From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-22 01:28:47
Robert Ramey wrote:
>> For example:
>> binary_object make_binary_object(void* ptr, unsigned size);
>> Returns: binary_object(ptr, size);
>> binary_object::save(Archive& ar, unsigned version)
>> Effects: Calls ar.save_binary(m_ptr, m_size);
> Aside - I wouldn't expect load/save/load_binary/save_binary to ever be
> invoked by a library user.
But make_binary_object is likely to be called, and to understand what it
does you need docs for binary_object::save.
>> It would be nice to avoid asking the user to do BOOST_CLASS_EXPORT for
>> all possible argument types. What's desirable is:
>> template<class T>
>> void register_rpc_function(const char* name, void (*f)(const T&))
>> functions[name] = ... ;
>> boost::serialization::export_class< function_call_1<T>
>> I can't put BOOST_CLASS_EXPORT in register_rpc function now.
> This situation is discussed in the documentation under the heading
> Serialization Traits". There is an example that uses assignation of
> to the nvp<T> template. BOOST_CLASS_EXPORT is just a syntactic short hand
> to for the specialization above. Uh-oh - I just looked at the definition
> of BOOST_CLASS_EXPORT and I see it's not that obvious as it is in the
> other traits.
Exactly. Not to mention that BOOST_CLASS_EXPORT
1. Instantiates a function
2. Instantiates a helper class
Which is considerably more complex than specializing a trait class and
cannot be done in arbitrary place.
>> I'm afraid the no matter how smart XML reader is, it still would have to
>> scan the entire file.
> So what's wrong with that? I would guess that such an XML reader already
> exists somewhere and you cat get everything thing for free. Assuming this
> doesn't address your need, and you want to do some programming, one can
> create another XML archive version. This would create two output files.
I guess I have two questions:
1. Won't serialization fail in some way if I just seek the stream to the
position found in index and try reading.
2. For random access I need to make sure that all saved objects have export
key. How do I do that? Not necessary out-of-the box but where I can plug
>> The reason why I think the other is important, it that's it's actually
>> saving/loading support for plain C++ array -- which is rather basic
> Hmmm - the library already implements serialization of plane C++ arrays by
> serializing each element.
For *fixed-size* arrays. But not for dynamically allocated arrays. BTW, it
seems we need two wrappers for completeness: one for dynamic arrays with
element-wise save and another for dynamic arrays with binary save.
>> But you won't catch a case where you save one type and load another.
> True, but I think it would help a lot - and practically free to implement.
That would be good.
>> So, the get zero overhead I need to tweak base class an disable tracking
>> pointers. Let me try that... yea, the results are nice. One one extra
>> element (class id) per saved item.
> If your not serializing pointers, the class_id isn't written to the
> even once. Object id is required for tracking, class id is required for
> pointers. If versioning is used, class-id is used once. I do not believe
> that there is any information stored in an archive which is not used.
I agree. I actually have a *crazy* but cute idea that one can use file
offset for object id. How object ids are assigned and can I customize that
process? That would keep overhead at absolute minimum.
>> BTW, how to I set tracking level and implementation level for a template
>> class. I think I can partially specialize 'tracking_level', but it should
>> be mentioned in the docs.
> See docs section "Template Serialization Traits"
Ah, I've missed that. Do I need to provide both 'type' and 'value'? Can't
serialization library work with just one?
>> It also necessary to provide overload for char*. Does not count as
> Default implementation for char * will work as it does for other pointers.
Eh... I though that serialization of pointers to builtin types is just not
Actually, my archive initially have only one (non-templated) 'save' for
unsigned. I got compile error until I've declared 'save' for const char*.
I'm not sure why.
> I came to conclude it presented a big security risk. The problem is the
> char str[MAX_STRING_SIZE]
> ar >> static_cast<char *>(str); // to avoid str being treated as an array
> suppose the text archive gets corrupted to:
> 3000 abc............
> The archive will load with a buffer overrun - a security risk.
Right. I think this problem can be addressed with a wrapper for dynamic
ar >> make_dynarray_wrapper(str)
so that the library allocates the string itself.
>> Can I define only one 'load' for unsigned int?
> As oppose to ?
As opposed to overloads for all builtin types. For polymorphic_archive we
can't have templated function which 'fallbacks' anywhere. We need to have a
closed set of virtual functions and I wonder what's the minimal set.
> the rest. BTW this provided a huge benefit. In the original version of
> last year I got into a never-ending battle to specify virtual functions
> which was
> dependent on the compiler - long long, etc. It was hopeless - moving to
> templates solved that.
:-( I guess we're back to those problems.
>> > I've concluded this myself. Its pretty easy given the bjam setup.
>> > it can be made even easier with a bjam argument or environmental
>> > It
>> > just needs to be explained.
> BTW as a bjam expert, you might want to suggest how to do this in cool
> I would love to have a shell script which lets me do
> test_archive <toolset> <archive>
> But I don't see how to fix up the bjam files to support this. As a bjam
> expert, maybe you could look into this.
Maybe it could be possible.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk