Concept:

During load you may have dependencies on something which is already in memory loaded from another aspect of your application. That may be something like a renderer, or a mouse, or a central texture atlas which has its own load/save process unrelated to your existing object hierarchy. You may even need to hook up some loaded/saved items to objects outside of the save/load heirarchy (as in the case with a central texture atlas, if you have textures from a loaded scene coming in, maybe you want to register them with that atlas as they get created.)

Right now you can construct objects through cereal and any owned resources will be correctly loaded during the save/load(serialize) process. The issue is that handles to in-memory resources need to be reconstituted later.

For simple cases of flat single type objects this can be trivial to hook up after load.

RenderObject myRenderer;

JSONInputArchive archive;
std::shared_ptr<Rectangle> rect;
archive(cereal::make_nvp("rect", rect));
rect->setRenderer(myRenderer); //acceptable!  Unless the rectangle needs information about the viewport on load.  Maybe we have to re-design the class a bit, but probably workable.

This becomes more difficult, however when layers are added, and polymorphic types step in. What if I have a clickable element deep inside a scene graph and it needs reference to the mouse wrangler?

RenderThing myRenderer;
MouseWrangler myMouse;

JSONInputArchive archive;
std::shared_ptr<Node> root;
archive(cereal::make_nvp("root", root));
root->setRenderer(myRenderer); //Same as above example!
//root->setMouse(myMouse); //WHOOPSE!  What if setMouse only exists in clickable nodes?  Now the user of cereal has to make a choice as to how to fix the loaded object post-load, or make myMouse globally accessible!

Ideally we would be able to supply these additional requirements which the enclosing scope (enclosing of the archive process) would already have access to. Then propogate that through the load process so objects could grab that information during their creation/loading instead of after.

RenderThing myRenderer;
MouseWrangler myMouse;
Point defaultRotateOrigin; //just adding this for a "value" example of something we want copied.

JSONInputArchive archive;

archive.store( cereal::make_nvp("mouse", &myMouse), cereal::make_nvp("renderer", &myRenderer), cereal::make_nvp("defaultRotateOrigin", defaultRotateOrigin));

std::shared_ptr<Node> root;
archive(cereal::make_nvp("root", root));
//Oh, and hey, all the items are now responsible for their own loading.  If they try to access a value that doesn't exist in the archive we can throw or something as usual.

the following is some pseudo code:

class Clickable : public Node {
Clickable(const std::string &name, RenderThing* renderer, MouseWrangler &mouse, Point defaultRotateOrigin);
...

template <class Archive>
static void load_and_allocate( Archive & ar, cereal::allocate<Clickable > & allocate )
    {
      std::string name;
      Point position;

      ar( cereal::make_nvp("name", name), cereal::make_nvp("position", position) );

      RenderThing* renderer;
      MouseWrangler* mouse;
      Point defaultRotateOrigin;
      ar.extract(cereal::make_nvp("renderer", renderer), cereal::make_nvp("mouse", mouse), cereal::make_nvp("defaultRotateOrigin", defaultRotateOrigin));
      assert(mouse != null);

      allocate( name, renderer, mouse, defaultRotateOrigin );
      allocate.object().position = position;
}
...
}

I recently updated to a newer version of cereal and it seems like some things have changed.

On startup Cereal creates these "StaticObject" instances now for every polymorphic registration. My app now takes around 60 seconds to startup, compared to 1 second previously. I'm on iOS with an iPad Pro.

Why does this happen now? What's the benefit of these StaticObjects? Can I turn this off somehow?

The test and code has been written in similar style to that of the existing support for boost_variant, I hope this is fine. For the tests to run one shall pass -DCMAKE_CXX_STANDARD=17 to cmake.

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.

I'm opening this as a separate issue as it was introduced by the most recent couple check-ins on the develop branch. You should be using Visual Studio 2013 to reproduce this (I am currently on the November Compiler Prerelease as well, but I suspect it's a problem with the standard install too.)

#include <iostream>
#include <sstream>
#include <string>
#include <map>

#include "cereal/cereal.hpp"
#include "cereal/types/map.hpp"
#include "cereal/types/vector.hpp"
#include "cereal/types/memory.hpp"
#include "cereal/types/string.hpp"
#include "cereal/types/base_class.hpp"

#include "cereal/archives/json.hpp"
#include <cereal/types/polymorphic.hpp>

class BaseClass : public std::enable_shared_from_this<BaseClass> {
public:
    virtual ~BaseClass(){}

