C / C++ / MFC

13-Mar-07 4:41

Hi all,

This might be a stupid question(s) but here goes:
Does a registered dll stay in memory?
And does a dll that doesn't need registered stay in memory?

Thanx in advance.
Regards,

The only programmers that are better than C programmers are those who code in 1's and 0's..... Smile | :)

Programm3r
My Blog: ^_^

CPallini13-Mar-07 4:53

CPallini

13-Mar-07 4:53

Naively, all kind of DLLs (registered and unregistered ones) are loaded in memory by the OS loader when a process needs to get linked with.

Standard DLLs (such as User32.dll) don't need registration, registration is required only by COM DLLs.

Hope that helps.
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

Programm3r13-Mar-07 4:58

13-Mar-07 4:58

CPallini wrote:
Hope that helps.

CPallini, yes it does help, thank you very much. But the other thing is after the function call will the dll still reside in memory? (Registered and those who don't need registration)

Thanx for your reply.
Regards,

The only programmers that are better than C programmers are those who code in 1's and 0's..... Smile | :)

Programm3r
My Blog: ^_^

Cedric Moonen13-Mar-07 5:02

Cedric Moonen

13-Mar-07 5:02

Programm3r wrote:
But the other thing is after the function call will the dll still reside in memory? (Registered and those who don't need registration)

Which function call ?

In fact, you have two ways to load your dll. Either explicitely (by using LoadLibrary) or implicitely (you link to a library provided with the dll that contains information about how to load the dll's).
In the first case, the Dll is loaded when you call LoadLibrary and is released when you call FreeLibrary (if there is no other application that uses it). Or it is released when your application exits.
In the second case, the dll is loaded when your application is started an is released when your application terminates.

Cédric Moonen
Software developer

Charting control [v1.1]

Programm3r13-Mar-07 5:20

13-Mar-07 5:20

Cedric Moonen wrote:
Which function call ?

Thanx Cédric, you have already answered my question in your thread.
Regards,

The only programmers that are better than C programmers are those who code in 1's and 0's..... Smile | :)

Programm3r
My Blog: ^_^

Roger Stoltz13-Mar-07 5:10

Roger Stoltz

13-Mar-07 5:10

Registration of a DLL has nothing to do with when the DLL is loaded into the address space of the process that uses the DLL. Registration of a DLL is only needed if the DLL exposes a function called DllRegisterServer which usually is only applicable for COM DLLs.

Read more about DLL loading here[^].

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

Programm3r13-Mar-07 5:22

13-Mar-07 5:22

Thank you very much Roger.

Regards,

The only programmers that are better than C programmers are those who code in 1's and 0's..... Smile | :)

Programm3r
My Blog: ^_^

CPallini13-Mar-07 5:16

CPallini

13-Mar-07 5:16

Programm3r wrote:
But the other thing is after the function call will the dll still reside in memory?

Oh YES, of course...

The OS loader may discard the DLL if the process detaches from. For an ordinary DLL, if the process implicitely links with (e.g. you have used the DLL's *.lib as input for the LINKER; this is the most common way...) the detaching happens on process termination; on the other hand, if the process explicitely links with (via LoadLibrary call), then the process can, at any time, discard the library by means of the corrensponding FreeLibrary call.

COM uses a completely different approach, a component DLL may be discarded by the COM when the component it's no more needed, i.e. when the reference count of the component reaches 0 (see life cycle of COM components in MSDN, however, basically, calling Release() on a COM pointer, allows COM to discard the related DLL).

Hope that helps
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

Programm3r13-Mar-07 5:23

13-Mar-07 5:23

Thank sfor your help CPallini, really appreciate it.

Regards,

The only programmers that are better than C programmers are those who code in 1's and 0's..... Smile | :)

Programm3r
My Blog: ^_^

you're welcome.

CPallini13-Mar-07 6:10

CPallini

13-Mar-07 6:10

you're welcome.
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

Eytukan13-Mar-07 6:59

Eytukan

13-Mar-07 6:59

Now tell me an MFCxx.dll is a COM dll or a standard DLL? Roll eyes | :rolleyes:

