473,320 Members | 1,900 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

auto_ptr and operator void*();

Is there any reason why auto_ptr does not have the cast operator like this:

operator void* ();

So that one could easily test auto_ptr for NULL ???
Standard does not declare such operator.
Is the only way to check if auto_ptr points to NULL, is to use .get() method
?

Martin
Jul 19 '05 #1
24 6221
WW
Marcin Vorbrodt wrote:
Is there any reason why auto_ptr does not have the cast operator like
this:

operator void* ();

So that one could easily test auto_ptr for NULL ???
Standard does not declare such operator.
Is the only way to check if auto_ptr points to NULL, is to use .get()
method ?


Nope. There is another one, but that is uglier. To call opertator-> in its
function form. I dunno what is the rationale to leave out operator void*...
It might be present in the rationale in the upcoming C++ Standard book. But
until then I guess the best is to ask in comp.lang.c++.moderated. Guys who
actually worked on this design mostly hang out there because they gave up on
this group due to the sheer amount of trolls and off-topic posts. IIRC I
have read about how auto_ptr became what it is today, but I do not recall
talling anything about the "missing" operator bool or void*.

According to Herb Sutter in http://www.gotw.ca/gotw/025.htm it was Bill
Gibbons, Greg Colvin and Steve Rumsby who has finalized auto_ptr.

--
WW aka Attila
Jul 19 '05 #2
"Marcin Vorbrodt" <mv*****@eos.ncsu.edu> wrote in message
news:bk**********@uni00nw.unity.ncsu.edu...
Is there any reason why auto_ptr does not have the cast
operator like this:

operator void* ();

So that one could easily test auto_ptr for NULL ???
This would allow someone to write:

auto_ptr<int> p(new int);

delete p;
Standard does not declare such operator.
Nor should it. A "safe bool" idiom would be better.
Is the only way to check if auto_ptr points to NULL, is to
use .get() method ?


As far as I know, but that's not a guarantee that there isn't
another way.

Dave
Jul 19 '05 #3
David B. Held wrote:
"Marcin Vorbrodt" <mv*****@eos.ncsu.edu> wrote in message
news:bk**********@uni00nw.unity.ncsu.edu...
Is there any reason why auto_ptr does not have the cast
operator like this:

operator void* ();

So that one could easily test auto_ptr for NULL ???

This would allow someone to write:

auto_ptr<int> p(new int);

delete p;


