C++ Guidelines

[Pete Vidler]

Hi Folks,

I'm wondering if there is a compilation of C++ guidelines out there
anywhere. Here are some of the ones I've picked up so far (as examples):

- Functions should fit on one screen, from various sources.

- Non-leaf classes should be abstract (have pure virtual methods), from
More Effective C++, Item 33.

- Virtual methods should be private by default and protected if they
need access to a base classes version (except for the destructor, of
course), from http://www.gotw.ca/publications/mill18.htm.

- Header files should be self contained, from various sources.

- Destructors for base classes should be either virtual or protected.

I think I've probably missed (or never heard of) quite a few more.
Anyone know where I can find such things? Or have some guidelines of
their own to share?

-- Pete

[Pete Vidler]

Steven T. Hatton wrote:
[snip]

But, I believe you are looking for just about the same kind of resource I
have been wanting. Have you found a winner yet?

Of the books I have read so far, the following have been extremely useful:

Effective C++
More Effective C++
Effective STL
Exceptional C++
More Exceptional C++

.... not exactly guideline books, but still good: TC++PL, Design
Patterns, Modern C++ Design, etc.

And the articles at www.gotw.ca are good. Also, there are many good
articles at www.cuj.com (if you dig around the archives).

Other than that I have found very little.

-- Pete

[Pete Vidler]

Joe Gottman wrote:
[snip]

- Destructors for base classes should be either virtual or protected.

Never heard of the "protected" one.

[snip]

Neither had I, which was /exactly/ why I started this thread. To try and
find more of these guidelines.

-- Pete

[Pete Vidler]

Joe Gottman wrote:
[snip]

- Destructors for base classes should be either virtual or protected.

Never heard of the "protected" one.

[snip]

Neither had I, which was /exactly/ why I started this thread. To try and
find more of these guidelines.

-- Pete

[Steven T. Hatton]

Pete Vidler wrote:

Joe Gottman wrote:
[snip]

- Destructors for base classes should be either virtual or protected.

Never heard of the "protected" one.

[snip]

Neither had I, which was /exactly/ why I started this thread. To try and
find more of these guidelines.

-- Pete

Here's one I tend to use in Java, and believe it applies to C++ as well. In
C++ terms it would be use /out/ not /std::cout/. That is, create a
variable /out/ of type std::ostream. Do this, say in the parameter list of
a function. Then when you call the function you pass std::cout, or some
other instance of std::ostream.

Unfortunately, I am not familiar enough with the STL <iostream> to know
exactly what level of abstraction to use. E.g., there is a distinction
between std::cout, and std::wcout.

The same also applies to input streams.

The idea is to write code that doesn't care what it's writing to/reading
from, just so long as it has a stream. This is handy, for example, when
you write code that can be run from the commandline and dumps to console,
or can be run from a web server and writes to the network.

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Steven T. Hatton]

Pete Vidler wrote:

Joe Gottman wrote:
[snip]

- Destructors for base classes should be either virtual or protected.

Never heard of the "protected" one.

[snip]

Neither had I, which was /exactly/ why I started this thread. To try and
find more of these guidelines.

-- Pete

Here's one I tend to use in Java, and believe it applies to C++ as well. In
C++ terms it would be use /out/ not /std::cout/. That is, create a
variable /out/ of type std::ostream. Do this, say in the parameter list of
a function. Then when you call the function you pass std::cout, or some
other instance of std::ostream.

Unfortunately, I am not familiar enough with the STL <iostream> to know
exactly what level of abstraction to use. E.g., there is a distinction
between std::cout, and std::wcout.

The same also applies to input streams.

The idea is to write code that doesn't care what it's writing to/reading
from, just so long as it has a stream. This is handy, for example, when
you write code that can be run from the commandline and dumps to console,
or can be run from a web server and writes to the network.

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Phlip]

Pete Vidler wrote:

What I am looking for is what I posted originally -- guidelines similar
to the ones I posted. I'm not looking for a book describing individual
C++ features, but rather a book describing (the authors) best practices
in /using/ them.
This thread has revolved around such books.
I'm not looking for software design info (large scale or otherwise), but
guidelines on using C++ effectively.

You are having reading comprehension issues. Lakos' book is about physical
construction - the do's and don't's of implementation. Its forward expressly
states it is not about "design" in the abstract.

Stop complaining about everyone's quite valid recommendations .

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Phlip]

Pete Vidler wrote:

What I am looking for is what I posted originally -- guidelines similar
to the ones I posted. I'm not looking for a book describing individual
C++ features, but rather a book describing (the authors) best practices
in /using/ them.
This thread has revolved around such books.
I'm not looking for software design info (large scale or otherwise), but
guidelines on using C++ effectively.

You are having reading comprehension issues. Lakos' book is about physical
construction - the do's and don't's of implementation. Its forward expressly
states it is not about "design" in the abstract.

Stop complaining about everyone's quite valid recommendations .

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Phlip]

"Pete Vidler wrote:

Never heard of the "protected" one.

Neither had I, which was /exactly/ why I started this thread. To try and
find more of these guidelines.

Did you read the C++ FAQ?

You have read enough to start coding. If you only do the intersection - not
the union - of those books' recommendations , you will have a sufficiently
narrow sane subset.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Phlip]

Phlip wrote:

"Pete Vidler wrote:

>Never heard of the "protected" one.

Neither had I, which was /exactly/ why I started this thread. To try and
find more of these guidelines.

Did you read the C++ FAQ?

That came out wrong.

Did you read the _book_ /C++ FAQs/ by Marshall Cline?
You have read enough to start coding. If you only do the intersection - not the union - of those books' recommendations , you will have a sufficiently
narrow sane subset.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[jeffc]

"Siemel Naran" <Si*********@RE MOVE.att.net> wrote in message
news:Lu******** **********@bgtn sc05-news.ops.worldn et.att.net...

- Non-leaf classes should be abstract (have pure virtual methods), from
More Effective C++, Item 33.
A suggestion. Sometimes we want a reasonable default behavior which

clients can then override. Requring the above as a guideline imposes too much
design burden on the project and could cause it to run out of budget.

Agreed. I don't like that "guideline" very much.

- Header files should be self contained, from various sources.

What?

Makes sense to me, and I wholeheartedly agree. Nothing worse than
unnecessary dependencies in header files.