Primitive types

[DrAWolf]

I am missing the equivalent of
BOOST_CLASS_IMPLEMENTATION(MyClass, primitive_type)

Example:
I have classes that already know how to convert to/from a string.
so I use

template<class Archive>                                 
void save( Archive& archive ) const                         
{                                                                           
    archive( ToString() );              
}          

resulting in the JSON

"testobject": {
    "value0": "testobjectAsString"
}

but WHAT I WANT is just a single line

"testobject": "testobjectAsString"

---

Remark: the same thing happens for ENUMs in your implementation.
They are always saved as a 2-level object, which seems unnecessary.

---

[DrAWolf]

I also tried to call
archive.saveValue( ToString() )
instead of
archive( ToString() );
directly, but this results in a crash
the former should either be private or it should have a well defined behaviour...

[AzothAmmo]

Making enum a single level should be no problem. As far as your first issue goes, I'm not sure I have a good way of solving it that doesn't complicate the API unnecessarily. You can accomplish what you want by moving the actual toString call up a level, e.g.:

archive( cereal::make_nvp("some cool name", myObject.toString()) ); // saving

std::string stringrep; // load the string
archive( cereal::make_nvp("some cool name", stringrep) ); // NVP not strictly required here, but we'll soon support out of order loading
myObject = MyObject( stringrep ); // construct from string, or whatever

The way our serialization code works right now, by the time we've entered into the save function we've already opened up a node in the JSON and started an object or array. I don't like the idea of bringing in more Boost functionality here just to get rid of one word in the JSON.

There are a few functions in the JSON (and likely in the XML) archives that are not intended for public use (they have to be coupled with other functions for setting up/tearing down state) and those will get changed to be private.

[AzothAmmo]

Actually I just thought of how you can solve your issue quite easily, through the same mechanism I'll be using with the enum types. If you look into the JSON archive header, you'll notice that we have various prologue/epilogue functions that get called immediately before and immediately after the serialize function is called for a specific type.

You can use these to control when the JSON archive creates/ends nodes and get the functionality you desire. It's a little more effort than us providing a macro, but the prologue/epilogue functions provide a lot more power than fixed functionality.

[DrAWolf]

Thanks for your answers.

+1 in advance for putting in the std::is_enum or !std::is_enum in the appropriate enable_ifs for JSON and XML.

(As I read from your second thoughts, you agree that the "one level up" approach is quite unsatisfactory, because it breaks encapsulation/unity etc. )

I was indeed playing around with those enable_if lines (tried the enum first).
The only trait I found useful: is_convertible. Got that working easily. But I really do not want to have implicit conversions to string.
I'd have to modify your code anyway.
Your last suggestion also requires that.

I still hold the opinion that you should offer a trait for this (e.g. 'is_cereal_primitive') that the user can set for his class if he needs/wants to and that your archive impls use in all the places you now use 'is_enum'.

I also think you will someday need/want to use the same technique for 'is_bitwise_serializable'

As I am into traits for no longer than a total of 3-4 hours I cannot figure that out atm.
One could use is_convertible<T,cereal_primitive> where cereal_primitive would be a dummy class.
The user would then add a dummy operator cereal_primitive const { return cereal_primitive(); } (using a Macro)
to make that conversion available...
But this idea seems a little non-standard and misleading...

[DrAWolf]

It's actually simpler than expected:

I added the following lines to cereal.hpp

  template< typename T >
  struct is_primitive
  {
      static const bool value = false;  // default is non-primitve
  };

  #define CEREAL_PRIMITVE_TYPE( Type )                            \
  namespace cereal                                                \
  {                                                               \
      template<>                                                  \
      struct is_primitive< Type >                                 \
      {                                                           \
          static const bool value = true;                         \
      };                                                          \
  } 

and used cereal::is_primitive in the appropriate enable_if lines of the archive
e.g.

  template <class T>
  typename std::enable_if<!std::is_arithmetic<T>::value && !std::is_enum<T>::value && !cereal::is_primitive<T>::value , void>::type
  prologue( JSONOutputArchive & ar, T const & )
  {
    ar.startNode();
  }

if I now put

CEREAL_PRIMITVE_TYPE( testclass )

after my class definition, it serializes as expected.

[AzothAmmo]

That's a fairly clean solution but I'm still not sure about introducing it into cereal, since it can be accomplished by just writing your own prologue/epilogue functions (which can be anywhere - these don't need to reside in json.hpp for example), which is what I would prefer to see someone do.

So basically your solution minus the traits, which is more verbose in general but keeps the interface cleaner. It would look like, for your example:

(in one of your headers, so long as it knew about JSONOutputArchive)

void prologue( JSONOutputArchive & ar, testclass const & t )
{
  // whatever is needed/not needed
}

void epilogue( JSONOutputArchive & ar, testclass const & t )
{
  // whatever is needed/not needed
}

You could then use this overload, which would be preferred over the generic template version, to control whether your class needed to do setup/teardown operations for the archive.

I'm not sure if there is going to be a trivial way to make the various internal functionality of the JSON/XML archives private, since unfortunately a friend declaration like template <class U> friend void prologue( JSONOutputArchive &, U const & ); will not catch things such as template <class T> void prologue( JSONOutputArchive &, SomeType<T, MaybeOtherT> const & ); and I don't want peole writing their own epi/prologue or save/load functions to have to manually add themselves as friends.

[DrAWolf]

Valid solution, too, but...

I think we are now entering the arena of clean code discussion, always leading to a fight :o)
I'm not a fighter, so I will just state my points, maybe they are 'wrong', maybe you will come back to them in a later version/refactoring.
Do not feel obliged to answer/defend.(except for point 5)
I think you have done a great job so far.

