× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Clever UNIX/C Constructs
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Thu, 4 Jan 2001 10:32:47 -0600 (CST)



On Thu, 4 Jan 2001, Evan Harris wrote:

> Hi Scott
> 
> The original thread (which I think I started) was based on the premise that:
> 
> EVAL Variable = Variable + 5
> 
> is, in my opinion at least,
> 
> much more readable and obvious than
> 
> variable += 5
> 
> So far the major argument for providing this syntax has been to save 
> typing: if there is another argument I'd be more than interested to hear it 
> as I really cannot see what it adds to any language. As per Richard's 
> comments it seems it arose from a design decision due to limitations of the 
> past - just as the columnar RPG format was rooted in its origins.

In C, I was always told that "A += 5" performs better than "A = A + 5".
The reason being that the compiled code only needs to load the value of A
from memory once instead of twice.  

My opinion is that there are circumstances when the "A +=" operator is
more intuitive for the person reading the code than the "A = A + " would
be.  Since this is a question of style, and style is purely a matter of
opinion, you don't necessarily have to agree with me.

> I agree with your statements regarding RPG syntax not necessarily being 
> obvious to the uninitiated, but it seems to me that += etc is just more of 
> the same from a different language. To make it clear where I am coming 
> from, would you want indicator logic added to C ? 

The whole premise of this is that "+=" makes for code that isn't obvious
to the reader.  I disagree with this premise.   This is NOT like putting
indicators into C.

There are C expressions that I don't like.  For example code that looks
like this:   
      newoption = (newoption == 0) ? newoption : newoption - 1;

Would be something that I would prefer not to add to RPG.  However, I just
don't see "A += 5" as being hard to follow.


> Why add something to RPG 
> that adds nothing content-wise merely additional form ?

I agree with this.  I wouldn't ask for this functionality in RPG unless I
was down to my last $2, and this was a $2 option.

> 
> Excuse my ignorance if I get this wrong (I have no more than a passing 
> acquaintance with C) but in the above example what would be the effect  of:
> 
> variable =+ 5
> 
> Would it (as I understand it) assign 5 to the variable rather than 
> incrementing it by 5 ? What are the side-effects (bad choice of words 
> possibly) of other incorrectly typed terse assignments ? And what is the 
> effect on debugging to those that are not proficient with this style of 
> expression ?

correct.   "variable =+ 5"  is the same thing as "variable = +5"

> 
> These days when I code I like to think that I am coding for "whoever comes 
> next" and that they will (hopefully) be impressed with how easy it is to 
> maintain or (god forbid) debug - not by having to refer to the manual to 
> understand indicators, cycles, expressions or whatever.
> 

The problem with RPG is we try to make the compiler writers decide what is
"good code" and what is "bad code", and then force it upon everyone.  They
don't try that in C.  They give you all the options, and leave it to the
programmer to develop code thats easy to follow.

The result, IMHO, is easier to follow C code.  The compiler developer
can't anticipate every piece of code we write, so give the programmer the
tools to do it the way that seems intuitive to him.


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.