Large-Scale C++ Software Design

[marktxx]

I've finally gotten around to reading the book "Large-Scale C++
Software Design" by John Lakos.
Has anyone documented what parts of this book are now obsolete due to
C++ language changes such as namespaces? or are now generally
considered bad advice?

Feel free to reply here on a particular topic discussed in the book.

I also noticed that John Lakos has a book in preparation called
"Scalable C++: Component-Based Development" maybe this is the much
needed 2nd edition.

thanks
Mark
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Phlip]

marktxx wrote:

I've finally gotten around to reading the book "Large-Scale C++
Software Design" by John Lakos.
Has anyone documented what parts of this book are now obsolete due to
C++ language changes such as namespaces?
Those recommendations were obsolete at the time the book was written.
or are now generally
considered bad advice?
There's a good repository of bad advise here:

http://c2.com/cgi/wiki?LargeScaleCppSoftwareDesign

To read LSCSD, imagine incorporating each guideline into your own
habits.
Some, such as where to put #include lines, are brilliant, crucial,
and easy.
Some, such as unit tests, are mission critical but hard.

Some, such as Registered Package Prefixes, are still generally valid but
should not be slavishly applied. The book is still completely relevant
because Lakos doesn't just say "do this", he explains his own
research to
arrive at each conclusion. Draw your own results, and question
_everything_
you read. Even the stuff that keeps up with the Standard.
I also noticed that John Lakos has a book in preparation called
"Scalable C++: Component-Based Development" maybe this is the much
needed 2nd edition.

Maybe it will cover CORBA, which is an over-researched and under-
documented
component system that appears to have much potential.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[kanze]

Phlip wrote:

marktxx wrote:

I've finally gotten around to reading the book "Large-Scale
C++ Software Design" by John Lakos. Has anyone documented
what parts of this book are now obsolete due to C++ language
changes such as namespaces? Those recommendations were obsolete at the time the book was
written.
Are you kidding? At the time I first saw the book, none of the
compilers I was using supported namespaces. Even today, I find
that namespaces introduce so much additional confusion in things
like function overloading (which isn't simple to begin with)
that I tend to avoid them, except maybe at the highest level.
(I'm glad that the standard library is in a namespace, for
example.)
or are now generally considered bad advice? There's a good repository of bad advise here: http://c2.com/cgi/wiki?LargeScaleCppSoftwareDesign
I gave it a quick glance, but there didn't really seem to be
much useful information there. (There were a lot of unjustified
opinions, but nothing concrete.)
To read LSCSD, imagine incorporating each guideline into your
own habits. Some, such as where to put #include lines, are
brilliant, crucial, and easy. Some, such as unit tests, are
mission critical but hard. Some, such as Registered Package Prefixes, are still generally
valid but should not be slavishly applied. The book is still
completely relevant because Lakos doesn't just say "do this",
he explains his own research to arrive at each conclusion.
Draw your own results, and question _everything_ you read.
Even the stuff that keeps up with the Standard.
That sounds about like what I would say. All of the basic
principles still apply. How you actually apply them in any
given project will vary.
I also noticed that John Lakos has a book in preparation
called "Scalable C++: Component-Based Development" maybe
this is the much needed 2nd edition.

Maybe it will cover CORBA, which is an over-researched and
under-documented component system that appears to have much
potential.

I agree. Corba seems to be almost moribond, but for most of the
applications I see, it would be a far better solution than
things like XML, which are being used because they are "in".

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Phlip]

kanze wrote:

Are you kidding?
No, I just didn't notice I was posting to the moderated group.
At the time I first saw the book, none of the
compilers I was using supported namespaces. Even today, I find
that namespaces introduce so much additional confusion in things
like function overloading (which isn't simple to begin with)
that I tend to avoid them, except maybe at the highest level.
(I'm glad that the standard library is in a namespace, for
example.)
The OP asked about what had become obsolete since. So maybe we agree that
the advice about Registered Package Prefixes is as obsolete now as it was
back then.

http://c2.com/cgi/wiki?LargeScaleCppSoftwareDesign

I gave it a quick glance, but there didn't really seem to be
much useful information there. (There were a lot of unjustified
opinions, but nothing concrete.)

Feel free to edit it. The page - vaguely - attempts reveal the tension and
debate between prefixes and namespaces, and the book's role in the debate.
Of course this rapidly devolves to one "side" screaming the book is evil
incarnate, and the other "side" trying to be rational.
I agree. Corba seems to be almost moribond, but for most of the
applications I see, it would be a far better solution than
things like XML, which are being used because they are "in".

I am currently learning CORBA Component Model, which might be worth all the
acres of PDF devoted to how awesome it is...

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Roland Pibinger]

