Here's another failing case:
///////
var i = 2;
proc otst[V,T with ContiguousArrayObject[T,V], Str[T]] (x:T, v1:V, v2:V,
s:string)
{
println$ "Len array = " + x.len.str;
println$ s;
x.stl_begin + i <- v1;
println$ x . i;
x.stl_begin + (i - 1) <- v2;
println x;
println "";
}
otst[int]$ varray(1,2,3,4),42, 53, "varray";
//////////////
Len array = 4
varray
42
varray(1, 53, 42, 4)
////////////////
Now, this used to work until I switched the tests to --inline=5.
But then I got this:
//////////
Len array = 4
darray
3
varray(1, 2, 3, 4)
/////////////
In other words the array modification isn't "taking".
Why?
Well ..
proc otst[V,T with ContiguousArrayObject[T,V], Str[T]] (var x:T, v1:V, v2:V,
s:string)
works. Note the "var x".
I checked the C++. For some weird reason, with lower levels of inlining,
this managed to inline the varray constructor, but not with higher levels.
So actually we're doing this:
varray(1,2,34).stl_begin + i <- v1;
which of course modifies a temporary.
With x as a var parameter eager evaluation is forced.
Still it's a bit surprising because a varray is just a plain old pointer.
So the array is "passed by reference" even if you use value semantics.
The real problem here is that stl_begin was a allowed on a value.
There's also a core point: object like enities (even is abstracted as
with varray) should have their constructors as generators
to ensure eager evaluation.
Of course that wouldn't fix, say, some other functional operation
such as adding two varrays.
Note Felix string = C++ string has the same problem.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
