Vladimir Prus wrote:

Hello, I've tried to dig into program options runtime failures on borland. Consider this code, from cmdline.cpp (cmdline::finish_option):

const option_description* xd = m_desc->find_nothrow(opt.string_key, (m_style & allow_guessing));

if (!xd) { if (m_allow_unregistered) { opt.unregistered = true; return; } else { throw_exception(unknown_option(opt.string_key)); } } const option_description& d = *xd;

Running in the debugger, I see that 'xd' is NULL, m_allow_unregistered is false, and the execution arrives on "throw_exception". After that, *nothing happens*, and program goes on dereferencing null pointer and using the obtained reference.

Evil.

If I replace throw_exception with "throw", the tests fails later, and if I replace all throw_exception's with throw in the module, test passes.

So I have two questions:

1. Did anybody else had this problem with throw_exception 2. If throw_exception function does not work with borland, maybe it should become macro on that compiler?

throw_exception can't be a macro because it can be called with boost:: qualification. In fact, try using boost::throw_exception in the code above; I remember hitting a similar code generation bug in Boost.Bind, take a look at the beginning of boost/bind.hpp.