Boost Users :
Subject: Re: [Boost-users] Signals2 benchmark
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-02-10 08:23:45
On 10 Feb 2015 at 1:07, Nevin Liber wrote:
> > > 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 <
> 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.
Assuming you actually want an answer here and are not baiting for the
sake of it as usual ...
Your example above requires much more than a useful ABI break as was
originally being discussed. A compile time selectable option for
whether thread safety is there or not can be easily encoded into a
boolean at the end of every template parameter, or via a compile time
thunk to two internal implementation namespaces.
If you have C++ 11, you can even let code change
FUSION_MAX_VECTOR_SIZE during compilation and get multiple Fusions
in the same translation unit if Fusion were built on top of my
BindLib framework. Each Fusion would not work with any other however
without additional bridge code. If you want a taste of the macro
programming involved for multi-ABI-in-the-same-TU use of BindLib,
However what you ask for is the ability to have the compiler
regenerate code on the basis of a compile time option change. One
approach is to type erase code which needs to be regenerated such
that it can pass through precompiled parts, and thunk out via a
virtual function back into just in time compiler assembled
functionality. It's a lot of hassle, but std::function and std::bind
make it work.
Past that though, sans C++ Modules or performing magic via dynamic
JIT recompilation of clang ASTs, I don't believe it is
straightforward no. That's a language limitation of statically
compiled languages with the evolution of toolset we currently have.
You might find my 2014 C++ Now paper of interest here, I exactly
envisaged a future C++ toolset which could do exactly as you want.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
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