(revised, check 3rd post) Ok, here is the deal, I just recently created my own memory leak tracer and everything is working fine, HOWEVER, I have designed the memory leak tracer to be created as a class, "through an interface". Meaning that the real class is hidden, and is created and then returned as the interfaced. However, when doing this I found something which wasn't to my liking... MSVC (.NET 2005) seems to be overloading new/delete even in "sub-projects" (e.g, statically linked libraries, internally)... I've looked and looked, I guess I can understand why, but there must be some way to get rid of this behaviour? So that it only defines the new/delete for the project I've set it in? (ie, not exporting all functions by default to the .lib/.exe somehow?) [Edited by - Syranide on July 4, 2005 2:03:39 PM]

Apparently, there is no way around this.

However, there is *something* you can do in a single threaded environment... Along the lines of:



This defines two macros such that a function (SetLocation()) is called to track the allocations and deallocations when new and delete are called.

How is this helpful? Statically linked libraries will not include your macros. Hence, they will not call SetLocation(). Using this information, you can know which calls are made through your memory manager, and ignore the ones that are not (if SetLocation() wasn't called before new or delete, perform the operation, but disregard it in your memory-leak tracking).

Yeah sorry for beeing a little diffuse about my question... just came to mind.

Yeah, I already use that approach, HOWEVER, I've also overloaded the default new and delete as I can then have it track memory leaks (but no source) in ALL files in the project.

So, after some thinking, what my question really becomes is, is it possible to stop a function from being exported from the lib? (Such as a non-exported function in a DLL) With other words, no other projects can use that function within the LIB?

EDIT: in that way my "safe" operators won't be usable by some other project, and it would also be great as I could then make sure the other project cannot use some functions. (of course, if nothing works then I'll remove the safe operators, but it would be nice either way to be able to do that), or of course making it not available outside the current source-file, if that now is possible, preferable both if someone knows a solution.

Using namespace perhaps, would work in the libraries, but not in the main application I guess. Still I think really hiding them would be most valuable.

Well I don't know if its possible to disable that. I ran into the same problem, as you might have noticed from my other thread in this forum. The thing is that, the new and delete operators get overloaded everywhere because its their nature to be omnipresent, in a way. You *don't have* to include any header file to use new and delete. I agree, however, that its kind of lame to program an overloaded operator new, and to run into this kind of "exception to the rule", that everything you define is only accessible if the definition is included.

It might not let you define it into a namespace... And if it does, it might either not work as you expected, do the same thing as before, or result in a working solution in VC++ that will not work on another compiler. But its always worth a shot to try.

Hmm, truly seems so, well thanks for your help... I'll look into a little more and report if I come across anything (likely not).

EDIT: nope I give up