Singleton MFC Extension DLL
in [MFC]
|
From: Tom Serface on 7 Jan 2010 18:55 That works for me too Dave, although, most of the time I put it in the Input line under Linker properties. I know you can also link in libraries using a pragma as well. Like all this other stuff, there are too many ways to do the same thing ... Tom "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:#zcvpF$jKHA.1824(a)TK2MSFTNGP04.phx.gbl... > "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message > news:alqck591gias2lej7b560um35fus8qfq0i(a)4ax.com... >>>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. >> I never had that happen. I always had to manually add it or I would get >> undefined symbol >> errors. >> joe >> > > I don't know what to say. I've been doing it this way for years. I just > verified my .exe has Project Dependencies checkmark for a static lib, and > the static lib is not mentioned in the .exe's Project Properties | Linker > | Input | Additional Dependencies. > > -- David > >
From: Ajay Kalra on 8 Jan 2010 09:46 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. -- Ajay
From: Stephen Myers on 8 Jan 2010 09:50 MFDonadeli wrote: > With project dependencies, I can access all the classes and functions > on this DLL, and in the build line command the lib apper at the end of > the command. > > And I think that if project dependencies is wrong the solution that I > describe, wouldn't compile: > > In this case I can access the Singleton if I remove the variable > static CMySingleton* singleton and put on the Instance function like > this: > static CMySingleton* Instance() > { > static CMySingleton* singleton; > if(!singleton) > singleton = new CMySingleton(); > return singleton; > } > but the problem in this case, is that this function create another > instance of CMySingleton, even if static singleton var is already > initialized. Exactly when do you get the unresolved external link error? Is it with the DLL or when you try to reference the DLL? It looks like the problem is you have an inline class, apparently defined completely within the .h file. Where is CMySingleton* CMySingleton::singleton = NULL; This would usually be in MySingleton.cpp, and would be part of the regular dll you are creating. Is it? Steve
From: David Ching on 8 Jan 2010 11:26 "Ajay Kalra" <ajaykalra(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. -- David
From: Ajay Kalra on 8 Jan 2010 11:41
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 |