Large Scale C++ Software Design, by John Lakos

[al.cpwn]

I recently bought this book, and wanted some recommendations on what
are the most important lessons one should learn from this book. i.e.
something that comes up frequently in large C++ based designs and will
be useful to me over and over again. I am an undergrad student so I
don't run into problems involving large projects (as I have never
worked on one) but would nevertheless like to learn the principles so
that if I am hired to work on something big I won't feel lost. Is there
a difference between software engineering and what Lakos is
recommending us to do?

 

[Phlip]

I recently bought this book, and wanted some recommendations on what
are the most important lessons one should learn from this book. i.e.

The most important lesson is simply _how_ Lakos wrote the book. He did it by
experimenting, painstakingly, on huge codebases.

something that comes up frequently in large C++ based designs and will
be useful to me over and over again. I am an undergrad student so I
don't run into problems involving large projects (as I have never
worked on one) but would nevertheless like to learn the principles so
that if I am hired to work on something big I won't feel lost. Is there
a difference between software engineering and what Lakos is
recommending us to do?

Note that Lakos's projects have copious unit tests. These are _still_
underrepresented in programming. Take them away from the book if nothing
else, and write them to _prevent_ your project from growing huge.

When Lakos differs from some common wisdom (specifically, namespaces), then
return to Lakos's research techniques, and draw your own conclusion.

Apply all the Lakos guidelines (that you agree with) to projects of any
size.

Then read all the Sutter books, and the books in their series. And the
Effective books!

 

[Victor Bazarov]

I recently bought this book, and wanted some recommendations on what
are the most important lessons one should learn from this book. i.e.
something that comes up frequently in large C++ based designs and will
be useful to me over and over again. I am an undergrad student so I
don't run into problems involving large projects (as I have never
worked on one) but would nevertheless like to learn the principles so
that if I am hired to work on something big I won't feel lost. Is
there a difference between software engineering and what Lakos is
recommending us to do?

It's a good book, but a bit dated. Of course, there are eternal useful
things, like the need to componentize, abstract, design before coding,
document, plan... Give it a read but don't take anything too close to
heart.

V

 

[Dietmar Kuehl]

I recently bought this book, and wanted some recommendations on what
are the most important lessons one should learn from this book.

It is admittedly long ago that I have read [at least part of] the
book but the important lesson I took from this book is the critical
need to decouple components and techniques on how to effectively do
it. I was involved in a large project which failed at least partially
due to the lack of decoupling: everything was dependent on everything
else. This problem could have been avoided (although others would
still have caused the project to fail...).

 

[Roland Pibinger]

I recently bought this book, and wanted some recommendations on what
are the most important lessons one should learn from this book.

It is admittedly long ago that I have read [at least part of] the
book but the important lesson I took from this book is the critical
need to decouple components and techniques on how to effectively do
it. I was involved in a large project which failed at least partially
due to the lack of decoupling: everything was dependent on everything
else. This problem could have been avoided (although others would
still have caused the project to fail...).

I had the same experience (not only in C++ but also in Java). Even for
a moderately sized C++ program it's indispensable to create a system
architecture upfront that clearly defines allowed (and sometimes
desired) dependencies between components using a layered,
dependency-minimizing approach. BTW, this is also one of the reasons
why 'modern', 'boosted' libraries (which actually are template
collections rather than traditional libraries) are inappropriate for
any real world programming.

Best regards,
Roland Pibinger

 

[al.cpwn]

I recently bought this book, and wanted some recommendations on what
are the most important lessons one should learn from this book.

It is admittedly long ago that I have read [at least part of] the
book but the important lesson I took from this book is the critical
need to decouple components and techniques on how to effectively do
it. I was involved in a large project which failed at least partially
due to the lack of decoupling: everything was dependent on everything
else. This problem could have been avoided (although others would
still have caused the project to fail...).

I had the same experience (not only in C++ but also in Java). Even for
a moderately sized C++ program it's indispensable to create a system
architecture upfront that clearly defines allowed (and sometimes
desired) dependencies between components using a layered,
dependency-minimizing approach. BTW, this is also one of the reasons
why 'modern', 'boosted' libraries (which actually are template
collections rather than traditional libraries) are inappropriate for
any real world programming.

If I'm not mistaken, are you suggesting that a newbie shouldn't take
Lakos very seriously because in today's c++ we can't follow his advice
easily? If boost is not excluded from the 'boosted' library category
then you are partly wrong, because it is used at least by Adobe, in
photoshop.

 

[al.cpwn]

I recently bought this book, and wanted some recommendations on what
are the most important lessons one should learn from this book.

