[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-glpk] C++ throw instead of C exit

From: Robbie Morrison
Subject: [Help-glpk] C++ throw instead of C exit
Date: Mon, 18 Jan 2010 21:24:28 +0100
User-agent: Thunderbird (X11/20080306)

Hello API users and Andrew

Andrew Makhorin recently wrote:

  "An incorrect call to glpk api routines causes an
   error message to be sent to the terminal."

And a call to 'exit' from <stdlib.h> may also result
.. at which point your app is toast.  I strongly
considered replacing this call with a C++ 'throw' which
I could then catch in 'main' and finish up somewhat
more gracefully and with my own return value.  But I
haven't as yet because this would mean patching each
new GLPK release.  Exceptions could also be caught by
the caller, although I wasn't planning on using that

A better solution might be to have these two statements
-- 'exit' and 'throw' -- embedded in the official GLPK
codebase and controlled by a user set preprocessor
macro (perhaps 'CPLUSPLUS_THROW'), determined at
configure-time (perhaps --c++-throw), or selected on
whether '__cplusplus' or similar is defined (or some
combination of these).

The exception object should contain the stated reason.
It could be 'std::runtime_error'.  Or it could be a
custom GLPK exception class (unrelated to 'std::exception')

I realize this would introduce C++ calls and perhaps
(but not necessarily) header includes into the GLPK
codebase, but only if actively switched-in.

This general topic is dealt with under "Error handling"
on p18 of the 4.42 GLPK manual.  I don't believe this
idea contradicts the sentiments expressed in the manual?

Does this suggestion have any merit?  I am happy to
undertake the C++ coding and testing .. but not any of
the autoconfig stuff, which I know nothing about.  On
the other hand, this idea might be really daft!

Alternatively, some kind of user-defined C-style
callback function pointer might also work.  In which
case I can keep the C++ throws within my own code and
GLPK stays true?

Does anyone know how other solvers (CPLEX perhaps)
behave under malformed API calls?

Any thoughts on the proposal?

(There will be some delay before I can respond)

ps: Andrew: The new GLPK problem format looks clean and
workable --- I will add the APIs to my code in due
course and let you know if I encounter problems.
Congratulations also on the recent interest from the US
Department of Energy.

best wishes
Robbie Morrison
PhD student -- policy-oriented energy system simulation
Technical University of Berlin (TU-Berlin), Germany
University email (redirected) : address@hidden
Webmail (preferred)           : address@hidden
[from IMAP client]

reply via email to

[Prev in Thread] Current Thread [Next in Thread]