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



Larry,

There's been some discussion about this in the past. In particular look for posts from Barbara Morris
on the subject.

Here's one:
http://archive.midrange.com/rpg400-l/200705/msg00155.html

"Neither CONST nor VALUE is always better than the other. But if you _were_ restricted to one or the
other, CONST would be a better choice.

For a few data types (pointer, float, integer), VALUE is a bit more efficient. For other data types,
CONST is usually more efficient; the larger the parameter, the better CONST is. For large parameters,
CONST is more efficient even if you have to copy the parameter to a temporary within the procedure to
have something you can modify; this is especially true of VARYING parameters."

Whenever possible, if I'm passing large strings, or to be more precise, if my procedure accepts large
strings, I make them CONST VARYING.


HTH,
Charles


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Larry Ducie
Sent: Tuesday, October 30, 2007 8:17 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Is const really that much better than value?

Hi Chaps,

Quick question - when passing a variable value to a
subprocedure, and the passed variable does not have the same
length/precision as that defined on the prototype, what is
the real difference between passing it by constant reference
or by value? Why choose one over the other? For passing long
strings by constant reference and options(*varsize) is not
used then doesn't the OS simply copy the variable to a
temporary field anyway if the variable length does not match
the prototype definition? Isn't this the same as passing by
value in all real respects?

I mean, when parameters are passed to a subprocedure the OS
passes an array of pointers together with operational
descriptors doesn't it? for passing by value the pointers
will point to temporary variables containing copies of the
original data. These are cast/padded/truncated accordingly.
When passing by constant reference doesn't the OS also do
this if the original variable definition does not exactly
match that on the prototype? This is why we can pass zoned
fields even though the prototype defines a packed parm, etc.

I guess I'm basicaly asking - in this scenario is there any
real performance reason for passing a long string by constant
reference over passing it by value? Do we only get a
performance gain when we have an exact match and a temporary
field is not necessary when passing by constant reference? (I
must stress thet I'm talking about scenarios when
options(*varsize) and/or opdesc are NOT used).

I'm very interested to know the mechanics behind this so I
can make the right design choices. If I have it all wrong
then I'd rather know now. :-)

Cheers

Larry Ducie

--
This is the RPG programming on the AS400 / iSeries (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.