Re: Can copy assignment operator be const?
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" (it isn't
considered a copy assignment operator if it is declared const --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++...).
The standard most explicitely says that any user defined
non-template operator= which takes a possibly cv-qualified
version of the class type is a copy assignment operator. Any
compiler which generates a non-const copy assignment operator
when a user-defined const version is there is not conform.
I just tested g++, it gets it right.
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. He (and the other
committee members) are under a lot of pressure right now, and I
can understand their getting irritated by being nagged at for
not picking up some of the less important points as promptly as
the person raising them might like. Being a committee member is
a thankless task; if you contribute seriously, as Pete does,
it's a lot of work, and no matter what you do, some people will
consider it wrong.
I added a bit to the confusion, when asking about bitset<>::reference,
because I forgot a couple of quotation marks: 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, 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. 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.
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.
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. In practice, no
matter what you do, sooner or later, you're going to run into
problemes. In the end, proxies are just that, proxies. They
act as the real thing in certain, well defined cases, and the
rest, you just don't support. In practice, almost all, if not
all, of the uses of swap on standard containers are to achieve
move semantics---it's an optimization for copy constructing,
then destructing. And you don't allow iterators to float around
when you do it, because they wouldn't be valid if you did the
actual copy construction/destruction. Intuitively, an iterator
points into a container, and having it miraculously change the
container it points into is a sure recepe for unreadable code.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]