Boost logo

Boost Users :

Subject: Re: [Boost-users] Signals2 benchmark
From: Nevin Liber (nevin_at_[hidden])
Date: 2015-02-10 02:07:49

On 9 February 2015 at 19:00, Niall Douglas <s_sourceforge_at_[hidden]>

> On 8 Feb 2015 at 19:25, Nevin Liber wrote:
> > > > Is it reallistic that folks would want a variant of signals that's
> not
> > > > threadsafe, trading some callback restrictions for performance?
> > >
> > > I think a version which is compile time switchable is the ideal.
> > >
> >
> > -1.
> >
> > Unless you can always build everything from source (as opposed to linking
> > against libraries built by others), this becomes a nightmare when trying
> to
> > avoid ODR violations.
> It would be a very poor implementation that had that problem Nevin.

Parts of Boost *already* have that problem.

Suppose I'm using Boost.Fusion, and I need a 50 element Fusion vector. If
I want to change that, the documentation <>

You may define the preprocessor constant FUSION_MAX_VECTOR_SIZE before
including any Fusion header to change the default. Example:


So, without rebuilding the entire world, how do I increase the maximum size
of a Fusion vector without an ODR violation??

This is a huge problem with global flags.

[Note: I am not criticizing Boost.Fusion here, as they really didn't have
a choice in a pre-variadic template world.]

> You'd almost certainly use namespaces or template parameters to make
> symbol unique the two implementations.

Again, how do you do this if you are using compile time switches? Please
post some sample code showing the technique you envision for users.

 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  (847) 691-1404

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at