MFC: Multi-threaded DLL Errors & Related Syntax :: C++

[kuphryn]

Hi.

I am studying MFC from Jeff Promise's book. I had problems compiling the first sample MFC program from Prosis because I need to set the project from "single-threaded" to "multi-threaded."

First, "multi-threaded" works, but the execute is huge, maybe five-folds from my biggest win32 console program with many more lines of code. The size of "multi-threaded" un debug mode was 1.5mb. There are less than 100 lines of code. I tried to set "multi-threaded" to "multi-threaded DLL," but then Visual C++ would not compile the source . It responded with a bunch of errors. Do I need to install anything before using the multi-threaded DLL mode?

How does MFC works as far as software release? Let say I give the MFC program to a friend. Will the friend be able to run it? Is MFC/C++ similar to Java and VB where the program comes require specific system DLL?

Lastly, Promise's book is exceptional because it touches everything about MFC. I found some MFC syntax that are not like C++ (or maybe it is just my inexperience). For example, some derived functions return "BOOL" and "TRUE." I know C++'s "bool" and "true." I replaced "TRUE" with "true," and that worked okay. However, Visual C++ came up with errors when I replaced "BOOL" with "bool." Are syntax like th ones above MFC specific and are required?

Kuphryn

 

[DaveSimmons]

<< First, "multi-threaded" works, but the execute is huge ... >>

debug build size doesn't matter, only release build size. But yes, MFC is a big framework and static linking it in does add 150 K or more to the size of your release build. It's a one time penalty though, since (for example) you only add the code for CString class once.



<< Do I need to install anything before using the multi-threaded DLL mode >>

when you installed VC++ you had a choice of which of the 4 libraries to install (single/mulit thread, static/dynamic). Perhaps you didn't install the dynamic multithreaded? You could try creating a new empty MFC project set to multi-threaded / shared library and then pasting in code.



<< Let say I give the MFC program to a friend. Will the friend be able to run it? Is MFC/C++ similar to Java and VB where the program comes require specific system DLL? >>

MFC apps only need the MFC runtime DLL if you choose shared/dynamic linking over static linking. Windows 98SE or newer will already have the DLL installed though.



<< For example, some derived functions return "BOOL" and "TRUE." >>

MFC is older than the C++ standard, so at the time Microsoft had to define their own BOOL and TRUE/FALSE. When using MFC you should use the Microsoft versions (which are typedefs and #defines) not the C++ ones which are "real" types and language constants.

Keep at it, it gets easier

 

[kuphryn]

Okay. Thanks.

First, I would really want to multi-thread using DLL (dynamically). I will post the errors as soon as I get access to the source at home.

One more question about MFC syntax. I learn from Deitel & Deitel to using "0" instead of "NULL." However, MFC uses "NULL" consistantly. Should I use "NULL" as Promise implements it?

Kuphryn

 

[kuphryn]

Okay. I tested two versions of multi-threaded DLL.

multi-threaded DLL (DEBUG): Here are the errors when I tried to compile.
----------
-----
Hello error LNK2001: unresolved external symbol ___argc
-----
Hello error LNK2001: unresolved external symbol ___argv
-----
Hello error LNK2001: unresolved external symbol __mbctype
-----
Hello error LNK2019: unresolved external symbol __mbctype referenced in function "public: void __thiscall CEditView::ReadFromArchive(class CArchive &,unsigned int)" (?ReadFromArchive@CEditView@@QAEXAAVCArchive@@I@Z)
-----
Hello error LNK2019: unresolved external symbol __mbctype referenced in function "void __stdcall AfxFormatStrings(class ATL::CStringT<char,class StrTraitMFC<char,class ATL::ChTraitsCRT<char> > > &,unsigned int,char const * const *,int)" (?AfxFormatStrings@@YGXAAV?$CStringT@DV?$StrTraitMFC@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@IPBQBDH@Z)
-----
Hello fatal error LNK1120: 3 unresolved externals
-----
----------

multi-threaded DLL: Here are the errors when I tried to compile.

----------
-----
Hello error LNK2001: unresolved external symbol ___argc
-----
Hello error LNK2001: unresolved external symbol ___argv
-----
Hello error LNK2001: unresolved external symbol __mbctype
-----
Hello error LNK2019: unresolved external symbol __mbctype referenced in function "public: void __thiscall CEditView::ReadFromArchive(class CArchive &,unsigned int)" (?ReadFromArchive@CEditView@@QAEXAAVCArchive@@I@Z)
-----
Hello error LNK2019: unresolved external symbol __mbctype referenced in function "void __stdcall AfxFormatStrings(class ATL::CStringT<char,class StrTraitMFC<char,class ATL::ChTraitsCRT<char> > > &,unsigned int,char const * const *,int)" (?AfxFormatStrings@@YGXAAV?$CStringT@DV?$StrTraitMFC@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@IPBQBDH@Z)
-----
Hello fatal error LNK1120: 3 unresolved externals
-----
Hello warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
-----
----------

I would like to compile MFC using multi-threaded DLL, thus making the program smaller.

Thanks,
Kuphryn

 

[DaveSimmons]

<< Should I use "NULL" as Promise implements it? >>

I think your intention is slightly clearer if using NULL instead of 0:
if (p != NULL) // I know p is a pointer
if (p != 0) // is p a pointer or number?

Why do D&D recommend using 0 instead? Portability?

 

[kuphryn]

I believe it has something to do with NULL being a Microsoft variable. I know it has something to do with Windows. I can look it up if you still want to know their exact explanation.

Kuphryn

 

[DaveSimmons]

<< multi-threaded DLL (DEBUG): Here are the errors when I tried to compile. >>

I think article Q166504 in online help (or msdn.microsoft.com) applies -- you have a mismatch between the MFC and CRT (C runtime) libraries. Easiest way to fix is to let the IDE put in the right switches by going to project > settings > C++ and switching the pulldown to "code generation". Look for the "use run-time library" box.

 

[DaveSimmons]

<< I believe it has something to do with NULL being a Microsoft variable. I know it has something to do with Windows. I can look it up if you still want to know their exact explanation. >>


Portability I suppose if you're thinking of moving between different OS's then using NULL might be a bad habit, but you can always add "#define NULL 0" to your linux code.

 

[kuphryn]

Yeah. Portibility.

I used NULL, but then I switched to 0. Now I am using 0.

Kuphryn

 

[singh]

I believe NULL is defined in stdlib.h -- a standard C++ header file. So I don't know why it would be a portability issue.