Oppolzer - Informatik / Blog

I don't like C++ very much, for several reasons, but I am working with C (and PL/1)
for more than 20 years now, and IMHO and in my experience C is a wonderful language
where I can create large, secure, reliable and effective software products ... of course
it has to be well done, as with every other language, too. C is NO TOY language.

More arguments below.

Very respectfully, kind regards

Bernd Oppolzer


Am 19.11.2014 13:53, schrieb J.G.:
> As I have had occasion to note here before, the traditions of C and
> its sequelę interest me chiefly as illustrations of  one or another
> pathology.
>
> The PL/I tradition provides better positive guidance.  From the
> beginning, with the PL/I F
> compiler, such a construction as
>
> declare hashvcs entry(character(*) varying, binary fixed(15,0))
>    returns(binary fixed(15,0)) ;
> . . .
> declare hashin character(*) varying, hashval binary fixed(15,0) ;
>
> hashval = hashvcs(hashin, 1101b) ;

you can do similar function calls in C; I don't see your problem;
you only have to take the call-by-value paradigm into account
and you need to make all your call-by-reference parameters explicit
by passing pointers.

In C, this would look like

hashval = hashvcs (hashin, 0x0d);   /* hex instead of binary */

the function prototype could look like this:

int hashvcs (char *hashin, int hashval);

there are some possible variations; the int parameter and result type could be short
(but I would prefer int, because C promotes parameters to int anyway),and the char *hashin
could be something more sophisticated, maybe a structure containing a length, or the
length could be passed as another parameter. I don't like the convention with the
zero byte at the end very much ... but it's just that: a convention ... you can define
your function interfaces without using it. You can even emulate PL/1 varchars, if you
want.

BTW: at the site I am working we are calling all the time C libraries from PL/1; we solved
all the problems with different data representation etc., no problem at all. The reason for
us to do this: the C part of the application needs to be present on all platforms
(insurance math). I believe I told you already.

> resulted in the creation of a halfword temporary initialized  to have
> the binary value 1101b (decimal 13).  The address of that temporary,
> not that of the (internal/converted) value of the literal 1101b, was
> then made available to the entry hashvcs, which was free to mutilate
> it without non-local effect.

the call-by-value paradigm also doesn't generate non-local effects.
Sometimes for performance reasons parameters which are not meant to be changed
by the function are passed by reference (via pointer). In this case, the function
specification tells, that the parameter is not changed by the function. If it is changed,
this is an error in the function implementation and can (and must) be fixed locally.

> Today, one can make corresponding distinctions within a function like
> hashvcs, as in
>
> hashvcs: procedure(vcs, modulus)
>    returns(signed binary fixed(15,0))
>    reorder ;
>
>    declare (vcs character(*) varying2,
>       modulus signed binary fixed(15,0))
>       nonassignable parameter ;
>
>    . . .
>    return(hashval) ;
>
> end hashvcs ;
>
> C and its sequelę are and now seem likely to remain toys.  They have
> achieved all of  the portability of assembly language without its
> expressive power.

No. With C, it was for example possible for me to write an XML parser that
works on Windows, Linux, other Unixes, OS/2 and z/OS, with the same source, without
platform or opsys dependencies. Validating or non-validating, SAX and DOM,
three times faster than XerCes, a storage management on top of standard
ANSI malloc, that outperforms malloc in most cases for many small allocations
of storage (and returns all storage to the system at the end of the XML processing).

I see no other language which would make this possible.

I have a lot of other tools written in C, all are running on all the
platforms above from the start.

>
> J.G.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to listserv@listserv.ua.edu with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@listserv.ua.edu with the message: INFO IBM-MAIN