The real issue with accessors and mutators

[Steven T. Hatton]

The reason Stroustrup warns against using set and get functions is that an
object of class type should be designed in such a way as to maintain some
invariant. All operations on the class should be such that they maintain
the invariant. An example is a std::vector<>. The invariant can be state
as: a std::vector<T> hold a number of elements given by the return value of
the member function std::vector<T>::size(). This means that adding or
removing elements from the vector must happen in such a way that the
returnvalue of size() reflects the resulting number of elements.

Hence, the value that should not be available for direct manipulation by a
user is the value returned by size(). We can assume for the sake of this
discussion that this return value is stored in some memory location defined
as a member field of the vector<> under discussion.

I find the general warning against using get and set member functions overly
vague, and potentially harmful. There are many, many, instances where
using such functions is perfectly legitimate, and can be done in such a way
as to preserve a meaningful invariant. Too often such general injunctions
become widely accepted in the same way as the misguidance rendered by the
injunction that a preposition is some thing we should not end a sentence
with has.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Victor Bazarov]

The reason Stroustrup warns against using set and get functions is that an

Can you share at least the chapter number where such warning is?

object of class type should be designed in such a way as to maintain some
invariant. All operations on the class should be such that they maintain
the invariant. An example is a std::vector<>. The invariant can be state
as: a std::vector<T> hold a number of elements given by the return value of
the member function std::vector<T>::size(). This means that adding or
removing elements from the vector must happen in such a way that the
returnvalue of size() reflects the resulting number of elements.

Hence, the value that should not be available for direct manipulation by a
user is the value returned by size(). We can assume for the sake of this
discussion that this return value is stored in some memory location defined
as a member field of the vector<> under discussion.

I find the general warning against using get and set member functions overly
vague, and potentially harmful.

Potentially? Like scissors? They are potentially harmful.

There are many, many, instances where
using such functions is perfectly legitimate, and can be done in such a way
as to preserve a meaningful invariant. Too often such general injunctions
become widely accepted in the same way as the misguidance rendered by the
injunction that a preposition is some thing we should not end a sentence
with has.

I think you have too much time on your hands.

A warning is a warning. You cannot argue against it because there are
cases where such warning doesn't hold. You cannot argue that warning
against driving too fast is "overly vague and potentially harmful" because
there can be instances when driving fast is essential to survival. If the
author of a book has to make excuses and provide explanations for every
passage they put in a book, there will be no trees left on this planet.

V

 

[Andrew Koenig]

The reason Stroustrup warns against using set and get functions is that an
object of class type should be designed in such a way as to maintain some
invariant. All operations on the class should be such that they maintain
the invariant. An example is a std::vector<>. The invariant can be state
as: a std::vector<T> hold a number of elements given by the return value
of
the member function std::vector<T>::size(). This means that adding or
removing elements from the vector must happen in such a way that the
returnvalue of size() reflects the resulting number of elements.

This conclusion does not follow. A more accurate conclusion would be that
every operation that changes the value of size() must change the number of
elements correspondingly--in other words, there must not be an operation
that changes the value of size() and does nothing else.

Hence, the value that should not be available for direct manipulation by a
user is the value returned by size(). We can assume for the sake of this
discussion that this return value is stored in some memory location
defined
as a member field of the vector<> under discussion.

But in fact, there *is* an operation that changes the value of size() --
it's named resize. If is a vector and we call v.resize(n), v.size() will
subsequently be equal to n. Of course, a side effect of that call is to
cause the number of elements in v to *be* n, either by deleting elements or
fabricating new ones.

 

[Steven T. Hatton]

Can you share at least the chapter number where such warning is?

The one place I can find mention of set and get functions right now is
§24.4.2. I don't believe that is the only place where he mentions the
issue. If time permits, I'll try to find the other comment.

I think you have too much time on your hands.

A warning is a warning. You cannot argue against it because there are
cases where such warning doesn't hold. You cannot argue that warning
against driving too fast is "overly vague and potentially harmful" because
there can be instances when driving fast is essential to survival. If the
author of a book has to make excuses and provide explanations for every
passage they put in a book, there will be no trees left on this planet.

V

I think this kind of thing can be important. I'm grappling with a tricky
situation along these lines in code I'm currently working on. I have a set
of basis vectors which are members of one class, and which I want to modify
as a result of calculations in another class. The solution of returning a
mutable reference to the member bases makes the modification code much
cleaner, but compromises my ability to guarantee linear independence as a
class invariant.

The reason I believe such warnings can be potentially harmfull is because
people can and often do accept them uncritically and judge another person's
work accordingly.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Steven T. Hatton]

This conclusion does not follow. A more accurate conclusion would be that
every operation that changes the value of size() must change the number of
elements correspondingly--in other words, there must not be an operation
that changes the value of size() and does nothing else.

I believe that is a superset of what I was describing.

