I used to have to live under the same silly coding standard. Eventually I was able to convince the rest of the team, except the one guy who had the power to make such decisions, that we were being really silly. We *were* linking to the standard library so any supposed benefit of not using exceptions was lost (and I don't buy the supposed benefits either). Eventually that guy quit; best thing to ever happen to us actually.

But then, he had a big issue with third party libs too so using boost was even out of the question at the time.

My advice would be to try your best to convince your team leader that compiling with that switch is possibly not the best idea in the world. If you can't convince them, maybe you can outlast them and eventually make positive changes for your employer.

There seem to be plenty of rather stupid people, which have a problem with exception handling.

Emil Dotchevski wrote:

On Tue, Apr 14, 2009 at 9:40 AM, Noah Roberts wrote:

...

...

Is there a way to disable the exception handling in the Boost libraries? Our project requires that we disable exceptions by using the -no-exceptions parameter when building (via gcc). Is this also a valid parameter to use when building the Boost libraries? I used to have to live under the same silly coding standard. Eventually I was able to convince the rest of the team, except the one guy who had the

Dykstra, Martin wrote: power to make such decisions, that we were being really silly. We *were* linking to the standard library so any supposed benefit of not using exceptions was lost (and I don't buy the supposed benefits either). Eventually that guy quit; best thing to ever happen to us actually.

The problem is that "the guy in charge" may not quit (or the platform you're targeting may not support exceptions) and in that case it is reasonable to make an effort to use STL or Boost.

It's pretty darn rare that there's actually a legitimate reason why exceptions won't work for you. Of course in that situation it might be worthwhile to try boost and stl. Then again, when you have a legitimate reason against exceptions you just might have a legitimate reason against templates too. At that point you might consider if C++ is even the best option and you're probably doing a lot of things by hand.

The other problem is that guys in charge who don't like exceptions usually don't like STL or Boost either. :)

Yes, I found that true. I was constantly having to defend myself for using std::string instead of a statically sized char[]! I never considered myself good enough to do that correctly; problem is that he wasn't either but thought he was. Like I said, best thing that ever happened to us was his quitting. This guy even told me that the document/view architecture was considered bad by most experts now when I tried to get GUI/data model separation in the design. That's the day I realized there'd be no reasoning with the guy :P It was certainly hard to work in such a situation. But eventually, if you can earn the respect of the rest of the team and the boss's boss you can force change for the better. That's actually part of what happened to this guy ;) Show that you can accomplish more, with less expense, and more stability with every little inroad you can get. I started with forcing the std::string issue and slowly moved forward, pushing the boundary every step of the way. Not that I'd recommend that with every superior you don't agree with. Sometimes (usually) they have real reasons for what they're doing.

Yes, I found that true. I was constantly having to defend myself for using std::string instead of a statically sized char[]! I never considered myself good enough to do that correctly; problem is that he wasn't either but thought he was.

No human being is good enough to deal with strings and arrays in C. Just have a look at the buffer-overflow mess we are currently in.

Emil Dotchevski:

On Tue, Apr 14, 2009 at 6:34 AM, Dykstra, Martin wrote:

...

Is there a way to disable the exception handling in the Boost libraries? Our project requires that we disable exceptions by using the -no-exceptions parameter when building (via gcc). Is this also a valid parameter to use when building the Boost libraries?

You can #define BOOST_NO_EXCEPTIONS.

There should be no need to #define BOOST_NO_EXCEPTIONS by hand. boost/config/compiler/gcc.hpp defines it automatically when -fno-exceptions is used: #ifndef __EXCEPTIONS # define BOOST_NO_EXCEPTIONS #endif