Re: Another ILE question : CONST vs VALUE

["Rory Hewitt" <roryhewitt@xxxxxxxxx>]

All,

> > ...the system could provide some checking in this area...

Could, but doesn't. I've used the subversion technique to my advantage.
Probably a bad move, but at the time it was the only way I could get round
the problem of having lots of procedures calling my procedure where the PR's
they were using specified CONST (as did my procedure) but I needed to pass
back a value. Rather than change the callers, I changed the procedure to use
a non-CONST PI and then included code to check the calling procedure's name
and only change the parameter if it was from a (known) procedure which was
passing a variable.

It worked fine, but I got rid of it as soon as I could and used a wrapper
procedure. Needs must when the devil's at the door :-)

Like Tommy says, I like the compiler to catch my problems for me. Although a
system which doesn't allow parameter overloading is pretty crappy :-)

Rory

On 5/7/07, Bruce Vining <bvining@xxxxxxxxxx> wrote:
> > Nor is there any run-time mechanism to detect the mis-match.
>
> I do not know if RPG takes advantage of this (and suspect it doesn't, but
> Barbara would know for sure), but the system can provide some basic
> run-time checking.  If the caller specified that a parameter was to be
> treated as a constant, then the storage for the parameter could (and I
> emphasize could) be carved out of a read-only memory allocation by the
> compiler/run-time.  Attempts to modify the constant by the called program
> would then be detected.
>
> A minor point, but the system could provide some checking in this area
> (though it is dependent on the compiler).
>
> Bruce Vining