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: Ioannis Papadopoulos (ipapadop_at_[hidden])
Date: 2012-02-16 16:19:38

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_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

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.

>
> ----------------------------------------------------------------------
> 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.