C++ Guidelines

[Steven T. Hatton]

Re: C++ Guidelines

Pete Vidler wrote:
[color=blue]
> 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[/color]
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.
--
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]

Re: C++ Guidelines

Pete Vidler wrote:
[color=blue]
> 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[/color]
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.
--
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

[Pete Vidler]

Re: C++ Guidelines

Claudio Puviani wrote:
[snip][color=blue][color=green]
>>Right, but if it almost pre-dates namespaces there is
>>going to be a lot missing from it -- am I right?
>>Templates and such?[/color]
>
> 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.[/color]

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][color=blue]
> 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.[/color]

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

[snip][color=blue]
> 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.[/color]

Fair enough.

[snip][color=blue][color=green][color=darkred]
>>>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.[/color]
>>
>>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.[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
>>And for all I know, if I do read it much of its contents might be
>>obvious to me.[/color]
>
> Right. Maybe you should read it instead of patting yourself on the back
> prematurely.[/color]

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]

Re: C++ Guidelines

Claudio Puviani wrote:
[snip][color=blue][color=green]
>>Right, but if it almost pre-dates namespaces there is
>>going to be a lot missing from it -- am I right?
>>Templates and such?[/color]
>
> 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.[/color]

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][color=blue]
> 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.[/color]

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

[snip][color=blue]
> 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.[/color]

Fair enough.

[snip][color=blue][color=green][color=darkred]
>>>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.[/color]
>>
>>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.[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
>>And for all I know, if I do read it much of its contents might be
>>obvious to me.[/color]
>
> Right. Maybe you should read it instead of patting yourself on the back
> prematurely.[/color]

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]

Re: C++ Guidelines

Steven T. Hatton wrote:
[snip][color=blue]
> But, I believe you are looking for just about the same kind of resource I
> have been wanting. Have you found a winner yet?[/color]

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]

Re: C++ Guidelines

Steven T. Hatton wrote:
[snip][color=blue]
> But, I believe you are looking for just about the same kind of resource I
> have been wanting. Have you found a winner yet?[/color]

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]

Re: C++ Guidelines

Joe Gottman wrote:
[snip][color=blue][color=green][color=darkred]
>>>- Destructors for base classes should be either virtual or protected.[/color]
>>
>>Never heard of the "protected" one.[/color][/color]
[snip]

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

-- Pete

[Pete Vidler]

Re: C++ Guidelines

Joe Gottman wrote:
[snip][color=blue][color=green][color=darkred]
>>>- Destructors for base classes should be either virtual or protected.[/color]
>>
>>Never heard of the "protected" one.[/color][/color]
[snip]

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

-- Pete

[Steven T. Hatton]

Re: C++ Guidelines

Pete Vidler wrote:
[color=blue]
> Joe Gottman wrote:
> [snip][color=green][color=darkred]
>>>>- Destructors for base classes should be either virtual or protected.
>>>
>>>Never heard of the "protected" one.[/color][/color]
> [snip]
>
> Neither had I, which was /exactly/ why I started this thread. To try and
> find more of these guidelines.
>
> -- Pete[/color]
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]

Re: C++ Guidelines

Pete Vidler wrote:
[color=blue]
> Joe Gottman wrote:
> [snip][color=green][color=darkred]
>>>>- Destructors for base classes should be either virtual or protected.
>>>
>>>Never heard of the "protected" one.[/color][/color]
> [snip]
>
> Neither had I, which was /exactly/ why I started this thread. To try and
> find more of these guidelines.
>
> -- Pete[/color]
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]

Re: C++ Guidelines

Pete Vidler wrote:
[color=blue]
> 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.[/color]

This thread has revolved around such books.
[color=blue]
> I'm not looking for software design info (large scale or otherwise), but
> guidelines on using C++ effectively.[/color]

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?TestFirstUserInterfaces

[Phlip]

Re: C++ Guidelines

Pete Vidler wrote:
[color=blue]
> 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.[/color]

This thread has revolved around such books.
[color=blue]
> I'm not looking for software design info (large scale or otherwise), but
> guidelines on using C++ effectively.[/color]

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?TestFirstUserInterfaces

[Phlip]

Re: C++ Guidelines

"Pete Vidler wrote:
[color=blue][color=green][color=darkred]
> >>Never heard of the "protected" one.[/color][/color][/color]
[color=blue]
> Neither had I, which was /exactly/ why I started this thread. To try and
> find more of these guidelines.[/color]

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?TestFirstUserInterfaces

[Phlip]

Re: C++ Guidelines

Phlip wrote:
[color=blue]
> "Pete Vidler wrote:
>[color=green][color=darkred]
> > >>Never heard of the "protected" one.[/color][/color]
>[color=green]
> > Neither had I, which was /exactly/ why I started this thread. To try and
> > find more of these guidelines.[/color]
>
> Did you read the C++ FAQ?[/color]

That came out wrong.

Did you read the _book_ /C++ FAQs/ by Marshall Cline?
[color=blue]
> You have read enough to start coding. If you only do the intersection -[/color]
not[color=blue]
> the union - of those books' recommendations , you will have a sufficiently
> narrow sane subset.
>
> --
> Phlip
> http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces
>
>[/color]

[jeffc]

Re: C++ Guidelines


"Siemel Naran" <SiemelNaran@RE MOVE.att.net> wrote in message
news:LuYdc.5380 $K_.168425@bgtn sc05-news.ops.worldn et.att.net...[color=blue]
>[color=green]
> > - Non-leaf classes should be abstract (have pure virtual methods), from
> > More Effective C++, Item 33.[/color]
>
> A suggestion. Sometimes we want a reasonable default behavior which[/color]
clients[color=blue]
> 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.[/color]

Agreed. I don't like that "guideline" very much.
[color=blue][color=green]
> > - Header files should be self contained, from various sources.[/color]
>
> What?[/color]

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