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


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

"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

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

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