Software maintenance

[Nick Keighley]

I've no idea what you are on about. If you have a specific criticism
of Jacob's post why not state it explicitly. Or are you just
trolling? [...]
I started to add some thoughts, but after a few responses I realized
he had an agenda

he probably does. So which bits of his post are wrong or refutable?

Like I said, the whole thing is so lame that it is not worth responding
to other than as a whole, which I already did.

failure to repond in any meaningful fashion noted.

<snip unresponsive post>

 

[Seebs]

The point he (Jacob) either doesn't get or refuses to concede is that
language is already there. If you only want to use the C subset of C++
and a few extras, then just use them. No one or no compiler is forcing
the bits you don't want on you. That is part of the philosophy of C++:
you don't pay for what yo don't use.

That was an original design goal, but it's no longer consistently true;
there are some cases where you pay extra for stuff.

However, there's a much more serious problem with trying to use C++ as a
"better C". If you have a team, different people on that team will think
different parts of C++ are obviously-better and have low cost, and even a
fairly good set of code reviewers will occasionally miss something.

-s

 

[Malcolm McLean]

However, there's a much more serious problem with trying to use C++ as a
"better C".  If you have a team, different people on that team will think
different parts of C++ are obviously-better and have low cost, and even a
fairly good set of code reviewers will occasionally miss something.

The only consenus is on // comments. Everything else some swear by,
others abominate.

 

[Keith Thompson]

that reminds me of an example on "C Unleashed", something like:

func1(path); // in C:\DIR\
func2(path);

so the preprocessor will do:

1) line splicing:

func1(path); // in C:\DIRfunc2(path);

2) comment removal (...and the result is):

func1(path);

Even worse, you can "avoid" the problem by adding a space after the
trailing \ character. Line splicing is done only when a backslash
is *immediately* followed by new-line character.

