Each check is only reasonable if it finds more bugs than it causes problems. We seem to disagree about the proportion for the *specific case* of the >check in serialization library.
I guess so. But you might check Joaquin's previous message regarding this.
Of course your correct on this. But lot's of people drive without seat belts too. That doesn't mean that the rest of us should be prohibited from using them.
I don't think the analogy is correct. I guess if you were required to refasten the belt each time you change gear, you won't be using it.
If this is happening more than an occasionally, I would guess you're using the library in ways that I failed to envision. In my demos and examples it was easy to avoid the problem without casts and the tests/demos do things like save and load within the same function that not the most usual case.
Default trait is non-primitive objects is "track_selectivly" This means that objects will be tracked if and only anywhere in the source, some object of this class is serialized through a pointer. So when I'm compiling one module above and checking at compile time I realy don't know that the object will in fact be tracked. So I trap unless the serialization trait is set to "track never". To reiterate, in this case the object won't be tracked unless somewhere else its serialized as a pointer.
I'm not sure this behaviour is right. It certainly matters if I save the *same* object as pointer or not. Why does it matter if I have *another* object by pointer.
Suppose you've saving an object with the same address twice. There possible situations are:
1. Both saves are via pointers. You enable tracking for this address; only one object is actually saved. User is responsible for making sure that the object does not change between saves.
2. First save is via pointer, the second is not by pointer. You throw pointer_conflict.
3. First save is not by pointer, second is by pointer. You ehable tracking >for this address.
4. Both saves are not via pointer. You don't track anything.
Is there anything wrong with above behaviour?
#3 -for this address-. We can't know at compile time what the addresses of the objects are. If an object of a certain type is serialized anywhere in the program through a pointer, we have to instantiate code to track pointers.
class a ( X & m_x; .... };
And how would you deserialize this, given that references are not rebindable?
Specialization of save/load_construct_data
for(...{
X x = *it; // create a copy of ar << x }
How do we know that one of the x's saved in the loop is not serialized asa pointer somewhere else?
You keep a set of addresses of all saved objects.
Isn't it just easier and better just to let the serialization system do it by reformulating the above as: For(... const X & x = *it; ar << x }
We have to track ALL x's because we don't know which ones if any are being tracked somewhere else. It could even be in a different module.
Right, you need to track all addressed while saving, but in archive the saves from the above loop need not be marked as tracked.
Currently there is no way (and no need in my opinion) to assign tracking behavior for each invocation of the << and >> operator. If you want to suppress tracking altogether for type X you can assign track_never trait. In the case the STATIC_ASSERT won't trap - so there you are.
const X x; const X& x2 = x;
are you saying that saving them works differently?
I'm saying that const X &x = m_x; ar << x; is different thatn const x = m_x ar << x;
which we are quite comfortable with. In fact I believe
auto_ptr<const Data> finish() { //auto_ptr<Data> result; // whoops auto_ptr<const Data> result; // modify result return result; }
expresses your intention quite well. That you're returning an auto_ptr to an object that you don't expect should be changed by anyone who gets the pointer this way.
Except that it does not compile.
I recall that in earlier versions users simple *could not* serialize a pointer to int. Did that change or I am wrong?
It could probably be done by tweaking the serialization traits for int but that would ripple through the whole program. Robert Ramey