Le 16/09/10 08:06, Brian a écrit :
jacob navia wrote:
[snip]
You entire post and every "point" in it was a strawman.
Well, thanks for your very substantive contribution. It offers me the
possibility of refining certain points of my post.
The first point that I underscored was (in a few words) that inheritance
increases the dependency between the framework or software you inherit
from, and the rest of the code.
Obviously your software runs in *some* kind of context, and even if you
do not formally inherit from the environment, you are bound to it. My
proposition was that APIs and Interfaces are a much cleaner separation
boundary that allows for code reuse without commiting completely
everything to everything else.
A second point concerns the problem of readability of C++ code, that in
my opinion is not really where that language shines. I can't offer a
formal proof of that, but there are some facts that should prove my
assertion
(A) If you go to the discussion group comp.lang.c++ you will find a lot
of questions from newcomers and not newcomers asking more or less:
"I do not understand why this code doesn't compile".
In many questions the answers are: "It compiles in Comeau and gcc", or,
"I tried it in g++ under Sun Os", etc. An answer like:
"Your code can't compile because the error is at line 5: you forgot that
the default value ..." (etc, some explanation as to WHY the code doesn't
compile). The "explanations" offered (when at all) are just that compler
xyz compiles (or not) the stuff.
In the C discussion group this kind of "reasoning" is seldom used
because C is much more transparent and can be read by a seasoned
programmer WITHOUT having to go to the compiler to get a definitive
answer.
(B)
The underlying problem is evident when you read the SPECIFICATIONS of
the language. For instance, when I tried to understand the sequence of
rules being applied to operator overloading and the selection of the
function to call, the C++ standard went for several PAGES of completely
abstruse specifications that needed a "topological sort" of the classes
involved to figure out which function will be called!
But this means that a normal development programmer can't know in a
medium size project what function will be actually called and can at
best make an educated GUESS of what will be the result of the
topological sort of the classes that are considered and their possibly
overloaded methods. In most cases this works, and the cases where that
can NEVER work aren't discovered by the developer but by the maintenance
programmer that must figure out WHY the program took a completely
unexpected path and crashed...
A third problem I proposed to consideration is the fact that templates
have no specifications for their arguments, what makes unit testing MUCH
more difficult since the set of their arguments is completely UNBOUNDED.
ANY type can be thrown to a template and it is very difficult to test
within the template if the given type is acceptable.
Confronted to the typical mess of C++ code it is completely out of the
question for the maintenance programmer to READ the code to figure out
what is doing. The only way (and the accepted way of learning how the
program works) is to use the debugger and an IDE that understands C++.
In many companies where I worked the windows version was maintened not
because the program run under windows but because the MSVC IDE have that
MAGIC feature called "go to definition". Grep will not help you because
to know where an indetifier is defined you must know which of the
several definitions is the one used.
This message was a proposal to reflect about that part of language
design that is obviously not as "sexy" as "look how easily you can write
this or that" but about "look how easily you can READ this code and
understand what it is doing".
I hope that now you can better understand what I am trying to do.
jacob
