You could implement it with realloc. The problem is it's not part of the interface the standard containers use, so they wouldn't be able to use it.
You could implement it with realloc. The problem is it's not part of the interface the standard containers use, so they wouldn't be able to use it.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
I have never in my life traced a performance problem to an expanding array that was implemented correctly. Whether copies are required or not. I think you're imagining problems that don't exist.
If an object is expensive to copy, then that object is probably rather large, and you ought to be storing pointers (preferably, smart pointers) instead of objects.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Yeah I think I made out like I care more than I actually do. My main concern has always been that rookie programmers use realloc incorrectly.
Sure it might be nice to have realloc available from the standard allocator in C++, but at the same time I think we're just fine without it. Those that do tend to use it are often likely to be prematurely optimising anyway.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
