"Robert Ramey"
goes away. Any chance this could be added to a boost::serialization FAQ?
you mean change the section named "rationale" to "FAQ"?
Ermm... Yes, I suppose so. There ought to be some section that a newbie who is having problems would immediately look to see if this is a common problem. In my browser, the "Rationale" section of the documentation appears unexpanded by default. And even when I expand it, "Compile time trap when saving a non-const value" doesn't seem (when skimming the docs) relevant to the static assertion error. It also didn't appear in my Google search for the cryptic error message that the compiler produced.
The "Compile time trap" section of the documentation doesn't actually explain what "object tracking" is all about. Neither (amusingly) does the Boost->Serialization->Reference->Special Considerations->Object Tracking section!
Hmmm - well it's intended to. Maybe I just thought the meaning of the term "Object Tracking" obvious.
As a newbie, I can tell you that it wasn't obvious to me! :-) As I said, I wouldn't have expected the serialization library to do any automagical pointer stuff, so from this perspective, it's very hard to see what object tracking is, and why it would be necessary.
What on earth does it actually mean to serialize a pointer?
Exactly what you think it means - see above.
Well, once you've got an idea in your head about what should happen when a pointer is serialized (and had that concept for years, and written a whole library to implement it!), it probably seems obvious and "natural" that it should work that way. But to a newbie (to boost::serialization, not to C++), this behavior is rather surprising. For example if I do: my_class mc; my_class* mc_ptr = &mc; cout << mc_ptr; I don't get the my_class object sent to stdout. I get the value of the pointer itself. If I wanted the actual object displayed, I would dereference the pointer. So my intuition would be that boost::serialization would work in a similar way: if I wanted the object itself output/input, I would do it explicitly. I'm not trying to say that your approach is wrong. All I'm attempting to point out is that other people may have very different (and quite reasonable) expectations about what should happen.
And why would I want to do such a thing, anyway?
I don't know what your application is.
Sorry. What I meant was "Why would someone want this?" or "Why is this a useful feature?" Fundamentally, there are two approaches to dealing with pointer serialization: (1) disallow it altogether; or (2) serialize the pointed-to object, and do all the clever object-tracking stuff. The first approach has the benefit of simplicity . So the only reason to take the second approach would be if automagic pointer serialization is really useful. However, I can't think of an example of when this would be really useful. Hence my question. 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! :-) 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. -- Dominick