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;
}

"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;
> }

> 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.

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))) ]

"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.

"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
to
> null.

Even those on stack?

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

"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
> to
>> 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?

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
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.
>
> Even those on stack?
>
> Then, let's get back to our "let's insert a check for null references" discussion... =)

"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...

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))) ]