Walter Bright wrote:
> Lots of meat and potatoes here, and a cookie! (spelling checker for error messages)
> 
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.057.zip
> 
> 
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.041.zip
> 
> Thanks to the many people who contributed to this update!


Bug 1914 Array initialisation from const array yields memory trample

was fixed, in D2 only. Can we get this into D1 as well?

To show what a huge difference this bug makes, try this test case for large values of N:

Executable size in bytes

N       D2.040   D2.041
---    -------   ------
10      266 Kb   241 Kb
100     306 Kb   241 Kb
2000  16151 Kb   257 Kb
10K  <locks up>  321 Kb
---------
enum : int { N = 1000 }

struct S {
    const float[N] BIGINIT = [7];
    float a[N] = BIGINIT;
}

void main() {}

bearophile wrote:
> Andrei Alexandrescu:
>> 	$(LI std.conv: changed the default array formatting from "[a, b, c]" to "a b c")
> 
> That's a regression!!!
> (And I think in the past it was [a,b,c] instead of [a, b, c], because it's better to save some screen space, it costs a lot!).

Sorry, this stays. The idea behind the change is to make 'to' a minimalistic function that makes minimum assumptions (e.g. the comma may be a decimal point in some languages, so is [1,2] in a German locale an array of double with one value or two? etc.

The canonical "to" prints values separated by one space. Why one space? It's the most neutral thing I could think of. Why no brackets? Because of minimalism. You can very easy add them if you want them.


Andrei

If you compile a program like this:

double[100_000] arr;
void main() {}

With dmd you produce a binary about 1 MB in size, because doubles in D are not filled with zero.

So for n-D arrays bigger than a certain amount of memory, can DMD compile that code with a zero initialization plus filling of the Nans at run-time?

Note: this produces the same very large binary, I don't know why:

double[100_000] arr = void;
static this() {
    arr[] = typeof(arr[0]).init;
}
void main() {}


While this hangs my compiler, I don't know why:

double[100_000] arr = 0.0;
static this() {
    arr[] = typeof(arr[0]).init;
}
void main() {}

Bye,
bearophile

On Mon, 08 Mar 2010 14:27:36 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> bearophile wrote:
>> Andrei Alexandrescu:
>>> 	$(LI std.conv: changed the default array formatting from "[a, b, c]" to "a b c")
>>  That's a regression!!!
>> (And I think in the past it was [a,b,c] instead of [a, b, c], because it's better to save some screen space, it costs a lot!).
>
> Sorry, this stays. The idea behind the change is to make 'to' a minimalistic function that makes minimum assumptions (e.g. the comma may be a decimal point in some languages, so is [1,2] in a German locale an array of double with one value or two? etc.
>
> The canonical "to" prints values separated by one space. Why one space? It's the most neutral thing I could think of. Why no brackets? Because of minimalism. You can very easy add them if you want them.

What about an array of strings with spaces in them?  Or an array of arrays?  Is there at least a way to force 'to' to format the way you want?

I tend to side with bearophile on this one...

-Steve

Andrei Alexandrescu:

> Sorry, this stays.

Then I'm not going to use the Phobos printing in all my future D2 programs. As I was not using it in D1. I'm not going to change idea on this.


>(e.g. the comma may be a decimal point in some languages, so is [1,2] in a German locale an array of double with one value or two?<

In German you need no space after the comma, and there's no [] after and before it. So [1, 2] is not a floating point value in German.


>Why one space?<

Because that's they way people print things in natural languages. It's a convention, you know. And it's a good one. It tells apart the FP numbers and it's the minimal.


>It's the most neutral thing I could think of. Why no brackets? Because of minimalism. You can very easy add them if you want them.<

The purpose of things like the square brackets is to give a less ambiguous textual representation of the most common data structures (array and strings are the most common after numbers). So you put "" or '' around strings and [] to know what you are printing.

Steven Schveighoffer wrote:
> On Mon, 08 Mar 2010 14:27:36 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> bearophile wrote:
>>> Andrei Alexandrescu:
>>>>     $(LI std.conv: changed the default array formatting from "[a, b, c]" to "a b c")
>>>  That's a regression!!!
>>> (And I think in the past it was [a,b,c] instead of [a, b, c], because it's better to save some screen space, it costs a lot!).
>>
>> Sorry, this stays. The idea behind the change is to make 'to' a minimalistic function that makes minimum assumptions (e.g. the comma may be a decimal point in some languages, so is [1,2] in a German locale an array of double with one value or two? etc.
>>
>> The canonical "to" prints values separated by one space. Why one space? It's the most neutral thing I could think of. Why no brackets? Because of minimalism. You can very easy add them if you want them.
> 
> What about an array of strings with spaces in them?  Or an array of arrays?  Is there at least a way to force 'to' to format the way you want?

Yes, you may specify the separator.

Andrei

bearophile wrote:
> Andrei Alexandrescu:
> 
>> Sorry, this stays.
> 
> Then I'm not going to use the Phobos printing in all my future D2
> programs. As I was not using it in D1. I'm not going to change idea
> on this.
> 
> 
>> (e.g. the comma may be a decimal point in some languages, so is
>> [1,2] in a German locale an array of double with one value or two?<
>> 
> 
> In German you need no space after the comma, and there's no [] after
> and before it. So [1, 2] is not a floating point value in German.
> 
> 
>> Why one space?<
> 
> Because that's they way people print things in natural languages.
> It's a convention, you know. And it's a good one. It tells apart the
> FP numbers and it's the minimal.
> 
> 
>> It's the most neutral thing I could think of. Why no brackets?
>> Because of minimalism. You can very easy add them if you want
>> them.<
> 
> The purpose of things like the square brackets is to give a less
> ambiguous textual representation of the most common data structures
> (array and strings are the most common after numbers). So you put ""
> or '' around strings and [] to know what you are printing.

Your choice of leading/trailing symbols and of separators makes 'to' friendlier for printing e.g. debug strings. My choice makes it a primitive for text serialization. I'm not 100% sure which is the more frequent use and therefore which is the most appropriate as a default, but I'm leaning towards the latter.

Andrei

Steven Schveighoffer wrote:
> On Mon, 08 Mar 2010 14:27:36 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> bearophile wrote:
>>> Andrei Alexandrescu:
>>>>     $(LI std.conv: changed the default array formatting from "[a, b, c]" to "a b c")
>>>  That's a regression!!!
>>> (And I think in the past it was [a,b,c] instead of [a, b, c], because it's better to save some screen space, it costs a lot!).
>>
>> Sorry, this stays. The idea behind the change is to make 'to' a minimalistic function that makes minimum assumptions (e.g. the comma may be a decimal point in some languages, so is [1,2] in a German locale an array of double with one value or two? etc.
>>
>> The canonical "to" prints values separated by one space. Why one space? It's the most neutral thing I could think of. Why no brackets? Because of minimalism. You can very easy add them if you want them.
> 
> What about an array of strings with spaces in them?  Or an array of arrays?  Is there at least a way to force 'to' to format the way you want?

auto s = to!string([1,2,3], "[", ", ", "]");

-Lars

On Mon, 08 Mar 2010 14:49:33 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> bearophile wrote:
>> Andrei Alexandrescu:
>>
>>> Sorry, this stays.
>>  Then I'm not going to use the Phobos printing in all my future D2
>> programs. As I was not using it in D1. I'm not going to change idea
>> on this.
>>
>>> (e.g. the comma may be a decimal point in some languages, so is
>>> [1,2] in a German locale an array of double with one value or two?<
>>>
>>  In German you need no space after the comma, and there's no [] after
>> and before it. So [1, 2] is not a floating point value in German.
>>
>>> Why one space?<
>>  Because that's they way people print things in natural languages.
>> It's a convention, you know. And it's a good one. It tells apart the
>> FP numbers and it's the minimal.
>>
>>> It's the most neutral thing I could think of. Why no brackets?
>>> Because of minimalism. You can very easy add them if you want
>>> them.<
>>  The purpose of things like the square brackets is to give a less
>> ambiguous textual representation of the most common data structures
>> (array and strings are the most common after numbers). So you put ""
>> or '' around strings and [] to know what you are printing.
>
> Your choice of leading/trailing symbols and of separators makes 'to' friendlier for printing e.g. debug strings. My choice makes it a primitive for text serialization. I'm not 100% sure which is the more frequent use and therefore which is the most appropriate as a default, but I'm leaning towards the latter.

No it doesn't.

Tell me how you would parse the following text serialization string for a string[]:

hello world how are you

What if it was a string[][]?

Compare that to:

[hello world, [how are, you]]

That is almost completely unambiguous (you still have to account for literal commas or brackets), whereas you have a multitude of choices with the first version.

The thing is, friendlier for text-based serialization is almost identical to friendlier for printing.  In fact, friendlier for text-based serialization should have even more annotations to escape delimiters.

In fact, I find the defaults you defined not useful in most cases.  Printing or serializing, I want to see the delimiters for the arrays, elements, and subarrays.

-Steve

bearophile wrote:
> While this hangs my compiler, I don't know why:
> 
> double[100_000] arr = 0.0;
> static this() {
>     arr[] = typeof(arr[0]).init;
> }
> void main() {}

Well, it didn't hang, it just took a while. I found the problem.