[Scip] Design choices

[Timo Berthold]

> How about a little programming challenge?

I put 50 Euro on Thorsten.

Seriously:
I do not see where the discussion is currently going. Definitely, a
230-member mailing list is not the appropriate surrounding for debates
on principles.
There were some very reasonable questions on how and why certain design
decisions were made and there were answers and motivations for each of them.
Then, the discussion drifted somewhat away into dogmatism.
If anyone thinks that there is only one path leading to the epiphany and
all others are wrong: fine with me, but I do not need this opinion
restated a dozen times.

Timo

Am 01.07.2013 13:47, schrieb Stefan Lörwald:
> 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/d78bfd79/attachment.html