Re: set erase of null and nonexistent elements

[puzzlecracker]

Anyway, the code below does not make any use of operator(). It uses
std::less<A*>. If that is not specialized in A.h, the remarks below apply.
If it is specialzed, you have to make sure it is a strict total ordering.

I meant something else entirely. I was refering to algorithms, such as
find_if where passed predicate, which implemented operator () for
comparison. I assume set uses operator == to locate elements of UDT.
Correct me if am wrong.

What does standard or popular implementation dictate of the following
example:

#include<set>
#include "A.h"

using std::set

int main(int argc, char **argv)
{
std::set<A *aSet;
A *nullA=0;
A *a=new A("NOT HERE")

set.insert(new A("something"))
//here is the list of operations I am
aSet.erase(nullA);

null-op: nullA is not in the set.

aSet.erase(a);

null-op: a is not in the set.

//clean up and return
return 0;
}

How do standard containers (instantiated with some pointer to user-
defined type) behave in the presence of null pointer?

Well, if we insert a null pointer into a set, wouldn't it cause an
error whenever the container would try to invoke its member.

Wait, perhaps an std container doesn't do that, hence no errors are to
be seen, then how does find work?

[Kai-Uwe Bux]

puzzlecracker wrote:

>

>Anyway, the code below does not make any use of operator(). It uses
std::less<A*>. If that is not specialized in A.h, the remarks below
apply. If it is specialzed, you have to make sure it is a strict total
ordering.

I meant something else entirely. I was refering to algorithms, such as
find_if where passed predicate, which implemented operator () for
comparison. I assume set uses operator == to locate elements of UDT.
Correct me if am wrong.

You are wrong: std::set<uses std::less<to decide whether two elements
are equal. The idea is that a == b can be characterized as neither a < b
nor b < a. In fact, operator== is not used by std::set<at all.

What does standard or popular implementation dictate of the following
example:

#include<set>
#include "A.h"

using std::set

int main(int argc, char **argv)
{
std::set<A *aSet;
A *nullA=0;
A *a=new A("NOT HERE")

set.insert(new A("something"))
//here is the list of operations I am
aSet.erase(nullA);

null-op: nullA is not in the set.

aSet.erase(a);

null-op: a is not in the set.

//clean up and return
return 0;
}

How do standard containers (instantiated with some pointer to user-
defined type) behave in the presence of null pointer?

Well, if we insert a null pointer into a set, wouldn't it cause an
error whenever the container would try to invoke its member.

Yes. Dereferencing a null-pointer is undefined behavior. That, however, does
not imply that you cannot insert the null-pointer into a set. You just have
to make sure that it does not get dereferenced.

Wait, perhaps an std container doesn't do that, hence no errors are to
be seen, then how does find work?

Post code, so that we can discuss find() or find_if() meaningfully. I don't
trust my crystal ball and can only guess what you are looking at.

Best

Kai-Uwe Bux

[James Kanze]

On Sep 15, 1:21 am, Kai-Uwe Bux <[e-mail]:

puzzlecracker wrote:

[...]

Well, if we insert a null pointer into a set, wouldn't it
cause an error whenever the container would try to invoke
its member.

Yes. Dereferencing a null-pointer is undefined behavior. That,
however, does not imply that you cannot insert the
null-pointer into a set. You just have to make sure that it
does not get dereferenced.

Also, std::set<T*never dereferences the pointers it contains.
Let's face it, this is pure template code, with no partial
specializations or whatever, so the code is exactly the same for
pointers and for non-pointers.

Of course, if you explicitly specialize std::less< A* so that
it does dereference the pointer, you'll get into deep trouble if
the pointer is null. But that would be just stupid (unless your
goal is obfuscation). The standard defines a full ordering on
pointers (using std::less, but not with <), and requires
std::set to use this ordering by default. A reader who sees a
set instantiated without a custom ordering function has a right
to expect that this ordering is what is used, and not something
else. (If this ordering isn't appropriate, and it often isn't,
then you should says so explicitly, by providing an ordering
argument to the template instantiation.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]