Re: [eigen] private copy ctors

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


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.

That's not a convincing argument. Doesn't it just make it more difficult
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).

> Maybe we could make it even nicer with macros. 

Wow, you used the words "nicer" and "macros" in the same sentence :-D

> First, it would allow us to prevent this hack for non VC compilers 
> and second, since the we just learned that for state- / memberless 
> objects it is more optimal to let the compiler generate ctor, dtor 
> and assignment (if possible), we could even prevent the explicit 
> implementation for GCC in cases where it were required but GCC 
> manages to create the code automatically.

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. If VS still warns, then I think the best way to
get around this is to actually disable the warning (either with a flag
or with the pragma that was mentioned somewhere). This avoids putting
undefined operators into way too many classes (which actually also needs
documentation everywhere, because it might not be obvious that there is
no implementation, and it might not be obvious why it's done).

Markus




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/