[Scip] Design choices

Thorsten Koch koch at zib.de
Mon Jul 1 17:23:46 MEST 2013


Hi Stefan,

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.
> 
You probably have no idea what a good joke this is.

I have been following C++ basically since cfront.
And every few years when the promises have not been fulfilled,
some new features where added and it was said that it has to be done
all different and it was used the wrong way.
While I completely agree that most C++ is used wrong the question remains
whether there is a right way at all.

But the discussion is fruitless anyway, since I will not (and need not)
to convince you, as you will not be able to convince me.
This is the nice thing about programming languages:
There are many of them. You do it your way and we do it our way.

Viele Grüße
Thorsten


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

-- 
The important thing is not to stop questioning.
Curiosity has its own reason for existing.          -- Albert Einstein
______________________________________________________________________
Dr. Thorsten Koch / Konrad-Zuse-Zentrum für Informationstechnik Berlin
www.zib.de/koch  /          Takustraße 7, 14195 Berlin-Dahlem, Germany
koch at zib.de     /                     Phone +49-30-84185-213, Fax -269
_______________/  DFG Research Center "Matheon"  http://www.matheon.de

Kooperativer Bibliotheksverbund Berlin Brandenburg  http://www.kobv.de
digiS: Servicestelle Digitalisierung Berlin
http://www.servicestelle-digitalisierung.de
______________________________________________________________________


More information about the Scip mailing list