This little program gives me an "Error: Access Violation" on Windows, v1.042:

import std.random: rand;
void main() {
    auto a = new uint[10_000_000];
    for (int i = 0; i < a.length; i++)
        a[i] = rand();
    a.sort;
    a.sort;
}

Can someone confirm this?

Bye,
bearophile

Even just:

void main() {
    auto a = new uint[10_000_000];
    a.sort;
    a.sort;
}

Bye,
bearophile

bearophile wrote:
> Even just:
> 
> void main() {
>     auto a = new uint[10_000_000];
>     a.sort;
>     a.sort;
> }
> 
> Bye,
> bearophile

Confirmed. In fact, any size below 0x8F_FFFF works,
and any size >= 0x8F_FFFF fails. On DMD2.027 as well.

void main() {
    auto a = new uint[0x8F_FFFF]; // smallest size that fails
    a.sort;
    a.sort;
}

Don wrote:
> bearophile wrote:
>> Even just:
>>
>> void main() {
>>     auto a = new uint[10_000_000];
>>     a.sort;
>>     a.sort;
>> }
>>
>> Bye,
>> bearophile
> 
> Confirmed. In fact, any size below 0x8F_FFFF works,
> and any size >= 0x8F_FFFF fails. On DMD2.027 as well.
> 
> void main() {
>     auto a = new uint[0x8F_FFFF]; // smallest size that fails
>     a.sort;
>     a.sort;
> }
And it's caused by the hard-coded
  byte*[40] stack;              // stack

in
extern (C) long _adSort(Array a, TypeInfo ti)
in qsort.d.

Smaller version, one sort is enough to cause the error:

void main() {
  auto a = new uint[0x8F_FFFF]; // smallest size that fails
  a.sort;
}

I like the idea of having a built-in sort, but I think it's now better to remove it, and move it into the std lib, so:
- It can be replaced/improved/debugged in a simpler way.
- It can be more flexible (for example mine accepts an optional "key" mapping function)
- It can be a template, so it can be faster (confirmed. I have a sort that is sometimes 3+ times faster).
- The overall size and complexity of the language can be a bit lower.
- The usage syntax can be almost the same anyway: arr.sort()

Bye,
bearophile

bearophile wrote:
<snip>
> - It can be more flexible (for example mine accepts an optional "key" mapping function)

What is there preventing a built-in sort being implemented to do this?

> - It can be a template, so it can be faster (confirmed. I have a sort that is sometimes 3+ times faster).
<snip>

What is there preventing a built-in sort being implemented in this way?

Stewart

Stewart Gordon wrote:
> bearophile wrote:
> <snip>
>> - It can be more flexible (for example mine accepts an optional "key" mapping function)
> 
> What is there preventing a built-in sort being implemented to do this?

It's more difficult than doing it in a library. For apparently no benefit at all.

> 
>> - It can be a template, so it can be faster (confirmed. I have a sort that is sometimes 3+ times faster).
> <snip>
> 
> What is there preventing a built-in sort being implemented in this way?
> 
> Stewart

Stewart Gordon:
> > - It can be a template, so it can be faster (confirmed. I have a sort that is sometimes 3+ times faster).
> What is there preventing a built-in sort being implemented in this way?

Can you use templates with a statically compiled std lib?

Bye,
bearophile

On Tue, Apr 7, 2009 at 7:08 PM, bearophile <bearophileHUGS@lycos.com> wrote:
> Stewart Gordon:
>> > - It can be a template, so it can be faster (confirmed. I have a sort that is sometimes 3+ times faster).
>> What is there preventing a built-in sort being implemented in this way?
>
> Can you use templates with a statically compiled std lib?

The template would have to be in the "headers."  It wouldn't be compiled into the library file itself.

The other problem with a templated sort is that while it's faster than the current built-in sort, it also means there would be a different template instantiation for every element type.  Not ideal.

Jarrett Billingsley:
> The other problem with a templated sort is that while it's faster than the current built-in sort, it also means there would be a different template instantiation for every element type.  Not ideal.

So far it was not a problem for me.

Bye,
bearophile