compiling under MSdev

[Alpar Juttner]

The following change are necessary to compile lp_glpk under MSdev:

-lp_glpk.cc(67):    int ind[LEMON_glp(get_num_cols)(glp.lp)];
-lp_glpk.cc(68):    Value val[1+LEMON_glp(get_num_cols)(glp.lp)];

+lp_glpk.cc(67):   int* ind=new int[LEMON_glp(get_num_cols)(glp.lp)];
+lp_glpk.cc(68):   Value* val=new Value[1+LEMON_glp(get_num_cols)(glp.lp)];
+lp_glpk.cc(91):	delete [] ind; delete [] val;

I do not even understand how can it be compiled under gcc?

This ticket is a copy of report #62 of the old bug tracking system. It refers to svn trunk -r3426. The original report was posted by Janos Tapolcai.

[Alpar Juttner]

Replying to alpar:

Strange. As far as I know, this is a legal way of allocating an array in C++. If MSdev is unwilling to understand it, I'd rather use std::vector<> instead.

[Akos Ladanyi]

In C++98 the array size shall be an integral constant expression and its value shall be greater than zero. In C99 it can be any expression with integer type.

Note that even g++ rejects the above declarations when used with the -ansi and -pedantic flags.

Using std::vector is not an option here because the ind and val arrays are used as an argument of glp_get_mat_col() and glp_set_mat_col() functions which expect const int[] and const double[] arguments.

If you agree with the solution proposed by Janos, I will commit that.

[Alpar Juttner]

Replying to ladanyi:

Using std::vector is not an option here because the ind and val arrays are used as an argument of glp_get_mat_col() and glp_set_mat_col() functions which expect const int[] and const double[] arguments.

IMHO, we should still use std::vector as it provides automatic allocation and deallocation. You can pass them to glpk with &*ind.begin() or with &ind[0].

If you sill insist on allocating an array with new which I do not suggest, the you should probably use auto_ptr<>.

[Akos Ladanyi]

Replying to alpar:

IMHO, we should still use std::vector as it provides automatic allocation and deallocation. You can pass them to glpk with &*ind.begin() or with &ind[0].

This didn't come into my mind. Although this solution worries me a bit, because the standard doesn't state that the elements of a vector are stored in an array.

If you sill insist on allocating an array with new which I do not suggest, the you should probably use auto_ptr<>.

I understand your concerns about using this new/delete approach, but I don't see how auto_ptr could be used with an array.

Another solution would be to create a small class which holds a pointer to an array and which deallocates it in its destructor. This is similar how it is done in Gtkmm when interfacing with functions from GTK accepting array arguments (class Glib::ArrayHandle).

[Alpar Juttner]

Replying to ladanyi:

Although this solution worries me a bit, because the standard doesn't state that the elements of a vector are stored in an array.

I think we can safely assume that. Although the array based implementation it is not stated explicitly in the standard, many properties of std::vector implicitly implies this implementation. Some examples:

• The fact that it enables reallocation of the elements,
• The existence of capacity() function
• The insert() operator 'Causes reallocation if the new size is greater than the old capacity'. For me this sentence mean that there a reallocation will always take place in this case.

I don't see how auto_ptr could be used with an array.

It is not appropriate for this directly, you are right. It must have been a short-circuit in my brain.

[Akos Ladanyi]

Fixed in svn r3474.