Re: [Help-glpk] GLPK API change

[Andrew Makhorin]

> Following on from the discussion about the new GLPK API.
> And I realize that some of the current issues are to be
> addressed in upcoming GLPK 4.16.

> I assume one can not (naively) add a preprocessor hash-define
> as follows:

> ---c++-code-begin---

> extern "C" {             // linkage advice for C++ compiler
> #  include <glpk.h>      // GLPK API header for version 4.15 or better
> }

In 4.16 this is included in glpk.h and therefore not longer needed.

> #define lpx_ _glp_lpx_   // hack for code containing old GLPK calls

> int main()
> {
>     LPX* my_lpx;
>     my_lpx = lpx_create_prob();  // pre-4.15 GLPK call
> }

> ---c++-code-end---

> Is there some other hash-define we can use?

In 4.16 there are two preprocessing variables defined like follows:

/* library version numbers: */
#define GLP_MAJOR_VERSION  4
#define GLP_MINOR_VERSION  16

which can be used to distinguish between newer and older versions of
the package.

Note that all old api routines, i.e. whose names begin with 'lpx_',
are kept for backward compatibility.

> In addition, is there any reason not to introduce a
> GLPK namespace in order to differentiate the new APIs
> from the old, for instance:

>     glpk::LPX* my_lpx;   // note the hypothetical namespace
>     my_lpx = glpk::lpx_create_prob();

> Does that not work for C programming?  Because it would
> be quite sensible for C++ coding as far as I can tell.

This construction does not conform to ISO C.

In 4.16 names of all new api rouitines begin with 'glp_' (that was
suggested by gnu guru's), while other (old api and non-api routines)
are prefixed with '_glp' by means of #define directives.

> regards to all and many thanks to Andrew Makhorin

Thank you for your interest in glpk :)