View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000224 | LDMud 3.3 | Efuns | public | 2004-11-26 23:28 | 2011-02-23 23:22 |
| Reporter | Assigned To | zesstra | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Target Version | 3.3.720 | Fixed in Version | 3.3.720 | ||
| Summary | 0000224: sort() should be able to sort in-place | ||||
| Description | Short: 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. | ||||
| Tags | No tags attached. | ||||
|
|
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? ;-) |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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]),...)? |
|
|
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). |
|
|
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. |
|
|
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. ;-) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-26 23:28 |
|
New Issue | |
| 2009-09-30 18:21 | zesstra | Note Added: 0001383 | |
| 2009-10-01 02:22 | Gnomi | Note Added: 0001385 | |
| 2009-10-06 13:45 | zesstra | Note Added: 0001498 | |
| 2009-10-07 02:29 | Gnomi | Note Added: 0001507 | |
| 2009-10-22 14:45 | zesstra | Status | new => assigned |
| 2009-10-22 14:45 | zesstra | Assigned To | => zesstra |
| 2009-10-22 16:36 | zesstra | Note Added: 0001547 | |
| 2009-10-24 06:18 | Gnomi | Note Added: 0001549 | |
| 2009-10-24 06:30 | zesstra | Note Added: 0001550 | |
| 2009-10-24 06:55 | zesstra | Relationship added | related to 0000694 |
| 2009-10-25 10:15 | zesstra | Project | LDMud => LDMud 3.3 |
| 2009-10-25 10:17 | zesstra | Note Added: 0001551 | |
| 2009-10-25 10:17 | zesstra | Status | assigned => resolved |
| 2009-10-25 10:17 | zesstra | Fixed in Version | => 3.3.720 |
| 2009-10-25 10:17 | zesstra | Resolution | open => fixed |
| 2011-02-23 23:22 | zesstra | Target Version | => 3.3.720 |
