Prev: Rational Robot Isnot Recognising MFC object
Next: Please use wxWidgets
From: MFDonadeli on 8 Jan 2010 14:22
Joe and all,

Thank you for all the responses.

When I said that I implement CMySingleton in "A" and "C", what I want
to say is that the implementation is in "A" and in "B" and "C" I
implement instances of CMySingleton like this: CMySingleton* var =
CMySingleton::Instance();

CMySingleton is a example of the need of usage for a class that I need
to use in "B" and in "C". In this case CMySingleton is a class for a
floating Message Window for Windows Mobile system. So I want to code
this class in a DLL which only exports functions for other Dlls and
the main app, so I choose a MFC Extension Dll for this end.

I found the the solution:
I change getInstance implementation to .cpp file and the build works
well.
I think that solution works because I use .cpp file and .h file in
differents directories.

Thank you for help.
From: David Ching on 8 Jan 2010 19:10
"Ajay Kalra" <ajaykalra(a)yahoo.com> wrote in message
news:748dd6f5-c20b-4c0f-b235-478a1b26990e(a)w12g2000vbj.googlegroups.com...
>> 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?
>

It's different in the case where you change a .cpp file in the .lib and then
build your .exe. If the .exe doesn't have a project dependency on the .lib
(but just has the .lib on the linker line), then building the .exe will
erroneously not build the .lib first. However, if the .exe does have a
project dependency on the .lib, then the .lib will be built before the .exe.
So having the project dependency helps when you are actively editing the
dependent modules like the .lib simultaneously with the caller of it like
the .exe. Sometimes this is done quite often, so project dependencies
really simplify things. Really, the concept of the .sln is incomplete
without the additional concept of project dependencies because without that,
Build Solution really has no meaning. For one thing, the dependencies
define the build order of the solution so that the module with no
dependencies on the rest of the solution is built first.

I can see where like Stephen says it makes the .sln file a key player such
that .vcproj files are not standalone anymore, so in this case it is also
helpful to put the .lib in the linker line also. But most of my projects
are small such that I only use one .sln, and for me, adding the .lib to the
linker line is superfluous. Regardless, the proper Project Dependencies
must be set up.

-- David

From: Ajay Kalra on 8 Jan 2010 19:53
On Jan 8, 7:10 pm, "David Ching" <d...(a)remove-this.dcsoft.com> wrote:
>
> It's different in the case where you change a .cpp file in the .lib and then
> build your .exe.  If the .exe doesn't have a project dependency on the ..lib
> (but just has the .lib on the linker line), then building the .exe will
> erroneously not build the .lib first.  

I see what you are saying but why would anyone do it this way(not
having build order). I never checked that box and had a problem with
this, mainly because I had specified build order in addition to having
a .lib on the linker line. This has worked forever. A change in any
module trickles thru all the projects that it links the changed
project.

It could be that we are talking about the same thing as I havent used
VC++ for a very long time and I recall using Project Dependencies tab
for each project. However I always specified the lib in linker tab.
This was carry over from VC6 days. Its possible that specifying on
linker tab was redundant at that time (but I doubt it), as I got
errors if I didnt specify it.


> For one thing, the dependencies
> define the build order of the solution so that the module with no
> dependencies on the rest of the solution is built first.

It looks like we are talking about the same thing. I *always* used it
but also specified the libs on linker tab. Keep in mind that project
dependcies are not necessarlily used for linking purposes. Our COM
servers needed to be built first followed by other modules. A post
build step took care of the rest.

We didnt use Project Dependencies for the purpose of using updated
linked libraries. It was always explicit. I would still do it this
way. Its simple and clear to everyone. In a large project, with 100s
of users accessing it, it matters. Nothing wrong with the strategy
that you mentioned.

--
Ajay
From: David Ching on 8 Jan 2010 21:19
"Ajay Kalra" <ajaykalra(a)yahoo.com> wrote in message
news:b88cebfe-6c4c-4255-b562-1c55c1ac58cc(a)z7g2000vbl.googlegroups.com...
> It looks like we are talking about the same thing. I *always* used it
> but also specified the libs on linker tab.

I see, yes we are talking about the same thing. When I found out that
checking the box in Project Dependencies made specifying the .lib in the
linker line unnecessary, I stopped adding it, but I certainly can see for
non-trivial cases it would be valuable to still add it. I actually had an
issue where my .exe was dependent on the .dll but I did not want to
staticallly link to it because I did not want it loaded on startup because
the DLL required a specific version of Windows or later, and it would fail
to load if the .exe was run on an earlier version of Windows. (The .exe
checked the Windows version and only loaded the DLL via LoadLibrary if the
version was recent enough to support the DLL. [*]) In this case, there is a
handy setting "Ignore Import library" in the Linker settings that cause the
..lib *not* to be linked in automatically to the .exe (or other projects
dependent on the .dll). I believe the similar setting for static libs is
"Link Library Settings" in the Librarian settings. (These are for VS2005.)

---
[*] An easier way to avoid the DLL issue would have been to use delay-load
DLL's which cause the DLL not to be loaded until the first call to it. If
the .exe determines the Windows does not support the DLL, the .exe just
jumps over the code that would call its functions and the DLL would never be
loaded. But delay-loading a DLL requires delayload.lib (or something like
that) to be linked into the .exe which added some bloat to the .exe size
which in my case was not desireable. So I did it the hard way.


Thanks,
David

From: Ajay Kalra on 8 Jan 2010 21:44
> but I did not want to staticallly link

Theres that word again :-) We never used static link.. perhaps thats a
reason?

> [*] An easier way to avoid the DLL issue would have been to use delay-load
> DLL's which cause the DLL not to be loaded until the first call to it.  If
> the .exe determines the Windows does not support the DLL, the .exe just
> jumps over the code that would call its functions and the DLL would never be
> loaded.  But delay-loading a DLL requires delayload.lib (or something like
> that) to be linked into the .exe which added some bloat to the .exe size
> which in my case was not desireable.  So I did it the hard way.

I did use DelayLoading successfully(based on Richter's article in 1996
(?)) and it really worked fine. Too bad it didnt go in the final
product. We wanted to have document DLLs loaded on demand as most
users used only a few types of docs. Good old days..

--
Ajay
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: Rational Robot Isnot Recognising MFC object
Next: Please use wxWidgets