troy d. straszheim wrote:
Robert Ramey wrote:
There might be people interested. You might upload it to the vault.
You don't have to write a test program. You can use all the boost archive test programs with your own archives by following the instructions in the documentation Reference/Archve Class Reference/ Testing. The batch file run_archive_test.bat will run all the tests with your archive.
Right. This testing architecture I've used; the portable_binary_(i|o)archive and the polymorphic version pass all the existing serialization tests, alongside the regular binary, text, and xml archives (I just got all that done, it's sitting here on disk.)
So that much is good. But of course the real test of such an archive is to verify that you can correctly read on platform A what was written on platform B, and vice-versa. I've done this testing (probably to the point of overkill), but again with a different testing scheme. One thing inherent to the problem is that you are required to have portable binary archives checked in to source control.
This is something that my test suite should test but doesn't. Regardless of what happens with your portable_binary archive, It would be very helpful to have the test suite enhanced to explicitly test archive portability. Since we're just talking, So I would like to see the following changes in the test suite: a) That output of the tests go to a particular directory. There would be a directory for each column in the test matrix. b) There would be a set of directories for each boost release 1.32, 1.33, ... c) Tests would be run on the four combinations which result from: i) set of archives created by the previous version ii) set of archives created by other compilers (portable archives only) This would result in a HUGE number of tests so it couldn't be run any more than on an occasional basis. But it would be helpful to run very occasionally. This would require more investigation into boost test in order to find out what facilities are already there for helping out with ths. d) An alternative to the above might be just to make some specific tests for backward compatibility and for cross compiler compatibility. This is probably a better idea as it would result in tests that could be run more frequently. e) That the tests move to the boost unit test library rather than the test exec library. e) A number of tests leave memory leaks. I would prefer to fix these if it were possible to do so without making the tests so complex that they are no longer serve as convincing tests. Just food for thought. Robert Ramey