hi
i am using try catch mechanism to check validity of pointers

i have some class called X and i matrying to exe. this
class X{
public;
    bool valid();
};


{
X *x= new X;
delete x;
try{
    if(x->Valid()){...}
    cout<<"i have reached here(Problem)";
}
catch(...){
    cout<<"Trying to access invalid object";
}
}

i want something like if x is deleted it should raise exception. i cann't assign NULL after deleting that object, that object will be having some value, it may be valid or invalid but surlly not NULL

pls if possible tell me other workout solution or bug in this code

Deleting an object doesn't necessarilly set its contents to any arbitrary values that might cause an exception if accessed.

-Walter

"Neo" <newneo2@yahoo.com> wrote in message news:as21fj$27v0$1@digitaldaemon.com...
> hi
> i am using try catch mechanism to check validity of pointers
>
> i have some class called X and i matrying to exe. this
> class X{
> public;
>     bool valid();
> };
>
>
> {
> X *x= new X;
> delete x;
> try{
>     if(x->Valid()){...}
>     cout<<"i have reached here(Problem)";
> }
> catch(...){
>     cout<<"Trying to access invalid object";
> }
> }
>
> i want something like if x is deleted it should raise exception. i cann't assign NULL after deleting that object, that object will be having some value, it may be valid or invalid but surlly not NULL
>
> pls if possible tell me other workout solution or bug in this code
>
>
>
>

One solution:

class X
{
  bool deleted_;
public:
  X() : deleted_(false) {}
  virtual ~X() { deleted_ = true; }
  bool valid() {
    if (deleted_) throw WhateverGoodNameYouCanThinkOf();
    return true; }
};

You can even derive from X (multiple inheritance might result from here), and you need to make sure that every method is calling the X::valid() - not good, if other people can derive from your classes, since this is not enforced by compiler, as with constructors/destructors.

Second solution:

