🚀 go-pugleaf

Distribution:
In article <...>, kanze@gabi-soft.fr (J. Kanze) wrote:

> Cay S. Horstmann (horstman@jupiter.SJSU.EDU) wrote:
> 
> |> I did have this problem [determining whether a type is built-in or
> |> not] when trying to write a decent array template.
> |> For numeric and pointer types, I'd like to use memmove when the array
> |> grows and is relocated. For class types that cannot be done in
> |> general. I did "solve" the problem by having two templates, but now
> |> the risk is that someone who doesn't understand the distinction uses
> |> the "BuiltinTypeArray" (not its real name) with a class type, which
> |> might have bizarre results. So I think Brett's desire is not totally
> |> outlandish.  
> 
> At least for your problem, I would just write the loop and forget it.
> 

In my experience it has been beneficial to distinguish not between types
which can be shuffled around via memmove and those which cannot, but between
types which should be created with default constructors and those which
should only be created in the array with placement new.

For types which have constructors and destructors, it's usually quicker to
manage the storage for the array as an array of characters, with elements
managed by placement new and explicit destruction. For types which do not
have constructors and destructors, it's quicker to manage the array storage
directly as an array of objects of that type.

In both cases, I've found that assignment via a loop was quicker than
assignment via memmove.

The clever part is to construct the array templates so that for any type
you can just write MyArray<T> and based on info you have elsewhere provided
about T, an appropriate implementation is chosen at compile time. Through a
couple of iterations of my implementation, I've also managed to factor out
~80% of the implementation of the array into a type-independent base class.

-- 
Scott Howlett
Storm Software, Inc.
howlett@netcom.com

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]