Re: [boost] Domagoj Saric: "Re: [function] invoking without requiring boost::throw_exception"
From: "Peter Myerscough-Jackopson" <peter.myerscough-jackopson_at_[hidden]> Sent: Thursday, September 02, 2010 5:36 PM
I am using boost::function on an embedded platform, which requires me to not use exceptions, and as commented in the thread associated with
http://article.gmane.org/gmane.comp.lib.boost.devel/195351
I am checking that the function object contains a function before calling it. There is therefore no need for the invocation of the function to check if it is valid, but also there is no method circumvent this checking, and therefore my program requires the definition of boost::throw_exception, when really it is not needed. This is a concern because I intend on compiling my code into a library and do not wish to require the user to define boost::throw_exception, especially when I am guaranteeing it isn't going to be called from this site. I liked the idea of a templated NOP for the function library, but at the very least an unchecked invocation method would be great, or a nop-if-empty invocation method would be useful.
If you are certain that neither you nor your users use or will use boost::throw_exception (to actually handle some other cases 'exceptional' cases in other parts of boost) then you can provide the definition yourself. I cannot know whether my users will invoke other parts of boost that may make use of boost::throw_exception because my code is being compiled up and provided as a (application support) library. Also, since I know that I will never call the function object when it is null, I don’t want to burden my users by requiring them to define a function that will never be called from my code. As it is currently I am resorting to mimicking the code that occurs after the check and I have put a check in to ensure the library is compiled with an exact version of boost, a poor/bad/nightmare work around, but it means my users don’t have to define throw_exception. As others have noted, a common idiom for using a boost function object is to check if it is non-empty prior to calling it, is it an unreasonable extension to add this call? I am aware TR1 has subsumed “function” and so it is probably not possible remove the if-clause, but adding an unchecked invoke has significant benefits, [unchecked_invoke(), might be a better name than purely invoke()]. Peter Dr Peter Myerscough-Jackopson - Principal Engineer Tel: +44 (0)23 8076 7808 Fax: +44 (0)23 8076 0602 Web: http://www.macltd.com/ <BLOCKED::http://www.macltd.com/> Email: peter.myerscough-jackopson@macltd.com <mailto:peter.myerscough-jackopson@macltd.com> MULTIPLE ACCESS COMMUNICATIONS LIMITED is a company registered in England at Delta House, The University of Southampton Science Park, Southampton, SO16 7NS, United Kingdom with Company Number 1979185 and VAT Number GB 411942866
On Mon, Sep 6, 2010 at 12:03 PM, Peter Myerscough-Jackopson <peter.myerscough-jackopson@macltd.com> wrote:
As others have noted, a common idiom for using a boost function object is to check if it is non-empty prior to calling it, is it an unreasonable extension to add this call? I am aware TR1 has subsumed “function” and so it is probably not possible remove the if-clause, but adding an unchecked invoke has significant benefits, [unchecked_invoke(), might be a better name than purely invoke()].
+1 -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Mon, Sep 6, 2010 at 12:03 PM, Peter Myerscough-Jackopson <peter.myerscough-jackopson@macltd.com> wrote:
As others have noted, a common idiom for using a boost function object is to check if it is non-empty prior to calling it, is it an unreasonable extension to add this call? I am aware TR1 has subsumed “function” and so it is probably not possible remove the if-clause, but adding an unchecked invoke has significant benefits, [unchecked_invoke(), might be a better name than purely invoke()].
Another possible solution to this particular problem is to change the call to boost::throw_exception to BOOST_THROW_EXCEPTION (http://www.boost.org/doc/libs/release/libs/exception/doc/BOOST_THROW_EXCEPTI...) and then change boost/throw_exception.hpp to not define BOOST_THROW_EXCEPTION if it is already defined by the user. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Mon, Sep 6, 2010 at 12:03 PM, Peter Myerscough-Jackopson <peter.myerscough-jackopson@macltd.com> wrote:
From: "Peter Myerscough-Jackopson" <peter.myerscough-jackopson_at_[hidden]> Sent: Thursday, September 02, 2010 5:36 PM
I am using boost::function on an embedded platform, which requires me to not use exceptions, and as commented in the thread associated with
http://article.gmane.org/gmane.comp.lib.boost.devel/195351
I am checking that the function object contains a function before calling it. There is therefore no need for the invocation of the function to check if it is valid, but also there is no method circumvent this checking, and therefore my program requires the definition of boost::throw_exception, when really it is not needed. This is a concern because I intend on compiling my code into a library and do not wish to require the user to define boost::throw_exception, especially when I am guaranteeing it isn't going to be called from this site. I liked the idea of a templated NOP for the function library, but at the very least an unchecked invocation method would be great, or a nop-if-empty invocation method would be useful.
If you are certain that neither you nor your users use or will use boost::throw_exception (to actually handle some other cases 'exceptional' cases in other parts of boost) then you can provide the definition yourself.
I cannot know whether my users will invoke other parts of boost that may make use of boost::throw_exception because my code is being compiled up and provided as a (application support) library. Also, since I know that I will never call the function object when it is null, I don’t want to burden my users by requiring them to define a function that will never be called from my code. As it is currently I am resorting to mimicking the code that occurs after the check and I have put a check in to ensure the library is compiled with an exact version of boost, a poor/bad/nightmare work around, but it means my users don’t have to define throw_exception.
I don't understand why you say your users need to define boost::throw_exception. If BOOST_NO_EXCEPTIONS is not defined, then the Boost Exceptions library defines throw_exception. If you define BOOST_NO_EXCEPTIONS, then you, not your users, need to define throw_exception. http://www.boost.org/doc/libs/1_44_0/libs/exception/doc/throw_exception.html It seems to me that in your situation on an embedded platform without exception support, you should define BOOST_NO_EXCEPTIONS and then use something like Domagoj's example of an unreachable throw_exception implementation.
As others have noted, a common idiom for using a boost function object is to check if it is non-empty prior to calling it, is it an unreasonable extension to add this call? I am aware TR1 has subsumed “function” and so it is probably not possible remove the if-clause, but adding an unchecked invoke has significant benefits, [unchecked_invoke(), might be a better name than purely invoke()].
Yeah, it seems like a good idea to add something like this. Could you submit a feature request at svn.boost.org, if there isn't one there already? Daniel Walker
participants (4)
-
Daniel Walker -
Dave Abrahams -
Emil Dotchevski -
Peter Myerscough-Jackopson