On 11 May 2006 19:28:13 -0400, ma*****@yahoo.com wrote:

I also noticed that John Lakos has a book in preparation called
"Scalable C++: Component-Based Development" maybe this is the much
needed 2nd edition.

You probably mean this:
http://www.devconnections.com/shows/...=2&s=67&i=1655
.. BTW, are papers from
http://www.devconnections.com/shows/...t.asp?c=1&s=67
available online?

Best regards,
Roland Pibinger

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Francis Glassborow]

In article <11********************@i39g2000cwa.googlegroups.c om>, kanze
<ka***@gabi-soft.fr> writes

Some, such as Registered Package Prefixes, are still generally
valid but should not be slavishly applied. The book is still
completely relevant because Lakos doesn't just say "do this",
he explains his own research to arrive at each conclusion.
Draw your own results, and question _everything_ you read.
Even the stuff that keeps up with the Standard.

That sounds about like what I would say. All of the basic
principles still apply. How you actually apply them in any
given project will vary.

And that was true from the moment the book was published. The importance
of reading books such as this one is to educate ones thought processes,
not to obtain a collection of recipes to be applied without thought or
context.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Marco]

see also:
http://www.geocities.com/foetsch/large-scale/

[James Kanze]

Phlip wrote:

kanze wrote:

Are you kidding? No, I just didn't notice I was posting to the moderated group.

At the time I first saw the book, none of the compilers I was
using supported namespaces. Even today, I find that
namespaces introduce so much additional confusion in things
like function overloading (which isn't simple to begin with)
that I tend to avoid them, except maybe at the highest level.
(I'm glad that the standard library is in a namespace, for
example.)

The OP asked about what had become obsolete since. So maybe we
agree that the advice about Registered Package Prefixes is as
obsolete now as it was back then.
It depends. Today, of course, you do have a choice, but I can
imagine still using registered prefixes in many cases.

http://c2.com/cgi/wiki?LargeScaleCppSoftwareDesign

I gave it a quick glance, but there didn't really seem to be
much useful information there. (There were a lot of unjustified
opinions, but nothing concrete.)

Feel free to edit it. The page - vaguely - attempts reveal the
tension and debate between prefixes and namespaces, and the
book's role in the debate. Of course this rapidly devolves to
one "side" screaming the book is evil incarnate, and the other
"side" trying to be rational.

OK. I'd missed the fact that it was a Wiki, which automatically
means that considerable sorting of the proposed information is
necessary. (Quick glances, of course, tend to see those who
talk loudest and longest. Which are seldom those who have
useful information.)

--
James Kanze ka*********@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France [phone]

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Marco]

I also noticed that John Lakos has a book in preparation called
"Scalable C++: Component-Based Development" maybe this is the much
needed 2nd edition.

It's a shame when important computer books, that achieved good sales
figures, never get much needed follow-on editions. It seems only Craig
Larman, Bruce Eckel and the O'Reilly books do it in a timely fashion.
Steve McConnell did finally update "Code Complete" but it would have
been more valuable if he didn't take 11 years to do it.

Wikis are interesting but too much unsupported opinion ends up in them
so their credibility suffers. My fear is that computer information will
devolve into the celebrity weekly tabloids we see in the supermarket.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Francis Glassborow]

In article <11**********************@i40g2000cwc.googlegroups .com>,
Marco <pr**********@yahoo.com> writes

It's a shame when important computer books, that achieved good sales
figures, never get much needed follow-on editions. It seems only Craig
Larman, Bruce Eckel and the O'Reilly books do it in a timely fashion.
Steve McConnell did finally update "Code Complete" but it would have
been more valuable if he didn't take 11 years to do it.