    template <class Archive>
    void serialize(Archive & archive){
        archive(CEREAL_NVP(name), CEREAL_NVP(baseMember));
    }
protected:
    BaseClass(const std::string &a_name):
        name(a_name){
    }

    std::string name;
    int baseMember; //let this have random junk so we can see if it saves right.
};

class DerivedClass : public BaseClass {
    friend cereal::access;
public:
    static std::shared_ptr<DerivedClass> make(const std::string &a_name, int a_derivedMember){
        return std::shared_ptr<DerivedClass>(new DerivedClass(a_name, a_derivedMember));
    }

    template <class Archive>
    void serialize(Archive & archive){
        archive(CEREAL_NVP(derivedMember), cereal::make_nvp("base", cereal::base_class<BaseClass>(this)));
    }
private:
    DerivedClass(const std::string &a_name, int a_derivedMember):
        BaseClass(a_name),
        derivedMember(a_derivedMember){
    }

    template <class Archive>
    static DerivedClass * load_and_allocate(Archive &archive){
        int derivedMember;
        archive(CEREAL_NVP(derivedMember));
        DerivedClass* object = new DerivedClass("", derivedMember);
        archive(cereal::make_nvp("base", cereal::base_class<BaseClass>(object)));
        return object;
    }

    int derivedMember;
};

CEREAL_REGISTER_TYPE(DerivedClass);

void saveTest(){
    std::stringstream stream;
    {
        cereal::JSONOutputArchive archive(stream);
        auto testSave = DerivedClass::make("TestName", 4);
        archive(cereal::make_nvp("test", testSave));
    }
    std::cout << stream.str() << std::endl;
    std::shared_ptr<DerivedClass> loaded;
    {
        cereal::JSONInputArchive archive(stream);
        archive(cereal::make_nvp("test", loaded));
    }
    std::stringstream stream2;
    {
        cereal::JSONOutputArchive archive(stream2);
        archive(cereal::make_nvp("test", loaded));
    }
    std::cout << stream2.str() << std::endl;
    std::cout << "TA-DA!" << std::endl;
}

int main(){
    saveTest();
}

The error I get is related to the line: if( ar.isSharedPointerValid ) in memory.hpp:

The following is what I get from my LIVE CODE, not from the above test. I'll go ahead and get the error for the above code this evening.

