[mpl][ref] typeof registrations
In order for BOOST_TYPEOF to work with xpressive's static regexes (something I'm actively trying to support), I need registrations for reference_wrapper<> and mpl::int_<>. I'm happy to add them, but I'm not sure where. Thoughts? -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> wrote
In order for BOOST_TYPEOF to work with xpressive's static regexes (something I'm actively trying to support), I need registrations for reference_wrapper<> and mpl::int_<>. I'm happy to add them, but I'm not sure where. Thoughts?
Looks like the model where authors are responsible for registering their own classes dosn't work quite well... Maybe there should be a designated place with collective ownership, where interested users could add such registrations? This place could mimique the boost directory structure, to avoid conflicts, something like: typeof_registrations mpl bind xpressive spirit ... Regards, Arkadiy
On Sat, 2007-10-27 at 11:08 -0400, Arkadiy Vertleyb wrote:
"Eric Niebler" <eric@boost-consulting.com> wrote
In order for BOOST_TYPEOF to work with xpressive's static regexes (something I'm actively trying to support), I need registrations for reference_wrapper<> and mpl::int_<>. I'm happy to add them, but I'm not sure where. Thoughts?
Looks like the model where authors are responsible for registering their own classes dosn't work quite well... Maybe there should be a designated place with collective ownership, where interested users could add such registrations? This place could mimique the boost directory structure, to avoid conflicts, something like:
typeof_registrations mpl bind xpressive spirit ...
There are several libraries that have this kind of problem. typeof needs registrations, serialization needs serialize() functions, MPI needs datatype traits, etc. I wonder if we can solve this problem for all of Boost with some kind of automatic scheme that says: if you include header A from one library and header B from another library, you automatically get whatever glue makes A and B work well together. It's relatively simple to implement this for two headers. In header A you have: #ifdef HEADER_B_INCLUDED # include <glue_a_and_b.hpp> #endif In header B you have: #ifdef HEADER_A_INCLUDED # include <glue_a_and_b.hpp> #endif For the general case, we would probably want a "glue" subdirectory whose directory mimics the Boost directory structure (like a generalized version of your typeof_registrations suggestion). Each header in "glue" would have a bunch of #ifdef's checking all of the various other library/header names and including the appropriate glue code. Overall, it's O(N^2) work in the number of data structures/headers/libraries (depending on how we chop it up), but users would get all of the important glue "for free". - Doug
Douglas Gregor wrote:
On Sat, 2007-10-27 at 11:08 -0400, Arkadiy Vertleyb wrote:
"Eric Niebler" <eric@boost-consulting.com> wrote
In order for BOOST_TYPEOF to work with xpressive's static regexes (something I'm actively trying to support), I need registrations for reference_wrapper<> and mpl::int_<>. I'm happy to add them, but I'm not sure where. Thoughts? <snip>
There are several libraries that have this kind of problem. typeof needs registrations, serialization needs serialize() functions, MPI needs datatype traits, etc. I wonder if we can solve this problem for all of Boost with some kind of automatic scheme that says: if you include header A from one library and header B from another library, you automatically get whatever glue makes A and B work well together.
It's relatively simple to implement this for two headers. In header A you have:
#ifdef HEADER_B_INCLUDED # include <glue_a_and_b.hpp> #endif
In header B you have:
#ifdef HEADER_A_INCLUDED # include <glue_a_and_b.hpp> #endif
I don't think this is a very good idea. Take a really basic example like boost/ref.hpp, that is included *everywhere*. Are you really going to add PP blocks like this to ref.hpp for every library in boost that includes it? That would be almost every library in Boost, and it would be an continuing maintenance problem for the author of ref.hpp. I think the better solution is the one Arkadiy suggested ... that there is a dedicated place for such registrations so interested parties can add them if they need them. I'd be happy with his suggestion of $BOOST_ROOT/boost/typeof_registrations/<library>/. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler:
I think the better solution is the one Arkadiy suggested ... that there is a dedicated place for such registrations so interested parties can add them if they need them.
The various registrations are indeed the responsibility of the library authors but they will probably not happen unless it is possible to make said registrations without including a foreign header and in a risk-free manner.
Peter Dimov wrote:
Eric Niebler:
I think the better solution is the one Arkadiy suggested ... that there is a dedicated place for such registrations so interested parties can add them if they need them.
The various registrations are indeed the responsibility of the library authors but they will probably not happen unless it is possible to make said registrations without including a foreign header and in a risk-free manner.
Peter, I'm not exactly sure what you're arguing for here. Can you be more specific? -- Eric Niebler Boost Consulting www.boost-consulting.com
Peter Dimov wrote:
Eric Niebler:
I think the better solution is the one Arkadiy suggested ... that there is a dedicated place for such registrations so interested parties can add them if they need them.
The various registrations are indeed the responsibility of the library authors but they will probably not happen unless it is possible to make said registrations without including a foreign header and in a risk-free manner.
Peter, I'm not exactly sure what you're arguing for here. Can you be more specific?
Hm. I think I'm arguing for a documented registration interface that looks like this: namespace boost { namespace type_of { template< class V, class T > struct encode_type; template<> struct encode_type< whatever-is-required > { whatever-is-required; }; } // namespace type_of } // namespace boost I've no idea how practical is that.
Peter Dimov wrote:
Peter Dimov wrote:
Eric Niebler:
I think the better solution is the one Arkadiy suggested ... that there is a dedicated place for such registrations so interested parties can add them if they need them. The various registrations are indeed the responsibility of the library authors but they will probably not happen unless it is possible to make said registrations without including a foreign header and in a risk-free manner. Peter, I'm not exactly sure what you're arguing for here. Can you be more specific?
Hm.
I think I'm arguing for a documented registration interface that looks like this:
namespace boost {
namespace type_of {
template< class V, class T > struct encode_type;
template<> struct encode_type< whatever-is-required > { whatever-is-required; };
} // namespace type_of
} // namespace boost
I've no idea how practical is that.
I'm confused. There already is a documented registration interface (involving macros). The question is where to put the registrations. Consider that if I consume library X and need X::Y to be registered, I could put the registration in my code, but if everybody did that it would be chaos. Have I misunderstood your suggestion? -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler:
I think I'm arguing for a documented registration interface that looks like this:
namespace boost {
namespace type_of {
template< class V, class T > struct encode_type;
template<> struct encode_type< whatever-is-required > { whatever-is-required; };
} // namespace type_of
} // namespace boost
I've no idea how practical is that.
I'm confused. There already is a documented registration interface (involving macros).
Yes. The current registration interface requires me to #include <boost/typeof.hpp>, then #include BOOST_TYPEOF_SOMETHING(), then use a macro. These headers in turn include MPL headers, PP headers and who knows what else. I'm saying that if the registration interface did not require me to include any header, then I'd be willing to register all my types and templates at the point of their definition.
"Peter Dimov" <pdimov@pdimov.com> wrote in message news:01bf01c81a67$bc9ae2c0$6407a80a@pdimov2...
The current registration interface requires me to #include <boost/typeof.hpp>, then #include BOOST_TYPEOF_SOMETHING(), then use a macro. These headers in turn include MPL headers, PP headers and who knows what else.
I'm saying that if the registration interface did not require me to include any header, then I'd be willing to register all my types and templates at the point of their definition.
Rather than registering your types and templates at their point of definition, I think it's better to put them in a separate header file. That header file is only needed by a user whose compiler doesn't provide a native typeof operator or an exploit of a compiler bug to discover types. So far, we've been lucky (and smart) enough to discover MSVC bugs that eliminate the need for typeof registrations on those compilers. But if Microsoft were to fix the bug in a service pack, we'd be SOL without type registrations. So why not have each library create a file in $BOOST_ROOT/boost/typeof_registrations named "MyLibrary_typeof.hpp". The file would (1) include the <boost/typeof/typeof.hpp> header, (2) include the <boost/typeof_registrations/OtherLibrary_typeof.hpp> files for libraries that it uses and (3) specify all of its own type and template registrations.
From: "Peter Dimov" <pdimov@pdimov.com>
The current registration interface requires me to #include <boost/typeof.hpp>, then #include BOOST_TYPEOF_SOMETHING(), then use a macro. These headers in turn include MPL headers, PP headers and who knows what else.
I'm saying that if the registration interface did not require me to include any header, then I'd be willing to register all my types and templates at the point of their definition.
I seriously doubt that you'd be really willing to register your templates without the dependency on PP ;-) Regards, Arkadiy
On Oct 29, 2007, at 11:08 AM, Eric Niebler wrote:
Douglas Gregor wrote:
On Sat, 2007-10-27 at 11:08 -0400, Arkadiy Vertleyb wrote:
"Eric Niebler" <eric@boost-consulting.com> wrote
In order for BOOST_TYPEOF to work with xpressive's static regexes (something I'm actively trying to support), I need registrations for reference_wrapper<> and mpl::int_<>. I'm happy to add them, but I'm not sure where. Thoughts? <snip>
There are several libraries that have this kind of problem. typeof needs registrations, serialization needs serialize() functions, MPI needs datatype traits, etc. I wonder if we can solve this problem for all of Boost with some kind of automatic scheme that says: if you include header A from one library and header B from another library, you automatically get whatever glue makes A and B work well together. [snip]
I don't think this is a very good idea. Take a really basic example like boost/ref.hpp, that is included *everywhere*. Are you really going to add PP blocks like this to ref.hpp for every library in boost that includes it? That would be almost every library in Boost, and it would be an continuing maintenance problem for the author of ref.hpp.
Well, for every library that has traits that need to be specialized for many of Boost's types.
I think the better solution is the one Arkadiy suggested ... that there is a dedicated place for such registrations so interested parties can add them if they need them. I'd be happy with his suggestion of $BOOST_ROOT/boost/typeof_registrations/<library>/.
Right, but we'll then need $BOOST_ROOT/boost/serialization/ <library>/, and $BOOST_ROOT/boost/mpi/<library>/, and so on. Doug
AMDG Douglas Gregor <dgregor <at> osl.iu.edu> writes:
There are several libraries that have this kind of problem. typeof needs registrations, serialization needs serialize() functions, MPI needs datatype traits, etc. I wonder if we can solve this problem for all of Boost with some kind of automatic scheme that says: if you include header A from one library and header B from another library, you automatically get whatever glue makes A and B work well together.
It's relatively simple to implement this for two headers. In header A you have:
#ifdef HEADER_B_INCLUDED # include <glue_a_and_b.hpp> #endif
In header B you have:
#ifdef HEADER_A_INCLUDED # include <glue_a_and_b.hpp> #endif
For the general case, we would probably want a "glue" subdirectory whose directory mimics the Boost directory structure (like a generalized version of your typeof_registrations suggestion). Each header in "glue" would have a bunch of #ifdef's checking all of the various other library/header names and including the appropriate glue code.
Overall, it's O(N^2) work in the number of data structures/headers/libraries (depending on how we chop it up), but users would get all of the important glue "for free".
- Doug
The work needs to be done anyway! This is just a convenient way to package it. There should probably be some way to automate the process. For example every library that need this feature could have a directory nested directory called auto_include. Then the header boost/typeof/detail/auto_include/ref.hpp e.g. should contain a comment looking like: // boostauto_include: boost/typeof/typeof.hpp boost/ref.hpp This will cause two things to happen: a) The file boost/auto_include/boost/typeof/typeof.hpp will be generated and will look like #ifndef BOOST_AUTO_INCLUDE_BOOST_TYPEOF_TYPEOF_HPP_INCLUDED #define BOOST_AUTO_INCLUDE_BOOST_TYPEOF_TYPEOF_HPP_INCLUDED #endif #ifdef BOOST_AUTO_INCLUDE_BOOST_REF_HPP_INCLUDED #include <boost/typeof/detail/auto_include/ref.hpp> #endif // more stuff involving typeof Similarly, boost/auto_include/boost/ref.hpp will be updated. b) The headers boost/ref.hpp and boost/typeof/typeof.hpp will be checked to verify that they contain #include <boost/auto_include/boost/ref.hpp> and #include <boost/auto_include/boost/typeof/typeof.hpp> respectively. It's probably not a good idea to automatically update these files. I'm willing to write the necessary script if this seems like a good way to go. In Christ, Steven Watanabe
on Sat Oct 27 2007, Douglas Gregor <dgregor-AT-osl.iu.edu> wrote:
On Sat, 2007-10-27 at 11:08 -0400, Arkadiy Vertleyb wrote:
"Eric Niebler" <eric@boost-consulting.com> wrote
In order for BOOST_TYPEOF to work with xpressive's static regexes (something I'm actively trying to support), I need registrations for reference_wrapper<> and mpl::int_<>. I'm happy to add them, but I'm not sure where. Thoughts?
Looks like the model where authors are responsible for registering their own classes dosn't work quite well... Maybe there should be a designated place with collective ownership, where interested users could add such registrations? This place could mimique the boost directory structure, to avoid conflicts, something like:
typeof_registrations mpl bind xpressive spirit ...
There are several libraries that have this kind of problem. typeof needs registrations, serialization needs serialize() functions, MPI needs datatype traits, etc.
Python needs Python bindings...
I wonder if we can solve this problem for all of Boost with some kind of automatic scheme that says: if you include header A from one library and header B from another library, you automatically get whatever glue makes A and B work well together.
...but Python doesn't really fit into this scheme of yours. There aren't any headers that bind BGL to Python. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (9)
-
Arkadiy Vertleyb -
Dave Jenkins -
David Abrahams -
Doug Gregor -
Douglas Gregor
-
Eric Niebler -
Peter Dimov -
Steven Watanabe -
Vertleyb