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