Re: [Boost-users] Signals2 benchmark

Subject: Re: [Boost-users] Signals2 benchmark
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2015-02-10 17:22:20

On Tue, Feb 10, 2015 at 11:53 AM, Michael Powell <mwpowellhtx_at_[hidden]> wrote:
>
> ODR itself I understand. To my knowledge, you can't apply it to
> template, header only libraries.
>
> Abandon your notion of ODR. Where Fusion, Spirit, etc, are concerned,
> AFAIK, it's irrelevant. These are C++ template-based, which means by
> definition, their 'definition' may be different from instance to
> instance, but the underlying pattern is consistent, interface driven,
> etc. That's a fundamental SOLID principle.
>

1. I assure you Nevin understands ODR (as much as anyone understands
C++ - no one is an expert).  Let's give him that much.
2. Fusion/Spirit/templates/... maybe, but in general "header only"
doesn't mean no ODR issues.  The answer really is "it depends".

ie

template <typename T> struct SboContainer
{
    T sbo[SBO_SMALL_AMOUNT];
    T * more;
   ...
};

Imagine the above is a template for a container that uses a "small
buffer optimization" - for a small number of elements, they are local.
For more elements, it allocates.
Now imagine that SBO_SMALL_AMOUNT is a #define.
Now imagine that foo.cpp and bar.cpp both use SboContainer<int>, but
foo.cpp #defines SBO_SMALL_AMOUNT differently than bar.cpp (before
#including SboContainer.hpp).
Now imagine that foo.cpp passes a SboContainer<int> & to bar.cpp...
Bad things happen.  ODR violation, undefined behaviour, cats getting
pregnant, etc.

Conversely, if we instead do

template <typename T, size_t BuffSize = SBO_SMALL_AMOUNT> struct SboContainer
{
    T sbo[BuffSize];
    T * more;
   ...
};

now SboContainer<int> from foo.cpp and SboContainer<int> from bar.cpp
may actually be different *types*, and instead of a runtime crash we
get a compile/link time error. Yay.

Parts of Boost have these ODR issues if you are not careful.  Other
parts don't.  So you need to "do it right" when designing/implementing
the API.
It sounds like Nigel has convinced Nevin that for a hypothetical
thread-safe + non-thread-safe "Signals3", we could/would do it the
right way.

Tony