operator= function

[James Kanze]

terminator wrote:

[...]

I don't. It's just another option, which is considered better.

Better than what? iostream continues to use it, for historical
reasons, but I think that the generally approved solution today
is either HiddenClass* (where HiddenClass is a private member),
or some sort of pointer to member of HiddenClass; both make it
extremely difficult (and the pointer to member makes it
impossible) for the user to recover an apparently usable pointer
to anything, and thus reduce the chance of mis-use even more.

 

[Pete Becker]

terminator wrote:
[...]

why do you insist on 'void*'?

I don't. It's just another option, which is considered better.

Better than what? iostream continues to use it, for historical
reasons, but I think that the generally approved solution today
is either HiddenClass* (where HiddenClass is a private member),
or some sort of pointer to member of HiddenClass; both make it
extremely difficult (and the pointer to member makes it
impossible) for the user to recover an apparently usable pointer
to anything, and thus reduce the chance of mis-use even more.

Specifically, the primary justification for returning a
pointer-to-member rather than a pointer to a class type (or to void*,
for that matter) is that you can't delete it. I haven't seen or heard
of any studies indicating that either of these is a significant
problem, however.

 

[Victor Bazarov]

terminator wrote:
[...]

why do you insist on 'void*'?

I don't. It's just another option, which is considered better.

Better than what?

Better than 'bool'. Better than 'int'.

iostream continues to use it, for historical
reasons, but I think that the generally approved solution today
is either HiddenClass* (where HiddenClass is a private member),
or some sort of pointer to member of HiddenClass; both make it
extremely difficult (and the pointer to member makes it
impossible) for the user to recover an apparently usable pointer
to anything, and thus reduce the chance of mis-use even more.

Yes, that's better still.

V

 

[gpderetta]

terminator wrote:

[...]
why do you insist on 'void*'?
I don't. It's just another option, which is considered better.

Better than what? iostream continues to use it, for historical
reasons, but I think that the generally approved solution today
is either HiddenClass* (where HiddenClass is a private member),
or some sort of pointer to member of HiddenClass; both make it
extremely difficult (and the pointer to member makes it
impossible) for the user to recover an apparently usable pointer
to anything, and thus reduce the chance of mis-use even more.

Specifically, the primary justification for returning a
pointer-to-member rather than a pointer to a class type (or to void*,
for that matter) is that you can't delete it. I haven't seen or heard
of any studies indicating that either of these is a significant
problem, however.

I've seen it happen at least once. The conversion was always to
false,
so delete 0 didn't complain (crashing the application would have saved
a lot of debugging).
It took us a while to track the bug.

The (not) fun thing is that our operator safe-bool was actually
using the proper pointer to member function idiom but we were
using a broken gcc version (3.3.5 IIRC) that had a regression
that allowed that illegal code to compile (it was fixed in gcc 3.3.6).

HTH,

 

[terminator]

On 2007-12-07 07:15:59 -0500, James Kanze <[email protected]> said:

terminator wrote:
[...]
why do you insist on 'void*'?
I don't. It's just another option, which is considered better.
Better than what? iostream continues to use it, for historical
reasons, but I think that the generally approved solution today
is either HiddenClass* (where HiddenClass is a private member),
or some sort of pointer to member of HiddenClass; both make it
extremely difficult (and the pointer to member makes it
impossible) for the user to recover an apparently usable pointer
to anything, and thus reduce the chance of mis-use even more.

Specifically, the primary justification for returning a
pointer-to-member rather than a pointer to a class type (or to void*,
for that matter) is that you can't delete it. I haven't seen or heard
of any studies indicating that either of these is a significant
problem, however.

I've seen it happen at least once. The conversion was always to
false,
so delete 0 didn't complain (crashing the application would have saved
a lot of debugging).
It took us a while to track the bug.

The (not) fun thing is that our operator safe-bool was actually
using the proper pointer to member function idiom but we were
using a broken gcc version (3.3.5 IIRC) that had a regression
that allowed that illegal code to compile (it was fixed in gcc 3.3.6).

casting to pointer to a type that defines delete can fix that too:

class none_delete{
void operator delete(void *)//can become public
{/*empty*/};
}

operator A::none_delete*()
{
....
return reinterpreit_cast<none_delete *>(result);
};

regards,
FM.

 

[terminator]

terminator wrote:
On Dec 4, 11:53 pm, "Victor Bazarov" <[email protected]>
wrote:
[..]
Imagine (and that will require you to think outside the box, I *am*
holding my breath for this one) that the OP wants to check the
success of the assignment operation. The OP could then define
class A {
bool operator=(const A& other);
};
so that the assignment could be either checked
you will lose the ability to chain:
{
int a, b, c;
a=b=c;//ok
}{
A a, b, c;
a=b=c;//error
}
Chaining is not necessarily a good idea. Neither is the assignment
operator that can fail, of course. In that case it would probably
be best to have a member function that would return 'bool'.

as long as OP needs a type that follows the syntax for intrisic
types ,chaining must not be dropped.But generally you are right of
course.

why do you insist on 'void*'?

I don't. It's just another option, which is considered better.
You seem to not like it. Why?

I was not just sure if it was the best,Now I know it was not.

regards,
FM.

 

[James Kanze]

On 2007-12-07 07:15:59 -0500, James Kanze <[email protected]> said:

terminator wrote:

[...]

why do you insist on 'void*'?
I don't. It's just another option, which is considered better.

Better than what? iostream continues to use it, for historical
reasons, but I think that the generally approved solution today
is either HiddenClass* (where HiddenClass is a private member),
or some sort of pointer to member of HiddenClass; both make it
extremely difficult (and the pointer to member makes it
impossible) for the user to recover an apparently usable pointer
to anything, and thus reduce the chance of mis-use even more.

Specifically, the primary justification for returning a
pointer-to-member rather than a pointer to a class type (or to
void*, for that matter) is that you can't delete it.

Adding a private operator delete to HiddenClass would solve that
as well.

I'm not that much of a purist. I might use HiddenClass*,
because it only takes one extra line, and it will solve the most
obvious abuses (static_cast, or passing it to a legacy C
function which takes a void*). But quite frankly...

I haven't seen or heard of any studies indicating that either
of these is a significant problem, however.

I've never had (nor heard of) any problems with misuse of the
void* in iostream either. I use HiddenClass in my smart
pointers, as an argument for == and !=, so that the user can
only pass NULL, but that's really about it in practice.

But he said "better". And it's a sort of a challenge to
think of how you could detect as many user errors as possible,
even if you'd never actually do it in practice, because the work
involved largely outweighs the actual gain.

 

[Pete Becker]

But he said "better". And it's a sort of a challenge to
think of how you could detect as many user errors as possible,
even if you'd never actually do it in practice, because the work
involved largely outweighs the actual gain.

The problem is that these exercises tend to become enshrined. The
current WD for C++0x has half a dozen places that advise returning a
pointer-to-member as the implementation-specific return type of a
conversion operator that's intended for testing the state of an object.
Fortunately, most of those are going away, and being replaced with
explict conversion operators.