Re: accessors

From: Mark A. Gibbs (x_gibbsmark_at_rogers.com_x)
Date: 08/18/04 

Date: Wed, 18 Aug 2004 17:09:40 GMT

so to summarize several posts (thank you to all contributors), i
personally think the best choice for me would be:

class foo
{
public:
    void set_name(string const& n) { n = name_; }
    string const& name() const { return name_; }
private:
    string name_;
};

daniel t. mentioned that returning references from functions makes using
the function in a distributed environment more difficult, and if the
value returned has to be read from an external source it would have to
have a copy maintained in ram. my response to the first concern is that
i, personally, never write code to be used across application
boundaries, but if i did, "string const& name() const" is functionally
the same as "string name() const", so i don't see why i'd have to change
anything (but if i did, the change does not really affect client code,
beyond making it more expensive). as for the second point, i was
referring specifically to member accessors, but if i were to deal with
the case mentioned, i would think maintaining a local copy of small
amounts of data would probably be "better" performance-wise than reading
it out of a hard disk on each call - but if it cost too much memory to
maintain the data, and/or the data should be read "fresh" on each call,
i would not disguise the call as a call to an accessor, i would use an
imperative function name (as mr. steinbach suggested) and return by
value, so the costs are clearly visible.

i think that in general i can assume a certain amount of trust with
client code. if someone really wants to do dumb things, there are plenty
of ways to do it in c++. in the same way that basic_string.c_str() notes
that the memory pointed to in the return value belongs to the string and
  1) should not be changed by the application or 2) may become invalid
after a modifying operation on the string, i think i can note to client
code that the object referenced in the return belongs to the class,
should not be messed around with by clients and may be invalid after a
modifying operation. there's no practical way you can "accidently" do
anything unkosher to a const reference. and maintaining references to
any object without a severely restricted scope is a risky thing to do.

mark

Relevant Pages

  • Re: Update sheetname from cell, automatically
    ... Const sERROR As String = "Invalid worksheet name in cell " ... Dim sSheetName As String ... Set mySheet = Sheet2 ... ElseIf Not ) Is ...
    (microsoft.public.excel.programming)
  • RE: Get Open File Name dialog. When user clicks cancel.
    ... strCustomFilter As String ... Const ahtOFN_OVERWRITEPROMPT = &H2 ... Optional varTitleForDialog As Variant) As Variant ... Dim strFilter As String ...
    (microsoft.public.office.developer.vba)
  • Get Open File Name dialog. When user clicks cancel.
    ... strCustomFilter As String ... Const ahtOFN_OVERWRITEPROMPT = &H2 ... Optional varTitleForDialog As Variant) As Variant ... Dim strFilter As String ...
    (microsoft.public.office.developer.vba)
  • RE: API Open Dialog. What if user cancels
    ... strCustomFilter As String ... Const ahtOFN_OVERWRITEPROMPT = &H2 ... Optional varTitleForDialog As Variant) As Variant ... Dim strFilter As String ...
    (microsoft.public.access.formscoding)
  • API Open Dialog. What if user cancels
    ... strCustomFilter As String ... Const ahtOFN_OVERWRITEPROMPT = &H2 ... Optional varTitleForDialog As Variant) As Variant ... Dim strFilter As String ...
    (microsoft.public.access.formscoding)
Loading