struct MyStruct {
	// stuff
}

void main(string[] args) {
	MyStruct s1 = void;
}

Could anyone describe me what this initialization does, please?
When do I need to use the void initialization?

On Tuesday, 31 March 2015 at 15:12:54 UTC, ref2401 wrote:
> struct MyStruct {
> 	// stuff
> }
>
> void main(string[] args) {
> 	MyStruct s1 = void;
> }
>
> Could anyone describe me what this initialization does, please?
> When do I need to use the void initialization?

By default variables are initialized with default value called 'default initializer'.
i.e default initialize for integer value is 0 (for  more take a look at http://dlang.org/type.html)

initializing to void means 'not initialize to default value'.

On Tuesday, 31 March 2015 at 15:12:54 UTC, ref2401 wrote:
> Could anyone describe me what this initialization does, please?

It skips the initialization entirely, leaving the memory random instead of making it zeroes (or NaN or whatever the .init is of the actual type, typically zero though).

The struct members will thus be random when made with =void. However, it does tell the compiler that you thought about initializing it - you tell it you specifically want it uniniitalized and didn't just forget to write something.

> When do I need to use the void initialization?

Very rarely, don't use it unless you can answer this yourself.

But some possible answers would be:

1) the initialization wasted program runtime; it can be an optimization. Only use it in this case if you are sure it matters (the speed was actually a problem) and if you do initialize it yourself immediately afterward. Otherwise, you might be introducing bugs.

2) you want some kind of random data, like if you are using it to seed a random number. There's often better ways of doing this, but =void might work in some cases.

3) You are initializing a private member with default construction turned off. Here, "Struct s;" wouldn't compile because of the disabled default constructor, but you need to set it up anyway. So you do "Struct s = void; s.values = something;" - void to tell the compiler you know what you're doing, then you quickly initialize it to what it needs to be.  I say in a private member because you'd be bypassing the object's requirements this way, so you are responsibile for making sure the values are indeed valid before using the object.

On Tuesday, 31 March 2015 at 15:23:12 UTC, Adam D. Ruppe wrote:
> 2) you want some kind of random data, like if you are using it to seed a random number. There's often better ways of doing this, but =void might work in some cases.

Like almost never? I can't think of any reason to ever do that.

On Tuesday, 31 March 2015 at 15:59:53 UTC, John Colvin wrote:
> Like almost never? I can't think of any reason to ever do that.

I mentioned it because of this story:

https://www.schneier.com/blog/archives/2008/05/random_number_b.html

I'm sure there's better ways to do it, but since a similar technique was used in a high profile product, I thought I'd mention it as a possible use.

though I'd recommend against trying this at home for anything serious since there's better sources of more random randomness...

On Tuesday, 31 March 2015 at 16:10:07 UTC, Adam D. Ruppe wrote:
> On Tuesday, 31 March 2015 at 15:59:53 UTC, John Colvin wrote:
>> Like almost never? I can't think of any reason to ever do that.
>
> I mentioned it because of this story:
>
> https://www.schneier.com/blog/archives/2008/05/random_number_b.html
>
> I'm sure there's better ways to do it, but since a similar technique was used in a high profile product, I thought I'd mention it as a possible use.
>
> though I'd recommend against trying this at home for anything serious since there's better sources of more random randomness...

In general, I can't think of a worse way of choosing a seed other than a fixed value*. It's actually quite interesting thinking of all the ways it's bad :)

*and even that has it's upsides for repeatability!

On Tue, Mar 31, 2015 at 03:23:11PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote: [...]
> 3) You are initializing a private member with default construction turned off. Here, "Struct s;" wouldn't compile because of the disabled default constructor, but you need to set it up anyway. So you do "Struct s = void; s.values = something;" - void to tell the compiler you know what you're doing, then you quickly initialize it to what it needs to be.  I say in a private member because you'd be bypassing the object's requirements this way, so you are responsibile for making sure the values are indeed valid before using the object.

Ooh, I never thought of this before. Nice!! I'll have to keep this in mind next time I need to store a non-default-constructible object as an aggregate member. Thanks for the tip!


T

-- 
Lawyer: (n.) An innocence-vending machine, the effectiveness of which depends on how much money is inserted.

On 3/31/15 11:23 AM, Adam D. Ruppe wrote:
> On Tuesday, 31 March 2015 at 15:12:54 UTC, ref2401 wrote:
>> Could anyone describe me what this initialization does, please?
>
> It skips the initialization entirely, leaving the memory random instead
> of making it zeroes (or NaN or whatever the .init is of the actual type,
> typically zero though).
>
> The struct members will thus be random when made with =void. However, it
> does tell the compiler that you thought about initializing it - you tell
> it you specifically want it uniniitalized and didn't just forget to
> write something.
>
>> When do I need to use the void initialization?
>
> Very rarely, don't use it unless you can answer this yourself.
>
> But some possible answers would be:
>
> 1) the initialization wasted program runtime; it can be an optimization.
> Only use it in this case if you are sure it matters (the speed was
> actually a problem) and if you do initialize it yourself immediately
> afterward. Otherwise, you might be introducing bugs.
>
> 2) you want some kind of random data, like if you are using it to seed a
> random number. There's often better ways of doing this, but =void might
> work in some cases.

Stack data is almost never random. I'd also substitute "often" for "always".

>
> 3) You are initializing a private member with default construction
> turned off. Here, "Struct s;" wouldn't compile because of the disabled
> default constructor, but you need to set it up anyway. So you do "Struct
> s = void; s.values = something;" - void to tell the compiler you know
> what you're doing, then you quickly initialize it to what it needs to
> be.  I say in a private member because you'd be bypassing the object's
> requirements this way, so you are responsibile for making sure the
> values are indeed valid before using the object.

4) initialization depends on runtime logic, but you want to scope the variable outside those conditionals. For example:

Struct s = void;

if(somecond)
{
   s = option1;
}
else
{
   s = option2;
}

// need to use s out here

Of course, this is a ridiculous example, a real example would be more complex (generally your logic is difficult to rework coupled with other code). This doesn't happen very often, but it is really the only time I have used the =void expression.

-Steve

Thank you.

On Tuesday, 31 March 2015 at 16:24:02 UTC, John Colvin wrote:
> On Tuesday, 31 March 2015 at 16:10:07 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 31 March 2015 at 15:59:53 UTC, John Colvin wrote:
>>> Like almost never? I can't think of any reason to ever do that.
>>
>> I mentioned it because of this story:
>>
>> https://www.schneier.com/blog/archives/2008/05/random_number_b.html
>>
>> I'm sure there's better ways to do it, but since a similar technique was used in a high profile product, I thought I'd mention it as a possible use.
>>
>> though I'd recommend against trying this at home for anything serious since there's better sources of more random randomness...
>
> In general, I can't think of a worse way of choosing a seed other than a fixed value*. It's actually quite interesting thinking of all the ways it's bad :)

More fun than I thought:

Depending on the OS and toolchain, you might be looking at anything in the current process (at best).

That seed might be directly drawn from user data: an attacker could conceivably now choose your seed.

The seed might contain sensitive data: an attacker who can measure the output of the PRNG might be able to work backwards to find the seed, exposing the data.

You might always seed 0, or some other fixed value, or something almost always fixed depending on the program state: heavily biased towards certain values, bad for randomness.

Based on observable state, an observer could conceivably infer or predict the value of the seed and hence predict future values from the PRNG.

and so on...