Re: C coding
Scott Klement <[email protected]>
| Newsgroups | gmane.comp.lang.as400.c |
|---|---|
| Message-ID | <[email protected]> |
Frank,
In my opinion, C (and C++) are very well suited to writing things like
tools, compilers, OSes, drivers, and similar things. In my job, I use
it for 5250 emulation products, modernization tools (5250 screen
refacing, Open Access handlers that produce web applications, etc.)
It's a very different experience writing this sort of code, since it
rarely uses a database at all, doesn't really ever do number crunching
or totalling, etc. Very different from business logic. I find RPG to be
a much better environment for business logic. (And, in fact, where I
work we use RPG as well, using C where it's appropriate, and RPG where
it's appropriate, etc.)
We certainly do serious coding in ILE C on IBM i. (Sorry, I will not
say "on AS400", as I don't want to appear _that_ outdated.)
You can write very nice, maintainable code in C. Just as with any
programming language (C, C++, Java, PHP, RPG, JavaScript... doesn't
matter) it's always best to divide your code into modular parts that
stand alone, and for each part to have a 'well-defined interface' that
consists of a prototype (called "signature" in some languages) that
defines what is allowed to be passed into the routine, and this is the
_only_ way that variable data gets passed on a call.
This assists with encapsulation: You don't need to understand the logic
within the routine to call it, you only need to understand the
interface. It also assists with reusability... you don't have to
worry about it affecting something outside of the routine, because
everything is internal, except the bits you can see in the interface.
It also assists with maintenance and agility, because you can rewrite
the internals of the code without worrying about it affecting the
callers, as long as you keep the interface compatible.
The other stuff you mention (loop on a single line of code making it
hard to step thru in a debugger, etc) is just a matter of coding style.
I wouldn't even try to debug an intermediate representation of the
code (IBM doesn't give us debugging tools for that, anyway) but if I
needed to debug it, I'd simply insert some line breaks into the code so
it's not all on one line... then I can use a normal debugger. It's not
that big of a deal.
On 2/10/2014 3:59 PM, frank kolmann wrote:
> Hi
>
> Having done a first pass on learning C using the K&R The C programming
> Language I am
>
> Now doing the examples in ILE C for AS/400(R) Programmer's Guide.
> The below is an example of a program in the IBM Guide.
> The IBM code seems to me to be a trivial example of what C is capable of.
> Scott you mentioned before when I posted a question on C Syntax Errors that
> the
>
> Code posted was 'Absolutely horrible code'. At the time your comment did
> not really
> register with me. I well respect your opinion and I have learnt a lot from
> you.
> I would be grateful to hear your views on how to write C code.
>
>>From my reviews of what is said on the net about C code,
>
> I have stumbled on these points.
>
> Professional C programmers use a subset of C that they have found
>
> best suits their needs.
>
> It is easy to introduce errors in C codes that lead to the infamous
> 'memory leaks' and such errors can be very hard to find.
> So hard in fact that some C projects have failed.
>
> Debugging C can be hard because a single line can be a looping function and
>
> the error can be inside the loop but the debugger cannot see that level of
>
> detail unless you debug intermediate source and the intermediate source
>
> can be so arcane you still cannot find the error.
>
> So I am prompted to ask, is anyone doing serious coding in C on the AS400.
> And if so what is the application and more interesting to me what style of
> C code is being used?
>
>
>
> Regards
> Frank Kolmann
>
>
>
> http://publib.boulder.ibm.com/infocenter/iadthelp/v7r0/index.jsp?topic=/com.ibm.etools.iseries.pgmgd.doc/cpprog162.htm
>
>
>
> /* This function writes an audit trail. To write the audit trail
> the */
>
> /* file field structure is retrieved from the DDS file T1520DD1
> and */
>
> /* the taxrate data item is imported from service program
> T1520SP2. */
>
> /* Retrieves the file field structure.
> */
>
> #pragma mapinc("myinc", "MYLIB/T1520DD1(*all)", "both", "p z","")
>
> #include <stdio.h>
>
> #include <stdlib.h>
>
> #include <string.h>
>
> #include <time.h>
>
> #include <decimal.h>
>
> #include <recio.h>
>
> #include <xxcvt.h>
>
> /* These includes are for the call to QWCCVTDT API to get the
> system */(1)
>
> /* date to be used in the audit
> trail. */
>
> #include <QSYSINC/H/QWCCVTDT>
>
> #include <QSYSINC/H/QUSEC>
>
> /* DDS mapping of the audit file,
> T1520DD1. */(2)
>
> #include "myinc"
>
> /* Tax rate is imported from service program
> T1520SP2. */(3)
>
> const extern decimal (2,2) taxrate;
>
> void write_audit_trail (char user_id[10],
>
> char item_name[],
>
> decimal (10,2) price,
>
> short int quantity,
>
> char formatted_cost[22])
>
> {
>
> char char_item_name[21];
>
> char char_price[11];
>
> char temp_char_price[11];
>
> char char_quantity[4];
>
> char char_date[6];
>
> char char_taxrate[2];
>
> /* Qus_EC_t is defined in
> QUSEC. */
>
> Qus_EC_t errcode;
>
> char get_date[16];
>
> int i;
>
> double d;
>
> /* File field structure is generated by the #pragma mapinc
> directive. */
>
> MYLIB_T1520DD1_T1520DD1R_both_t buf1;
>
> _RFILE *fp;
>
> /* Get the current date.
> */
>
> errcode.Bytes_Provided = 0;
>
> QWCCVTDT ("*CURRENT ", "", "*MDY ", get_date, &errcode);
>
> memcpy (char_date, &(get_date[1]), 6);
>
> /* Loop through the item_name and remove the null
> terminator. */
>
> for (i=0; i<=20; i++)
>
> {
>
> if (item_name[i] == '\0') char_item_name[i] = ' ';
>
> else char_item_name[i] = item_name[i];
>
> }
>
> /* Convert packed to zoned for audit
> file. */
>
> d = price;
>
> QXXDTOZ (char_price, 10, 2, d);
>
> QXXITOZ (char_quantity, 4, 0, quantity);
>
> d = taxrate;
>
> QXXDTOZ (char_taxrate, 2, 2, d);
>
> /* Set up buffer for
> write. */
>
> memset(&buf1, ' ', sizeof(buf1));
>
> memcpy(buf1.USER, user_id, 10);
>
> memcpy(buf1.ITEM, char_item_name, 20);
>
> memcpy(buf1.PRICE, char_price, 11);
>
> memcpy(buf1.QTY, char_quantity, 4);
>
> memcpy(buf1.TXRATE, char_taxrate, 2);
>
> memcpy(buf1.TOTAL, formatted_cost, 21);
>
> memcpy(buf1.DATE, char_date, 6);
>
> if ((fp = _Ropen("MYLIB/T1520DD1", "ar+")) == NULL)
>
> {
>
> printf("Cannot open audit file\n");
>
> }
>
> _Rwrite(fp, (void *)&buf1, sizeof(buf1));
>
> _Rclose(fp);
> }
>> date: Fri, 17 Jan 2014 20:13:16 -0600
>> from: Scott Klement <[email protected]>
>> subject: Re: [C400-L] C syntax errors
>>
>> Not to mention that it uses global variables (and even extern variables)
>> throughout instead of parameters...
>>
>> Absolutely horrible code. Definitely not to be used as an example!.
>>
>>
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: C400-L-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.