Hi,
> It's possible. Replacing default malloc()/free() functions have to be global.
> Some compilers may keep some hardcoded references to default memory manager
> and in such case they will crash when memory pointers from two different
> memory manager are mixed.
> In this case with HBQT you are introducing C++ RTL which may use it's own
> references to build in memory manager. It's possible that adding this code to
> one of HBQT CPP files will resolve the problem:
> void * operator new( size_t nSize ) { return hb_xgrab( nSize ); }
> void operator delete( void * p ) { hb_xfree( p ); }
> You can test it but it may also create new one if some code does not cleanly
> removes all allocated objects before HVM exit which may also deinitialize
> some other memory managers.
Yes, it is desirable to have as many as possible memory management calls in a
single HVM managements/statistics, if it is possible.
Taking into consideration that we are in releasing stage, this approach should
be postponed after release freezing taking into consideration that the testing
takes a relative long time and possible new issues generation.
I can mention here, that Qt collects in a single cpp the MM calls and offers in
this way for special builds, maybe for harbour, the malloc()/free() capture.
But this will be a future task, s I see now.
> Enabling USE_DL_PREFIX resolves any possible conflicts with C/C++ RTL
> though it's less efficient. But if current state creates real problems
> then we should change it and enable full memory manager replacement
> only on explicit user request by some macro, i.e. HB_FM_DL_PREFIX_OFF.
If it is a solution for the upcoming release, we should freeze our
possibilities related to the working default built for both MSC and MinGW too.
>> Or maybe there are some other approaches like HB_FM_STD_ALLOC macro
>> definition.
>It's rather inefficients memory manager so for many users it will be
>hard to accept it.
OK, I accept this.
Best regards,
István
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
