Re: Can copy assignment operator be const?
On 30 Nov 2006 22:23:42 -0500, James Kanze wrote:
Gennaro Prota wrote:
On 28 Nov 2006 10:47:06 -0500, James Kanze wrote:
Gennaro Prota wrote:
FWIW, we were talking about *copy* assignment operators.
I missed that. I thought it was just a question of assignment
operators in general. To tell the truth, I hadn't thought too
much about the question of copy assignment; in at least some
implementations, I don't even support it. (The only operator=
that exists returns void).
Just to be sure we are on the same wavelength: there seems to be no
such a thing as a "const copy assignment operator" [...] --the
standard seems to say otherwise, but all compilers I tried, including
Comeau, seemed to agree with the above; I think a DR would be in
order, but if you have read Pete Becker's comments in the thread
'Editorial change proposal in 12.8/2', on c.std.c++...).
[...]
Any compiler which generates a non-const copy assignment operator
when a user-defined const version is there is not conform.
That's how I read 12.8 (actually that's how I read 12.8/10, on the
grounds that "if" stands, as usually happens in the standard, for "if
and only if")
I just tested g++, it gets it right.
Instead I tried the following with Comeau online:
struct X
{
const int x;
X():x(0) {}
const X& operator=( const X & ) const { return *this; }
};
int main()
{
X x;
/*const*/ X x2; // add the const to compile successfully
x2 = x;
}
and the error message was
"ComeauTest.c", line 1: error: implicitly generated
assignment operator cannot copy:
const member "X::x"
struct X
^
detected during implicit generation of
"X &X::operator=(const X &)" at line 12
As for Pete Becker's comments in c.s.c++, I imagine that what
he's really bored by is people complaining that there defect
report isn't getting priority attention.
Too bad that this isn't the right place for discussing such behaviors.
[...] I just meant to ask if
you felt a compelling reason for having a const operator=(const
reference &).
As I said, nothing compelling. Except that the default is to
make any function const if one can,
That's what I usually do as well. For the two assignment operators in
dynamic_bitset<>::reference (and other member functions, now that I
think about it) it really didn't occur to me. My bad :-)
and that it is, in some
circles, a recognized hallmark of a proxy, and so helps some in
the documentation.
Thinking about it, however, I don't think it makes a difference.
(And the compiler generated version doesn't work, so my
BitVectorAccessProxy has an error.)
Do you have a const one in your BitVectorAccessProxy?
Actually, I just let the compiler do its thing. Which is wrong,
see below:
I'd imagine you have only mutable data members in it, then (or
that you store a pointer to the corresponding bit-vector,
which makes bit-references not stable under a standard library
swap of their bit-vectors).
On thinking about it: the whole idea behind using a proxy is
that it is in some way transparent. The user never declares
instances of a proxy (although we can't prevent it);
In the case of static/dynamic bitsets access control can help. In my
implementation, for instance, the only non-copy constructor of the
proxy class is private (dynamic_bitset is a friend).
That's often what I do, at least today. In the case of my
BitVectorAccessProxy, however, there are technical reasons why
this isn't possible. (I think---I'd have to look at it again.)
the real
reason one might want to support it is for expressions of the
sort:
a[ i ] = b[ j ] = newValue ;
Now, this would work perfectly if there was NO copy assignment
operator, but we can't achieve that; there will always be one.
You mean it would work perfectly relying on the proxy implicit
conversion and a non-copy assignment from value_type?
Well, if there were NO copy assignment operator, that's what
would happen. The only assignment operator available would be
the one taking a bool, and since there is an implicit conversion
available...
Yes. But, as you
say,
a[ i ] = b[ j ]
will always lead to consider (and eventually generate) the copy
assignment operator.
More correctly (although it really doesn't make any difference),
there is no such thing as a class type in which no copy
assignment operator is declared. The declaration is generated
as soon as the class definition is seen. That operator takes
part in overload resolution, and of course, would be chosen
here.
In my original expression, of course, it would suffice if the
operator=( bool ) returned a bool, rather than a reference to
the proxy.
For this expression to work, it's semantics should be:
Container::AsgnProxy const&
Container::AsgnProxy operator=(
Container::AsgnProxy const& other ) const
{
return ::operator=(
static_cast< Container::value_type> ( other ) ) ;
}
And yes, a const assignment operator works perfectly well here.
I assume you mean "would" work (if there was NO copy assignment).
For the
b[ j ] = newValue ;
part, instead, one usually defines another assignment operator.
I'm not sure I'm following you.
You are following :-) I just stated the obvious.
We're talking about a proxy
here. By definition, it has another assignment operator.
Otherwise, the above would be illegal. The question is how to
make something like:
a[ i ] = b[ j ] = newValue ;
work as expected. Off hand, you either need something like I
just proposed, or the other assignment operator must return
bool.
My
question is: would you consider my implementation of
dynamic_bitset::reference defective in this regard?
<http://preview.tinyurl.com/uew6m>
I'd have to study it. Off hand, it looks like it should work.
Well, it works :-) But my question was more on the style side: "how
would you consider the lack of const?". I'm happy to hear that you
don't consider adding it compelling, though if I had thought of it I'd
have used it.
Given the name, and it's presumed relationship to std::bitset,
I'd say that it should probably do whatever bitset does.
That is, do you feel that operator=( bool ) should be const?
Considered in isolation, I'd probably make it const, because
that corresponds to the conventions in vigor where I work.
Considered as a potential part of the standard, related to
std::bitset, I'd follow the conventions in std::bitset, where it
isn't const.
Note, however, that there is no real reason for it not to be
const. Declare the function const, and all desired uses still
work.
Propagating the const qualification on a bunch of other functions (and
on at least a return type), yes :-) The idea to return a bool from
bool operator=(bool x) const { do_assign(x); return x; }
is particularly nice.
Note that
the bitset/dynamic_bitset case is a bit peculiar (hence my question; I
even supposed that you could restrict the term "proxy" to exclude such
pseudo-reference beasts --I had a look at Design Patterns and I'm not
sure whether "bit references" as we are discussing them here are
proxies in any of the GoF meanings), in that you cannot store a
pointer to the container (because you want a standard library swap on
the containers not to invalidate any proxy object --IOWs the proxies,
like real references, have to refer to the same bits, even if those
bits have changed container).
I'm not sure. Typically, as I said, you don't ever declare
variables of a proxy type.
I think if you really want to support STL, and have reference
act as if it were a real reference in some way, you'd have to
also define a "pointer" type, overload &, etc.
One idea I wanted to experiment with was to have address-of return an
iterator when applied to a reference. So far I haven't had time (and
spurs) for that, though.
[hard-to-disagree-with comments snipped :-)]
--
Gennaro Prota. C++ developer. For hire.
(to mail me, remove any 'u' from the address)
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]