C++ Guidelines

[Claudio Puviani]

Claudio Puviani wrote:
[snip]

Good information is never out of date. Knuth's "Art
of Computer Programming" series was first published
in 1968 and anyone would get shot for calling it out
of date. A discriminating reader can easily filter out
what's still relevant and what isn't. Those who can't
are probably not ready to read the book yet.

Right, but if it almost pre-dates namespaces there is
going to be a lot missing from it -- am I right?
Templates and such?

First of all, it doesn't predate namespaces, much less templates. It's not a
book about individual C++ features. If that's what you're looking for, this
is the wrong book for you. It's about large-scale software design, and the
basic principles can be applied to almost any language.

Knuth's book is somewhat different, the concepts it
addresses are not based on a language that has changed
a great deal over time. It isn't even based on a real
language at all (unless you count a few implementations
by enthusiasts).

Software design is fairly language-independent as well. John Lakos simply
used C++ as an example because it's still the best vehicle for large scale
software development.

EVERY book that proposes guidelines has strange guidelines.
Or at least, we perceive them as being strange because the
author comes from a different background. The thing to
remember is that guidelines are NOT rules and should be
followed only if they make sense in a given context.

[snip]

I have to disagree. I have read many guideline type books (the
"Effective" and "Exceptional" books to name five) that I have
had no disagreements with at all. I don't believe I come from
the same background as the authors.

You're a rare exception. Most people have built up equally valid guidelines
over years of developing in C++, and it's just impossible for every rule in
every book to seemlessly fit into every other system. It's not a criticism
of the authors; just situations that make some recommendations inapplicable
or inconsistent with existing practices.

The truth is that whether or not one appreciates John's style
or agrees with every detail, anyone who hasn't read the book
is a step behind those who have with regard to physical design.

[snip]

That cannot possibly be true. If we haven't read the book we
might still know everything it contains (through other sources)
and not realise it.

That's highly unlikely and slightly pretentious. The best software
developers I know -- and I know some stellar ones -- still learn something
every time they pick up a new book. Anyone who thinks he's too good to learn
something new is just plain delusional.

And for all I know, if I do read it much of its contents might be
obvious to me.

Right. Maybe you should read it instead of patting yourself on the back
prematurely.

Claudio Puviani

 

[Rob Williscroft]

Phlip wrote in in
comp.lang.c++:

The rules for 'protected' roughly mean "anything you could reference
thru 'this' (plus statics)".

So 'delete this' breaks your protection.

It calls D's dtor, since that is the type of *this.

Rob.

 

[Steven T. Hatton]

Claudio Puviani wrote:
[snip]

It has rudimentary design guidelines as well. The formatting section is
just a few pages, and the least interesting at that.

But how rudimentary? I can't possibly buy a book on the off-chance it
might contain what I need (I couldn't afford it). I can't find any
actual reviews of the book, and the only info in the summary suggets the
book is about formatting/naming conventions (useless to me).

Here's a list of books I posted once before that would give you what you
need:

Cool, thanks. I have read most of these, but there are one or two on
that list I haven't seen before.

-- Pete

I never bought that particular book, but I have the Java counterpart. I
assume they are comperable. It's probably not the one book you are looking
for. OTOH, there is something to be said for the relationship between
programming style and design approach. To some extent good style produces
good design by default.

One of the best lessons I ever learned was something someone told me about
how to stack boxes in a warehouse. If there is some obvious pattern
available follow it. Things will simply fall into place. So, you stack
all the boxes so the same face (the picture of the product, for example) is
oriented identically for all boxes. The principle has far reaching
consequence on how smoothely the overall processes work.

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

 

[Steven T. Hatton]

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

Zawinski is known for being a bit off the wall, but he also wrote everything
from the keycaps program, through a good deal of the XEmacs code, and to a
lot of the code in the original Mozilla (aka Netscape). Consider the love
affair between Netscape and Microsoft when you read his review of _Writing
Solid Code_:

http://www.mozillazine.org/resources/recommendations1.html

I haven't read any of the books cover to cover, and cannot provide
assessments of the reviews. It just seemed like a resource worth sharing.

 

[Pete Vidler]

Claudio Puviani wrote:
[snip]

First of all, it doesn't predate namespaces, much less templates. It's not a
book about individual C++ features. If that's what you're looking for, this
is the wrong book for you. It's about large-scale software design, and the
basic principles can be applied to almost any language.

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.

[snip]

Software design is fairly language-independent as well. John Lakos simply
used C++ as an example because it's still the best vehicle for large scale
software development.

I'm not looking for software design info (large scale or otherwise), but
guidelines on using C++ effectively.

[snip]

You're a rare exception. Most people have built up equally valid guidelines
over years of developing in C++, and it's just impossible for every rule in
every book to seemlessly fit into every other system. It's not a criticism
of the authors; just situations that make some recommendations inapplicable
or inconsistent with existing practices.

Fair enough.

[snip]

That's highly unlikely and slightly pretentious. The best software
developers I know -- and I know some stellar ones -- still learn something
every time they pick up a new book. Anyone who thinks he's too good to learn
something new is just plain delusional.

Did I say I thought I was too good to learn something new? Would I have
even sent my original post if I thought that?

I don't care how good someone is at software development, even beginners
could pick up a book and find they already know the info it contains.
It's a distinct possibility with so many books, articles, web pages, etc
covering the same topics.

I'm fairly sure I could read a beginners C++ guide and learn nothing
that I didn't already know. That doesn't mean that I believe this of all
books.

Note that none of this reflects on the book in question. I have not read
it so I cannot possibly say. My purpose in asking these questions about
it was not to insult anyone, or to imply that it is not worth reading --
I am just trying to establish if it meets my needs.

Right. Maybe you should read it instead of patting yourself on the back
prematurely.

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

 

[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][snip]

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

-- Pete

 

[Phlip]

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.

 

[Steven T. Hatton]

Joe Gottman wrote:
[snip][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:stream. 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:stream.

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.

 

[Phlip]

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]

Did you read the C++ FAQ?

That came out wrong.

Did you read the _book_ /C++ FAQs/ by Marshall Cline?

 

[jeffc]

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.

What?

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

 

[jeffc]

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.

 

[Siemel Naran]

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.

 

[Steven T. Hatton]

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

 

[Steven T. Hatton]

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.

 

[Christopher Benson-Manica]

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.