"Robert Ramey"
Actually, I've considered reviewing all the email in this list and summarizing the results in a section "Hints and Troubleshooting Tips". I think this is useful and necessary and useful, but I just havent gotten around to it.
That sounds ideal.
But if you could provide me an example of when pointer serialization shines, then I would say "Aha! Now I understand why Robert went to so much trouble to make this work.", and I could be at peace with the world again! :-)
LOL - I haven't had time to make any real apps lately.
So... no example at all? My problem is that I just don't see when pointer serialization would be a big win. But I can't tell if I just have a limited perspective. That's why I was genuinely hoping that you could provide a concrete example. Naturally, a system that "just works" no matter what structure is thrown at it sounds very enticing. However, as you have acknowledged, the system is not foolproof, and user gotchas remain. One way to eliminate the gotchas would be to reduce the scope of the library. Clearly, this is unlikely to happen, as (i) you've invested a lot of time and effort getting the pointer magic to work, and (ii) there are probably a lot of applications out there that would break if you did so. I for one would certainly appreciate a simplified version which omitted the pointer magic, and thus removed the const trap and similar issues. If I want to set up pointers within an object, then I can do so manually using the type-specific load()/save() functions. Obviously, I can just switch to a different serialization library (e.g. s11n). But as much as possible, I would like to stick with whatever is most "standard". And as part of the Boost family, I'm guessing that boost::serialization is top dog here. Would that be right? Is this library included in any of the proposed C++ standards (TR2, C++0x)?
BTW, I don't want to sound like I'm bashing your library, so let me end with a compliment. I think the symmetric design of serialize(), with the same function used for both input and output, is one of the prettiest idioms I've seen in years.
And that's the one thing I didn't do - I believe I "borrowed" it from Jens Maurer.
Hah! Ooops. Well, that compliment backfired! ;-) Let's try again: I *really* appreciate the built-in support for all the STL container classes. So far, these have "just worked" perfectly for me. Nice work!
One tiny point. I'm aware that the "const" trap is annoying. But I've become convinced that the annoyance is small compared to the hassles it saves me and users from. I suspect that those who have a problem with aren't in the habit of using "const" everywhere they can.
It does seem bizarre to have to const-cast an object just so that it can be output. I presume that the majority of objects that are to be serialized are not intrinsically constant, so this needs to be done the majority of the time. And it looks dangerous. What does the const-cast actually mean in this context? I assume it means: "I promise that no other thread is going to modify the object (or anything its pointers point to) while the serialize() operation is pending. Is that correct? If so, then shouldn't it be solved explicitly with concurrent programming primitives (i.e. mutexes or similar)? -- Dominick