C++ Coding Standards : 101 Rules, Guidelines, and Best Practices

[Stuart Gerchick]

C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
Herb Sutter, Andrei Alexandrescu is now a month or so away from
release. What is people's opinion on this...is it going to be a
seminal work or lackluster

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Phlip]

ma740988 wrote:

42 per the text. Dont give away your internals

Accessor and mutator as I understand it are - for the most part -
design flaws.
The example in the text shows a GetBuffer member function returing a
char*
In any event, when data needs to be shared among classes this
accessor/mutator beats the alternative (public member data) so I've
never quite understood this one.
A host of get and sets - I suspect - are signs of poor design. I'd
still like to see a concrete example that shows the solution.

OO design is about behavior. Classes should tell others what to do. If a
class takes data out of another, manipulates it, and puts it back in, then
the behavior is in the wrong class.

If you indeed share data, then this "data transfer object" should be a
separate thing, without any behavior, and the classes should pass it around.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Steven T. Hatton]

Phlip wrote:

OO design is about behavior. Classes should tell others what to do. If a
class takes data out of another, manipulates it, and puts it back in, then
the behavior is in the wrong class.
I don't know how widely shared that opinion is. One view of OOP is
expressed in Roman Mäder's _Computer Science With Mathematica_ as follows:
"An object is, therefore, a collection of data elements together with the
functions operating on them."
If you indeed share data, then this "data transfer object" should be a
separate thing, without any behavior, and the classes should pass it
around.

So, for example, and int should have a wrapper class called Integer?
--
"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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Phlip]

Steven T. Hatton wrote:

Phlip wrote:

OO design is about behavior. Classes should tell others what to do. If a
class takes data out of another, manipulates it, and puts it back in, then the behavior is in the wrong class.

I don't know how widely shared that opinion is. One view of OOP is
expressed in Roman Mäder's _Computer Science With Mathematica_ as follows:
"An object is, therefore, a collection of data elements together with the
functions operating on them."

Designing a program means organizing the relations between its structure in
memory and their behavior in time.

OO design is about partitioning that behavior with polymorphism.

I am aware that the entry-level tutorials describe objects as data and the
functions that operate on them. You can also find tutorials that say "OO
objects are like real-world objects".

If you indeed share data, then this "data transfer object" should be a
separate thing, without any behavior, and the classes should pass it
around.

So, for example, and int should have a wrapper class called Integer?

Why?

It's the same question as before - what is an int's behavior? If it has only
a little, then it's a "value object", and unbeholden to any one class.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Steven T. Hatton]

Phlip wrote:

Steven T. Hatton wrote:

Phlip wrote:

> OO design is about behavior. Classes should tell others what to do. If
> a class takes data out of another, manipulates it, and puts it back in, then > the behavior is in the wrong class.

I don't know how widely shared that opinion is. One view of OOP is
expressed in Roman Mäder's _Computer Science With Mathematica_ as
follows: "An object is, therefore, a collection of data elements together
with the functions operating on them."

Designing a program means organizing the relations between its structure
in memory and their behavior in time.

OO design is about partitioning that behavior with polymorphism.

Not all classes exhibit polymorphism. How do the so-called concrete classes
fit into your model?
I am aware that the entry-level tutorials describe objects as data and the
functions that operate on them. You can also find tutorials that say "OO
objects are like real-world objects".

What I quoted from is a textbook used at ETH in Zrich. Perhaps you've heard
of the University? It's where Einstein got his degree in Physics.

> If you indeed share data, then this "data transfer object" should be a
> separate thing, without any behavior, and the classes should pass it
> around.

So, for example, and int should have a wrapper class called Integer?

Why?

It's the same question as before - what is an int's behavior? If it has
only a little, then it's a "value object", and unbeholden to any one
class.

I guess I'm confused about what you mean by shared data. Using set and get
methods is not typically considered sharing data. If I have a class called
Arrow which has different properties such as color, length, position,
rotation, etc., how am I supposed to manipulate objects of that class in
order to change these properties? Am I expected not to be interested in
the current value of these objects at runtime? If I am interested in
observing these values, then how am I expected to access them without 'get'
methods?

