.TH "cereal::specialize< Archive, T, S >" 3 "Mon Oct 26 2026 20:39:03" "cereal" \" -*- nroff -*-
.ad l
.nh
.SH NAME
cereal::specialize< Archive, T, S > \- A class used to disambiguate cases where cereal cannot detect a unique way of serializing a class\&.  

.SH SYNOPSIS
.br
.PP
.PP
\fR#include </home/build/include/cereal/specialize\&.hpp>\fP
.PP
Inherits std::false_type\&.
.SS "Related Symbols"
(Note that these are not member symbols\&.) 
.in +1c
.ti -1c
.RI "enum class \fBspecialization\fP "
.br
.in -1c
.SH "Detailed Description"
.PP 

.SS "template<class Archive, class T, \fBspecialization\fP S>
.br
struct cereal::specialize< Archive, T, S >"A class used to disambiguate cases where cereal cannot detect a unique way of serializing a class\&. 

cereal attempts to figure out which method of serialization (member vs\&. non-member serialize or load/save pair) at compile time\&. If for some reason cereal cannot find a non-ambiguous way of serializing a type, it will produce a static assertion complaining about this\&.

.PP
This can happen because you have both a serialize and load/save pair, or even because a base class has a serialize (public or private with friend access) and a derived class does not overwrite this due to choosing some other serialization type\&.

.PP
Specializing this class will tell cereal to explicitly use the serialization type you specify and it will not complain about ambiguity in its compile time selection\&. However, if cereal detects an ambiguity in specializations, it will continue to issue a static assertion\&.

.PP
.PP
.nf
class MyParent
{
  friend class cereal::access;
  template <class Archive>
  void serialize( Archive & ar ) {}
};

// Although serialize is private in MyParent, to cereal::access it will look public,
// even through MyDerived
class MyDerived : public MyParent
{
  public:
    template <class Archive>
    void load( Archive & ar ) {}

    template <class Archive>
    void save( Archive & ar ) {}
};

// The load/save pair in MyDerived is ambiguous because serialize in MyParent can
// be accessed from cereal::access\&.  This looks the same as making serialize public
// in MyParent, making it seem as though MyDerived has both a serialize and a load/save pair\&.
// cereal will complain about this at compile time unless we disambiguate:

namespace cereal
{
  // This struct specialization will tell cereal which is the right way to serialize the ambiguity
  template <class Archive> struct specialize<Archive, MyDerived, cereal::specialization::member_load_save> {};

  // If we only had a disambiguation for a specific archive type, it would look something like this
  template <> struct specialize<cereal::BinaryOutputArchive, MyDerived, cereal::specialization::member_load_save> {};
}
.fi
.PP

.PP
You can also choose to use the macros CEREAL_SPECIALIZE_FOR_ALL_ARCHIVES or CEREAL_SPECIALIZE_FOR_ARCHIVE if you want to type a little bit less\&.

.PP
\fBTemplate Parameters\fP
.RS 4
\fIT\fP The type to specialize the serialization for 
.br
\fIS\fP The specialization type to use for T 
.RE
.PP


.SH "Author"
.PP 
Generated automatically by Doxygen for cereal from the source code\&.