It is admittedly long ago that I have read [at least part of] the
book but the important lesson I took from this book is the critical
need to decouple components and techniques on how to effectively do
it. I was involved in a large project which failed at least partially
due to the lack of decoupling: everything was dependent on everything
else. This problem could have been avoided (although others would
still have caused the project to fail...).

I had the same experience (not only in C++ but also in Java). Even for
a moderately sized C++ program it's indispensable to create a system
architecture upfront that clearly defines allowed (and sometimes
desired) dependencies between components using a layered,
dependency-minimizing approach. BTW, this is also one of the reasons
why 'modern', 'boosted' libraries (which actually are template
collections rather than traditional libraries) are inappropriate for
any real world programming.

If I'm not mistaken, are you suggesting that a newbie shouldn't take
Lakos very seriously because in today's c++ we can't follow his advice
easily? If boost is not excluded from the 'boosted' library category
then you are partly wrong, because it is used at least by Adobe, in
photoshop.

 

[Roland Pibinger]

If I'm not mistaken, are you suggesting that a newbie shouldn't take
Lakos very seriously because in today's c++ we can't follow his advice
easily?

You are mistaken. Lakos' book is highly recommendable to real world
C++ programmers (don't see why you conclude the opposite). It's not a
book for newbies but sooner or later you are confronted with
dependency problems.

If boost is not excluded from the 'boosted' library category
then you are partly wrong, because it is used at least by Adobe, in
photoshop.

"partly wrong" means that I'm also partly right ;-)

Best wishes,
Roland Pibinger

 

[Ben Pope]

I had the same experience (not only in C++ but also in Java). Even for
a moderately sized C++ program it's indispensable to create a system
architecture upfront that clearly defines allowed (and sometimes
desired) dependencies between components using a layered,
dependency-minimizing approach. BTW, this is also one of the reasons
why 'modern', 'boosted' libraries (which actually are template
collections rather than traditional libraries) are inappropriate for
any real world programming.

I fail to see how 'boosted' libraries are not appropriate for "real
world programming". In fact, I fail to see how the bit you wrote after
"BTW" is in any way related to the bit you wrote before "BTW".

Boost doesn't necessarily remove or add dependencies between components
in your design.

Maybe I misunderstand 'boosted'.

Ben Pope

 

[Phlip]

Roland Pibinger wrote:

If I'm not mistaken, are you suggesting that a newbie shouldn't take
Lakos very seriously because in today's c++ we can't follow his advice
easily? If boost is not excluded from the 'boosted' library category
then you are partly wrong, because it is used at least by Adobe, in
photoshop.

Two comments.

A newbie should take Lakos very seriously. For example, 'The first line of
Foo.cpp should be #include "Foo.h".' If a newbie gets physical design issues
like these wrong, they can cripple a project before it gets large.

Next, boost may couple endlessly and onanistically with itself, but it's not
going to somehow force your own packages to all couple together. Claiming
boost is antithetical to any "up-front high-level architectural plan" is a
non-sequitur, and boost is full of both good examples of decoupling
(namespaces) and of gadgets you can use to decouple (shared pointers).

Also it has unit tests, which some folks think are better than up-front
designs.

 

[Roland Pibinger]

I fail to see how 'boosted' libraries are not appropriate for "real
world programming". In fact, I fail to see how the bit you wrote after
"BTW" is in any way related to the bit you wrote before "BTW".

Lakos' book is mostly about (the management of) depencencies.
Template-only libraries produce dependencies that are an order of
magnitude 'heavier' than those produced by function declarations and
class definitions. Using tempates means that you program against and
are depedent on the template implementation (which is needed for
template instantiation). Dependencies multiply when the used template
library/collection is dependent on several other template libraries
which are dependent ... (look at Boost headers for details).


Best wishes,
Roland Pibinger

 

[Ben Pope]

Lakos' book is mostly about (the management of) depencencies.
Template-only libraries produce dependencies that are an order of
magnitude 'heavier' than those produced by function declarations and
class definitions. Using tempates means that you program against and
are depedent on the template implementation (which is needed for
template instantiation).
Understood.

Dependencies multiply when the used template library/collection is
dependent on several other template libraries which are dependent ...
(look at Boost headers for details).

Also understood.

I guess developing boost in trunk is a pain.

However, I use a pretty stable version of boost, so although it
increases compilation times, that increase scales linearly, not
exponentially, which is the problem I guess Lakos is addressing (I can
only guess, I haven't read it... yet).

As such, I don't see the use of template based libraries as a problem of
scalability. Developing them is somewhat different.

Ben Pope