|
> From: Jim Langston > > There are a few generally accepted methods to do this, and I > didn't see the > original e-mail so don't know the specifics in this case. > > But James Rich is right, returning a pointer to private storage is bad > design, private storage being memory available to a subroutine or function > only. As I said, I agreed with the concept of internal variables being kept private. This by definition would mean any temporary variables. And if we're just referring to temporary variables, then I agree completely. However, James went a little too far, in my estimation, when he made a blanket condemnation of returning pointers to static variables. There are times when returning a pointer to a static variable or dynamically allocated memory is a valid technique. In my example, that of a pool or cache, it's perfectly acceptable to have a method return pointers either to statically defined or dynamically allocated memory. Indeed, in a truly OO design it's required, beacuse the calling method should have no idea how much memory to allocate, since it should not know the internal layout of the structure (this is the age old issue of "handles" vs. "pointers"). > The way around this is to have the calling module set up memory > before hand > and pass a pointer to it into the function. Returning a pointer > to a system > object or class is not considered private storage, it is available outside > of that function. This is not necessarily the best solution. This solution implies that the calling method knows how much memory to allocate, and thus binds the caller to the callee. If it is instead the job of the called method to allocate the memory, then only that method needs to know how much memory to allocate. Of course, this is only valid in the situation where the entire contents of the generated object are unknown to the caller, but that's pretty much the entire concept behind object oriented programming. I ought to do a primer someday on using RPG procedures to mimic OO behavior. It's actually quite fascinating, and relatively easy to accomplish. Each "class" is actually a module with one procedure for each "method". There is also a "constructor" which allocates a chunk of memory (or multiple chunks, depending on the object) and returns a pointer to it - this pointer becomes the object "handle". Every other method in the module takes as its first argument a handle, which is used within the module to access the memory. > The biggest reason not to do this is because memory is not guaranteed to > exist beyond the life of the function. Again, two different issues. Returning pointers to temporary values is by definition bad, for just the reason you (and James) mentioned. Using a STATIC just to get around that concern is probably bad, but returning pointers to non-temporary data, either static or dynamically allocated, is not IN AND OF ITSELF a bad thing. I just wanted to make the distinction. Pointer to temporary variable = BAD Pointer to static, dynamic = MAYBE Joe
As an Amazon Associate we earn from qualifying purchases.
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.