1
IMHO the prologue/epilogue/save/load interface - clean and simple inside cereal.hpp - is already too messy inside e.g. json.hpp. With the cascades of enable_ifs and other templates, it's quite hard to figure out what is really happening. Coders greater than me are advising not to use enable_if.

2
Additional confusion (in me) arises from the fact, that prologue/epilogue/save/load can be called with or without a NVP and even with a SizeTag. In this respect, the interface could be cleaned up a little. I would probably add 'makeName' and 'makeSize' as interface functions and call pro/epi/save/load only with the objects that are serialized.

3
Your definition of the archive-interface is too vague for my taste.
Much is done through calling ar( something ), but then at multiple points along the way it is spread into save/load (for types) an the into pro/epi/save/load (for archives) This is going too deep, I am not your code-analyst, but I just feel it could be cleaner there.

4
All that is needed in json.cpp and other archives (and somehow done by your SFINAE code) is to discriminate
primitive types (int,float,enum, AND user defined) => do not open a new node/object
array (or array like / SizeTag) => open an array
other => open a new node
(binary => ... )

5
Coming back to your proposed solution: Writing custom pro/epi functions will only add to the mess adressed in 1.
If a type/user class is considered/defined 'primitive', this applies to all archives, even the ones not written yet.
I want my primitive classes (as well as enums) not to open a new node in any of those archives.

[randvoorhies]

The solution I like is to introduce another set of serialization functions, e.g.

struct party_goer
{
  bool is_fun;
  bool is_male;

  std::string save_string()
  {
     return std::string(is_fun ? "amusing" : "boring") + " " + std::string(is_male ? "guy" : "girl");
  }

  void load_string(std::string const & s)
  {
     std::vector<std::string> vals;
     boost::split(vals,s,boost::is_any_of(" "));

     if(vals[0] == "amusing") is_fun = true;
     else if(vals[0] == "boring") is_fun = false;
     else throw "Bad fun value in string";

     if(vals[1] == "guy") is_male = true;
     else if(vals[1] == "girl") is_male = false;
     else throw "Bad gender value in string";
  }
};

We would obviously add non-member versions, and a load_and_allocate version as well.

[AzothAmmo]

Initially this was only going to make it in as a change to enums but the current plan is to do something more along your request for something like is_primitive. We can't allow users to blindly write their own serialization functions if they mark something as primitive however, since attempting to serialize more than one item would cause issues. So this will likely be paired with some sort of special set of serialization functions, either in the form of string representations or something else to ensure that only a single value is serialized.

[DrAWolf]

Nice to hear.
The randvoorhies way covers 80% of my use cases - classes that simply serialize to/from a string.

1
I guess, it is understood (but you did not mention) that for binary archives, ordinary serialization takes place (to make it smaller and faster), while for text archives save_string and load_string are used if available.

2
You did not mention enums. I guess they would be covered by non-member versions I could define for my enums like this

template<class Archive>  
void save_string( Archive& archive, const myEnum& m ) 
{ 
    std::string a = myEnumToString( m );
    archive( a );
} 

[DrAWolf]

My second intention concerning is_primitive was to remove clutter from the JSON(XML) files.
So if a class just saves as - say just one int (or double or string) the result should just be

"testobject": 42,

if a class is flagged as 'primitive'. Maybe this could even happen automatically!?
Also covering this case, would indeed have all my use cases covered. Thx in advance...

[AzothAmmo]

I do want it to happen automatically if possible, my only concern is if someone tries to serialize something with either an NVP or more than one thing within their serialization function for a class declared as "primitive", it will lead to undefined behavior that we won't catch at compile time. This leads to the potential need for specialized "minimal" serialization functions for this case. Use case from a user would be something like adding either serialize_minimal, load_minimal, (etc), which we would automatically detect and use for a text archive. Still haven't fully decided on the interface for all of this.

[AzothAmmo]

Quick update on this - the current design, which you can follow here, is to add a new pair of serialization functions to cereal: load_primitive and save_primitive (both member and non-member versions).

The interface will be something like

struct A
{
  template <class Archive>
  std::string save_minimal( Archive & ar )
  { /* somehow bundle self up into a string, or any primitive type */ }
  template <class Archive>
  void load_minimal( Archive & ar, std::string const & data )
  { /* loaded data contained in data, type must match return type of save_minimal */ }
};

You won't be able to mix these with other serialization types unless you tell cereal to explicitly use one type. You can pick the return type of save so that it outputs any primitive type or a string. It may be that we end up not passing the archive so you can't try and save or load extra stuff here, though we'll probably keep the template type to allow specialization.

enums will default to a minimal numerical representation after all of this.

[DrAWolf]

Sounds reasonable, but a little confusing to me.

Because we are talking about primitive types, supported by every archive, I don't think, template specialization will ever be needed or make sense.

Possible issues (apart from templatization).
If enums default to int, will it be possible to override that by defining non-member std::string save_minimal( const myEnum& m )?
What if the user defined 'std::string save_minimal()' AND 'int save_minimal()'?
What if the user defined different types in save and load?
What if the user defined 'std::string save_minimal()' AND standard 'save'?
Seems like an awful lot of compile time testing to me...

Maybe you will be better off using just save_string and load_string applicable to text archives only.