Re: Can copy assignment operator be const?
Gennaro Prota wrote:
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
Looks like a bug. My test was a bit different; my class was
empty, but I instrumented a const copy constructor, and it was
called; the compiler didn't generate a non-const one to replace
it.
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.
There's nothing to discuss. Pete's contributing a lot to the
standardization effort. Volentarily. If you want to ensure
that your points receive the attention you want them to receive,
there's only one way: participate yourself. I'm sure that every
member of the committee appreciates a polite indication
concerning how and where the standard could be improved. I'm
just as sure that none of them appreciate someone jumping on
their back because their suggestion wasn't treated with as much
importance as they wanted. There are a lot of issues competing
for attention, and if you find that some aren't getting enough
attention, you're welcome to lend a hand.
[...]
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 :-)
That's a broad statement. Define "works". Can I write
something like:
sometype* p = &a[i] ;
?
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.
Off hand, and without having seen a full description of the
class, I got the impression that it was designed to be the
dynamic equivalent of std::bitset. If so, it should do what
std::bitset does, unless there is an imperative reason to do
otherwise.
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.
Maybe. Is it intended that users declare things like
dynamic_bitset::reference? Do you want to support something
like:
dynamic_bitset::reference
someFunction()
{
// ...
return a[ i ] = someValue ;
}
(I could do this with a vector<int> and vector<int>::reference,
for example.)
Until you define exactly what you want to support, and what not,
it's impossible to say what is a good idea, and what isn't. My
proxies don't support this, and it doesn't bother my in the
style of coding I use. But other people have different styles;
there is a reason why = on the built in types results in an
lvalue, for example, even if my code never uses this fact.
--
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! ]