Hi Lin,
I've verified & reproduced the bug you mentioned. Thanks for
the heads-up.
The current workaround for this is to use a pointer to your
BamWriter:
std::vector<BamTools::BamWriter*>
writers(numInput, 0);
for ( int i =
0; i < numInput; ++i ) {
writers[i] = new BamWriter;
if ( !writers[i]->Open(....) {
cerr << .....
}
}
// do stuff
with writers, and then
// later on, cleanup
for ( int i =
0; i < numInput; ++i ) {
if ( writers[i] ) {
writers[i]->Close();
delete writers[i];
writers[i] = 0;
}
}
I know it's a little extra effort to manage the memory manually,
but it will work. In fact several command-line utilities (e.g.
'bamtools split', and API classes (e.g. BamMultiReader) use this
approach for readers & writers. There are other reasons I had
used the pointer approach, but that at least explains why I
haven't seen this behavior so far. I'm sure it has to do with the
pimpl not playing well with STL copy behavior for containers. I'll
make a note to fix this in the next major release.
Please let me know this helps or not.
- Derek