Re: [boost] [serialization] Passing literals to oarchive

Subject: Re: [boost] [serialization] Passing literals to oarchive
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-03-27 12:49:09

Bjorn Reese wrote
> On 03/27/2015 05:40 AM, Robert Ramey wrote:
> 
>> is never called from the application but rather from lower level.  By
>> the time  interface_oarchive::operator<<(T & t) gets called, the T
>> already
>> has the "const" as part of the type.  (Actually it has a & also so the
> 
> That is not what my compiler says:
> 
> hasher.cpp:126:13: error: invalid operands to binary expression 
> ('hasher::oarchive
> <hasher::fnv1a>
> ' and 'int')
>      archive << 42 << x;
>      ~~~~~~~ ^  ~~
> /home/breese/src/boost/boost/boost/archive/detail/interface_oarchive.hpp:62:15: 
> note: candidate function [with T = int] not viable: expects an l-value 
> for 1st argument
>      Archive & operator<<(T & t){
>                ^
> 1 error generated.

I realized this immediately just after I hit the send button.  I sent
another post but 
it seems it didn't come through.  Sorry about that.

interface::operator<<(T & t) eventually calls a lower level which checks
for "constness" of T.

In this case the problem is different.  A parameter value placed on the
stack cannot be passed by "const T & t".  This syntax assumes and enforces
that t is an lvalue refeference.  To make this work, one could
pass a "universal reference "T && t" which will accept either an lvalue
or an rvalue (your literal placed on the stack).

But this would create  a couple of other issues:

a) code wouldn't be C++03 compatible any more.

b) The serialization library tracks the address of most serialized objects

in order to detect duplicates and avoid creation of multiple instances when
the archive is loaded. So serializing something currently on the the stack
would generally not be be a great idea.  In your particular case, it 
wouldn't matter since primitive types are not tracked.

Now one could add yet one more layer of TMP code to distinguish
between tracked and untracked types and handle them differently.
But that would introduce another layer of complexity and hide even
more what is going on.  I would be reluctant to do this.

So your current alternative in these cases would be to use:

int x = 42;
oa << x;

which will work without problem.  It will be no different nor less efficient
(when compiled for release) than

oa << 42;

I'm presuming that this is not a common case.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/serialization-Passing-literals-to-oarchive-tp4673832p4673865.html
Sent from the Boost - Dev mailing list archive at Nabble.com.