[Bug-glpk] RE: C++ and glpk

[Kendall Demaree]

Kendall Demaree's responses to Andrew Makhorin comments below:

The extern "C" {...} linkage would work, except I was using some memory
checking stuff oriented to C++.  Also I thought it would be a good
experiment to see how solid the code appears.  If this is the first time
anyone had run this through a C++ compiler, I would say the code is
extremely clean.  Bravo!!!

I used the macro idea as you suggested, but it was a bit more
complicated than simply replacing the existing macro's since you need to
pass the type to the macro as well.

The macro changes are what I performed in most cases, but not all.  Some
of the "info" functions return void pointers that are then cast to
something else.  

Also in addition to umalloc and ucalloc, there is at least one usage of
the standard malloc.  It might be worth a look at the usage of malloc as
it might be better to replace this with your umalloc macro like in the
rest of the program.   See glplib2.c line 66.

Again, if you want me to send the tar'ed file of these changes to
someone, just let me know.  I will follow this glpk bug list for another
week, but will then unsubscribe unless I get a specific request to
follow up on something.

Its looking like I won't be able to use the GLPK software because of the
GPL terms don't allow integration with proprietary software.  I would
LOVE to see the LGPL, as I have no choice but to sell my power system
analysis libraries to system integrators locked into proprietary
systems.  I already have support for three different LP engines and was
hoping to add GLPK, but I just can't do it with the GLP terms.  In any
case I plan to use the GLPK stand alone to help verify other LP engines.

I liked the fact there is no global data in GLPK.  This makes it clean
to run multiple instances of the LP in a single program and to
"probably" safely run individual LP models in separate threads of
execution.

Thanks, for all your efforts.

Kendall Demaree



-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf
Of address@hidden
Sent: Tuesday, June 24, 2003 3:59 AM
To: address@hidden
Subject: Bug-glpk Digest, Vol 6, Issue 7

Send Bug-glpk mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.gnu.org/mailman/listinfo/bug-glpk
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bug-glpk digest..."


Today's Topics:

   1. Re: C++ and glpk


----------------------------------------------------------------------

Date: Tue, 24 Jun 2003 09:01:24 +0400
From: =?windows-1251?Q?=22?=Andrew
        Makhorin=?windows-1251?Q?=22=20?=<address@hidden>
To: =?windows-1251?Q?=22?=Kendall
        Demaree=?windows-1251?Q?=22=20?=<address@hidden>,
        address@hidden
Cc: address@hidden
Subject: [Bug-glpk] Re: C++ and glpk
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1251
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: list
Reply-To: =?windows-1251?Q?=22?=Andrew Makhorin=?windows-1251?Q?=22=20?=
        <address@hidden>
Message: 1

>I have converted version 4.0 to run under the MSVC6, MSVC7, and
>gcc3.2(cygwin) compilers as C++ files.
>
>This took a bit of editing, but nothing complicated.   The main issue
>was casting void pointers to something else.
>
>About 500 lines of code were needed to be modified, but these were
>trivial modifications that could easily be made to be compatible with
>ANSI C compilers also.

I think to replace umalloc and ucalloc by some macros which will return
pointers of appropriate type. This will allow the C compiler detecting
potential bugs like that you reported about and also compiling all glpk
modules as if they were written in C++ (glpk is written in a subset of
ANSI C and I believe there is nothing specific to C which would be
incompatible with C++). However I do not completely understand why the
standard linkage extern "C" { ... } is not fit for your needs.

>In the process I discovered a couple of items you may wish to correct
>regardless of C++ compatibility.
>
>Found something that looks fishy in glplpx6a.c file.
>The line 1056 allocates SPX.refsp as doubles but SPX header declares as
>int*
>in the glpspx.h file.
>
>glpmip1.c line 641:  Allocating array of sizeof(void*) and assigning to
>IESITEM**.
>This probably works on all platforms but is a bit sloppy.

Thank you for your information. In fact, these are potential bugs.


Andrew Makhorin



------------------------------

_______________________________________________
Bug-glpk mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/bug-glpk


End of Bug-glpk Digest, Vol 6, Issue 7
**************************************