RE:[Help-glpk] None

[Yuri]

Ivan,

Also being an adept of OO approach I would
like to note that in OO paradigm GLPK solver
would only be represented by one major object
and maybe 3-5 secondary minor ones.

In  this type of the situation programmer
doesn't gain much if such API gets OO look.
Just syntax of function calls will change,
first argument will get in front of function
name and that's it.

Like you mentioned glpkxx will destroy handles
but if you forget to invoke destructor in C++
it also won't do it. Same thing.

This is just a matter of habit. You probably
programming in C++ much and tend to make classes
even if they are instantiated only once.
I programmed a lot in both C and C++ and don't
feel disadvantged with the lack of objects there.

This is just a matter of taste, habit and background
in this type of API. If there were more objects
than it would be different story.

Regards,
Yuri.


------- Original message --------------------------
I am new to glpk and just find out how good it is.

I think that glpk is a great tool and as far as I know it's getting more

efficient and robust.

The only thing that I don't like about c-api is the way to build the model, 

mainly because it's not object oriented.

I had the same opinion about cplex before they came out with Concert Technology.

When I first saw ILOG concert technology I soon realized that it was a big

step ahead toword an easy way of developing optimization programs.

I thought that building an object oriented framework around glpk was a good

idea to let c++ programmers use this tool in an easy way.

For this reason I started the "glpkxx project" a GPL software that allow to

easily build linear optimization models in object oriented fashion and provide 
all the

feature of glpk.


The idea is to have an object GlpkProblem that interact with the solver.

The user add and removes variables and constraints as object, without 

the problem of storing indeces and so on; then when the

optimization is called, the problem is set up in glpk format and solved.

Then the user calls the query routine using its object, regardless of the

real index in the tableau.

Furthermore the use of expressions allows to write constraint in a more

"natural" way and both by row and by column, and to evaluate them after the

optimization. I also include function like Sum(varArray) or 

ScalarProduc(valueArray, varArray).


Memory is considered through the use of handles, to avoid excessive usage,

and freed by the solver itself when it is deleted.

Arrays of data and variables use STL array so that the user is not concerned

with the problem of allocating and deallocating memory.

So far I'm just in a beta phase and I only implemented some feature but

enough to

build and run the example below.


I would like to get your opinion about this project and any other hints.


Best regards

Ivan Luzzi