[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [modularization] Extract xml_archive from serialization
From:       Vladimir Prus <vladimir () codesourcery ! com>
Date:       2014-09-22 19:05:06
Message-ID: lvprt2$jrf$1 () ger ! gmane ! org
[Download RAW message or body]

On 09/19/2014 09:20 AM, Emil Dotchevski wrote:
> On Thu, Sep 18, 2014 at 9:53 PM, Vladimir Prus <vladimir@codesourcery.com>
> wrote:
>
>> On 09/18/2014 10:29 PM, Emil Dotchevski wrote:
>>
>>> In principle there should be no reason for e.g. time_serialize.hpp to
>>> include Boost Serialization headers in order to define the "load" or"save"
>>> function templates needed for serialization.
>>>
>>> For example, to define:
>>>
>>> template<class Archive>
>>> void save( Archive & ar, const posix_time::time_duration& td, unsigned int
>>> /*version*/)
>>> {
>>>      ....
>>> }
>>>
>>> one doesn't need to include any serialization headers.
>>>
>>
>> That's true as far as general C++ goes, but you'd very likely need to use
>> BOOST_SERIALIZATION_NVP - and for XML archives it's required to use it -
>> and it's a macro, so two phase lookup won't help?
>>
>
> Sure, one can write a serialization library that makes this kind of
> definition impossible. My point is that in principle it is possible and if
> there is a general agreement to refactor important libraries to reduce
> physical coupling then it is something that can be done.
>
> This is even more important for a library like Serialization because any
> data type may need the ability to be serialized yet many (most?) programs
> that use such types will not serialize them.

Yes, it's possible in principle, and even with current serialization code,
but it's not clear that replacing

	BOOST_SERIALIZATION_NVP(data_member)

with

	boost::serialization::make_nvp("data_member", data_member)

is net win.

- Volodya
		


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]