www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - initial values

reply "Ben Hinkle" <bhinkle mathworks.com> writes:
Let me bring up an old chestnut topic: default initial values.

My beef with the current treatment of initial values is that some initial 
values (like integer and pointer types) are very convenient and some are 
very inconvenient (like char and floating point types). Walter has stated 
that if there existed an inconvenient integer or pointer value he would use 
that (I hope I remembered that correctly). But in practice the convenience 
of the initial values can be crucial. I almost never see code that 
explicitly initializes integers to 0 or pointers to null. For example the 
word count example at the bottom of the associative array example uses the 
statement dictionary[word]++; to both insert the word in the array if it 
wasn't present and increment its word count. I noticed that statement when 
thinking about the associative array indexing behavior but I'd like to use 
it now as an example of how people (including Walter himself) use initial 
values for their convenience. D is harder to use when some types have 
convenient intial values and some don't. Let's aim for consistency and just 
make all initial values convenient. Does anyone know of another language 
that has nan as the default floating point value? While I'm at it the char 
types initial values should IMO go back to 0, too.

As an aside, if you allocate an array of double[] or char[] the array is 
initially filled with 0's.

-Ben
Mar 16 2005
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 As an aside, if you allocate an array of double[] or char[] the array is 
 initially filled with 0's.


I can see it now.

"DMD 0.119 release!  Bugs fixed: double[] and char[] arrays are now 
initialized to nan and 0xffff, respectively."

;)
Mar 16 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:d1a507$22h8$1 digitaldaemon.com...

 As an aside, if you allocate an array of double[] or char[] the array is 
 initially filled with 0's.


 I can see it now.

 "DMD 0.119 release!  Bugs fixed: double[] and char[] arrays are now 
 initialized to nan and 0xffff, respectively."


actually that is a bug in dmd since the spec says dynamic arrays are filled 
with the default value when resized.
Mar 16 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


"DMD 0.119 release!  Bugs fixed: double[] and char[] arrays are now 
initialized to nan and 0xffff, respectively."


 
 actually that is a bug in dmd since the spec says dynamic arrays are filled 
 with the default value when resized. 


There is a similar bug with the autocreated value of missing AA keys...

I guess just uses calloc, and "forgets" to set the proper .init values?

--anders
Mar 16 2005
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:d1a5mt$235t$1 digitaldaemon.com...

 actually that is a bug in dmd since the spec says dynamic arrays are 
 filled with the default value when resized.


Oh.

..
Mar 16 2005
prev sibling parent reply "Craig Black" <cblack ara.com> writes:
 actually that is a bug in dmd since the spec says dynamic arrays are 
 filled with the default value when resized.


I don't know if I like the idea of needlessly initializing large arrays to 
unusable values.  Wouldn't this have a significant adverse effect on 
performance?  Perhaps this could be a compiler option.

-Craig
Mar 17 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Craig Black wrote:


actually that is a bug in dmd since the spec says dynamic arrays are 
filled with the default value when resized.


 
 I don't know if I like the idea of needlessly initializing large arrays to 
 unusable values.  Wouldn't this have a significant adverse effect on 
 performance?  Perhaps this could be a compiler option.


At least allocating them as "zero" would be both fast and usable... ?

I think the arrays are right, and that the .init values need changing.

--anders
Mar 17 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


 My beef with the current treatment of initial values is that some initial 
 values (like integer and pointer types) are very convenient and some are 
 very inconvenient (like char and floating point types). Walter has stated 
 that if there existed an inconvenient integer or pointer value he would use 
 that (I hope I remembered that correctly).


http://www.digitalmars.com/d/function.html says:

 Local Variables
 It is an error to use a local variable without first assigning it a
 value. The implementation may not always be able to detect these cases.
 Other language compilers sometimes issue a warning for this, but since
 it is always a bug, it should be an error.


Note that this only talks about local variables. Class fields are always
initialized to the .init values (arrays *should* be, but it is buggy...)


