.idup flawed?

Xinok xnknet at gmail.com
Thu Jun 21 17:48:34 PDT 2007


I'm thinking this flaw can be fixed, but it requires creating copies of 
everything in the array, and not just the single dimension. This means 
if you have a multi-dimensional array, you'd have to duplicate all the 
dimensions in that array. If you have an array of classes, you'll also 
have to create copies of all the classes.

Pointers aren't an easy fix. The only way to do these is to slice them, 
then idup.

int* ptr;
ptr[0..10].idup;

Classes can be copied, but it will require the class to have a copy 
constructor.

class N{ this(N other){ } }

If the class contains pointer types, it shouldn't matter if the copy 
constructor is written properly.

Last, if the array type has any invariant data, it shouldn't be 
important to copy that.

invariant(int)[] arr = [15, 30, 45];
arr.idup; // Invariant data does not need to be copied since it's 
already invariant

Walter Bright wrote:
> Xinok wrote:
>> .idup creates an invariant copy of an array. According to this page:
>> http://digitalmars.com/d/const.html
>>
>> "One is that constant data really is constant. It never changes. It's 
>> different enough that it needs a different name. In D, this kind of 
>> constant is called an invariant."
>>
>>
>> So if you have an invariant array, you expect that it's data will 
>> never change.
>>
>> This is not always the case if you have an array of classes. Classes 
>> are pointers, and when you use the .idup property, it only creates 
>> invariant copies of the pointers, and not the objects themselves. This 
>> means that the objects are still mutable and the data can change, 
>> which is not the intended behavior of invariant.
> 
> I think you might have found a fatal flaw in .idup. Aggh!



More information about the Digitalmars-d mailing list