On Mon, 04 Jan 2010, Szak�ts Viktor wrote:
Hi,
> The only "problem" with valgrind is that it doesn't work
> on Windows, and most QT developers use Windows. Otherwise
> it's indeed the best tool.
And seems that such port is not even planed.
In BCC there is CodeGuard tool which you can also try to use
but I've never used it so I cannot help. Chen is our CG expert.
> I'm thinking of two solutions.
> 1) Add these override methods to HBQT. I fear that it will
> collide if we will have any other C++ libs in the pack.
Linker should detect it and report symbol collision if the same
operators are overloaded more then once by different code and
dependencies forces linking both versions so even if such problem
appears then it should be easy detected at link time.
> 2) Add an extra Harbour core lib named hbcpp (f.e.) and
> build that in forced C++ mode for all targets.
> This poses a problem when given target doesn't
> support C++ mode.
and because it's a lib then you will have to introduce mechanism
to force linking its module(s) with final application. Much more
flexible is compiled object file (.o|.obj) which can be linked
or not with final binaries. Anyhow it also needs some additional
modifications in other tools to create final elegant solution and
I do not know if it's worth of your time. Probably the simplest
modification to reach such effect locally without touching the
harbour build process is adding an option to hbmk2 to compile and
link with final application hbfm.cpp file. This file can be created
dynamically by hbmk2 or it can be added to our ./include directory.
The second version is easier for updating.
> > Alternatively we can try to use dlmalloc as full replacement for
> > standard malloc()/calloc()/realloc()/free() functions and report
> > info all memory blocks not freed after HVM exit. This is the most
> > often used method in different devel tools catching memory leaks.
> > To minimize number of modifications and keep our own FM logs we
> > can also use dlmalloc with USE_DL_PREFIX and create our own wrappers
> > to above functions, i.e.:
> > void * malloc( size_t size )
> > {
> > return hb_xalloc( size );
> > }
> > void * calloc( size_t size )
> > {
> > void * ptr = hb_xalloc( size );
> > if( ptr )
> > memset( ptr, 0, size );
> > return ptr;
> > }
> > [...]
> I can't oversee this solution, but for me it's good.
I'll check if I can implement it. Anyhow it may not work with compilers
which do not like overloading standard malloc()/free()/... functions so
not everywhere it will work.
> Next question: What to do now?
Full overloading of standard MM functions is one of options and I'll try
to add it but it's not be solution for all compilers so we should also
think about adding sth to only overload C++ new/delete operators.
See my answers for proposed by you 2 solutions and chose sth what you
think is the best and easiest to implement.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
