Modern C++ Design: Generic Programming and Design Patterns Applied

Author: Andrei Alexandrescu
4.4
All Hacker News 7
This Year Stack Overflow 3
This Month Stack Overflow 3

Modern C++ Design: Generic Programming and Design Patterns Applied

4.4

Review Date:

Comments

by anonymous   2018-04-02

The weak_ptr need to point to something that can tell if the object exist or not so it knows if it can be converted to a shared_ptr. Therefore a small object is needed to housekeep this information.

This housekeeping control block needs to be destroyed when the last week_ptr (or shared_ptr) is removed. Therefore it has to keep count of both the shared_ptr and the week_ptr's.

Note that the housekeeping control block is not the same as the object the ptr's point to and therefore the week_ptr do not affect the objects lifetime.

There is a bunch of different ways to implement smart pointers depending on what behavior you would like it to have. If you want to know more I would recommend "Modern C++ Design" by Alexandrescu (https://www.amazon.com/Modern-Design-Generic-Programming-Patterns/dp/0201704315)

by anonymous   2018-03-19

Another option is that you use std::shared_ptr in Foo, to hold a Bar reference, and then a std::weak_ptr to hold references to Foo from Bar.

Edit: I believe what I recommend is the one closest to the spirit of how the std smart pointers are meant to be used. You should use unique_ptr / shared_ptr to delineate (and enforce) ownership, and weak_ptr when you want to hold a reference to an object in a class that does not own it. This way you can avoid using naked pointers entirely.

Using weak_ptr requires that you also use shared_ptr, since weak_ptr's cannot be created from unique_ptr's, but even if only ever one class holds a shared_ptr to the object in question, that is still in the spirit of how they are intended to be used.

Regarding M.M.'s point on ownership semantics, either shared or unique ptr signify ownership, while weak_ptr signifies a reference, so this is still fine.

Another two tips towards this architecture:

A: You could create your classes in a Factory, having their relations defined through setters, rather than each class handling the creation of its children (Dependency Injection). Ideally you could follow Alexandrescu's tips on the Factory design.

Alternatively B: You could use the named constructor idiom, with public static create(...) methods doing the actual constructing, to circumvent the error that occurs due to the class being incomplete during construction.

But I'd rather recommend alternative A here.

by Simon Hughes   2018-03-19

Meyers is OK, however, if you really want to push yourself, you have to read:

Andrei Alexandrescu - Modern C++ Design: Generic Programming and Design Patterns Applied

It will blow your mind. What you learn in the book describes the Loki library.

One of my favourites is the int-to-type conversions:

template <int v>
struct Int2Type
{
    enum { value = v };
};

I've used it in the past for my C++ XML serialisation library for pre-allocating vector<>'s before loading them with data:

// We want to call reserve on STL containers that provide that function,
// namely std::vector.
// However, we would get a compiler error if we tried to call reserve on
// an STL container that
// did not provide this function. This is the solution.
template <bool b, class T>
class CReserve
{
public:
    static void reserve(T &lst, const int &n)
    { reserve(lst, n, Loki::Int2Type<b>()); }

private:
    static void reserve(T &lst, const int &n, Loki::Int2Type<true>)
    { lst.reserve(n); }

    static void reserve(T &lst, const int &n, Loki::Int2Type<false>)
    { (void)lst; (void)n; }
};

Notice the private specialisations above. Well, if you look closely, one calls reserve(), and the other doesn't. This is a template specialisation using a bool as a type.

which in turn is used by:

template <bool bCallReserve, class T>
bool STLSerializeClassType(MSXML::IXMLDOMNodePtr pCurNode, T &lst,
                           CXmlArchive &archive, const char *name)
{
    if(archive.IsStoring())
    {
        ...
    } else {
        lst.clear();

        T::size_type nCount(0);
        XML_ELEMENT(nCount);

        CReserve<bCallReserve, T>::reserve(lst, nCount);

        while(nCount--)
        {
            T::value_type temp;
            temp.SerializeXml(archive, pCurNode);
            lst.push_back(temp);
        }
    }
}

To make things simple in users' C++ code, I added a lot of helper definitions:

#define SERIALIZE_XML_STL_CLASS(list_name, bCallReserve) \
(HS::STLSerializeClassType<(bCallReserve)>
    (pCurNode, (list_name), archive, (#list_name))
)

So in your code you'd use something like:

std::list<CFred> fredList;
SERIALIZE_XML_STL_CLASS(fredList, false);

Or for vectors:

vector<CFred> fredList;
SERIALIZE_XML_STL_CLASS(fredList, true);

Anyway, I'll stop wittering on... That's just putting the simple Int2Type<> template to good use. There are loads of clever stuff like getting the compiler to compute a ton of stuff beforehand by clever use of enums. It is a truly awesome book.

by wnissen   2017-08-20
He understands C++ well enough to have written "Modern C++ Design" ( ) back in 2001. If he's interested in D, so am I.
by chollida1   2017-08-20
I think this might be well traveled ground now, but people always ask me what I'd recommend to learn good C++ style.

http://www.amazon.ca/The-Design-Evolution-Bjarne-Stroustrup/...

and

http://www.amazon.ca/Modern-Design-Generic-Programming-Patte...

are my two favorite books. And then if you aren't happy with these books this stackoverflow link has more books than you could ever want:

http://stackoverflow.com/q/388242/25981

This link from Microsoft is also pretty darn good:

https://msdn.microsoft.com/en-us/library/hh279654.aspx

by drothlis   2017-08-20
If you're coming from C, then you need to understand the STL's concepts of "Concepts", "Modeling", "Refinement", and Iterators etc: http://www.sgi.com/tech/stl/index.html (that link doesn't cover C++11, nor even the STL additions in C++03 and TR1; but it is still essential background reading).

When some people say "Modern C++" they mean template meta-programming (traits, partial template specialisation, etc) as exemplified by Alexandrescu's book "Modern C++ design": http://www.amazon.com/Modern-Design-Generic-Programming-Patt... (note that I am not necessarily advocating such techniques, but understanding them will certainly help when you run across them in the wild).

by litb   2017-08-20

Beginner

Introductory, no previous programming experience

  • Programming: Principles and Practice Using C++ (Bjarne Stroustrup) (updated for C++11/C++14) An introduction to programming using C++ by the creator of the language. A good read, that assumes no previous programming experience, but is not only for beginners.

Introductory, with previous programming experience

  • C++ Primer * (Stanley Lippman, Josée Lajoie, and Barbara E. Moo) (updated for C++11) Coming at 1k pages, this is a very thorough introduction into C++ that covers just about everything in the language in a very accessible format and in great detail. The fifth edition (released August 16, 2012) covers C++11. [Review]

  • A Tour of C++ (Bjarne Stroustrup) (EBOOK) The “tour” is a quick (about 180 pages and 14 chapters) tutorial overview of all of standard C++ (language and standard library, and using C++11) at a moderately high level for people who already know C++ or at least are experienced programmers. This book is an extended version of the material that constitutes Chapters 2-5 of The C++ Programming Language, 4th edition.

  • Accelerated C++ (Andrew Koenig and Barbara Moo) This basically covers the same ground as the C++ Primer, but does so on a fourth of its space. This is largely because it does not attempt to be an introduction to programming, but an introduction to C++ for people who've previously programmed in some other language. It has a steeper learning curve, but, for those who can cope with this, it is a very compact introduction into the language. (Historically, it broke new ground by being the first beginner's book to use a modern approach at teaching the language.) [Review]

  • Thinking in C++ (Bruce Eckel) Two volumes; is a tutorial style free set of intro level books. Downloads: vol 1, vol 2. Unfortunately they’re marred by a number of trivial errors (e.g. maintaining that temporaries are automatically const), with no official errata list. A partial 3rd party errata list is available at (http://www.computersciencelab.com/Eckel.htm), but it’s apparently not maintained.

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

Best practices

  • Effective C++ (Scott Meyers) This was written with the aim of being the best second book C++ programmers should read, and it succeeded. Earlier editions were aimed at programmers coming from C, the third edition changes this and targets programmers coming from languages like Java. It presents ~50 easy-to-remember rules of thumb along with their rationale in a very accessible (and enjoyable) style. For C++11 and C++14 the examples and a few issues are outdated and Effective Modern C++ should be preferred. [Review]

  • Effective Modern C++ (Scott Meyers) This is basically the new version of Effective C++, aimed at C++ programmers making the transition from C++03 to C++11 and C++14.

  • Effective STL (Scott Meyers) This aims to do the same to the part of the standard library coming from the STL what Effective C++ did to the language as a whole: It presents rules of thumb along with their rationale. [Review]

Intermediate

  • More Effective C++ (Scott Meyers) Even more rules of thumb than Effective C++. Not as important as the ones in the first book, but still good to know.

  • Exceptional C++ (Herb Sutter) Presented as a set of puzzles, this has one of the best and thorough discussions of the proper resource management and exception safety in C++ through Resource Acquisition is Initialization (RAII) in addition to in-depth coverage of a variety of other topics including the pimpl idiom, name lookup, good class design, and the C++ memory model. [Review]

  • More Exceptional C++ (Herb Sutter) Covers additional exception safety topics not covered in Exceptional C++, in addition to discussion of effective object oriented programming in C++ and correct use of the STL. [Review]

  • Exceptional C++ Style (Herb Sutter) Discusses generic programming, optimization, and resource management; this book also has an excellent exposition of how to write modular code in C++ by using nonmember functions and the single responsibility principle. [Review]

  • C++ Coding Standards (Herb Sutter and Andrei Alexandrescu) “Coding standards” here doesn't mean “how many spaces should I indent my code?” This book contains 101 best practices, idioms, and common pitfalls that can help you to write correct, understandable, and efficient C++ code. [Review]

  • C++ Templates: The Complete Guide (David Vandevoorde and Nicolai M. Josuttis) This is the book about templates as they existed before C++11. It covers everything from the very basics to some of the most advanced template metaprogramming and explains every detail of how templates work (both conceptually and at how they are implemented) and discusses many common pitfalls. Has excellent summaries of the One Definition Rule (ODR) and overload resolution in the appendices. A second edition is scheduled for 2017. [Review]


Advanced

  • Modern C++ Design (Andrei Alexandrescu) A groundbreaking book on advanced generic programming techniques. Introduces policy-based design, type lists, and fundamental generic programming idioms then explains how many useful design patterns (including small object allocators, functors, factories, visitors, and multimethods) can be implemented efficiently, modularly, and cleanly using generic programming. [Review]

  • C++ Template Metaprogramming (David Abrahams and Aleksey Gurtovoy)

  • C++ Concurrency In Action (Anthony Williams) A book covering C++11 concurrency support including the thread library, the atomics library, the C++ memory model, locks and mutexes, as well as issues of designing and debugging multithreaded applications.

  • Advanced C++ Metaprogramming (Davide Di Gennaro) A pre-C++11 manual of TMP techniques, focused more on practice than theory. There are a ton of snippets in this book, some of which are made obsolete by typetraits, but the techniques, are nonetheless useful to know. If you can put up with the quirky formatting/editing, it is easier to read than Alexandrescu, and arguably, more rewarding. For more experienced developers, there is a good chance that you may pick up something about a dark corner of C++ (a quirk) that usually only comes about through extensive experience.


Reference Style - All Levels

  • The C++ Programming Language (Bjarne Stroustrup) (updated for C++11) The classic introduction to C++ by its creator. Written to parallel the classic K&R, this indeed reads very much alike it and covers just about everything from the core language to the standard library, to programming paradigms to the language's philosophy. [Review]

  • C++ Standard Library Tutorial and Reference (Nicolai Josuttis) (updated for C++11) The introduction and reference for the C++ Standard Library. The second edition (released on April 9, 2012) covers C++11. [Review]

  • The C++ IO Streams and Locales (Angelika Langer and Klaus Kreft) There's very little to say about this book except that, if you want to know anything about streams and locales, then this is the one place to find definitive answers. [Review]

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.

  • The Design and Evolution of C++ (Bjarne Stroustrup) If you want to know why the language is the way it is, this book is where you find answers. This covers everything before the standardization of C++.

  • Ruminations on C++ - (Andrew Koenig and Barbara Moo) [Review]

  • Advanced C++ Programming Styles and Idioms (James Coplien) A predecessor of the pattern movement, it describes many C++-specific “idioms”. It's certainly a very good book and might still be worth a read if you can spare the time, but quite old and not up-to-date with current C++.

  • Large Scale C++ Software Design (John Lakos) Lakos explains techniques to manage very big C++ software projects. Certainly a good read, if it only was up to date. It was written long before C++98, and misses on many features (e.g. namespaces) important for large scale projects. If you need to work in a big C++ software project, you might want to read it, although you need to take more than a grain of salt with it. The first volume of a new edition is expected in 2015.

  • Inside the C++ Object Model (Stanley Lippman) If you want to know how virtual member functions are commonly implemented and how base objects are commonly laid out in memory in a multi-inheritance scenario, and how all this affects performance, this is where you will find thorough discussions of such topics.

  • The Annotated C++ Reference Manual (Bjarne Stroustrup, Margaret A. Ellis) This book is quite outdated in the fact that it explores the 1989 C++ 2.0 version - Templates, exceptions, namespaces and new casts were not yet introduced. Saying that however, this book goes through the entire C++ standard of the time explaining the rationale, the possible implementations and features of the language. This is not a book to learn programming principles and patterns on C++, but to understand every aspect of the C++ language.

by anonymous   2017-08-20

The thing to keep in mind here is templates are different from language features like generics in languages like C#.

It is a fairly safe simplification to think of templates as an advanced preprocessor that is type aware. This is the idea behind Template metaprogramming (TMP) which is basically compile time programming.

Much like the preprocessor templates are expanded and the result goes through all of the same optimization stages as your normal logic.

Here is an example of rewritting your logic in a style more consistent with TMP. This uses function specialization.

template<bool X>
double foo(double x);

template<>
double foo<true>(double x)
{
    return moo(x);
}

template<>
double foo<false>(double x)
{
    return bar(x);
}

TMP was actually discovered as a happy accident and is pretty much the bread and butter of the STL and Boost.

It is turing complete so you can do all sorts of computation at compile time.

It is lazily evaluated so you could implement your own compile time asserts by putting invalid logic in a specialization of a template that you don't want to be used. For example if I were to comment out the foo<false> specialization and tried to use it like foo<false>(1.0); the compiler would complain, although it would be perfectly happy with foo<true>(1.0);.

Here is another Stack Overflow post that demonstrates this.

Further reading if interested:

  1. Modern C++ Design
  2. C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond
  3. Effective C++
by anonymous   2017-08-20

A singleton instance has the same thread safety issues as any other instance, so calls to its methods or access to its members should be synchronized.

The initialization of the singleton itself is another issue...in gcc static initialization is threadsafe, but probably not so much on other platforms.

Also take a look at this paper addressing some threading singleton issues by Andrei Alexandrescu. His Modern C++ Design book also addresses singleton issues.

by anonymous   2017-08-20

Is there any reason why you are not using dynamic dispatch for the computecost function?

The simplest thing would be creating a inheritance hierarchy and just using dynamic dispatch. Each type in the hierarchy that would return mxINT8_CLASS as class id would implement computecost as a call to computecost<signed char>, and similarly for all of the other combinations.

If there is a strong reason not to use dynamic dispatch, you might consider implementing your own dynamic dispatch in different ways. The most obvious, simple and probably easier to maintain is what you already have. Slightly more complex can be done with macros, or you can try a templated version just for fun...

The macro solution (next one in complexity) could use a macro to define the relationship, another to define each case and then combine them:

#define FORALL_IDS( macro ) \
   macro( mxINT8_CLASS, signed char ); \
   macro( mxUINT8_CLASS, unsigned char ); \
// ...

#define CASE_DISPATCH_COMPUTECOST( value, type ) \
   case value: computecost<type>( T, offT, Offset, CostMatrix ); break

Combine:

switch ( category ) {
   FORALL_IDS( CASE_DISPATCH_COMPUTECOST );
};

I have seen this done in the past, and don't like it, but if there is a good amount of places where you need to map from the category to the type that could be a simple to write hard to maintain solution. Also note that the FORALL_IDS macro can be used to implement metaprogramming traits that map from the enum to the type and vice versa:

template <classId id>
struct type_from_id;
#define TYPE_FROM_ID( id, T ) \
   template <> struct type_from_id<id> { typedef T type; }
FORALL_IDS( TYPE_FROM_ID );
#undef TYPE_FROM_ID

template <typename T>
struct id_from_type;
#define ID_FROM_TYPE( id, T ) \
   template <> struct id_from_type<T> { static const classId value = id; }
FORALL_IDS( ID_FROM_TYPE );
#undef ID_FROM_TYPE

Note that this has a lot of drawbacks: macros are inherently unsafe, and this macros more so, as they define types and don't quite behave like functions, it is harder to find the appropriate amount of parenthesis to the arguments, which makes it more prone to all shorts of errors in text substitution... Macros don't know about contexts, so you might want to try and minimize the scope by undefining them right after use. Implementing the traits above is one good way to go about it: create the macro, use that to generate templated non-macro code, undef the macros. The rest of the code can use the templates rather than the macros to map from one to the other.

A different way of implementing dynamic dispatch is using a lookup table instead of the switch statement above:

typedef T function_t( T1, T2, T3 ); // whatever matches the `computecost` signature
function_t *lookup[ categories ];   // categories is 1+highest value for the category enum

You can manually initialize the lookup table, or you can use a macro as above, the complexity of the code will not change much, just move from the calling side to wherever the lookup table is initialized. On the caller side you would just do:

lookup[ mxGetClassID(prhs) ]( T, offT, Offset, CostMatrix );

Instead of the switch statement, but don't get fooled, the cost has not be removed, just pushed to the initialization (which might be good if you need to map more than one function, as you could create a struct of function pointers and perform the initialization of all at once, and there you have your own manually tailored vtable, where instead of a vptr you use the classId field to index.

The templated version of this is probably the most cumbersome. I would try to implementing just for the fun of it, but not really use it in production code. You can try building the lookup table from a template[1], which is fun as an exercise but probably more complex than the original problem.

Alternatively, you can implement a type-list type of approach (A la Modern C++ Design) and in each one of the nodes dispatch to the appropriate function. This is probably not worth the cost, and will be a nightmare to maintain in the future, so keep away from it from production code.

To sum up:

Just use the language dynamic dispatch, that is your best option. If there is a compelling reason not too, balance the different options and complexities. Depending on how many places you need to perform the dispatch from classId to X (where X is computecost here but could be many more things), consider using a hand tailored lookup table that will encapsulate all X operations into a function table --note that at this point, whatever the motives to avoid the vtable might have gone away: you are manually, and prone to errors implemented the same beast!

[1] The complexity in this case is slightly higher, because of the mapping from the enum to the types, but it should not be much more complex.