Just a comment on coding style:
I understand there are some nasty traps that an RPG coder can fall into, but you should avoid awkward constructs that mimic or build on RPG style of coding. One reason for using C could be access to skilled personnel, C skills should be more easily accessible than RPG skills these days; you don't want a situation where a generally good C coder will have a hard time understanding your programs.
Regardless, maybe you will not maintain this program for the rest of your life... ;-)
/Joakim
Joakim Lindbom
Principal | Certified Enterprise Architect
Capgemini Sweden / Application Consulting / Sales Enablement
Tel: +46 8 5368 3934 / Skype: joakim.lindbom
www.capgemini.com
People matter, results count.
________________________________________
Från: c400-l-bounces@xxxxxxxxxxxx [c400-l-bounces@xxxxxxxxxxxx] för Frank Kolmann [fkolmann@xxxxxxxxx]
Skickat: den 3 april 2014 12:39
Till: c400-l
Ämne: [C400-L] First C program
Hi Jevgeni
Thank you. You make good points.
That is a good way of trapping the == issue.
I will follow Barbaras advice in the coding of the if.
I like the way you use the #define for the type defs.
It does make the code clearer, I will use that sytle.
Frank
*Subject: Re: First C program
*From: Jevgeni Astanovski <Jevgeni.Astanovski@xxxxxxxxxxxxx>
*Date: Wed, 2 Apr 2014 07:54:34 +0000
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.
....
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....
--
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.
________________________________
Capgemini is a trading name used by the Capgemini Group of companies which includes Capgemini Sverige AB, a company registered in Sweden (number 556092-3053) whose registered office is at Gustavslundsvägen 131 Box 825 – S-161 24 Bromma.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
midrange.com