Press: 1500 to 2,200 messages in just 6 days? How's that possible sir?
Dr.Brad :Well,I just replied to everything Graus did and then argued with Negus for a bit.

toxcct13-Mar-07 8:01

toxcct

13-Mar-07 8:01

VuNic wrote:
Now tell me an MFCxx.dll is a COM dll or a standard DLL?

none. you have to provide it with your application binary, or place it in the path...

[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]

Eytukan13-Mar-07 16:59

Eytukan

13-Mar-07 16:59

That's what a standard win32 dll dear.

Press: 1500 to 2,200 messages in just 6 days? How's that possible sir?
Dr.Brad :Well,I just replied to everything Graus did and then argued with Negus for a bit.

Save struct to right map?

ThatsAlok15-Mar-07 1:47

ThatsAlok

15-Mar-07 1:47

VuNic wrote:

That's what a standard win32 dll dear.

he he he

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

cheers,
Alok Gupta
Global Interface Table: An Easy Way to Marshal an Interface Pointer[new]
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You

bosfan13-Mar-07 4:40

bosfan

13-Mar-07 4:40

Hello comunity,
i try to save a struct variables to a map!
Simple struct with some CStrings as member!
Which one(Map) to use for that: CMapStringToOb, CMapStringToPtr, CMapWordToPtr?

regards
break;

Maximilien13-Mar-07 4:51

Maximilien

13-Mar-07 4:51

in the context of MFC, I would use CMapStringToPtr or CMapWordToPtr depending on the key.

but I strongly suggest you start using STL and std::map.

Maximilien Lincourt
Your Head A Splode - Strong Bad

Roger Stoltz13-Mar-07 5:01

Roger Stoltz

13-Mar-07 5:01

Maximilien wrote:
I strongly suggest you start using STL and std::map

I second that.
MFC also has a template version called CMap which works similar to std::map. Haven't tried it though since I prefer the STL version.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

bob1697213-Mar-07 7:12

bob16972

13-Mar-07 7:12

I thought CMap used a hash table and thus was similar to the non-standard hash_map as opposed to std::map.

std::map does not (as far as I know) provide constant average lookup times where CMap does. This would, in my opinion, indicate that std::map is not a good substitute (as far as performance is concerned) for CMap.

This is the main reason I still use CMap, at least until the new "standard" version of hash_map finally gets fully approved.

Maybe I'm missing something so correct me if that's incorrect

Roger Stoltz13-Mar-07 22:55

Roger Stoltz

13-Mar-07 22:55

Regarding the performance issue you're probably right, but I cannot verify this since, like I said, I haven't used CMap very much. Whether this performance boost is necessary or not would depend on how the map is used and how frequently elements have to be looked up.

I prefer the STL version due to portability reasons, CMap only exists in MFC library.
If I e.g. develop software in C++ aimed for an embedded system I wouldn't find CMap in that environment. So if I know how to use the STL library I can write more portable code.
If the std::map implementation becomes a performance issue I will first re-evaluate my design and if I find the design to be allright I probably will write my own mapping container using a hash table or similar.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

bob1697214-Mar-07 5:05

bob16972

14-Mar-07 5:05

Roger Stoltz wrote:
So if I know how to use the STL library I can write more portable code

Fair enough. I would agree that the portability issue is a big one. I hesitated to use hash_map only because of all the warnings about each library implementing slightly different variations of it and the fact that the "standard" extension for it will likely be of a different name. I'd hate to learn a specific library only to have to change once again when the standard was ratified.

I'm stuck in a windows only OS environment so the MFC's portability issues have been non-existent but I keep forgetting that's not the case for everyone.

Anyway, I'm constantly struggling to understand it all and I posted the comment out of fear that I may have missed something between std::map, hash_map, and CMap. My main concern was the comparison between std::map and CMap since, as far as I know, std::map does not use a hashing table and thus the similarities are not enough to consider one a direct replacement for the other. CMap and hash_map appear, at first glance, to be closer.

One of these years this stuff may all finally make some sense to me. Wink | ;)