Re: accessor member functions and const
From: Faheem Mitha (faheem_at_email.unc.edu)
Date: 02/05/05
- Next message: James Dennett: "Re: [C++] Need help with program please"
- Previous message: J Swift: "Re: I need help with homework problem"
- In reply to: B. v Ingen Schenau: "Re: accessor member functions and const"
- Next in thread: B. v Ingen Schenau: "Re: accessor member functions and const"
- Reply: B. v Ingen Schenau: "Re: accessor member functions and const"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 05 Feb 2005 04:34:53 GMT
On Fri, 04 Feb 2005 09:16:36 +0100, B. v Ingen Schenau
<bart@ingen.ddns.info> wrote:
> Faheem Mitha wrote:
>
> <snip>
>> By the way, the original motivation for doing all this was because I
>> had changed my code recently, and one of my class objects was being
>> mysteriously modified, and it was not clear where. It turned out that
>> this was something of the form
>>
>> model_being_modified = some_other_model
>>
>> This is the implicitly defined copy assignment operator at work. I had
>> forgotten that C++ implicitly defines such things. Any suggestions
>> about good methods of how to set up access control for this? One idea
>> I read would be to declare the copy assignment operator (and copy
>> constructor) private, and then declare functions that need to access
>> this functionality as friend functions. Would that work?
>
> That depends on the circumstances. If assignment is only allowed in a
> very small set of functions and those functions are closely connected
> with the Model class, then the approach of friend-functions could work.
> Otherwise, you are giving yourself a maintenance headache and a false
> sense of security.
There are three functions (out of a much larger group) than need to
use the assignment operator. These are also the only functions which
modify the Model class in any way. I'm not sure I'd say they were
closely connected with the Model class, though.
> If the assignment that you mentioned above was done in a suspicious
> context, like as the test in an if-statement (you wanted ==, but you
> forgot to type one =-sign), then it would be a good idea to crank up
> the warning level of your compiler as high as it will go. Many
> compilers can warn about such apparent mistakes.
No, the assignment in question was legitimate. The problem was that I
had a function where I initialized a Model within the function, then
modified it and returned it. I later changed the function so that
object that was initially initialized as passed in from
outside. Unfortunately, this was an object I should not have been
messing with. I could not declare the object const, because there was
actually one innocuous type "completion" function which all these
object have to be run through before using them.
The friend function approach would not have saved me here, since the
function in question would already have had permission to use the
assignment operator, but at least it would have limited the number of
places I had to look in, and what I had to look for.
> Another option is to use a lint tool, like PCLint, FlexeLint or splint
> (if that last one supports C++, I am not sure). These tools are
> especially designed to find as many dubious constructs in your code as
> possible.
I've not made any systematic effort to use a lint program. Thanks for
the suggestion. Judging from the manual, splint does not support C++.
Faheem.
- Next message: James Dennett: "Re: [C++] Need help with program please"
- Previous message: J Swift: "Re: I need help with homework problem"
- In reply to: B. v Ingen Schenau: "Re: accessor member functions and const"
- Next in thread: B. v Ingen Schenau: "Re: accessor member functions and const"
- Reply: B. v Ingen Schenau: "Re: accessor member functions and const"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]