Large scale C++ software design,

[puzzlecracker]

Large scale C++ software design, by John Lakos - people any good
recommendations to this book?

[davidrubin]

Definitely worthwhile. /david :-)

[Shezan Baig]

davidru...@warp mail.net wrote:

Definitely worthwhile. /david :-)

Yep, I second that. :)

-shez-

[E. Robert Tisdale]

puzzlecracker wrote:

Large scale C++ software design, by John Lakos
- people any good recommendations to this book?

This book was published in 1996
and contains a lot of obsolete advice.
For example, Chapter 2 Ground Rules,
Section 5 Redundant Include Guards, page 85,

Minor Design Rule
Place a redundant (external) include guard
around each preprocessor include directive
in every header file.

Today, we expect the C preprocessor to remember
idempotent header files and read them only once.

[puzzlecracker]

E. Robert Tisdale wrote:

puzzlecracker wrote:

Large scale C++ software design, by John Lakos
- people any good recommendations to this book?

This book was published in 1996
and contains a lot of obsolete advice.
For example, Chapter 2 Ground Rules,
Section 5 Redundant Include Guards, page 85,

Minor Design Rule
Place a redundant (external) include guard
around each preprocessor include directive
in every header file.

Today, we expect the C preprocessor to remember
idempotent header files and read them only once.

what would you supplement this book with? Any viable alternatives or
construction suggestions that would go on par with this book?

[davidrubin]

I would personally recommend Meyers, Dewhurst, and various books by
Sutter. However, none of these really address physical design in the
way that Lakos does.

[Shezan Baig]

E. Robert Tisdale wrote:

This book was published in 1996
and contains a lot of obsolete advice.
For example, Chapter 2 Ground Rules,
Section 5 Redundant Include Guards, page 85,

Minor Design Rule
Place a redundant (external) include guard
around each preprocessor include directive
in every header file.

Today, we expect the C preprocessor to remember
idempotent header files and read them only once.

What are you talking about? Is that specified in standard C++? Does
the following code compile for you?

blah.h
------
int somefunction() { return 9; }

blah.cpp
--------
#include <iostream>
#include "blah.h"
#include "blah.h"

int main() { std::cout << somefunction() << std::endl; }

I tried it on gpp and got "error: redefinition of 'int
somefunction()' ". If it compiles for you, I'd really like to know what
compiler you're using.

Thanks,
-shez-

[Victor Bazarov]

"Shezan Baig" <sh************ @gmail.com> wrote...

E. Robert Tisdale wrote:

This book was published in 1996
and contains a lot of obsolete advice.
For example, Chapter 2 Ground Rules,
Section 5 Redundant Include Guards, page 85, ^^^^^^^^^
Minor Design Rule
Place a redundant (external) include guard ^^^^^^^^ around each preprocessor include directive
in every header file.

Today, we expect the C preprocessor to remember
idempotent header files and read them only once.
What are you talking about?

He is talking about advice John Lakos gave in his book.
Is that specified in standard C++?
Why should that matter? The Standard doesn't specify any
design guidelines nor does it say what features of a C++
compiler make a better competitor on today's market. If
the preprocessor remembers what headers it has already
included, the redundant guards become unnecessary.
Does
the following code compile for you?

blah.h
------
int somefunction() { return 9; }

blah.cpp
--------
#include <iostream>
#include "blah.h"
#include "blah.h"

int main() { std::cout << somefunction() << std::endl; }

I tried it on gpp and got "error: redefinition of 'int
somefunction()' ". If it compiles for you, I'd really like to know what
compiler you're using.

No, what you presented here will certainly not compile.
However, if you add

#pragma once

to 'blah.h', some modern compilers will not preprocess it
again. The existence of 'once' pragma makes *external*
include guards unnecessary.

V

[davidrubin]

These small details are less important compared to the overall
methodology presented in the book. The main point is to recognize that
physical design is a separate problem from logical design, and then to
learn how to implement a physical design.

[Shezan Baig]

Victor Bazarov wrote:

However, if you add

#pragma once

to 'blah.h', some modern compilers will not preprocess it
again. The existence of 'once' pragma makes *external*
include guards unnecessary.

That worked! Cool, thanks!

-shez-