Modern C++ Design: Generic Programming and Design Patte

by anonymous 2019-07-21

This is the school book example of double dispatch, the wikipedia article gives a good description of the problem and the solution:

http://en.wikipedia.org/wiki/Double_dispatch

If I remember correctly there's a very elegant solution to the problem in the book "Modern C++ Design" by Andrei Alexandescu

http://www.amazon.com/Modern-Design-Generic-Programming-Patterns/dp/0201704315

Original Thread

by anonymous 2019-07-21

Since you come from a language that has reflection and are asking about similar capabilities in C++ and, I suggest you should have a look into "Template Meta Programming" and "Policy based design", "Type traits" and the like and thus pushing these decisions out to compile time, compared to reflection.

In your case, I suggest having a look at tagging the classes appropriately, and making these decisions at compile time using the meta programming techniques offered by std::is_same, std::is_base_of, std::is_convertible, std::enable_if and std::conditional

As you seem to be moving to a major refactoring, more good, in-depth resources on this topic would be practically everything by Alexandrescu, Alexandrescu's book, Di Gennaro's book and David Abrahams's book on these techniques.

I especially found these posts insightful in all these matters to start with...

HTH, since TMP is much fun

Original Thread

by anonymous 2019-07-21

There are two ways you could go with that

1) A pool of objects. When you "allocate" you take an object from the pool and when you deallocate you return it back to the pool. This is not that transparent but the implementation is not that hard.

2) Create a custom allocator for your classes/structs. You preallocate the memory in a big buffer and when you need to allocate you take memory from there and when you need to deallocate you return the memory back (the actual mechanism is up to you). This is a bit harder to implement but can be more transparent.

Check the following links for ideas

http://www.drdobbs.com/policy-based-memory-allocation/184402039
http://www.boost.org/doc/libs/1_57_0/doc/html/interprocess/allocators_containers.html
http://en.cppreference.com/w/cpp/memory/allocator
http://yosefk.com/blog/why-custom-allocatorspools-are-hard.html

Also, while you are at it, there is a great book by Alexandrescu

http://www.amazon.com/Modern-Design-Generic-Programming-Patterns/dp/0201704315

a bit old, but exceptional nevertheless and has a section for memory management/allocator.

Original Thread

by anonymous 2019-01-13

Take a look at binary heap. This structure represents a tree inside an array.
Take a look at Aleksandrescu's small object allocator from his book. In the second chapter (AFAIR) he describes a practical approach to embed ~8-~128 bytes long structures inside an external byte array with no overhead.

Original Thread

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)

Original Thread

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.

Original Thread

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.

Original Thread

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.

Original Thread

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

Original Thread

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).

Original Thread

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

_{* 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.

Original Thread

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:

Original Thread

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.

Original Thread

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.

Original Thread

by anonymous 2017-08-20

Take a look at Modern C++ Design by Alexandrescu

http://www.amazon.com/Modern-Design-Generic-Programming-Patterns/dp/0201704315

He covers template implementation of several design patterns. In fact, IIRC, one of the forewards is written by one of the GOF.

Original Thread

by anonymous 2017-08-20

This is probably a great time to use Policy-based design to implement the strategy pattern, especially since you're using C++ and you're probably targeting a compiler older than 2002. (Since C++'s templating mechanism is so awesome, we can get the strategy pattern for free this way!)

First: Make your class accept the strategy/policy class (in this case, your ICameraRenderer) at a template parameter. Then, specify that you are using a certain method from that template parameter. Make calls to that method in the camera class...

Then implement your strategies as a plain old class with a render() method!

This will look something like this:

class Camera<RenderStrategy>{
    using RenderStrategy::render;

    /// bla bla bla 

    public:
        void renderCamera(){  render(cameraModel); }
};

class SpiffyRender{
    public:
        void render(CameraModel orWhateverTheParameterIs){ // some implementation goes somewhere }
};

Whenever you want to make a camera that uses one of those policy/strategies:

// the syntax will be a bit different, my C++ chops are rusty; 
// in general: you'll construct a camera object, passing in the strategy to the template  parameter
auto SpiffyCamera = new Camera<SpiffyRender>();

(Since your renderer strategy doesn't have any state, that makes this approach even more favorable)

If you are changing your renderer all the time, then this pattern / approach becomes less favorable... but if you have a camera that always renders the same way, this is a slightly nicer approach. If your renderer has state, you can still use this method; but you'll want a reference to the instance inside the class, and you won't use the Using:: statement. (In general, with this, you write less boilerplate, don't need to make any assignments or allocations at runtime, and the compiler works for you)

For more about this,see: http://en.wikipedia.org/wiki/Policy-based_design Or read Modern C++ Design... it's a great read, anyways! http://www.amazon.com/Modern-Design-Generic-Programming-Patterns/dp/0201704315

As an unrelated aside: You may want to look into some of the goodness that C++x11 gives you. It'll really clean up your code and make it safer. (Especially the shared/unique/etc ptr classes.)

Original Thread

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

Comments

Beginner

Introductory, no previous programming experience

Introductory, with previous programming experience

Best practices

Intermediate

Advanced

Reference Style - All Levels

Classics / Older