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
> > > > 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
> > 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:
#define FUSION_MAX_VECTOR_SIZE 20
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 hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net