On Thursday, 29 May 2014 at 10:41:59 UTC, Kagamin wrote:
> On Wednesday, 28 May 2014 at 05:40:26 UTC, Jesse Phillips wrote:
>> When he explained why C++ inferred a const int type as int, he tripped me up because D does drop const for value types.
>
> Hmm, this bit me (doesn't compile):
> void f(in char[] s)
> {
>   auto s1=s;
>   s1=s;
> }

I suppose at this point you know:

    void f(const(char)[] s);

I understanding that expected may not be the same as simple. But you did ask for s1 to be const then tried to modify it.

On Thursday, 29 May 2014 at 11:08:03 UTC, Leandro Lucarella wrote:
> I think void means "you don't know what the
> value is", not "is a random value" or "a value different from the
> default" (which is impossible for stack values, at least if the idea
> behind void is to avoid the extra runtime cost ;).

The language docs state, "If the Initializer is void, however, the variable is not initialized." Which I suspect is false in the case of module scope and as Steven pointed out, other times doing special "don't init" is costly.

On Thu, 29 May 2014 10:20:39 -0400, Jesse Phillips <Jesse.K.Phillips+D@gmail.com> wrote:

> On Thursday, 29 May 2014 at 13:11:52 UTC, Steven Schveighoffer wrote:
>> IIRC, the entire section of global TLS data is initialized, and is all contiguous memory, so it would be anti-performant to initialize all but 4 bytes.
>
>      int x2;
>      float f2;
>
> These are both TLS and they init to different values, I suppose:
>
>      float f2prime = void;
>
> would mean f2prime is 0 and not float.init. Otherwise what you state is kind of what I was expecting.

This is not what I would have expected. But one can test easily enough :)

http://dpaste.dzfl.pl/6619cf538f8e

I find this interesting. I would have expected the TLS initialization to be one giant memcpy. If it is, I find it puzzling that these would be different.

The only logical explanation is that TLS is initialized first with all zeros, and then specific inits are overlaid on types that have inits. Otherwise, what difference does it make if you are blitting 0's or nans?

-Steve

On 5/29/2014 7:28 AM, Jesse Phillips wrote:
> The language docs state, "If the Initializer is void, however, the variable is
> not initialized." Which I suspect is false in the case of module scope and as
> Steven pointed out, other times doing special "don't init" is costly.

The language does not guarantee it is initialized. That doesn't mean it has no value, however. It means its initial value must not be relied upon.

While the current implementations puts them in BSS which is set to 0 before program start, it doesn't have to be done that way. Embedded systems that don't have loaders, for example, may map it onto RAM and that RAM may have whatever garbage in them that appeared when power was applied.

On 5/29/2014 6:11 AM, Steven Schveighoffer wrote:
> struct X
> {
>    int a;
>    int b = void; // also initialized to 0.
> }
>
> This is because X must blit an init for a, and it would be silly to go through
> the trouble of blitting X.init to a, but not b. Especially, for instance, if you
> had an array of X (you'd have to blit every other int!)

But it would not be silly for:

  struct X {
     int a;
     int[100] b = void;
  }

to only initialize X.a. The compiler is allowed to optimize that. And, in fact, I wished for just this in Warp.

On Thu, 29 May 2014 13:12:24 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 5/29/2014 6:11 AM, Steven Schveighoffer wrote:
>> struct X
>> {
>>    int a;
>>    int b = void; // also initialized to 0.
>> }
>>
>> This is because X must blit an init for a, and it would be silly to go through
>> the trouble of blitting X.init to a, but not b. Especially, for instance, if you
>> had an array of X (you'd have to blit every other int!)
>
> But it would not be silly for:
>
>    struct X {
>       int a;
>       int[100] b = void;
>    }
>
> to only initialize X.a. The compiler is allowed to optimize that. And, in fact, I wished for just this in Warp.

I don't disagree. I think the spec should not specify what happens, to leave it open for future optimizations.

Has anyone ever considered making the compiler build an 'optimized' init-blitting function instead of just defaulting to memcpy? In other words, the compiler knows at compile time the layout and initialization values of a struct. What about using the compiler and optimizer to create the most optimized, no-runtime-variables function to blit memory? We wouldn't even need compiler help, if we did it with RTInfo.

-Steve

Jesse Phillips, el 29 de May a las 14:28 me escribiste:
> On Thursday, 29 May 2014 at 11:08:03 UTC, Leandro Lucarella wrote:
> >I think void means "you don't know what the
> >value is", not "is a random value" or "a value different from the
> >default" (which is impossible for stack values, at least if the
> >idea
> >behind void is to avoid the extra runtime cost ;).
> 
> The language docs state, "If the Initializer is void, however, the variable is not initialized." Which I suspect is false in the case of module scope and as Steven pointed out, other times doing special "don't init" is costly.

The thing is, you cannot not initialize a variable while writing the binary file to disk, you have to write something. Is not like with the stack that you can increase a pointer and leave the memory as is.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
We are born naked, wet and hungry
Then things get worse

On 5/29/2014 10:54 AM, Steven Schveighoffer wrote:
> Has anyone ever considered making the compiler build an 'optimized'
> init-blitting function instead of just defaulting to memcpy? In other words, the
> compiler knows at compile time the layout and initialization values of a struct.
> What about using the compiler and optimizer to create the most optimized,
> no-runtime-variables function to blit memory? We wouldn't even need compiler
> help, if we did it with RTInfo.

I have, but obviously I haven't done anything about it.

On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu wrote:
> http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/
>
> https://news.ycombinator.com/newest (search that page, if not found click "More" and search again)
>
> https://www.facebook.com/dlang.org/posts/855022447844771
>
> https://twitter.com/D_Programming/status/471330026168651777
>
>
> Andrei

YouTube mirror : http://youtu.be/48kP_Ssg2eY

On 5/29/2014 9:14 AM, Steven Schveighoffer wrote:
> On Thu, 29 May 2014 04:57:14 -0400, Alix Pexton
> <alix.DOT.pexton@gmail.dot.com> wrote:
>>
>> I couldn't resist looking up this debate, and its quite a fiery one
>> with no clear winner! There is no clear origin to the phrase and equal
>> arguments for and against both forms.
>
> If you think I'll let it go you're mad, you got another thing comin'
>

Heh, I see I'm not the only one who's has that playing in their head through this whole conversation ;)

Oddly enough, my mind plays it as the Pat Boone cover (from "In a Metal Mood"). His version is surprisingly good.