Newsgroups: comp.os.ms-windows.misc
Path: cantaloupe.srv.cs.cmu.edu!magnesium.club.cc.cmu.edu!news.sei.cmu.edu!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!network.ucsd.edu!news.cerf.net!pagesat!spssig.spss.com!ralph
From: ralph@spss.com (Ralph Brendler)
Subject: Re: Using Microsoft Foundation Classes with Borland C++ 3.1
Message-ID: <C5r3CH.635@spss.com>
Sender: news@spss.com (SuperUser(IG))
Organization: SPSS, Inc.
References: <ivarC5Hrw4.82H@netcom.com> <1qv1rc$fcp@news.cs.tu-berlin.de>
Distribution: usa
Date: Mon, 19 Apr 1993 21:50:39 GMT
Lines: 53

In article <1qv1rc$fcp@news.cs.tu-berlin.de>, make@cs.tu-berlin.de (M. Kerkhoff) writes:
> Hi all,
> 
> has anybody tried to compile CTRLTEST from the MFC/SAMPLES directory,
> after compiling the MFC-libs with BWC ?
> 
> Seems to me, that BWC isn't able to distinguish pointers to overloaded
> functions.
> For example, imagine the following 2 (overloaded) functions:
> void same_name ( void ) 
> void same_name ( int )
>  
> After trying the whole day, I think, with BWC its impossible to take the
> adress of one of the above two functions and assign it to a properly defined
> function pointer. 
> Am I right ? Has anybody else had this problem ?
> 
> 	thanx

I think you may be chasing the wrong problem.  I don't think it is the
function overloading at all-- I do that sort of thing all of the time
in BC++ without a hitch.  The big problems I have encountered in
porting MFC to BC++ is that fact that MFC _depends_ on a couple of
invalid C++ assumptions.

I have never gotten the _entire_ ctrltest app to run under BC++, but
the reason is that MS makes some bad assumptions about the order in
which static/global objects are initialized (i.e. some objects are
getting accessed before they are initialized).  The problem is in the
owner-draw menu code somewhere-- if you comment out that section, all
other pieces of ctrltest work fine.

Two other major gotchas I have found using MFC under BC++:

- The CFile::OpenFlags enum uses hard-coded numbers for the open mode,
  rather than the manifest constants defined in fcntrl.h (which differ
  between MSC and BC).

- All of the MFC collection classes depend on another bad C++
  assumption-- that a reference to a base object can used be in place
  of a reference to a derived object (true for pointers, NOT for
  references).

I am sure there are other problems along the same lines, but I have
not encountered them (yet).  I have not seen MFC 2.0 yet, but I hope
that some of these will be addressed.  If they are not, all of MS's
hype about portability to other vendor's compilers will be just that.

-- 
      If these were my employer's opinions, I wouldn't be posting them.
###############################################################################
  "Whoever said nothing lasts forever was obviously  # R. Brendler
   NOT a Cubs fan..." - Mike Royko                   # SPSS, Inc. - Chicago IL
