[Scip] Design choices

[Stefan Lörwald]

Dear SCIP developers,

I've been using SCIP for a while now, mainly using it as branch-and-cut
framework. There are a couple of oddities that have puzzled me and/or it
took me a long time to remember how to use.

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.

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.

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.

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".
5. Why does "SCIPinfinity" take a "SCIP*" as argument? Shouldn't this be a
compile time constant independent of any object?

Please do not take any of this as offensive, even if you are the
responsible developer. It is meant as construct criticism and curiosity
about design decision which I would have done otherwise. Personally, I
would have implemented it in C++ right away, so here's my final question:

6. What led to the decision developing in C?

And just to let you know (I wrote this in an earlier email which apparently
wasn't submitted to the mailing list):

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).
Although it is unlikely to cause any trouble, they are reserved for the
implementation of the C compiler. See section 7.1.3 "Reserved identifiers"
from the 1999 C Standard or have a look at
http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier(which
ask about C++, but this applies to C as well, as mentioned in the
best answer). I'd recommend either removing those double underscores or
just use "#pragma once". it is widely supported and avoids name collision
of include guards, but provides the same functionality.

Oh and just another small one coming to mind after browsing the source
again:

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.

Yours,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.zib.de/mailman/private/scip/attachments/20130627/d0585d08/attachment.html