Hello,
Yes, this does solve the problem. Sorry for my wrong fix.
Bye
Rainer
On 24.06.2013 19:56, Rick McGuire wrote:
I'm not sure why the AIX compiler is thinking that OREF_NULL is
defined as an int, but I think the appropriate fix should be
if (((RexxObject *)string_value) ==
This question may be of interest for other developers as well, so moving/asking
it to the ooRexx
developer list:
While experimenting with a little C++ program, there would be a
RexxRoutineObject created using
NewRoutine() which then got executed with CallRoutine() many thousand times.
While
The interpreter knows nothing about any of the references you have in your
C code. Those are just normal pointers, so nothing happens to let the
interpreter know that those pointers are out-of-context. The only
mechanism the interpreter has available is the context object used to
provide the api
Thanks Rick.
I started writing a reply based on my experiences so far, but I know you
could explain it better.
I have one question based on Rony's code:
void executeProgram(RexxThreadContext *threadContext, char *fname, char
*code)
{
RexxRoutineObject
Nop, your analysis is correct. The return value (if is exists) is also a
potential memory leak. This probably doesn't show up as a problem because
the RoutineObjects take up a fairly substantial amount of memory.
Rick
On Wed, Jun 26, 2013 at 2:32 PM, Mark Miesfeld miesf...@gmail.com wrote:
Yes, any long-lived contexts like this should be doing that sort of
reference management. Strings are objects just like any other object.
They needed to be managed in the same way.
Rick
On Wed, Jun 26, 2013 at 2:41 PM, Rony G. Flatscher
rony.flatsc...@wu.ac.atwrote:
Thanks a lot, Rick!
Again, thank you very much for your explanations and answers!
---rony
Rony G. Flatscher (mobil/e)
Am 26.06.2013 um 20:46 schrieb Rick McGuire object.r...@gmail.com:
Yes, any long-lived contexts like this should be doing that sort of reference
management. Strings are objects just like any
