May 09, 2004
I can't run any D program which involves classes, even something trivial like this:

class Tester {
int val;
}

int main(char[][] args) {
Tester t;
t.val = 1;
return 0;
}

I get is a segmentation fault (I'm running Debian Unstable, DMD ver. 0.88). If I
replace class with struct, it runs without a SEGV. Haven't been able to actually
try any of the samples which include classes, as they are Windows-specific. My
GCC is: gcc (GCC) 3.3.3 (Debian 20040429)

Any hints?

Regards,
Greg


May 09, 2004
On Sun, 09 May 2004 21:15:22 +0000, blackfire wrote:

> I can't run any D program which involves classes, even something trivial like
> this:
> <SNIP>

Class variables are always references in D. You need to instantiate t. Try:

int main(char[][] args) {
Tester t = new Tester;
t.val = 1;
return 0;
}

Mike Swieton
__
I've developed a new philosophy. I only dread one day at a time.
	- Charlie Brown

May 09, 2004
On Sun, 09 May 2004 17:22:33 -0400, Mike Swieton <mike@swieton.net> wrote:
> On Sun, 09 May 2004 21:15:22 +0000, blackfire wrote:
>
>> I can't run any D program which involves classes, even something trivial like
>> this:
>> <SNIP>
>
> Class variables are always references in D. You need to instantiate t.

In that case, IMO this should have generated a compile error, preferrably saying exactly this:

"Class variables are always references in D. You need to instantiate t."

If that is possible?

> Try:
>
> int main(char[][] args) {
> Tester t = new Tester;
> t.val = 1;
> return 0;
> }
>
> Mike Swieton
> __
> I've developed a new philosophy. I only dread one day at a time.
> 	- Charlie Brown
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 09, 2004
On Mon, 10 May 2004 10:01:53 +1200, Regan Heath wrote:
>> Class variables are always references in D. You need to instantiate t.
> 
> In that case, IMO this should have generated a compile error, preferrably saying exactly this:
> 
> "Class variables are always references in D. You need to instantiate t."
> 
> If that is possible?
> 

I don't believe that this is a good idea, because it means you can't declare a reference without instantiating it. A better idea would be (which I expect to come eventually) to cause an error on "XX hasn't been initialized".

Mike Swieton
__
Flight by machines heavier than air is unpractical and insignificant, if not
utterly impossible.
	- Simon Newcomb; 1902 - 18 months before Kitty Hawk

May 09, 2004
On Sun, 09 May 2004 18:37:54 -0400, Mike Swieton <mike@swieton.net> wrote:
> On Mon, 10 May 2004 10:01:53 +1200, Regan Heath wrote:
>>> Class variables are always references in D. You need to instantiate t.
>>
>> In that case, IMO this should have generated a compile error, preferrably
>> saying exactly this:
>>
>> "Class variables are always references in D. You need to instantiate t."
>>
>> If that is possible?
>>
>
> I don't believe that this is a good idea, because it means you can't declare a reference without instantiating it. A better idea would be (which I expect to come eventually) to cause an error on "XX hasn't been initialized".

Of course.. where is my brain this morning!

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 10, 2004
blackfire@o2.pl wrote:

>I can't run any D program which involves classes, even something trivial like
>this:
>
>class Tester {
>int val;
>}
>
>int main(char[][] args) {
>Tester t;
>t.val = 1;
>return 0;
>}
>
>I get is a segmentation fault (I'm running Debian Unstable, DMD ver. 0.88). If I
>replace class with struct, it runs without a SEGV. Haven't been able to actually
>try any of the samples which include classes, as they are Windows-specific. My
>GCC is: gcc (GCC) 3.3.3 (Debian 20040429)
>
>Any hints?
>
>Regards,
>Greg
>
>
>  
>
See http://www.prowiki.org/wiki4d/wiki.cgi?ErrorMessages for other common mistakes C++ programmers make in D.

-- 
-Anderson: http://badmama.com.au/~anderson/
May 10, 2004
Mike Swieton wrote:

> On Mon, 10 May 2004 10:01:53 +1200, Regan Heath wrote:
> 
>>>Class variables are always references in D. You need to instantiate t.
>>
>>In that case, IMO this should have generated a compile error, preferrably saying exactly this:
>>
>>"Class variables are always references in D. You need to instantiate t."
>>
>>If that is possible?
> 
> I don't believe that this is a good idea, because it means you can't declare a
> reference without instantiating it.

Not quite.  If the compiler throws an error, it would be trying to catch a runtime error before it happens.  Actually, I can see a case for object references having no default initialisation (hence being an error anyway) when declared as function-local.

> A better idea would be (which I expect to
> come eventually) to cause an error on "XX hasn't been initialized".
<snip>

Or even subsequently been nullified.

Yes, we could do with runtime checking for nulls.  See
http://www.digitalmars.com/drn-bin/wwwnews?D/26693

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.
May 10, 2004
>> Class variables are always references in D. You need to instantiate t.
>
>In that case, IMO this should have generated a compile error, preferrably saying exactly this:
>
>"Class variables are always references in D. You need to instantiate t."
>
>If that is possible?
>

Actually, doesn anyone know if this have thrown an Exception rather than causing
a segfault?  (something like "Foo.d (13) Null reference exception.")

- Eric


May 11, 2004
"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:c7o5vi$2vdl$1@digitaldaemon.com...
> Yes, we could do with runtime checking for nulls.  See http://www.digitalmars.com/drn-bin/wwwnews?D/26693

I hate to say it, but the hardware does that for you. That's what a seg fault is! (The old 8086 CPUs and msdos would drive you crazy because they didn't seg fault on an invalid address, they'd just scribble all over the interrupt table.) If you run the program under a debugger, it'll tell you what line (instruction) caused the fault. If there's any remaining question, a quick look at the register contents will make it pretty obvious that a null dereference is or is not the problem.

Hardware generated exceptions are pretty cool because:

1) they do not cost you any runtime performance or code bloat, i.e. they
come for free
2) they are always on
3) they can be caught in catch blocks like other exceptions
4) pinpointing where they happen is one of the few things debuggers are good
at

Hardware exceptions are so useful that back in the old days I'd develop msdos programs by first writing and debugging them on a system that did hardware exceptions, and only after that was perfect would I even try to run it under msdos.

Having a software exception for the sole purpose of avoiding a hardware exception is counterproductive because of how well the hardware ones work and all the tools that are available that integrate well with them. Such a software check would have been pretty useful, however, back in the DOS days!


Top | Discussion index | About this forum | D home