home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / mswindo / programm / tools / 695 < prev    next >
Encoding:
Text File  |  1992-08-12  |  3.2 KB  |  73 lines
  1. Newsgroups: comp.os.ms-windows.programmer.tools
  2. Path: sparky!uunet!microsoft!wingnut!stevesi
  3. From: stevesi@microsoft.com (Steven Sinofsky)
  4. Subject: Re: borland c++ and microsoft c/c++
  5. Message-ID: <1992Aug12.193916.17762@microsoft.com>
  6. Date: 12 Aug 92 19:39:16 GMT
  7. Organization: Microsoft Corporation
  8. References: <Bsqpr9.EqH@apollo.hp.com> <1992Aug10.171802.18367@nntpd.lkg.dec.com> <pathak-100892175041@virtual.mitre.org>
  9. Lines: 60
  10.  
  11. In article <pathak-100892175041@virtual.mitre.org> pathak@mitre.org (Heeren Pathak) writes:
  12. >In article <1992Aug10.171802.18367@nntpd.lkg.dec.com>,
  13. >feldman@toklas.enet.dec.com (Gary Feldman) wrote:
  14. >> 
  15. >> I'm just starting to look at compilers and windows programming (for myself).
  16. >> One thing that struck me was that Borland appears to have added a non-standard 
  17. >> C++ extension, to bind messages to member functions (the "= [WM_FIRST + mesage]"
  18. >> construct).  It seems like a nifty idea, but if you use it, doesn't it lock
  19. >> you into buying compilers from Borland?  
  20. >> 
  21. >
  22. >From what I understand, Borland's extensions are being debated by the ANSI
  23. >committee and may actually become part of the standard.
  24.  
  25. To the best of my knowledge and after checking with several representatives
  26. on the ANSI XJ316 (the C++) committee, the Borland extension has not been
  27. proposed, let alone debated by the XJ316 folks.
  28.  
  29.  
  30. >
  31. >> As I said, I'm just getting started, and it's difficult making my way through
  32. >> all the documentation.  So it's possible I've got this wrong.
  33. >> 
  34. >
  35. >Microsoft uses a different non-standard mechanism.  Granted, their
  36. >mechanism is handled by a preprocessor but it is still non-standard.  In
  37. >reality, I don't see a big difference either way.
  38.  
  39. Microsoft does not use a language extension, everything that is used
  40. for the message routing is standard ANSI C++.  MFC will compile with
  41. BCC 3.1.
  42.  
  43. >
  44. >Personally, I have had very good experiences as a Borland customer and no
  45. >so good experiences as a Microsoft customer.  However from what I have read
  46. >recently, the Microsoft complier has improved considerably (I haven't used
  47. >a Microsoft complier for several years now).  
  48. >
  49. >Comparing class libraries, I prefer the Borland class library.  While it
  50. >doesn't cover the entire Windows API, the sections it does cover contain a
  51. >much higher level of abstraction the Microsoft Foundation Classes.  When I
  52. >looked at the MFC a month or two ago, I wasn't impressed.  Most of the MFC
  53. >seems to be a wrapper around Windows function calls.  While this is great
  54. >for those who already know Windows and are porting their code, I am
  55. >doubtful that the MFC will provide the flexiblity that a well designed
  56. >Object-Oriented Application Framework provides.  
  57. >
  58.  
  59. OWL and MFC provide nearly identical functionality in almost every
  60. area.  MFC provides substantial abstraction in the areas of OLE, custom
  61. controls, object persistance (that is much more automatic than OWL's).
  62. OWL has 54 classes and MFC has 87, and the classes that the two have
  63. in common are essentially identical, except that MFC is substantially
  64. more complete.  Often at first look, people consider MFC less "abstract"
  65. than OWL only because it uses the same names as Windows APIs and has
  66. all the functionality of Windows.  
  67.  
  68.  
  69. -- 
  70. Steven Sinofsky
  71. stevesi@microsoft.com
  72. Disclaimer: I don't speak for Microsoft, BillG does that.
  73.