View Issue Details

IDProjectCategoryView StatusLast Update
0000224LDMud 3.3Efunspublic2011-02-23 22:22
ReporterlarsAssigned Tozesstra  
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Target Version3.3.720Fixed in Version3.3.720 
Summary0000224: sort() should be able to sort in-place
DescriptionShort: sort_array(&arr) sorts in-place
From: Freaky
Date: 000405
Type: Feature
State: New

While sort_array(arr) sorts a copy of the array, sort_array(&arr)
might sort the arr in place. This would allow the wizard to chose
whatever is best.
TagsNo tags attached.

Relationships

related to 0000694 resolvedGnomi LDMud 3.5 sort() should accept protected ranges (&(a[3..5]) as first argument 

Activities

zesstra

2009-09-30 16:21

administrator   ~0001383

I don't know the details the implemenation of sort(). But if that implicitly has to create a copy of the array (new array, which it populates instead of exchaning entries), then there is no sorting in place. Does anybody know without reading the code? ;-)

Gnomi

2009-10-01 00:22

manager   ~0001385

Internally our sort algorithm sorts in-place, but it creates a copy of the array first, so that the original array is not modified. So this feature request is not a big deal.

zesstra

2009-10-06 11:45

administrator   ~0001498

Mhmm. v_sort_array() makes only a copy of arrays which have more than one reference.
But these arrays with more than one ref are the interesting case. If we change them, that might produce very interesting and by no means obvious bugs. I am not sure we can assume that every caller knows, with whom he may share an array.

Gnomi

2009-10-07 00:29

manager   ~0001507

I don't think, that is a problem. When doing a[1]=10 you either know who you are sharing the array with or you don't care. Nevertheless you change the array a for everybody who has a reference to it. A sort_array(&a) would only do the same.

zesstra

2009-10-22 14:36

administrator   ~0001547

I committed a patch for the reference support in r2776 and r2777.
Does anybody think it necessary to support protected ranges? E.g. sort_array(&(arr[3..5]),...)?

Gnomi

2009-10-24 04:18

manager   ~0001549

Yes, I think that protected ranges should be supported. &(arr[3..5]) should behave similar to &arr in LPC. But I don't know whether this should be done in 3.3 or 3.5 (I can do that in the lvalue branch in 3.5).

zesstra

2009-10-24 04:30

administrator   ~0001550

Ok, then I would suggest to do it there. After your rework of the lvalues the code will have to be changed anyway and actually, I don't think it is the most important thing to support it now, although it is more consistent.
The details about the protected lvalues are still a bit fuzzy to me, but I think, we would have to move the definition of struct protected_range_lvalue from interpret.c to interpret.h, because we have to get index1,index2 from the protector struct. Anyway, you have more knowledge about the details there.

zesstra

2009-10-25 09:17

administrator   ~0001551

With the protected ranges separated into 0000694, which is dependent of Gnomis lvalue work, I will close this one, makes a better changelog for 3.3.720. ;-)

Issue History

Date Modified Username Field Change
2004-11-26 22:28 lars New Issue
2009-09-30 16:21 zesstra Note Added: 0001383
2009-10-01 00:22 Gnomi Note Added: 0001385
2009-10-06 11:45 zesstra Note Added: 0001498
2009-10-07 00:29 Gnomi Note Added: 0001507
2009-10-22 12:45 zesstra Status new => assigned
2009-10-22 12:45 zesstra Assigned To => zesstra
2009-10-22 14:36 zesstra Note Added: 0001547
2009-10-24 04:18 Gnomi Note Added: 0001549
2009-10-24 04:30 zesstra Note Added: 0001550
2009-10-24 04:55 zesstra Relationship added related to 0000694
2009-10-25 09:15 zesstra Project LDMud => LDMud 3.3
2009-10-25 09:17 zesstra Note Added: 0001551
2009-10-25 09:17 zesstra Status assigned => resolved
2009-10-25 09:17 zesstra Fixed in Version => 3.3.720
2009-10-25 09:17 zesstra Resolution open => fixed
2011-02-23 22:22 zesstra Target Version => 3.3.720