Re: [Boost-users] Signals2 benchmark

Subject: Re: [Boost-users] Signals2 benchmark
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2015-02-10 07:49:21

On Tue, Feb 10, 2015 at 1:07 AM, Nevin Liber <nevin_at_[hidden]> wrote:
> On 9 February 2015 at 19:00, Niall Douglas <s_sourceforge_at_[hidden]>
> wrote:
>>
>> 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
> <http://www.boost.org/doc/libs/1_57_0/libs/fusion/doc/html/fusion/container/vector.html>
> says:
>
> 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

I could be wrong, but isn't Fusion (or Spirit, etc) header-only?

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

I'm not sure what you mean, ODR violation? To appreciate where you are
coming from, I assume you have at least built boost and have worked
with it to some extent?

>From experience, the Boost parts that are 'static' in nature (whether
the actual libs themselves are static or dynamic) are built once.
Anything else is usually header only, calling upon those static parts
(i.e. for threading).

Also from experience, the Boost maintainers do a pretty good job
keeping a sane compile-vs-header only boundary.

> This is a huge problem with global flags.

I don't think it's the mountain you think it is.

Once you build the Boost libs in an iteration, or application life
cycle, unless there's been a Boost patch or upgrade, you generally
never need to touch it again.

Everything else is header-only. Yes, you sometimes declare fully or
partially specialized templates (or at least, I do), but this is a
'trivial' part of using template header-only resources.

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

AFAIK, compile time switches are injected via whatever project headers
you are using. In a Microsoft Visual C++ world, for example, that is
the *vcsproj* file, to my knowledge, usually via project settings. But
once these are established, you focus can (and should) be on the
problem solution / application at hand.

> --
>  Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users