1>  textures.cpp
1>C:\git\external\cereal\include\cereal/types/memory.hpp(171): error C3867: 'cereal::InputArchive<cereal::JSONInputArchive,0>::isSharedPointerValid': function call missing argument list; use '&cereal::InputArchive<cereal::JSONInputArchive,0>::isSharedPointerValid' to create a pointer to member
1>          C:\git\external\cereal\include\cereal/cereal.hpp(767) : see reference to function template instantiation 'void cereal::load<AA,MV::FileTextureDefinition>(Archive &,cereal::memory_detail::PtrWrapper<std::shared_ptr<MV::FileTextureDefinition> &> &)' being compiled
1>          with
1>          [
1>              AA=cereal::JSONInputArchive
1>  ,            Archive=cereal::JSONInputArchive
1>          ]
1>          C:\git\external\cereal\include\cereal/cereal.hpp(692) : see reference to function template instantiation 'cereal::JSONInputArchive &cereal::InputArchive<cereal::JSONInputArchive,0>::processImpl<T>(T &)' being compiled
1>          with
1>          [
1>              T=cereal::memory_detail::PtrWrapper<std::shared_ptr<MV::FileTextureDefinition> &>
1>          ]
1>          C:\git\external\cereal\include\cereal/cereal.hpp(692) : see reference to function template instantiation 'cereal::JSONInputArchive &cereal::InputArchive<cereal::JSONInputArchive,0>::processImpl<T>(T &)' being compiled
1>          with
1>          [
1>              T=cereal::memory_detail::PtrWrapper<std::shared_ptr<MV::FileTextureDefinition> &>
1>          ]
1>          C:\git\external\cereal\include\cereal/cereal.hpp(558) : see reference to function template instantiation 'void cereal::InputArchive<cereal::JSONInputArchive,0>::process<_Ty>(T &&)' being compiled
1>          with
1>          [
1>              _Ty=cereal::memory_detail::PtrWrapper<std::shared_ptr<MV::FileTextureDefinition> &>
1>  ,            T=cereal::memory_detail::PtrWrapper<std::shared_ptr<MV::FileTextureDefinition> &>
1>          ]
1>          C:\git\external\cereal\include\cereal/cereal.hpp(558) : see reference to function template instantiation 'void cereal::InputArchive<cereal::JSONInputArchive,0>::process<_Ty>(T &&)' being compiled
1>          with
1>          [
1>              _Ty=cereal::memory_detail::PtrWrapper<std::shared_ptr<MV::FileTextureDefinition> &>
1>  ,            T=cereal::memory_detail::PtrWrapper<std::shared_ptr<MV::FileTextureDefinition> &>
1>          ]
1>          C:\git\external\cereal\include\cereal/details/polymorphic_impl.hpp(160) : see reference to function template instantiation 'ArchiveType &cereal::InputArchive<ArchiveType,0>::operator ()<cereal::memory_detail::PtrWrapper<std::shared_ptr<MV::FileTextureDefinition> &>>(cereal::memory_detail::PtrWrapper<std::shared_ptr<MV::FileTextureDefinition> &> &&)' being compiled
1>          with
1>          [
1>              ArchiveType=cereal::JSONInputArchive
1>          ]
1>          C:\git\external\cereal\include\cereal/details/polymorphic_impl.hpp(160) : see reference to function template instantiation 'ArchiveType &cereal::InputArchive<ArchiveType,0>::operator ()<cereal::memory_detail::PtrWrapper<std::shared_ptr<MV::FileTextureDefinition> &>>(cereal::memory_detail::PtrWrapper<std::shared_ptr<MV::FileTextureDefinition> &> &&)' being compiled
1>          with
1>          [
1>              ArchiveType=cereal::JSONInputArchive
1>          ]
1>          C:\git\external\cereal\include\cereal/details/polymorphic_impl.hpp(150) : while compiling class template member function 'cereal::detail::InputBindingCreator<Archive,T>::InputBindingCreator(void)'
1>          with
1>          [
1>              Archive=cereal::JSONInputArchive
1>  ,            T=MV::FileTextureDefinition
1>          ]
1>          C:\git\external\cereal\include\cereal/details/static_object.hpp(56) : see reference to function template instantiation 'cereal::detail::InputBindingCreator<Archive,T>::InputBindingCreator(void)' being compiled
1>          with
1>          [
1>              Archive=cereal::JSONInputArchive
1>  ,            T=MV::FileTextureDefinition
1>          ]
1>          C:\git\external\cereal\include\cereal/details/polymorphic_impl.hpp(293) : see reference to class template instantiation 'cereal::detail::InputBindingCreator<Archive,T>' being compiled
1>          with
1>          [
1>              Archive=cereal::JSONInputArchive
1>  ,            T=MV::FileTextureDefinition
1>          ]
1>          C:\git\external\cereal\include\cereal/details/polymorphic_impl.hpp(290) : while compiling class template member function 'void cereal::detail::polymorphic_serialization_support<cereal::JSONInputArchive,T>::instantiate(void)'
1>          with
1>          [
1>              T=MV::FileTextureDefinition
1>          ]
1>          C:\git\external\cereal\include\cereal/details/polymorphic_impl.hpp(307) : see reference to class template instantiation 'cereal::detail::polymorphic_serialization_support<cereal::JSONInputArchive,T>' being compiled
1>          with
1>          [
1>              T=MV::FileTextureDefinition
1>          ]
1>          C:\git\external\cereal\include\cereal/details/polymorphic_impl.hpp(306) : while compiling class template member function 'void cereal::detail::bind_to_archives<MV::FileTextureDefinition>::bind(std::false_type) const'
1>          C:\git\external\cereal\include\cereal/details/polymorphic_impl.hpp(321) : see reference to function template instantiation 'void cereal::detail::bind_to_archives<MV::FileTextureDefinition>::bind(std::false_type) const' being compiled
1>          Source\Render\textures.cpp(13) : see reference to class template instantiation 'cereal::detail::bind_to_archives<MV::FileTextureDefinition>' being compiled
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I'm having issues with circular references. I'm not sure if this is another bug or if there's something I'm doing wrong. It seems like creating a nested pointer_wrapper to a node higher up the chain fails and simply returns 1. I'm getting an exception throwing on load because of this:

throw Exception("Error while trying to deserialize a smart pointer. Could not find id " + std::to_string(id));

Also, another oddity is that shared_ptr objects no matter if they are polymorphic or not seem to need to need CEREAL_REGISTER_TYPE which means I need to give them a virtual method as well. Trying to remove the CEREAL_REGISTER_TYPE and virtual destructor for ChildWithPointerToParent fails at compile time.

