Sign in to follow this  
Syranide

How to prevent function to be exported outside LIB (changed) (C++)

Recommended Posts

(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]

Share this post


Link to post
Share on other sites
Apparently, there is no way around this.

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

#define new (SetLocation(__FILE__, __LINE__, __FUNCTION), false)? NULL: new
#define delete (SetLocation(__FILE__, __LINE__, __FUNCTION), false)? NULL: delete


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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this