It sounds a bit strange that the default values of all such fields,
that are being automatically initialized, should be as inconvenient
as possible ? (for local vars, it would make sense since those are
illegal anyway and might as well have such "sentinel" default values)

Not to give Walter any ideas, but -1 is a pretty inconvenient value...
Imagine if all integers and pointers started with that default! Ouch.
It would make more sense to give all types convenient values instead ?
(i.e. make them *all* zero, as in: 0 or 0.0 or false or null or '\0')


That is: change characters and floats, instead of integers and pointers?
(but this has probably *also* been beaten to death already, on this NG?)



 Does anyone know of another language 
 that has nan as the default floating point value?


No, but D floating point support aims to be... different. :-)
(just take a look at x!<>=y, which I haven't seen elsewhere?)


 While I'm at it the char 
 types initial values should IMO go back to 0, too.


That would make D closer to what I am used to, too:


Let's just hope this does not end up making the default value
for integers and pointers unusable too... That would be sad...

Like when the default string points to 0xDEADBEEF and is -1 long :-P

--anders
Mar 17 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d1c7ch$157m$1 digitaldaemon.com...

 Ben Hinkle wrote:


 My beef with the current treatment of initial values is that some initial 
 values (like integer and pointer types) are very convenient and some are 
 very inconvenient (like char and floating point types). Walter has stated 
 that if there existed an inconvenient integer or pointer value he would 
 use that (I hope I remembered that correctly).


 http://www.digitalmars.com/d/function.html says:

 Local Variables
 It is an error to use a local variable without first assigning it a
 value. The implementation may not always be able to detect these cases.
 Other language compilers sometimes issue a warning for this, but since
 it is always a bug, it should be an error.




Wow - it also says unused variables are an error. Is the doc out of date? 
DMD doesn't complain if I use an implicitly-initialize variable or declare 
an unsed variable. Not even a warning. If the doc is right I urge Walter to 
fix the compiler to enforce the error so that we have time to update our 
code. Given a choice I prefer the current compiler behavior - allow people 
to use defaults and be sloppy with declarations (though perhaps warn). If 
there is a strong reason for it (eg, it enables better optimizations, etc) 
then erroring is fine.


 Note that this only talks about local variables. Class fields are always
 initialized to the .init values (arrays *should* be, but it is buggy...)

 It sounds a bit strange that the default values of all such fields,
 that are being automatically initialized, should be as inconvenient
 as possible ? (for local vars, it would make sense since those are
 illegal anyway and might as well have such "sentinel" default values)

 Not to give Walter any ideas, but -1 is a pretty inconvenient value...
 Imagine if all integers and pointers started with that default! Ouch.
 It would make more sense to give all types convenient values instead ?
 (i.e. make them *all* zero, as in: 0 or 0.0 or false or null or '\0')


agreed.


 That is: change characters and floats, instead of integers and pointers?
 (but this has probably *also* been beaten to death already, on this NG?)


yeah - but it's been a while :-)


 Does anyone know of another language that has nan as the default floating 
 point value?


 No, but D floating point support aims to be... different. :-)
 (just take a look at x!<>=y, which I haven't seen elsewhere?)


But at least that is additional behavior that other languages don't have. 
One can safely ignore those extra features. Default values exist in other 
languages and it gets annoying that D's are different.


 While I'm at it the char types initial values should IMO go back to 0, 
 too.


 That would make D closer to what I am used to, too:



That's what I have in mind, too.


 Let's just hope this does not end up making the default value
 for integers and pointers unusable too... That would be sad...


All I'm asking for is consistency - either all unusable or all usable. With 
a preference for making them usable.


 Like when the default string points to 0xDEADBEEF and is -1 long :-P


hehe.
Mar 17 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


 Wow - it also says unused variables are an error. Is the doc out of date?


You must be new here :-) (just kidding, but a lot of D docs are old...?)