If I understand the opinion that I should not use set and get methods, it
means I should not have code such as that shown below. Is that what you
are trying to suggest?

class Light{
//...
virtual const array<GLfloat,4 >& ambient() const {return _ambient; }

virtual void ambient(const array<GLfloat,4 >& ambient_)
{
_ambient = ambient_;
}
virtual const array<GLfloat,4 >& diffuse() const {return _diffuse; }

virtual void diffuse(const array<GLfloat,4 >& diffuse_)
{
_diffuse = diffuse_;
}
virtual const array<GLfloat,4 >& specular() const {return _specular; }

virtual void specular(const array<GLfloat,4 >& specular_)
{
_specular = specular_;
}
virtual const array<GLfloat,4 >& ambientModel() const
{
return _ambientModel;
}

virtual void ambientModel(co nst array<GLfloat,4 >& ambientModel_)
{
_ambientModel = ambientModel_;
}

virtual GLenum light() const {return _light; }

virtual void light(GLenum light_)
{
_light = light_;
}
protected:
array<GLfloat,4 > _position;
array<GLfloat,4 > _ambient;
array<GLfloat,4 > _diffuse;
array<GLfloat,4 > _specular;

array<GLfloat,4 > _ambientModel;

GLenum _light;
};

--
"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

[Phlip]

Steven T. Hatton wrote:

Designing a program means organizing the relations between its structure
in memory and their behavior in time.

OO design is about partitioning that behavior with polymorphism.
Not all classes exhibit polymorphism. How do the so-called concrete

classes fit into your model?
Another aspect of design is how easily it can change. Most methods should
not be virtual, and most re-use should be delegated, not inherited.

I am aware that the entry-level tutorials describe objects as data and the functions that operate on them. You can also find tutorials that say "OO
objects are like real-world objects".

What I quoted from is a textbook used at ETH in Zrich. Perhaps you've

heard of the University? It's where Einstein got his degree in Physics.
I'm sitting on the same landmass as Cal Tech. Perhaps you have heard of Cal
Tech? It's where they invented something that I decline to look up with
Google.

I could let your fallacy of "appeal to authority" slide, except you seem to
think you are arguing with me about something. I'm not sure what.

The point: Classes should minimize getters and setters, because they should
expose access to behaviors.
I guess I'm confused about what you mean by shared data. Using set and get methods is not typically considered sharing data. If I have a class called Arrow which has different properties such as color, length, position,
rotation, etc., how am I supposed to manipulate objects of that class in
order to change these properties? Am I expected not to be interested in
the current value of these objects at runtime? If I am interested in
observing these values, then how am I expected to access them without 'get' methods?

Okay, I'm going to make a great effort to agree with you here, but I need
you to know that before I start, because I'm trying to avoid one of /those/
threads...

Consider this graphic:

A -> B

The "behavior" of -> is that it points at B. However, if we move B...

A ->
B

....then -> no longer points at B. Let's call that behavior "extrinsic" .

->'s intrinsic behavior is its tail is there and its head is here, etc. Set
these behaviors with setters.

Limit your application's access to those setters. A class aware of A -> B
could respond to high-level commands that move B by fixing the extrinsic
behavior of the arrow. However, that AB class should not make its awareness
of -> public. The buck stops here.

Encapsulation is hierarchical. The rule "Don't make primitive things
globally public" is more useful than the rule "don't make data members
public".

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Steven T. Hatton]

Phlip wrote:

Steven T. Hatton wrote:

Not all classes exhibit polymorphism. How do the so-called concrete classes

fit into your model?

Another aspect of design is how easily it can change. Most methods should
not be virtual, and most re-use should be delegated, not inherited.

That really depends on what you are designing. IMO, if you make one member
function virtual, you should have a good reason /not/ to make the remainder
virtual. I'll follow Stroustrup's convention of reserving the term
"method" for pure virtual member functions.
I could let your fallacy of "appeal to authority" slide, except you seem
to think you are arguing with me about something. I'm not sure what.
There is no fallacy in appeal to authority when the subject is one of widely
help opinions in a field. The opinions of authorities in the field
constitute the topic.
The point: Classes should minimize getters and setters, because they
should expose access to behaviors.
The fundamental concept of object oriented programming is the idea of data
objects combined with associated operators.
Okay, I'm going to make a great effort to agree with you here, but I need
you to know that before I start, because I'm trying to avoid one of
/those/ threads...

