
Peter Dimov wrote:
Eric Niebler:
You, Joel de Guzman, Dan Marsden and I should coordinate. We might be able to use Proto so that the bind placeholders can be shared with the Phoenix placeholders, eliminating this source of confusion once and for all.
Bind can already use any placeholders (and in fact does recognize the Lambda placeholders). No coordination is needed, just a specialization of boost::is_placeholder.
The main problem is that all code that relies on the placeholders being visible will break.
You mean code that requires the placeholders to be at global scope? Why not bring them into the global scope with a using declaration?
A secondary problem I have is that to keep Bind header-only I (think I) need to move to using inline functions instead of objects for _K on all compilers. This will consume one release cycle, during which the global placeholders will be "deprecated". The next release will remove them from the global namespace.
You are talking about ODR violations in code that refers to const objects at namespace scope? There are ways around this problem.... namespace boost { namespace placeholders { template<class I> struct placeholder_instance { placeholder<I> const value; }; // statically initialized ... template<class I> placeholder<I> const placeholder_instance<I>::value = {{}}; namespace { // This reference should also be statically initialized placeholder<mpl::int_<1> > const & _1 = placeholder_instance<mpl::int_<1> >::value; } }} // for back-compatibility ... using boost::placeholders::_1; Now every use of _1 refers to the same object, even across translation units, and it's all header-only. Not all compilers support this yet, but Dave and I fought to get this approved for C++0x. For older compilers, I think we can live with the ODR, as these objects will be stateless (identity doesn't matter). If placeholder<> is an appropriately-defined Proto terminal, then it can be reused in Phoenix.
But if there's a Boost-wide header that defines _K, I can easily make Bind use it.
I think it should all be possible. -- Eric Niebler BoostPro Computing http://www.boostpro.com