"Anders F Björklund" <afb@algonet.se> wrote in message news:dtaf3q$2qlp$1@digitaldaemon.com...
> Then again, it's usually better to catch those bugs at compile time ?
>
> Like in Java: (jikes compiler)
> *** Semantic Error: The variable "sum" may be accessed here before having
> been definitely assigned a value.

"may" be? That's why it isn't in D. Wishy-washy messages aren't a solution. Furthermore, they encourage programmers to introduce dead assignments to get rid of the message, leaving the mysterious assignment to confuse the maintenance programmer trying to figure out what the code does.

Good, clean code should have every statement be reachable, and every assignment mean something. Having the compiler force you to insert meaningless assignments and unreachable code is just not helpful.

Sean Kelly wrote:
> Sean Kelly wrote:
>> John Stoneham wrote:
>>> Walter Bright wrote:
>>>> I've also heard from people who do serious numerical work that, at last, D is a language that cares about numerical analysis and its needs. Default initializing to nan is part of that - it forces the user to *think* about what he wants the initial value to be. Initializing it by default to 0 means that it can easilly be overlooked, and 0.0 can introduce undetected, subtle errors in the result.
>>>>
>>>
>>> I agree. I'm currently working on an involved combinatorial calculation, and having one of the doubles auto-initialized to NAN help me find a bug in one of the calculations which would have been very difficult to find otherwise.
>>>
>>> I say keep it.
>>>
>>>
>>>> There is a 'nan' value for pointers - null, a 'nan' value for UTF-8 chars - 0xFF - which is an illegal UTF-8 character. If there was a 'nan' value for ints, D would use it as the default, too.
>>>>
>>>
>>> There *is* a way get this behavior, and it can be done at compile time: raise an error when an int is assigned an initial value which cannot be calculated at compile time. This behavior could even be turned on with a command-line switch, -nan, or whatever.
>>
>> This would be nice.
> 
> I take it back:
> 
> struct S { int i; }

Actually, does this work?

struct S { int i = 5; }

Not quite a flexible as a ctor, but it would be sufficient for the above suggestion.

Sean

Walter Bright wrote:

>>Like in Java: (jikes compiler)
>>*** Semantic Error: The variable "sum" may be accessed here before having been definitely assigned a value.
> 
> "may" be? That's why it isn't in D. Wishy-washy messages aren't a solution. 

Jikes is always so polite about it, other compilers are more terse:
* javac: "variable sum might not have been initialized"
* gcc: "warning: `sum' might be used uninitialized in this function"

But you are right, as it's leaving the possibility that it is wrong...
(it's an error in Java, and an optional -Wuninitialized warning in GCC)

> Furthermore, they encourage programmers to introduce dead assignments to get rid of the message, leaving the mysterious assignment to confuse the maintenance programmer trying to figure out what the code does.

Yes, sometimes workarounds like that are needed to "silence" GCC...

The warning also only occurs during optimization/register candidates:
http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Warning-Options.html#index-Wuninitialized-214

There's also special attributes and preprocessor tricks to "help" it.

> Good, clean code should have every statement be reachable, and every assignment mean something. Having the compiler force you to insert meaningless assignments and unreachable code is just not helpful. 

You're only "forced" if you want it to compile without warnings, though.

Having it lintfree/warningless takes some initial effort, no doubt about
that. But after that it is usually "effortless", and helps catch bugs...

I know what you think about warnings :-), so it is probably not for D.
(Having Phobos compile with the -w flag takes same about of workarounds)


The only thing that has me confused, is the D overview says that D is for people who like using lint and compile with all warnings as errors.

And activities such as the above "not helpful" ones is what I associate
with those two extra code analysis passes. Maybe I'm stuck in the past ?

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:dtbs2u$15dl$1@digitaldaemon.com...
> The only thing that has me confused, is the D overview says that D is for people who like using lint and compile with all warnings as errors.

No two compilers emit the same warnings. So a general statement about warnings does not mean I consider a particular warning to be worth having. DMC doesn't emit any wishy-washy warnings.

Walter Bright wrote:

> DMC doesn't emit any wishy-washy warnings. 

Haven't used DMC enough, I'm afraid, just GCC...
(something of a side effect from not using Win)

Nothing personal :-)
--anders


PS.
Doing some Windows now, so I will play with it.
(probably not enough to purchase the CD, though)

I support the use of NaN as an initializer. I only wish it could also be done for all numerics.

I work with a language (Euphoria) in which all variables are set to uninitialized and it doesn't allow you to use an uninitialized variable. And it  doesn't have syntax to initialize them at declaration time. This strict enforcement has made me appreciate the importance of explicitly initializing variables to improve readibility and removing potential bugs.

(I just wish Euphoria would allow one to initialize at declaration time though <g>)

-- 
Derek Parnell
Melbourne, Australia

"Derek Parnell" <derek@psych.ward> wrote in message news:op.s5ahr0v26b8z09@ginger.vic.bigpond.net.au...
> I work with a language (Euphoria) in which all variables are set to uninitialized and it doesn't allow you to use an uninitialized variable.

That appears to implement in software my idea that memory should have a parallel set of bits saying whether each location is initialized or not. The trouble with doing it in software is it about halves the execution speed.

Walter Bright wrote:
> "Derek Parnell" <derek@psych.ward> wrote in message news:op.s5ahr0v26b8z09@ginger.vic.bigpond.net.au...
>> I work with a language (Euphoria) in which all variables are set to uninitialized and it doesn't allow you to use an uninitialized variable.
> 
> That appears to implement in software my idea that memory should have a parallel set of bits saying whether each location is initialized or not. The trouble with doing it in software is it about halves the execution speed. 

Could make it an optional/debug feature, but it might be a lot of work for something that a code analyzer could possibly accomplish as well?


Sean

On Mon, 20 Feb 2006 19:39:50 -0800, Walter Bright wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:op.s5ahr0v26b8z09@ginger.vic.bigpond.net.au...
>> I work with a language (Euphoria) in which all variables are set to uninitialized and it doesn't allow you to use an uninitialized variable.
> 
> That appears to implement in software my idea that memory should have a parallel set of bits saying whether each location is initialized or not. The trouble with doing it in software is it about halves the execution speed.

Yes, I know that, and I wasn't suggesting that D adopt this strategy. Euphoria is an interpreter so its not trying to be as fast as a compiled program, and thus the extra management overheads for this facility are not a problem for it. I was just saying that my experience with working with variables that must be explicitly initialized has been beneficial, and so I was attempting to support NaN for floating point, etc...

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
21/02/2006 4:26:11 PM

"Derek Parnell" <derek@psych.ward> wrote in message news:13ffimd0poz2u$.i1ldoex0oqcq$.dlg@40tude.net...
> Yes, I know that, and I wasn't suggesting that D adopt this strategy.
> Euphoria is an interpreter so its not trying to be as fast as a compiled
> program, and thus the extra management overheads for this facility are not
> a problem for it. I was just saying that my experience with working with
> variables that must be explicitly initialized has been beneficial, and so
> I
> was attempting to support NaN for floating point, etc...

Thanks for clarifying this.