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 64  3289 
Pete Vidler <pv*****@mailblocks.com> wrote: 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?
Check out these two books:
"Large-Scale C++ Software Design" by John Lakos
"Object-Oriented Design Heuristics" by Arthur J. Riel
This site may also be helpful:
<http://www.chris-lott.org/resources/cstyle/>
Pete Vidler <pv*****@mailblocks.com> wrote: 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?
Check out these two books:
"Large-Scale C++ Software Design" by John Lakos
"Object-Oriented Design Heuristics" by Arthur J. Riel
This site may also be helpful:
<http://www.chris-lott.org/resources/cstyle/>
Pete Vidler wrote: 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.
Functions should have 1 to 5 activities. In higher level languages this
translates to 1 to 5 statements, but C++ requires a lot of rigging and
piping.
- Non-leaf classes should be abstract (have pure virtual methods), from
More Effective C++, Item 33.
The corpus of Addison Wesley [Longman]'s C++ and theory books form the
pinacle of known style. Try /Design Patterns/, /Large Scale C++ Software
Design/, and /Refactoring/.
- 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.
Also try /Exceptional C++/, by Herb Sutter.
- Header files should be self contained, from various sources.
The implication here is you can always add a new #include "thing.h", and it
takes care of itself. You never need to add another #include above it.
/Large Scale/ covers this in great detail.
- Destructors for base classes should be either virtual or protected.
Never heard of the "protected" one.
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?
These guidelines occupy a spectrum. At one end, we have requirements that
C++'s minimal expression enforces. Thou shalt make all destructors virtual
unless profiling reveals the need to remove a class's 'vtable'. At the other
end we have team specific patterns and behaviors. For example, one team may
adopt STL for all collection classes, and another may have an alternative
library, hence should not use STL. But we should recommend STL when writing
books for AW.
--
Phlip http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces
Pete Vidler wrote: 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.
Functions should have 1 to 5 activities. In higher level languages this
translates to 1 to 5 statements, but C++ requires a lot of rigging and
piping.
- Non-leaf classes should be abstract (have pure virtual methods), from
More Effective C++, Item 33.
The corpus of Addison Wesley [Longman]'s C++ and theory books form the
pinacle of known style. Try /Design Patterns/, /Large Scale C++ Software
Design/, and /Refactoring/.
- 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.
Also try /Exceptional C++/, by Herb Sutter.
- Header files should be self contained, from various sources.
The implication here is you can always add a new #include "thing.h", and it
takes care of itself. You never need to add another #include above it.
/Large Scale/ covers this in great detail.
- Destructors for base classes should be either virtual or protected.
Never heard of the "protected" one.
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?
These guidelines occupy a spectrum. At one end, we have requirements that
C++'s minimal expression enforces. Thou shalt make all destructors virtual
unless profiling reveals the need to remove a class's 'vtable'. At the other
end we have team specific patterns and behaviors. For example, one team may
adopt STL for all collection classes, and another may have an alternative
library, hence should not use STL. But we should recommend STL when writing
books for AW.
--
Phlip http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces
Daniel T. wrote:
[snip] Check out these two books:
"Large-Scale C++ Software Design" by John Lakos
I've heard of this one, but isn't it seriously out of date? I've also
heard that he has some strange guidelines like not using namespaces?
"Object-Oriented Design Heuristics" by Arthur J. Riel
I'll look into it, thanks.
This site may also be helpful:
<http://www.chris-lott.org/resources/cstyle/>
Most of the links there appear to be documents detailing naming
conventions and recommending a given style for the placement of braces.
I'm looking for more along the lines of design guidelines like I posted
(there was one good page there though, thanks).
I don't really need the basic stuff (I know most of them), but I am
looking for more advanced guidelines (with justifications, like the one
about making virtual methods private).
Thanks,
-- Pete
Daniel T. wrote:
[snip] Check out these two books:
"Large-Scale C++ Software Design" by John Lakos
I've heard of this one, but isn't it seriously out of date? I've also
heard that he has some strange guidelines like not using namespaces?
"Object-Oriented Design Heuristics" by Arthur J. Riel
I'll look into it, thanks.
This site may also be helpful:
<http://www.chris-lott.org/resources/cstyle/>
Most of the links there appear to be documents detailing naming
conventions and recommending a given style for the placement of braces.
I'm looking for more along the lines of design guidelines like I posted
(there was one good page there though, thanks).
I don't really need the basic stuff (I know most of them), but I am
looking for more advanced guidelines (with justifications, like the one
about making virtual methods private).
Thanks,
-- Pete
"Pete Vidler" <pv*****@mailblocks.com> wrote I'm wondering if there is a compilation of C++ guidelines out there
anywhere.
http://search.barnesandnoble.com/boo...sbn=0521893089
It's basically an extension of what used to be Rogue Wave's guidelines. No
one will agree with every guideline, but they're mostly reasonable.
Here are some of the ones I've picked up so far (as examples):
- Functions should fit on one screen, from various sources.
That's really a side-effect of a few more fundamental principles, such as
"maximize cohesion" and "modularize where reasonable." A function that is
very large should raise flags, but there are rare instances where it's
entirely justified to have even extremely large functions (as anyone who's
ever used YACC will testify).
- Header files should be self contained, from various sources.
This one should be shredded or rephrased. Header files have dependencies
just like any other software component, and so can rarely be self-contained.
Claudio Puviani
"Pete Vidler" <pv*****@mailblocks.com> wrote I'm wondering if there is a compilation of C++ guidelines out there
anywhere.
http://search.barnesandnoble.com/boo...sbn=0521893089
It's basically an extension of what used to be Rogue Wave's guidelines. No
one will agree with every guideline, but they're mostly reasonable.
Here are some of the ones I've picked up so far (as examples):
- Functions should fit on one screen, from various sources.
That's really a side-effect of a few more fundamental principles, such as
"maximize cohesion" and "modularize where reasonable." A function that is
very large should raise flags, but there are rare instances where it's
entirely justified to have even extremely large functions (as anyone who's
ever used YACC will testify).
- Header files should be self contained, from various sources.
This one should be shredded or rephrased. Header files have dependencies
just like any other software component, and so can rarely be self-contained.
Claudio Puviani
Claudio Puviani wrote:
[snip] http://search.barnesandnoble.com/boo...sbn=0521893089
It's basically an extension of what used to be Rogue Wave's guidelines. No
one will agree with every guideline, but they're mostly reasonable.
Interesting.. but the summary says it deals with formatting, naming,
documentation, etc. I was looking for design guidelines along the lines
of those that I posted. Am I correct in assuming it doesn't cover such
issues? - Functions should fit on one screen, from various sources.
That's really a side-effect of a few more fundamental principles, such as
"maximize cohesion" and "modularize where reasonable." A function that is
very large should raise flags, but there are rare instances where it's
entirely justified to have even extremely large functions (as anyone who's
ever used YACC will testify).
Yes that example was more basic than I really wanted. Ignore it, I'm far
more interested in guidelines similar to the others that I posted. - Header files should be self contained, from various sources.
This one should be shredded or rephrased. Header files have dependencies
just like any other software component, and so can rarely be self-contained.
[snip]
Obviously if a header file is from a library then the library must be
linked to. I meant from a compiler point of view.
More specifically that it should forward declare or #include everything
it requires to compile. I'm fairly sure most people would understand
this from "self contained", but I suppose I should have been more precise.
-- Pete
Claudio Puviani wrote:
[snip] http://search.barnesandnoble.com/boo...sbn=0521893089
It's basically an extension of what used to be Rogue Wave's guidelines. No
one will agree with every guideline, but they're mostly reasonable.
Interesting.. but the summary says it deals with formatting, naming,
documentation, etc. I was looking for design guidelines along the lines
of those that I posted. Am I correct in assuming it doesn't cover such
issues? - Functions should fit on one screen, from various sources.
That's really a side-effect of a few more fundamental principles, such as
"maximize cohesion" and "modularize where reasonable." A function that is
very large should raise flags, but there are rare instances where it's
entirely justified to have even extremely large functions (as anyone who's
ever used YACC will testify).
Yes that example was more basic than I really wanted. Ignore it, I'm far
more interested in guidelines similar to the others that I posted. - Header files should be self contained, from various sources.
This one should be shredded or rephrased. Header files have dependencies
just like any other software component, and so can rarely be self-contained.
[snip]
Obviously if a header file is from a library then the library must be
linked to. I meant from a compiler point of view.
More specifically that it should forward declare or #include everything
it requires to compile. I'm fairly sure most people would understand
this from "self contained", but I suppose I should have been more precise.
-- Pete
On Sat, 10 Apr 2004 16:16:23 +0100 in comp.lang.c++, Pete Vidler
<pv*****@mailblocks.com> wrote, This site may also be helpful:
<http://www.chris-lott.org/resources/cstyle/>
Most of the links there appear to be documents detailing naming
conventions and recommending a given style for the placement of braces.
I'm looking for more along the lines of design guidelines like I posted
Well, arguing over the placement of braces has less potential for harm
than many of the design guidelines I have seen.
On Sat, 10 Apr 2004 16:16:23 +0100 in comp.lang.c++, Pete Vidler
<pv*****@mailblocks.com> wrote, This site may also be helpful:
<http://www.chris-lott.org/resources/cstyle/>
Most of the links there appear to be documents detailing naming
conventions and recommending a given style for the placement of braces.
I'm looking for more along the lines of design guidelines like I posted
Well, arguing over the placement of braces has less potential for harm
than many of the design guidelines I have seen.
David Harmon wrote:
[snip] Well, arguing over the placement of braces has less potential for harm
than many of the design guidelines I have seen.
Yes, but there's no potential for learning anything with
brace-placement. You can already see the possibilities.
-- Pete
David Harmon wrote:
[snip] Well, arguing over the placement of braces has less potential for harm
than many of the design guidelines I have seen.
Yes, but there's no potential for learning anything with
brace-placement. You can already see the possibilities.
-- Pete
Pete Vidler <pv*****@mailblocks.com> wrote: Daniel T. wrote:
[snip] Check out these two books:
"Large-Scale C++ Software Design" by John Lakos
I've heard of this one, but isn't it seriously out of date? I've also
heard that he has some strange guidelines like not using namespaces?
"Object-Oriented Design Heuristics" by Arthur J. Riel
I'll look into it, thanks.
This site may also be helpful:
<http://www.chris-lott.org/resources/cstyle/>
Most of the links there appear to be documents detailing naming
conventions and recommending a given style for the placement of braces.
I'm looking for more along the lines of design guidelines like I posted
(there was one good page there though, thanks).
I don't really need the basic stuff (I know most of them), but I am
looking for more advanced guidelines (with justifications, like the one
about making virtual methods private).
Try the articles at this site:
< http://tinyurl.com/2tt4h >
Pete Vidler <pv*****@mailblocks.com> wrote: Daniel T. wrote:
[snip] Check out these two books:
"Large-Scale C++ Software Design" by John Lakos
I've heard of this one, but isn't it seriously out of date? I've also
heard that he has some strange guidelines like not using namespaces?
"Object-Oriented Design Heuristics" by Arthur J. Riel
I'll look into it, thanks.
This site may also be helpful:
<http://www.chris-lott.org/resources/cstyle/>
Most of the links there appear to be documents detailing naming
conventions and recommending a given style for the placement of braces.
I'm looking for more along the lines of design guidelines like I posted
(there was one good page there though, thanks).
I don't really need the basic stuff (I know most of them), but I am
looking for more advanced guidelines (with justifications, like the one
about making virtual methods private).
Try the articles at this site:
< http://tinyurl.com/2tt4h >
"Pete Vidler" <pv*****@mailblocks.com> wrote Claudio Puviani wrote:
[snip] http://search.barnesandnoble.com/boo...sbn=0521893089
It's basically an extension of what used to be Rogue
Wave's guidelines. No one will agree with every
guideline, but they're mostly reasonable.
Interesting.. but the summary says it deals with formatting,
naming, documentation, etc. I was looking for design
guidelines along the lines of those that I posted. Am I
correct in assuming it doesn't cover such issues?
It has rudimentary design guidelines as well. The formatting section is just
a few pages, and the least interesting at that.
Here's a list of books I posted once before that would give you what you
need:
For general inheritance guidelines, strategies, pitfalls, etc. (in no
particular order):
"C++ Primer" by Lippman and Lajoie
"Effective C++" by Scott Meyers
"More Effective C++" by Scott Meyers
"Effective STL" by Scott Meyers
"Exceptional C++" by Herb Sutter
"More Exceptional C++" by Herb Sutter
"Large Scale C++ Software Design" by John Lakos
"Designing and Coding Reusable C++" by Carroll and Ellis
"Ruminations on C++" by Koenig and Moo
"Enough Rope to Shoot Yourself in the Foot" by Allen Holub
"C++ Strategies and Tactics" by Bob Murray
"C++ Programming Style" by Tom Cargill
"C++ in Action" by Bartosz Milewski
"C++ Code Capsules" by Chuck Allison
and even the old but excellent "Advanced C++" by James Coplien
Claudio Puviani
"Pete Vidler" <pv*****@mailblocks.com> wrote Claudio Puviani wrote:
[snip] http://search.barnesandnoble.com/boo...sbn=0521893089
It's basically an extension of what used to be Rogue
Wave's guidelines. No one will agree with every
guideline, but they're mostly reasonable.
Interesting.. but the summary says it deals with formatting,
naming, documentation, etc. I was looking for design
guidelines along the lines of those that I posted. Am I
correct in assuming it doesn't cover such issues?
It has rudimentary design guidelines as well. The formatting section is just
a few pages, and the least interesting at that.
Here's a list of books I posted once before that would give you what you
need:
For general inheritance guidelines, strategies, pitfalls, etc. (in no
particular order):
"C++ Primer" by Lippman and Lajoie
"Effective C++" by Scott Meyers
"More Effective C++" by Scott Meyers
"Effective STL" by Scott Meyers
"Exceptional C++" by Herb Sutter
"More Exceptional C++" by Herb Sutter
"Large Scale C++ Software Design" by John Lakos
"Designing and Coding Reusable C++" by Carroll and Ellis
"Ruminations on C++" by Koenig and Moo
"Enough Rope to Shoot Yourself in the Foot" by Allen Holub
"C++ Strategies and Tactics" by Bob Murray
"C++ Programming Style" by Tom Cargill
"C++ in Action" by Bartosz Milewski
"C++ Code Capsules" by Chuck Allison
and even the old but excellent "Advanced C++" by James Coplien
Claudio Puviani
"Pete Vidler" <pv*****@mailblocks.com> wrote Daniel T. wrote:
[snip] Check out these two books:
"Large-Scale C++ Software Design" by John Lakos
I've heard of this one, but isn't it seriously out of date?
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.
I've also heard that he has some strange guidelines like
not using namespaces?
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. Taking John's
admonition against using namespaces out of context is less than meaningless.
What he actually suggested, which anyone who actually read the book would
know, is to wait until namespace support was more stable and universal
before using it. At the time the book was written, there were quite a few
compilers that didn't support namespaces or that supported them incorrectly.
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.
Claudio Puviani
"Pete Vidler" <pv*****@mailblocks.com> wrote Daniel T. wrote:
[snip] Check out these two books:
"Large-Scale C++ Software Design" by John Lakos
I've heard of this one, but isn't it seriously out of date?
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.
I've also heard that he has some strange guidelines like
not using namespaces?
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. Taking John's
admonition against using namespaces out of context is less than meaningless.
What he actually suggested, which anyone who actually read the book would
know, is to wait until namespace support was more stable and universal
before using it. At the time the book was written, there were quite a few
compilers that didn't support namespaces or that supported them incorrectly.
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.
Claudio Puviani
"Pete Vidler" <pv*****@mailblocks.com> wrote in message
news:ShTdc.309$sp4.218@newsfe1- 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):
We should have guidelines and suggestions. Suggestions are weaker than
guidelines.
- Functions should fit on one screen, from various sources.
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.
- 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.
- 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.
They should be private or protected. Often, a virtual function will call
the same function in the base class and do some additional processing, as
for example a virtual equal function. I generally call the private virtual
functions myaction, and the protected ones doaction.
- Header files should be self contained, from various sources.
What?
- Destructors for base classes should be either virtual or protected.
No. Classes meant to not be derived from may have public non-virtual
destructors, such as std::vector.
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?
There are lots of others.
"Pete Vidler" <pv*****@mailblocks.com> wrote in message
news:ShTdc.309$sp4.218@newsfe1- 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):
We should have guidelines and suggestions. Suggestions are weaker than
guidelines.
- Functions should fit on one screen, from various sources.
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.
- 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.
- 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.
They should be private or protected. Often, a virtual function will call
the same function in the base class and do some additional processing, as
for example a virtual equal function. I generally call the private virtual
functions myaction, and the protected ones doaction.
- Header files should be self contained, from various sources.
What?
- Destructors for base classes should be either virtual or protected.
No. Classes meant to not be derived from may have public non-virtual
destructors, such as std::vector.
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?
There are lots of others.
Siemel Naran wrote:
[snip] 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):
We should have guidelines and suggestions. Suggestions are weaker than
guidelines.
I see no difference. I am just as free to ignore either. The purpose of
my post was to find out what various people (or websites, books, etc)
might have to say about what they consider to be "good" design.
- Functions should fit on one screen, from various sources.
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.
- 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.
You can have pure virtual methods with an implementation. Note that
abstract in this case means simply that the class has >=1 pure virtual
method, not that they are all pure virtual (my interpretation of that
source).
Having tried this in a recent project, it really isn't that much of a
burden (most of my classes were close anyway).
- 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.
They should be private or protected. Often, a virtual function will call
the same function in the base class and do some additional processing, as
for example a virtual equal function. I generally call the private virtual
functions myaction, and the protected ones doaction.
Aside from the naming that is exactly what I posted? Except that I'm not
too sure about having a virtual "equal function".
- Header files should be self contained, from various sources.
What?
I posted more info on this elsewhere in the thread. Basically I just
meant that you should be able to include the header at the very top of
your source file and not get errors.
- Destructors for base classes should be either virtual or protected.
No. Classes meant to not be derived from may have public non-virtual
destructors, such as std::vector.
Umm.. since when is std::vector a base class? A base class is one that
has been (or is intended to be) derived from (IMO).
[snip] There are lots of others.
That doesn't help. The entire purpose of my post was to get people to
post some (or post links, etc).
-- Pete
Siemel Naran wrote:
[snip] 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):
We should have guidelines and suggestions. Suggestions are weaker than
guidelines.
I see no difference. I am just as free to ignore either. The purpose of
my post was to find out what various people (or websites, books, etc)
might have to say about what they consider to be "good" design.
- Functions should fit on one screen, from various sources.
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.
- 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.
You can have pure virtual methods with an implementation. Note that
abstract in this case means simply that the class has >=1 pure virtual
method, not that they are all pure virtual (my interpretation of that
source).
Having tried this in a recent project, it really isn't that much of a
burden (most of my classes were close anyway).
- 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.
They should be private or protected. Often, a virtual function will call
the same function in the base class and do some additional processing, as
for example a virtual equal function. I generally call the private virtual
functions myaction, and the protected ones doaction.
Aside from the naming that is exactly what I posted? Except that I'm not
too sure about having a virtual "equal function".
- Header files should be self contained, from various sources.
What?
I posted more info on this elsewhere in the thread. Basically I just
meant that you should be able to include the header at the very top of
your source file and not get errors.
- Destructors for base classes should be either virtual or protected.
No. Classes meant to not be derived from may have public non-virtual
destructors, such as std::vector.
Umm.. since when is std::vector a base class? A base class is one that
has been (or is intended to be) derived from (IMO).
[snip] There are lots of others.
That doesn't help. The entire purpose of my post was to get people to
post some (or post links, etc).
-- Pete
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
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
Claudio Puviani wrote:
[snip] I've heard of this one, but isn't it seriously out of date?
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?
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).
I've also heard that he has some strange guidelines like
not using namespaces?
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.
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.
And for all I know, if I do read it much of its contents might be
obvious to me.
-- Pete
Claudio Puviani wrote:
[snip] I've heard of this one, but isn't it seriously out of date?
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?
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).
I've also heard that he has some strange guidelines like
not using namespaces?
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.
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.
And for all I know, if I do read it much of its contents might be
obvious to me.
-- Pete
"Phlip" <ph*******@yahoo.com> wrote in message
news:IQ************@newssvr15.news.prodigy.com... Pete Vidler wrote:
- Destructors for base classes should be either virtual or protected.
Never heard of the "protected" one.
If you have code like
class D : public B {};
B * pb = new D();
delete pb;
and D does not have a virtual destructor, undefined behavior results. There
are two possible solutions to this. If you give B a virtual destructor,
the correct destructor is called by delete. Alternatively, if you give B a
protected destructor the "delete pb;" statement will fail to compile. Thus,
you give a class a protected destructor when you don't want anybody deleting
a derived class through a pointer to the base class.
Joe Gottman
"Phlip" <ph*******@yahoo.com> wrote in message
news:IQ************@newssvr15.news.prodigy.com... Pete Vidler wrote:
- Destructors for base classes should be either virtual or protected.
Never heard of the "protected" one.
If you have code like
class D : public B {};
B * pb = new D();
delete pb;
and D does not have a virtual destructor, undefined behavior results. There
are two possible solutions to this. If you give B a virtual destructor,
the correct destructor is called by delete. Alternatively, if you give B a
protected destructor the "delete pb;" statement will fail to compile. Thus,
you give a class a protected destructor when you don't want anybody deleting
a derived class through a pointer to the base class.
Joe Gottman
Joe Gottman wrote: If you have code like
class D : public B {};
B * pb = new D();
delete pb;
and D does not have a virtual destructor, undefined behavior results.
There are two possible solutions to this. If you give B a virtual destructor,
the correct destructor is called by delete. Alternatively, if you give B a
protected destructor the "delete pb;" statement will fail to compile.
Thus, you give a class a protected destructor when you don't want anybody
deleting a derived class through a pointer to the base class.
The rules for 'protected' roughly mean "anything you could reference thru
'this' (plus statics)".
So 'delete this' breaks your protection.
--
Phlip http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces
Joe Gottman wrote: If you have code like
class D : public B {};
B * pb = new D();
delete pb;
and D does not have a virtual destructor, undefined behavior results.
There are two possible solutions to this. If you give B a virtual destructor,
the correct destructor is called by delete. Alternatively, if you give B a
protected destructor the "delete pb;" statement will fail to compile.
Thus, you give a class a protected destructor when you don't want anybody
deleting a derived class through a pointer to the base class.
The rules for 'protected' roughly mean "anything you could reference thru
'this' (plus statics)".
So 'delete this' breaks your protection.
--
Phlip http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces
Pete Vidler wrote: Right, but if it almost pre-dates namespaces there is going to be a lot
missing from it -- am I right? Templates and such?
What you need is not in any book.
From Lakos, you will learn dozens of very valid guidelines. For example, the
first #include line inside foo.cpp should always be foo.h. This ensures that
foo.h can stand alone without any other header above it - no surprise
requirements.
From Knuth, you will learn how to think and reason much harder than is
usually needed. These are just warmups for thinking outside the box, and
going off one of Knuth's diagrams.
Also (if Pete Becker isn't around and it's safe to mention this), read the
Sedgewick books on algorithms.
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).
So is /Design Patterns/. There is no book that says "How can Pete Vidler use
the latest language features safely". Not even /Modern C++ Design/ by Andrei
Alexandrescu, which covers templates in greater detail than mere mortals
need.
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.
This misses the point. Lakos says "I analyzed my huge project like this, and
I found these conclusions". Many of his recommendations are perfect, but
many are simply the result of his project. Learn from how he analyzed the
project.
--
Phlip http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces
Pete Vidler wrote: Right, but if it almost pre-dates namespaces there is going to be a lot
missing from it -- am I right? Templates and such?
What you need is not in any book.
From Lakos, you will learn dozens of very valid guidelines. For example, the
first #include line inside foo.cpp should always be foo.h. This ensures that
foo.h can stand alone without any other header above it - no surprise
requirements.
From Knuth, you will learn how to think and reason much harder than is
usually needed. These are just warmups for thinking outside the box, and
going off one of Knuth's diagrams.
Also (if Pete Becker isn't around and it's safe to mention this), read the
Sedgewick books on algorithms.
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).
So is /Design Patterns/. There is no book that says "How can Pete Vidler use
the latest language features safely". Not even /Modern C++ Design/ by Andrei
Alexandrescu, which covers templates in greater detail than mere mortals
need.
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.
This misses the point. Lakos says "I analyzed my huge project like this, and
I found these conclusions". Many of his recommendations are perfect, but
many are simply the result of his project. Learn from how he analyzed the
project.
--
Phlip http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces
"Pete Vidler" <pv*****@mailblocks.com> wrote in message
news:OVZdc.83$7w.18@newsfe1- Aside from the naming that is exactly what I posted? Except that I'm not
too sure about having a virtual "equal function".
bool C::operator==(const C& that) const {
if (typeid(*this) != typeid(that)) return false;
return this->doequal(that);
}
bool C2::doequal(const C& arg) {
const C2& that = static_cast<const C2&>(arg);
...
}
Here C2 derives from C, and C::doequal is pure virtual. Though a double
dispatch mechanism might more elegant. Granted an operator== doesn't always
make sense.
"Pete Vidler" <pv*****@mailblocks.com> wrote in message
news:OVZdc.83$7w.18@newsfe1- Aside from the naming that is exactly what I posted? Except that I'm not
too sure about having a virtual "equal function".
bool C::operator==(const C& that) const {
if (typeid(*this) != typeid(that)) return false;
return this->doequal(that);
}
bool C2::doequal(const C& arg) {
const C2& that = static_cast<const C2&>(arg);
...
}
Here C2 derives from C, and C::doequal is pure virtual. Though a double
dispatch mechanism might more elegant. Granted an operator== doesn't always
make sense.
"Pete Vidler" <pv*****@mailblocks.com> wrote Claudio Puviani wrote:
[snip]I've heard of this one, but isn't it seriously out of date?
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.
I've also heard that he has some strange guidelines like
not using namespaces?
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
"Pete Vidler" <pv*****@mailblocks.com> wrote Claudio Puviani wrote:
[snip]I've heard of this one, but isn't it seriously out of date?
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.
I've also heard that he has some strange guidelines like
not using namespaces?
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
Phlip wrote in news:cL****************@newssvr32.news.prodigy.com in
comp.lang.c++: Joe Gottman wrote:
If you have code like
class D : public B {};
B * pb = new D();
delete pb;
and D does not have a virtual destructor, undefined behavior results.
There are two possible solutions to this. If you give B a virtual
destructor, the correct destructor is called by delete.
Alternatively, if you give B a protected destructor the "delete pb;"
statement will fail to compile.
Thus, you give a class a protected destructor when you don't want anybody
deleting a derived class through a pointer to the base class.
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.
-- http://www.victim-prime.dsl.pipex.com/
Phlip wrote in news:cL****************@newssvr32.news.prodigy.com in
comp.lang.c++: Joe Gottman wrote:
If you have code like
class D : public B {};
B * pb = new D();
delete pb;
and D does not have a virtual destructor, undefined behavior results.
There are two possible solutions to this. If you give B a virtual
destructor, the correct destructor is called by delete.
Alternatively, if you give B a protected destructor the "delete pb;"
statement will fail to compile.
Thus, you give a class a protected destructor when you don't want anybody
deleting a derived class through a pointer to the base class.
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.
-- http://www.victim-prime.dsl.pipex.com/
Pete Vidler wrote: 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?
--
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 wrote: 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?
--
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 wrote: 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...ndations1.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 wrote: 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...ndations1.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
Claudio Puviani wrote:
[snip] 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.
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] 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.
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.
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. 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.
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
Claudio Puviani wrote:
[snip] 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.
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] 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.
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.
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. 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.
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: beliavsky |
last post by:
Is there a more recent set of Python style guidelines than PEP 8,
"Style Guide for Python Code", by van Rossum and Warsaw, at
http://www.python.org/peps/pep-0008.html , which is dated July 5,
2001?
|
by: stevehayter |
last post by:
Wonder if anyone can help me solve this problem!
I have a 3x3 table which i'm using to create a table with a rounded
edge using images in the top left, top right, bottom left, and bottom
right...
|
by: Pete Vidler |
last post by:
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,...
|
by: E. Robert Tisdale |
last post by:
C++ Programming Style Guidelines
http://geosoft.no/development/cppstyle.html
I think that these guidelines are almost *all* wrong.
For example:
11. Private class variables should have...
|
by: jamilur_rahman |
last post by:
What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A...
| | |
by: John Salerno |
last post by:
Does Microsoft have any naming guidelines for variables? I've been
reading their guidelines for just about every other type (methods,
parameters, properties, etc.) but nothing about variables. Are...
|
by: Laurent Bugnion [MVP] |
last post by:
Hi group,
In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web...
|
by: mrashidsaleem |
last post by:
Can anyone guide me what is wrong with the naming conventions
suggested below? I know that this is not recommended by many
(including Microsoft) but I need to know what exactly is the rationale...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
