#Borland OWL vs. MFC
3 messages in this thread
Greetings…
I've got a customer who wants me to "shift" over to Borland's C++/OWL
(basically port a project that's almost finished) because Borland supports
templates. I know of MFC's "templdef" (haven't used it; can't rightly say I'd
look forward to using it either, but…), but I'm looking for other factors to
convince them to stay with VC++:
I've heard/read that VC 2.0 will have ANSI template support – but is VC 2.0
appropriate for Win 3.1 development?
I've read (the ads) that compare execution performance – clearly in VC's favor.
The fact that the MFC source is distributed is important – is this also the
case for OWL?
If any of you sage developers can comment on these factors or others that might
be pertinent, I'd be very grateful. I've invested enough into getting a handle
on MSVC that I don't wanna pack it up so fast.
Also anyone with OWL experience (especially templates), I'd love to hear some
of your thoughts/battle stories/etc.
Carl
Carl
I used Borland C++ and OWL for about 18 months and used templates extensively,
I liked that environment and the tools that Borland provided. I have missed not
having that capability in VC++. We found the Borland templates to be very
reliable and did not have any problems to speak of, except that code size was a
bit bloated. VC++ 2.0 will support templates but will only build 32-bit
applications. If you don't have any 16-Bit components then VC++ 2.0 might be a
viable option. But if you have any 16-Bit components then it could be difficult
to move your project to VC++ 2.0 because there aren't any easy ways to link 16
and 32 bit code. Thunks are an option but they are nasty and time consuming to
work with.
Michael
You might look at Watcom 10.0, which claims to support both templates and MFC
on both 16 and 32 bit platforms. I plan to get a copy after the current crunch
is over — then we'll see if it can replace VC++ as our primary compiler.