That is: change characters and floats, instead of integers and pointers?
(but this has probably *also* been beaten to death already, on this NG?)


 
 yeah - but it's been a while :-)


As in "we haven't had a good fight in a while". Or as in it has changed?


 All I'm asking for is consistency - either all unusable or all usable. With 
 a preference for making them usable.


Consistency seems to be a big deal lately :-) Not sure we're getting it.

--anders
Mar 17 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <d1cb3k$19ic$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Ben Hinkle wrote:


 Wow - it also says unused variables are an error. Is the doc out of date?


You must be new here :-) (just kidding, but a lot of D docs are old...?)


heh. you're right - I shouldn't have been surprised.


That is: change characters and floats, instead of integers and pointers?
(but this has probably *also* been beaten to death already, on this NG?)


 
 yeah - but it's been a while :-)


As in "we haven't had a good fight in a while". Or as in it has changed?


As in "it has been a while since it was last discussed and given the people
reading the list have changed and Walter is winding down on 1.0 it would be
worth revisiting to make sure the right thing happens". If all that happens is
the doc is fixed and the compiler bugs are fixed with dynamic arrays then that
would be better than nothing.


 All I'm asking for is consistency - either all unusable or all usable. With 
 a preference for making them usable.


Consistency seems to be a big deal lately :-) Not sure we're getting it.


Please don't lump this in with length, if that is what you mean. :-P
The two are unrelated - mostly w.r.t the scope of the issue. The $length and
friends were about a consitent syntax for some pretty different concepts - some
of which already existed in C and some not. That makes life much more
complicated. Consistency within a single concept (default values) feels to me
like a different argument than the length consistency argument.
Mar 17 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


All I'm asking for is consistency - either all unusable or all usable. With 
a preference for making them usable.


Consistency seems to be a big deal lately :-) Not sure we're getting it.


 
 Please don't lump this in with length, if that is what you mean. :-P


Well, there's been several "lacks of consistancy" over my time here.


The latest one was _arguments versus __FILE__, that is correct...

Then there was "bit" versus "true" and "false" (which *still* sucks)
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11757

And there was the lack of std.stdio.readf and std.string.unformat.

Plus the lack of a "isnot", even though === was replaced with "is" ?
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/14705

How bitfields are now totally lame, but how bit arrays rules the world.

...

Little things like that. Some of them petty, some of them disturbing...
Obviously I like D a lot, or I wouldn't bother with these trivialities.

But me too hopes the .init values can be changed into more convenient.
And that the definition of void main can be settled, once and for all.

--anders
Mar 17 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <d1cijj$1i10$2 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

And there was the lack of std.stdio.readf and std.string.unformat.


I wrote a version of this ages ago.  I haven't tested it since perhaps release
96, but it's available here:

http://home.f4.ca/sean/d/stdio.zip

I never submitted it to Walter because I was waiting for typeinfo to improve for
pointers so I could tune it a bit first.  It also needs some testing with wide
characters, since putback may potentially have to put back up to 4 bytes at the
end of the read process.


Sean
Mar 17 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Sean Kelly wrote:


And there was the lack of std.stdio.readf and std.string.unformat.


 
 I wrote a version of this ages ago.  I haven't tested it since perhaps release
 96, but it's available here:
 
 http://home.f4.ca/sean/d/stdio.zip
 
 I never submitted it to Walter because I was waiting for typeinfo to improve
for
 pointers so I could tune it a bit first.  It also needs some testing with wide
 characters, since putback may potentially have to put back up to 4 bytes at the
 end of the read process.


I actually just updated this, that was why I mentioned it.
See my other post, titled "readf and unformat (updated)" ?

It's working great, but TypeInfo is broken - especially on GDC...
The workaround you used only works on "_arguments", not on copies.

I renamed your "sreadf" as std.string.unformat instead,
and changed the definitions of getc/ungetc to use EOF...

--anders
Mar 17 2005