#include <iostream>
#include <sstream>
#include <string>
#include <map>

#include "cereal/cereal.hpp"
#include "cereal/types/map.hpp"
#include "cereal/types/vector.hpp"
#include "cereal/types/memory.hpp"
#include "cereal/types/string.hpp"
#include "cereal/types/base_class.hpp"

#include "cereal/archives/json.hpp"
#include <cereal/types/polymorphic.hpp>

class ChildWithPointerToParent;

class BaseClass : public std::enable_shared_from_this<BaseClass> {
public:
    virtual ~BaseClass(){}

    template <class Archive>
    void serialize(Archive & archive){
        archive(CEREAL_NVP(name), CEREAL_NVP(baseMember), CEREAL_NVP(child));
    }

    void addChild(std::shared_ptr<ChildWithPointerToParent> a_child){
        child = a_child;
    }
protected:
    BaseClass(const std::string &a_name):
        name(a_name){
    }

    std::weak_ptr<ChildWithPointerToParent> child;
    std::string name;
    int baseMember; //let this have random junk so we can see if it saves right.
};

class DerivedClass : public BaseClass {
    friend cereal::access;
public:
    static std::shared_ptr<DerivedClass> make(const std::string &a_name, int a_derivedMember){
        return std::shared_ptr<DerivedClass>(new DerivedClass(a_name, a_derivedMember));
    }

    template <class Archive>
    void serialize(Archive & archive){
        archive(CEREAL_NVP(derivedMember), cereal::make_nvp("base", cereal::base_class<BaseClass>(this)));
    }
private:
    DerivedClass(const std::string &a_name, int a_derivedMember):
        BaseClass(a_name),
        derivedMember(a_derivedMember){
    }

    template <class Archive>
    static DerivedClass * load_and_allocate(Archive &archive){
        return new DerivedClass("", 0); //values loaded in serialize (using work-around in memory.hpp)
    }

    int derivedMember;
};

class ChildWithPointerToParent {
    friend cereal::access;
public:
    virtual ~ChildWithPointerToParent(){} //Why do I have to do this?  I get an error if I don't.
    static std::shared_ptr<ChildWithPointerToParent> make(std::shared_ptr<BaseClass> parent){
        return std::shared_ptr<ChildWithPointerToParent>(new ChildWithPointerToParent(parent));
    }

    template <class Archive>
    void serialize(Archive & archive){
        archive(CEREAL_NVP(parent));
    }

private:
    ChildWithPointerToParent(std::shared_ptr<BaseClass> a_parent):
        parent(a_parent){
    }

    template <class Archive>
    static ChildWithPointerToParent * load_and_allocate(Archive &archive){
        return new ChildWithPointerToParent(nullptr); //values loaded in serialize (using work-around in memory.hpp)
    }
    std::shared_ptr<BaseClass> parent;
};

CEREAL_REGISTER_TYPE(DerivedClass);
CEREAL_REGISTER_TYPE(ChildWithPointerToParent); //Why do I have to do this?  I get an error if I don't.

void saveTest(){
    std::stringstream stream;
    {
        cereal::JSONOutputArchive archive(stream);
        std::shared_ptr<BaseClass> testSave = DerivedClass::make("TestName", 4);
        std::shared_ptr<ChildWithPointerToParent> child = ChildWithPointerToParent::make(testSave);
        testSave->addChild(child);
        archive(cereal::make_nvp("test", testSave));
    }
    std::cout << stream.str() << std::endl;
    std::shared_ptr<BaseClass> loaded;
    {
        cereal::JSONInputArchive archive(stream);
        archive(cereal::make_nvp("test", loaded));
    }
    std::stringstream stream2;
    {
        cereal::JSONOutputArchive archive(stream2);
        archive(cereal::make_nvp("test", loaded));
    }
    std::cout << stream2.str() << std::endl;
    std::cout << "TA-DA!" << std::endl;
}

int main(){
    saveTest
}

EXAMPLE OF REAL WORLD USE:

I have a class of type TextureDefinition. A TextureDefinition is always created via shared_ptr. TextureDefinitions are typically stored in a map keyed by their "name" so that multiple identical TextureDefinitions don't exist, but optionally a TextureDefinition might be owned by a specific rendering object like a text character which manages its own dynamic texture. It's also possible that I only care about the TextureDefinition when loading a scene and won't want to have it owned by a central node at all, but just let it be owned by its TextureHandles (more on this later). Basically I don't have one draconic TextureManager class that deals with their lifespan.

