CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 23 of 23
  1. #16
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,490

    Re: Opinions on my get/set approach

    Quote Originally Posted by superbonzo View Post
    exactly, and the question is, are locking properties the right way of encapsulating synchronization ? ( note that you mentioned locking as a *reason* for using getters/setters ) I don't think so. Such an approach focuses on a narrow view of thread "safety" meant just as "it does not crash with threads". Thread safety means more than that ...
    of course, I'm not against protecting methods with locks per se ( eventually offering multiple levels of granularity ), but getters/setters often are just public fields ( badly ) disguised, politically correct POD struct fields ...
    I mentioned locking as 'another' reason for using getters/setters, not as the *only* reason. Locking on properties are a way to achieve fine grain synchronization for an object, but using this approach depends on what you need (as you know). If you have one lock object and are synchronizing multiple fields with get/set methods, it isn't too efficient - a better approach would be to have a single get/set method pair that acts on the range of properties. However, if you have multiple lock objects within the object and wish to access different fields simultaneously, then the get/set approach could be a valid approach.

    At any rate, I always attempt to encapsulate the locking whenever possible. It always bugs me when I see locking on an object performed by a caller of the object. Sometimes, it is unavoidable, but coding like this is fragile in my opinion because it forces the callee to always lock when accessing the object. Even worse is when there is external locking and the manual release of the lock (vs. using RAII).

    All of this depends on what the usage of the code is. I imagine it would be different if coding for a general purpose library used by thousands vs. coding objects used by a small team.

  2. #17
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: Opinions on my get/set approach

    Quote Originally Posted by razzle View Post
    I mean immutability in the general design sense.

    The definition is simple: A class is immutable if objects cannot be changed after instantiation (regardless of how this is accomplished and enforced in a given language).
    And this is what I meant with "not really". Immutability in C++ is a language feature, not a contract. you can override it (cast it away although there's more ways to do it than just casting).

    static const will typically be located in a readonly section of the PE image making it "sort of" a guarantee, but you can still use system API's to change the page properties even there.

  3. #18
    Join Date
    Jul 2013
    Posts
    576

    Re: Opinions on my get/set approach

    Quote Originally Posted by OReubens View Post
    Immutability in C++ is a language feature
    You are wrong.

    The term immutability is not even mentioned in the standard. Immutable is mentioned once but then in the genereral computer science meaning of the word.

    C++ has a language feature called const or constness which is sometimes used to implement immutable classes. It can be used but it's not necessary to use it.

    The only (not strongly functional) language I know of where immutability is a language feature is D. It has both constness and immutability.

    static const will typically be located in a readonly section of the PE image making it "sort of" a guarantee , but you can still use system API's to change the page properties even there.
    You are missing the point.

    Immutability does't mean an object cannot be tampered with. It means a benign programmer is prevented from accidentally or intentionally modifying the object.

    Beyond that, given the nature of C++ as a close to the machine systems language, a malign programmer can do pretty much what he likes. Stroustrup has been very clear about this. C++ language security mechanisms only protect up to a point.
    Last edited by razzle; January 15th, 2015 at 12:40 PM.

  4. #19
    VictorN's Avatar
    VictorN is online now Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,396

    Re: Opinions on my get/set approach

    Hmm,,, This thread is already ten days old, but the OP seems to have forgotten about it and disappeared...
    Victor Nijegorodov

  5. #20
    Join Date
    Nov 2014
    Posts
    37

    Re: Opinions on my get/set approach

    Quote Originally Posted by VictorN View Post
    Hmm,,, This thread is already ten days old, but the OP seems to have forgotten about it and disappeared...
    Not at all, just a bit hijacked for my original question.

    James

  6. #21
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,490

    Re: Opinions on my get/set approach

    Quote Originally Posted by jcfuller View Post
    Not at all, just a bit hijacked for my original question.

    James
    Let's bring it back on point - don't use macros.

  7. #22
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: Opinions on my get/set approach

    Quote Originally Posted by Arjay View Post
    Let's bring it back on point - don't use macros.
    unless you really really have to. :-)

  8. #23
    Join Date
    Mar 2002
    Location
    St. Petersburg, Florida, USA
    Posts
    12,125

    Re: Opinions on my get/set approach

    1) Don't use macros.
    2) Realize that changing from an exposed member variable to a getter and/or setter is a BREAKING CHANGE.
    TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!)
    2008, 2009,2010
    In theory, there is no difference between theory and practice; in practice there is.

    * Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
    * How NOT to post a question here
    * Of course you read this carefully before you posted
    * Need homework help? Read this first

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured