D - classinfo.name
- Patrick Down (14/14) May 21 2002 So classinfo.name isn't implemented yet?
- Pavel Minayev (8/20) May 22 2002 See below...
- Patrick Down (5/8) May 22 2002 Yes that the second time that has bitten me. I need a little note
- Russ Lewis (12/20) May 22 2002 Why a warning? An unitialized variable is an ERROR, right? If you
- Walter (4/7) May 22 2002 All variables get initialized in D, an object reference gets initialized...
- Pavel Minayev (6/13) May 22 2002 to
- Patrick Down (8/18) May 22 2002 At least 5 or 6 times now I've failed to initialize an object
- Walter (4/10) May 31 2002 I think the problem is the null pointer exception is being trapped by th...
- Sean L. Palmer (36/50) May 23 2002 I believe the compiler could usually tell if someone wrote bad code like
- Pavel Minayev (7/19) May 23 2002 This is very similar to array bounds check: it is illegal to access
- OddesE (15/37) May 23 2002 be
- Russ Lewis (15/18) May 23 2002 I was thinking about this...what if a plain reference declaration also
- Sandor Hojtsy (17/27) May 23 2002 Indeed. Since you want to allocate 99% of the time, it should be the eas...
- Russ Lewis (19/21) May 24 2002 I thought about this, but then realized that the impact is comparatively
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
"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
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
Patrick Down wrote: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))) ]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
"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
"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...toWhy 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 initializednull.Even those on stack? Then, let's get back to our "let's insert a check for null references" discussion... =)
May 22 2002
"Pavel Minayev" <evilone omen.ru> wrote in news:achp8c$2a36$1 digitaldaemon.com:"Walter" <walter digitalmars.com> wrote in messageAt 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?All variables get initialized in D, an object reference gets initializedtonull.Even those on stack? Then, let's get back to our "let's insert a check for null references" discussion... =)
May 22 2002
"Walter" <walter digitalmars.com> "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
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... =)
May 23 2002
"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
"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...beI 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 shouldtellforbidden by the language. It Can Only Be Bad. If the compiler canI 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 mailyou'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
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
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:3CED24E8.A05A5EB9 deming-os.org...Russ Lewis wrote: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, SandorOn 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.
May 23 2002
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