www.digitalmars.com         C & C++   DMDScript  

c++.mfc - Building MFC

reply Chris Widdows <chris widdows.demon.nl> writes:
Hi,

I've started to try to get the default MFC source included with DM
building. Note that is not the MFC/ATL stuff on the web site. So far
the libs seem to build but I'm getting quite few warnings. On that
raises it head a lot is a warning "value of expression is not used",
which is for a line containing just "CATCH_ALL(e)".

I'm compiling with just very few defines _UNICODE, _WIN32 and
_WINDOWS. 

To those more experienced with building MFC, is this normal? Am I
missing any important define?

Chris
Apr 03 2002
next sibling parent Jan Knepper <jan smartsoft.cc> writes:
Chris Widdows wrote:


 Hi,

 I've started to try to get the default MFC source included with DM
 building. Note that is not the MFC/ATL stuff on the web site. So far
 the libs seem to build but I'm getting quite few warnings. On that
 raises it head a lot is a warning "value of expression is not used",
 which is for a line containing just "CATCH_ALL(e)".

 I'm compiling with just very few defines _UNICODE, _WIN32 and
 _WINDOWS.

 To those more experienced with building MFC, is this normal? Am I
 missing any important define?



This is normal AFAIK.

Jan
Apr 03 2002
prev sibling parent reply Chris Widdows <chris widdows.demon.nl> writes:
To add to that, I've found that defining _DEBUG will break the
compilation. When building the nafxcwd.prj the build fails as:

sc ..\arccore.cpp -cpp -Ae -mn -C -D_WINDOWS -S -3 -a8 -c -g -D_DEBUG
-D_WIN32 -D_MBCS=1 -I\dev\dm\mfcn\include
-o\dev\dm\mfcn\nafxcwd\arccore.obj 
Error: C:\Dev\dm\MFCN\SRC\32-BIT\PROJECTS\..\arccore.cpp(416): no
match for function '?_P(unsigned ,char *,int )'
Lines Processed: 176565  Errors: 1  Warnings: 0
Build failed
 
The source code line is 
	m_lpBufStart = new BYTE[m_nBufSize];

Something has gone wrong with the redefinition of new,  which I can
only find in afx.h, line 1646. Seems ok to me, what am I missing here.

Chris
Apr 03 2002
next sibling parent Chris Widdows <chris widdows.demon.nl> writes:
On Wed, 03 Apr 2002 15:06:32 +0200, Chris Widdows
<chris widdows.demon.nl> wrote:

Since then I have found that it is only the new[] that gives problems,
normal new's do compile.

Chris.


To add to that, I've found that defining _DEBUG will break the
compilation. When building the nafxcwd.prj the build fails as:

sc ..\arccore.cpp -cpp -Ae -mn -C -D_WINDOWS -S -3 -a8 -c -g -D_DEBUG
-D_WIN32 -D_MBCS=1 -I\dev\dm\mfcn\include
-o\dev\dm\mfcn\nafxcwd\arccore.obj 
Error: C:\Dev\dm\MFCN\SRC\32-BIT\PROJECTS\..\arccore.cpp(416): no
match for function '?_P(unsigned ,char *,int )'
Lines Processed: 176565  Errors: 1  Warnings: 0
Build failed
 
The source code line is 
	m_lpBufStart = new BYTE[m_nBufSize];

Something has gone wrong with the redefinition of new,  which I can
only find in afx.h, line 1646. Seems ok to me, what am I missing here.

Chris
Apr 03 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
One thing that has changed is array new[] overloading is now supported by
default. This sounds likely to be the culprit.

"Chris Widdows" <chris widdows.demon.nl> wrote in message
news:noqlaucrjrap9v6kvb1ev8eg6dmq4gdlie 4ax.com...

 To add to that, I've found that defining _DEBUG will break the
 compilation. When building the nafxcwd.prj the build fails as:

 sc ..\arccore.cpp -cpp -Ae -mn -C -D_WINDOWS -S -3 -a8 -c -g -D_DEBUG
 -D_WIN32 -D_MBCS=1 -I\dev\dm\mfcn\include
 -o\dev\dm\mfcn\nafxcwd\arccore.obj
 Error: C:\Dev\dm\MFCN\SRC\32-BIT\PROJECTS\..\arccore.cpp(416): no
 match for function '?_P(unsigned ,char *,int )'
 Lines Processed: 176565  Errors: 1  Warnings: 0
 Build failed

 The source code line is
 m_lpBufStart = new BYTE[m_nBufSize];

 Something has gone wrong with the redefinition of new,  which I can
 only find in afx.h, line 1646. Seems ok to me, what am I missing here.

 Chris
Apr 03 2002
parent reply Chris Widdows <chris widdows.demon.nl> writes:
On Wed, 3 Apr 2002 22:47:51 -0800, "Walter" <walter digitalmars.com>
wrote:


One thing that has changed is array new[] overloading is now supported by
default. This sounds likely to be the culprit.



quite possibly, the code I looked at seems to expect the new[] to get
back to the 'regular' new somehow. Do you imply that -Aa is always on?
Does the setting in the IDDE do anything (I tried switching it on/off
in the IDDE and that didn't help)? Should I use -Aa- ?

I also saw -Aw to enable wchar_t as a built-in type, curious, how does
this relate the wchar_t alias pragma?

Chris
Apr 04 2002
parent reply "Walter" <walter digitalmars.com> writes:
-Aa is always on now. Unfortunately, -Aa- won't turn it off. Perhaps I
should add that functionality. -Walter

"Chris Widdows" <chris widdows.demon.nl> wrote in message
news:rl1oauckn3cpeocija61283chl0psrq0s6 4ax.com...

 On Wed, 3 Apr 2002 22:47:51 -0800, "Walter" <walter digitalmars.com>
 wrote:


One thing that has changed is array new[] overloading is now supported by
default. This sounds likely to be the culprit.



 quite possibly, the code I looked at seems to expect the new[] to get
 back to the 'regular' new somehow. Do you imply that -Aa is always on?
 Does the setting in the IDDE do anything (I tried switching it on/off
 in the IDDE and that didn't help)? Should I use -Aa- ?

 I also saw -Aw to enable wchar_t as a built-in type, curious, how does
 this relate the wchar_t alias pragma?

 Chris
Apr 04 2002
parent Chris Widdows <chris widdows.demon.nl> writes:
On Thu, 4 Apr 2002 22:39:00 -0800, "Walter" <walter digitalmars.com>
wrote:


-Aa is always on now. Unfortunately, -Aa- won't turn it off. Perhaps I
should add that functionality. -Walter



I've sent some patches to MFC to help compilation, so perhaps you
won't have to.

Chris
Apr 05 2002