How to know the pointer of a object is deleted or not?
yangyong
{...};
int GetSome( const A* ptr)
{
// Is ptr valid??? How to know??
}
--
Best regards,
Knowledge is power!
---
Posted via news://freenews.netfront.net
Complaints to ne...@netfront.net
Gianni Mariani
> class A
> {...};
>
> int GetSome( const A* ptr)
> {
> // Is ptr valid??? How to know??
> }
>
There is no way using standard C++.
You can check for a NUL pointer .... if ( ptr == 0 ) ....
Other than that, you need to make sure you code does not allow for a
pointer to be used if it is deleted. This leads to all kinds of schemes
to deal with memory management.
G
Chris Theis
"yangyong" <yang...@xteamlinux.com.cn> wrote in message
news:bdtrsj$7k8$1...@adenine.netfront.net...
> class A
> {...};
>
> int GetSome( const A* ptr)
> {
> // Is ptr valid??? How to know??
> }
>
Just as Gianni already pointed out it's common practice to check for NULL.
For debugging purposes you can also use assert statements or take a look at
ENFORCEMENTS (http://www.cuj.com/documents/s=8250/cujcexp2106alexandr/).
HTH
Chris
flekso
new operator to add each instance of a class to some shared memory table:
active[pointers];
and something similar with delete.
"yangyong" <yang...@xteamlinux.com.cn> wrote in message
news:bdtrsj$7k8$1...@adenine.netfront.net...
Tom
responsible for the de-allocation. There for the position where the
de-allocation occurs is specified and after this the pointer should be
redirected to NULL.
For more information read C++ Memory Management (Scott Meyers).
Regards,
Tom
"yangyong" <yang...@xteamlinux.com.cn> wrote in message
news:bdtrsj$7k8$1...@adenine.netfront.net...
Chris Theis
"Tom" <t...@yahoo.com> wrote in message
news:bduf2l$107v8r$1...@ID-133116.news.dfncis.de...
> A Guide for C++ says, that the object which allocates the memory is
> responsible for the de-allocation.
That's what common design practice and common sense tells us but sometimes
one faces situations (unfortunately!) where this might not be true.
> There for the position where the
> de-allocation occurs is specified and after this the pointer should be
> redirected to NULL.
>
> For more information read C++ Memory Management (Scott Meyers).
>
> Regards,
> Tom
>
Chris
Robert Bauck Hamar
| "yangyong" <yang...@xteamlinux.com.cn> wrote in message
| news:bdtrsj$7k8$1...@adenine.netfront.net...
|> class A
|> {...};
|>
|> int GetSome( const A* ptr)
|> {
|> // Is ptr valid??? How to know??
|> }
|
| if you have control over class design maybe you could implement your custom
| new operator to add each instance of a class to some shared memory table:
|
| active[pointers];
|
| and something similar with delete.
This could work, until someone does:
A myA;
GetSome(&myA);
A better idea would be to add the instance in the constructor, and
remove it in the destructor. As a bonus, it will work with derived
classes.
--
Robert Bauck Hamar
flekso
"Robert Bauck Hamar" <hamr...@yahoo.no> wrote in message
news:slrnbg5hio....@sos-dhcp324.studby.uio.no...
Ron Natalie
"flekso" <tau...@email.hinet.hr> wrote in message news:bdu459$ecf5$1...@as201.hinet.hr...
> if you have control over class design maybe you could implement your custom
> new operator to add each instance of a class to some shared memory table:
>
> active[pointers];
>
> and something similar with delete.
>
or previously deleted) pointer value.
flekso
"Ron Natalie" <r...@sensor.com> wrote in message
news:3f02e66b$0$87833$9a6e...@news.newshosting.com...
Karl Heinz Buchegger
flekso wrote:
>
> do what?
>
eg. assign it to another pointer variable or use them in a comparison.
PS: Please don't top post. Put your reply beneath the text you are
replying to
--
Karl Heinz Buchegger
kbuc...@gascad.at
flekso
a pointer acquired from his custom 'new' operator in a table of currently
active objects somewhere in a shared memory and remove it upon deletion
in a custom new he has access to the allocation address and (if it's
possible to write a custom) delete operator he has access to the untouched
value(address) of that instance
so:
new
{
pA=malloc();
active[x++]= pA;
}
delete
{
search_and_destroy (active, pA);
free(pA);
x--;
}
"Karl Heinz Buchegger" <kbuc...@gascad.at> wrote in message
news:3F03E8EB...@gascad.at...
Ron Natalie
"flekso" <tau...@email.hinet.hr> wrote in message news:be1ndm$4e1o$2...@as201.hinet.hr...
> i didn't say that at all, i said that (s)he should place a value(address) of
> a pointer acquired from his custom 'new' operator in a table of currently
> active objects somewhere in a shared memory and remove it upon deletion
>
value after it's been deleted, so there's no safe way to go look it up. Your
example is specifcally covered by the standard (3.7.3.2/4)
If the argument given to a deallocation function in the standard library is a pointer that is not the null
pointer value (4.10), the deallocation function shall deallocate the storage referenced by the pointer, render-ing
invalid all pointers referring to any part of the deallocated storage. The effect of using an invalid
pointer value (including passing it to a deallocation function) is undefined.
Note that phrase in parentheses at the end there.
flekso
time then the second time around there won't be such value in the active[]
array thus delete will return quitely without making a move...
delete
{
first checks if there's an address in the active array
if so deallocates the ram
decrement the instance count
whatnot
}
"Ron Natalie" <r...@sensor.com> wrote in message
news:3f04642e$0$87913$9a6e...@news.newshosting.com...
Ron Natalie
"flekso" <tau...@email.hinet.hr> wrote in message news:be1s7q$3i74$1...@as201.hinet.hr...
> but if it(delete op.) removes the value(address) from the table the first
> time then the second time around there won't be such value in the active[]
> array thus delete will return quitely without making a move...
>
> delete
> {
> first checks if there's an address in the active array
> if so deallocates the ram
> decrement the instance count
> whatnot
> }
But it's too late. Yoiu can't call delete on a value that has already deleted. It's
NOT ALLOWED regardless of what your deallocation function does. Even if it
were, you are not allowed to compare it against all the elements in the table to
see if it were there. Thats NOT ALLOWED either.
And furthermore, please post real code. Your pseudocode is meaningless and it
leads me to believe you don't know what the difference between the delete operator
and the deallocation function (operator delete) is.
flekso
deleted."
pointer is still in use
active[0]=00406664
active[1]=07FF0032
pA=12345678 --doesn't even try to delete it, there's no entry
"you are not allowed to compare it against all the elements in the table to
see if it were there"
--how come?
"Ron Natalie" <r...@sensor.com> wrote in message
news:3f047641$0$87911$9a6e...@news.newshosting.com...
Ron Natalie
"flekso" <tau...@email.hinet.hr> wrote in message news:be25nl$4k90$1...@as201.hinet.hr...
> "But it's too late. Yoiu can't call delete on a value that has already
> deleted."
> --i'm not, that's what the active array is here for - to check if the
> pointer is still in use
Which you did in delete, which as I pointed out is TOO LATE.
>
> active[0]=00406664
> active[1]=07FF0032
>
> pA=12345678 --doesn't even try to delete it, there's no entry
>
> "you are not allowed to compare it against all the elements in the table to
> see if it were there"
> --how come?
Because the standard says so. Presumably the committee envisioned a
machine where pointers are a special type to the hardware (perhaps only when
loaded into an address or index register) and that the hardware might trap or
otherwise do bad things when it knows the value is not allocated to your
application.
flekso
the pA variable has not been touched until compared to all active[]
ments -how can that be late?
it's a brand new shiny address returned from malloc or such, and nobody else
touched it...
maybe i don't understand your meaning of lateness, could you give me an
example of not being too late?
thanks for reading(i'm really trying to sort this out in my head)
"Ron Natalie" <r...@sensor.com> wrote in message
news:3f049d25$0$11861$9a6e...@news.newshosting.com...
Karl Heinz Buchegger
flekso wrote:
>
> okay just one more time, what is too late for what?
>
> the pA variable has not been touched until compared to all active[]
> ments -how can that be late?
> it's a brand new shiny address returned from malloc or such, and nobody else
> touched it...
>
> maybe i don't understand your meaning of lateness, could you give me an
> example of not being too late?
>
> thanks for reading(i'm really trying to sort this out in my head)
Please, one more time: don't top post!
The problem is:
Once you have deleted an object, any pointers to that object
get invalid. So how do you check if the address in question
is in the array? You compare that address with every entry
in the array. And that's the problem: If the passed address
is already invalid (because it has been removed earlier), you
are no longer allowed to do this comparisons. The standard
says that *any* use of such an address is invalid, and that
includes comparisons too.
flekso
but if it's removed earlier it will *not be found* in the active[] array and
nothing good/bad will come out of it because you don't touch the active
table unless the comparison turns out right, and you don't delete a byte
until this condition is satisfied so:
first traverse the active[];
then deallocate the space;
it may be against the standard but it won't hurt the active table
Karl Heinz Buchegger
flekso wrote:
>
> > The problem is:
> > Once you have deleted an object, any pointers to that object
> > get invalid. So how do you check if the address in question
> > is in the array? You compare that address with every entry
> > in the array. And that's the problem: If the passed address
> > is already invalid (because it has been removed earlier), you
> > are no longer allowed to do this comparisons. The standard
> > says that *any* use of such an address is invalid, and that
> > includes comparisons too.
> >
> > --
> > Karl Heinz Buchegger
> > kbuc...@gascad.at
>
> but if it's removed earlier it will *not be found* in the active[] array
Here is the problem. What do you need to do to *find* that pointer?
You need to compare it with all entries. And thats already invalid
if the pointer is invalid.
> and
> nothing good/bad will come out of it because you don't touch the active
> table unless the comparison turns out right, and you don't delete a byte
> until this condition is satisfied so:
I am not talking about the delete.
I am talking about the lookup in the table!
Once a pointer has an invalid address you can't use it any longer
in any way, not even for comparing!
>
> first traverse the active[];
> then deallocate the space;
>
> it may be against the standard but it won't hurt the active table
On most systems, it will do no harm. Nevertheless you have no
guarantee that it will work everywhere.
Karl Heinz Buchegger
Karl Heinz Buchegger wrote:
>
> > and
> > nothing good/bad will come out of it because you don't touch the active
> > table unless the comparison turns out right, and you don't delete a byte
> > until this condition is satisfied so:
>
> I am not talking about the delete.
> I am talking about the lookup in the table!
> Once a pointer has an invalid address you can't use it any longer
> in any way, not even for comparing!
:-) Of course you can assign a new value to that variable, but that's
the only operation you safely can do with that variable.
flekso
address
if the pointer holds invalid address it does so by it's own fault -but it
still can't do any damage to the active[] table
"Karl Heinz Buchegger" <kbuc...@gascad.at> wrote in message
news:3F05511F...@gascad.at...
Karl Heinz Buchegger
flekso wrote:
>
> okay, but it's not my fault(or the new/delete's) if the pointer has invalid
> address
> if the pointer holds invalid address it does so by it's own fault -but it
> still can't do any damage to the active[] table
Nobody said it is your fault.
All we are saying is:
you have no guarantee that you can check a pointer for valifty
without crashing the machine.
That's all.
tom_usenet
wrote:
>okay, but it's not my fault(or the new/delete's) if the pointer has invalid
>address
>if the pointer holds invalid address it does so by it's own fault -but it
>still can't do any damage to the active[] table
It can, but it is more likely that the application will crash. This
simple program may crash:
int main()
{
int* p = new int;
delete p;
p != 0; // the comparison can cause a crash
}
The problem is that once you have deleted p, the simple act of loading
it into a pointer register on the CPU (triggered by an
lvalue-to-rvalue convertion in the C++ code) can cause the CPU to
trap, in practical terms leading to a crash.
Tom
flekso
sub [ecx] , [ebp+24] ;this could cause a gpf
rather
sub ecx, [ebp+24] ;nothing here
ecx being the pointer value
"tom_usenet" <tom_u...@hotmail.com> wrote in message
news:3f059621....@news.easynet.co.uk...
Raoul Gough
> "tom_usenet" <tom_u...@hotmail.com> wrote in message
> news:3f059621....@news.easynet.co.uk...
[snip]
>> This simple program may crash:
>>
>> int main()
>> {
>> int* p = new int;
>> delete p;
>> p != 0; // the comparison can cause a crash
>> }
>>
>> The problem is that once you have deleted p, the simple act of loading
>> it into a pointer register on the CPU (triggered by an
>> lvalue-to-rvalue convertion in the C++ code) can cause the CPU to
>> trap, in practical terms leading to a crash.
>>
> but it won't be doing an
> sub [ecx] , [ebp+24] ;this could cause a gpf
>
> rather
> sub ecx, [ebp+24] ;nothing here
>
> ecx being the pointer value
As Karl-Heinz tried to point out, the convention in this newsgroup is
to post comments/replies inline (i.e. not top-posted). It makes it
easier for readers to drop into a thread in the middle, since they can
more easily see what you are replying to.
To address the point you are making - yes, on an Intel x86 processor,
you will probably not have a problem doing a comparison with an
invalidated pointer value. What the others are trying to tell you is
that the C++ language standard does not *require* that it works. It is
"undefined behaviour" as far as the standard is concerned, and the
fact that some compiler on some OS on some processor works the way you
expect it to doesn't alter this fact.
As far as the C++ standard is concerned, tom_usenet's example could do
anything at all on your platform, including working as you expect, but
also including reformatting your hard disk when run on a Thursday,
etc...
The "use of deleted pointer value" discussion repeats itself in the
C++ newsgroups occasionally - maybe you can find some more info via
Google Groups.
--
Raoul Gough
"Let there be one measure for wine throughout our kingdom, and one
measure for ale, and one measure for corn" - Magna Carta
Jeff Rosenfeld
> int main()
> {
> int* p = new int;
> delete p;
> p != 0; // the comparison can cause a crash
> }
>
> The problem is that once you have deleted p, the simple act of loading
> it into a pointer register on the CPU (triggered by an
> lvalue-to-rvalue convertion in the C++ code) can cause the CPU to
> trap, in practical terms leading to a crash.
Mr Flekso seems to have trouble grokking the standard-based argument, but
there's another example that makes the array lookup plan wrong:
p = new P;
delete p;
q = new P; // might be assigned to where p used to be; q==p
delete p; // p is now in the table so q gets deleted
q->x = 1; // BOOM
So the detection effort complicated your life and didn't get you anything.
- Jeff.
flekso
you removed it on 2nd line
plus if you have control over delete intrinsic you could make sure p=NULL;
"Jeff Rosenfeld" <spamo...@comcast.net> wrote in message
news:dqadnfIEzpf...@comcast.com...
Karl Heinz Buchegger
flekso wrote:
> "Jeff Rosenfeld" <spamo...@comcast.net> wrote in message
> news:dqadnfIEzpf...@comcast.com...
> >
> > > int main()
> > > {
> > > int* p = new int;
> > > delete p;
> > > p != 0; // the comparison can cause a crash
> > > }
> > >
> > > The problem is that once you have deleted p, the simple act of loading
> > > it into a pointer register on the CPU (triggered by an
> > > lvalue-to-rvalue convertion in the C++ code) can cause the CPU to
> > > trap, in practical terms leading to a crash.
> >
> > Mr Flekso seems to have trouble grokking the standard-based argument, but
> > there's another example that makes the array lookup plan wrong:
> >
> > p = new P;
> > delete p;
> > q = new P; // might be assigned to where p used to be; q==p
> > delete p; // p is now in the table so q gets deleted
> > q->x = 1; // BOOM
> >
> > So the detection effort complicated your life and didn't get you anything.
> >
>
> & that resides in p is not in the table anymore,
The last time: please don't top post! I had to rearrange to bring your
remark into the correct context. If you don't care then we will stop
caring about your remarks.
You have to read more carefully.
There is nothing that prevents the runtime system to hand out
the same address for assignment to q that was used with p.
> you removed it on 2nd line
and on the 3-rd line a new address was requested. That might be the same
address that was handed out in line 2.
>
> plus if you have control over delete intrinsic you could make sure p=NULL;
>
That wouldn't buy you anything:
p = new P;
q = p;
delete q;
p->x = 1; // BOOM
even if q contains NULL after the delete, that wouldn't influence p.
Ron Natalie
"flekso" <tau...@email.hinet.hr> wrote in message news:be3eja$6nms$1...@as201.hinet.hr...
> okay just one more time, what is too late for what?
>
Too late to look at it's value.
> the pA variable has not been touched until compared to all active[]
> ments -how can that be late?
If it's already been deleted once, you can't compare it to active to see if it
is still there.
> it's a brand new shiny address returned from malloc or such, and nobody else
> touched it...
>
That part is fine, but your scenario was that you were going to check this after
the pointer had been possibly deleted once. If the pointer has been deleted
you can't look it up in a table to check to see if you are allowed to delete it again.
flekso
#include <stdlib.h>
#include <time.h>
static int *active;
static int onumber=0;
class A
{
public:
A()
{
time_t t;
mytime = time( &t );
}
~A()
{
}
void* operator new( unsigned int size )
{
void* p;
puts( "NEW" );
active = ( int* ) realloc ( active, onumber * sizeof( int ) + sizeof(
int ) );
p = malloc ( size );
active[onumber] = (int) p;
onumber++;
return ( p );
}
void operator delete( void* o )
{
int n = onumber - 1;
puts( "DELETE" );
if( o && onumber )
{
do
{
printf( "\t%i\t%p\n", n, active[n]);
if( active[n] == ((int) o) )
{
active[n] = active[onumber - 1];
onumber--;
active = ( int* ) realloc ( active, onumber * sizeof( int ) );
free( o );
printf( "\tDELETED\t%p\n\n", o );
break;
}
}
while (n--);
}
}
int gettime ( void )
{
printf( "my time is %i\n", mytime );
return( 0 );
}
private:
time_t mytime;
};
int freeo ( int *pactive, int numbero );
int main(int argc, char* argv[])
{
A* pA;
A* pB;
A* pC;
A* pD;
pA = new A;
pB = pA;
pC = new A;
pD = new A;
(*pA).gettime();
(*pD).gettime();
onumber = freeo ( active, onumber );
(*pC).gettime();
(*pB).gettime();
return 0;
}
int freeo ( int *pactive, int numbero )
{
if( numbero > 0 )
while( numbero )
delete (A*) pactive[numbero--];
return ( numbero );
}
flekso
Karl Heinz Buchegger
flekso wrote:
>
[snip an example which is intended to demonstrate that
something is possible, but has a major flaw: it is based
in the assumption that sizeof(int) >= sizeof(void*)]
And who guarantees that
sizeof( int ) >= sizeof( void*)
Flekso:
Just live with it. There is no 100% reliable way
to check if a pointer has been handed out or has
already been returned to the free store management.
No matter what you do.
100% reliable means: works guaranteed on each and
every compiler/operating system/hardware.
tom_usenet
wrote:
[SNIP code]
That formatted the hard disk on my DEATHSTATION 2000!
Tom
flekso
memory address, big deal
"Karl Heinz Buchegger" <kbuc...@gascad.at> wrote in message
news:3F0A7704...@gascad.at...
Karl Heinz Buchegger
flekso wrote:
>
> okay so you would have to insert one other macro or define the size of a
> memory address, big deal
On my Deathstation-2000 the situation is this:
sizeof(int) equals 2
sizeof(long) equals 4
sizeof(void*) equals 16
What macros would you suggest :-)
flekso
with all the deathstations in the world but you must admit it is feasible
( will i ever implement such a thing in my scribblings? highly unlikely,
but... )
better solution:
write a c++ parser that checks the code for double delete, NULL delete
"Karl Heinz Buchegger" <kbuc...@gascad.at> wrote in message
news:3F0ABA4F...@gascad.at...
Scott Condit
> better solution:
> write a c++ parser that checks the code for double delete, NULL delete
And why do you think such "parsers" are generally possible?
Scott Condit
scott a t socode d o t com
flekso
problem except for the runtime mischief + dlls okay,okay but maybe it's
doable -i'm to tired... schleep
"Scott Condit" <soc...@socode.com> wrote in message
news:beesn9$4ffct$1...@ID-189137.news.dfncis.de...