Tuesday, January 28, 2020

Digest for comp.lang.c++@googlegroups.com - 6 updates in 2 topics

Puppet_Sock <puppet_sock@hotmail.com>: Jan 28 07:38AM -0800

The new version of "Large Scale C++" by Lakos is finally out. Well, volume 1 is out.
 
https://www.amazon.com/Large-Scale-Architecture-Addison-Wesley-Professional-Computing/dp/0201717069/
 
I am about 70 pages in. So far, I'm liking.
 
Anybody else read it? Thoughts?
Robert Wessel <robertwessel2@yahoo.com>: Jan 27 07:37PM -0600

>// endofouterloop:
 
>the statements will jump to completely different points. The break
>actually goes to an implicit statement after the loop.
 
 
I think the slight oddity of target location when the label is used
for both a break/continue and a goto is pretty minor. I suppose we
could come up with some alternative way to specify a "statement name",
but I don't see a big advantage. If we can have a dozen meanings of
static, why not this.
 
 
 
>as it pinpoints exactly where the code will end up next. With loads of
>nested }s floating around, many nothing to do with the loops, the end of
>the desired loop is not always easy to find.
 
 
I think that's the wrong principle. If you want to target a specific
location, use a goto. The idea is to break/continue a loop/switch, so
it should be the *loop/switch* that should be identified.
Robert Wessel <robertwessel2@yahoo.com>: Jan 27 09:06PM -0600

On Sun, 26 Jan 2020 22:15:06 +0100, David Brown
>author). As you say, the context of that paper is different from the
>situation now, and I think we can all agree that spaghetti programming
>is a bad idea.
 
 
Let me emphasize, I didn't intend to accuse you of that sort of closed
mindedness, and if it came across that way, I apologize. There are
many people, though, who have heard a rule, and gosh darn it, they're
going to apply it, no matter what. Unfortunately it seems to be
prevalent with people who are in charge of writing and enforcing
coding standards.
 
That being said, I don't think we're really disagreeing on all that
much.
 
 
>or perhaps you need to change the problem.
 
>I am sure there are some types of coding situations where goto is
>considered a reasonable choice - I just don't meet these situations.
 
 
Different people will disagree about issues of style and clarity.
That's inevitable. Take the endless brace-style discussions
(please!).
 
But if I come work on one of your projects, I'll follow your project's
standards. And perhaps I might struggle a bit in some of the
(occasional) cases where I might consider a goto, or if your standards
for routine length might be a bit shorter than ours, or whatever,
simply because that somewhat changes the idioms I'm used to using
every day.
 
And if you come work on one of mine, I'll trust you not to run off and
refactor everything that doesn't meet your preferences.
 
And we can both (good naturedly) grumble about the wrong-headedness of
the other approach at the water cooler.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jan 27 07:15PM -0800

> On Mon, 27 Jan 2020 21:38:26 +0000, Bart <bc@freeuk.com> wrote:
[...]
 
> I think that's the wrong principle. If you want to target a specific
> location, use a goto. The idea is to break/continue a loop/switch, so
> it should be the *loop/switch* that should be identified.
 
Personally, I like the way Ada does this. You can apply a label to a
loop, and it's the name of the loop ("--" introduces a comment):
 
OUTER: while condition loop
INNER: while condition loop
-- do stuff
if Done_With_Outer then
exit OUTER; -- "exit" is Ada for "break"
elsif Done_With_Inner then
exit INNER;
end if;
-- do more stuff
end loop INNER;
end loop OUTER;
 
"exit OUTER" is best thought of as an operation that applies to the loop
named "OUTER" rather than as a branch to a particular location.
 
Loops that are the targets of goto statements have a different syntax,
one that was designed to stand out:
 
<<LABEL>>
...
goto LABEL;
 
On the other hand, Perl does something similar, but uses the same syntax
for loop names and goto labels. This does mean that seeing a named loop
raises the possibility that somewhere there's a goto that targets it,
but that's not much of a problem in practice.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
"Fred. Zwarts" <F.Zwarts@KVI.nl>: Jan 28 11:45AM +0100

Op 27.jan..2020 om 22:38 schreef Bart:
 
> as it pinpoints exactly where the code will end up next. With loads of
> nested }s floating around, many nothing to do with the loops, the end of
> the desired loop is not always easy to find.
 
Maybe, but for a "continue outerloop;" a label at the beginning would be
more appropriate, or even better, inside the loop.
David Brown <david.brown@hesbynett.no>: Jan 28 01:08PM +0100

On 28/01/2020 04:06, Robert Wessel wrote:
>> is a bad idea.
 
> Let me emphasize, I didn't intend to accuse you of that sort of closed
> mindedness, and if it came across that way, I apologize.
 
I didn't think you did accuse me of closed mindedness (other people
have, at times, and they have sometimes done so fairly. I can be rather
rigid in my opinions, or the way I express them). I was just trying to
clarify a little.
 
> going to apply it, no matter what. Unfortunately it seems to be
> prevalent with people who are in charge of writing and enforcing
> coding standards.
 
With coding standards, as with any other set of rules, there is always a
balance between having a clear and consistent rule set and having
flexibility. Sometimes the consistency outweighs the details of the
rule, other times the rule might be too strict. Usually in coding
standards it is a good idea to have different levels (you /must/ do
this, and /should/ do that) and to have procedures for breaking the
rules ("should" rules can be broken but you must comment the break in
code, breaks of "must" rules need written permission from the program
manager).
 
> That being said, I don't think we're really disagreeing on all that
> much.
 
Agreed. I think we are both against banning "goto" merely because it is
trendy to hate it, or because Djikstra wrote a paper against it. We are
both looking for ways to write the code in a clear, logical and
maintainable fashion, and we are both expecting to use good tools and
newer language standards in order to get that without a cost in
efficiency. We just disagree a little on when "goto" might boost code
clarity, and when it is a detriment - and that is likely to be from
different experiences and different types of code.
 
 
> Different people will disagree about issues of style and clarity.
> That's inevitable. Take the endless brace-style discussions
> (please!).
 
Yes. There is one correct way, that I use, and a number of wrong ways
that some other people use :-)
 
> every day.
 
> And if you come work on one of mine, I'll trust you not to run off and
> refactor everything that doesn't meet your preferences.
 
Indeed. Consistency is very important.
 
There are times when a big refactoring is appropriate, but you need good
reason for it - changing brace style, for example, is not such a reason.
 
 
> And we can both (good naturedly) grumble about the wrong-headedness of
> the other approach at the water cooler.
 
Yes - and I view c.l.c. and c.l.c++ as virtual water coolers!
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: