[Scip] Design choices

[Stefan Lörwald]

Hi Marc,

2013/6/27 Marc Pfetsch <pfetsch at mathematik.tu-darmstadt.de>

>
>
> 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.
>

Well, consistency would be the keyword here. And it wouldn't harm if
SCIPsetObjlimit (and similar methods) are deprecated but still usable.

>
> > 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.
>

Why not make it a function then? With a good compiler it would be inlined
anyway, so no overhead whatsoever.


>
> 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.
>

FYI, it's not in C++, just use a std::pair or std::tuple.


>
> > 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.
>

Can you please clarify? I don't see why two functions would be necessary.


>
> > 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.
>

Ah, well i should have looked into the documentation for that one. That's
the reason I dislike boolean values in function calls by the way: The
purpose is not clear at all, better use enum.


>
> > 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.
>

What for?


>  > 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.
>

"C can be compiled faster" I seriously doubt that ;-) Have you tried? I
just did with scip.c and it turns out it needs 11s with gcc and exactly the
same time with g++. Execution time is identical if the SCIP source code is
compiled as c++, so no downside from that perspective.
C++ did not change in 2002, in fact there was no change between 1999 and
2011.


All the best,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.zib.de/mailman/private/scip/attachments/20130627/55c96b4b/attachment.html