In C++ User's Journal, a few months ago, it was a very interesting article "Debugging Memory Leaks".  The idea will change a little bit in your case: you'll still use a custom memory allocator (you still need page granularity for memory protection to work), but you set the memory access to PAGE_NO_ACCESS (or whatever it's called in Win32 API), in the destructor.  It's a beautiful solution, work even with STL-derived classes, and everything!  The advantage is that the existing code doesn't need to be modified, and any access to a deleted object will trigger a processor exception, easy to catch with the debugger, and then you just have to go up in the stack trace, to find the bad guy.

Third solution, probably best:

Rethink your object lifetime design.

HTH,
  Laurentiu

P.S.  I would be very interested to hear about other possible solutions to this particular problem.


Neo wrote:
> hi
> i am using try catch mechanism to check validity of pointers
> 
> i have some class called X and i matrying to exe. this
> class X{
> public;
>     bool valid();
> };
> 
> 
> {
> X *x= new X;
> delete x;
> try{
>     if(x->Valid()){...}
>     cout<<"i have reached here(Problem)";
> }
> catch(...){
>     cout<<"Trying to access invalid object";
> }
> }
> 
> i want something like if x is deleted it should raise exception. i cann't
> assign NULL after deleting that object, that object will be having some
> value, it may be valid or invalid but surlly not NULL
> 
> pls if possible tell me other workout solution or bug in this code
> 
> 
> 
> 

"Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:as36h0$m0j$1@digitaldaemon.com...
> P.S.  I would be very interested to hear about other possible solutions to this particular problem.

In D, whenever an object gets deleted, it's vptr is set to NULL and the reference is set to NULL. This means that accessing the object through the reference generates an exception, and if there are any copies referencing it, they will generate an exception anytime a member function call is attempted.

Is that something that could be added to DMC++ (via an option, of course)?

"Walter" <walter@digitalmars.com> wrote in message news:as3gip$10q8$1@digitaldaemon.com...
>
> "Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:as36h0$m0j$1@digitaldaemon.com...
> > P.S.  I would be very interested to hear about other possible solutions to this particular problem.
>
> In D, whenever an object gets deleted, it's vptr is set to NULL and the reference is set to NULL. This means that accessing the object through the reference generates an exception, and if there are any copies referencing it, they will generate an exception anytime a member function call is attempted.
>
>

Yes.

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:as3l25$15pt$1@digitaldaemon.com...
> Is that something that could be added to DMC++ (via an option, of course)?
>
> "Walter" <walter@digitalmars.com> wrote in message news:as3gip$10q8$1@digitaldaemon.com...
> >
> > "Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:as36h0$m0j$1@digitaldaemon.com...
> > > P.S.  I would be very interested to hear about other possible solutions to this particular problem.
> >
> > In D, whenever an object gets deleted, it's vptr is set to NULL and the reference is set to NULL. This means that accessing the object through
the
> > reference generates an exception, and if there are any copies
referencing
> > it, they will generate an exception anytime a member function call is attempted.
> >
> >
>
>

Cool. When can we have it? Obviously it'll have to be after Mr Access Violation is vanquished ... ;)


"Walter" <walter@digitalmars.com> wrote in message news:as405q$1guh$1@digitaldaemon.com...
> Yes.
>
> "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:as3l25$15pt$1@digitaldaemon.com...
> > Is that something that could be added to DMC++ (via an option, of
course)?
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:as3gip$10q8$1@digitaldaemon.com...
> > >
> > > "Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:as36h0$m0j$1@digitaldaemon.com...
> > > > P.S.  I would be very interested to hear about other possible solutions to this particular problem.
> > >
> > > In D, whenever an object gets deleted, it's vptr is set to NULL and
the
> > > reference is set to NULL. This means that accessing the object through
> the
> > > reference generates an exception, and if there are any copies
> referencing
> > > it, they will generate an exception anytime a member function call is attempted.
> > >
> > >
> >
> >
>
>

It'll have to wait, there are a lot of other things to do first :-(

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:as44eq$1l9n$1@digitaldaemon.com...
> Cool. When can we have it? Obviously it'll have to be after Mr Access Violation is vanquished ... ;)
>
>
> "Walter" <walter@digitalmars.com> wrote in message news:as405q$1guh$1@digitaldaemon.com...
> > Yes.
> >
> > "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:as3l25$15pt$1@digitaldaemon.com...
> > > Is that something that could be added to DMC++ (via an option, of
> course)?
> > >
> > > "Walter" <walter@digitalmars.com> wrote in message news:as3gip$10q8$1@digitaldaemon.com...
> > > >
> > > > "Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:as36h0$m0j$1@digitaldaemon.com...
> > > > > P.S.  I would be very interested to hear about other possible solutions to this particular problem.
> > > >
> > > > In D, whenever an object gets deleted, it's vptr is set to NULL and
> the
> > > > reference is set to NULL. This means that accessing the object
through
> > the
> > > > reference generates an exception, and if there are any copies
> > referencing
> > > > it, they will generate an exception anytime a member function call
is
> > > > attempted.
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Once I had a feature in the runtime library where it would issue an error if you tried to free() the same pointer twice. You would not believe the continuous stream of bug reports I'd get saying that their program "worked" with Brand X compiler and I needed to fix the "bug" in mine.

One more reason why garbage collection is where the future lies <g>.

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:as44eq$1l9n$1@digitaldaemon.com...
> Cool. When can we have it? Obviously it'll have to be after Mr Access Violation is vanquished ... ;)
>
>
> "Walter" <walter@digitalmars.com> wrote in message news:as405q$1guh$1@digitaldaemon.com...
> > Yes.
> >
> > "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:as3l25$15pt$1@digitaldaemon.com...
> > > Is that something that could be added to DMC++ (via an option, of
> course)?
> > >
> > > "Walter" <walter@digitalmars.com> wrote in message news:as3gip$10q8$1@digitaldaemon.com...
> > > >
> > > > "Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:as36h0$m0j$1@digitaldaemon.com...
> > > > > P.S.  I would be very interested to hear about other possible solutions to this particular problem.
> > > >
> > > > In D, whenever an object gets deleted, it's vptr is set to NULL and
> the
> > > > reference is set to NULL. This means that accessing the object
through
> > the
> > > > reference generates an exception, and if there are any copies
> > referencing
> > > > it, they will generate an exception anytime a member function call
is
> > > > attempted.
> > > >
> > > >
> > >
> > >
> >
> >
>
>

This means that D uses only late binding, just like Java, right? Otherwise, this wouldn't affect non-virtual methods...

Laurentiu

Walter wrote:
> "Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message
> news:as36h0$m0j$1@digitaldaemon.com...
> 
>>P.S.  I would be very interested to hear about other possible
>>solutions to this particular problem.
> 
> 
> In D, whenever an object gets deleted, it's vptr is set to NULL and the
> reference is set to NULL. This means that accessing the object through the
> reference generates an exception, and if there are any copies referencing
> it, they will generate an exception anytime a member function call is
> attempted.
> 
>