Re: [Bug-apl] Unexpected cell type change to CT_BASE

[Juergen Sauermann]

Hi Dirk,

probably the same as in your previous example.

The FloatScalar object might be destructed before the second printout.
Try:

Value_P a = FloatScalar(3.141592653589793,LOC);

A Value_P is a pointer, so it is as efficient as a const Value &.
 
const Value & are safe but only as long as the Value object exists.

That means you can safely pass a const Value & to a function but not safely return it from a function (if the Value object is destructed
before returning). In contrast, A Value_P  can safely be passed and returned from a function.

In your example below the float value is destructed almost immediately after construction because taking a Value &
of it does not prevent destruction. On the other hand copying a Value_P to a (as in my example) does prevent destruction
because of the second Value_P (i.e. a) pointing to the same float value (that is the magic of shared pointers)

/// Jürgen

On 02/23/2015 09:38 AM, Dirk Laurie wrote:

2015-02-22 21:48 GMT+02:00 Dirk Laurie <address@hidden>:

The folllowing program pinpoints what I do not understand about
the use of Value and Value_P.

I am beginning to think it may be a bug. Here is a minimal example
of the phenomenon that causes it.

~~~
#include <iostream>
using namespace std;

#include <Value.icc>

main() {
   const Value& a = FloatScalar(3.141592653589793,LOC).getref();
   cerr << "a[0] cell type = " << a.get_ravel(0).get_cell_type() << endl;
   Value_P ret(a.get_shape(), LOC);
   cerr << "a[0] cell type = " << a.get_ravel(0).get_cell_type() << endl;
}
~~~

Output:

~~~
a[0] cell type = 32
a[0] cell type = 1
~~~