#2466 closed Bugs (fixed)
function_template.hpp uses exceptions even when BOOST_NO_EXCEPTIONS is defined
Reported by: | Owned by: | Douglas Gregor | |
---|---|---|---|
Milestone: | Boost 1.38.0 | Component: | function |
Version: | Boost 1.36.0 | Severity: | Problem |
Keywords: | Cc: |
Description
g++ gives this error message:
/home/andyc/work/tiger/1/include/ppc_BOS/boost/function/function_template.hpp:720: error: exception handling disabled, use -fexceptions to enable
This patch fixes it:
boost/function/function_template.hpp 1.1 vs edited
--- 1.1/boost/function/function_template.hpp 2008-10-30 16:15:10 +00:00 +++ edited/boost/function/function_template.hpp 2008-11-03 14:41:30 +00:00 @@ -715,12 +715,16 @@
return *this;
this->clear();
+#ifndef BOOST_NO_EXCEPTIONS
try {
this->assign_to_own(f);
} catch (...) {
vtable = 0; throw;
}
+#else + this->assign_to_own(f); +#endif
return *this;
}
Change History (4)
comment:1 by , 14 years ago
Component: | None → function |
---|---|
Owner: | set to |
comment:2 by , 14 years ago
The patch looks different.
In essence, all attempts to use try/catch in function_template.hpp should be surrounded by #ifndef BOOST_NO_EXCEPTIONS - my patch doesn't do that: I just fixed the compile error I saw.
Perhaps all try/catch should be surrounded.
comment:3 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:4 by , 13 years ago
(In [54824]) Merge various function changes from trunk.
Merged revisions 49571,50064,51743,51745,53722,54616-54619 via svnmerge from https://svn.boost.org/svn/boost/trunk
........
r49571 | noel_belcourt | 2008-11-03 18:37:49 +0000 (Mon, 03 Nov 2008) | 9 lines
Both Sun and Pgi on Linux correctly put typeinfo into the std namespace, but function_base keys off the BOOST_NO_EXCEPTION_STD_NAMESPACE macro instead of the BOOST_NO_STD_TYPEINFO macro. The attached patch changes function_base to use the typeinfo macro. Because eVC 4.2 doesn't put typeinfo into the std namespace, I need to define BOOST_NO_STD_TYPEINFO only for this eVC version.
........
r50064 | johnmaddock | 2008-12-02 10:10:46 +0000 (Tue, 02 Dec 2008) | 1 line
Fix -Wundef warning and suspect usage of BOOST_STRICT_CONFIG.
........
r51743 | dgregor | 2009-03-13 05:23:53 +0000 (Fri, 13 Mar 2009) | 11 lines
Implement an optimization that David Abrahams and myself came up with, where Boost.Function uses a bit in the vtable pointer to indicate when the target function object has a trivial copy constructor, trivial destructor, and fits within the small object buffer. In this case, we just copy the bits of the function object rather than performing an indirect call to the manager.
This results in a 60% speedup on a micro-benchmark that copies and calls such function objects repeatedly.
........
r51745 | dgregor | 2009-03-13 05:49:02 +0000 (Fri, 13 Mar 2009) | 7 lines
Make Boost.Function compile under BOOST_NO_EXCEPTIONS.
........
r53722 | vladimir_prus | 2009-06-07 16:44:50 +0100 (Sun, 07 Jun 2009) | 4 lines
Make Boost.Function compile with disabled exceptions.
Closes #2900. Patch from Gabi Davar.
........
r54616 | danieljames | 2009-07-03 23:20:26 +0100 (Fri, 03 Jul 2009) | 3 lines
When copying boost::ref, copy even when the referenced function is empty. Fixes #2642
Patch by Steven Watanabe
........
r54617 | danieljames | 2009-07-03 23:20:52 +0100 (Fri, 03 Jul 2009) | 6 lines
Add 'and later versions' to support info for GCC and Visual C++. Fixes #2847.
I didn't explicitly specify the versions since no one's updating this list and it's highly unlikely that a future version will break this. The same could probably be done for the other compilers but I don't know them very well so I'm leaving them alone.
........
r54618 | danieljames | 2009-07-03 23:21:40 +0100 (Fri, 03 Jul 2009) | 4 lines
Fix Boost.Function unit tests for C++0x. Fixes #3012
Based on a patch from Richard Webb. Changed a bit so that it also works for the Visual C++ 10 beta.
........
r54619 | danieljames | 2009-07-03 23:22:03 +0100 (Fri, 03 Jul 2009) | 3 lines
Work around Visual C++ copy constructor bug. Fixes #2929.
Based on the patch by Steven Watanabe.
........
Is this a duplicate of #2469?