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-oarchiv... Sent from the Boost - Dev mailing list archive at Nabble.com.