[Scip] Design choices

[Marc Pfetsch]

Hi Stefan!

> 1. Naming: why is it e.g. "SCIPsetObjlimit" with a lower case L?
> "objective" and "limit" are two words which should use camel case as
> your general naming convention implies.

You are right - the naming convention would suggest SCIPsetObjLimit(), 
which is probably better. However, we considered objlimit as a single 
word here (this also happens for several other names) and I do not think 
it makes sense to change it.

> 2. Why is "SCIPallocMemory" a macro while not written in upper case
> only? Without a surrounding "SCIP_CALL", this raises warnings, so this
> is not nice in functions that need to return something different than
> "SCIP_RETCODE", which is common in C++ code.

These are two questions. First, according to the coding rules, it should 
be SCIPALLOCMEMORY. Since memory functionality is used at many places, I 
suppose that it just looked ugly, so the lower case was used.

Second, SCIP_CALL is used for the SCIP internal error passing. If you do 
not like it, you do not have to use it (but at the loss of having a 
backtrace of SCIP functions). See also the SCIP introduction by 
Cornelius Schwarz (http://scip.zib.de/further.shtml), which provides a 
macro to use exceptions.

Moreover, returning more than one argument is always complicated in 
C/C++. The price you have to pay for the SCIP error passing is that you 
need to return values via pointers.

> 3. With "SCIPgetSol(...)", why can one refer to the solution of a LP via
> "NULL"? My intuition says that with "NULL", there is no partial
> structure it is referring to, so I would expect to get the current
> _global_ solution.

Well, you would need two functions otherwise, so it was just easier to 
use NULL. It also comes in handy at several places in the code.

But in principle, two different things get mixed up here: LP solutions 
(relaxations) and primal solutions.

> 4. Concerning the C++ interface, it is mildly disturbing to have dynamic
> memory management in function calls, i.e. you have to construct objects
> with "new Object", without ever calling delete on them. This is
> considered bad practice in C++, which prefers the "RAII" idiom. "Whoever
> constructs an object,destroys it" should be obeyed. Why was this
> violated in SCIP? See your TSP example for reference. While it does not
> leak resources, it is not visible/obvious to the user since there is no
> "delete".

I am not sure whether I understand you correctly. If you want to delete 
the objects yourself, you can do so: See for example 
SCIPincludeObjConshdlr() - set deleteobject to TRUE.

> 5. Why does "SCIPinfinity" take a "SCIP*" as argument? Shouldn't this be
> a compile time constant independent of any object?

The infinity value can in principle be changed, so it is not a compile 
time value.

> 6. What led to the decision developing in C?

First, the predecessor SIP of SCIP was written in C. Second, the C++ 
standard rapidly changed when the SCIP project started (2002), while C 
is quite stable (there is hardly any problem with SCIP and compilers). 
Third, C can be compiled faster.

But you are right - there are several parts in SCIP that somewhat 
simulate C++ class behavior.

> 7. Your code is not compliant with the C99 standard, since you use
> double underscores as prefix to identifiers (e.g. in your header include
> guards).

O.k. (There are some other parts that do not strictly conform to the C99 
standard.)

> 8. Why don't you split your source files into smaller ones? Incremental
> compilation time will drastically improve (especially for minor
> modifications). As a personal preference I try to keep the number of
> lines per file below 500, extreme cases have up to a thousand. Several
> thousand lines of code neither seems practical for compilation nor does
> it simplify coding.

Well, it is easier for us. The whole SCIP code is quite modular. There 
is hardly any reason to split the files further. The only exception 
might be scip.c, but it is quite comfortable to have most functions that 
can be called in one file. Sill, compiling scip.c is still sufficiently 
fast - so there is simply no problem here.

Best

Marc