Hacker News Reader

Comment by pkolaczk | Hacker News Reader

The funny thing is that most of STL gives no realtime guarantees either, even if you use a custom realtime allocator with it. E.g. vector.push_back takes O(n) time sometimes. Running a chain of destructors caused by reference count dropping to 0 can be unpredictable as well.

View on HN

But you can be sure of when those "sometimes" will be with e.g. std::vector::reserve

http://en.cppreference.com/w/cpp/container/vector/reserve

If you want realtime guarantees, you have a lot more unpredictable problems, like CPUs having cache.

Yep, but exactly the same applies to Java. Just preallocate all your objects statically and you're never going to have GC problems :P

If you don't want the occasional O(n) copy on growth, use an stl list with a custom allocator.

reserve can be very easily misused. For example, let's assume a function append_10_items_to_vector. Since we're adding 10 items, we may get a better performance if we call reserve() before 10 push_back()s. Right?

Not always. If we have a loop that calls our append_10_items_to_vector N times (on the same vector), then your reserve() just transformed the loop into O(N^2) code. Without reserve, it would be O(N).

As a rule of thumb, use reserve only if you are really sure that nobody's ever going to add anything more to your vector in the future.

I once had to re-implement the pieces of the STL I wanted in a real-time embedded system, for precisely this reason (well, that plus the fact that STL's use of allocators is broken, and I wanted to be able to allocate from fixed-size pools to avoid non-O(1) trips through an allocator at run-time).

Reply on news.ycombinator.com