boost::function & gcc 2.96 problem
Because of a problem in boost/function/function_template.hpp Boost.Python in the current CVS HEAD does not compile with gcc 2.96 under RedHat 7.3. Attached is a suggested workaround (tested with gcc 2.96 and EDG 245). Ralf Index: function_base.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/function/function_base.hpp,v retrieving revision 1.72 diff -u -r1.72 function_base.hpp --- function_base.hpp 11 Feb 2004 18:16:55 -0000 1.72 +++ function_base.hpp 12 Feb 2004 22:01:42 -0000 @@ -188,8 +188,10 @@ // The trivial manager does nothing but return the same pointer (if we // are cloning) or return the null pointer (if we are deleting). template<typename F> - inline any_pointer - trivial_manager(any_pointer f, functor_manager_operation_type op) + struct trivial_manager + { + static inline any_pointer + get(any_pointer f, functor_manager_operation_type op) { switch (op) { case clone_functor_tag: return f; @@ -209,6 +211,7 @@ // Clears up a warning with GCC 3.2.3 return make_any_pointer(reinterpret_cast<void*>(0)); } + }; /** * The functor_manager class contains a static function "manage" which Index: function_template.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/function/function_template.hpp,v retrieving revision 1.70 diff -u -r1.70 function_template.hpp --- function_template.hpp 24 Jan 2004 23:31:40 -0000 1.70 +++ function_template.hpp 12 Feb 2004 22:01:42 -0000 @@ -508,7 +508,7 @@ invoker_type; invoker = &invoker_type::invoke; - this->manager = &detail::function::trivial_manager<FunctionObj>; + this->manager = &detail::function::trivial_manager<FunctionObj>::get; this->functor = this->manager( detail::function::make_any_pointer( @@ -529,7 +529,7 @@ >::type invoker_type; invoker = &invoker_type::invoke; - this->manager = &detail::function::trivial_manager<FunctionObj>; + this->manager = &detail::function::trivial_manager<FunctionObj>::get; this->functor = detail::function::make_any_pointer(this); } __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html
Ralf W. Grosse-Kunstleve wrote:
Because of a problem in boost/function/function_template.hpp Boost.Python in the current CVS HEAD does not compile with gcc 2.96 under RedHat 7.3. Attached is a suggested workaround (tested with gcc 2.96 and EDG 245).
[...]
@@ -209,6 +211,7 @@ // Clears up a warning with GCC 3.2.3 return make_any_pointer(reinterpret_cast<void*>(0));
This of course doesn't have anything to do with your patch, but it caught my eye. reinterpret_casting 0 to void* is not guaranteed to yield a null pointer. :-)
On Thursday 12 February 2004 05:22 pm, Peter Dimov wrote:
Ralf W. Grosse-Kunstleve wrote:
@@ -209,6 +211,7 @@ // Clears up a warning with GCC 3.2.3 return make_any_pointer(reinterpret_cast<void*>(0));
This of course doesn't have anything to do with your patch, but it caught my eye. reinterpret_casting 0 to void* is not guaranteed to yield a null pointer. :-)
Shortly after this message this message hit the Boost list (and before I saw it), I received this helpful little note from a friend: "You might want to arm yourself with 5.2.10/8 and 4.10/1." He's right, I think. 0 is the null pointer constant, which is a null pointer value, which is converted to the null pointer value of the destination type. But if you don't agree, I'm just as happy replacing it with a static_cast instead of starting a long discussion. It's just not worth it :) Doug
Douglas Gregor wrote:
On Thursday 12 February 2004 05:22 pm, Peter Dimov wrote:
Ralf W. Grosse-Kunstleve wrote:
@@ -209,6 +211,7 @@ // Clears up a warning with GCC 3.2.3 return make_any_pointer(reinterpret_cast<void*>(0));
This of course doesn't have anything to do with your patch, but it caught my eye. reinterpret_casting 0 to void* is not guaranteed to yield a null pointer. :-)
Shortly after this message this message hit the Boost list (and before I saw it), I received this helpful little note from a friend:
"You might want to arm yourself with 5.2.10/8 and 4.10/1."
He's right, I think. 0 is the null pointer constant, which is a null pointer value, which is converted to the null pointer value of the destination type.
He is right, but not because of 5.2.10/8. :-) 5.2.10/5 + footnote 64 say you are home free.
But if you don't agree, I'm just as happy replacing it with a static_cast instead of starting a long discussion.
Your choice. :-)
On Fri, 13 Feb 2004 01:22:10 +0200, "Peter Dimov" <pdimov@mmltd.net> wrote:
He is right, but not because of 5.2.10/8. :-) 5.2.10/5 + footnote 64 say you are home free.
Hmm... I think a committee clarification is in order: 5.2.10/8 mentions "null pointer value", not "null pointer constant". That seems intentional, but then the footnote makes a special case for any integral constant expression (even if lvalue). Furthermore, that's a footnote... I don't see anything in normative text supporting it; and it seems more useful to have static_cast and reinterpret_cast work differently. Note that, if the footnote is correct, to have reinterpret_cast semantics you have to use a non-const intermediary, for instance an int variable: int v = 0; reinterpret_cast<T*>(v); // implementation defined. reinterpret_cast<T*>(0); // null pointer value of type T* const int W = 0; reinterpret_cast<T*>(w); // null pointer value of type T* Nightly yours ;) Genny.
On Thu, 12 Feb 2004 18:02:13 -0500, Douglas Gregor <gregod@cs.rpi.edu> wrote:
Shortly after this message this message hit the Boost list (and before I saw it), I received this helpful little note from a friend:
"You might want to arm yourself with 5.2.10/8 and 4.10/1."
He's right, I think. 0 is the null pointer constant, which is a null pointer value,
No. It becomes a null pointer value *if* converted to a pointer type. 5.2.10/8 is telling you can do this: 0 -> pointer type -> reinterpret_cast<void*> while you are doing, directly 0 -> reinterpret_cast<void*> This way, you are converting an int.
[...] But if you don't agree, I'm just as happy replacing it with a static_cast instead of starting a long discussion. It's just not worth it :)
Yes :) Genny.
On Thursday 12 February 2004 05:13 pm, Ralf W. Grosse-Kunstleve wrote:
Because of a problem in boost/function/function_template.hpp Boost.Python in the current CVS HEAD does not compile with gcc 2.96 under RedHat 7.3. Attached is a suggested workaround (tested with gcc 2.96 and EDG 245). Ralf
Thanks, you're a step ahead of me. Checked into CVS head. Doug
participants (1)
-
Douglas Gregor -
Gennaro Prota -
Peter Dimov -
Ralf W. Grosse-Kunstleve