>> 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.
Yes, I've read some text about this, it'd be too much work. > 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. Though QT doesn't support BCC, so it won't help us where it would be the most important ATM. >> 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. Good idea. I tend to favor the dynamic creation to not pollute our tree with such lose files, but I'll think about it some more. >>> [...] >> 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. Okay, I'll try to make something with hbfm.cpp. Here the problem I see is to decide when to add it and when not, probably there should be a new option to control that. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
