Nathan Ridge wrote:
And sometimes is less efficient. For instance, if you are populating from StaticVector from list iterators (or any non-random access iterators), it's an O(n) check ahead of time or a complicated wrapper around a one-at-a-time insert. (Note: this is a bug in the current implementation of StaticVector, as its iterator constructor currently requires random access iterators).
I assume I want to simply check the distance between two random access iterators and return immediately if the size is too big. Then, if it isn't random access I should just start copying and check if I've run out of space on each element that is added. Is this correct?
Basically, yes. You may also want to have a version for forward iterators - if you're allowed to traverse the range more than once, then it is usually more efficient to traverse it once to find out the length, throw (or whatever) if the length is too big, and otherwise traverse it a second time to actually insert the elements. (This is not always more efficient - for example, if your iterators are transform_iterators, and the transformation function they are calling is expensive, it's not - but I believe several STL implementations assume it is and do it this way).
Why would you optimize the failure case? _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.