This is likely a secondary effect from some other error. There's no way I can help with this. But still, I'll give it a try. I know from previous questions that you're using serialization pretty extensively in more complex scenarios: derived classes, abstract classes, dlls, pointers etc. So when you have a problem the source of the failure isn't easy to find. I don't know if you already do this, but I'll suggest it anyway in case you don't. Take a look at the tests in the serialization library. There is approximately 60 of them. Most of them are run for each of the archive classes delivered with the serialization library. So that results in a couple of hundred distinct tests. For each one of your classes, you should make a test. This test should include the archive class as a test/template parameter like the serialization library tests do. Your tests should be run in particular order - base classes first. test A #include "A.hpp" main(... // code create, save and load an instance of A and pointer to A // maybe collections of A as well? test B #include "B.hpp" // which includes A main(.. // code create, save and load an instance of B and pointer to B Now I know that this "seems" like a huge amount of work. But in practice it's a lot less work than it seems. This amount of investment save huge amounts of time in the long run. a) Once you've created the first test_A, subsequent ones are created by copying this first one and changing A to B and some other changes. It generally takes only a few minutes. b) Everytime anyone makes a change to a class A, the tests which use this component are re-run. This guarentees that you're not moving backwards. My principle environment is MSVC IDE. Each test is a separate project. The post-build step is setup to run the test. The project for test A is dependent upon the code in A, the code in test A an the serialization library. of these change, the test is automatically re-compiled, re-linked and the test is re-run automatically. If any test fails, the build fails and I can't go on without addressing the problem. That is I stop myself from building crappy code which I would otherwise do. c) This forces you to maintain a hierarchy of composable components and stops one's code from morphing into a "rat's nest" of inter-module calls which is impossible to debug. e) If something fails, you automatically have a test case to submit. d) This makes bug-free code development MUCH faster. I don't know if this helps - but it makes me feel better. Good Luck. Robert Ramey elizabeta petreska wrote:
Hello I do not have small working example, and can't reduce the problem to such. I know that is impossible to say what can be the problem from the following information, but still I 'll give it a try. I am getting runtime error in STL ( vector is out of range error ) when trying to load my shared pointer. The runtime error happens in basic_iarchive.cpp line line 431 :
cobject_id_vector[i].bpis_ptr = bpis_ptr;
I am using boost 1.41. Anyone has seen this error and maybe knows what can get to it.
Thanks
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users