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



Hi, Vern:

<RANT>
Let's not forget why this is so, why do C or C++ APIs require this special treatment? This is because when the C language was first developed, all arguments to all functions were always passed "by value". In fact, if you want to pass an argument to a function that may be modified, you must explicitly code this in the C language, e.g.:

foo (arg1, &arg2);

where the "&" operator takes the address of arg2 -- so you are passing the address of arg2 as the second "by value" parameter, in effect, creating your own "pass by reference" (aka. "pass by address" or "pass by location") parameter-passing convention.

What makes this even worse is that you must therefore remember to always put that & in exactly the right place, in this case, when invoking "foo", for the second argument, instead of just declaring this on a prototype for the function or procedure, as most "modern" languages, like Pascal, or even RPG IV, do. :-o

Or, you can do something slightly trickier, in C, such as:

int arg1;
*char parg2; parg2 = &arg2;
foo(arg1, parg2);

Now, isn't that just wonderful? :-o

This was in part because in the original K&R C, you never had to "prototype" functions; you just wrote something like "bar(a, b, c);" and the compiler assumed it was an external function call (to a routine named "bar" in this case).
Ugh! And, by the way, guess how many "memory overlay" errors this has caused, when someone omitted that little "&" in a call?

Note also that the original C language made no distinction between procedures or functions. So you could code:
x= bar(a, b);
or
bar(a, b);

The original C compiler did not care, and if bar returns a value, in the second case above, the compiler just tosses away any result returned.

Now, don't you just love Unix and C?

Oh, well, just more Unix "lossage" ... (Unix dweebs actually coined a word for these kinds of problems caused by Unix and/or C conventions!)
</RANT>

Cheers,

Mark S. Waterbury

> Vern Hamberg wrote:
David

In our own applications there is almost no reason to use VALUE that I can think of. The main reason is to call certain APIs that have parameters defined as integers, and these are by value. These tend to be C/C++ APIs. Things like the access() function that acts like a CHKOBJ - it uses an integers for some of its parameters, as I recall, and you get spurious results if you don't use *BYVAL in a CL or VALUE in RPG.

Even when using CONST on a large parameter, only 16 bytes are passed - for the pointer - even though a copy might be made of the original variable. At least the entire variable is not being passed.

HTH
Vern

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.