![[de]](/mwf/flags/de.png "Germany")
I dunno if this is a real bug or if I just missed something in the proplist/array development. So I'm posting it here:This is my testing script and the result. What happens:
- An object (CableCrossing #236) searches for another one of its kind (found #237), calling Getfoo() to get the array 'foobar', saving it in 'arraybar'
- Then #236 adds a value to arraybar
- After this it calls Logfoo in #237 to log the value of foobar
-> foobar changed together with arraybar
Is this the intended behaviour of arrays? And if so, what do I have to do to get a copy of foobar to which I can make changes with no effect on foobar itself?
This is a consequence of the "noref" changes. Arrays now behave like objects. It's a difficult tradeoff, and we (Peter and me) originally decided to do it the other way, but I think the resulting complexity in the engine and the surprising performance characteristics weren't worth it. You effectively couldn't know when an array would be copied behind the scenes by the script interpreter without being familiar with the implementation, and nobody is familiar with the old implementation without having worked on it at most a few weeks ago. Of course one could pretend that an array was copied every time it got passed from one place to another, but then a loop like for(i = 0; i < GetLength(a); ++i) foo(a[i]) would copy the array GetLength(a) times, so you'd have to cache the length. (CR either uses a reference parameter for GetLength to avoid the copy or the copy-on-write efforts barely manage to avoid the copy in this simple example. They're supposed to, but I would have to test to know for sure....) I think having to manually copy arrays requires less effort from scripters.
![[cr]](/mwf/flags/cr.png "Costa Rica")
Hmm, better the complexity is in the engine than in C4Script.
This is not really more a question of definition rather than complexity, because we already have both value (int, string, etc.) and handle-types (objects and definitions).If you're coming from C, you're used to an array-pointer-equivalence. But then, you'd expect the same for strings.
Virtually every imperative language has the same array semantics. Especially scripting languages like Python, Javascript, Lua, etc. C++ might be the only popular language with something similar to the CR arrays: std::vector. Though I don't think std::vector typically has a copy-on-write mechanism, I've heard that some std::string implementations have.
Interestingly, std::string implementations that do copy-on-write violate the standard, which requires O(1) time for std::string::operator[]. And conversely, COW for std::vector would be perfectly fine, because vector element access only needs to run in amortized O(1) time.
The overall complexity should be kept low, though, and a slight increase in script complexity is worth a big decrease in engine complexity.Also, often a complex piece of code is better implemented in a language without pointer arithmetic and garbage collection.
>he surprising performance characteristics
Did anyone actually ever benchmarked that change? :)
Not the array change alone. But that's kinda the point: Before, you had to profile to know whether your array code was doing excessive copies, now you can see the copies in the script. Sure, in order to improve the speed you still need to measure, but once the measurement blames a function, you can look at the function and have a good chance of guessing what it is that's slow in it.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