Consider this graphic:

A -> B

The "behavior" of -> is that it points at B. However, if we move B...

A ->
B

...then -> no longer points at B. Let's call that behavior "extrinsic" .

->'s intrinsic behavior is its tail is there and its head is here, etc.
Set these behaviors with setters.

Limit your application's access to those setters. A class aware of A -> B
could respond to high-level commands that move B by fixing the extrinsic
behavior of the arrow. However, that AB class should not make its
awareness of -> public. The buck stops here.

Encapsulation is hierarchical. The rule "Don't make primitive things
globally public" is more useful than the rule "don't make data members
public".

This seems like a far weaker statement than the idea that using set and get
methods indicated a probable design flaw. That was, IIRC, the point at
which this thread forked. Stroustrup makes a similar assertion in
TC++PL(SE) regarding set and get methods. I have questioned that in this
newsgroup, and I have never been convinced of the merits of the general
guideline. Perhaps a better statement might be 'Be judicious in what you
expose through accessor methods'. That I can agree with.
--
"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

[osmium]

Someone wrote:

Accessor and mutator as I understand it are - for the most part -
design flaws.
The example in the text shows a GetBuffer member function returing a
char*
In any event, when data needs to be shared among classes this
accessor/mutator beats the alternative (public member data) so I've
never quite understood this one.
A host of get and sets - I suspect - are signs of poor design. I'd
still like to see a concrete example that shows the solution.

You are asking for a concrete solution to an unexpressed problem. Remember
we can't see what you are looking at in a book.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Phlip]

Steven T. Hatton wrote:

This seems like a far weaker statement than the idea that using set and get methods indicated a probable design flaw.
Using getters and setters indicates a probable design flaw.
That was, IIRC, the point at
which this thread forked. Stroustrup makes a similar assertion in
TC++PL(SE) regarding set and get methods. I have questioned that in this
newsgroup, and I have never been convinced of the merits of the general
guideline. Perhaps a better statement might be 'Be judicious in what you
expose through accessor methods'. That I can agree with.

Encapsulation is hierarchical. The root principle of OO is encapsulation of
indirection. Without polymorphism there is no OO. (Regardless of whether a
given program happens to use virtuals.)

"Data objects with the methods that operate on them" is just "object based".

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Steven T. Hatton]

Phlip wrote:

Steven T. Hatton wrote:

This seems like a far weaker statement than the idea that using set and

get

methods indicated a probable design flaw.

Using getters and setters indicates a probable design flaw.

In your unsubstantiated opinion.

That was, IIRC, the point at
which this thread forked. Stroustrup makes a similar assertion in
TC++PL(SE) regarding set and get methods. I have questioned that in this
newsgroup, and I have never been convinced of the merits of the general
guideline. Perhaps a better statement might be 'Be judicious in what you
expose through accessor methods'. That I can agree with.

Encapsulation is hierarchical. The root principle of OO is encapsulation
of indirection. Without polymorphism there is no OO. (Regardless of
whether a given program happens to use virtuals.)

"Data objects with the methods that operate on them" is just "object
based".

My reason for saying the fundamental concept of object oriented programming
is the idea of data objects combined with associated operators, is based on
a comment in Ole-Johan Dahl's The *Birth of Object Orientation: the Simula
Languages*:

"... The example shows that the idea of data objects with associated
operators was under way already in 1965."

That seems to be the watershed in his mind as to when OOP first appeared. I
will note that he subsequently adds:

"There is universal use of the term "object orientation", OO. Although no
standard definition exists, some or all of the above ideas enter into the
OO paradigm of system development."

You are free to continue making absolute assertions such as "OO design is
about behavior", but please don't expect such statements to be taken too
seriously by experience computer professionals.

--
"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

[Phlip]

Steven T. Hatton wrote:

Phlip wrote:

Using getters and setters indicates a probable design flaw.

In your unsubstantiated opinion.

I stopped reading here.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces