Den 11-10-2017 kl. 01:05 skrev Louis Dionne via Boost:
Hi Louis,
Did you know Boost.Container has similar constructs? Would you then now not use Boost.Container?
I did not know Boost.Container had similar constructs, and I could not find them in the documentation. Could you please share a link? If it does have them, I certainly hope they were justified properly when they were introduced or when the library was reviewed.
http://www.boost.org/doc/libs/1_65_1/doc/html/boost/container/vector.html
- What is your evaluation of the documentation?
- The design rationale for `devector` at the beginning of the documentation is slightly misleading. `devector` can't be a drop-in replacement for `std::vector`, because of iterator invalidation guarantees of move operations (see https://stackoverflow.com/a/41384937/627587).
Can you explain why ? ... it is not obvious that devector differs in this respect.
With the small buffer optimization, I think moving containers will invalidate iterators.
Sure. But by default the is no small buffer. But the documentation should stress those differences when one starts to use the small buffer or a version of decvetor that supports a small buffer.
- I would really like to see actual benchmarks, even if this needs coming up with more realistic use cases. IMO, it is not acceptable for a library tailored for performance (and having unsafe operations for that purpose) to provide only a listing of assembly at `-O2`.
Some have been posted. What is your take on them?
It seems like the benchmarks (if we're talking about the serialization and deserialization ones) are mostly about the facilities allowing to skip initialization. This is nice, but would it be possible to construct benchmarks that do not use Boost.Serialization for demonstrating the same thing? Doing otherwise opens the door to speedups and slowdowns caused by things unrelated to DoubleEnded itself.
Basically, whenever you encounter double initialization of trivially copyable types, you can avoid it. That's what you save, nothing less, nothing more. I can't understand your last sentence.
Also, my understanding is that these benchmarks only showcase the benefit of not double-initializing containers, but not the actual main purpose of the library, which is to provide double-ended containers. Benchmarks showing why one cares about that (beyond std::vector and std::deque) would be welcome.
Well, if you take devector, I think it's very much pointless to show push_front is faster than vector front insertion. It simply is. If you take batch_deque, it also very much pointless to compare it with std::deque. No fixed segment size can be best for all possible use cases. It cannot. For example, when I work with an A* algorithm for decrete optimization problems, I need one batch_deque with a fairly large segments size. Other programs that have a need for many small deques, would not want a very large segment size. There are some benchmarks done here: http://larshagencpp.github.io/blog/2016/05/22/devector If you walk through the messages in this thread there are benchmarks on batch_deque iteration and unsafe_push_back. Hopefully I will also post one showing random insertion/erase is very good for devector. kind regards -Thorsten