I have another class of type TextureHandle. A TextureHandle is created by a TextureDefinition always of type shared_ptr. When the first TextureHandle is created the TextureDefinition associated with it loads into memory. When the all TextureHandles are destroyed the TextureDefinition unloads, but if something still owns the TextureDefinition it remains possible to reload it by creating new handles.

TextureDefinition maintains a list of weak_ptr's to TextureHandles (because they do not manage a TextureHandle's lifespan, something like Shape::Rectangle would have a shared_ptr).

TextureHandle maintains a shared_ptr because it would be an error to have the TextureDefinition explode while there are any active TextureHandles.

In this way, we can plot the object composition like this:

----> is weak_ptr
====> is shared_ptr
TextureDefinition1|---->TextureHandle1===>TextureDefinition1
                  |---->TextureHandle2===>TextureDefinition1
                  |---->TextureHandle3===>TextureDefinition1

The objects owning these could be a different shape for each TextureHandle and a scene manager owning the TextureDefinition so it can spawn new handles. If we don't care about spawning new handles (let's say we've loaded the whole scene already) that scene manager owned handle is optional, but the objects owning TextureHandles must still keep the TextureDefinition alive.

Seems to have an issue with the fact that we save drawListVector in the serialize method. If I comment out ar(CEREAL_NVP(drawListVector)); it stops crashing.

It was not doing this prior to pulling the latest save_from_this fix for saving.

#include <strstream>

#include "cereal/cereal.hpp"
#include "cereal/types/map.hpp"
#include "cereal/types/vector.hpp"
#include "cereal/types/memory.hpp"
#include "cereal/types/string.hpp"
#include "cereal/types/base_class.hpp"

#include "cereal/archives/json.hpp"
#include "cereal/types/polymorphic.hpp"

#include <memory>

struct A : std::enable_shared_from_this<A>
{
    typedef std::vector<std::shared_ptr<A>> DrawListVectorType;
    DrawListVectorType drawListVector;

    template <class Archive>
    void serialize(Archive & ar)
    {
        ar(CEREAL_NVP(drawListVector)); //If we don't actually save the drawListVector it's fine.  If we do, we'll get a crash in the destructor.
    }
    virtual ~A(){
    }
};

struct B : A
{
    template <class Archive>
    void serialize(Archive & ar)
    { }
};

CEREAL_REGISTER_TYPE(B);

void saveTest(){
    {
        cereal::JSONOutputArchive ar(std::cout);
        std::shared_ptr<A> a = std::make_shared<A>();
        std::shared_ptr<A> b = std::make_shared<B>();
        std::shared_ptr<A> c = std::make_shared<A>();
        a->drawListVector.push_back(b);

        b->drawListVector.push_back(c);

        ar(a);

        auto x = a->shared_from_this();
        b.reset();
        a->drawListVector.clear();
        std::cout << "grood";
    }
    std::cout << "grood";
}

int main(){
    saveTest();
}

If you are doing some pretty custom serialization/deserialization it can really help being able to know the current node key/tag.

I couldn't really figure out where to put this into the unit tests - any hints? Would you want tests for this?

The problem is in this segment of code (in xml.hpp, at or around line 261)

  template <class T> inline
  void insertType()
  {
    if( !itsOutputType )
      return;

    // generate a name for this new node
    const auto nameString = util::demangledName<T>();

    // allocate strings for all of the data in the XML object
    auto namePtr = itsXML.allocate_string( nameString.data(), nameString.size() );

    itsNodes.top().node->append_attribute( itsXML.allocate_attribute( "type", namePtr ) );
  }

Since the nameString parameter is mapped to a char ptr of length 99 issues arise. If the string is shorter, say 47 characters long, then what trails will be binary trash. If you open the resulting XML in your favorite browser it should fail to load, if you open it in an editor the trash should be obvious. To fix this problem you should explicitly let allocate_attribute know the size of "type" and "namePTR". The fix can be seen below.

I have not checked to see if something similar has occurred elsewhere in the code.

  template <class T> inline
  void insertType()
  {
    if( !itsOutputType )
      return;

    // generate a name for this new node
    const auto nameString = util::demangledName<T>();

    // allocate strings for all of the data in the XML object
    auto namePtr = itsXML.allocate_string( nameString.data(), nameString.size() );

    itsNodes.top().node->append_attribute( itsXML.allocate_attribute( "type", namePtr , 4 , nameString.size() ) );
  }

