On Sun, Dec 13, 2009 at 3:00 PM, mmoll
<Markus.Moll@xxxxxxxxxxxxxxxx> wrote:
Hi
Quoting Hauke Heibel <
hauke.heibel@xxxxxxxxxxxxxx>:
> Another argument pro the empty and private implementation is that
> even in cases where we potentially need the assignment in the future,
> we will have to implement it anyways manually since VS.net fails to
> generate the code automatically and probably the resulting compiler
> errors are nicer too.
to find out for which classes an assignment operator has already been
defined? (no compiler errors (but linker errors), not as easily
greppable...)
Furthermore, VS doesn't really fail to create an assignment operator. It
just can't, and isn't even allowed to, create one in these
circumstances. (Member-wise assignment is impossible to do in the
presence of const members). GCC doesn't create one either (it simply
doesn't warn).
There were actually occasions when that error was issued without const members - I don't recall exactly which classes/structs it were - and that is why I initially chose the current approach. I admit that at some point I started to follow the pattern blindly which was not good.
> Maybe we could make it even nicer with macros.
Wow, you used the words "nicer" and "macros" in the same sentence :-D
Yes, that starts to happen when you want to write portable code... "nicer" = "less intrusive".
I am curious if VS would also warn if you did something similar to
boost's noncopyable, but then nonassignable only. (i.e. have a class
with a private copy assignment operator that is not actually
implemented, and derive from it). If not, this would be the cleanest
solution in my opinion.
It would probably not complain but why would this be the cleanest solution? Boost's noncopyable does exactly the same as I did - private, unimplemented assignment (plus and copy ctor). You just move the linker errors to the base class.
Finally, can somebody please enlighten me, why it is not possible to create an assignment operator for classes with const members? To me it seems sane and the following code compiles perfectly over here:
struct Foo
{
Foo() : i(5) {}
const int i;
};
void main ()
{
Foo a;
Foo b = a;
}
- Hauke
p.s.: I have the commit that disables the warning ready.