digitalmars.D.learn - struct variable initialized with void.
- ref2401 (8/8) Mar 31 2015 struct MyStruct {
- Lukasz Wrzosek (6/14) Mar 31 2015 By default variables are initialized with default value called
- Adam D. Ruppe (27/29) Mar 31 2015 It skips the initialization entirely, leaving the memory random
- John Colvin (2/5) Mar 31 2015 Like almost never? I can't think of any reason to ever do that.
- Adam D. Ruppe (8/9) Mar 31 2015 I mentioned it because of this story:
- John Colvin (5/15) Mar 31 2015 In general, I can't think of a worse way of choosing a seed other
- John Colvin (16/35) Apr 01 2015 More fun than I thought:
- H. S. Teoh via Digitalmars-d-learn (8/16) Mar 31 2015 Ooh, I never thought of this before. Nice!! I'll have to keep this in
- Steven Schveighoffer (19/46) Mar 31 2015 4) initialization depends on runtime logic, but you want to scope the
- ref2401 (1/1) Mar 31 2015 Thank you.
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?
Mar 31 2015
"Lukasz Wrzosek" <wrzoski gmail.com>
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'.
Mar 31 2015
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.
Mar 31 2015
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.
Mar 31 2015
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...
Mar 31 2015
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: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!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...
Mar 31 2015
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: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...On Tuesday, 31 March 2015 at 15:59:53 UTC, John Colvin wrote: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 :)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...
Apr 01 2015
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.
Mar 31 2015
On 3/31/15 11:23 AM, Adam D. Ruppe wrote:On Tuesday, 31 March 2015 at 15:12:54 UTC, ref2401 wrote:Stack data is almost never random. I'd also substitute "often" for "always".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.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
Mar 31 2015