On Mon, Dec 14, 2009 at 12:25 PM, Benoit Jacob
<jacob.benoit.1@xxxxxxxxx> wrote:
2009/12/14 mmoll <Markus..Moll@xxxxxxxxxxxxxxxx>:
>> 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.
>
> Yes. The biggest advantage is that it documents what you're doing.
>
> class X : nonassignable
> {
> ...
> };
>
> is much easier to understand than
>
> class X
> {
> X& operator= (const X&);
> ...
> };
>
> (you wouldn't even know whether or not it's defined!)
There's a potential practical problem however: if the class X already
inherited a base class, you now have multiple inheritance, and this
tells compilers "now you have a great pretext to go crazy and people
will blame multiple inheritance, not you". I can't speak specifically
for operator=, but I know that MSVC gave us very strange errors when
we tried to do that for overloading operator new. We had to go for a
macro EIGEN_MAKE_ALIGNED_OPERATOR_NEW instead of such a base class,
because of that.
yes, for the sake of completeness let me recall that the pb is that MSVC disables the empty base class optimization when multiple inheritance occurs, so e.g. if we declare:
class ConstMatrix2f : public MatrixBase, nonassignable {
float m_data[2];
// ...
};
then
sizeof(ConstMatrix2f) == sizeof(float)*2 + 1
that is really bad. It should only be: sizeof(float)*2.
gael.
Benoit