[Coin-discuss] OsiClp/Clp initialSolve

[Jan-Willem.Goossens at nc3a.nato.int]

I think this about mentions all the details:

...\Coin\CoinFileIO.cpp(592) : error C2556: 'char **__p__environ(void) '
: overloaded function differs only by return type from 'char
***__p__environ(void)  '
        ...\Microsoft Visual Studio .NET 2003\Vc7\include\stdlib.h(214)
: see declaration of '__p__environ'
...\Coin\CoinFileIO.cpp(592) : error C2040: '__p__environ' : 'char
**(void) ' differs in levels of indirection from 'char ***(void)  '
...\Coin\CoinFileIO.cpp(592) : error C2072: '__p__environ' :
initialization of a function
...\COIN\Coin\CoinFileIO.cpp(592) : fatal error C1903: unable to recover
from previous error(s); stopping compilation

More precisely, it's the standard MS "cl" compiler version 13.10.3077,
that comes with Visual Studio .NET 2003.
As you see, line 214 in stdlib.h defines __p__environ, not environ, but
(apparently) eventually 'environ' resolves to this (and it's not
something I'm defining..).

Anyway, home_dir works fine for me.





-----Original Message-----
From: coin-discuss-bounces at list.coin-or.org
[mailto:coin-discuss-bounces at list.coin-or.org] On Behalf Of Matthew
Saltzman
Sent: 10 October 2005 14:07
To: Discussions about open source software for Operations Research
Subject: RE: [Coin-discuss] OsiClp/Clp initialSolve


On Mon, 10 Oct 2005 Jan-Willem.Goossens at nc3a.nato.int wrote:

> Hi again,
>
> Thanks for the quick reply and code change!
>
>
> After updating, I saw this in Coin/CoinFileIO.cpp (Rev 1.3) :
>
> char * environ = getenv("HOME");			(line 592)
>
> This causes a problem (at least on my windows machine), because
stdlib.h
> contains a macro def called   environ

Which compiler, which version?

> Just changing the name environ into something else solves this.

Just as a point of information, ANSI/ISO stdlib.h should not define this

symbol.  But it would probably be better to use something else, as it 
was commonly provided in older *NIX and Windows compilers.

I've changed the name of the variable to home_dir.

>
>
> Jan-Willem
>
>
>
> -----Original Message-----
> From: coin-discuss-bounces at list.coin-or.org
> [mailto:coin-discuss-bounces at list.coin-or.org] On Behalf Of John J 
> Forrest
> Sent: 07 October 2005 22:46
> To: Discussions about open source software for Operations Research
> Subject: Re: [Coin-discuss] OsiClp/Clp initialSolve
>
>
>
> Your wish is my command.
>
> If the user has not set any hints (apart from reducing printout) and 
> if there is an all slack basis OsiClp will do a 
> ClpSimplex::initialSolve with some of the more exotic possibilities 
> switched off.
>
>
> <Jan-Willem.Goossens at nc3a.nato.int>
> Sent by: coin-discuss-bounces at list.coin-or.org
> 10/07/2005 09:20 AM Please respond to
> Discussions about open source software for Operations Research
>
> To<coin-discuss at list.coin-or.org>
> cc
> Subject[Coin-discuss] OsiClp/Clp initialSolve
>
>
>
>
>
>
>
> Hi all,
>
> I noticed that solving some LPs through OsiClp takes longer than 
> solving them with Clp (simple initialSolve), without any Hints set. 
> From what I can see, there is quite some code in the OsiClp 
> initialSolve, e.g. to see whether or not to use primal/dual simplex 
> etc. Wouldn't it be a good idea for OsiClp initialSolve to rely more 
> on Clp's logic here, at least in no-hints/automatic mode? Or am I 
> seeing this the wrong way?..
>
> Thanks,
>
> Jan-Willem Goossens
>
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at list.coin-or.org 
> http://list.coin-or.org/mailman/listinfo/coin-discuss
>
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at list.coin-or.org 
> http://list.coin-or.org/mailman/listinfo/coin-discuss
>

-- 
 		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
_______________________________________________
Coin-discuss mailing list
Coin-discuss at list.coin-or.org
http://list.coin-or.org/mailman/listinfo/coin-discuss