|
Hello,
I change project properties from Use of MFC- Use MFC in a shared DLL to
Use MFC in Static library, but size of application make it to large.
Use MFC in a Shared DLL - size is 50 KB
Use MFC in Static library - size is 500 KB
How can i create minimum size exe or is there any option.Abhijit
|
|
|
|
|
50K are less than 500, but 50K + the size of the MFC DLL are much more than 500!
If you don't want DLL dependency, static linking is a must.
If you want small sizes, welcome in the DLL hell!
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Abhijit D. Babar wrote: Use MFC in a Shared DLL - size is 50 KB
Use MFC in Static library - size is 500 KB
Unless you have strict requirements on the executable size (for instance if you need to send the executable on a slow line) such figures are irrelevant: whenever the executables becomes processes (i.e. are loaded by the OS) the amount of wasted memory is roughly the same.
On the other hand, if an efficient executable is needed, why are you using MFC? 
 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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
| you need to build a setup to install the MFC-Runtime. Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Sorry sir, i am not geting what you mean to say.
|
|
|
|
|
Goto build option, click on that for build tthe application, and goto debug option click 10 to execution, it will help to what happening in line by line
|
|
|
|
|
In addition to everything below, you need to make sure you don't use any Win32 APIs not in Windows 2000.
To do that you need the following #defines before you include any files in your stdafx.h:
#define _WIN32_WINNT 0x0500
#define WINVER 0x0500 Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
heyhey,
I have several projects that are dependent of each other with a lot of source and header files.
Like project: A<-B<-C<-D (B dependent of A, ...)
The projects themselves are each quite large and except one they all build static libraries (of course?). In each project I have a file called like ProjectCPrivate.h that I include from each header file from within project C. in this header actually only project B is referenced (and indirectly A) and some settings (defines) for the project itself. Also for each project I have a file like ProjectC which includes pretty much every class from project C, so that I can easily use this header file for project D and so on...
I'm facing long compile-times as the project grows. I'm not 100% sure if all this is solved by precompiled headers if used correctly. maybe my projects-design is lacking efficiency from the beginning. Using a precompiled header for each project would pretty much map the precompiled-header file to ProjectXPrivate.h, right?
What do you guys think? Thanks a lot in advance
zqueezy
|
|
|
|
|
You could try to use the /MP compiler switch for multiple copies of the compiler (cl.exe).
But this will not work with pre-compiled headers.
So you will have to disable pre-compiled headers.
Build with Multiple Processes[^]
|
|
|
|
|
zqueezy wrote: Using a precompiled header for each project would pretty much map the precompiled-header file to ProjectXPrivate.h, right?
you could also put all the standard C/C++ .H files in there (STL, stdio, windows.h, etc.). i just did that last night for a 12-project solution - all the non-project includes went into the PCH, along with anything that would cause a full (or near full) rebuild anyway. seems to have sped-up the build a bit. it wasn't a huge difference, however.
|
|
|
|
|
zqueezy wrote: I have a file called like ProjectCPrivate.h that I include from each header file from within project C
Sounds like you're coupling the external interface of each 'Project C' to the internal interface - that's probably something to minimise, otherwise changes to that internal interface will require rebuilding of the whole system that's upstream of it.
That should help when doing incremental builds. As for full builds...well, I've never found that the number of include files is much of a problem - it's the total amount of source code needing to be built...Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
I have a struct similar to the following:
template<int i>
struct foo {
public:
static const int a;
static const int b;
};
template<>
const int foo<3>::a = 1;
template<>
const int foo<5>::a = 2;
template<int i>
const int foo<i>::b = 3 * foo<i>::a;Then, I attempted to execute the following:
#include <iostream>
#include "foo.h"
using namespace std;
int main() {
cout << foo<3>::b << endl << foo<5>::b << endl;
return 0;
}The first time I ran this code, the code produced the result b=0 for both template instantiations, but at the time I was declaring static member b prior to a. Next, I switched the order of declaration thinking that perhaps static members are initialized in the order they are declared, just like instance members. Again, the code produced 0 for the value of static member b in both template instantiations. Then, I added a cout statement prior to the one presented in the code above to print the value of a when the template parameter i=3. This time, the output was correct and gave b=3 when i=3 and b=6 when i=5. Since then, I have been unable to get my code to break, but think there is some static initialization problem that could be lurking. Does anyone know why this happened, and how I can address it?
I am also wondering how I can move the static member initialization code out of the header file where class foo is declared. I was able to move the initialization of static member a to whatever compilation unit I wanted, but when I moved initialization of b to the other compilation unit I started receiving unresolved external linker errors. Thanks,Sounds like somebody's got a case of the Mondays
-Jeff
modified on Thursday, February 11, 2010 3:50 PM
|
|
|
|
|
| What compiler are you using? When using VS2008, your initial code works fine...I suspect VC++ compiler issues - there are lots of thm with regard to templates... Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
| I am using Visual Studio 2008. I think I found my error... when I move the template-specialized definition of foo::a to a different compilation unit, I get unexpected results. Some of my data members declared exactly like foo::b are populated with the correct values dependent on foo::a, while others are being incorrectly initialized to 0. I guess I just don't know the rules for static initialization. Is it performed in the order of declaration, order of definition, or in the order of first access? Thanks, Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
Templates complicate the rules, I suspect…
Not sure - the C++ Standard is the ultimate arbiter.Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
Skippums wrote: when I move the template-specialized definition of foo::a to a different compilation unit, I get unexpected results
Beware of the fact that compiler may remove code that's not referenced, as linker may skip linking of non called modules.
If you define the static-s in a separate translation unit, make sure that there is some code in that translation unit that is called from outside, or the linker may skip the module.
A typical way is to define a void init_mymodule(){}
or a class raii_module_loader { ctor; dtor; };, with ctor and dtor defined in the module (not the header) and make sure at global level in the main() definition file, the function is called, or the raii_module_loader is globally instantiated.
This force the module code to be called and hence the module to be linked.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
| Got it... apparently it is dependent on the order of declaration, just like non-static members. Thanks, Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
|
tell me proper way to add an item to ListCtrl.
Here is my code:-
#define WM_MYMESSAGE (WM_USER+1)
-------------------------------------------------------
class CMyThread : public CWinThread
{
DECLARE_DYNCREATE(CMyThread)
.
.
.
public:
unsigned int f0ll, f1ll, f2ll, f3ll;
unsigned int f0ul, f1ul, f2ul, f3ul;
public:
afx_msg void MyMessageHandler(WPARAM, LPARAM);
-------------------------------------------------------
.
.
.
afx_msg void CMyThread::MyMessageHandler(WPARAM, LPARAM)
{
}
BEGIN_MESSAGE_MAP(CMyThread, CWinThread)
ON_THREAD_MESSAGE(WM_MYMESSAGE, MyMessageHandler)
END_MESSAGE_MAP()
-------------------------------------------------------
.
.
.
void CIPMDlg::OnBnClickedBrefreshdevices()
{
.
.
.
pRefreshThread = AfxBeginThread(RUNTIME_CLASS(CMyThread));
pRefreshThread->PostThreadMessage(WM_MYMESSAGE, 0, 0);
}Future Lies in Present.
Manmohan Bishnoi
|
|
|
|
|
If "MyThread" is not the thread that owns the ListCtrl, then you will have problems.
You must add items to the ListCtrl only from the thread that created the ListCtrl.
|
|
|
|
|
CIPMDlg class created the ListCtrl
should I post a message back to the main thread's message pump to add item to ListCtrlFuture Lies in Present.
Manmohan Bishnoi
|
|
|
|
|
Manmohan29 wrote: should I post a message back to the main thread's message pump to add item to ListCtrl
Yes."One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I need to find out (in a release version) how much memory has been allocated after loading (a large) object - the object itself is loaded by a DLL (if that's relevant). I am looking at GlobalMemoryStatus but not sure sure which properties I should use to get accurate information...
Help welcome!
Jerry
|
|
|
|
|
Hi,
I am starting a project where in I have a dual monitor setup for shown objects.My project involves showing squares, circles, lines on the screen. I use the primary monitor to control the attributes and the second monitor solely for display. I have issues setting up these two windows/frames; one in each monitor using MFC app wizard. I am at loss as to which model I should use: SDI or MDI. Any ideas, pointers to existing projects, directions are more than welcome..
rgds,
-K
|
|
|
|
|
As a final user, in general I hate when an application want to decide itself how to set the the spaces into my desktop.
Unless you are in a very captive environment (PC running your application only, may be on a synoptic etc.), the best way is to operate on two different frames and let the user to decide where those frames must go and how they have to be sized.
What you can do is save the frames positions (may be in registry, or in a "state file", into the user data directory) so that they can be placed the same among different invocations.
Using SDI or MDI is than much more a matter of the complexity of the frames content, than the fact there are two of them.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
