------- Comment #9 from igodard at pacbell dot net 2009-12-01 19:02 ------- FWIW, I think it is a design error in the standard. The resize function seems to be designed from an assumption that the vector type T is POD. The second argument should not be a T, it should be a constructor, so any added cells (if the resize extends the vector) are constructed in place rather than the construct-a-temp/copy-construct/destruct sequence. Or there should be no second argument and the null constructor used implicitly iff actually needed.
The actual usecase (that prompted the report) used the vector as a state holder in a recursive tree walk; the resize was used to cut back the state when returning from a leaf. The null constructor is seriously non-trivial for the node type, involving considerable file activity that could fail (a file system search). The workaround was simple when the problem was discovered: have a do-nothing null constructor for the vector, with the "real" null constructor turned into a constructor taking a dummy argument. Of course, that wound up getting exposed into the exported interface, and required macros to hide. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42242
