Bill Baxter wrote:
> Robert Fraser wrote:
>> Bill Baxter Wrote:
>>
>>> Isn't there something we can do about this? I do this about once a
>>> day when in a heavy D using phase. It bites newbies and
>>> not-so-newbies alike. I almost think it should be made so that no
>>> initializer calls the default constructor, and if you really want it
>>> to be null then you should initialize with null:
>>>
>>> Tester fun; // creates a new Tester
>>> Tester nofun = null; // doesn't create anything
>>
>> But then I (coming from a Java background) would be bitten by it about
>> once a day.
>>
>> I think the best way is to make a compiler warning for every local
>> variable that's used before it's explicitly assigned, a la Java
>> (actually, it's an error in Java).
>
> Assuming it applied only to classes in D, that seems like a good idea.
>
> --bb
Probably a good idea.
I hesitated because I sometimes use null as a sentinel value, but null
can be assigned explicitly, so all is good.
I think a worse problem though is how D errors on null dereferencing.
On windows I get Access Violations, and I think the segv is a linux
thing if I remember correctly. Such error messages are completely
unhelpful while debugging. The following should probably be done:
instance.member = something;
becomes
assert(instance !is null,
format("%s,%d: %s is null!",
__FILE__,__LINE__,instance.stringof)
);
instance.member = something;
It would be sort of like how arrays are bounds checked at runtime unless
in release mode.

Bill Baxter escribió:
> Ary Manzana wrote:
>> Bill Baxter escribió:
>>> BCS wrote:
>>>> Reply to convert,
>>>>
>>>>> Hi,
>>>>>
>>>>> I wrote this very simple class, but the call to fun.testIt()
>>>>> segfaults.
>>>>> If I put the function outside of the class it works just fine.
>>>>> What am I missing?
>>>>> I have tried this with dmd v1.015 and the tango dmd v1.018, same
>>>>> thing.
>>>>> Thank you very much.
>>>>>
>>>>> -------------------
>>>>> import std.stdio;
>>>>> class Tester
>>>>> {
>>>>> void testIt() {}
>>>>> }
>>>>> void main()
>>>>> {
>>>>> Tester fun;
>>
>> The compiler should do the following:
>>
>> Since fun wasn't assigned to something, any access to it before an
>> assignment to fun should result in a compiler error.
>>
>>>>> fun.testIt();
>>>>> writefln("I made it!");
>>>>> }
>>>>
>>>> you don't new the Tester
>>>>
>>>>> Tester fun = new Tester();
>>>>
>>>>
>>>
>>> Isn't there something we can do about this? I do this about once a
>>> day when in a heavy D using phase. It bites newbies and
>>> not-so-newbies alike. I almost think it should be made so that no
>>> initializer calls the default constructor, and if you really want it
>>> to be null then you should initialize with null:
>>>
>>> Tester fun; // creates a new Tester
>>> Tester nofun = null; // doesn't create anything
>>>
>>> But then there's all sorts of questions that crop up, like what
>>> should "new Tester[5]" do? Or "Tester m_fun;" as a class/struct member.
>>
>> Any access to Tester[i] before Tester[i] is assigned something should
>> result in a compiler error.
>
> I don't think that's something that could be realistically enforced
> using static analysis. How would you propose implementing that?
Umm... Now that I think of, the first comment I made is doable (Java
does it), but the second... forget it.

Bill Baxter wrote:
> I guess the best we can hope for is some kind of better error message
> than just a generic segfault, or perhaps a compiler warning if you
> forget to initialize a class instance.
Aren't those segfaults the famous "hardware exceptions", that you get
"for free" instead of the compiler having to throw real exceptions ?
Doesn't seem too impossible to discover in the debugger, I'm worried
that having the compiler error on it would trip up some valid code...
gdb says:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00002d81 in D main () at Tester.d:11
11 fun.testIt();
--anders

Chad J wrote:
> I think a worse problem though is how D errors on null dereferencing. On
> windows I get Access Violations, and I think the segv is a linux thing
> if I remember correctly.
Correct. They're called Bus Errors on Mac. "Kärt barn har många namn"*.
--anders
* translated to english: We find many names for those we love

"Chad J" <gamerChad@_spamIsBad_gmail.com> wrote in message
news:f9tu35$1d7q$1@digitalmars.com...
>
> I think a worse problem though is how D errors on null dereferencing. On
> windows I get Access Violations, and I think the segv is a linux thing if
> I remember correctly. Such error messages are completely unhelpful while
> debugging. The following should probably be done:
>
> instance.member = something;
>
> becomes
>
> assert(instance !is null,
> format("%s,%d: %s is null!",
> __FILE__,__LINE__,instance.stringof)
> );
> instance.member = something;
>
> It would be sort of like how arrays are bounds checked at runtime unless
> in release mode.
Was suggested, shot down, forgotten. :\

Jarrett Billingsley wrote:
> "Chad J" <gamerChad@_spamIsBad_gmail.com> wrote in message
> news:f9tu35$1d7q$1@digitalmars.com...
>> I think a worse problem though is how D errors on null dereferencing. On
>> windows I get Access Violations, and I think the segv is a linux thing if
>> I remember correctly. Such error messages are completely unhelpful while
>> debugging. The following should probably be done:
>>
>> instance.member = something;
>>
>> becomes
>>
>> assert(instance !is null,
>> format("%s,%d: %s is null!",
>> __FILE__,__LINE__,instance.stringof)
>> );
>> instance.member = something;
>>
>> It would be sort of like how arrays are bounds checked at runtime unless
>> in release mode.
>
> Was suggested, shot down, forgotten. :\
>
>
grrrr.
This seems like low-lying fruit to me.
Considering the impressive stuff dmd does, I figured this would take
very little effort to accomplish. At the same time, this fix would save
many programmers many hours of time, same as bounds checks. This stuff
has worked me over more than enough times. The ubiquitous crappy
runtime error messages need to go.

* Anders F Björklund <afb@algonet.se> [07-08-15 08:38]:
>Bill Baxter wrote:
>
>>I guess the best we can hope for is some kind of better error message than
>>just a generic segfault, or perhaps a compiler warning if you forget to
>>initialize a class instance.
>
>Aren't those segfaults the famous "hardware exceptions", that you get
>"for free" instead of the compiler having to throw real exceptions ?
On Unix systems, a segmentation fault triggers a SIGSEGV signal, which -
by default - results in program termination. It can be catched, but IIRC
the state of the program is undefined afterwards.