[Bug libstdc++/42242] vector::resize could be split up into two different functions
igodard at pacbell dot net
gcc-bugzilla@gcc.gnu.org
Tue Dec 1 19:02:00 GMT 2009
------- 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
More information about the Gcc-bugs
mailing list