[Scip] Design choices

Domenico Salvagnin dominiqs at gmail.com
Mon Jul 1 21:07:01 MEST 2013


Dear all,

I think that Stefan remarks can be split into two categories:

1) C vs C++

I think that what Stefan didn't like was the feeling that the SCIP framework ended up implementing by hand a lot of things that would have been for free in C++. As a C++ programmer myself, I cannot but share his same feelings.

As far as the language itself is concerned, there is no doubt that C++ is much more complicated than C (to learn and to master), but the reason is simply that it provides much higher abstractions and concepts than C does: generic programming with templates, runtime polymorphisms with virtual functions, error handling with exceptions and resource handling via RAII (just to name a few) are of course higher level constructs than simple structs and functions.

However, those abstraction are very helpful (needed?) to manage projects beyond a given level of complexity: if they are not provided by the language, they  are usually implemented by hand (this is what SCIP is currently doing), and the end result is no piece of cake either. Complexity does not disappear, we are just moving it around (from the language to the specific hand-made implementation).

Personally, I prefer the C++ way: although more difficult to master, the language approach is more generic (once you learn the language you can use it in many different projects), more safe (checks are done by the complier, and not based on programmers self-discipline) and efficient (compilers are better at inlining than we are…).

Note that I am not objecting to the choice of C for implementing SCIP back then: the status of the C++ language and compilers 10 years ago was far from perfect and the language itself was not taught the proper way (blame Java for that). In addition, some techniques/constructs were not well known/understood even among C++ programmers. Finally, C still has an advantage concerning embedding: it is still easier to embed a C library into another language than a C++ one, because of name mangling and the need for a C++ runtime (this may be a more important point for a commercial solver, though).

For the above reasons, I think that if SCIP were to be restarted from scratch NOW, then C++ would be a much better choice. However the point is moot, since I don't see a rewriting of SCIP anytime soon, and for good reasons :-)

2) Design choices (more of less language independent).

This is an area where improvement can still be done. SCIP is very well designed, but of course it is not perfect, and some small inconsistencies can be fixed and small design flaws improved upon. However, I agree with Timo that in some cases there is really no perfect solution, and a design which is good in one scenario is a pain in another.



To sum up,  there is not a lot that we can do on point 1), but suggestions, comments and code are very welcome on point 2).

Just my 2 cents,

Happy SCIPping!

Domenico

On Jul 1, 2013, at 1:47 PM, Stefan Lörwald wrote:

> Hi Thorsten,
> 
>  > With 20 years of experience I can tell that this is definitely not true.
>  > Apart from this you can get pretty much the same amount of data
>  > encapsulation and
>  > abstraction in C, though the effort might be somewhat higher.
>  > And even to precisely tell what a given piece of C++ code does is so
>  > much more
>  > complicated than simple C. 
> 
> I'm sorry to hear that, but chances are that you've been using C++ wrong.
> 
> >> This also enables further
>  >> optimizations, e.g. by having some methods declared const which means that
>  >> the method does not modify the object (bitwise const, pre-C++11) or is
>  >> const in the sense of thread-safety (inherently synchronized, >=C++11).
>  >
>  > maybe in C++ 11. Let us dream on.
> 
> C++11 is reality. Why dream?
> 
>  > Fortran is still optimizing better :-D (for bad reasons, but anyway) 
> 
> Fortran hasn't been part of this discussion, but well yes, maybe it does a lot more optimization, I don't know. So what?
> 
> >> Templates reduce code duplication (with free maintainability bonus!
> > 
> > Have you every looked at polymake? Look there and tell me about
> > the maintainability bonus :-) 
> 
> I didn't say you'd automagically (sic!) get good code with C++. You don't even need to include a different project into this discussion. The TSP example in the SCIP suite is enough. Templates give you the possibility of maintainable and fast code, but as with everything, you can abuse them.
> 
> Just for fun though: How about a little programming challenge? For two arbitrary built-in type such as integers or floats, check if a value of the first type is representable as the second type.
> I'd like to see you try getting a efficient implementation with C. Problem: C lacks templates. C++ can do most of these checks with at most two assembly instructions (floats are a bit more tricky).
> 
> This is how a C++ solution could look like: http://ideone.com/lBxnAW
> 
> Note that there is no truth table or similar things. Most of the type checks and comparisons are done at compile time. This is the beauty of C++11 and templates: Highly flexible code, short code, readable code, most efficient code.
> 
> I'd be extremely intrigued to see your implementation in C.
> 
> > And finally, just to note that C and C++ are not 100% compatible anymore.
> > Just to give an example:
> > double* b = calloc(100, sizeof(*b)); is not valid C++. 
> 
> Why would you ever do such a horrendously looking thing in C++? Yes, C is not a proper subset of C++, that's a fact, but I never stated the opposite.
> 
> Yours,
> Stefan
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.zib.de/mailman/private/scip/attachments/20130701/2d32a294/attachment.html


More information about the Scip mailing list