Yes. Barbara mentioned the define and I haven't...
Definitely there are lots of this sort of advises to avoid =/== possible mistake.
I've never saw the one you referred.
However some use another technique:
Instead of writing
if ((pf = _Ropen(PFILENAME, "rr")) == NULL)
they write
if (NULL == (pf = _Ropen(PFILENAME, "rr")))
In this case if you make a mistake and write
if (NULL = (pf = _Ropen(PFILENAME, "rr")))
you will immediately get a syntax error.
Of course this sort of problem (pseudo-problem) is caused by a person's backgound.
If I recall correctly, in PASCAL you also had to distinguish assignement and logical comparison.
Comparison was "=" and assignement was ":="....
On the second issue - this is purely a question of how readable is your program.
My personal practice is to use "explicit" way of defining types. For example:
#pragma mapinc("dspf", "*LIBL/Y80ALD(ADDCHRG)", "both", "_P", "Y80", "Y80")
#include "dspf"
#define INPUT_T Y80_ADDCHRG_i_t
#define OUTPUT_T Y80_ADDCHRG_o_t
in this case it is (more) clear where these types are derived from....
-----Original Message-----
From: c400-l-bounces@xxxxxxxxxxxx [mailto:c400-l-bounces@xxxxxxxxxxxx] On Behalf Of frank kolmann
Sent: Wednesday, April 02, 2014 9:32 AM
To: c400-l
Subject: [C400-L] First C program
Hi Jevgeni
Replies inline.
Frank,
read your code and found something new for myself.
You write:
if ((pf = _Ropen(PFILENAME, "rr")) EQ NULL) I would write it:
if ((pf = _Ropen(PFILENAME, "rr")) == NULL)
At the same time you write:
for (i = 1; i <= *n ; i++)
and not
for (i = 1; i LT *n ; i++)
Why?
I even did not imagine that EQ is allowed...
From Paul Contes book. Thanks Paul. I am still rereading your book to
understand more.
Common Sense C - Advice & Warnings for C and C++ Programmers
(Publisher: 29th Street Press)
Author(s): Paul Conte ISBN: 1882419006 Publication Date: 10/01/92
-- excerpt begins --
Reasonable arguments might be marshalled for either of three guidelines:
1. Use all of the standard C symbols
2. Use EQ instead of == (and possibly NE instead of <>), but use the standard C symbols for the rest of the operators 3. Use EQ, LE, etc., and don't use any of the standard C symbols
The first approach is risky and would only make sense if it were combined with some other guidelines, such as always checking a program with a compiler or "lint" utility that could detect the use of = where == was expected.
APPENDIX A -- C CODING SUGGESTIONS
Chapter 2
1. Don't use = in an if statement expression, unless it is
absolutely necessary.
2. Define a macro EQ for ==, and never use ==.
3. Define macros for &, |, &&, and ||.
4. Define macros for BOOL, TRUE, and FALSE.
5. Use only Boolean-valued expressions in if statements.
6. Use only Boolean variables with the logical operators && and ||.
7. Do all assignments as separate statements, not as part
of a more complex expression.
8. Use parentheses in expressions to explicitly define
order of evaluation.
9. Don't use %i format specifications or numbers that begin with 0.
10. Be sure to code addresses for arguments to scanf and
similar functions
-- excerpt ends --
I am using guideline 2.
And there is at least one thing unclear after reading your code:
where (how) the types S01_o_t, S01_i_t and C01_o_t are defined?
From this manual IBM has kindly set up the equivalent of Externally
Described files.
The #pragma mapinc directive provides the opportunity to convert DDS files to include files directly.
http://publib.boulder.ibm.com/infocenter/iadthelp/v7r0/index.jsp?topic=/com.ibm.etools.iseries.pgmgd.doc/cpprog318.htm
This is the C code.
#pragma mapinc("ddhpf","*libl/REL(*ALL)","input"," ",,"") #include "ddhpf"
#pragma mapinc("ddspf","*libl/SEL(*ALL)","input"," ",,"") #include "ddspf"
#pragma mapinc("ddhdf","*LIBL/CDISPRF(*ALL)","both indicators"," ",,"") #include "ddhdf"
after compiling the program check this file QTEMP QACYXTRA , it has the include source.
Frank
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list To post a message email: C400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/c400-l.
midrange.com