In the programming industry sales figures above 5000 count as good,
above 10000 as very good. Much more than $2 per copy in royalties would
be unusual in my experience. Considering the time it takes to write a
book that is very poor reward for the author.

I made more money a year writing a monthly column for .EXE Magazine than
I do from my first book (whose UK sales figures alone exceed 5000), yet
those columns took an afternoon a month to write.

There are too many bad and mediocre books sucking up the resources of
newcomers and too many 'experienced' programmers think that the
post-novice books have nothing to offer them. Good authors need support
else they find more rewarding ways to spend their time.

--
Francis Glassborow ACCU
Author of 'You Can Do It!'& 'You Can Program in C++'
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Phlip]

Francis Glassborow wrote:

Good authors need support
else they find more rewarding ways to spend their time.

They also may need supports other than money.

(Insert rant here about the review process for technical books that cover
C++, to keep us topical;)

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[John Wait]

I had the good fortune to be the editor for John Lakos' first book, as
well as a few other C++ books such as Scott Meyers' gems, and first
books by Tom Cargill, Steve Dewhurst, Kathy Stark, etc. I also had the
good fortune to publish all of the first editions written by Rich
Stevens, Evi Nemeth and others. And I was lucky to be the editor for
Design Patterns, Gamma et al (c) 1995.

While I spent years begging and nagging many authors to revise, let me
now defend them. Many of the most successful authors are not full time
writers. They are teachers, trainers, coders, sys admins, network
managers, professors, researchers, or managers. Many wrote a book as
a one-time let-me-help-by-sharing-what-I-know exercise. Many moved to
new topics, such as from C++ to Java to Ruby on Rails. They were no
longer working in the same subject and had little interest in revising
a book on a technology she/he no longer used.

Authors and editors regularly look forward to receiving comments for
suggestions for improvements--updates/deletions/etc. Generally their
email address is listed in the preface or acknowledgements of the book.
Some Publishers list their editors on their web site, such as this:
http://www.awprofessional.com/about/...us.asp#editors

If you like a book, and hope for an update, I encourage you to send
your suggestions to the author of the book and/or the editor for the
book.

Best regards,
John Wait
Pearson Technology Group
http://www.pearsoned.com/professional/technical.htm
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Simon Bone]

On Wed, 17 May 2006 18:11:07 -0400, John Wait wrote:

I had the good fortune to be the editor for John Lakos' first book, as
well as a few other C++ books such as Scott Meyers' gems, and first
books by Tom Cargill, Steve Dewhurst, Kathy Stark, etc. I also had the
good fortune to publish all of the first editions written by Rich
Stevens, Evi Nemeth and others. And I was lucky to be the editor for
Design Patterns, Gamma et al (c) 1995.

While I spent years begging and nagging many authors to revise, let me
now defend them. Many of the most successful authors are not full time
writers. They are teachers, trainers, coders, sys admins, network
managers, professors, researchers, or managers. Many wrote a book as
a one-time let-me-help-by-sharing-what-I-know exercise. Many moved to
new topics, such as from C++ to Java to Ruby on Rails. They were no
longer working in the same subject and had little interest in revising
a book on a technology she/he no longer used.

First let me say that I appreciate that they do. I can't really imagine
ever having the time and energy to add such a task on top of the day job.

Secondly, I think it is important to accept that such writers do
move on. Perhaps publishers should give more consideration to buying the
rights to derivative works. Then if the original author moves on, some
other poor sucker^H^H^H^H^H^H^H^H^H^H^Hwilling soul could be put on the
task of providing an updated version.

I notice that CC and GDL licensed books are appearing from some
publishers, especially on topics that obviously relate to open source
software. Those licenses have specific clauses on derivative works that
may be a long term advantage. (And FWIW I like paper books, and so
I've bought at least one.)

Whatever the means, I do wish publishers would find a way to update
popular books to fit current standards. There is not much worse than
having to update the skills of co-workers who just read a new book- one
they just bought, but which was written 10 years earlier. It is all too
common unfortunately.

Cheers,

Simon Bone

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Phlip]

Simon Bone wrote:

John Wait wrote:

