On 10 February 2015 at 06:49, Michael Powell <mwpowellhtx@gmail.com> 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++.
 
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.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404