Re: [Boost-bugs] [Boost C++ Libraries] #9165: small buffer optimization for vector or new container

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #9165: small buffer optimization for vector or new container
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-09-27 08:19:48

#9165: small buffer optimization for vector or new container
-------------------------------+--------------------------
  Reporter:  gast128@…         |      Owner:  igaztanaga
      Type:  Feature Requests  |     Status:  assigned
 Milestone:  To Be Determined  |  Component:  container
   Version:  Boost 1.54.0      |   Severity:  Optimization
Resolution:                    |   Keywords:
-------------------------------+--------------------------
Changes (by igaztanaga):

 * status:  new => assigned

Comment:

 This is an interesting feature that was in the Boost.Container to-do list
 for a long time. Note that LLVM SmallVector<T, N> is also more flexible
 than allowing small buffer optimization, as it can be converted to a base
 SmallVectorImpl<T> class that is independent from N, allowing capacity-
 independent code:

 http://llvm.org/docs/ProgrammersManual.html#llvm-adt-smallvector-h



 {{{#!c++
 // BAD: Clients cannot pass e.g. SmallVector<Foo, 4>.
 hardcodedSmallSize(SmallVector<Foo, 2> &Out);
 // GOOD: Clients can pass any SmallVector<Foo, N>.
 allowsAnySmallSize(SmallVectorImpl<Foo> &Out);

 void someFunc() {
   SmallVector<Foo, 8> Vec;
   hardcodedSmallSize(Vec); // Error.
   allowsAnySmallSize(Vec); // Works.
 }
 }}}

 Small buffer optimization can be achieved (without LLVM capacity-
 independent Impl class), allowing extended allocator requirements.
 Currently the STL says for allocator.requirements that:

 {{{#!c++
 //Shall not exit via an exception.
 X a1(a);
 //post: a1 == a
 }}}

 For SBO allocators (allocators holding an internal buffer) that would no
 longer be true, so boost::container::vector could support this extended
 allocators. We'd need to see how this affects to exception safety (swap
 could throw for throwing copy/move constructors) and it might require
 extending boost::container::allocator_traits and how vector behaves in
 copy/move constructor and assignments (¿should this SBO allocator be
 propagated?).

 If this is successful, SBO could be applied to any Boost.Container
 container.

 Implementing LLVM-like capacity-independent features is much tougher, as
 it might require a really big surgery or writing new classes from the
 scratch.

 I'll start exploring extended allocator requirements for Boost 1.56 or
 1.57. Thanks for the ticket and the links.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/9165#comment:1>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.