Re: [eigen] portable reallocation...

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/2/26 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> On Fri, Feb 26, 2010 at 12:48 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> Since this will only be used by Eigen, specifically by
>> conservativeResize, your portable realloc wrapper doesn't have to have
>> the standard realloc API where only the new size is passed. You can
>> instead write your own realloc-like function that also takes the old
>> size as an argument.
>
> Yes, I tried that. After implementing this, I stumbled over something
> rather strange which we might want to discuss. :)
>
> When creating new memory we do
>
> template<typename T, bool Align> inline T*
> ei_conditional_aligned_new(size_t size)
> {
>  T *result = reinterpret_cast<T*>(ei_conditional_aligned_malloc<Align>(sizeof(T)*size));
>  return ei_construct_elements_of_array(result, size);
> }
>
> For integral types the compiler seems to be able to remove
> 'ei_construct_elements_of_array' but as soon as we try to allocate
> e.g. std::complex arrays or user types T, the memory will be filled
> with 'size' times 'new T()' -- why? Why do we initialize memory for
> non integral types? I thought we agreed upon uninitialized matrix
> creation!?

We agreed to not initialized by zero.

But we still have to call default constructors for each entry of the
array. For example, imagine that the user is using Eigen with some
multiple-precision numbers class as the Scalar type. Such a class
would probably have a default constructor allocating some memory or at
least initializing some pointers, even if it doesn't initialize
anything by zero!

So we are calling T() on each coefficient, but we're not initializing
by zero (or initializing to any particular value at all).

Then, if for some type T, T() initializes by zero, that's not our
fault, it's the design choice of type T. At least that's not the case
for int,float,double  (ints are not special in this respect). I don't
know about std::complex but if they do initialize by zero then that's
their own choice, not our fault.

>
> Just try
>
> VectorXcd m(50);
> std::cout << m << std::endl;
>
> it will be all zeros - and not uninitialized objects.

It's all zeros indeed, but that doesn't mean that they were
initialized to zero. For example, I tried with VectorXi and I got
zeros too: that means that the memory there happened to be filled with
zeros.

Benoit

>
> Maybe somebody has an idea?
>
> - Hauke
>
>
>