Would it? Can you delete a void *? The delete operator wouldn't know
what destructor (if any) to use, or the amount of memory to be freed
(unless it's stored with the allocated memory somehow).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #4
WW
Kevin Goodsell wrote:
auto_ptr<int> p(new int);

delete p;


Would it? Can you delete a void *? The delete operator wouldn't know
what destructor (if any) to use, or the amount of memory to be freed
(unless it's stored with the allocated memory somehow).


According to 5.3.5 P 1, 2 not.

"In the first alternative (delete object), the value of the operand of
delete shall be a pointer to a nonarray object or a pointer to a subobject
(1.8) representing a base class of such an object (clause 10). If not, the
behavior is undefined."

--
WW aka Attila
Jul 19 '05 #5
WW wrote:
Kevin Goodsell wrote:
auto_ptr<int> p(new int);

delete p;


Would it? Can you delete a void *? The delete operator wouldn't know
what destructor (if any) to use, or the amount of memory to be freed
(unless it's stored with the allocated memory somehow).

According to 5.3.5 P 1, 2 not.

"In the first alternative (delete object), the value of the operand of
delete shall be a pointer to a nonarray object or a pointer to a subobject
(1.8) representing a base class of such an object (clause 10). If not, the
behavior is undefined."


So are you saying it can be a void *, or it cannot? As far as I can
tell, this passage only talks about the value of the operand, not the type.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #6
Kevin Goodsell wrote:
WW wrote:
Kevin Goodsell wrote:
auto_ptr<int> p(new int);

delete p;
Would it? Can you delete a void *? The delete operator wouldn't know
what destructor (if any) to use, or the amount of memory to be freed
(unless it's stored with the allocated memory somehow).


According to 5.3.5 P 1, 2 not.

"In the first alternative (delete object), the value of the operand of
delete shall be a pointer to a nonarray object or a pointer to a
subobject
(1.8) representing a base class of such an object (clause 10). If not,
the
behavior is undefined."


So are you saying it can be a void *, or it cannot? As far as I can
tell, this passage only talks about the value of the operand, not the type.


From the same section, paragraph 3:

3 In the first alternative (delete object), if the static type of the
operand is different from its dynamic type, the static type shall be a
base class of the operand's dynamic type and the static type shall
have a virtual destructor or the behavior is undefined.

I think that would cover void *, meaning the behavior is undefined, right?

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #7
Kevin Goodsell wrote:
Kevin Goodsell wrote:
WW wrote:
According to 5.3.5 P 1, 2 not.

"In the first alternative (delete object), the value of the operand of
delete shall be a pointer to a nonarray object or a pointer to a
subobject
(1.8) representing a base class of such an object (clause 10). If
not, the
behavior is undefined."


So are you saying it can be a void *, or it cannot? As far as I can
tell, this passage only talks about the value of the operand, not the
type.


From the same section, paragraph 3:

3 In the first alternative (delete object), if the static type of the
operand is different from its dynamic type, the static type shall be a
base class of the operand's dynamic type and the static type shall
have a virtual destructor or the behavior is undefined.

I think that would cover void *, meaning the behavior is undefined, right?


Footnote from the section I quoted above:

21) This implies that an object cannot be deleted using a pointer of
type void* because there are no objects of type void.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #8
WW
Kevin Goodsell wrote:
According to 5.3.5 P 1, 2 not.

"In the first alternative (delete object), the value of the operand
of delete shall be a pointer to a nonarray object or a pointer to a
subobject (1.8) representing a base class of such an object (clause
10). If not, the behavior is undefined."


So are you saying it can be a void *, or it cannot? As far as I can
tell, this passage only talks about the value of the operand, not the
type.


It can. And it is undefined behavior. IMO they could say it cannot. I
have no idea why didn't they do so. There is no DR on it... I wonder why.
But I guess at 00:30 with flu I will not find it out. :-( I guess we could
post to the std newsgroup to ask why didn't they say that deleting a void*
is ill-formed. g++ warns about it being undefined but that is all. I did
not see anything telling what the type should be.

--
WW aka Attila
Jul 19 '05 #9
WW
Kevin Goodsell wrote:
3 In the first alternative (delete object), if the static type of
the operand is different from its dynamic type, the static type
shall be a base class of the operand's dynamic type and the
static type shall have a virtual destructor or the behavior is
undefined.

I think that would cover void *, meaning the behavior is undefined,
right?


Paragraph 2 with 1 together does. It should either be a (or be convertible
to) a pointer to a complete class type or to an array. void is neither of
those and as you see my quote then the behavior (for a pointer to non-array
what void * is) is undefined.

--
WW aka Attila
Jul 19 '05 #10
WW
Kevin Goodsell wrote:
Footnote from the section I quoted above:

21) This implies that an object cannot be deleted using a
pointer of type void* because there are no objects of type void.


Yep. But footnotes are non-normative and the normative text only says
undefined behavior. I think deleting of void * should be ill-formed. It
can be vaught at compile time and it is always an error.

--
WW aka Attila
Jul 19 '05 #11
WW wrote:
Kevin Goodsell wrote:
Footnote from the section I quoted above:

21) This implies that an object cannot be deleted using a
pointer of type void* because there are no objects of type void.

Yep. But footnotes are non-normative and the normative text only says
undefined behavior. I think deleting of void * should be ill-formed. It
can be vaught at compile time and it is always an error.


Well, my interpretation of paragraph 3 makes it ill-formed. But perhaps
my interpretation is wrong.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #12
"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:Hm****************@newsread3.news.pas.earthli nk.net...
[...]
This would allow someone to write:

auto_ptr<int> p(new int);

delete p;


Would it? Can you delete a void *? The delete operator
wouldn't know what destructor (if any) to use, or the
amount of memory to be freed (unless it's stored with
the allocated memory somehow).


How does it know when you cast to void* and back?

int* p = new int(42);
void* q = static_cast<void*>(p);
int* r = static_cast<int*>(q);

delete r;

Obviously, the information must be saved somewhere,
so it doesn't seem impossible that:

delete q;

wouldn't have the same effect as "delete r;" above.

Anyway, I seem to recall that this was an argument for
not having an implicit conversion to void* in MC++D,
which is why Loki::SmartPtr does not provide one.
But, since my copy of MC++D is not handy, I can't
look it up.

Dave
Jul 19 '05 #13
WW
Kevin Goodsell wrote:
WW wrote:
Kevin Goodsell wrote:
Footnote from the section I quoted above:

21) This implies that an object cannot be deleted using a
pointer of type void* because there are no objects of type void.


Yep. But footnotes are non-normative and the normative text only
says undefined behavior. I think deleting of void * should be
ill-formed. It can be vaught at compile time and it is always an
error.


Well, my interpretation of paragraph 3 makes it ill-formed. But
perhaps my interpretation is wrong.


Unfortunately it is. The phrase ill-formed is nowhere present in that
paragraph (or the 1 and 2 for that matter). What is there is undefined
behavior. Which needs no diagnostics! So in this matter (as I understand
the current text and saw no DRs on it) David B. Held is right, the auto_ptr
class type would implicitly be converted into a void * and then all the
demons of hell would break loose when it is deleted. IMO this is a fixable
error in the standard. I see no reason why to leave this void* in as
undefined behavior, when it is clearly diagnostizable at compile time. I
also do not get the undefined behavior if the pointed class is incomplete -
but that can be justified. Only the static type can be checked at compile
time, the dynamic not. But IMO this is only problem with multiple
inheritance. With single inheritance the deletion can be done by simply
calling the right destructor, since there will be no subobject and no
pointer adjustment is necessary.

--
WW aka Attila
Jul 19 '05 #14
David B. Held wrote:
"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:Hm****************@newsread3.news.pas.earthli nk.net...
[...]
This would allow someone to write:

auto_ptr<int> p(new int);

delete p;
Would it? Can you delete a void *? The delete operator
wouldn't know what destructor (if any) to use, or the
amount of memory to be freed (unless it's stored with
the allocated memory somehow).

How does it know when you cast to void* and back?

int* p = new int(42);
void* q = static_cast<void*>(p);
int* r = static_cast<int*>(q);

delete r;

Obviously, the information must be saved somewhere,
so it doesn't seem impossible that:


I think you're argument is lacking.

r is an int * - the size is sizeof(int). The static_cast<int*>(q) put
that information you're referring to back into the pointer. Hence the
size of what r is pointing to is known at the time it is deleted.

What do you think this should do ?

int* p = new char(42);
void* q = static_cast<void*>(p);
MuthaObject * r = static_cast<int*>(q);
delete r;

delete q;


the size of what q is pointing to is not known.
Jul 19 '05 #15
Gianni Mariani wrote in news:bk********@dispatch.concentric.net:

I think you're argument is lacking.

r is an int * - the size is sizeof(int). The static_cast<int*>(q) put
that information you're referring to back into the pointer. Hence the
size of what r is pointing to is known at the time it is deleted.

What do you think this should do ?

int* p = new char(42);
void* q = static_cast<void*>(p);
MuthaObject * r = static_cast<int*>(q);
delete r;

delete q;


the size of what q is pointing to is not known.


operator delete doesn't take size info, demo below.

The type info in delete is (can) only be used to call the destructor.
Also there would be little utility in banning delete (void *), as
all it really does is call the global operator delete( void * ). It
never needs the :: when used in a member function though.

#include <iostream>
#include <ostream>

struct base
{
virtual ~base() {}
void *operator new (std::size_t sz )
{
std::cout << "new; " << sz << std::endl;
return ::operator new( sz );
}

void operator delete ( void *p )
{
std::cout << "deleteing; " << p << std::endl;
::operator delete ( p );
}
};

struct derived: base
{
int i;
};

void del_base( base *b )
{
delete b;
}

int main()
{
base *b = new base;
del_base( new derived );
del_base( b );
}

Rob.
--
http://www.victim-prime.dsl.pipex.com/
Jul 19 '05 #16
"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bk********@dispatch.concentric.net...
[...]
What do you think this should do ?

int* p = new char(42);
void* q = static_cast<void*>(p);
MuthaObject * r = static_cast<int*>(q);
delete r;


Unless there is a defined conversion from int* to
MuthaObject*, I think it should elicit a diagnostic.
And if there is a conversion from int* to MuthaObject*,
I should hope the author of such a conversion has
taken into account this very situation.
delete q;


the size of what q is pointing to is not known.


That's an interesting question. Theoretically, the
compiler *could* always keep track of what void* are
pointing to, but I'm not sure they are required to do so,
which is probably why it results in undefined behaviour.

Dave
Jul 19 '05 #17
David B. Held wrote:
"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bk********@dispatch.concentric.net...
[...]
What do you think this should do ?

int* p = new char(42);
void* q = static_cast<void*>(p);
MuthaObject * r = static_cast<int*>(q);
delete r;

Unless there is a defined conversion from int* to
MuthaObject*, I think it should elicit a diagnostic.


Maybe, but it is perfectly legal C++ (except for a typo I just noticed).

The point was that the pointer information is mostly compile-time, not
run time and with casting you get to control the behaviour.
And if there is a conversion from int* to MuthaObject*,
I should hope the author of such a conversion has
taken into account this very situation.
Even if there was a conversion, it would not be used because the
conversion is from a void *.

No question that the above code is like whacking yourself over the head
with a 4x2. C++ (and C) let's you do that, especially when you start
messing with type casts.

delete q;


the size of what q is pointing to is not known.

That's an interesting question. Theoretically, the
compiler *could* always keep track of what void* are
pointing to, but I'm not sure they are required to do so,
which is probably why it results in undefined behaviour.


I don't think you can. There are paths of data that are outside the
control of the conmpiler.


Jul 19 '05 #18
Rob Williscroft wrote:
Gianni Mariani wrote in news:bk********@dispatch.concentric.net:

I think you're argument is lacking.

r is an int * - the size is sizeof(int). The static_cast<int*>(q) put
that information you're referring to back into the pointer. Hence the
size of what r is pointing to is known at the time it is deleted.

What do you think this should do ?

int* p = new char(42);
void* q = static_cast<void*>(p);
MuthaObject * r = static_cast<int*>(q);
delete r;

delete q;

the size of what q is pointing to is not known.

operator delete doesn't take size info, demo below.


I think it does.
#include <iostream>
char allocator_data[1024];
int amount_allocated = 0;
class Foo
{
public:

void * operator new( unsigned int size )
{
char * ptr = ( allocator_data + amount_allocated );
amount_allocated += size;

std::cout << "Allocate size is " << size << std::endl;

return ( void * ) ptr;
}

void * operator new[]( unsigned int size )
{
char * ptr = ( allocator_data + amount_allocated );
amount_allocated += size;

std::cout << "Allocate size is " << size << std::endl;

return ( void * ) ptr;
}

void operator delete( void * ptr, unsigned int size )
{
std::cout << "delete size is " << size << std::endl;

// drop memory on the floor
}

void operator delete[] ( void * ptr, unsigned int size )
{
std::cout << "delete size is " << size << std::endl;

// drop memory on the floor
}

};
class B : public Foo
{
public:
int xxx;
int yyy;
};
int main()
{

B * z = new B;

B * k = new B[30];

delete z;

delete [] k;
}

Admittedly it's an optional parameter BUT it is available and I've seen
some really KULE allocators that use this information when managing
extreme numbers of tiny objects and saving big time on memory and cycles.

The type info in delete is (can) only be used to call the destructor.
Most of the time.
Also there would be little utility in banning delete (void *), as
all it really does is call the global operator delete( void * ). It
never needs the :: when used in a member function though.

delete ptr

and

operator delete( ptr )

are 2 different things.

delete ptr also calls the destructor (if it exists) while operator
delete( ptr ) simply calls the method "operator delete( ... )".


Jul 19 '05 #19
"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bk********@dispatch.concentric.net...
David B. Held wrote:
[...]
Unless there is a defined conversion from int* to
MuthaObject*, I think it should elicit a diagnostic.
Maybe, but it is perfectly legal C++ (except for a typo I
just noticed).


I'm not sure what's so legal about it:

class MuthaObject { };

int main()
{
MuthaObject* p = new int;
}

"ComeauTest.c", line 5: error: a value of type "int *" cannot
be used to initialize an entity of type "MuthaObject *"
MuthaObject* p = new int;

The point was that the pointer information is mostly
compile-time, not run time and with casting you get to
control the behaviour.
Of course. What does that have to do with void*?
And if there is a conversion from int* to MuthaObject*,
I should hope the author of such a conversion has
taken into account this very situation.


Even if there was a conversion, it would not be used
because the conversion is from a void *.


Not sure what you're talking about here. I'm talking
about:
MuthaObject * r = static_cast<int*>(q);


[...]
That's an interesting question. Theoretically, the
compiler *could* always keep track of what void* are
pointing to, but I'm not sure they are required to do so,
which is probably why it results in undefined behaviour.


I don't think you can. There are paths of data that are
outside the control of the conmpiler.


Such as?

Dave
Jul 19 '05 #20
David B. Held wrote:
"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bk********@dispatch.concentric.net...
David B. Held wrote:
[...]
Unless there is a defined conversion from int* to
MuthaObject*, I think it should elicit a diagnostic.
Maybe, but it is perfectly legal C++ (except for a typo I
just noticed).

I'm not sure what's so legal about it:

class MuthaObject { };

int main()
{

This was posted (typo fixed).
int* p = new int(42);
void* q = static_cast<void*>(p);
MuthaObject * r = static_cast<int*>(q);
delete r;

and you tried this ?
MuthaObject* p = new int;
}

"ComeauTest.c", line 5: error: a value of type "int *" cannot
be used to initialize an entity of type "MuthaObject *"
MuthaObject* p = new int;


I don't think you're testing what I posted.

The point was that the pointer information is mostly
compile-time, not run time and with casting you get to
control the behaviour.

Of course. What does that have to do with void*?

Maybe I mis-understood what you meant by

"the information must be saved somewhere".

What did you mean by that ?

And if there is a conversion from int* to MuthaObject*,
I should hope the author of such a conversion has
taken into account this very situation.
Even if there was a conversion, it would not be used
because the conversion is from a void *.

Not sure what you're talking about here. I'm talking
about:

Specifically, the compiler MUST NOT apply a conversion from int * to
MuthaObject* (even if one exists) to be compliant to the standard with
the code snippet I posted.


MuthaObject * r = static_cast<int*>(q);

[...]
That's an interesting question. Theoretically, the
compiler *could* always keep track of what void* are
pointing to, but I'm not sure they are required to do so,
which is probably why it results in undefined behaviour.


I don't think you can. There are paths of data that are
outside the control of the conmpiler.

Such as?


Libraries, files, devices ...

Jul 19 '05 #21
"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bk********@dispatch.concentric.net...
David B. Held wrote:
[...]
I'm not sure what's so legal about it:

class MuthaObject { };

int main()
{

This was posted (typo fixed).
int* p = new int(42);
void* q = static_cast<void*>(p);
MuthaObject * r = static_cast<int*>(q);
delete r;

and you tried this ?
MuthaObject* p = new int;
}

[...]

I don't think you're testing what I posted.


I'm testing the part that I thought should cause a diagnostic
to be emitted, which was the assignment of an int* to a
MuthaObject*.
[...]
Maybe I mis-understood what you meant by

"the information must be saved somewhere".

What did you mean by that ?
I mean the compiler must keep track of pointer type
information somewhere in order to do valid casts to void*
and back. But technically, I guess that's not the case.
The compiler could just assume that you perform casts
correctly, and invoke undefined behaviour if you don't.
[...]
Specifically, the compiler MUST NOT apply a
conversion from int * to MuthaObject* (even if one
exists) to be compliant to the standard with the code
snippet I posted.


So what's your point?
[...]
I don't think you can. There are paths of data that are
outside the control of the conmpiler.


Such as?


Libraries, files, devices ...


I don't think you can read pointers from a file and expect
them to work properly, but I will buy that a pointer passed
over a DLL/so boundary will probably not have any
special type information.

Dave
Jul 19 '05 #22
Gianni Mariani wrote in news:bk********@dispatch.concentric.net:
Rob Williscroft wrote:
Gianni Mariani wrote in news:bk********@dispatch.concentric.net:

I think you're argument is lacking.

r is an int * - the size is sizeof(int). The static_cast<int*>(q)
put that information you're referring to back into the pointer. Hence
the size of what r is pointing to is known at the time it is deleted.

What do you think this should do ?

int* p = new char(42);
void* q = static_cast<void*>(p);
MuthaObject * r = static_cast<int*>(q);
delete r;
delete q;
the size of what q is pointing to is not known.

operator delete doesn't take size info, demo below.


I think it does.


[snip]

Thanks for the code, as an aside I got:
<aside>

bcc32:
Allocate size is 16
Allocate size is 480
delete size is 16
delete [] size is 16

g++:
Allocate size is 8
Allocate size is 244
delete size is 8
delete size is 244

cl:
Allocate size is 8
Allocate size is 240
delete size is 8
delete [] size is 8

g++ takes an extra 4 bytes for the size-of info it passes back.

1 out of 3 got delete [] right. I mostly consider cl to be my most
conforming compiler ( It does 2-Phase lookup if you prod it just right )
but then gcc comes along and does this.

</aside>
Admittedly it's an optional parameter
Size info never gets passed on to the to ::operator delete i.e. the
inbuilt "free-store" has to retain any size-of information that it might
require.

In general a compiler has to be able to compile delete expresions
where it is unable to pass size or any other info other than the
pointer to operator delete.
BUT it is available and I've seen
some really KULE allocators that use this information when managing
extreme numbers of tiny objects and saving big time on memory and
cycles.

The type info in delete is (can) only be used to call the destructor.


Most of the time.
Also there would be little utility in banning delete (void *), as
all it really does is call the global operator delete( void * ). It
never needs the :: when used in a member function though.

delete ptr

and

operator delete( ptr )

are 2 different things.

delete ptr also calls the destructor (if it exists) while operator
delete( ptr ) simply calls the method "operator delete( ... )".


delete (void *)ptr; will call ::operator delete( ptr ) and nothing else.
It will do this even when in a class scope that defines a member
operator delete.

Rob.
--
http://www.victim-prime.dsl.pipex.com/
Jul 19 '05 #23
Marcin Vorbrodt <mv*****@eos.ncsu.edu> wrote:
# Is there any reason why auto_ptr does not have the cast operator like this:

# operator void* ();

# So that one could easily test auto_ptr for NULL ???
# Standard does not declare such operator.

Right. Moreover, such an operator will not allow you to compare the inside
pointer against NULL. At least because NULL is not a 'void*' value, but
'int' value.

To be able to compare the inside pointer against NULL, the auto_ptr template
had to provide appropriate '==' operator with 'int' as an argument. This also
does not matter if you use the deprecated NULL constant, or - as recommended
- directly 0.

I think also that this problem is wider and is a more global problem with
null pointer value. Neither 0 nor NULL is a good way to check the pointer
against null pointer value. You can find a better definition of 'null'
symbol at:

http://www.intercon.pl/~sektor/cbx/g...templates.html

Search for "NULL" string there; the definition is below that line.
(any suggestions welcome ;)
# Is the only way to check if auto_ptr points to NULL, is to use .get() method
# ?

By standard methods, yes.
--
1 6 1 7 4 4 2 548 g4bc7a4 66z 3xt7w v1y z9p1 120 32
(( Michal "Sektor" Malecki w4 66 64 73 7564 24 5 v 34 4
)) ektor van Skijlen 1 5 5 1 844 a v r z 4
Software engineer, Motorola GSG Poland 1 2 2a 1 4
WARNING: Opinions presented by me on usenet groups are my personal opinions
ONLY and are not connected to the employer.
Jul 19 '05 #24

"Sektor van Skijlen" <se****@hasiok.org> wrote in message news:bk**********@newshost.mot.com...
Right. Moreover, such an operator will not allow you to compare the inside
pointer against NULL. At least because NULL is not a 'void*' value, but
'int' value.
Huh? Of coruse it's not a void* value, but it's comparable to one. An
arbitrary object pointer that is a null pointer, converted to another object pointer
(like void*) is the null pointer and can be compared against the null pointer
constant (NULL).

To be able to compare the inside pointer against NULL, the auto_ptr template
had to provide appropriate '==' operator with 'int' as an argument. This also
does not matter if you use the deprecated NULL constant, or - as recommended
- directly 0.
Nonsense, the overload would not be needed. NULL is NOT deprecated.
I think also that this problem is wider and is a more global problem with
null pointer value. Neither 0 nor NULL is a good way to check the pointer
against null pointer value.
It works, the major problem is that it's confusable with integers in overloading
contexts.

You can find a better definition of 'null' symbol at:

http://www.intercon.pl/~sektor/cbx/g...templates.html


I don't speak Polish.
Jul 19 '05 #25

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

10
by: ma740988 | last post by:
Part of my confusion here is certainly my ignorance of templates and std::auto_ptr. Two topics, I've perused but need to really _delve_ into. In any event, consider the 'test' source. #...
2
by: Stephan Hoffmann | last post by:
Hi, I'm new to std::auto_ptr<> and wanted to use it with a base class and several derived classes. I'm using gcc 3.3.5 and get a compile error I don't know how to resolve when compiling the...
10
by: dragoncoder | last post by:
Hi all, I am trying to understanding std::auto_ptr<Tclass implementation from "The C++ standard library" by Nicolai Josuttis. He gives a sample implementation of auto_ptr class template in...
9
by: dragoncoder | last post by:
Hi all, I am trying to understand the auto_ptr_ref role in the implementation of auto_ptr<>. I read the information on net but still not 100% sure of it. My plan is as follows. 1. To see the...
39
by: Andre Siqueira | last post by:
Hello all, I have a member function like thist: Query(const std::string & id, std::auto_ptr<Modifiermodif = std::auto_ptr<Modifier>()) when a try to instantiate a Query like ...
18
by: Barry | last post by:
struct A { void Print() const { cout << "Print" << endl; } }; auto_ptr<AGet() {
4
by: james.lawton | last post by:
Hi, I'm having a problem that I can't diagnose. I'm creating istreams of unknown types, and want to manage them on the stack, co I'm passing around ownership-holding pointers. Usually, I would...
15
by: asm23 | last post by:
Hi, everyone, I'm studying the <<Thinking in C++>volume Two. In Chapter One, the example code : Auto_ptr.cpp //------------------------------------------------------- #include <memory> #include...
17
by: Ankur Arora | last post by:
Hi All, I'm building a sample application that uses a custom auto_ptr implementation. The program crashes with the following output:- Output (Debug Assertion failed) ----------
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.