In preparation for release, I've been working on documentation. When I read my documentation, I sometimes get an uncomfortable feeling about what I have to write and realize it would be better to fix the implementation. A few small changes are happening now as a result: 1. The BOOST_PYTHON_[MEMBER_]FUNCTION_OVERLOADS macros used to expose functions with default arguments will not be available by simply #including <boost/python/class.hpp> or <boost/python/def.hpp>. Instead they will be moved to <boost/python/overloads.hpp> 2. The module class is officially disappearing, for real. I'm going to keep module.hpp, but only so I can do: #include <boost/python/module_init.hpp> #define BOOST_PYTHON_MODULE BOOST_PYTHON_MODULE_INIT BOOST_PYTHON_MODULE_INIT will continue to be available but deprecated for Boost 1.29.0, but the "official" macro will be BOOST_PYTHON_MODULE By the way, I've been pondering the merits of having a <boost/python.hpp> header which exposes all of the public headers, just for ease-of-use. Opinions? ----------------------------------------------------------- David Abrahams * Boost Consulting dave@boost-consulting.com * http://www.boost-consulting.com
----- Original Message ----- From: "David Abrahams" <dave@boost-consulting.com>
By the way, I've been pondering the merits of having a <boost/python.hpp> header which exposes all of the public headers, just for ease-of-use. Opinions?
I've often wondered what people *really* think about this, not only in the context of boost.python but all libraries in general. I'm very interested to hear the general consensus. Modern C++ stresses the compiler a lot and brings it to its knees. An all encompassing header, while easy to type, will unnecessarily add more burden on the already burdened compiler. OTOH, if the user is fully aware of these issues, then it's his call. He has a choice of easy typing vs. longer compile times. --Joel PS> Was this issue ever raised in boost?
--- David Abrahams <dave@boost-consulting.com> wrote:
1. The BOOST_PYTHON_[MEMBER_]FUNCTION_OVERLOADS macros used to expose functions with default arguments will not be available by simply #including <boost/python/class.hpp> or <boost/python/def.hpp>. Instead they will be moved to <boost/python/overloads.hpp>
Even though I am working with the latest RC_1_29_0 branch I do not have to include overloads.hpp to use the OVERLOADS macros. Could this be due to an oversight? -- Here is the preprocessor output of one of my files: http://cci.lbl.gov/~rwgk/tmp/regression_test_module_cpp_gcc_preprocessed
2. The module class is officially disappearing, for real. I'm going to keep module.hpp, but only so I can do:
#include <boost/python/module_init.hpp> #define BOOST_PYTHON_MODULE BOOST_PYTHON_MODULE_INIT
BOOST_PYTHON_MODULE_INIT will continue to be available but deprecated for Boost 1.29.0, but the "official" macro will be BOOST_PYTHON_MODULE.
So which file do I have to include in the future? Like this? #include <boost/python/module.hpp> BOOST_PYTHON_MODULE(my_extension) { ... } Will module_init.hpp eventually go away? Thanks, Ralf __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
From: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com>
--- David Abrahams <dave@boost-consulting.com> wrote:
1. The BOOST_PYTHON_[MEMBER_]FUNCTION_OVERLOADS macros used to expose functions with default arguments will not be available by simply #including <boost/python/class.hpp> or <boost/python/def.hpp>. Instead they will be moved to <boost/python/overloads.hpp>
Even though I am working with the latest RC_1_29_0 branch I do not have to include overloads.hpp to use the OVERLOADS macros. Could this be due to an oversight?
No, it's due to the fact that I've been making a few changes on the trunk which haven't been moved to the release candidate branch yet.
2. The module class is officially disappearing, for real. I'm going to
keep
module.hpp, but only so I can do:
#include <boost/python/module_init.hpp> #define BOOST_PYTHON_MODULE BOOST_PYTHON_MODULE_INIT
BOOST_PYTHON_MODULE_INIT will continue to be available but deprecated for Boost 1.29.0, but the "official" macro will be BOOST_PYTHON_MODULE.
So which file do I have to include in the future? Like this?
#include <boost/python/module.hpp>
BOOST_PYTHON_MODULE(my_extension) { ... }
Good. See any of libs/python/test/*.cpp on the main trunk for examples.
Will module_init.hpp eventually go away?
In the distant future, yes. ----------------------------------------------------------- David Abrahams * Boost Consulting dave@boost-consulting.com * http://www.boost-consulting.com
participants (3)
-
David Abrahams -
Joel de Guzman -
Ralf W. Grosse-Kunstleve