On Mon, Nov 22, 2010 at 1:25 PM, Derek Gaston <[email protected]> wrote:
>
> On Nov 22, 2010, at 10:29 AM, John Peterson wrote:
>
>> So apparently they have some macro to declare copy constructor and op=
>> private when they are not needed. At first I thought this was
>> overkill because I assumed that if you provided *any* constructor, the
>> compiler doesn't auto-generate the copy constructor or operator=, but
>> that is wrong. If you ever provide an empty constructor for your
>> class, the copy ctor and op= still get auto-generated...
>
> Yeah - this is what I was nipped by earlier. I did my_matrix = matrix....
> and it compiled fine... and just didn't do anything!
>
>> 1.) BoundaryInfo op= implemented but copy ctor not? If you
>
> Boundary info is tricky. There is a reason there is no copy constructor (I'm
> partially to blame here as I added the operator=... and went to add the ctor
> and decided that it couldn't be done). The trouble is with the _mesh
> reference. If you are making a copy of BoundaryInfo it's probably because
> you're wanting to copy it to a new mesh... so you don't want to construct the
> BoundaryInfo object with the old mesh reference (which is what you would do
> in a straightforward copy constructor). So to work around this I coded up
> Mesh::operator= to create a new BoundaryInfo object with the incoming mesh...
> then do bi_new = bi_old using the operator= for BI. Basically doing the
> construction in two steps.
I agree that this is a tricky case, and therefore, we shouldn't use
operator= as the name of the function you have implemented...
operator= should always be just that: assignment with no other
unexpected side effects, since that's what someone naturally expects
when they say a=b. It may be true that a=b doesn't make sense for
BoundaryInfo objects (for the reasons you have mentioned). In that
case, we should disable operator= and the function to "sort of" make a
copy should be named "assign_boundaryinfo_to_new_mesh()" or something.
> BTW - I'm not entirely against the macro... but it has it's own problems. #1
> is that you have to remember to put it everywhere. #2 is that you might
> forget that it is there and try to define operator= and copy ctor... what
> happens then? Also... adding a bunch of macro stuff like this can be the
> path to the darkside....
#1 - yep, there's no way around that, and we can't find every case.
But I think we should favor code that has the potential to be correct
rather than code that generates (possibly) hard-to-diagnose runtime
errors.
#2 - If you forget that it's there and try to define operator=, you
get a compiler error, something along the lines of "cannot be
overloaded" so you can deal with it then
#2a - I agree that macros are evil, but this one is pretty benign:
#define DISALLOW_COPY_AND_ASSIGN(TypeName) \
TypeName(const TypeName&); \
void operator=(const TypeName&);
And you place it into the private section of a class via:
class D
{
public:
D() { }
D(int) { }
private:
// Macro explicitly prevents copy and assignment by declaring
// them private. (Note, you must put the private section in
// yourself, it's not part of the macro!)
DISALLOW_COPY_AND_ASSIGN(D);
};
--
John
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
