× 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.



Simon et al,

I have a fair number of hang-ups with C and C++, as well as Java/RPG.

For example, I do NOT care for data-casting.  I would like, rather than
overloading on procedures and qualified data structures, overloaded data.
Iow, I would like a compiler that automajically allows a numeric
quantity-type of data element to be available as both a subfield and
standalone field, and available for display/print (eventually /voice?)
presentation as edited left-justified, edited right justified and also
available for arithmetic.  *MAPVAL is great for display/print files, but
insufficient imo.

It's been a while (25 years?) since I did a thorough investigation and
comparison of programming languages.

But my basic question is whether MI is going to continue to be relegated as
an less-than-close-to-fully-supported language.  Iow, there is (at least)
one very pragmatic reason to stick with C, which is it'd be harder for IBM
to neuter than what it's done with MI and RPG.

| -----Original Message-----
| From: mi400-bounces@xxxxxxxxxxxx [mailto:mi400-bounces@xxxxxxxxxxxx]On
| Behalf Of Simon Coulter
| Sent: Tuesday, March 02, 2004 3:39 PM

| On Wednesday, March 3, 2004, at 02:29  AM, James H. H. Lampert wrote:
|
| > Yes, and since it makes no allowances for the way C handles character
| > strings (which, I freely admit, is more than a little bit meschuga, but
| > PL/I would be my language of choice), you try to look at a character
| > string variable, and you've got to go through all sorts of rigmarole to
| > do it.
|
| PL/1 is my choice too.
|
| While I'm not defending the the ILE debugger it is much easier to use
| once you realise that it tries to behave like the underlying language
| therefore it does make allowances for C's admittedly crappy idea of
| strings.
|
| Since C has no concept of character variables (if you discount the
| stupid idea that a char is numeric data type) and uses null-terminated
| arrays to represent them, and that in C arrays and pointers are the
| same thing (another stupid idea), then the debugger's contortions are
| understandable.
|
| To reference the contents of a characters string in C you must either
| use array subscripting or pointer de-referencing.  Thus:
|       EVAL    *string
| in the debugger will do exactly what *string does in C, that is
| de-reference the pointer and access the first character. So too,
|       EVAL    *string:s
| will treat the stuff pointed to by string as a null-terminated string
| (because of the :s) and show all characters up to the first null
| (x'00). This behaviour seems to be what a C programmer would expect.
|
| Since it is common for programmers to make errors the debugger will
| only show the first 30 bytes of a C-style string--in case there isn't a
| null. You wouldn't want the debugger to attempt to dump all storage
| from the pointer address in the hope that a null might appear would
| you? Thus:
|       EVAL *string:s 100
| will show the all characters up to the first null, or the first 100
| bytes of whatever string points to if a null is not encountered, in
| character form.
|       EVAL *string:x 100 will show the first 100 bytes regardless of any
| nulls in hexadecimal output.
|
| There is also the :f form which will display formatted strings by
| evaluating embedded directives like \n.
|
| Using the affinity between pointers and arrays allows you to also do
| things like:
|       EVAL    string[0]
| which is equivalent to
|       EVAL    *string
| or
|       EVAL    string[10]
| which is equivalent to
|       EVAL    *(string+10)
| Again this seems to be what a C programmer would expect.
|
| The one missing thing is displaying array ranges. In non-C source you
| can do:
|       EVAL    array(10..20)
| to display the array elements 10 to 20 inclusive. I haven't found any
| way to do the same in the ILE debugger. EVAL  array[10.20] results in
| "Syntax error occurred".
|
| Regards,
| Simon Coulter.
| ---------------------------------------------------------------------
| Arterial Software
| IBM Tower
| Level 3, 60 City Road
| Southgate Victoria 3006
| Australia
| http://www.arterialsoftware.com
| +61 3 9421 5911 (Phone)
| +61 3 9428 3729 (Fax)




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-2023 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.