However I am thinking here in terms of WG21 standardisation, specifically SG14's work on a std::vector upgrade which doesn't have the really unfortunate unpredictable latency. The general idea is that a low latency std::vector would never expand its capacity automatically, instead it would return success + capacity approaching warning status. You then could schedule the construction of a new, bigger vector outside the hot path.
I find this example as unconvincing as Lawrence's original one. For one, vector functions that grow the size typically return void. So you could just turn that into bool or an enum and you'd be done.
For another, when you're in the hot path, the "capacity warning" status is not actionable, so it's of little use. Instead, when you get out of the hot path (or, better yet, before you get into it), you'd simply check capacity(), see if it's yellow/red, and reserve. Or not even check, just reserve( size() + <hot path max size requirement> ).
All valid observations. Yet SG14 likes anything which relocates latency unpredictable things (exception throws, malloc, etc) to the caller. It's certainly how I'd have personally designed the STL originally. std::vector's latency insensitive design has always irritated me, and I still hope - without much basis - that any STL v2 will fix that. I'm minded to try and deliver SG14 a vocabulary type which can help with that so they can propose it for standardisation. As much as it'll cause problems with the Boost review, it delights SG14 members. I received quite a lot of private email during and after the Outcome v1 review about how from the review feedback on boost-dev it was clear here doesn't understand SG14's needs and priorities. I really wish they'd say that here instead of emailing me privately about it. I already know, it's a difference of mindset and philosophy. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/