While I spent years begging and nagging many authors to revise, let me
now defend them. Many of the most successful authors are not full time
writers. They are teachers, trainers, coders, sys admins, network
managers, professors, researchers, or managers. Many wrote a book as
a one-time let-me-help-by-sharing-what-I-know exercise. Many moved to
new topics, such as from C++ to Java to Ruby on Rails. They were no
longer working in the same subject and had little interest in revising
a book on a technology she/he no longer used.

First let me say that I appreciate that they do. I can't really imagine
ever having the time and energy to add such a task on top of the day job.

Note that Addison Wesley recently RIF'ed their editors. I suspect to prepare
for a merger with Simon & Schuster, or something. So their surviving editors
are now actively seeking sequels to popular books, to add some sure-bets to
their portfolio.

Moderated group removed from the group list.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Marco]

{This is really OT but it seems in the interest of the wider community
to let it through but not for further discusssion here, please.
-mod/fwg}
John Wait wrote:

While I spent years begging and nagging many authors to revise, let me
now defend them. Many of the most successful authors are not full time
writers. They are teachers, trainers, coders, sys admins, network
managers, professors, researchers, or managers. Many wrote a book as
a one-time let-me-help-by-sharing-what-I-know exercise. Many moved to
new topics, such as from C++ to Java to Ruby on Rails. They were no
longer working in the same subject and had little interest in revising
a book on a technology she/he no longer used.

I don't want to sound anti-author-rights but maybe after a period of
say 5 years the publisher gets the right to locate another author to
revise the next edition with the approval of the original author. Maybe
the original author could be an editor. The original author would
receive royalties (but just not as much) if he/she allowed their name
to be listed. This would help keep books current. I noticed that
O'Reilly appears to do something like this.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Nicola Musatti]

Marco wrote:

{This is really OT but it seems in the interest of the wider community
to let it through but not for further discusssion here, please.
-mod/fwg}

John Wait wrote: [...] I don't want to sound anti-author-rights but maybe after a period of
say 5 years the publisher gets the right to locate another author to
revise the next edition with the approval of the original author. Maybe
the original author could be an editor. The original author would
receive royalties (but just not as much) if he/she allowed their name
to be listed. This would help keep books current. I noticed that
O'Reilly appears to do something like this.

I don't think it's really a problem of rights, but one of expected
sales. Consider "C++ Primer"; the first two editons were authored by
Stan Lippmann, then Josee Lajoie joined him for the third one and
Barbara Moo joined the team for the latest one. I wouldn't be surprised
to learn that the first two had little to do with the fourth edition.

These things do happen when publishers consider them worthwhile.

Cheers,
Nicola Musatti
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Lance Diduck]

I have read large portions of the new manuscript. I wont quote it or preview it, that is the priveledge of the author and his publisher.

What I liked about the first book was the motivation: trying to understand what went wrong with the notorious Mentor Graphics "Version 8.0" project. This was the early 90's, with CFRONT, "Physical design" was largely equated with "static linked libraries in a makefile," which had a ring of truth to it. Implementers back then groped with these problems - no exceptions, no templates, no remote databases, lttile or no networking, no standard libraries, expensive RAM, etc. Databases, networking, collection classes, resource managers, were all designed in house -- there was no open source. C++ utility libraries barely existed, and large db systems and networking solutions were expensive, and were not available to the vast majority of developers. The book dealt with these issues squarely. The book disappointingly did not address what Mentor finally did, which I understand was integrate the older working product into the new, a C++/Pascal hybrid" effectively facelifitng the pascal..
The challenges facing todays C++ developers (and we all know that no one only programs in one language now) are far different.than those Mentor faced. In large scale systems now, integration is paramount, reinterfacing legacy systems equally so. Learning to make the most effective use of the plethora of available tools, integrating with other technolgies, working with developers who are not language gurus are the challgenge facing the modern large scale developer. Any "large scale designer" now takes dependency management, testing, software capital management as a given -- it always was that was, just that in the early 90's software construction was less understood.
I design and implement systems with thousands of interoperating C++ classes, and have found namespaces to be a godsend in grouping logical constructs togethers, a making sense of the names that model domain concepts, utilties, adapters to the various messaging and persistent stores, script intepreters and so forth. the concept of the "RPP" and levelization is more "where does this particular archive go in the makefile." which honestly is the least of my worries.