[32947] in Perl-Users-Digest
Perl-Users Digest, Issue: 4223 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun May 25 21:09:26 2014
Date: Sun, 25 May 2014 18:09:04 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 25 May 2014 Volume: 11 Number: 4223
Today's topics:
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 25 May 2014 14:25:39 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87d2f2f0rw.fsf@sable.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2014-05-21 15:40, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
>> On 20.05.14 23:01, Rainer Weikusat wrote:
[...]
>>> (it took me more than five years of writing a lot of C before I
>>> encountered an "Oh! I really need a postincrement here!" situation
>>> for the first time).
>
> You never *really* need a postincrement operator. You can always get the
> same effect by saving the previous value in an auxiliary variable[1]. It
> does make code more concise, though. The canonical example is of course
> strcpy, which can be implemented as ¡°while (*s++ = *t++);¡±.
... which oversteps both s and t: There's no reason to increment either
of both beyond the trailing 0, making this a very bad example (This is
an issue of 'unclear use of language' at the source code level, not 'an
optimization problem' focussed on whether or not some computer will actually
execute the spurious increment).
[...]
>> By what criteria do you arrive at "easier to read"?
>> Subjectively, objectively, statistically, ..., or based
>> on your later mention of it: inherently?
>
> Subjectely, probably. But there is an objective component here: It is
> harder to read 4 lines instead of 1, so
I specifically wrote that it would cause the rather unimportant parts of
the code to take up a lot more space.
[...]
> (I don't know the code in question, so maybe there is a reason to split
> the call to rmdir from the error handling but I would probably write
> this as:
> $rc = rmdir($_[0]) or $sysc = "rmdir $_[0]", last;
>
> ¡°function_call() or error_handling¡± is a very common idiom in Perl and
> you should have a good reason for deviating from it.)
The 'very good reason' is 'code has to be debugged'. Which means there
should be an easy opportunity to inspect state immediately after the
rmdir and before control moves elsewhere, either interactively from a
debugger or by inserting some kind of 'diagnostic output' statement.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4223
***************************************
