-
January 13th, 2015, 01:17 PM
#16
Re: Opinions on my get/set approach
Originally Posted by superbonzo
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.
-
January 14th, 2015, 07:47 AM
#17
Re: Opinions on my get/set approach
Originally Posted by razzle
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.
-
January 15th, 2015, 03:06 AM
#18
Re: Opinions on my get/set approach
Originally Posted by OReubens
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.
-
January 15th, 2015, 04:48 AM
#19
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
-
January 15th, 2015, 05:43 AM
#20
Re: Opinions on my get/set approach
Originally Posted by VictorN
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
-
January 15th, 2015, 04:55 PM
#21
Re: Opinions on my get/set approach
Originally Posted by jcfuller
Not at all, just a bit hijacked for my original question.
James
Let's bring it back on point - don't use macros.
-
January 16th, 2015, 07:50 AM
#22
Re: Opinions on my get/set approach
Originally Posted by Arjay
Let's bring it back on point - don't use macros.
unless you really really have to. :-)
-
March 11th, 2015, 03:52 PM
#23
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
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|