www.digitalmars.com         C & C++   DMDScript  

D - classinfo.name

reply Patrick Down <pat codemoon.com> writes:
So classinfo.name isn't implemented yet?
This program returns blank.

class Foo
{
 int a;
}

int main(char[][] args)
{ 
  Foo a;
  
  printf("%.*s\n",a.classinfo.name);
  
  return 0;
} 
May 21 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns92167B953193patcodemooncom 63.105.9.61...

 So classinfo.name isn't implemented yet?
 This program returns blank.

See below...
 class Foo
 {
  int a;
 }

 int main(char[][] args)
 {
   Foo a;

Didn't you forget something? =) a = new Foo; Don't forget that classinfo is a run-time property, and object must be instantiated for it to be queried. In fact, I wonder why didn't it gave you a GPF.
   printf("%.*s\n",a.classinfo.name);

   return 0;
 }

May 22 2002
parent reply Patrick Down <pat codemoon.com> writes:
 Don't forget that classinfo is a run-time property, and object
 must be instantiated for it to be queried. In fact, I wonder why
 didn't it gave you a GPF.

Yes that the second time that has bitten me. I need a little note that says "Look for uninitialized objects before posting to the list stupid" stuck to the monitor. :-) This will probably be a common problem for C++ programmers moving to D. As much as Walter hates warnings an unititialized variable one would be nice.
May 22 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Patrick Down wrote:

 Don't forget that classinfo is a run-time property, and object
 must be instantiated for it to be queried. In fact, I wonder why
 didn't it gave you a GPF.

Yes that the second time that has bitten me. I need a little note that says "Look for uninitialized objects before posting to the list stupid" stuck to the monitor. :-) This will probably be a common problem for C++ programmers moving to D. As much as Walter hates warnings an unititialized variable one would be nice.

Why a warning? An unitialized variable is an ERROR, right? If you really want to read random unitialized values from memory, write an asm block for it, or write it in C. Why even pretend to support it in D? On another note, maybe there should be 2 syntaxes for declaring class references...and have the "easy" one automatically initialize the variable with a new object? -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
May 22 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CEBC83A.72404177 deming-os.org...
 Why a warning?  An unitialized variable is an ERROR, right?  If you
 really want to read random unitialized values from memory, write an asm
 block for it, or write it in C.  Why even pretend to support it in D?

All variables get initialized in D, an object reference gets initialized to null.
May 22 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:achaei$1s1q$1 digitaldaemon.com...

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CEBC83A.72404177 deming-os.org...
 Why a warning?  An unitialized variable is an ERROR, right?  If you
 really want to read random unitialized values from memory, write an asm
 block for it, or write it in C.  Why even pretend to support it in D?

All variables get initialized in D, an object reference gets initialized

 null.

Even those on stack? Then, let's get back to our "let's insert a check for null references" discussion... =)
May 22 2002
next sibling parent reply Patrick Down <pat codemoon.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in
news:achp8c$2a36$1 digitaldaemon.com: 

 "Walter" <walter digitalmars.com> wrote in message
 All variables get initialized in D, an object reference gets
 initialized 

 null.

Even those on stack? Then, let's get back to our "let's insert a check for null references" discussion... =)

At least 5 or 6 times now I've failed to initialize an object reference and the program hasn't blown up when they are accessed. The defining factor is that it doesn't seem to have any problem reading from address 0. If I pull and equivalent trick with VC++ the program blows up with an "Access Violation" Is the D compiler setting up memory protection attributes differently?
May 22 2002
parent "Walter" <walter digitalmars.com> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns92171EF889patcodemooncom 63.105.9.61...
 At least 5 or 6 times now I've failed to initialize an object
 reference and the program hasn't blown up when they are accessed.
 The defining factor is that it doesn't seem to have any problem
 reading from address 0.  If I pull and equivalent trick with VC++
 the program blows up with an "Access Violation"   Is the D compiler
 setting up memory protection attributes differently?

I think the problem is the null pointer exception is being trapped by the startup code.
May 31 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I believe the compiler could usually tell if someone wrote bad code like
this:

class Foo { int val; }

void Doh()
{
  Foo a;
  a.val = 0;  // Error:  program accesses thru nil reference, which is
forbidden by the language.
}

For this to be considered an error, accesses thru nil references should be
forbidden by the language.  It Can Only Be Bad.  If the compiler can tell
you're doing it, it should wag its finger under your nose.

Of course someone could fool the compiler like so:

import random;

void Doof()
{
  Foo a;
  if (rand()==0)
    a = new Foo;
  a.val = 0;  // No compiler error detected, but program only works one in
65536 tries.
}

You could probably handle this kinda like "missing return values" or
"potentially uninitialized variables", and ensure that in every possible
execution path that leads to a reference, an initialization to the variable
(to something other than nil) must have occurred prior (via the graph).

It'd always be possible to fool the compiler by accessing through a
int/reference union or something.

This would catch so many bugs and such at compile time, Walter.  Would be
very handy.  Compilers could always be lax about enforcing the language
specification, since the standard doesn't say how well it has to enforce the
prohibition against possible nil object accesses.

Sean

"Pavel Minayev" <evilone omen.ru> wrote in message
news:achp8c$2a36$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:achaei$1s1q$1 digitaldaemon.com...

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CEBC83A.72404177 deming-os.org...
 Why a warning?  An unitialized variable is an ERROR, right?  If you
 really want to read random unitialized values from memory, write an



 block for it, or write it in C.  Why even pretend to support it in D?

All variables get initialized in D, an object reference gets initialized

 null.

Even those on stack? Then, let's get back to our "let's insert a check for null references" discussion... =)

May 23 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:aci63l$2nnr$1 digitaldaemon.com...
 I believe the compiler could usually tell if someone wrote bad code like
 this:

 class Foo { int val; }

 void Doh()
 {
   Foo a;
   a.val = 0;  // Error:  program accesses thru nil reference, which is
 forbidden by the language.
 }

 For this to be considered an error, accesses thru nil references should be
 forbidden by the language.  It Can Only Be Bad.  If the compiler can tell
 you're doing it, it should wag its finger under your nose.

This is very similar to array bounds check: it is illegal to access element with index out of bounds, so the compiler checks it at compile-time wherever it can, but it also have an option to turn on run-time checks, for debugging purposes. I think this situation is the same...
May 23 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:acilm2$42j$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:aci63l$2nnr$1 digitaldaemon.com...
 I believe the compiler could usually tell if someone wrote bad code like
 this:

 class Foo { int val; }

 void Doh()
 {
   Foo a;
   a.val = 0;  // Error:  program accesses thru nil reference, which is
 forbidden by the language.
 }

 For this to be considered an error, accesses thru nil references should


 forbidden by the language.  It Can Only Be Bad.  If the compiler can


 you're doing it, it should wag its finger under your nose.

This is very similar to array bounds check: it is illegal to access element with index out of bounds, so the compiler checks it at compile-time wherever it can, but it also have an option to turn on run-time checks, for debugging purposes. I think this situation is the same...

I agree! It would be very handy! How difficult would it be to do such a check where all paths must initialize a newly declared object before it is accessed? -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
May 23 2002
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Russ Lewis wrote:

 On another note, maybe there should be 2 syntaxes for declaring class
 references...and have the "easy" one automatically initialize the
 variable with a new object?

I was thinking about this...what if a plain reference declaration also included an object declaration? MyClass a; // equivalent to MyClass a = new MyClass; MyClass b = otherObject; // doesn't create a new object, of course MyClass c = null; // creates a reference initialized to null...to object created. This, of course, would cause some confusion at first (with people who use the first syntax), but I think that we'd all get used to it quickly. It has the advantage of being a very easy switchover for C++ programmers... -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
May 23 2002
parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CED24E8.A05A5EB9 deming-os.org...
 Russ Lewis wrote:

 On another note, maybe there should be 2 syntaxes for declaring class
 references...and have the "easy" one automatically initialize the
 variable with a new object?

I was thinking about this...what if a plain reference declaration also included an object declaration? MyClass a; // equivalent to MyClass a = new MyClass; MyClass b = otherObject; // doesn't create a new object, of course MyClass c = null; // creates a reference initialized to null...to object created.

Indeed. Since you want to allocate 99% of the time, it should be the easiest way of all. It also removes the Evil Redundancy, but then you will also need: BaseClass a; // equivalent to BaseClass a = new BaseClass; BaseClass b = new Child; // this suggests that you always need to "new" BaseClass c(1, 3); // equivalent to BaseClass a = new BaseClass(1, 3); BaseClass d(otherObject); // equivalent to BaseClass a = new BaseClass(otherObject); copy construct I feel that Java natives will suffer from this, so maybe some syntactic sugar here: new Baseclass a; // equivalent to BaseClass a = new BaseClass; Yours, Sandor
May 23 2002
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Sandor Hojtsy wrote:

 I feel that Java natives will suffer from this, so maybe some syntactic
 sugar here:

I thought about this, but then realized that the impact is comparatively minimal. Consider this code, written by an old Java programmer: MyClass a; a = new MyClass; I would lean toward declaring this to be an "object unused" error. The only problem with that solution is that there might be, occasionally, classes that do something useful in the constructor and the programmer explicitly wanted to create two objects. In that case, I would recommend either that he create reference variables for both objects, or that he move the "active code" out of the constructor and into a member function: MyClass a; a.DoStuff(); a = newMyClass(); -- The Villagers are Online! http://villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
May 24 2002