Re: [Boost-users] [serialization] compile-time detection of whether serialization is implemented for a class

Subject: Re: [Boost-users] [serialization] compile-time detection of whether serialization is implemented for a class
From: Nelson, Erik - 2 (erik.l.nelson_at_[hidden])
Date: 2012-02-16 16:37:06

Ioannis Papadopoulos wrote:

> On 02/16/2012 02:41 PM, Nelson, Erik - 2 wrote:
> > Ioannis Papadopoulos wrote
> >> On 02/16/2012 08:45 AM, Nelson, Erik - 2 wrote:
> >>>
> >>> 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<binary_oarchive, A>::value
> >>>that can detect whether or not the object has serialization
> >>> available.
> >>>
> >>> If it could work for testing pointer serialization as well
> >>> (is_serializable<A*>::value or is_ptr_serializable<A>::value) that
> >>> would be doubly super.
> >>>
> >>
> >> 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
> >>
> > 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_oarchive<boost::archive::binary_oarc
> > hive>  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
> 
> 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.

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<typename Archive, typename T>
struct HasSerializeOperator
{
   typedef boost::archive::detail::interface_oarchive<Archive> interface_t;
   template<typename U, Archive& (interface_t::*)(U &)> struct SFINAE {};
   template<typename U> static char Test(SFINAE<U, &interface_t::operator<< >*);
   template<typename U> static int Test(...);
   static const bool value = sizeof(Test<T>(0)) == sizeof(char);
};

But HasSerializeOperator<boost::archive::binary_oarchive, A>::value seems to be always true, even when taking the address of interface_t::operator<< (as in my above example) fails.  Maybe I'm missing something.

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.