So two different versions of the same source file, which *appear*
completely identical when viewed on a printout or on your screen
(unless you've configured your editor to display trailing blanks)
behave completely differently.

I would support changing the standard so that whitespace after
a trailing backslash does not inhibit line splicing. Though I
suppose it might break some existing code (that was already
extremely fragile).

 

[jacob navia]

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

 

[Shao Miller]

Indeed...I simply use the old-style comments also for one-line comments,
and I would suggest to everyone to do the same...

The original style is certainly enjoyable. I don't use '//'. The only
"problem" (hardly counts as a problem) that I perceive is in lining-up
the '*/' in a series of comments, for the human eye. Using spaces is
tedious. Using tabs might just happen to go past the last column. You
need enough room for the '*/'. Oh well.

 

[Ian Collins]

That was an original design goal, but it's no longer consistently true;
there are some cases where you pay extra for stuff.

However, there's a much more serious problem with trying to use C++ as a
"better C". If you have a team, different people on that team will think
different parts of C++ are obviously-better and have low cost, and even a
fairly good set of code reviewers will occasionally miss something.

The teams I have trained have coding standards and follow them. Those
standards listed the features to be used.

 

[Seebs]

The teams I have trained have coding standards and follow them. Those
standards listed the features to be used.

I have seen a whole lot of documented coding standards which are followed
about 90% of the time, but stuff slips through occasionally.

Of course, I'm in no position to talk, since I'm on a team that consistently
and specifically DOES NOT use the nominal company coding standard, largely
because we work mostly on open source packages, and have to follow their
standards.

-s

 

[Ian Collins]

I have seen a whole lot of documented coding standards which are followed
about 90% of the time, but stuff slips through occasionally.

It may, but then the developer's pair slaps him round the head with a
rolled up copy of the standard. Or the next pair to change the code
take the offending construct out. I prefer short (often a page or two)
wiki based project coding standards that can evolve as the team matures.

Of course, I'm in no position to talk, since I'm on a team that consistently
and specifically DOES NOT use the nominal company coding standard, largely
because we work mostly on open source packages, and have to follow their
standards.

Oh I've been there and done that! You have to use the ISO When In Rome
standard.

 

[Seebs]

It may, but then the developer's pair slaps him round the head with a
rolled up copy of the standard. Or the next pair to change the code
take the offending construct out. I prefer short (often a page or two)
wiki based project coding standards that can evolve as the team matures.

Interesting, I haven't done anything with pair programming, so I don't have
solid opinions of it yet. It sounds really crazy to me, but then, I can't
function if I have to interact with other people for more than an hour or
two a day. On the other hand, I love code review, and any time I'm working
on something on my own time, that's the thing I miss most.

I hear a lot of people talking derisively about code review, from which
I infer a lot of places must not take it seriously. Luckily, $dayjob is
serious about it. There is no pressure on people to pass review on the
first go -- if there were, that would start creating indirect pressure to
not complain about stuff in review. So instead we focus on trying to
ensure that things don't pass review until they're really carefully looked
over, and we catch a LOT of potential issues in review.

.... I say this, of course, while I'm running some tests to see whether we've
fixed something I missed doing a code review a month or two back.

Oh I've been there and done that! You have to use the ISO When In Rome
standard.

Yeah. A very important standard.

-s

 

[Keith Thompson]

I see...actually I was wondering: wouldn't it be better to require
the preprocessor to remove comments before splicing lines?
is there any conflict or any reason not to do so?

I think it would solve some problems but cause others and make the
overall translation model more complex.

Currently, line-splicing occurs in translation phase 2, and it acts on
physical source lines. In that phase, tokens, even preprocessing
tokens, don't exist yet; neither do comments.

And there's always the possibility of breaking existing code.

 

[jacob navia]

Le 16/09/10 23:50, Keith Thompson a écrit :

I think it would solve some problems but cause others and make the
overall translation model more complex.

Currently, line-splicing occurs in translation phase 2, and it acts on
physical source lines. In that phase, tokens, even preprocessing
tokens, don't exist yet; neither do comments.

And there's always the possibility of breaking existing code.

A language is REGULAR if there are simple rules that allow easy use of
features.

Rule:
Comments are comments and not program text. What is behind a comment
doesn't affect the code.

Exceptions:
If a comment ends with a backslash, it will swallow the next line.
If a comment has //???/ (or similar) the sequence ??/ can be undesrtood
as a trigraph \ and will provoke similar behavior.

All this is completely unnecessary BS.

 

[Keith Thompson]

Le 16/09/10 23:50, Keith Thompson a écrit :

A language is REGULAR if there are simple rules that allow easy use of
features.

Rule:
Comments are comments and not program text. What is behind a comment
doesn't affect the code.

Exceptions:
If a comment ends with a backslash, it will swallow the next line.
If a comment has //???/ (or similar) the sequence ??/ can be undesrtood
as a trigraph \ and will provoke similar behavior.

All this is completely unnecessary BS.

I don't disagree, but I'm just not sure how to fix it.

Leaving trigraphs aside for the moment, there's a conflicting set of
rules:

Each physical line is a logical line, except that trailing backslashes
may be used to join two or more physical lines into a logical line.

The standard resolves this by doing line-splicing in phase 2 and
tokenization in phase 3. The result is unambiguous, but can lead to
some surpising results.

So how would you resolve this without breaking too much existing code?

Do you propose swapping phases 2 (line splicing) and 3
(tokenization)? That would cause backslashes within comments to
be ignored, but it would mean you couldn't have a line-splicing
backslash in the middle of a token. Older code commonly uses this to
splice long string literals; this is better done with concatenation
(handled in TP6), but breaking such code would have a real cost.

(And yes, I certainly would have done trigraphs differently, probably
leaving them disabled unless there's an explicit enabling sequence at
the beginning of a physical source file.)

 

[Ian Collins]

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.

But... just look at all the arguments about promotion rules etc. in
regards to the bit manipulation macros posted by our mate Brian. You
wouldn't see those on a C++ list because the idiomatic C++ solution
(function template rather than macro) in inherently type safe and does
not involve any integral promotion.

Again... just look at all the debate on the "Continuing an outer loop
from an inner loop" thread. You wouldn't see those on a C++ list
because the language supports automatic clean-up, so the single
justification for goto in C is removed.

You see all languages have their dark corners.

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.

And macros aren't? At least the type of the augment is known inside a
template and it can be checked if required.

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

If the original authors didn't include unit tests, that is regrettable.
But the same applies to any new, large code base whatever the language.
Overuse of macros can and does make C code more incomprehensible than
badly written C++. At least with the latter you can step through with a
debugger.

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.

Ah the perils of an IDE. Unfortunately all programming languages are
vulnerable to those.

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.

Reinvent a wheel?

 

[Seebs]

But... just look at all the arguments about promotion rules etc. in
regards to the bit manipulation macros posted by our mate Brian. You
wouldn't see those on a C++ list because the idiomatic C++ solution
(function template rather than macro) in inherently type safe and does
not involve any integral promotion.

It does if you're using shorts.

-s

 

[Ian Collins]

It does if you're using shorts.

Where does the promotion occur?

I always wear shorts!

 

[Seebs]

Where does the promotion occur?

Every expression ever. Unless C++ removed the default integer promotions.

short s = 1, t = 3;
s << t;

In C, at least, the expression is of type int, because it's a plain int
left shifted by a plain int. 6.5.7 (Bitwise shift operators), p3:

The integer promotions are performed on each of the operands. The
type of the result is that of the promoted left operand.

Heck.

(short) (((short) s) << ((short) t));

This is still a left shift the operands of which are both plain int, not
short. I think the expression as a whole evaluates to short, though, I
don't think full expressions are promoted. But if you did anything with
it, it would be.

-s

 

[Ian Collins]

Every expression ever. Unless C++ removed the default integer promotions.

short s = 1, t = 3;
s<< t;

In C, at least, the expression is of type int, because it's a plain int
left shifted by a plain int. 6.5.7 (Bitwise shift operators), p3:

The integer promotions are performed on each of the operands. The
type of the result is that of the promoted left operand.

Heck.

(short) (((short) s)<< ((short) t));

This is still a left shift the operands of which are both plain int, not
short. I think the expression as a whole evaluates to short, though, I
don't think full expressions are promoted. But if you did anything with
it, it would be.

I see your point, silly me.

I was specifically referring to Eric Sosman's excellent Brian baiting posts.

 

[Seebs]

I was specifically referring to Eric Sosman's excellent Brian baiting posts.

Ahh. I've been sorta wandering in and out of the thread, and I have less
continuity of discussion than you get from most modern TV commercials.

-s

 

[Ed Prochak]

Recently in another thread, we discussed a bit about C vs C++
maintenance. As usual in those discussions, many of the arguments and
ideas behind the views expressed weren't even said, and even less dicussed.

I would like to make the motives behind my viewpoint explicit.

[details deleted]

This proves that C++ has grown so complex that there isn't any human
mind capable of understanding it, not even the mind that started the
language several years ago.
[]

Many speak about easy of use, meaning the easy to WRITE code. I prefer C
because easy of use means for me more the ability of READING and
UNDERSTANDING code in that language.

Obviously these are my views and engage only myself. I hope we can avoid
polemic in discussions here. This is not an "all out" attack on C++
either. It is just a dissenting view about it, and an explanation why I
prefer C.

jacob

Wow. You expressed some opinions about C++ (and implications for
related OO languages) better than I have ever been able to.


Thanks.
Ed