Re: [boost] Submission: Fixed-Capacity STL Containers Library

From: Synge Todo (wistaria_at_[hidden])
Date: 2002-02-05 17:55:18

Dear Darin and Andrei,

Thank you for your important suggestions.

From: Darin Adler <darin_at_[hidden]>
Date: Tue, 05 Feb 2002 10:49:56 -0800
> On 2/5/02 10:24 AM, "Synge Todo" <wistaria_at_[hidden]> wrote:
> 
> Darin:
> >>> I think that we should look into fixed_capacity_vector implementations
> >>> that  don't behave this way; for one thing, it would make them more
> >>> compatible with vector, and for another, it would make them more efficient.
> 
> > I should confess that I've never thought about that.  I have no idea
> > if it's possible to implement it in such a way without using dynamic
> > allocation.
> 
> It's possible; the main challenge is finding a way to portably declare a
> member that's an array of the right amount of suitably-aligned raw memory.
> 
> Andrei:
> >> I agree. The fixed-capacity vector should allocate raw memory, not T[N]. The
> >> current implementation would be suitable for PODs only.

So, what you suggested is replacing T elems_[N] by
char array_[sizeof(T)*N + max_padding] ?  Is this correct understanding?

I have not yet read Andrei's paper, but I think one possibility to
caluculate a proper value of max_padding at the compile time is using
a helper class like

  template<class T>
  struct alignment_helper {
    struct pad { T x; char y; T z; };
    static const std::size_t alignment = sizeof(pad) - 2 * sizeof(T);
    static const std::size_t max_padding = alignment - 1;
  };

and calculating T* elems_ in the constructor as

  elems_ = (T*)(alignment * (((std::size_t)array_ + max_padding) / alignment);

Is it a correct direction to proceed?  Or, is it too naive?

Synge Todo
wistaria_at_[hidden]