By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,819 Members | 1,185 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,819 IT Pros & Developers. It's quick & easy.

Large scale C++ software design?

P: n/a
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 fairly thorough
literature search, but i haven't found anything fitting this criteria.

In general there seems to be a huge amount concerning the C++ language as
such and more "narrow" design issues, e.g. along the lines of Meyers
Effective-
series.

I have already considered Design Patterns by Gamma et al, which
is a good book as well, but perhaps (implicitly) a bit too focused on
flexibility (as opposed to e.g. efficiency, insulation etc).

Any good suggestions concerning such literature?

Thanks in advance

/ Kymert




Jul 19 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
"Kymert persson" <mi*****@ida.his.se> wrote...
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 fairly thorough
literature search, but i haven't found anything fitting this criteria.

In general there seems to be a huge amount concerning the C++ language as
such and more "narrow" design issues, e.g. along the lines of Meyers
Effective-
series.

I have already considered Design Patterns by Gamma et al, which
is a good book as well, but perhaps (implicitly) a bit too focused on
flexibility (as opposed to e.g. efficiency, insulation etc).

Any good suggestions concerning such literature?


"Object-Oriented Software Construction", maybe?

Try asking in comp.software-eng as well. Successful creation,
development, maintenance of a large system, depend on many
factors, which are not necessarily common between organisations.

Victor
Jul 19 '05 #2

P: n/a
OK, i agree to som of what you are saying but I alsö
disagree to some of it.

I agree that the best way to learn programming is by doing it. But
at least in my experience more theoretical issues give you a lot
of the ideas that you later choose to experiment with in practice.

I disagree to your view on Lakos work as mainly concerned with
dividing projects into directories, rather i would say his main concern
is insulation, i.e. how to minimize compile time dependencies between
components, an issue of major concern to anyone designing/implementing
large software systems (in a compiled language anyway).

When it comes to your view that the "language is irrelevant" i do
understand what you are getting at, i.e. that the same design can be
realized in any language (with more or less pain of course). The problem
with the "language is irrelevant" view, in my opinion, is that it breaks
down in many
practical settings. Consider the STL for example, imagine implementing that
in
a language without support for templates... Another example would be using
Prolog
for implementing the next version of the Appache web server, surely Prolog
could deliver the appropriate function but the hardware requirements as
well as the development costs would surely break through the roof...

Another issue, related to the "language irrelevancy", is the fact that there
is
always many ways to implement the same design (even in the same
programming language and perhaps especially in languages such as C++
which supports several design paradigms). The problem is that many of these
"ways"
are really bad, perhaps not at first sight but perhaps when the system grows
larger or when it has to be ported to some other platform etc...
Given these very real problems i think that literature such as the book by
Lakos
is invaluable in that it discusses real world success, i.e. things that
worked
really well in this or that setting (In Lakos case, really large systems)
/K



/K


"Victor Bazarov" <v.********@attAbi.com> wrote in message
news:vj************@corp.supernews.com...
"Kymert persson" <mi*****@ida.his.se> wrote...
Thanks for the tip, but i think this book is a bit too high-level
compared to what i am looking for. And i guess this is part of

a general problem concerning software/programming-

literture, i.e. that they are either fairly low level descibing a

language or rather high level descibing things such as

reusability, modularity, portability etc., without really demonstrating

how to realise these ideas in a particular language (preferrably C++

in my case)


The only reason they don't is because the language is irrelevant.
I think that the "Large scale C++ software design" by Lakos, J. is

exceptional in this respect, he discusses fairly high level issues
concerning

large system design without ever loosing the connection to the
implementation

level.


As far as Lakos is concerned, his book is good for a novice who has
never worked on large project before. Once you've been there two or
three times and faced different issues than splitting projects into
directories, you will set that book aside as a memento, nothing more.

Your level changes as you progress. The level of the book doesn't.
And it doesn't cover issues that are increasingly important. Only
the basics, which become details very soon.

I recommend "shock therapy" as the main approach to learning things.
Programming? Knuth. C++? Stroustrup and Ellis, Coplien. Driving?
Get on the road after you learn shifting from the first to the second
gear. Swimming? Jump in the water at the deep end of the pool. From
my point of view, you learn by doing. Join a big group of people and
see how they organise their work to understand what motivates them and
what is wrong with their processes. As soon as you can consciously
make a suggestion and it gets accepted, you got it. Reading books is
not going to get you there, trust me.

Victor

Jul 19 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.