Singleton MFC Extension DLL
in [MFC]
|
From: Stephen Myers on 8 Jan 2010 13:13 Ajay Kalra wrote: > On Jan 8, 11:26 am, "David Ching" <d...(a)remove-this.dcsoft.com> wrote: >> "Ajay Kalra" <ajayka...(a)yahoo.com> wrote in message >> >> news:16c3c820-a9c7-49cb-99e6-31724452b1ac(a)j1g2000vbm.googlegroups.com... >> >>> On Jan 7, 4:41 pm, "David Ching" <d...(a)remove-this.dcsoft.com> wrote: >>>> Joe and the others are incorrect. Using Project Dependencies *does* in >>>> fact >>>> cause a link of the associated .lib file. You _do not_ have to add the >>>> .lib >>>> manually to the linker input. >>> Well.. Live and learn. I had no idea this even existed. Also, it >>> doesnt make much sense to me as you shouldnt have one project change >>> other project. In addition, this has side effect of not working if you >>> compile/link the project(which depends upon the lib) by itself. This >>> will work if solution itself is compiled. >> It works beautifully in this case. If your .lib changes and you rebuild the >> lib project only, the next time you build the .exe which depends on it it >> will see the .lib has changed and relink. It's even better. If you change >> a .cpp file in the .lib and rebuild the .exe, it will first build the .lib, >> then build the .exe. It's all as it should be. > > I agree that it works(I havent verfified it) but the behavior you > described is no different than if you explicitly put it the lib as on > the input libs. No? > > -- > Ajay My choice would be to add the .lib explicitly as a linker input, and use the project dependencies to force the build order. Using the project dependencies as an input moves some critical information from the project up into the solution. If you then try to use the project in a different solution, it will no longer link. Things get even worse if the new solution doesn't contain all of the dependent projects. We work with a couple of large solutions (100 projects or so), and it is frequently convenient to work with a subset. If all I have to do is Add Existing Project or Remove Project things are pretty easy. Having to go in and play with project dependencies is less fun. Steve
From: MFDonadeli on 8 Jan 2010 13:24 Steven and others, The CMySingleton is in "A" dll, which is a MFC Extension Dll. When I create a "B" dll (which is a Regular shared DLL) and I implements the CMySingleton class, all works fine. When I create "C" dll (which is a MFC Extension Dll) and I implements CMySingleton class, the unresolved external message shows up. I set the lib, via project dependencies (all A.lib is included on B and C projects, I see it via command-line in each project property) When I remove the private var and put it on Instance function, all works fine. What I can not understand is if C can use a var from A or cannot. I simply don't understand why the unresolved external error shows up. And Joe, if the dependencies does not work I cannot access CMySingleton even in "B" dll, can I? And I will try to explicit include the lib to see if the problem solves.
From: Joseph M. Newcomer on 8 Jan 2010 13:38 See below... On Fri, 8 Jan 2010 10:24:48 -0800 (PST), MFDonadeli <hworking(a)gmail.com> wrote: >Steven and others, > >The CMySingleton is in "A" dll, which is a MFC Extension Dll. > >When I create a "B" dll (which is a Regular shared DLL) and I >implements the CMySingleton class, all works fine. > >When I create "C" dll (which is a MFC Extension Dll) and I implements >CMySingleton class, the unresolved external message shows up. > >I set the lib, via project dependencies (all A.lib is included on B >and C projects, I see it via command-line in each project property) > >When I remove the private var and put it on Instance function, all >works fine. > >What I can not understand is if C can use a var from A or cannot. I >simply don't understand why the unresolved external error shows up. > >And Joe, if the dependencies does not work I cannot access >CMySingleton even in "B" dll, can I? **** If you cannot access the symbol, you should at least look at the depends analysis to see if the symbol is exported from the DLL. Note that the only place an instance of the singleton may be created is in the DLL that implements the singleton class. You may not under any conditions create private instances of the singleton in the clients of the DLL, because the DLL could have many clients. I look at dependencies entirely as a mechanism for dealing with build order. If CMySingleton is in "A", the only place that any code is allowed to exist that creates the instance, and the only place where the single instance variable may be, is in "A". Any other DLL is permitted to get a *pointer* to that one-and-only instance, but nobody else is permitted to have a variable that is implemented as the code you show. In particular, the local static variable you showed can only exist in a piece of code that is implemented in the DLL (and NOT in the header file!) "C" cannot implement the CMySIngleton class, because you already said that "A" implements the CMySingleton class, so I don't understand the statement that it implements the class. Either it is implemented by "A" or by "C", but it CANNOT be implemented by both, because it is supposed to be a singleton, which means it can have only one implementation and one instance. As I said earlier, when you start playing with singletons and DLLs, all the naive examples illustrated in C++ books become irrelevant. You must be extremely careful that exactly one DLL owns the one-and-only instance. This means that the ONLY variable that holds the "master pointer" to the instance must itself be in the DLL, and cannot be in a static declared in the header file or as a local in a method implemented in the header file. The naive examples always assume a single executable image, without any DLLs. joe **** > >And I will try to explicit include the lib to see if the problem >solves. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Ajay Kalra on 8 Jan 2010 13:44 > My choice would be to add the .lib explicitly as a linker input, and use > the project dependencies to force the build order. Thats how I would still prefer it. But I didnt know this was even possible. -- Ajay
From: Stephen Myers on 8 Jan 2010 13:49
MFDonadeli wrote: > Steven and others, > > The CMySingleton is in "A" dll, which is a MFC Extension Dll. > > When I create a "B" dll (which is a Regular shared DLL) and I > implements the CMySingleton class, all works fine. > > When I create "C" dll (which is a MFC Extension Dll) and I implements > CMySingleton class, the unresolved external message shows up. > > I set the lib, via project dependencies (all A.lib is included on B > and C projects, I see it via command-line in each project property) > > When I remove the private var and put it on Instance function, all > works fine. > > What I can not understand is if C can use a var from A or cannot. I > simply don't understand why the unresolved external error shows up. > > And Joe, if the dependencies does not work I cannot access > CMySingleton even in "B" dll, can I? > > And I will try to explicit include the lib to see if the problem > solves. I would expect the implementation of CMySingleTon to be completely within "A". This would include CMySingleton* CMySingleton::singleton = NULL; in MySingleton.cpp Does it? Steve |