But in fact, there *is* an operation that changes the value of size() --
it's named resize. If is a vector and we call v.resize(n), v.size() will
subsequently be equal to n. Of course, a side effect of that call is to
cause the number of elements in v to *be* n, either by deleting elements
or fabricating new ones.

What I meant by direct manipulation was the ability to write directly to the
memory location where size is stored. By calling resize(n), the user
specifies the desired value of size, but leaves it to the details of the
function to affect the actual change.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Mike Wahler]

The reason I believe such warnings can be potentially harmfull is because
people can and often do accept them uncritically and judge another person's
work accordingly.

The 'potential harm' of which you speak does not come from
e.g. warnings by experts, but by those who read but don't think.

-Mike

 

[DaKoadMunky]

The reason Stroustrup warns against using set and get functions is that an

object of class type should be designed in such a way as to maintain some
invariant.

Strange. I would think get and set functions were ways to help maintain the
invariant. Making the corresponding data members public certainly makes
maintaining the invariant less likely. This of course assumes that the get and
set functions read and write data members that are part of the visible state of
the object and are implemented such that implementation dependencies are not
created and invariants cannot be violated.

I find the general warning against using get and set member functions overly
vague, and potentially harmful. There are many, many, instances where
using such functions is perfectly legitimate, and can be done in such a way
as to preserve a meaningful invariant. Too often such general injunctions
become widely accepted in the same way as the misguidance rendered by the
injunction that a preposition is some thing we should not end a sentence
with has.

I agree with you. Too many times I have heard or seen statements such as...

"Getters and setters are evil"

....or other blanket statements regarding them.

I rarely find statements involving the words "evil" or "always" or "never" to
be of value, except of course where they describe constructs that always lead
to undefined or unspecified behavior.

 

[Victor Bazarov]

[...]
The reason I believe such warnings can be potentially harmfull is because
people can and often do accept them uncritically and judge another person's
work accordingly.

This is sheer nonsense. Anything can be potentially harmful. People
do strange things. If you're (or somebody else is) unable to apply
critical thinking to something you (they) read or hear why is somebody
else (especially one who gives the warning) to blame?

What would you prefer, not to hear a warning at all, or have more
information available to you to research the roots of the warning? If
the former, you're not reading the right books. Switch to Schildt.

And just listen to yourself... "Potentially harmful warning". What
a bunch of...

V

 

[Victor Bazarov]

[..]
I rarely find statements involving the words "evil" or "always" or "never" to
be of value, [..]

Would you say that you [almost] *never* find them helpful, or,
rather, that they are [almost] *always* *evil*?

 

[DaKoadMunky]

Would you say that you [almost] *never* find them helpful, or,

rather, that they are [almost] *always* *evil*?

In order for me to answer this question I will need to consult with my
attorney.

Switch to Schildt.

The cheap American beer?

 

[Victor Bazarov]

Would you say that you [almost] *never* find them helpful, or,
rather, that they are [almost] *always* *evil*?

In order for me to answer this question I will need to consult with my
attorney.

Are you invoking the fifth?

The cheap American beer?

Yep. Awful hangover.

 

[E. Robert Tisdale]

I think this kind of thing can be important.
I'm grappling with a tricky situation along these lines
in code I'm currently working on.
I have a set of basis vectors which are members of one class,

Is this class a *container* class?

and which I want to modify as a result of calculations in another class.
The solution of returning a mutable reference to the member bases
makes the modification code much cleaner,
but compromises my ability to guarantee linear independence
as a class invariant.

This sounds suspicious.

The reason I believe such warnings can be potentially harmful
is because people can and often do accept them uncritically
and judge another person's work accordingly.

It sounds to me like you have a flaw in your design.
This is exactly the kind of mistake
that the cited warning is suposed to illuminate
but we can't know that for sure unless you show us the code.

 

[Gary Labowitz]

[...]
The reason I believe such warnings can be potentially harmfull is because
people can and often do accept them uncritically and judge another person's
work accordingly.

This is sheer nonsense. Anything can be potentially harmful. People
do strange things. If you're (or somebody else is) unable to apply
critical thinking to something you (they) read or hear why is somebody
else (especially one who gives the warning) to blame?

What would you prefer, not to hear a warning at all, or have more
information available to you to research the roots of the warning? If
the former, you're not reading the right books. Switch to Schildt.

And just listen to yourself... "Potentially harmful warning". What
a bunch of...

Don't go wild. There are two types of harm, for which the term harmful is
used. Something can be inherently harmful, meaning in correct operation it
does an action that is harmful. Something can be imminently harmful, meaning
that if used incorrectly or by someone for which it is not intended it can
do an action that is harmful. Explosives are inherently harmful, being
dangerous even when used properly by a proper user. An automobile is
imminently harmful, being dangerous when used improperly or by an improper
user.

So can programming advice be inherently harmful (as coming from Schildt) or
imminently harmful (as coming from other than Schildt)? I suggest the
latter.