By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,406 Members | 1,353 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,406 IT Pros & Developers. It's quick & easy.

C++ Guidelines

P: n/a
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
Jul 22 '05
Share this Question
Share on Google+
64 Replies


P: n/a
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
Jul 22 '05 #51

P: n/a
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
Jul 22 '05 #52

P: n/a
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
Jul 22 '05 #53

P: n/a
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
Jul 22 '05 #54

P: n/a
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
Jul 22 '05 #55

P: n/a
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
Jul 22 '05 #56

P: n/a
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
Jul 22 '05 #57

P: n/a
"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
Jul 22 '05 #58

P: n/a
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

Jul 22 '05 #59

P: n/a

"Siemel Naran" <Si*********@REMOVE.att.net> wrote in message
news:Lu******************@bgtnsc05-news.ops.worldnet.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.
Jul 22 '05 #60

P: n/a

"Pete Vidler" <pv*****@mailblocks.com> wrote in message
news:OV************@newsfe1-gui.server.ntli.net...

A suggestion. Functions could easily be longer once you add blank lines and comments. Functions that are pretty straightforward but long, say because they have to read in a lot of input arguments, are fine, it seems to me. As soon as you start to process input arguments and do stuff, that's when the long function should raise a bell.

A related concept is that functions should have few input arguments.


I usually adhere to this one because I find that I make fewer mistakes
if the entire method is immediately available. I'm not sure how this
relates to the number of arguments, but I'll accept that as a suggestion.


Worry about cohesion rather than number of lines. If you worry too much
about number of lines, then you'll start breaking down every 2 lines into
function, and that can make things *less* readable ultimately.
Jul 22 '05 #61

P: n/a
"jeffc" <no****@nowhere.com> wrote in message
news:40********@news1.prserv.net...
"Siemel Naran" <Si*********@REMOVE.att.net> wrote in message

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


You mean like header A.h fails to include B.h though it depends on entities
from B.h. Then the user who includes A.h has to include B.h first then A.h.
Is this what you mean? If so, definitely this is a good rule.

In fact, my cpp files always include the h file as the first non-comment
line. But in windows they have this stdafx.h if you use pre-compiled
headers, and so you shouldn't by accident include B.h in this file.
Jul 22 '05 #62

P: n/a
Pete Vidler wrote:
I am not patting myself on the back. I do not believe it will be obvious
to me. It's just that the book has some /very/ mixed reviews on the
internet, so I need some solid reassurance that it covers the kind of
guidelines that I mentioned earlier before I go out and buy it.

-- Pete

I got to #3, and so far, I'm finding these worth considering. I suggest
reading with your eyes open. #3 threw me for a loop at first.

The Top 20 C++ Tips of All Time
http://www.devx.com/cplus/Article/16328/0/page/1
--
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
Jul 22 '05 #63

P: n/a
Steven T. Hatton wrote:
Pete Vidler wrote:
I am not patting myself on the back. I do not believe it will be obvious
to me. It's just that the book has some /very/ mixed reviews on the
internet, so I need some solid reassurance that it covers the kind of
guidelines that I mentioned earlier before I go out and buy it.

-- Pete I got to #3, and so far, I'm finding these worth considering. I suggest
reading with your eyes open. #3 threw me for a loop at first.


Doh! #2 is the one that tripped me up.
The Top 20 C++ Tips of All Time
http://www.devx.com/cplus/Article/16328/0/page/1


Can I trust #4? I believe I can by virtue of this:
http://www.itga.com.au/~gnb/wp/cd2/
3.6.2 Initialization of non-local objects [basic.start.init]

1 The storage for objects with static storage duration
(_basic.stc.static_) shall be zero-initialized (_dcl.init_) before any
other initialization takes place. Objects of POD types
(_basic.types_) with static storage duration initialized with constant
expressions (_expr.const_) shall be initialized before any dynamic
initialization takes place. Objects of namespace scope with static
storage duration defined in the same translation unit and dynamically
initialized shall be initialized in the order in which their defini-
tion appears in the translation unit. [Note: _dcl.init.aggr_
describes the order in which aggregate members are initialized. The
initialization of local static objects is described in _stmt.dcl_. ]

But I'm not sure if there are any subtelties I need to be aware of.
--
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
Jul 22 '05 #64

P: n/a
Siemel Naran <Si*********@remove.att.net> spoke thus:
In fact, my cpp files always include the h file as the first non-comment
line. But in windows they have this stdafx.h if you use pre-compiled
headers, and so you shouldn't by accident include B.h in this file.


If one writes header files correctly, including header files
accidently causes very minor effects at worst.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Jul 22 '05 #65

64 Replies

This discussion thread is closed

Replies have been disabled for this discussion.