[Serialization] Non-standard extensions used.
The following is a dead simple example of using Boost.Serialization using an
XML output archive which follows the patterns laid down in examples:
/*
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
*/
#include <iostream>
#include
My understanding of the standard is that this operation is legal but that
the compiler
writer has the option of using a copy operation to implement it.
a) As far as I know - no compiler we've used has done this.
b) nvp is a "wrapper" in that it is just a holder for the underlying values
to be
serialized - so making a copy of this wrapper would do no harm.
This issue has provoked a lot of problematic behavior between compilers.
I'm not
sure whether the current situation is the result of evolution to universal
functionality or just an original oversight which has never been addressed.
It's interesting to consider - but not urgent as it has no practical impact
on the operation of the library.
Note that microsoft vc compilers of late are in the habit of emitting
warning messages alledging "deprecated" or non-standard behavior
where none exists. Also, some standard behavior (e.g. two-phase
lookup) is not implemented by microsoft compilers. So using
a microsoft C++ compiler (Or any particular compiler) as a definitive
test for code conformance to the standard is ill-advised.
Robert Ramey
"Stephen Hewitt"
I find the C++ standard a bit like reading a legal document (and I'm no lawyer) but the following is from ISO 14882: 3.10/5: "The result of calling a function that does not return a reference is an rvalue. User defined operators are functions, and whether such operators expect or yield lvalues is determined by their parameter and return types." 8.5.3/5 (extract): "Otherwise, the reference shall be a non-volatile const type (i.e., cvl shall be const)." 8.5.3/5 is a little complicated however and I've only quoted a small portion of it; some careful reading is probably in order. The behaviour you seem to be referring to when you say, "the compiler writer has the option of using a copy operation to implement it", is a sub-point of the point in my quote and thus I think it only applies if the reference is const. Again I feel I need to point out that I found this part of the standard more than a little confusing. There are a number of places in the standard which refer to the binding of non-const references to temporaries and refer to it as an error. I find further evidence for my assertion in the following links: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html - The whole purpose of this proposal is to address the fact that rvalues can not be bound to non-const references. http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm - Describes the "Forwarding Problem". Regards, Steve PS: Sorry if this is a re-post but I had a little trouble figuring out how to reply.
participants (2)
-
Robert Ramey
-
Stephen Hewitt