×
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.
On 6/18/2012 11:51 AM, Rory Hewitt wrote:
What would be the benefit of your 'true' CONST over VALUE - performance
only?
You don't always have the luxury of using VALUE. If you are writing a
subprocedure and calling it, both from RPG, then sure, you can use VALUE.
But, if you're calling a CL program, OPM program -- or for that matter,
any sort of *PGM call, you can't choose to use VALUE, since they only
accept parameters by reference.
Likewise, not all languages allow all data types to be passed by VALUE.
For example, you can't really pass a character string by VALUE to C
programs (yes, I know you can work around that with data structures...
but you can't always control how the C programmer chooses to receive his
parameters, plus you're making things more difficult for him.) --
character strings need to be passed by reference.
I guess I can see your point, but (and here I'm, only talking about parms
where the parameter doesn't need to be transformed) except for the
discussed scenario where the called program doesn't specify CONST, there
are very few occasions where a CONST parameter can be changed by the called
procedure anyway. How often do you run into those scenarios?
This part I agree with.
Frankly, there are a small minority of people who get confused by CONST
because they have this strange opinion that when you pass something by
CONST it can't be changed by ANY method at all, even other means of
accessing the same underlying memory. To my mind, those people are the
ones who are wrong, not the way CONST works today!
So I don't really think it _needs_ to be changed -- but the feature
wouldn't hurt, either.
midrange.com
