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

S

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
 
M

Mike Wahler

Stuart Gerchick said:
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

If I were capable of predicting the future, I'd be heading
for Las Vegas or Wall Street. And I can't give an opinion
about the literature itself, since I haven't seen it. However
I suspect it will be of value to many, based upon the reputations
of Herb & Andrei.

-Mike
 
H

Herb Sutter

C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
Herb Sutter, Andrei Alexandrescu is now a month or so away from
release.

In North America, it should be available in bookstores around now. Andrei
and I got our first copies a week ago, and it was available for sale at
OOPSLA. I haven't looked at my local Barnes & Noble or Borders yet.

More at http://pluralsight.com/blogs/hsutter/archive/2004/10/07/2709.aspx
...

Herb

---
Herb Sutter (www.gotw.ca) (www.pluralsight.com/blogs/hsutter)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
Architect, Developer Division, Microsoft (www.gotw.ca/microsoft)
 
A

apm

(e-mail address removed) (Stuart Gerchick) wrote in message
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

Judging from the table of contents, it looks good. It seems to sum up
several pearls of wisdom from sources such as Meyers I, II, III and
GoTW. It looks like it is going to avoid the more contravesial
style-oriented guidelines, and so to me, does not appear to be like
other coding guidelines. I think it is more tutorial in nature and
thus may not be suitable for use by QA during code review. But who
knows, until it is actually published?

Regards,

Andrew Marlow
 
S

Stuart Gerchick

Herb Sutter said:
In North America, it should be available in bookstores around now. Andrei
and I got our first copies a week ago, and it was available for sale at
OOPSLA. I haven't looked at my local Barnes & Noble or Borders yet.

More at http://pluralsight.com/blogs/hsutter/archive/2004/10/07/2709.aspx
..

Herb

I didn't expect Herb Sutter himself to respond to this posting. I am
eagerly awaiting it actually and cant wait to have it in my hands.
Unfortunately, I am in the UK most of the time these days, and will
have to wait a bit for the release. I have it on order and it should
arrive soon.

Thank for for your time Herb. I appreciate it
 
S

Stephen Howe

What is people's opinion on this...is it going to be a seminal work or
lackluster

With the book not released, how are we supposed to judge? And what do
people's opinions matter, at all, with so little to go on?

Stephen Howe
 
K

kanze

(e-mail address removed) (Stuart Gerchick) wrote in message
C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
Herb Sutter, Andrei Alexandrescu is now a month or so away from
release.

At least some of the people I know have seen actual copies of the
printed book. (On the other hand, Amazon says "not yet been released".)
What is people's opinion on this...is it going to be a seminal work or
lackluster

How can anyone tell if they've not actually seen the book. And I'm not
quite sure what you mean by "seminal" -- I wouldn't have considered it
an antonym for lackluster. Given the authors, I expect lots of useful
information, and a readable style. Given the authors, I also expect
some information "just for fun", and some information which won't be
immediately usable because compilers and/or collegues who have to read
and understand the code aren't up to date. On the other hand, by
"seminal", I understand something that will change the way we think
about the language -- a priori, I don't expect either author to present
new ideas that they haven't already discussed here, for example. (In
the industry, from a pratical point of view, "seminal" often means,
"interesting, but not usable in the next ten years". While some of
Andrei's work might fall into that category -- especially if you have
difficulty getting updates for your collegues:), for the most part, I
expect that most of the information in the book will be immediately
usable.)
 
S

Stuart Gerchick

Stephen Howe said:
lackluster

With the book not released, how are we supposed to judge? And what do
people's opinions matter, at all, with so little to go on?

Stephen Howe

As Herb Sutter said above it was available for sale at OOPSLA. People
have now seen it. The kinds of people who are on comp.lang.c++
 
M

ma740988

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


I approach it from the standpoint that book (my copy showed up
yesterday) - as the title says - is a collection of 'best practices'.

Paragraph 3, page xiii states

" The coding standards introduced by this book are collection of
guidelines for writing high-quality C++ code. They are distilled
conclusions of a rich collective experience of the C++ community.
Much of this body of knowledge has only been available in bits and
pieces spread throughout books, or as word-of-mouth wisdom. This
book's intent is to collect that knowledge into a collection of rules
that is terse, justified, and easy to understand and follow".

The key IMO starts here "This book's intenet .. follow".

Here's one that I'm still confused - if you will - on what constitutes
the ideal implementation approach.

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.

My 2cents for what it's worth.
 
F

Frank Birbacher

Hi!

Stuart said:
People
have now seen it. The kinds of people who are on comp.lang.c++

There are also European people on this newsgroup, like me. And
they don't have the book yet.

Frank
 
P

Phlip

ma740988 said:
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.
 
S

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
 
P

Phlip

Steven said:
Phlip wrote:

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

Steven T. Hatton

Phlip said:
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.
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(const 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
 
P

Phlip

Steven said:
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.
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".
 
S

Steven T. Hatton

Phlip said:
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
 
O

osmium

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

Phlip

Steven said:
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".
 
S

Steven T. Hatton

Phlip said:
Using getters and setters indicates a probable design flaw.

In your unsubstantiated opinion.
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top