[serialization] compile-time detection of whether serialization is implemented for a class
I'm using the Serialization library and am trying to find a way to detect at compile-time whether or not serialization is implemented for a given type. For example, if I have
#include "boost/archive/binary_oarchive.hpp"
#include <strstream>
struct A{};
void function()
{
const A a;
std::strstream s;
boost::archive::binary_oarchive oa(s);
oa << a;
}
I get an error (as expected) along the lines of
C:\work\boost\boost/serialization/access.hpp(118): error C2039: 'serialize' : is not a member of 'A'
What I'd like is a compile-time way of detecting that 'A' is not serializable, maybe Boost Type Traits-style, something like
is_serializable<A>::value or is_serializable
Nelson, Erik - 2 wrote:
I'm sure this would be possible and probably not all that hard but would likely require a tweak in the serialization library. Add a trac item so the idea doesn't get forgotten. Robert Ramey
Robert Ramey wrote:
Okay, thanks- I gave that a shot, got a Trac error
Trac detected an internal error: OperationalError: database is locked
The action that triggered the error was:
POST: /newticket
I'll try again later.
In the meantime, I was thinking something along the lines of
template
On 02/16/2012 08:45 AM, Nelson, Erik - 2 wrote:
I was trying to do something like that before. The problem is that 1) serialize() might be private so any metaprogramming trick you are going to try will be met with a compiler error 2) how do you detect if serialization is supported using a non-intrusive way? I made a relevant question some time ago and requires decltype :( Some additional discussion: http://lists.boost.org/Archives/boost/2010/10/172236.php Bottom line, I don't think it can happen without assistance from Boost.Serialization
Ioannis Papadopoulos wrote
Thanks for the link- that looks pretty close to what I'm trying to do. It seems to me it should be possible... after all, the compiler knows if the serialization is available. If you write ar << my_type; and my_type is not serializable (either intrusively or not) the compile will fail. And if I do something like typedef boost::archive::binary_oarchive Archive; typedef boost::archive::detail::interface_oarchiveboost::archive::binary_oarchive interface_t; typedef Archive& (interface_t::*functype)(A &); Archive& (interface_t::*ptr1)(A &) = &interface_t::operator<<; Taking the address of operator<< will fail if serialization is not somehow available. It seems like turning that compile-time error into a compile-time trait might be possible, but I don't know exactly how. Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
On 02/16/2012 02:41 PM, Nelson, Erik - 2 wrote:
Hmmm, I never thought going that way. Have you ever considered something like the following in https://gist.github.com/931835 ? Maybe it can be used to detect the operator.
Ioannis Papadopoulos wrote:
Sorry for the messy quoting... my client doesn't handle it well.
Yes, I've investigated something like that, but since the function I'm trying to detect is a member template function, I think the compilers I'm using (MSVC2010, anyway) can't do it correctly- at least I haven't found a way yet. Here's the issue that seems to be the problem
http://www.cplusplus.com/forum/general/38601/
What I tried was something like
template
I would look into something like:
#include
Robert Ramey wrote:
I played around with that a little, but it looks like for that to work I'd need to do something like BOOST_CLASS_IMPLEMENTATION(my_class, boost::serialization::not_serializable) for each type that was not serializable... am I missing something? In my experiment it seems like boost::serialization::implementation_level<A>::type::value resolves to object_class_info unless I use the BOOST_CLASS_IMPLEMENTATION. That's akin to manually marking the types, which I'd like to avoid if possible. Thanks Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
participants (3)
-
Ioannis Papadopoulos -
Nelson, Erik - 2 -
Robert Ramey