473,326 Members | 2,102 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Large Scale C++ Software Design, by John Lakos

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?

Mar 4 '06 #1
12 3708
al.cpwn wrote:
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!

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
Mar 4 '06 #2
al*****@gmail.com wrote:
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
--
Please remove capital As from my address when replying by mail
Mar 4 '06 #3
al*****@gmail.com wrote:
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...).
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Mar 4 '06 #4
On Sat, 04 Mar 2006 02:46:44 +0100, Dietmar Kuehl
<di***********@yahoo.com> wrote:
al*****@gmail.com wrote:
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
Mar 4 '06 #5
Roland Pibinger wrote:
On Sat, 04 Mar 2006 02:46:44 +0100, Dietmar Kuehl
<di***********@yahoo.com> wrote:
al*****@gmail.com wrote:
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.

Mar 4 '06 #6
Roland Pibinger wrote:
On Sat, 04 Mar 2006 02:46:44 +0100, Dietmar Kuehl
<di***********@yahoo.com> wrote:
al*****@gmail.com wrote:
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.

Mar 4 '06 #7
On 4 Mar 2006 06:19:59 -0800, al*****@gmail.com 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?
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
Mar 4 '06 #8
Roland Pibinger wrote:

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
--
I'm not just a number. To many, I'm known as a string...
Mar 4 '06 #9
al.cpwn wrote:
Roland Pibinger wrote:

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.


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.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
Mar 4 '06 #10
On Sat, 04 Mar 2006 18:00:05 +0000, Ben Pope
<be***************@gmail.com> wrote:

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
Mar 5 '06 #11
Roland Pibinger wrote:
On Sat, 04 Mar 2006 18:00:05 +0000, Ben Pope
<be***************@gmail.com> wrote:
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).


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
--
I'm not just a number. To many, I'm known as a string...
Mar 5 '06 #12
Roland Pibinger wrote:
[talking about dependency minimization]
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 understand that template code can cause additional coupling where
non-template code which is cleanly separated into declaration and
definition would not. That is, you might not arrive at a dependency
minimum because the template code introduces certain additional
dependencies. However, I don't understand how you derive from such
an observation that "modern" (as in A.Alexandrescu's work) or
"boosted" (as in www.boost.org) are inappropriate for any world
programming! Fiddling with templated libraries while also using
them might cause some additional recompilation because for such
libraries the implementation is, in some sense, also part of the
interface. However, many of the corresponding tools support nice
decoupling techniques. Personally, I had never any problems using
template libraries like Boost but also other maintained within the
project in large projects.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Mar 5 '06 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

36
by: Andrea Griffini | last post by:
I did it. I proposed python as the main language for our next CAD/CAM software because I think that it has all the potential needed for it. I'm not sure yet if the decision will get through, but...
2
by: Kymert persson | last post by:
Hi. I was wondering if there are any more C++ books along the lines of "Large scale C++ software design" by Lakos, J. I.e. concerning larger design issues in close relation to C++. I have made a...
14
by: Steven T. Hatton | last post by:
Is there a more or less accepted authority describing how to structure a project? I know Julie has asked about namespaces. That is certainly a part of my question, but I want to know about the...
28
by: puzzlecracker | last post by:
Large scale C++ software design, by John Lakos - people any good recommendations to this book?
16
by: marktxx | last post by:
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...
6
by: razael1 | last post by:
Does anyone know of a good article dealing with organizing large class heirarchies? I've always had trouble with circular dependencies, global constants and variables, etc. Thanks.
10
by: sasquatch | last post by:
X-No-Archive: Are there any good books that provide tips about how to understand and "play with" large C++ programs? It seems like a very important skill, and yet its hardly taught in the...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.