-
Notifications
You must be signed in to change notification settings - Fork 739
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Begin serialization without enclosing parent node? #303
Comments
Also this solution does not work if |
There's no built in mechanism for this but you could modify xml.hpp or json.hpp to achieve what you want. In the constructors for the output archives we start the root node, which you could selectively disable by adding some parameters to the options struct. You may have problems loading because you won't be loading valid XML/JSON documents. You could likely modify the input archives to handle this as well. |
I think you are missing the idea here. I'm not suggesting we remove the root XML node. But rather, the 2nd child that is created. Example:
The 2nd child is
This isn't invalid XML. |
Any thoughts @AzothAmmo ? |
I haven't had time to look into this much yet, but I do understand what you want to do. Without thinking through all of the implications, I think this could potentially be implemented via a wrapper class that you would use something like: ar( cereal::make_minimal( myData ) ); Which would cause I think this is a lot cleaner (implementation-wise) than adding new serialization function variants. |
I guess my point is, the current behavior seems undesirable. Is there a reason to have another root under the root you already add at the archive level? Isn't it redundant? I can't think of a single use case for it. It seems like the latter example output I provided in an earlier reply should be the default behavior. Unless the use case is to support minimal types passed directly to the archive? I can understand then, but doesn't seem like a practical scenario. I like your idea of flexibility I am just questioning if the current behavior has valid use cases. |
It is the way it is because we need to support serializing multiple objects to the same archive. |
That's true! Good point. I'll look forward to your suggested solution. On Mon, Jul 11, 2016, 6:45 PM Shane Grant notifications@github.com wrote:
|
So I am working on a
However, I'm not sure how I should implement Do you have any ideas? I want to implement this externally first and see how it works, then I'm happy to do a PR. |
My idea was more along the lines of how Naming it I'm a bit worried that there may be ways to break this mechanism through some combination of nesting it and using out of order loading. |
What this is effectively enabling is a "passthrough" to children, or a "make children into siblings" functionality. In that case, wouldn't it be reasonable to make it function as if the intermediate class doesn't exist at all? The children will be treated as siblings to the parent that initiated its serialize function. But honestly this isn't something we need to overgeneralize. I can't even make a good argument for using this functionality outside of the root level invocation to the archive. Can't we just make it a simple on/off flag at the archive level?
Effectively this forces the serializable class ( Much simpler, less scenarios to consider. Similar to this, maybe a CRTP derived class that can be used to change this behavior:
Food for thought... |
@AzothAmmo Would it be possible for you to help me come up with a solution to your This is a huge problem right now for me so I need a solution. |
Before the responses would be a struct of the form: ``` { "value0": ...the actual stuff... } ``` This is related to this issue: USCiLab/cereal#303 By crafting the response manually instead of defining the response as a C++ type that is then serialized, we solve the problem. It seems to be less code in the end anyways :-)
If you are using external serialize function, u also can fix that problem calling this function directly:
And then for serialization:
for deserialization (because cereal also doesn't wanna deserialize without enclosing parent node ):
Hope it will help somebody. |
Hi there. I wrote simple header that help to perform inline serialization (without versioning): https://github.com/LowCostCustoms/cereal-inline/blob/master/cereal_inline.hpp |
@LowCostCustoms is a versioning supported version hard to make? I took a look but immediately ran into a bit of trouble so thought I'd ask if anyone else has tried? |
I'm running into this with serializing a {
"value0": [
1,
2,
3
]
} But I want: [
1,
2,
3
] This was my first test with cereal, and I can't figure out how to get what I want. It might be back to rapidjson for me. :( |
@wrightleft |
I want to write my object to json or xml archive without the preliminary wrapper node around the root-level data. This situation is covered perfectly in this stack overflow question:
http://stackoverflow.com/questions/33726072/how-to-serialize-a-json-object-without-enclosing-it-in-a-sub-object-using-cereal
My sample code:
The above yields the wrapping object which I do not want (named
"value0"
). Per the SO answer linked previously, the solution is:However, this will not work if there are separate save/load functions or other types of callbacks.
Is there a built-in mechanism to disable the root node on
develop
?The text was updated successfully, but these errors were encountered: