Re: [Boost-users] Signals2 benchmark

Subject: Re: [Boost-users] Signals2 benchmark
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2015-02-10 11:53:47

On Tue, Feb 10, 2015 at 10:15 AM, Nevin Liber <nevin_at_[hidden]> wrote:
> On 10 February 2015 at 06:49, Michael Powell <mwpowellhtx_at_[hidden]> wrote:
>>
>> >
>> > #define FUSION_MAX_VECTOR_SIZE 20
>>
>> I could be wrong, but isn't Fusion (or Spirit, etc) header-only?
>
>
> Yes, but I'm not sure what that has to do with solving the ODR violation
> problem.  Quite the opposite; it contributes to the problem.
>
>>
>> > 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?
>
> ODR, or One Definition Rule, basically says that you cannot redefine a
> function or class within a program.  See
> <http://en.cppreference.com/w/cpp/language/definition> for a more detailed
> explanation, or N4296 section [basic.def.odr] to read the specifics of what
> the standard says about it.  It's fundamental to C++.

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.

>> To appreciate where you are
>> coming from, I assume you have at least built boost and have worked
>> with it to some extent?
>
>
> Yes.
>
>>
>> > This is a huge problem with global flags.
>>
>> I don't think it's the mountain you think it is.
>
>
> Oh?
>
>>
>> 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.
>
>
> I don't see how any of that addresses the problem I mentioned.  If I use a
> third party library that
>
> #define FUSION_MAX_VECTOR_SIZE 20
>
> and I need to
>
> #define FUSION_MAX_VECTOR_SIZE 50
>
> how does that not lead to an ODR violation?  This is still an issue even if
> that third party library only used Boost.Fusion in its implementation.

It sounds to me as though there are secondary, or even tertiary+,
dependencies involved. You would need cooperation from your vendor, or
access to the source, in order to do what you want it seems.

HTH

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