RE: [Freepooma-devel] UninitializedVector implementation

[William Humphrey]

Hello Richard,

 

UninitializedVector was put in to avoid having the constructors for domain objects be executed when an array of those objects was created.  Originally, when first written, the domain objects just used

 

T[Dim]

 

for their storage, where T was the type of the 1D domain class (so you'd have an array of, say, Range<1> objects when you created a Range<3> object).  But I would see (I think even in optimized code using the compilers at that time, around 1998 or so if I recall) the constructors for the Range<1> objects be run when the array was allocated.  It was a waste, because immediately afterward the code would set the value for each array element to the desired values.  At the time, I was obsessed with getting domain-object initialization down to the absolute bare minimum of execution steps, damn the code-complexity cost, thus UninitializedVector.

 

The reason StorageT is different, and not just T, is that the use-case is for situations where T is a complex type with a defined constructor, like Range<1>, and StorageT is a simple type that is the equivalent of what T stores internally (it is int[3] for a Range<1>, for example).  UninitializedVector stores the array using the more-basic-type that does not trigger constructors to be executed; later you initialize those elements directly using placement-new, and the reinterpret_cast<>.  So the net result is that a Range<3> object stores its data in an UninitializedVector<Range<1>, 3, int[3]> object.  It's over-engineered, I won't argue about that, but it solved the problem at the time.  I suspect more recent optimizers would be able to handle just using Range<1>[3] as the storage type about equally efficiently.

 

- Bill Humphrey

 

-----Original Message-----
From: Richard Guenther [mailto:address@hidden]
Sent: Friday, November 19, 2004 8:42 AM
To: address@hidden
Subject: [Freepooma-devel] UninitializedVector implementation

Hi!

Does anyone remember why UninitializedVector<T, Dim, StorageT>
uses the third template parameter as type for the storage
(which is then reinterpret_cast<>ed to T on access) and not
simply uses an array of  T[Dim]  here?  It looks like the current
implementation may inhibit proper aliasing analysis by the compiler.

UninitializedVector<> is exclusively used by the domain classes
at the moment.

Thanks,
Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

_______________________________________________
Freepooma-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/freepooma-devel