Hi! On 2007-05-12 22:33 CEST, Ron Garret wrote:
On May 12, 2007, at 1:11 PM, Richard B. Kreckel wrote:
Well, it depends on your point of view. I was referring to the entire read_number_bad_syntax function as a form of "user- specifiable callback". :-)
Except that it isn't user-specifiable and it isn't a callback. Other than that there's no problem.
Ron, what happened to your sense of humor? Overriding the function is certainly user-specifiable and the entire thing is kind of a "callback" if you are willing to accept that the function to call is specified at link time rather than at run time. That's why I was putting double quotes and a smile there. But never mind. :-/ On 2007-05-13 22:01 CEST Ron Garret wrote:
OK, here's a minimalist version. It only changes cl_abort.cc:
namespace cln {
void (*cl_abort_hook)(int) = exit;
void cl_abort (void) { cl_abort_hook(1); }
} // namespace cln
I have tested this on OS X with the following client code:
namespace cln { extern void (*cl_abort_hook)(int); void cl_reader_error(int status) { throw status; } }
and it works. I have not tested in on Linux, but I have no reason to believe it would behave any differently there.
An improved version would replace cl_read_number_XXX with functions that assembled the error message as a string instead of outputting it to cerr, and calling cl_abort_hook with that string, with a default cl_abort_hook that printed the string to cerr and then called exit, but I thought I'd start with the smaller version just to test the waters.
This may solve your problem but, in practice, how useful is it? I am imagining some Linux distribution where CLN is compiled with -fno-exceptions and a naive user is specifiying cl_reader_error to be called instead of exit. I haven't checked but I'm sure this will incur undefined behavior: a crash, a memory leak, you name it. So, to be safe, the library will have to be compiled with exceptions enabled. But what is the advantage of providing such a callback then? I don't think anyone will do anything but throw exceptions from it! But then it will be better to throw well-specified exceptions directly. The real question that I would like to see answered is how much overhead is incurred by exceptions. If it is negligible, I propose to define a couple of exception classes and throw these instead of calling cl_abort. The exception classes could be subtypes of std::runtime_error, because catching these is frequently used as a last resort. Let's have a look at the overhead before deciding on an interface.
This patch is small enough that it probably doesn't matter, but for future reference, what is the preferred format for submitting patches? diff? diff -e? diff -n? Can I send a darcs patch?
Any diff with context such that I can apply it using patch is fine. Best -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>