Boost Users :
Subject: Re: [Boost-users] Signals2 benchmark
From: Nevin Liber (nevin_at_[hidden])
Date: 2015-02-10 11:15:16
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
> > 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
[basic.def.odr] to read the specifics of what the standard says about it.
It's fundamental to C++.
> To appreciate where you are
> coming from, I assume you have at least built boost and have worked
> with it to some extent?
> > 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.
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.
-- 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