www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Best Practices: Default initializers for structs

reply Jonathan M Davis <jmdavisProg gmx.com> writes:
Here's an interesting thought. All built-in types in D default initialize to
the 
closest thing that they have to an error. Floating points arguably do the best 
job of this with NAN, and integral types arguably the worst with 0, but that
is, 
as I understand it, the basic idea: default initializations initialize to an 
error value (or as close to one as you can get). That way, it quickly becomes 
obvious when you failed to properly initialize one before using it. So, the 
question is this: what about structs?

Structs default initialize to whatever their member variables are directly 
initialized to. That may or may not be an error state, but I don't get the 
impression that people generally _try_ and make it an error state. What should 
be the best practice on this? Should we generally _try_ and make struct 
initializers initialize to error states, just like the primitive types do -
with 
the idea that you really are supposed to initialize them or assign to them 
before you use them. Or should we treat structs differently and try and make 
their default states something other than an error state?

By no means am I claiming that we should _always_ try and make a struct's init 
property an error or _always_ make it valid (that's going to depend on what 
exactly the struct is for and what it does), but which would be the best 
practice in the general case?

- Jonathan M Davis
Nov 06 2010
parent reply d'oh <homer simpsons.name> writes:
On 07/11/10 15:28, Jonathan M Davis wrote:
 Here's an interesting thought. All built-in types in D default initialize to
the
 closest thing that they have to an error. Floating points arguably do the best
 job of this with NAN, and integral types arguably the worst with 0, but that
is,
 as I understand it, the basic idea: default initializations initialize to an
 error value (or as close to one as you can get). That way, it quickly becomes
 obvious when you failed to properly initialize one before using it. So, the
 question is this: what about structs?

 Structs default initialize to whatever their member variables are directly
 initialized to. That may or may not be an error state, but I don't get the
 impression that people generally _try_ and make it an error state. What should
 be the best practice on this? Should we generally _try_ and make struct
 initializers initialize to error states, just like the primitive types do -
with
 the idea that you really are supposed to initialize them or assign to them
 before you use them. Or should we treat structs differently and try and make
 their default states something other than an error state?

 By no means am I claiming that we should _always_ try and make a struct's init
 property an error or _always_ make it valid (that's going to depend on what
 exactly the struct is for and what it does), but which would be the best
 practice in the general case?

 - Jonathan M Davis
Arguable floating points would do better with -Infinity and integral types with a negative value e.g. -1, -2 or as negative as possible. I suspect booleans would do better with true (this being the furtherest away from false .. that if is false is taken to be the origin of the boolean value axis). Zero for an INIT value for integral types doesn't make sense for an "error" value in terms of least frequency of encounter. All-in-all, and for fast fail, the one simple rule that is easy to remember would be "all bits set" and that's all folks. I leave this as an exercise for the reader to speculate on what all-bits-set might manifest as at runtime for uninitialized pointers, in particular re null pointer exceptions. Remember Occam's Razor
Nov 07 2010
parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
d'oh <homer simpsons.name> wrote:

 Arguable floating points would do better with -Infinity
Why? A signaling nan tells you 'you'trying to use an uninitialized value!'.
 and integral types with a negative value e.g. -1, -2 or as negative as  
 possible.
Why? I can see some reasons, like foo * -1 yields a negative answer, while foo * 0 yields 0, which is a fairly common value. Still what are your reasons for saying it's the best?
 I suspect booleans would do better with true (this being the furtherest
 away from false .. that if is false is taken to be the origin of the
 boolean value axis).
And if true is taken to be the origin, then false would be the best? -- Simen
Nov 07 2010