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 <dirk.lau...@gmail.com>: 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 ~~~