www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Need help with D compiler!

reply blackfire o2.pl writes:
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
next sibling parent reply Mike Swieton <mike swieton.net> writes:
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
parent reply Regan Heath <regan netwin.co.nz> writes:
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
next sibling parent reply Mike Swieton <mike swieton.net> writes:
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
next sibling parent Regan Heath <regan netwin.co.nz> writes:
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 09 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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
parent "Walter" <newshound digitalmars.com> writes:
"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!
May 11 2004
prev sibling parent Eric Anderton <ericanderton at yahoo dot com> <Eric_member pathlink.com> writes:
 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 10 2004
prev sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
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 09 2004