Sorry Przemek, I could not have read your changelog until after my post.
Tomorrow I see but... good work!. Thank you.
Best regards,
Xavi
Javier escribió:
Przemek,
IMHO: Yes, I think that it is better don't force the parameters to
string and more thinking of the HRB's power.
I also think that
Przemek,
IMHO: Yes, I think that it is better don't force the parameters to
string and more thinking of the HRB's power.
I also think that it is very good solution pHrb in collectible pointer:
very sure and avoid possibles memory leaks.
The only thing I dislike is having the new pHrbBodyGC of _
On Mon, 07 Jul 2008, Javier wrote:
Hi Javier,
> If I have understood well I agree with best solution is automatic
> destructors for pHrb type pointer and them automatic call hb_hrbUnLoad()
> when release, in other words, do you plan to convert pHrb in collectible
> pointer?
> pHrb := __hrbLoad
Hi Przemek,
If I have understood well I agree with best solution is automatic
destructors for pHrb type pointer and them automatic call hb_hrbUnLoad()
when release, in other words, do you plan to convert pHrb in collectible
pointer?
pHrb := __hrbLoad( cHrb ) // pHrb it's the unique instan
I positive vote also
- Messaggio originale -
Da: Szakáts Viktor <[EMAIL PROTECTED]>
Inviato: lunedi 7 luglio 2008 14.03
A: Harbour Project Main Developer List.
Oggetto: Re: [Harbour] Change in runner.c __HRBLOAD()
>> The problem is that __hrbLoad() return the pointer o
The problem is that __hrbLoad() return the pointer of hrb in the
stack
return not in the stack parameter frame.-
As you can see above it's not a problem but it forces that user have
to create additional hack. Storing pointers in parameters is also
such hack though done in different way inside
On Sun, 06 Jul 2008, Javier wrote:
Hi Javier,
> Sorry for my wrong explanation, my problem is that I costs less program it
> that write this post. :'(
> Please, see my Test() function if there is error in the init functions of
> hrb, __hrbLoad() returns a wrong pointer (normally nil) disabling
