Dear all, when looking at Boost as a whole its obvious that it uses C++ exceptions to report exceptional conditions because its the C++ way of doing it and it has to interact with the C++ standard library. On the other hand it seems also obvious that some libraries (Boost.Units, Boost.MPL, etc.) do probably not use C++ exceptions at all since they are pure compile time libraries or provide services which do not have exceptional cases. I am working on a C++ based project which forbids the usage of C++ exceptions but it is still preferable to use Boost libraries at least the ones which do not make use of C++ exceptions at all. I am especially interested in using Boost.Units and Boost.Math. Which of Boost libraries do NOT make use of C++ exceptions (i did not find such a list but maybe its already available somewhere)? What would it take to use these libraries as a stand-alone "minimal" Boost library? Thanks
On 17/06/2012 12:45, Dirk Ulrich wrote:
I am working on a C++ based project which forbids the usage of C++ exceptions but it is still preferable to use Boost libraries at least the ones which do not make use of C++ exceptions at all.
All Boost libraries should work with exceptions disabled, with potentially limited functionality. If that is not the case, it's probably a library-specific bug that should be reported. If exceptions are disabled, Boost will call boost::throw_exception(std::exception const&), which must be defined by the user.
Mathias Gaunard-2 wrote
On 17/06/2012 12:45, Dirk Ulrich wrote:
I am working on a C++ based project which forbids the usage of C++ exceptions but it is still preferable to use Boost libraries at least the ones which do not make use of C++ exceptions at all.
All Boost libraries should work with exceptions disabled, with potentially limited functionality. If that is not the case, it's probably a library-specific bug that should be reported.
Hi, I don't see this as a bug but as a nice to have feature. In addition, for some libraries, the subset that could work with exceptions disabled could be minimal. I agree however that a list of libraries that works with exceptions disabled should be built as well as the ones with no-rtti. Anyway, we need some testers that will run the regression test with the specific options. Any volunteers? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-and-exceptions-tp4631441p4631449.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
Mathias Gaunard <mathias.gaunard <at> ens-lyon.org> writes:
On 17/06/2012 12:45, Dirk Ulrich wrote:
I am working on a C++ based project which forbids the usage of C++
exceptions
but it is still preferable to use Boost libraries at least the ones which do not make use of C++ exceptions at all.
All Boost libraries should work with exceptions disabled, with potentially limited functionality. If that is not the case, it's probably a library-specific bug that should be reported.
If exceptions are disabled, Boost will call boost::throw_exception(std::exception const&), which must be defined by the user.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I understand that Boost provides a possibility to disable the usage of C++ exceptions and instead it provides a callback (boost::throw_exception()) which clients can implement to catch any exception thrown. But that's not what i was looking for. I was more looking for a list of libraries which have kind of a "noexcept" guarantee (which would not even call boost::throw_exception()) because their service is either fully at compile time or simply has no exceptional cases (as i would expect from Boost.Units for example). Furthermore i wonder what the implementation requirements for implementation boost::throw_exception() are (sorry, i could not find any documentation yet). When looking at the Boost code it seems that it is not expected for boost:throw_exception() to return but to abort the program immediately. Is that correct? I also wonder how Boost handles allocation using new() in case of exceptions being disabled. In this case the new() operator is expected to return a NULL pointer instead of throw std::bad_alloc but i could not find code that tests pointers against NULL at places where allocations were done (i saw that Boost makes use of allocators instead of using plain new() but that should probably be the same).
On Mon, Jun 18, 2012 at 4:35 AM, Ulrich, <dirkude@yahoo.de> wrote:
I understand that Boost provides a possibility to disable the usage of C++ exceptions and instead it provides a callback (boost::throw_exception()) which clients can implement to catch any exception thrown.
But that's not what i was looking for. I was more looking for a list of libraries which have kind of a "noexcept" guarantee (which would not even call boost::throw_exception()) because their service is either fully at compile time or simply has no exceptional cases (as i would expect from Boost.Units for example).
Overall you're probably out of luck. As far as exceptions are concerned, the only requirement that exists for Boost Libraries is that they throw by calling boost::throw_exception, but this doesn't guarantee usability. It is just a mechanism to enable Boost authors to enforce postconditions, that is, to protect their own code from the effects of disabled exception handling. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Mon, Jun 18, 2012 at 4:35 AM, Ulrich, <dirkude@yahoo.de> wrote:
the only requirement that exists for Boost Libraries is that they throw by calling boost::throw_exception, ...
since when is this a requirement? Robert Ramey
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Jun 18, 2012 at 1:52 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
On Mon, Jun 18, 2012 at 4:35 AM, Ulrich, <dirkude@yahoo.de> wrote:
the only requirement that exists for Boost Libraries is that they throw by calling boost::throw_exception, ...
since when is this a requirement?
I meant it is a requirement if a library that throws exceptions supports BOOST_NO_EXCEPTIONS builds. AFAIK libraries aren't required required to support BOOST_NO_EXCEPTIONS. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Mon, Jun 18, 2012 at 1:52 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
On Mon, Jun 18, 2012 at 4:35 AM, Ulrich, <dirkude@yahoo.de> wrote:
the only requirement that exists for Boost Libraries is that they throw by calling boost::throw_exception, ...
since when is this a requirement?
I meant it is a requirement if a library that throws exceptions supports BOOST_NO_EXCEPTIONS builds.
Hmm - that sentence doesn't quite make sense for me. I'm supposing that it means: "if a library throws exceptions it is required to invoke boost::throw_exception" Assuming my understanding is correct my question is: since when is THIS a requirement? Robert Ramey
AFAIK libraries aren't required required to support BOOST_NO_EXCEPTIONS.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Jun 18, 2012 at 3:56 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
On Mon, Jun 18, 2012 at 1:52 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
On Mon, Jun 18, 2012 at 4:35 AM, Ulrich, <dirkude@yahoo.de> wrote:
the only requirement that exists for Boost Libraries is that they throw by calling boost::throw_exception, ...
since when is this a requirement?
I meant it is a requirement if a library that throws exceptions supports BOOST_NO_EXCEPTIONS builds.
Hmm - that sentence doesn't quite make sense for me. I'm supposing that it means:
"if a library throws exceptions it is required to invoke boost::throw_exception"
No, it means that if a library that throws exceptions supports BOOST_NO_EXCEPTIONS builds, it is required to use boost::throw_exception to throw. I know you have your own reasons to use a parallel implementation of boost::throw_exception, that's fine. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Mon, Jun 18, 2012 at 3:56 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
On Mon, Jun 18, 2012 at 1:52 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
On Mon, Jun 18, 2012 at 4:35 AM, Ulrich, <dirkude@yahoo.de> wrote:
the only requirement that exists for Boost Libraries is that they throw by calling boost::throw_exception, ...
since when is this a requirement?
I meant it is a requirement if a library that throws exceptions supports BOOST_NO_EXCEPTIONS builds.
Hmm - that sentence doesn't quite make sense for me. I'm supposing that it means:
"if a library throws exceptions it is required to invoke boost::throw_exception"
No, it means that if a library that throws exceptions supports BOOST_NO_EXCEPTIONS builds, it is required to use boost::throw_exception to throw.
Well, this is certainly news to me. I had always understood that BOOST_NO_EXCEPTIONS was defined for compilers which do not support the throw/catch statements. This posting starts a thread which http://lists.boost.org/Archives/boost/2003/09/53399.php which seems to end with the statement "No, we're talking about compilers that don't support C++ exceptions at all (embedded Visual C++ for example) - hence no unwinding no matter what else may be going on. And yes it was badly worded :-) " At some point, the definition of BOOST_NO_EXCEPTION was hijacked to mean to something completely unrelated and totally different. This broke a bunch of other libraries and resulting in problems that plague us to this day. and of course the same goes for BOOST_THROW_EXCEPTION. Would anyone object if I changed these back to the original (sensible) meanings? Robert Ramey I know you have your own reasons to
use a parallel implementation of boost::throw_exception, that's fine.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Jun 18, 2012 at 9:55 PM, Robert Ramey <ramey@rrsd.com> wrote:
At some point, the definition of BOOST_NO_EXCEPTION was hijacked to mean to something completely unrelated and totally different. This broke a bunch of other libraries and resulting in problems that plague us to this day. and of course the same goes for BOOST_THROW_EXCEPTION.
BOOST_THROW_EXCEPTION (the macro) has never been changed, it did not exist prior to the acceptance of Boost Exception. Would anyone object if I changed these back to the original (sensible)
meanings?
You probably mean boost::throw_exception. Yes, I object that being changed because that would handicap Boost Exception. Note that users of Boost Exception need other Boost libraries to throw exceptions using boost::throw_exception in order to take advantage of Boost Exception. You state that boost::throw_exception isn't sensible. Care to elaborate? Normally I don't knowingly write non-sensible code. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Mon, Jun 18, 2012 at 9:55 PM, Robert Ramey <ramey@rrsd.com> wrote:
At some point, the definition of BOOST_NO_EXCEPTION was hijacked to mean to something completely unrelated and totally different. This broke a bunch of other libraries and resulting in problems that plague us to this day. and of course the same goes for BOOST_THROW_EXCEPTION.
BOOST_THROW_EXCEPTION (the macro) has never been changed, it did not exist prior to the acceptance of Boost Exception.
Would anyone object if I changed these back to the original (sensible)
meanings?
You probably mean boost::throw_exception. Yes, I object that being changed because that would handicap Boost Exception. Note that users of Boost Exception need other Boost libraries to throw exceptions using boost::throw_exception in order to take advantage of Boost Exception.
Maybe we can reach some sort of compromise on this. According to http://www.boost.org/doc/libs/1_49_0/libs/config/doc/html/boost_config/boost... "The compiler does not support exception handling (this setting is typically required by many C++ compilers for embedded platforms). Note that there is no requirement for boost libraries to honor this configuration setting - indeed doing so may be impossible in some cases. Those libraries that do honor this will typically abort if a critical error occurs - you have been warned!" a) This definition is in the current and all past documentation and should be respected by all code which uses the macro BOOST_NO_EXCEPTIONS Reason: This is a clear meaning and it's been documented as such for many years. Your interpretation is at odds with the documentation. People who read the documentation and code according to it will be mislead. b) boost::throw_exception should be rolled back to it's orginal meaning. Reason:The problem here is that using something from the main boost namespace creates and unexpected and hidden dependency on another library. This occcurs without the library user getting notified at all. Much care has been expended so that those things directly inside the boost namespace (excluding convenience headers) be things which DO NOT create dependencies on other libraries. The current definition of boost::throw_exception is the only exception to this. c) Those who want or need the features of the Boost Exception library should be able to get them with: #include <boost/exception/throw_exception.hpp> // or maybe <boost/exception.hpp> ... boost::exception::throw_exception .... Reason: This is in line with standard practice with all other libraries - and for good reason. It exemplifies the "don't pay for what you don't use" which is essential to the success of boost. Robert Ramey
On 19 June 2012 18:11, Robert Ramey <ramey@rrsd.com> wrote:
According to http://www.boost.org/doc/libs/1_49_0/libs/config/doc/html/boost_config/boost...
"The compiler does not support exception handling (this setting is typically required by many C++ compilers for embedded platforms). Note that there is no requirement for boost libraries to honor this configuration setting - indeed doing so may be impossible in some cases. Those libraries that do honor this will typically abort if a critical error occurs - you have been warned!"
a) This definition is in the current and all past documentation and should be respected by all code which uses the macro BOOST_NO_EXCEPTIONS
From http://www.boost.org/doc/libs/1_31_0/libs/utility/throw_exception.html
"It is intended to be used in Boost libraries that need to throw exceptions, but support configurations and platforms where exceptions aren't available, as indicated by the presence of the BOOST_NO_EXCEPTIONS configuration macro." Suggests that the config documentation isn't in line with how it's been used for the past nine years.
b) boost::throw_exception should be rolled back to it's orginal meaning.
Reason:The problem here is that using something from the main boost namespace creates and unexpected and hidden dependency on another library. Â This occcurs without the library user getting notified at all. Â Much care has been expended so that those things directly inside the boost namespace (excluding convenience headers) be things which DO NOT create dependencies on other libraries. Â The current definition of boost::throw_exception is the only exception to this.
That's an odd claim to make. Look at: boost::any, boost::array, boost::bimap etc.
Daniel James wrote:
On 19 June 2012 18:11, Robert Ramey <ramey@rrsd.com> wrote:
According to http://www.boost.org/doc/libs/1_49_0/libs/config/doc/html/boost_config/boost...
"The compiler does not support exception handling (this setting is typically required by many C++ compilers for embedded platforms). Note that there is no requirement for boost libraries to honor this configuration setting - indeed doing so may be impossible in some cases. Those libraries that do honor this will typically abort if a critical error occurs - you have been warned!"
a) This definition is in the current and all past documentation and should be respected by all code which uses the macro BOOST_NO_EXCEPTIONS
From http://www.boost.org/doc/libs/1_31_0/libs/utility/throw_exception.html
"It is intended to be used in Boost libraries that need to throw exceptions, but support configurations and platforms where exceptions aren't available, as indicated by the presence of the BOOST_NO_EXCEPTIONS configuration macro."
Suggests that the config documentation isn't in line with how it's been used for the past nine years.
b) boost::throw_exception should be rolled back to it's orginal meaning.
Reason:The problem here is that using something from the main boost namespace creates and unexpected and hidden dependency on another library. This occcurs without the library user getting notified at all. Much care has been expended so that those things directly inside the boost namespace (excluding convenience headers) be things which DO NOT create dependencies on other libraries. The current definition of boost::throw_exception is the only exception to this.
That's an odd claim to make. Look at: boost::any, boost::array, boost::bimap etc.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Daniel James wrote:
On 19 June 2012 18:11, Robert Ramey <ramey@rrsd.com> wrote:
According to http://www.boost.org/doc/libs/1_49_0/libs/config/doc/html/boost_config/boost...
"The compiler does not support exception handling (this setting is typically required by many C++ compilers for embedded platforms). Note that there is no requirement for boost libraries to honor this configuration setting - indeed doing so may be impossible in some cases. Those libraries that do honor this will typically abort if a critical error occurs - you have been warned!"
a) This definition is in the current and all past documentation and should be respected by all code which uses the macro BOOST_NO_EXCEPTIONS
From http://www.boost.org/doc/libs/1_31_0/libs/utility/throw_exception.html
"It is intended to be used in Boost libraries that need to throw exceptions, but support configurations and platforms where exceptions aren't available, as indicated by the presence of the BOOST_NO_EXCEPTIONS configuration macro."
Suggests that the config documentation isn't in line with how it's been used for the past nine years.
b) boost::throw_exception should be rolled back to it's orginal meaning.
Reason:The problem here is that using something from the main boost namespace creates and unexpected and hidden dependency on another library. This occcurs without the library user getting notified at all. Much care has been expended so that those things directly inside the boost namespace (excluding convenience headers) be things which DO NOT create dependencies on other libraries. The current definition of boost::throw_exception is the only exception to this.
That's an odd claim to make. Look at: boost::any, boost::array, boost::bimap etc.
OK - maybe I should phrase this more carefully. I don't think that something I include from /boost - (other than a convenience header) should depend on something more specific like boost/exception, boost/serialization or whatever. (Nor do I think that anything not in boost/ should be bart of the namespace boost: but rather in in boost::library_name:: ); Of course a number of older libraries like any, array, etc violate this idea. I presume that when boost was small it didn't matter and no one likely expected that boost would become as large as it has. And some more recent libraries e.g. boost.range also violate this by putting stuff directly in the boost namespace. The fact that this occurs doesn't convince me that it's a good idea. Basically I want to be including what I expect to include and not include what I'm not expecting to include. I would like to know that if I use #include <boost/foreach.hpp> I'm not including anything outside of the the boost directory and namespace. Another way of saying this is that the stuff directly in boost/ is sort of "core boost" and including this stuff doesn't include anything outside of this "core". Thus, when I write my code - then I know what I'm getting. Of course if I include <boost/archive/binary_oarchive.hpp> I can expect to include a bunch of other stuff and double check accordingly. And this one of my main complaints about the implementation of boost.exception. I include something <boost/throw_exception> and I get a whole layer of stuff I didn't ask for. It makes my job and everyone else harder than it has to be. And of course I'm still smarting from having the BOOST_NO_EXCEPTIONS definition change while I wasn't looking to from what has always been documented in a way that makes some sense to something that I still dont' get. So I stand behind my suggestions.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Jun 19, 2012 at 3:51 PM, Robert Ramey <ramey@rrsd.com> wrote: [...]
And of course I'm still smarting from having the BOOST_NO_EXCEPTIONS definition change while I wasn't looking to from what has always been documented in a way that makes some sense to something that I still dont' get.
So I stand behind my suggestions.
Sorry, I've only been glossing over this discussion. Can someone please clarify how BOOST_NO_EXCEPTIONS has changed, what specific change Robert (and possibly others) find troubling, and what practical consequences this has had or presently has? Ditto for boost::throw_exception. (For the record, I've glanced at the blurbs on BOOST_NO_EXCEPTIONS within Boost.Config and Boost.Exception and it's difficult for me to parse what effect their differences have in practice, and it sounds like others have a good idea what the problem seems to be.) - Jeff
On Tue, Jun 19, 2012 at 4:01 PM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung@gmail.com> wrote:
On Tue, Jun 19, 2012 at 3:51 PM, Robert Ramey <ramey@rrsd.com> wrote: [...]
And of course I'm still smarting from having the BOOST_NO_EXCEPTIONS definition change while I wasn't looking to from what has always been documented in a way that makes some sense to something that I still dont' get.
So I stand behind my suggestions.
Sorry, I've only been glossing over this discussion. Can someone please clarify how BOOST_NO_EXCEPTIONS has changed, what specific change Robert (and possibly others) find troubling, and what practical consequences this has had or presently has? Ditto for boost::throw_exception.
The semantics of BOOST_NO_EXCEPTIONS have not changed. boost::throw_exception was altered with the acceptance of Boost Exception, to automatically make Boost exceptions derive from boost::exception. This is an empty shell that enables the Boost Exception functionality. Robert has no use for that functionality and sees the empty shell as overhead. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Jeffrey Lee Hellrung, Jr. wrote:
On Tue, Jun 19, 2012 at 3:51 PM, Robert Ramey <ramey@rrsd.com> wrote: [...]
And of course I'm still smarting from having the BOOST_NO_EXCEPTIONS definition change while I wasn't looking to from what has always been documented in a way that makes some sense to something that I still dont' get.
So I stand behind my suggestions.
Sorry, I've only been glossing over this discussion. Can someone please clarify how BOOST_NO_EXCEPTIONS has changed,
Just look higher in the the thread for Emil's definition of BOOST_NO_EXCEPTIONS. This is different than the one in the documentation which has never changed and in fact is part of another library. This situation has lead to much confusion as to what this macro means as noted higher in the thread.
what specific change Robert (and possibly others) find troubling, and what practical consequences this has had or presently has?
Well, it's left me confused about what it's supposed to be.
Ditto for boost::throw_exception.
Ahhh - a somewhat different case. boost throw exception as implemented in a very simple way for a very simple purpose. That purpose was to provide and escape to a global function which one could implement for those platoforms which failed to implement exceptions. This is not so uncommon for embedded systems and some shops which prohibit usage of exceptions. The function of this was changed with the inclusion of boost.exception which altered the purpose and implementation of boost::exception in include the functionality of boost.exeption. You should be able to guess what happened. All the librarires which has presumed the original operation started to have changed behavior. Longer build time, dependence on a new library, new requirement that the library be only used with rtti turned on. For some unfathonable reason, the change in boost::throw_exception was allowed to stand. So these libraries including serialization, boost.filesystem, and some others had to creat their own macros to implement the behavior of the original boost::throw_exception. So now we have the case where a) the original functionality is not found in boost, anyone who needs it has to implement it on their own. b) the same functionality is re-implemented in several other libraries which required a new round of updating of code a documentation, c) and now we have the situation where a user who invokes something in the core boost - boost::throw_exception is likely to get a lot more than he bargained for. Basically, if one want's the functionality of boost exeception, he should #include <boost/exception/thow_exception.hpp> .. boost::exception::throw_exception and if he want's the original behavior he should be able to say #include <boost/throw_exception.hpp> ... boost::throw_exception. gratuitiously changing the behavior of a long standing function in the boost core which other library depend on is an unfriendly practice. I know Emil is convinced that he's done us a big favor by forcing us to convert to behavior which he knows is better for us, But it's not his call to make. It's not for me to go around chaning the behavior of other peoples libraries just because I know better.
(For the record, I've glanced at the blurbs on BOOST_NO_EXCEPTIONS within Boost.Config and Boost.Exception and it's difficult for me to parse what effect their differences have in practice, and it sounds like others have a good idea what the problem seems to be.)
I hope I clarified this. Robert Ramey
- Jeff
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Jun 19, 2012 at 6:33 PM, Robert Ramey <ramey@rrsd.com> wrote:
Just look higher in the the thread for Emil's definition of BOOST_NO_EXCEPTIONS. This is different than the one in the documentation which has never changed and in fact is part of another library. This situation has lead to much confusion as to what this macro means as noted higher in the thread.
Maybe you're confused because you're looking for a change that doesn't exist? :) The semantics of the BOOST_NO_EXCEPTIONS configuration macro have not been changed. If it is defined, Boost Libraries must not throw exceptions. One way to do this was, and still is, to use boost::throw_exception to throw. You should be able to guess what happened.
All the librarires which has presumed the original operation started to have changed behavior. Longer build time, dependence on a new library, new requirement that the library be only used with rtti turned on.
I'm sorry but you'll have to back the "longer build time" claim with hard data. You're factually wrong about RTTI, it doesn't have to be turned on. others had to creat their own macros to implement the behavior of the
original boost::throw_exception. So now we have the case where
That's also wrong, nobody had to do anything. Not only it didn't break any library, it caught bugs in libraries that called boost::throw_exception with types that don't derive from std::exception (in violation of its requirements.)
a) the original functionality is not found in boost, anyone who needs it has to implement it on their own.
I'd like to see an example of a program that works with what you call "the original functionality" but doesn't work with the official boost::throw_exception. Basically, if one want's the functionality of boost exeception, he should
#include <boost/exception/thow_exception.hpp> .. boost::exception::throw_exception
and if he want's the original behavior he should be able to say
#include <boost/throw_exception.hpp> ... boost::throw_exception.
This would work only for exceptions emitted by user code. Boost Exception is quite useful (to the user) for exceptions that originate in library code. gratuitiously changing the behavior of a long standing function in the
boost core which other library depend on is an unfriendly practice. I know Emil is convinced that he's done us a big favor by forcing us to convert to behavior which he knows is better for us, But it's not his call to make.
No it wasn't my call obviously. Boost Exception was admitted by the usual review process.
(For the record, I've glanced at the blurbs on BOOST_NO_EXCEPTIONS within Boost.Config and Boost.Exception and it's difficult for me to parse what effect their differences have in practice, and it sounds like others have a good idea what the problem seems to be.)
You'd be able to make a better argument for your case if you understand how boost::throw_exception was changed (it's been what, 4 years ago now?) That change boils down to inserting class boost::exception, which does not implement any functionality, as a base. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski-3 wrote
On Tue, Jun 19, 2012 at 6:33 PM, Robert Ramey <ramey@> wrote:
Just look higher in the the thread for Emil's definition of BOOST_NO_EXCEPTIONS. This is different than the one in the documentation which has never changed and in fact is part of another library. This situation has lead to much confusion as to what this macro means as noted higher in the thread.
Maybe you're confused because you're looking for a change that doesn't exist? :)
The semantics of the BOOST_NO_EXCEPTIONS configuration macro have not been changed. If it is defined, Boost Libraries must not throw exceptions.
I don't interpret it this way. IMO, if BOOST_NO_EXCEPTIONS is defined, Boost libraries throwing exceptions or using try-catch will just not be supported, which is quite different. What I mean, is that this is not a library bug but a feature. Could you point where it is written that Boost Libraries must not throw exceptions when BOOST_NO_EXCEPTIONS is defined? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-and-exceptions-tp4631441p4631550.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Tue, Jun 19, 2012 at 7:14 PM, Emil Dotchevski <emildotchevski@gmail.com>wrote:
On Tue, Jun 19, 2012 at 6:33 PM, Robert Ramey <ramey@rrsd.com> wrote:
Just look higher in the the thread for Emil's definition of BOOST_NO_EXCEPTIONS. This is different than the one in the documentation which has never changed and in fact is part of another library. This situation has lead to much confusion as to what this macro means as noted higher in the thread.
Maybe you're confused because you're looking for a change that doesn't exist? :)
The semantics of the BOOST_NO_EXCEPTIONS configuration macro have not been changed. If it is defined, Boost Libraries must not throw exceptions.
This seems to be contradict [1], which specifically says "there is no requirement for boost libraries to honor this configuration setting". Which seems to imply that a library may simply choose to not be supported (i.e., us try/catch/throw) if BOOST_NO_EXCEPTIONS is defined. One
way to do this was, and still is, to use boost::throw_exception to throw.
Again, [2] seems to indicate that *all* exceptions in *all* of Boost will be forwarded to boost::throw_exception if BOOST_NO_EXCEPTIONS is defined, but your statement above seems to allow a given library's exceptions to be dealt with as the library sees fit, possibly using boost::throw_exception but possibly not. All in all, the combination of [1] and [2] does not give me a clear picture about the semantics of BOOST_NO_EXCEPTIONS, but perhaps it doesn't make any practical difference? I still find this documentation combination confusing, though :( - Jeff [1] http://www.boost.org/doc/libs/1_49_0/libs/config/doc/html/boost_config/boost... [2] http://www.boost.org/doc/libs/1_49_0/libs/exception/doc/configuration_macros...
On Tue, Jun 19, 2012 at 6:33 PM, Robert Ramey <ramey@rrsd.com> wrote:
Jeffrey Lee Hellrung, Jr. wrote:
On Tue, Jun 19, 2012 at 3:51 PM, Robert Ramey <ramey@rrsd.com> wrote: [...]
And of course I'm still smarting from having the BOOST_NO_EXCEPTIONS definition change while I wasn't looking to from what has always been documented in a way that makes some sense to something that I still dont' get.
So I stand behind my suggestions.
Sorry, I've only been glossing over this discussion. Can someone please clarify how BOOST_NO_EXCEPTIONS has changed,
Just look higher in the the thread for Emil's definition of BOOST_NO_EXCEPTIONS. This is different than the one in the documentation which has never changed and in fact is part of another library. This situation has lead to much confusion as to what this macro means as noted higher in the thread.
what specific change Robert (and possibly others) find troubling, and what practical consequences this has had or presently has?
Well, it's left me confused about what it's supposed to be.
Okay, Boost.Config says about BOOST_NO_EXCEPTIONS that "The compiler does not support exception handling...Note that there is no requirement for boost libraries to honor this configuration setting" while Boost.Exception says "This macro disables exception handling in Boost, forwarding all exceptions to a user-defined non-template version of boost::throw_exception<http://www.boost.org/doc/libs/1_49_0/libs/exception/doc/throw_exception.html> ." Is the confusion primarily that there are two descriptions of BOOST_NO_EXCEPTIONS? I certainly find this confusing, and it would be great if these descriptions can be brought more in line with one another. Is the confusion whether this applies to a property of the compiler (as Boost.Config suggests), or whether it is a user-defined setting (as one may infer from Boost.Exception's description)? From a library's point-of-view, I don't see any practical difference; if a library wants to support a defined BOOST_NO_EXCEPTIONS in either case, it can't have any exception handling code. Is the confusion whether respecting the disabling of exception handling is optional within a given library (as stated by Boost.Config) or mandatory, with any exceptions going to boost::throw_exception (as one may infer from Boost.Exception's description)? Except for the apparent requirement implied by Boost.Exception that all libraries will "throw" exceptions through boost::throw_exception when BOOST_NO_EXCEPTIONS is defined, these don't seem incompatible. If a library uses boost::throw_exception to "throw" exceptions, it likely will do so consistently, so will automatically support disabling exception handling. On the other hand, if it doesn't, well, it either doesn't support the disabling of exception handling or it uses its own mechanisms to deal with "exceptional" situations. I presume some libraries may take the latter approach? Meaning the assertion that all exceptions are forwarded to boost::throw_exception is inaccurate?
Ditto for boost::throw_exception.
Ahhh - a somewhat different case. boost throw exception as implemented in a very simple way for a very simple purpose. That purpose was to provide and escape to a global function which one could implement for those platoforms which failed to implement exceptions. This is not so uncommon for embedded systems and some shops which prohibit usage of exceptions.
Okay, I'm following.
The function of this was changed with the inclusion of boost.exception which altered the purpose and implementation of boost::exception in include the functionality of boost.exeption. You should be able to guess what happened. All the librarires which has presumed the original operation started to have changed behavior.
Okay, so I infer that, "before", "boost::throw_exception(e);" was equivalent to "throw e;"; "now", it is equivalent to "throw enable_current_exception(enable_error_info(e));". enable_error_info ensures the thrown object derives from boost::exception, while enable_current_exception "enables exception_ptr support". Okay, I admit, it's been a while since I've read the Boost.Exception docs and I forgot what that "exception_ptr support" means, but I think the point is that the actual thrown object is different "now" from "before". Although I think the idea was that the new thrown object still inherited publicly from the original object, so catch blocks should still function as before. Longer build time, dependence on a new library, new
requirement that the library be only used with rtti turned on.
At this point, based on Emil's and John's responses, it seems these first 2 issues aren't really problems in practice, while the 3rd issue is simply not the case. For some
unfathonable reason, the change in boost::throw_exception was allowed to stand. So these libraries including serialization, boost.filesystem, and some others had to creat their own macros to implement the behavior of the original boost::throw_exception.
Was actual code broken due to the change, and, if so, do you remember any examples? Or were those libraries authors who reimplemented the original functionality simply concerned with the overhead introduced by boost::throw_exception? So now we have the case where
a) the original functionality is not found in boost, anyone who needs it has to implement it on their own. b) the same functionality is re-implemented in several other libraries which required a new round of updating of code a documentation, c) and now we have the situation where a user who invokes something in the core boost - boost::throw_exception is likely to get a lot more than he bargained for.
Basically, if one want's the functionality of boost exeception, he should
#include <boost/exception/thow_exception.hpp> .. boost::exception::throw_exception
and if he want's the original behavior he should be able to say
#include <boost/throw_exception.hpp> ... boost::throw_exception.
gratuitiously changing the behavior of a long standing function in the boost core which other library depend on is an unfriendly practice. I know Emil is convinced that he's done us a big favor by forcing us to convert to behavior which he knows is better for us, But it's not his call to make. It's not for me to go around chaning the behavior of other peoples libraries just because I know better.
Okay, fair enough; this is an understandable but more philosophical point concerning development practices. At this point, though, boost::throw_exception has had these semantics since...well whenever Boost.Exception was released, which appears to be 1.36 based on my changing the version number in the URL of the documentation of boost::throw_exception :/ And it seems like changing it *back* to the pre-1.36 functionality would break more code than the change introduced in 1.36.
(For the record, I've glanced at the blurbs on BOOST_NO_EXCEPTIONS
within Boost.Config and Boost.Exception and it's difficult for me to parse what effect their differences have in practice, and it sounds like others have a good idea what the problem seems to be.)
I hope I clarified this.
Clearly not entirely :) - Jeff
Jeffrey Lee Hellrung, Jr. wrote:
Longer build time, dependence on a new library, new
requirement that the library be only used with rtti turned on.
At this point, based on Emil's and John's responses, it seems these first 2 issues aren't really problems in practice, while the 3rd issue is simply not the case.
It may or may not be the case now. This isn't really relevant to my complaint as you'll see below
For some
unfathonable reason, the change in boost::throw_exception was allowed to stand. So these libraries including serialization, boost.filesystem, and some others had to creat their own macros to implement the behavior of the original boost::throw_exception.
Was actual code broken due to the change,
Well it was noticed because it created problems.
and, if so, do you remember any examples?
of course not. I suppose you could troll the list if you were really interested.
Or were those libraries authors who reimplemented the original functionality simply concerned with the overhead introduced by boost::throw_exception?
Here's the real situation. One invests a HUGE amount of effort that it takes to get a libary over the various boost hurdles. I don't think very many people have any idea what it takes to get something like file_system, serialization, or others into boost. After this huge initial effort you've got to spend some time cleaning up some detail and handling user complaints, upgrading documentation etc. (don't even mention the time it takes to deal with boost tools). So now you can sort of relax as things settle down, you've responded to all the questions by upgrading your documentation, etc. etc. Of course by the time this happens, you're way behind on your "real" work and trying to catch up with that. Then you get a problem. OK well you made the library, you better fix it. After a fair amount of sleuthing, you track it down to a gratuitous change to some other library whose behavior has changed without you noticing. This is incredibly disheartening. You've invested huge amount of effort to get something of this scale "over the hump" and now you've been undermined by someone who really isn't being considerate and/or doesn't know the implications of what he's doing. And, if accepted, this would mean a whole new level of effort you have to engage in - just to keep things from breaking. Originally you dealt with this by building a moat around your app/library and you only depend on other aps/libraries which you can really trust to not let you down. So you do the only thing you really can do. You tweak you app so it doesn't depend on the offending component any more. You have to do this be it just takes too much time to really investigate the implications of introducing a dependency on a new library just to relplace a simple macro. So now your off the hook and you can move on with your life - but boost itself is worse off because of it since now the code base is more confusing and includes replicated functionality which it didn't have before. And it's even worse - Basically it's like an army where everyone wears the same uniform. Now someone with the same uniform as you stabs you in the back, and now you can't trust anyone anymore. So all the assumptions that you used to be able to make - (e.g. I'm not going to be surprised by something out of left field) aren't true any more. So it slows everyone down in the future. And it's even bigger than this. Have you noticed that in many shops the ONLY external library they permit is boost? Have you noticed that the first place people look for C++ code is boost - even though there are at least 100's (maybe 1000's) of C++ code modules available at the touch of a buttone. It's two things a) The review process - which catches most of the situations like this. b) Requirement for a test suite and regular execution thereof. these two things diminish problems like the example here. To me this situation is break down in the revew process - which thankfully is rare. If situations like this were to occur on a regular basis boost wouldn't be nearly as successful as it has been. I hope it should be obvious that I don't see posts like: "you're wrong - it doesn't take that long to compile (anymore)" or "it doesn't have this problem (anymore)" are not really relevant to my concerns. They just miss the real point. Honestly, I have no opinion at all on the merits of boost exception. Even more honest, I haven't even looked at the documentation or code. This is not about boost exception - its about how a developer can be expected to cope if this practice is permited to continue.
Okay, fair enough; this is an understandable but more philosophical point concerning development practices.
right. For me it is the main point.
At this point, though, boost::throw_exception has had these semantics since...well whenever Boost.Exception was released, which appears to be 1.36 based on my changing the version number in the URL of the documentation of boost::throw_exception :/ And it seems like changing it *back* to the pre-1.36 functionality would break more code than the change introduced in 1.36.
lol I didn't follow that. It doesn't matter though as we've already excluded it from our libraries and are unlikely to go back and revisit it as we've got other fish to fry.
(For the record, I've glanced at the blurbs on BOOST_NO_EXCEPTIONS
within Boost.Config and Boost.Exception and it's difficult for me to parse what effect their differences have in practice, and it sounds like others have a good idea what the problem seems to be.)
I hope I clarified this.
Clearly not entirely :)
lol - +1 I"m as confused as ever on the subject. From my standpoint, I'm just that much more greatful that I severed the dependence on this library. FWIW, I think boost.exception would have had much better reception from other authors if the author had a) implemented as I proposed. b) let it "rippen" over a couple of releases. c) made a pitch/case to other library authors about what the benefits would be if his library were included instead of the traditional way of doing things d) explained how users would appreciate the "upgrade". e) explained how there wouldn't be any downsides. f) explained how the library author wouldn't really have to do anything but a couple of simple edits. g) and accepted the fact that it would take time for people to migrate. h) and accepted the fact that in spite of his best efforts, he might not be able to convince everyone. I know it seems like it's a lot easier to just ram it down everyone's throat while they're attention is focused elsewhere. And it likely is - in the short run. But hopefully this thread might convince the next person considers this strategy that it's not really the shortcut it would seem to be. Robert Ramey
On 20/06/2012 23:55, Robert Ramey wrote:
Here's the real situation. One invests a HUGE amount of effort that it takes to get a libary over the various boost hurdles. I don't think very many people have any idea what it takes to get something like file_system, serialization, or others into boost.
A certain level of quality of expected, but calling it huge is an overstatement. A lot of large software development companies have much stricter requirements and expectations for software quality before they ship it.
After this huge initial effort you've got to spend some time cleaning up some detail and handling user complaints, upgrading documentation etc. (don't even mention the time it takes to deal with boost tools). So now you can sort of relax as things settle down, you've responded to all the questions by upgrading your documentation, etc. etc. Of course by the time this happens, you're way behind on your "real" work and trying to catch up with that.
Maintenance is part of software development. Software is never finished and always requires more work. Software that has ceased to be maintained may as well be thrown away. There will *always* be problems as new architectures, new compilers, new version of dependencies get introduced. No software is bug free.
Then you get a problem. OK well you made the library, you better fix it. After a fair amount of sleuthing, you track it down to a gratuitous change to some other library whose behavior has changed without you noticing. This is incredibly disheartening. You've invested huge amount of effort to get something of this scale "over the hump" and now you've been undermined by someone who really isn't being considerate and/or doesn't know the implications of what he's doing. And, if accepted, this would mean a whole new level of effort you have to engage in - just to keep things from breaking.
This is why we have tests. When doing development on anything, with possibly several other things using it or depending on it, it is expected that doing changes might break things. Doing regular tests on a full matrix of compilers and configurations can be used to clearly identify when a problem was introduced, what it is and in what situations and configurations it causes problems. Of course, this needs a good testing mechanism in place to clearly identify which commit is responsible for a test breaking. Boost has something a bit like this, but my guess is that you don't really make use of it in your developments. Efforts are being made by Dave and others to move to better tools (in this case buildbot) to make the whole of Boost more productive.
Originally you dealt with this by building a moat around your app/library and you only depend on other aps/libraries which you can really trust to not let you down.
You normally only need to take such actions for the stable version of your library, not for the development branch. It has been suggested that each library should have its own stable branch.
And it's even worse - Basically it's like an army where everyone wears the same uniform. Now someone with the same uniform as you stabs you in the back, and now you can't trust anyone anymore. So all the assumptions that you used to be able to make - (e.g. I'm not going to be surprised by something out of left field) aren't true any more. So it slows everyone down in the future.
Most software development involves working with other people. It can indeed be annoying when someone breaks your stuff by making a change elsewhere in the code. It happens every day in the projects I work on. It's part of the job.
Honestly, I have no opinion at all on the merits of boost exception. Even more honest, I haven't even looked at the documentation or code. This is not about boost exception - its about how a developer can be expected to cope if this practice is permited to continue.
I've personally found that Boost.Exception has quite a few problems, yet it has some useful functionality that sometimes I need. Don't use it when you don't need it, use it when you do. But as far as throw_exception is concerned, it's pretty much as if it weren't there.
(For the record, I've glanced at the blurbs on BOOST_NO_EXCEPTIONS
within Boost.Config and Boost.Exception and it's difficult for me to parse what effect their differences have in practice, and it sounds like others have a good idea what the problem seems to be.)
I hope I clarified this.
Clearly not entirely :)
lol - +1 I"m as confused as ever on the subject. From my standpoint, I'm just that much more greatful that I severed the dependence on this library.
BOOST_NO_EXCEPTIONS is defined if it is detected that the compiler has disabled exceptions. Users may also manually define BOOST_NO_EXCEPTIONS to disable exceptions regardless of what is detected (useful for compilers which lack a mechanism to disable exceptions explicitly or where it cannot be detected).
On 20 June 2012 16:55, Robert Ramey <ramey@rrsd.com> wrote:
After a fair amount of sleuthing, you track it down to a gratuitous change to some other library whose behavior has changed without you noticing. This is incredibly disheartening.
Here's the *real* situation: Welcome to software development. This can (and usually does) happen whenever I change any libraries, compilers or even compiler flags. It has nothing to do with Boost. Heck, it's been accelerated because compilers and libraries are in various stages of C++11 compliance. Is the burden higher on library writers? Absolutely. It's the nature of the beast. The spectrum is from putting up with a little pain every time something about your environment changes to locking everything down so you have no external dependencies. The alternative is stagnation. Every change has the potential to break something. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Nevin Liber wrote:
On 20 June 2012 16:55, Robert Ramey <ramey@rrsd.com> wrote:
After a fair amount of sleuthing, you track it down to a gratuitous change to some other library whose behavior has changed without you noticing. This is incredibly disheartening.
Here's the *real* situation: Welcome to software development.
True - it's bad enough already - So let's agree not to make it worse if we can avoid it. To put it another way. Good practices will never totally eliminate problems. But they have a HUGE positive effect. It would have cost almost nothing to avoid this situation.
It's the nature of the beast. The spectrum is from putting up with a little pain every time something about your environment changes to locking everything down so you have no external dependencies.
The alternative is stagnation. Every change has the potential to break something.
TL;DR; I see these and simlar arguments as variants of "It's not going to be perfect anyway, so don't sweat the small stuff" (I'm sorry if I mischaracterized your position here - but that's the way I interpret it) And I see this is at the bottom of many, many, problems in software development. It shows up in all sorts of ways that drive me crazy as a user and software developer. For example. as a user: a) constant "upgrades/bug fixes" which load up my computer with tons of junk and make it slower. b) quirky applications which have all sorts of unexpected behavior which makes me feel stupid. c) stuff that doesn't work together as it should d) weired indecipherable dependencies - load one component and some "unrelated" application breaks as a developer a) situation as you describe - change one thing - and something else breaks. b) large amounts of resources just dedicated to keeping things running c) inability to enhance programs wihtout huge effort These latter are our fault. And I disagree that the situation is hopeless and inevitable. They occur because we do things that create these problems and we should know better. In fact we DO know better. But often the person who takes the shortcut is not the person who suffers the concequences, there an irrestible temptation to just do it and let someone else worry about it. To me this is the main problem with the popular scripting languages. You can throw tother something that works in no time and the boss loves it. But you have all the problems mentioned about. C++ is almost unique in it's ability to create and enforce strong typing. This what makes it special. It IS possible to make something (almost) perfect, something (almost) unbreakable, and something (almost) optimally efficient. It demans work that other languages don't but it offers the opportunity to get off the endless treadmill of maintainng a years old application as a career. In order to come close to this idea it does require some disciplen - lack of which I'm addressing here - but it comes close to the holy grail - make it one and never have to go back to it. Lot's of boost libraries come close to achieving this - that's why we love boost. sorry for the rant. Robert Ramey
On 20 June 2012 19:19, Robert Ramey <ramey@rrsd.com> wrote:
Here's the *real* situation: Welcome to software development.
True - it's bad enough already - So let's agree not to make it worse if we can avoid it.
Define "worse". There are multiple conflicting goals. As I pointed out from the FAQ: "Many of the Boost libraries are actively maintained and improved, so backward compatibility with prior version isn't always possible."
"It's not going to be perfect anyway, so don't sweat the small stuff"
Of course we should strive for perfection (even if we can't achieve it), and sweat the small stuff. Now define "perfection". Perfection != 100% backwards compatible. As I said before: "While the bar on changing functionality and/or interfaces is high, it isn't (and never has been, as far as I know) absolute (and it isn't even as high as the C++ standard, nor should it be)." Good practices can reduce (but not eliminate) accidental risk., but ultimately, one has to balance risk of breakage vs. enhancement value. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Nevin Liber wrote:
Good practices can reduce (but not eliminate) accidental risk., but ultimately, one has to balance risk of breakage vs. enhancement value.
Your missing something key here. This injection of a gratuitous dependency wasn't any way necessary. Boost exception could have just as easily used it's own name for this function rather than hijacking an existing one which had a different purpose. This would have been better than, and if fact it would be better now, even though now it would be a "breaking change" This "breaking change was in no way necessary. I think I've tried to point that out. Robert Ramey
On Wed, Jun 20, 2012 at 2:55 PM, Robert Ramey <ramey@rrsd.com> wrote:
Jeffrey Lee Hellrung, Jr. wrote:
Longer build time, dependence on a new library, new
requirement that the library be only used with rtti turned on.
At this point, based on Emil's and John's responses, it seems these first 2 issues aren't really problems in practice, while the 3rd issue is simply not the case.
It may or may not be the case now.
It never was the case. FWIW, I think boost.exception would have had much better reception from
other authors if the author had
I am quite happy with the reception the library got, during the review process and after.
b) let it "rippen" over a couple of releases. c) made a pitch/case to other library authors about what the benefits would be if his library were included instead of the traditional way of doing things d) explained how users would appreciate the "upgrade". e) explained how there wouldn't be any downsides. f) explained how the library author wouldn't really have to do anything but a couple of simple edits. g) and accepted the fact that it would take time for people to migrate. h) and accepted the fact that in spite of his best efforts, he might not be able to convince everyone.
I know it seems like it's a lot easier to just ram it down everyone's throat while they're attention is focused elsewhere.
The Boost review process doesn't seem to resemble ramming things down throats. :) It is clear that you don't approve of the current definition of boost::throw_exception. That's fine, you don't have to use it, but if you want to criticize it, it'd help if you first understand it. Otherwise you end up making unsubstantiated claims, rather than pointing out real problems. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Wed, Jun 20, 2012 at 2:55 PM, Robert Ramey <ramey@rrsd.com> wrote:
It is clear that you don't approve of the current definition of boost::throw_exception. That's fine, you don't have to use it, but if you want to criticize it, it'd help if you first understand it. Otherwise you end up making unsubstantiated claims, rather than pointing out real problems.
lol - I haven't critcised boost exception. I only understand it in the very vaguest terms. I've said this in as many ways as I can think of. I don't know what else to do. I have criticised the way it's introduction into boost was handled. The few posts in the thread which have addressed my critcism have failed to convince me that I'm off track here. Robert Ramey.
On Wed, Jun 20, 2012 at 4:56 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
On Wed, Jun 20, 2012 at 2:55 PM, Robert Ramey <ramey@rrsd.com> wrote:
It is clear that you don't approve of the current definition of boost::throw_exception. That's fine, you don't have to use it, but if you want to criticize it, it'd help if you first understand it. Otherwise you end up making unsubstantiated claims, rather than pointing out real problems.
lol - I haven't critcised boost exception. I only understand it in the very vaguest terms. I've said this in as many ways as I can think of. I don't know what else to do.
I'm confused. I thought you were complaining about build times and dependencies. I mean, if there is a problem with boost::throw_exception or any other part of Boost Exception, I'd like to know about it. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
on Wed Jun 20 2012, Emil Dotchevski <emildotchevski-AT-gmail.com> wrote:
On Wed, Jun 20, 2012 at 4:56 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
On Wed, Jun 20, 2012 at 2:55 PM, Robert Ramey <ramey@rrsd.com> wrote:
It is clear that you don't approve of the current definition of boost::throw_exception. That's fine, you don't have to use it, but if you want to criticize it, it'd help if you first understand it. Otherwise you end up making unsubstantiated claims, rather than pointing out real problems.
lol - I haven't critcised boost exception. I only understand it in the very vaguest terms. I've said this in as many ways as I can think of. I don't know what else to do.
I'm confused. I thought you were complaining about build times and dependencies.
I mean, if there is a problem with boost::throw_exception or any other part of Boost Exception, I'd like to know about it.
Attempting to break a deadlock here... It seems clear to me from his posts that Robert wants to talk about the process and has forgotten any specifics about actual problems. It seems clear to me from your posts that you are most concerned with actual problems. Since he doesn't have the information, why not take his suggestion and search the lists for problems involving throw_exception and serialization? Seems like the only way for you to make progress. I'm not sure how to create progress for Robert, unfortunately. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Jun 21, 2012 at 5:32 PM, Dave Abrahams <dave@boostpro.com> wrote:
Attempting to break a deadlock here...
It seems clear to me from his posts that Robert wants to talk about the process and has forgotten any specifics about actual problems. It seems clear to me from your posts that you are most concerned with actual problems. Since he doesn't have the information, why not take his suggestion and search the lists for problems involving throw_exception and serialization?
I don't need to search, I remember very well. :) In its initial release (1.36), Boost Exception did not support BOOST_NO_RTTI configurations, which seemed reasonable because most compilers require RTTI for exception handling. The workaround was to #define BOOST_EXCEPTION_DISABLE under BOOST_NO_RTTI. A permanent fix was committed to trunk two weeks later, and released with 1.37. Faced with the initial problem, Robert's knee-jerk reaction was to not call boost::throw_exception at all. He changed Boost Serialization, making it incompatible with all previous releases under BOOST_NO_EXCEPTIONS. Someone pointed out Robert's mistake, which he corrected, but not before it got out with the following Boost release (1.37), in which Boost Serialization had his flawed (and unnecessary) workaround, requiring BOOST_NO_EXCEPTIONS users of Boost Serialization to make changes in their code. They had to revert those changes for 1.38. That was the end of it (or so I thought.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On 22 June 2012 04:39, Emil Dotchevski <emildotchevski@gmail.com> wrote:
In its initial release (1.36), Boost Exception did not support BOOST_NO_RTTI configurations, which seemed reasonable because most compilers require RTTI for exception handling. The workaround was to #define BOOST_EXCEPTION_DISABLE under BOOST_NO_RTTI. A permanent fix was committed to trunk two weeks later, and released with 1.37.
If we actually want to improve the process, that suggests to me that it'd be useful to have at least one tester running with rtti disabled (and perhaps another with exceptions disabled) and that we might want to reconsider point releases, which is hopefully easier with a modularised git setup.
On Thu, Jun 21, 2012 at 11:48 PM, Daniel James <dnljms@gmail.com> wrote:
On 22 June 2012 04:39, Emil Dotchevski <emildotchevski@gmail.com> wrote:
In its initial release (1.36), Boost Exception did not support BOOST_NO_RTTI configurations, which seemed reasonable because most compilers require RTTI for exception handling. The workaround was to #define BOOST_EXCEPTION_DISABLE under BOOST_NO_RTTI. A permanent fix was committed to trunk two weeks later, and released with 1.37.
If we actually want to improve the process, that suggests to me that it'd be useful to have at least one tester running with rtti disabled (and perhaps another with exceptions disabled) and that we might want to reconsider point releases, which is hopefully easier with a modularised git setup.
Yes, this is exactly why the problem wasn't detected before the release: we don't test that configuration. RTTI is particularly tricky because it isn't a simple on-off thing, there's BOOST_NO_RTTI and a separate BOOST_NO_TYPEID, plus there is an implicit link between RTTI and exception handling in some (most?) compilers. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
I don't need to search, I remember very well. :)
In its initial release (1.36), Boost Exception did not support BOOST_NO_RTTI configurations, which seemed reasonable because most compilers require RTTI for exception handling.
wow- that's something I never knew
The workaround was to #define BOOST_EXCEPTION_DISABLE under BOOST_NO_RTTI. A permanent fix was committed to trunk two weeks later, and released with 1.37.
Faced with the initial problem, Robert's knee-jerk reaction was to not call boost::throw_exception at all. He changed Boost Serialization, making it incompatible with all previous releases under BOOST_NO_EXCEPTIONS.
Someone pointed out Robert's mistake, which he corrected, but not before it got out with the following Boost release (1.37), in which Boost Serialization had his flawed (and unnecessary) workaround, requiring BOOST_NO_EXCEPTIONS users of Boost Serialization to make changes in their code. They had to revert those changes for 1.38.
Well, I remember it all very differently. Not that it matters. Robert Ramey
That was the end of it (or so I thought.)
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Dave Abrahams wrote:
I mean, if there is a problem with boost::throw_exception or any other part of Boost Exception, I'd like to know about it.
Attempting to break a deadlock here...
It seems clear to me from his posts that Robert wants to talk about the process and has forgotten any specifics about actual problems. It seems clear to me from your posts that you are most concerned with actual problems.
Since he doesn't have the information, why not take his suggestion and search the lists for problems involving throw_exception and serialization?
Seems like the only way for you to make progress.
I'm not sure how to create progress for Robert, unfortunately.
lol - then it doesn't matter as it seems I'm (almost) the only one that is concerned by this. The problem was the gratuitious inclusion of a new dependency. The extent/nature of any problem it created or didn't create is not relevant here. Just the injection of a new body of code which replaced two lines and added no functionality used/needed by the serialization library makes the any library which used boost::throw_exception "bigger" for no reason. It makes the library more "fragil". It means I have I a new place to look if something needs looking into. etc.etc. Sorry, I just can't understand why anyone fails to see this point. So we'll just move on as Vicente suggested. That will be satisfactory from my standpoint. Robert Ramey
On Thu, Jun 21, 2012 at 11:58 PM, Robert Ramey <ramey@rrsd.com> wrote:
Dave Abrahams wrote:
I'm not sure how to create progress for Robert, unfortunately.
lol - then it doesn't matter as it seems I'm (almost) the only one that is concerned by this.
The problem was the gratuitious inclusion of a new dependency. The extent/nature of any problem it created or didn't create is not relevant here. Just the injection of a new body of code which replaced two lines and added no functionality used/needed by the serialization library makes the any library which used boost::throw_exception "bigger" for no reason.
You seem to think that if a library doesn't benefit from calling boost::throw_exception, then the call to boost::throw_exception can't benefit the users of the library. As a matter of fact this is not true. There are practical benefits (to Boost users) from what you call "bigger", while the downside remains abstract.
It makes the library more "fragil". It means I have I a new place to look if something needs looking into. etc.etc.
Sorry, I just can't understand why anyone fails to see this point.
Because you keep talking in the abstract. You'll have better luck if you point out a practical issue with boost::throw_exception.
So we'll just move on as Vicente suggested. That will be satisfactory from my standpoint.
Your satisfaction notwithstanding, there needs to be a reason to change how Boost deals with exceptions. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On 6/22/12 8:58 AM, Robert Ramey wrote:
lol - then it doesn't matter as it seems I'm (almost) the only one that is concerned by this.
The problem was the gratuitious inclusion of a new dependency. The extent/nature of any problem it created or didn't create is not relevant here.
Yes it is, because in reality boost exception solves problems for the users of any library that uses it. When using boost exception I can safely let exceptions escape threads and have them rethrown in the starting thread, for instance.
Just the injection of a new body of code which replaced two lines and added no functionality used/needed by the serialization library makes the any library which used boost::throw_exception "bigger" for no reason.
It has a real and important reason, because it unifies boost exception handling, nearly for free. The few boost libraries which do not use it, serialization most notably, cause trouble because they need extra care to make exception handling well behaved.
It makes the library more "fragil".
No, it gave your users more functionality in an area of which you were not even aware.
It means I have I a new place to look if something needs looking into. etc.etc.
It is a shoulder (not quite a giants, but still) to stand on, which gives you a higher reach! regards Fabio
On 06/22/2012 11:30 AM, Fabio Fracassi wrote:
Yes it is, because in reality boost exception solves problems for the users of any library that uses it. When using boost exception I can safely let exceptions escape threads and have them rethrown in the starting thread, for instance.
I use this heavily and it works great while simplifying code considerably. Got rid of bubbling errors and multiple ways to do exceptions/errors. When the unified boost exceptions came into existence tried them and immediately found a difference in code style, code size, readability and code maintenance. Boost threads, smart pointers, unified exceptions, timers, etc. improved C++ multi-thread programming for me considerably. And now boost threads and exceptions are working with the same code on Windows, Mac and Linux with all gnu compile.
... It has a real and important reason, because it unifies boost exception handling, nearly for free. The few boost libraries which do not use it, serialization most notably, cause trouble because they need extra care to make exception handling well behaved.
Catching and handling is now so much better it is good to reflect on what was achieved since ~1.38
Fabio Fracassi wrote:
On 6/22/12 8:58 AM, Robert Ramey wrote:
The problem was the gratuitious inclusion of a new dependency. The extent/nature of any problem it created or didn't create is not relevant here.
Yes it is, because in reality boost exception solves problems for the users of any library that uses it. When using boost exception I can safely let exceptions escape threads and have them rethrown in the starting thread, for instance.
well, not every application uses threads. Really, I don't think anyone can say "solves problems for ANY library which uses it." without knowing what the application is.
Just the injection of a new body of code which replaced two lines and added no functionality used/needed by the serialization library makes the any library which used boost::throw_exception "bigger" for no reason.
It has a real and important reason, because it unifies boost exception handling, nearly for free. The few boost libraries which do not use it, serialization most notably, cause trouble because they need extra care to make exception handling well behaved.
Is there any reason you can't trap any exception from a library and rethrow it using boost.exception in your own application?
It makes the library more "fragil".
No, it gave your users more functionality in an area of which you were not even aware.
That's exactly what makes it more fragil. From my standpoint, I'm on the hook for any problem which occurs in the injected code. Code actually have no idea what it does.
It means I have I a new place to look if something needs looking into. etc.etc.
It is a shoulder (not quite a giants, but still) to stand on, which gives you a higher reach!
Gives YOU a higher reach - at my expense. I will say you've given a rousing endorsement of boost exception and a good case for it's merits. I'm not convinced that you've all the applications of boost libraries outside your problem domain. If someone wanted to take a serious look at the something the serialization (or other library) and propose some enhance me - maybe via a policy argument or whatever and create a TRAC item, that would be one thng. But for one person to inject code/depency into a separate library because he "knows better what users need" isn't a great idea (unless he wants to take over maintainence of the library - which of course would be a whole different thing. Robert Ramey
regards
Fabio
On Fri, Jun 22, 2012 at 12:55 PM, Robert Ramey <ramey@rrsd.com> wrote:
Fabio Fracassi wrote:
On 6/22/12 8:58 AM, Robert Ramey wrote:
The problem was the gratuitious inclusion of a new dependency. The extent/nature of any problem it created or didn't create is not relevant here.
Yes it is, because in reality boost exception solves problems for the users of any library that uses it. When using boost exception I can safely let exceptions escape threads and have them rethrown in the starting thread, for instance.
well, not every application uses threads. Really, I don't think anyone can say "solves problems for ANY library which uses it." without knowing what the application is.
This works the other way around too. A library developer, without knowing what the application is, shouldn't be preventing the user from using Boost Exception with the exceptions emitted by the library. When a library calls boost::throw_exception, this potentially solves problems for the USERS of the library (depending on the architecture of the application), even if the library itself doesn't benefit. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On 6/22/12 9:55 PM, Robert Ramey wrote:
Fabio Fracassi wrote:
On 6/22/12 8:58 AM, Robert Ramey wrote:
The problem was the gratuitious inclusion of a new dependency. The extent/nature of any problem it created or didn't create is not relevant here.
Yes it is, because in reality boost exception solves problems for the users of any library that uses it. When using boost exception I can safely let exceptions escape threads and have them rethrown in the starting thread, for instance.
well, not every application uses threads. Really, I don't think anyone can say "solves problems for ANY library which uses it." without knowing what the application is.
Ok, let me rephrase that, it solves the problem for any application which have it. Without harming others. More functionality is good! (and yes I know that more functionality has a cost)
It has a real and important reason, because it unifies boost exception handling, nearly for free. The few boost libraries which do not use it, serialization most notably, cause trouble because they need extra care to make exception handling well behaved.
Is there any reason you can't trap any exception from a library and rethrow it using boost.exception in your own application?
Of course I can, and that's what I end up doing. Its just onerous, and because I know that there is an easier and cleaner way it feels like a workaround hack. As Roger Martin stated in another reply: "I use this heavily and it works great while simplifying code considerably. Got rid of bubbling errors and multiple ways to do exceptions/errors. When the unified boost exceptions came into existence tried them and immediately found a difference in code style, code size, readability and code maintenance" Boost Exception allows me to ignore the issue, I don't even have to know if a peace of code does threading and needs it, it will just work when I do. These kind of 'Abstraction Enablers' provide real progress for programming in general, much more than the concrete functionality value alone.
It makes the library more "fragil".
No, it gave your users more functionality in an area of which you were not even aware.
That's exactly what makes it more fragil. From my standpoint, I'm on the hook for any problem which occurs in the injected code. Code actually have no idea what it does.
Thats what I gathered, and what I disagree with. IMVHO This stance you take does not scale.
It means I have I a new place to look if something needs looking into. etc.etc.
It is a shoulder (not quite a giants, but still) to stand on, which gives you a higher reach!
Gives YOU a higher reach - at my expense.
I will say you've given a rousing endorsement of boost exception and a good case for it's merits.
I'm not convinced that you've all the applications of boost libraries outside your problem domain. If someone wanted to take a serious look at the something the serialization (or other library) and propose some enhance me - maybe via a policy argument or whatever and create a TRAC item, that would be one thng. But for one person to inject code/depency into a separate library because he "knows better what users need" isn't a great idea (unless he wants to take over maintainence of the library - which of course would be a whole different thing.
That is how modular development works, you let go of some control in exchange for synergy effects and free added functionality. Yes, it creates communication overhead but the win (for the users) is huge. regards Fabio
on Fri Jun 22 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Dave Abrahams wrote:
I mean, if there is a problem with boost::throw_exception or any other part of Boost Exception, I'd like to know about it.
Attempting to break a deadlock here...
It seems clear to me from his posts that Robert wants to talk about the process and has forgotten any specifics about actual problems. It seems clear to me from your posts that you are most concerned with actual problems.
Since he doesn't have the information, why not take his suggestion and search the lists for problems involving throw_exception and serialization?
Seems like the only way for you to make progress.
I'm not sure how to create progress for Robert, unfortunately.
lol - then it doesn't matter as it seems I'm (almost) the only one that is concerned by this.
The problem was the gratuitious inclusion of a new dependency.
I wish you would stop using the term "gratuitous" here. I don't have any position on who's right or what's better, but clearly some people thought the inclusion of this dependency had a purpose and wasn't totally unnecessary.
The extent/nature of any problem it created or didn't create is not relevant here. Just the injection of a new body of code which replaced two lines and added no functionality used/needed by the serialization library makes the any library which used boost::throw_exception "bigger" for no reason. It makes the library more "fragil". It means I have I a new place to look if something needs looking into. etc.etc.
Sorry, I just can't understand why anyone fails to see this point.
Because, while it's true that it has those effects, that sort of thing happens all the time, and most of us see no reasonable way of stopping it without severely constraining Boost development. Don't you regularly "inject new bodies of code" into Boost.Serialization that "replace lines and add no functionality used/needed by" Boost.MPI? Don't you expect the author of type_traits to do the same thing?
So we'll just move on as Vicente suggested. That will be satisfactory from my standpoint.
I'm happy to move on if you're really going to put this behind you. If you won't truly be able to, then we should keep talking until we can all understand each other because this is at least the 2nd time we've had a long argument about it and it would be a shame to have to go over the same ground again. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams wrote:
on Fri Jun 22 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Sorry, I just can't understand why anyone fails to see this point.
Because, while it's true that it has those effects, that sort of thing happens all the time, and most of us see no reasonable way of stopping it without severely constraining Boost development.
Don't you regularly "inject new bodies of code" into Boost.Serialization that "replace lines and add no functionality used/needed by" Boost.MPI?
No. I don't do this. I have made some mistakes - particularly in the implementation of binary_iarchive which have broken other peoples code. But I assure you this was totally unintentional. This wouldn't mean that no new code is never added. Natually one could add a new archive type. But that would only affect those who conciously chose to use it. But that would of course that be a different case.
Don't you expect the author of type_traits to do the same thing?
No. I don't. If I use something like "is_arithmetic" I expect it's functionality to not change in the future.
So we'll just move on as Vicente suggested. That will be satisfactory from my standpoint.
I'm happy to move on if you're really going to put this behind you. If you won't truly be able to, then we should keep talking until we can all understand each other because this is at least the 2nd time we've had a long argument about it and it would be a shame to have to go over the same ground again.
I'm sympathetic to you view here. It wasn't really resolved before - we just worked around it. Basically this is what we're going to continue to do albeit is a less ad hoc way. I'm really sympathetic to those who see this as a pointless, endlee argument. But obviously it's not for those of us involved in it. For the most part I don't doubt the good intentions and sincerity of those who are disagreeing with me here. I just think they're wrong and they they have failed to make a convincing argument that I'm wrong. And I believe that these "wrong ideas" (my view) make a large negative impact on software usability and quality. That's why I take pains to try to exclude them from the serialization library. No Doubt Emil feels the same way about his ideas. So there can really be no real resolution, we can only muddle forward - which is not the worst thing we could do. Robert Ramey
on Fri Jun 22 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Dave Abrahams wrote:
on Fri Jun 22 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Sorry, I just can't understand why anyone fails to see this point.
Because, while it's true that it has those effects, that sort of thing happens all the time, and most of us see no reasonable way of stopping it without severely constraining Boost development.
Don't you regularly "inject new bodies of code" into Boost.Serialization that "replace lines and add no functionality used/needed by" Boost.MPI?
No. I don't do this.
I believe you mean that sincerely, but I just don't see how it's possible for you to know that. Do you keep track of exactly which of Boost.Serialization's headers is being used by every dependent Boost library and make sure that *no* new capabilities creep into any of those headers as you extend/evolve the library? Even if you _can_ do that for other Boost libraries, you can't possibly do it for your users.
I have made some mistakes - particularly in the implementation of binary_iarchive which have broken other peoples code. But I assure you this was totally unintentional.
Of course it was. Do you think the problems with boost::throw_exception were intentional?
This wouldn't mean that no new code is never added. Natually one could add a new archive type. But that would only affect those who conciously chose to use it.
Yes, if you never touch existing headers, you will never cause such a situation. But surely you do change existing headers from time-to-time?
But that would of course that be a different case.
Don't you expect the author of type_traits to do the same thing?
No. I don't.
If I use something like "is_arithmetic" I expect it's functionality to not change in the future.
That's not at all like what you said happened. Sure you would expect is_arithmetic to remain the same. What you said was that "new bodies of code" were "injected" that "add no functionality used/needed by Boost.Serialization." We did that to type_traits when we upgraded it to work more smoothly with Boost.MPL. Changes like that are rare, but changes like this one aren't: The maintainer of is_arithmetic makes changes to support compiler X. Boost.Serialization does not support compiler X. Therefore these changes "add no functionality used/needed by Boost.Serialization." Such changes might be arbitrarily complicated, including pulling in new header files.
I'm happy to move on if you're really going to put this behind you. If you won't truly be able to, then we should keep talking until we can all understand each other because this is at least the 2nd time we've had a long argument about it and it would be a shame to have to go over the same ground again.
I'm sympathetic to you view here. It wasn't really resolved before - we just worked around it. Basically this is what we're going to continue to do albeit is a less ad hoc way.
We have a plan that's less ad-hoc than the last one?
I'm really sympathetic to those who see this as a pointless, endless argument.
I'm not among them. I'm just trying to do everything possible to ensure that this time around the argument is point-ful.
But obviously it's not for those of us involved in it. For the most part I don't doubt the good intentions and sincerity of those who are disagreeing with me here. I just think they're wrong and they they have failed to make a convincing argument that I'm wrong. And I believe that these "wrong ideas" (my view) make a large negative impact on software usability and quality.
Some of us are arguing with you because we respect your opinions on these matters, but aren't able to see the "wrong ideas" you've been pointing at. Arguing is a way of probing for enlightenment. My guess so far is that you have something real in mind, but you're not expressing it with enough precision for others to grasp it. I think it might help if you could make an effort to be extremely concise, so your point is in a non-TL;DR context. If you use very few words it should be very obvious to you whether they'll communicate what you actually mean to say. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams wrote:
on Fri Jun 22 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Dave Abrahams wrote:
on Fri Jun 22 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Sorry, I just can't understand why anyone fails to see this point.
Because, while it's true that it has those effects, that sort of thing happens all the time, and most of us see no reasonable way of stopping it without severely constraining Boost development.
Don't you regularly "inject new bodies of code" into Boost.Serialization that "replace lines and add no functionality used/needed by" Boost.MPI?
No. I don't do this.
I believe you mean that sincerely, but I just don't see how it's possible for you to know that. Do you keep track of exactly which of Boost.Serialization's headers is being used by every dependent Boost library and make sure that *no* new capabilities creep into any of those headers as you extend/evolve the library? Even if you _can_ do that for other Boost libraries, you can't possibly do it for your users.
I use other libraries in the implementation. These implementation details are generally not directly accessible by the library user. Any code injection/enhancement would be something that users would see in library portability, performance, robustness etc. It's my job to ensure that that is what happens. Actually, you've hit the nail on the head here. Chaning boost::throw_exception injects a dependency on a whole other boost library into the serialization library. And of course this is the crux of my complaint.
Of course it was. Do you think the problems with boost::throw_exception were intentional?
I'm sure the changes were intentional. I think the dispute is about whether those changes are problems (my view) or useful features whose value far exceeds any side effects of the changes (other's view) that.
But surely you do change existing headers from time-to-time?
only to a) fix bugs b) re-implement some existing interface c) add some new feature to the serialization library d) improve robustness, portability, etc. note that this above list does not include changing the functionality corresponding to some already existing interface - which is what we're talking about here.
But that would of course that be a different case.
Don't you expect the author of type_traits to do the same thing?
No. I don't.
If I use something like "is_arithmetic" I expect it's functionality to not change in the future.
That's not at all like what you said happened. Sure you would expect is_arithmetic to remain the same.
What you said was that "new bodies of code" were "injected" that "add no functionality used/needed by Boost.Serialization."
well, boost::throw_exception(x) wraps the x in some other class with some other stuff and does a throw. The serialization library does't use this. In order do this, I has to include some headers from boost exception. I've labeled this "code injection". Maybe it should have been "dependcy extension" but not the less I don't think I've said anything misleading..
We did that to type_traits when we upgraded it to work more smoothly with Boost.MPL. Changes like that are rare, but changes like this one aren't:
The maintainer of is_arithmetic makes changes to support compiler X. Boost.Serialization does not support compiler X. Therefore these changes "add no functionality used/needed by Boost.Serialization."
Such changes might be arbitrarily complicated, including pulling in new header files.
In this example the choice is clear. Either add suport for compiler X at the cost of increasing the code base or leave compiler X unsupported. And as the person responsable for the serialization library - I need to have the authority to make this decision. In this case the decision was made for me and didn't really evaluate all the concequences. This is no surprise because changes like this have a much larger ripple effect that first meets the eye. This has been my principal objection from the begining. Take the pottery barn rule: "if you break it, you bought it" this seems reasonable. Hence the following must be true: "If you're not prepared to buy it, don't risk breaking it!" So, unless one is prepared to take responsablity for the consequences, to muck with some other library.
We have a plan that's less ad-hoc than the last one?
There are number of other libraries which have implemented the same work around that the serialization library has - presumably for similar motivations. Each of these has been specified in it's own namespace. We're considering consolidating these into one header in the boost namespace/directory to put all these work arounds in a single place. Basically this would give a new name to the original boost::throw() functionality.
My guess so far is that you have something real in mind, but you're not expressing it with enough precision for others to grasp it. I think it might help if you could make an effort to be extremely concise, so your point is in a non-TL;DR context. If you use very few words it should be very obvious to you whether they'll communicate what you actually mean to say.
lol - could be. but it's not as easy as it looks. I'll try. Robert Ramey
on Sat Jun 23 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Dave Abrahams wrote:
on Fri Jun 22 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Dave Abrahams wrote:
on Fri Jun 22 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Sorry, I just can't understand why anyone fails to see this point.
Because, while it's true that it has those effects, that sort of thing happens all the time, and most of us see no reasonable way of stopping it without severely constraining Boost development.
Don't you regularly "inject new bodies of code" into Boost.Serialization that "replace lines and add no functionality used/needed by" Boost.MPI?
No. I don't do this.
I believe you mean that sincerely, but I just don't see how it's possible for you to know that. Do you keep track of exactly which of Boost.Serialization's headers is being used by every dependent Boost library and make sure that *no* new capabilities creep into any of those headers as you extend/evolve the library? Even if you _can_ do that for other Boost libraries, you can't possibly do it for your users.
I use other libraries in the implementation. These implementation details are generally not directly accessible by the library user.
Of course they are, if they end up in the user's translation unit. The user only has to have a "using namespace boost;" in his code to create an instant ambiguity when one of your "implementation details" adds a new name, or when you add a new implementation detail yourself. Blame it on the C language inclusion model. We need true modules in C++, but that's irrelevant to this conversation.
Any code injection/enhancement would be something that users would see in library portability, performance, robustness etc. It's my job to ensure that that is what happens.
You mean to ensure that it (users seeing changes in portability, performance, robustness, etc) *doesn't* happen?
Actually, you've hit the nail on the head here. Chaning boost::throw_exception injects a dependency on a whole other boost library into the serialization library. And of course this is the crux of my complaint.
In general it's hard for me to believe that you'd complain (or probably even ever notice) if one of the libraries you depend on as an "implementation detail" added a dependency of its own, and thereby injected a new dependency into Boost.Serialization... unless this change happened to break something. I assert that this kind of thing happens all the time: every Boost library author (well, maybe Peter Dimov is an exception) feels free to start using some new library as an "implementation detail" of his own.
Of course it was. Do you think the problems with boost::throw_exception were intentional?
I'm sure the changes were intentional. I think the dispute is about whether those changes are problems (my view) or useful features whose value far exceeds any side effects of the changes (other's view) that.
But surely you do change existing headers from time-to-time?
only to
a) fix bugs b) re-implement some existing interface c) add some new feature to the serialization library d) improve robustness, portability, etc.
note that this above list does not include changing the functionality corresponding to some already existing interface - which is what we're talking about here.
Any of these actions could result in "new bodies of code" being "injected" that "add add no functionality used/needed by" Boost.MPI (to choose "at random" one dependent of Boost.Serialization), and probably, they often do.
But that would of course that be a different case.
Don't you expect the author of type_traits to do the same thing?
No. I don't.
If I use something like "is_arithmetic" I expect it's functionality to not change in the future.
That's not at all like what you said happened. Sure you would expect is_arithmetic to remain the same.
What you said was that "new bodies of code" were "injected" that "add no functionality used/needed by Boost.Serialization."
well, boost::throw_exception(x) wraps the x in some other class with some other stuff and does a throw.
Right. That changes the type actually thrown, and that's a change of behavior someone slipped in, which is a totally different issue from the header dependency issue. The change of behavior in this case is almost certainly benign most of the time, since the exception actually thrown has a copy of x as a base subobject...but still, it's a substantial change of behavior, and it's entirely legitimate to complain if and when something like this happens behind your back (I'm not saying it did or didn't happen behind your back, though; I don't know the history well enough to judge).
The serialization library does't use this. In order do this, I has to include some headers from boost exception. I've labeled this "code injection". Maybe it should have been "dependcy extension" but not the less I don't think I've said anything misleading..
No, I don't think so either. I just think you fail to appreciate how easily, silently, and commonly header dependencies actually proliferate in Boost. These things happen *all the time*, and you never even notice.
We did that to type_traits when we upgraded it to work more smoothly with Boost.MPL. Changes like that are rare, but changes like this one aren't:
The maintainer of is_arithmetic makes changes to support compiler X. Boost.Serialization does not support compiler X. Therefore these changes "add no functionality used/needed by Boost.Serialization."
Such changes might be arbitrarily complicated, including pulling in new header files.
In this example the choice is clear. Either add suport for compiler X at the cost of increasing the code base or leave compiler X unsupported. And as the person responsable for the serialization library - I need to have the authority to make this decision. In this case the decision was made for me
The decision about change of behavior was made for you. Let's just keep that clearly distinguished from the library dependency issue, please.
and didn't really evaluate all the concequences.
Who didn't?
This is no surprise because changes like this have a much larger ripple effect that first meets the eye. This has been my principal objection from the begining.
Take the pottery barn rule:
"if you break it, you bought it"
this seems reasonable. Hence the following must be true:
"If you're not prepared to buy it, don't risk breaking it!"
So, unless one is prepared to take responsablity for the consequences, to muck with some other library.
Emil clearly was prepared to take responsibility for the consequences, and he did. He broke something (bad Emil!), and then he fixed it (good man!). What am I missing?
We have a plan that's less ad-hoc than the last one?
There are number of other libraries which have implemented the same work around that the serialization library has - presumably for similar motivations. Each of these has been specified in it's own namespace. We're considering consolidating these into one header in the boost namespace/directory to put all these work arounds in a single place. Basically this would give a new name to the original boost::throw() functionality.
I see. Doesn't handle the cultural rift, but it's cleaner architecturally than the status quo. I'm still concerned that we get this issue figured out though.
My guess so far is that you have something real in mind, but you're not expressing it with enough precision for others to grasp it. I think it might help if you could make an effort to be extremely concise, so your point is in a non-TL;DR context. If you use very few words it should be very obvious to you whether they'll communicate what you actually mean to say.
lol - could be. but it's not as easy as it looks.
Of course not. There are several famous quotations about how concision is harder than verbosity. But it is worth the effort. I work at it every time I write.
I'll try.
Thank you! I mean that sincerely. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Here's the real situation. One invests a HUGE amount of effort that it takes to get a libary over the various boost hurdles. I don't think very many people have any idea what it takes to get something like file_system, serialization, or others into boost. After this huge initial effort you've got to spend some time cleaning up some detail and handling user complaints, upgrading documentation etc. (don't even mention the time it takes to deal with boost tools). So now you can sort of relax as things settle down, you've responded to all the questions by upgrading your documentation, etc. etc. Of course by the time this happens, you're way behind on your "real" work and trying to catch up with that.
For sure, and I've been bitten by that a few times, come to that I think I may have caused that a few times for which I apologise. I also was seem to dimly remember being bitten by the changes to Boost.Exception when they happened, but you no what? Not once since, never. That's a pretty good record IMO.
FWIW, I think boost.exception would have had much better reception from other authors if the author had
a) implemented as I proposed. b) let it "rippen" over a couple of releases. c) made a pitch/case to other library authors about what the benefits would be if his library were included instead of the traditional way of doing things d) explained how users would appreciate the "upgrade". e) explained how there wouldn't be any downsides. f) explained how the library author wouldn't really have to do anything but a couple of simple edits. g) and accepted the fact that it would take time for people to migrate. h) and accepted the fact that in spite of his best efforts, he might not be able to convince everyone.
All of which are good arguments, except they're *4 years too late*. Sorry but suggesting we just revert something back to a way it never actually was in the first place, after it's been functioning apparently OK for 4 years, and which users may well have been relying on over that time isn't going to wash. Surprising how fast time goes yours, John.
John Maddock wrote:
Sorry but suggesting we just revert something back to a way it never actually was in the first place, after it's been functioning apparently OK for 4 years, and which users may well have been relying on over that time isn't going to wash.
lol - I guess the best arguement against my proposal would be to say that my proposal at this point (if that's what it was) would be engaging in the same practice that I've been arguing against in the first place. Which would be a tough argument to counter. It's sort of like eating my own tail. lol If this discussion prevents some future library author from gratuitously extending the dependencies of existing code, it will have been worthwhile. Still, I would like to consider one thing that might inprove things; a) boost::throw_exception would be deprecated. (not changed) b) the same facility would be invoked by: #include <boost/exception/throw_exception.hpp> ... boost::exception::throw_exception .... as usual, the deprecation would mean a) an initial period of compile time warning b) eventual elmination. This later stage would create a compile time error which would be trivial fixable. No program bugs would be introduced. This would advise programmers who've been inadvertantly including boost::exception that they are in fact doing so and give them the opportunity to decide whether or not they really want to do this. Of course this might require them to read at least some of the documentation of boost exception. This is not a bad thing. Authors of new code would conciously decide whether or not they were including boost exception. Also not a bad thing. Note that I'm not making any judgment on the merits of boost exception itself. This about limiting unintentional dependcies. Boost exception just happens to be the main example here. Robert Ramey
Le 21/06/12 19:12, Robert Ramey a écrit :
Sorry but suggesting we just revert something back to a way it never actually was in the first place, after it's been functioning apparently OK for 4 years, and which users may well have been relying on over that time isn't going to wash. lol - I guess the best arguement against my proposal would be to say
John Maddock wrote: that my proposal at this point (if that's what it was) would be engaging in the same practice that I've been arguing against in the first place. Which would be a tough argument to counter. It's sort of like eating my own tail. lol
If this discussion prevents some future library author from gratuitously extending the dependencies of existing code, it will have been worthwhile.
Still, I would like to consider one thing that might inprove things;
a) boost::throw_exception would be deprecated. (not changed) b) the same facility would be invoked by:
#include<boost/exception/throw_exception.hpp> ... boost::exception::throw_exception ....
Hi Robert, I propose you a different thing. Instead of changing again the name of boost::throw_exception, we can add something like boost::throw_strict_exception that will either throw the given exception or no throw at all depending on BOOST_NO_EXCEPTIONS as it was the case before the introduction of Boost.Exception. Best, Vicente
Vicente J. Botet Escriba wrote:
Hi Robert,
I propose you a different thing. Instead of changing again the name of boost::throw_exception, we can add something like boost::throw_strict_exception that will either throw the given exception or no throw at all depending on BOOST_NO_EXCEPTIONS as it was the case before the introduction of Boost.Exception.
Nothing wrong with this idea. It would address the situation where multiple libraries are re-implenting the same functionaliy to avoid the extra dependency. (I'm not all that crazy about the name - maybe boost::maybe_throw_exception). So I'm on board with this if we can't get a concensus on fixing the root problem. Robert Ramey
Le 22/06/12 01:55, Robert Ramey a écrit :
Vicente J. Botet Escriba wrote:
Hi Robert,
I propose you a different thing. Instead of changing again the name of boost::throw_exception, we can add something like boost::throw_strict_exception that will either throw the given exception or no throw at all depending on BOOST_NO_EXCEPTIONS as it was the case before the introduction of Boost.Exception.
Nothing wrong with this idea. It would address the situation where multiple libraries are re-implenting the same functionaliy to avoid the extra dependency. (I'm not all that crazy about the name - maybe boost::maybe_throw_exception). So I'm on board with this if we can't get a concensus on fixing the root problem.
I don't see any other way if backward compatibility must be preserved ;-) I like the maybe_ prefix. It states clearly the intent of the function. What about boost::maybe_throw(e)? It is shorter and closer to the throw(e) it is a replacement of. Could you see if the authors that have its own throw_exception version share the approach? Best, Vicente
On Thu, Jun 21, 2012 at 10:12 AM, Robert Ramey <ramey@rrsd.com> wrote:
a) boost::throw_exception would be deprecated. (not changed)
I'm yet to see a problem identified with boost::throw_exception, in terms of anything at all -- speed, space, build times, whatever. Removing functionality from a function breaks code. What is the pain you want to alleviate, that justifies deprecation? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Thu, Jun 21, 2012 at 10:12 AM, Robert Ramey <ramey@rrsd.com> wrote:
a) boost::throw_exception would be deprecated. (not changed)
I'm yet to see a problem identified with boost::throw_exception, in terms of anything at all -- speed, space, build times, whatever.
lol
Removing functionality from a function breaks code. What is the pain you want to alleviate, that justifies deprecation?
the pain would be miniscule. it would result in a trivial compile error which would take only a couple of minutes to fix. To me this is a small price to pay to address that the problem with gratuitous dependency extension. I realize you (and others) don't see this is a problem - we just have to agree to disagree on this. Robert Ramey
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, Jun 21, 2012 at 4:56 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
On Thu, Jun 21, 2012 at 10:12 AM, Robert Ramey <ramey@rrsd.com> wrote:
a) boost::throw_exception would be deprecated. (not changed)
I'm yet to see a problem identified with boost::throw_exception, in terms of anything at all -- speed, space, build times, whatever.
lol
Yes. That. :)
Removing functionality from a function breaks code. What is the pain you want to alleviate, that justifies deprecation?
the pain would be miniscule. it would result in a trivial compile error which would take only a couple of minutes to fix. To me this is a small price to pay to address that the problem with gratuitous dependency extension. I realize you (and others) don't see this is a problem - we just have to agree to disagree on this.
Oh, you can disagree, but this does not warrant an action, much less an action that breaks code. For that, you need facts rather than rhetoric and unsubstantiated claims. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
I took some time to dig up and read some earlier threads on this. Major deja vu here, yo. On Wed, Jun 20, 2012 at 2:55 PM, Robert Ramey <ramey@rrsd.com> wrote:
Jeffrey Lee Hellrung, Jr. wrote:
[...]
For some
unfathonable reason, the change in boost::throw_exception was allowed to stand. So these libraries including serialization, boost.filesystem, and some others had to creat their own macros to implement the behavior of the original boost::throw_exception.
Was actual code broken due to the change,
Well it was noticed because it created problems.
and, if so, do you remember any examples?
of course not. I suppose you could troll the list if you were really interested.
I was and I did. I've found 2 threads which seem to refer to problems observed in Boost.Serialization due to the Boost.Exception update of boost::throw_exception. One thread [1] (dated from May 2008) mentions the error of using throw_exception to throw non-class types and class types which do not inherit from std::exception; that specific requirement was not explicitly documented prior to the Exception update of throw_exception and only implicitly documented based on the code and the signature of the user-defined hook. It seems like this root cause of the original problem was identified fairly quickly. A fix to Serialization was or would have been fairly trivial, but I guess introduced or would have introduced a minor backward-compatibility issue...? A second thread [2] (dated August 2008) started by Robert mentions "issues with the serialization library" which prompted him to "investigate boost/throw_exception.hpp", but...I couldn't find any reference to said issues :(
Or were those libraries authors who reimplemented the
original functionality simply concerned with the overhead introduced by boost::throw_exception?
Here's the real situation. One invests a HUGE amount of effort that it takes to get a libary over the various boost hurdles. I don't think very many people have any idea what it takes to get something like file_system, serialization, or others into boost. After this huge initial effort you've got to spend some time cleaning up some detail and handling user complaints, upgrading documentation etc. (don't even mention the time it takes to deal with boost tools). So now you can sort of relax as things settle down, you've responded to all the questions by upgrading your documentation, etc. etc. Of course by the time this happens, you're way behind on your "real" work and trying to catch up with that.
Understood! Then you get a problem. OK well you made the library, you better
fix it. After a fair amount of sleuthing, you track it down to a gratuitous change to some other library whose behavior has changed without you noticing.
I presume "some other library" == boost::throw_exception? AFACT, any behavioral changes to throw_exception were *intended* to be fully backward compatible. So I would think that any *breaking* changes as you describe should (or should have been) filed as a bug against boost::throw_exception. This is incredibly disheartening. You've invested huge
amount of effort to get something of this scale "over the hump" and now you've been undermined by someone who really isn't being considerate and/or doesn't know the implications of what he's doing.
Sorry, this sounds is starting to sound like an unfair personal attack against the individual (Emil) who happened to spearhead the changes to boost::throw_exception. AFAICT, some of the proposed changes to boost::throw_exception did not originate with Emil, and ultimately there was enough consensus from the community to move forward with these proposed changes (whether this was right or wrong is another issue). And, if accepted, this would mean a whole new level of effort you have
to engage in - just to keep things from breaking.
Originally you dealt with this by building a moat around your app/library and you only depend on other aps/libraries which you can really trust to not let you down. So you do the only thing you really can do. You tweak you app so it doesn't depend on the offending component any more.
Although I understand your motivations, I still find it a little ironic that in your endeavor to rid yourself of boost::throw_exception you introduced a breaking change to Boost.Serialization [3]. In any case, this isn't the only thing you can do. One could work with community to iron out any issues with your use of boost::throw_exception. You have to do this be it just takes too much time to really
investigate the implications of introducing a dependency on a new library just to relplace a simple macro. So now your off the hook and you can move on with your life - but boost itself is worse off because of it since now the code base is more confusing and includes replicated functionality which it didn't have before.
Yes, I agree, it is worse off. [...snip back-stabbing...] And it's even bigger than this. Have you noticed that in many shops
the ONLY external library they permit is boost? Have you noticed that the first place people look for C++ code is boost - even though there are at least 100's (maybe 1000's) of C++ code modules available at the touch of a buttone. It's two things
a) The review process - which catches most of the situations like this. b) Requirement for a test suite and regular execution thereof.
these two things diminish problems like the example here. To me this situation is break down in the revew process - which thankfully is rare. If situations like this were to occur on a regular basis boost wouldn't be nearly as successful as it has been.
AFAIK, many Boost-wide decisions are made via consensus among the Boost community. This appears to me to be such a decision.
I hope it should be obvious that I don't see posts like: "you're wrong - it doesn't take that long to compile (anymore)" or "it doesn't have this problem (anymore)" are not really relevant to my concerns. They just miss the real point.
I don't think they do miss the real point. Backward compatible changes should be allowed to be introduced into any Boost component, but this obviously carries a risk that what an author *thinks* is backward compatible actually breaks something; that's a bug in said component. If the bug is addressed, everyone's happy, right? Even if you don't agree, your side of the story would still be more convincing if you could be more concrete about the actual problems introduced by the Boost.Exception update of boost::throw_exception. [...]
FWIW, I think boost.exception would have had much better reception from other authors if the author had
a) implemented as I proposed. b) let it "rippen" over a couple of releases. c) made a pitch/case to other library authors about what the benefits would be if his library were included instead of the traditional way of doing things d) explained how users would appreciate the "upgrade". e) explained how there wouldn't be any downsides. f) explained how the library author wouldn't really have to do anything but a couple of simple edits. g) and accepted the fact that it would take time for people to migrate. h) and accepted the fact that in spite of his best efforts, he might not be able to convince everyone.
I know it seems like it's a lot easier to just ram it down everyone's throat while they're attention is focused elsewhere. And it likely is - in the short run. But hopefully this thread might convince the next person considers this strategy that it's not really the shortcut it would seem to be.
Well I'm not sure duplicating existing functionality is any good either, especially if it requires double the work from Boost users. At the point at which you uncovered the issues with boost::throw_exception as they related to Boost.Serialization, you had already "lost the boost::throw_exception battle" (based only on my reading of the list archives; perhaps you have a different recollection of events). As such, I think everyone would have been better served in the long run by working with Emil and others in addressing any regressions caused by the boost::throw_exception changes rather than forking your own Boost.Serialization-local throw_exception, doubling code and documentation effort, and forcing Boost users to define and keep track two user-specified functions upon disabling of exceptions. - Jeff [1] http://lists.boost.org/Archives/boost/2008/05/136919.php [2] http://lists.boost.org/Archives/boost/2008/08/141187.php [3] http://lists.boost.org/Archives/boost/2008/09/142162.php
By the way, my first thought when I encountered this problem is that C++11 ought to have specified the range-based for loop in such a way that the lifetime of temporaries in the range expression is extended for the duration of the loop. Does anyone share this opinion? Would there be any downsides to this? It is also interesting to note that boost::for_each together with a lambda - a from to which any range-based for loop can easily be converted - does not suffer from this problem. I think this corroborates the fact that the range-base for loop is suboptimally specified in the standard - after all the range- based for loop was meant to replace things like boost::for_each. Regards, Nate
[please ignore that last message, I posted it by accident to the wrong thread -Nate]
on Sat Jun 23 2012, Nathan Ridge <zeratul976-AT-hotmail.com> wrote:
By the way, my first thought when I encountered this problem is that C++11 ought to have specified the range-based for loop in such a way that the lifetime of temporaries in the range expression is extended for the duration of the loop.
Does anyone share this opinion?
+0. I don't know enough to have an opinion yet.
Would there be any downsides to this?
Well of course there would. Extending the lifetime of a non-trivial temporary beyond what's needed creates inefficiencies (memory pressure, register pressure, worse locality of reference...)
It is also interesting to note that boost::for_each together with a lambda - a from to which any range-based for loop can easily be converted - does not suffer from this problem. I think this corroborates the fact that the range-base for loop is suboptimally specified in the standard - after all the range- based for loop was meant to replace things like boost::for_each.
You have a point... though maybe what we really need is expression-statements ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Fri, Jun 22, 2012 at 9:37 PM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung@gmail.com> wrote:
I took some time to dig up and read some earlier threads on this. Major deja vu here, yo.
[...]
[1] http://lists.boost.org/Archives/boost/2008/05/136919.php [2] http://lists.boost.org/Archives/boost/2008/08/141187.php [3] http://lists.boost.org/Archives/boost/2008/09/142162.php
Okay, I was wrong in my inference/assumption/assertion that a broad consensus had been reached regarding the Boost.Exception update of boost::throw_exception. Another thread [4] I found suggests the issue was actually not fully discussed prior to the introduction of the boost::throw_exception updates, seemingly due largely to communication problems. Apologies, Robert, regarding this inaccuracy in the previous post; I'm just trying to research the historical context of this issue :/ [4] http://lists.boost.org/Archives/boost/2008/08/141486.php - Jeff
Another way of saying this is that the stuff directly in boost/ is sort of "core boost" and including this stuff doesn't include anything outside of this "core". Thus, when I write my code - then I know what I'm getting.
Well maybe the extended throw info that Boost.Exception provides *is* core boost?
I include something <boost/throw_exception> and I get a whole layer of stuff I didn't ask for. It makes my job and everyone else harder than it has to be.
Sure, but it's a pretty small lightweight layer of stuff. I'd be very surprised if it's presence/absence could be detected in build times.
And of course I'm still smarting from having the BOOST_NO_EXCEPTIONS definition change while I wasn't looking to from what has always been documented in a way that makes some sense to something that I still dont' get.
It hasn't changed - BOOST_NO_EXCEPTIONS means "no exception handling support is available in the compiler - so don't use exceptions anywhere". When defined the Boost.Exception code doesn't even get #included. And while I realize that *you* may not have been looking when this change happened, remember that Boost.Exception (including this change) was reviewed, and as I recall got a lot of discussion. BTW there is a macro - BOOST_EXCEPTION_DISABLE - which disables use of Boost.Exception and reverts back to original boost/throw_exception.hpp behavior. Of course that's a global change which can't be used on a library-by-library basis. But frankly, I would prefer it if all libraries were on the same page here and all used BOOST_THROW_EXCETION consistently. Just my 2c... John.
John Maddock wrote:
Well maybe the extended throw info that Boost.Exception provides *is* core boost?
lol - Surprize!, it apparently it already is. Problem is, I don't like surprises.
And while I realize that *you* may not have been looking when this change happened, remember that Boost.Exception (including this change) was reviewed, and as I recall got a lot of discussion.
Hmmm - so this was "extensively" reviewed but no one thought to inform users of the then current system. I only discovered it when I started to have some sort of problems with the serialization library. (I forget the details). So by definition it wasn't an unobstrusive change. The whole way this was done conflicts with the whole Boost cooperative development model in a fundamental way. The whole concept of development using other libraries has to be based on the premise that once established, a library functionality can't be changed. If one can't depend on that, then it would require me going back and reviewing all the changes in libraries that I use every time there's a change to verify that my origiginal understanding of what the library does is still the same. The new functionality should have been given a new name. There is/was no reason that authors of other code couldn't be sent a email promoting the benefits of the new alternative and trying to convince them that it's worth switchiing. This is the appropriate way to do this.
But frankly, I would prefer it if all libraries were on the same page here and all used BOOST_THROW_EXCETION consistently.
lol - you mean like the way it used to be? that's my point. Robert Ramey
Robert Ramey wrote:
Hmmm - so this was "extensively" reviewed but no one thought to inform users of the then current system. I only discovered it when I started to have some sort of problems with the serialization library. (I forget the details). So by definition it wasn't an unobstrusive change.
There were some growing pains, but everything got identified and fixed, did it not? And, realistically, there is no other way to iron out the details... at some point things have to be deployed and the objections addressed.
On 20 June 2012 12:13, Robert Ramey <ramey@rrsd.com> wrote:
The whole way this was done conflicts with the whole Boost cooperative development model in a fundamental way. The whole concept of development using other libraries has to be based on the premise that once established, a library functionality can't be changed.
While the bar on changing functionality and/or interfaces is high, it isn't (and never has been, as far as I know) absolute (and it isn't even as high as the C++ standard, nor should it be). As it says in the Boost FAQ < http://www.boost.org/users/faq.html>: "Many of the Boost libraries are actively maintained and improved, so backward compatibility with prior version isn't always possible." -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On Wed, Jun 20, 2012 at 10:13 AM, Robert Ramey <ramey@rrsd.com> wrote:
Hmmm - so this was "extensively" reviewed but no one thought to inform users of the then current system. I only discovered it when I started to have some sort of problems with the serialization library. (I forget the details). So by definition it wasn't an unobstrusive change.
No, the change wasn't entirely unobtrusive, a few wrinkles had to be ironed out. If you insist, I don't mind discussing the initial deployment of Boost Exception, but perhaps it'd be a better use of everyone's time to stick to the present. The whole way this was done conflicts with the whole Boost
cooperative development model in a fundamental way. The whole concept of development using other libraries has to be based on the premise that once established, a library functionality can't be changed.
Obviously libraries change. The important thing is to keep changes compatible with existing code. The "new" (several years old now) boost::throw_exception functionality is 100% compatible with the original.
But frankly, I would prefer it if all
libraries were on the same page here and all used BOOST_THROW_EXCETION consistently.
lol - you mean like the way it used to be? that's my point.
FYI, there was no BOOST_THROW_EXCEPTION before Boost Exception. What he means is that BOOST_THROW_EXCEPTION is preferable to boost::throw_exception, because it allows more complete messages by boost::diagnostic_information. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On 20/06/2012 00:51, Robert Ramey wrote:
I don't think that something I include from /boost - (other than a convenience header) should depend on something more specific like boost/exception, boost/serialization or whatever.
First, preventing interdependence between libraries is useless. Second, boost::throw_exception is not strictly part of Boost.Exception. It's a component from the very core of Boost that allows people to disable exceptions. Boost.Exception is a set of exception types with rich RTTI that allow transfers between threads and arbitrary attaching of data. They're different things, though they can be integrated to work together, depending on whether BOOST_EXCEPTION_DISABLE is set or not.
On Tue, Jun 19, 2012 at 10:11 AM, Robert Ramey <ramey@rrsd.com> wrote:
b) boost::throw_exception should be rolled back to it's orginal meaning.
Reason:The problem here is that using something from the main boost namespace creates and unexpected and hidden dependency on another library. This occcurs without the library user getting notified at all. Much care has been expended so that those things directly inside the boost namespace (excluding convenience headers) be things which DO NOT create dependencies on other libraries. The current definition of boost::throw_exception is the only exception to this.
It isn't an exception, there are many other libraries that use the main boost namespace. FYI boost::throw_exception is a documented part of Boost Exception: www.boost.org/doc/libs/release/libs/exception/doc/throw_exception.html. In terms of dependencies, boost/throw_exception.hpp is extremely light, orders of magnitude lighter than boost/config.hpp, which is the low water mark for Boost dependencies. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
I am working on a C++ based project which forbids the usage of C++ exceptions but it is still preferable to use Boost libraries at least the ones which do not make use of C++ exceptions at all. I am especially interested in using Boost.Units and Boost.Math.
Which of Boost libraries do NOT make use of C++ exceptions (i did not find such a list but maybe its already available somewhere)?
I can't comment on other libraries, but you can turn off use of exceptions to report errors in Boost.Math via the policies mechanism: http://www.boost.org/doc/libs/1_49_0/libs/math/doc/sf_and_dist/html/math_too... In addition if you're only interested in the TR1 special functions, then the C compatible libraries provided by Boost.Math (see boost/math/tr1.hpp and http://www.boost.org/doc/libs/1_49_0/libs/math/doc/sf_and_dist/html/math_too...) will set ::errno rather than throw an exception. HTH, John.
I am working on a C++ based project which forbids the usage of C++ exceptions but it is still preferable to use Boost libraries at least the ones which do not make use of C++ exceptions at all. I am especially interested in using Boost.Units and Boost.Math.
Which of Boost libraries do NOT make use of C++ exceptions (i did not find such a list but maybe its already available somewhere)?
If you are using GCC in the project, you can also set some of the relevant compiler options to *purposely* eliminate proper exception handling: -fno-exceptions -fno-enforce-eh-specs This may result in smaller code and improved performance at the expense of losing run time exception handling. Although this slightly breaks standards adherence, these options are useful for projects with dire performance and size constraints. Best regards, Chris.
participants (18)
-
Christopher Kormanyos -
Daniel James -
Dave Abrahams -
Dirk Ulrich -
Emil Dotchevski -
Emil Dotchevski -
Fabio Fracassi -
Jeffrey Lee Hellrung, Jr. -
John Maddock -
Mathias Gaunard -
Nathan Ridge -
Nevin Liber -
Peter Dimov -
Robert Ramey -
Roger Martin -
Ulrich, Dirk
-
Vicente Botet -
Vicente J. Botet Escriba