When serializing an unsigned long to JSON, cereal outputs some non-human readable data which seems to be in base64. Indeed, looking at the source code (https://github.com/USCiLab/cereal/blob/master/include/cereal/archives/json.hpp#L110), any type with a size >= sizeof(long long) is considered 'exotic' and thus base64-encoded. Furthermore, the XML output is perfectly fine (by that, I mean readable).

I fail to see why longs are base64 encoded. Is this a desired thing? Also, it means that when compiling the code in 32bits or 64 bits, we have a different output. Finally, it makes unnecessarily difficult to read the JSON output in another language (Python in my case)

Currently cereal searches for serialize, load and save. If they could be made #defines, the user of the library could specify the name of the functions that cereal should be looking for.

#ifndef CEREAL_SERIALIZE_FUNCTION_NAME
#define CEREAL_SERIALIZE_FUNCTION_NAME serialize
#endif
#ifndef CEREAL_LOAD_FUNCTION_NAME
#define CEREAL_LOAD_FUNCTION_NAME load
#endif
#ifndef CEREAL_SAVE_FUNCTION_NAME
#define CEREAL_SAVE_FUNCTION_NAME save
#endif

This is because some styling guides require functions that are Capitalized and having Serialize, Load, Save would conform.

How do you guys feel about this? Is this something that would be acceptable to create a pull request for?

I had some problems while including cereal in my project using FetchContent, so I made some small modifications to the CMakeLists.txt:

• renamed some options using the CEREAL_ prefix to make clear to which project they belong to and avoid conflicts
• changed the default value of some options so that, when not the main project, doc, sandbox and performance comparisons are disabled by default
• added a more complete check for main project

I think this edits would make it easier to depend on cereal using FetchContent, including it as submodule or similar techniques. See this other pull request for more info.

Is there a way to read the cereal output (binary/XML/JSON) with Python? I would like to process the data from cereal in Python. Is there any convenient way?

I use cereal::JSONOutputArchive serialize 1M large string, it takes more than 100ms. Is it a normal behavior ? Is there a solution to reduce the serialization time ?

` std::string str1 = std::string(100 * 1024, 'a'); oStr = std::ostringstream(); // 创建新ss对象 StopWatch sw; { cereal::JSONOutputArchive archive(oStr); archive(cereal::make_nvp("Test", str1)); } std::cout << "cereal::JSONOutputArchive 100k string cost time:" << sw.elapsed().count() << std::endl;

std::string str2 = std::string(1024 * 1024, 'a');
oStr = std::ostringstream();  // 创建新ss对象
sw.reset();
{
    cereal::JSONOutputArchive archive(oStr);
    archive(cereal::make_nvp("Test", str2));
}
std::cout << "cereal::JSONOutputArchive 1M string cost time:" << sw.elapsed().count() << std::endl;

std::string str3 = std::string(10 * 1024 * 1024, 'a');
oStr = std::ostringstream();  // 创建新ss对象
sw.reset();
{
    cereal::JSONOutputArchive archive(oStr);
    archive(cereal::make_nvp("Test", str3));
}
std::cout << "cereal::JSONOutputArchive 10M string cost time:" << sw.elapsed().count() << std::endl;

`

output log: cereal::JSONOutputArchive 100k string cost time:0.01547 cereal::JSONOutputArchive 1M string cost time:0.147921 cereal::JSONOutputArchive 10M string cost time:1.36517

Is there a way to change the outermost name tag of an XML output file? I have an XML output of a class like this: <?xml version="1.0" encoding="utf-8"?> <cereal> <Item> <ItemID>Item 1</ItemID> </Item> </cereal>

Here instead of 'cereal', I would like to have a custom name for it.

I am trying to deserialize json file, the problem is that ifstream is not supported from what I have seen in another issue and tried myself. so this:

std::ifstream input("config.json");
cereal::JSONInputArchive archive(input);

won't work.

I have tried to read each line of the file into stringstream , which also isn't working because from what I have seen cereal::JSONInputArchive expect the format of the json to have quotation mark with escape characters like this - \" and stringstream isn't doing that while reading reading the file line by line.

I have searched the net and Cereal docs but couldn't find a way to deserialize json.

Cereal has two implementations for contiguous standard library containers:

1. serialise element-wise (default)
2. serialise en-bloc

The second implementation is only chosen for arithmetic element types when, in fact, it should be chosen for all trivially-copyable types; this is exactly what the trivially-copyable trait was made for 🙂

This PR changes the behaviour. It reduces the deserialisation time in one of our applications by more than 5x!

Note that the on-disk representation is not guaranteed to stay the same, although in many cases it will.