Large-Scale C++ Software Design

Category: Programming
Author: John Lakos
4.3
All Stack Overflow 56
This Year Stack Overflow 3
This Month Stack Overflow 13

Comments

by anonymous   2019-07-21

Lakos touches on this (amongst other things).

In his opinion (and I happen to agree with him) you shouldn't have degrees and radians tied to each other. If you need to convert from one to another then have a third class/struct to perform the switch.

So you would have 3 classes, Radians, Degrees and RadiansToDegrees, of which you could use RadiansToDegrees as a simple functor.

by anonymous   2019-07-21

Large-Scale C++ Software Design is a good resource.

Some quick tips to reduce dependencies.

  1. Forward declaration when possible.

  2. Use PIMPL

by George Sealy   2019-07-21

A good book that covers a lot of this (for both C and C++) is Large Scale C++ Software Design, by John Lakos:

Also, a good rule of thumb to remember is "Never do anything that allocates memory in a header file"

by anonymous   2019-07-21

In addition to the answers above getting hold of a copy of Large Scale C++ Software Design may help in this regard. Don't worry that the first chapter is a bit irrelevant these days, the majority of the ideas presented are still applicable.

by anonymous   2019-07-21

Read this: http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620

by anonymous   2019-07-21

So my question is: What are the major rules and reasons in using private / protected / non-public entities

In Python, there are no access modifiers.

So the reasons are actually language-specific. You might want to update your question slightly to reflect this.

It's a fairly common question about Python. Many programmers from Java or C++ (or other) backgrounds like to think deeply about this. When they learn Python, there's really no deep thinking. The operating principle is

We're all adults here

It's not clear who -- precisely -- the access modifiers help. In Lakos' book, Large-Scale Software Design, there's a long discussion of "protected", since the semantics of protected make subclasses and client interfaces a bit murky.

http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620

by litb   2017-08-20

Beginner

Introductory, no previous programming experience

Introductory, with previous programming experience

* Not to be confused with C++ Primer Plus (Stephen Prata), with a significantly less favorable review.

Best practices


Intermediate


Advanced


Reference Style - All Levels

C++11/14 References:

  • The C++ Standard (INCITS/ISO/IEC 14882-2011) This, of course, is the final arbiter of all that is or isn't C++. Be aware, however, that it is intended purely as a reference for experienced users willing to devote considerable time and effort to its understanding. As usual, the first release was quite expensive ($300+ US), but it has now been released in electronic form for $60US.

  • The C++14 standard is available, but seemingly not in an economical form – directly from the ISO it costs 198 Swiss Francs (about $200 US). For most people, the final draft before standardization is more than adequate (and free). Many will prefer an even newer draft, documenting new features that are likely to be included in C++17.

  • Overview of the New C++ (C++11/14) (PDF only) (Scott Meyers) (updated for C++1y/C++14) These are the presentation materials (slides and some lecture notes) of a three-day training course offered by Scott Meyers, who's a highly respected author on C++. Even though the list of items is short, the quality is high.

  • The C++ Core Guidelines (C++11/14/17/…) (edited by Bjarne Stroustrup and Herb Sutter) is an evolving online document consisting of a set of guidelines for using modern C++ well. The guidelines are focused on relatively higher-level issues, such as interfaces, resource management, memory management and concurrency affecting application architecture and library design. The project was announced at CppCon'15 by Bjarne Stroustrup and others and welcomes contributions from the community. Most guidelines are supplemented with a rationale and examples as well as discussions of possible tool support. Many rules are designed specifically to be automatically checkable by static analysis tools.

  • The C++ Super-FAQ (Marshall Cline, Bjarne Stroustrup and others) is an effort by the Standard C++ Foundation to unify the C++ FAQs previously maintained individually by Marshall Cline and Bjarne Stroustrup and also incorporating new contributions. The items mostly address issues at an intermediate level and are often written with a humorous tone. Not all items might be fully up to date with the latest edition of the C++ standard yet.

  • cppreference.com (C++03/11/14/17/…) (initiated by Nate Kohl) is a wiki that summarizes the basic core-language features and has extensive documentation of the C++ standard library. The documentation is very precise but is easier to read than the official standard document and provides better navigation due to its wiki nature. The project documents all versions of the C++ standard and the site allows filtering the display for a specific version. The project was presented by Nate Kohl at CppCon'14.


Classics / Older

Note: Some information contained within these books may not be up-to-date or no longer considered best practice.

by anonymous   2017-08-20

If you are going to build a large project in C++, you should at the very least read Large Scale C++ Software Design by John Lakos about it. It's a little old but it sounds like you could benefit from the fundamentals in it.

Keep in mind that building a large scale system in any language is a challenge and requires skill and discipline to prevent it falling to pieces very quickly. Don't take it lightly.

That said, if your definition of "large" is different than mine then I may have alternative advice to give you. I'm assuming you're talking about a project where the word "million" will be mentioned in sentences that also contain the words "lines of code".

by anonymous   2017-08-20

The best suggestion is to build makefiles that actually understand dependencies and do not automatically rebuild the world for a small change. But, if a full rebuild takes 90 minutes, and a small rebuild takes 5-10 minutes, odds are good that your build system already does that.

Can the build be done in parallel? Either with multiple cores, or with multiple servers?

Checkin pre-compiled bits for pieces that really are static and do not need to be rebuilt every time. 3rd party tools/libraries that are used, but not altered are a good candidate for this treatment.

Limit the build to a single 'stream' if applicable. The 'full product' might include things like a debug version, or both 32 and 64 bit versions, or may include help files or man pages that are derived/built every time. Removing components that are not necessary for development can dramatically reduce the build time.

Does the build also package the product? Is that really required for development and testing? Does the build incorporate some basic sanity tests that can be skipped?

Finally, you can re-factor the code base to be more modular and to have fewer dependencies. Large Scale C++ Software Design is an excellent reference for learning to decouple large software products into something that is easier to maintain and faster to build.

EDIT: Building on a local filesystem as opposed to a NFS mounted filesystem can also dramatically speed up build times.

by anonymous   2017-08-20

The solution is to make sure your modules form a directed acyclic graph... I.e. if A depends on B, make sure B doesn't depend on A. It takes a lot of discipline but is worth it in the long run.

If you are interested in this stuff, Large Scale C++ Software Design is a good read.

by anonymous   2017-08-20

in Bar.cpp, do we still need to guard the include such as

#ifndef MYPROJ_FOO
#include <Foo.h>
#endif

or simple #include is sufficient?

Simple #include is sufficient from a correctness point of view.

It seems redundant to me to have include guard if we already have header guard, but I see such practice quite often, hence wondering if I'm missing something.

The practice was recommended by John Lakos in his book Large Scale C++ Software Design.

However, a better alternative is to use the #pragma once directive, which is supported by most modern C++ compilers.

Foo.h:

#pragma once
....

Then, you can just use

#include "Foo.h"

in any .cpp file.

by pieterr   2017-08-19
A 21-year old book is dedicated to this subject:

https://www.amazon.com/Large-Scale-Software-Design-John-Lako...