Re: Best book for learning MFC/VC 7.1 for developing rich GUI apps ?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



Andre Kaufmann wrote:

Alfonso Morra wrote:



David Lowndes wrote:

[...]
Since you're just starting, many people will ask why you're not
considering starting from the .Net framework - which is where most of
Microsoft's efforts are today. So, have you considered that?

Dave 



Hi Dave,

Thanks for the feedback. Good question. My reluctance to move to .NEt is based on the information (which could be inacuurate) I have gathered so far:

1). It is "not secure" as far as IP is concerned - code is easily reversible from binaries


Well, IL code can be easier reengineered as native code, since you have additional information about classes, variable names etc. .
Native code hasn't, except if you have the debug information too ;-).
For that purpose there are obfuscators, e.g. dotfuscator integrated in the VS Studio IDE. It will obfuscate all variable and class names in the code so that it's nearly unusable anymore.

But if you use Managed C++, or better C++/CLI, you will normaly mix native code with .NET code. Such code compiles (normally) to a mixed binary. If you compile such code you'll get a mixed binary. Mixed native and managed code. By the way the C++ compiler is the only one which can compile mixed binaries.

Since you normally call only into the .NET framework or use simple wrapper classes i think the recompilation problem is neglectable.


2). I HATE the fuss of interoperatability between "managed code" and "unmanaged code" - pretty much all of my logic is in C/C++ libraries - really, all I need is to know how to create a GUI frontend for my libraries - I like .NET GUI capabilities but I don't like the fact that my binaries can be easily converted to source (even with obfuscation).


See above. Your native source code will still be compiled to native code. If you are using the GUI as a simple wrapper only i wouldn't care about recompilation.


3). I don't want to learn a new language - (C#)


You mustn't. It would be C++/CLI (VC++ 8.0) which i strongly recommend to use instead of the deprecated Managed C++.
It doesn't use that ugly double underscore keywords, since it's an ECMA standard and scheduled for ISO standardization.
Although it's easier to interoperate with native code now,
C++/CLI code is still managed code and you have to deal with interoperability issues. There are currently some restrictions mixing native and managed classes, with which you will have to deal till the next C++/CLI version, which are currently solved using (existing) wrapper classes.

Although I like C++/CLI very much, I tend to use C# as language for my managed GUI's, calling my native code through P/Invoke or COM Interop.
Just because of the compilation times ;-) and I'm much more productive.
Additionally I'm forced to separate GUI code from native (logic) code.

If I can be convinced that these objections can be overcome without too
trouble than I may consider using .NET


I think creating a WinForms GUI is much easier than with MFC. But if you have to use native code you will have to deal with interoperability issues and have to decide if the productivity gain of WinForms is worth the additional interoperability issues.
For me - mostly it is.

If not, perhaps available native C++ RAD GUI frameworks integrating into the VS IDE might be another valuable alternative for you, e.g. QT4 ?

Only downside:
You might be forced to change the framework in the future since the future of Windows application with GUI frontends is definitively managed. And since MFC and WinForms will allow you mixing native and managed GUI components, i don't know if the alternative native GUI's will allow it too in the future.

Hard decision to make.

Andre



Thanks for your input Andre. There are many pros and cons on both sides. However, when all is said and done, the balance (for me) lies with C++/"old school" MFC. After a little further research, trhis book looks interesting : "Visual C++ Mfc Programming by Example", I'll borrow it first, and if its useful, I'll buy it.

Many tks

.

Relevant Pages

  • Re: About VS C++
    ... GUI -- VCL is a little old, ... Native Code -- Yes, please put more resource on Native Code, such as ... Unicode, Fast String functions etc ...
    (borland.public.delphi.non-technical)
  • Re: App Development with Visual C++ .NET
    ... VS.NET 2003 can create native code, but not for Windows CE devices. ... > I've read that unmanaged code can be used in VS.NET 2003 for C++. ... I wanted a way to easily create a GUI ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: change .net application into native code application, possibl
    ... On Apr 25, 7:48 pm, fairyvoice ... There are utilities that will compile your .NET application into native code ... then you should not be using the .NET Framework to develop it. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Java performance
    ... not being compiled down to native code but just allways being ... interpreted which might result in an unreactive GUI as an effect (or at ... I have seen native GUIs become unresponsive just as much--in both Windows and Linux implementations. ... In fact, from the little I know of various toolkit implementations, this is just as much a problem in Java Swing code as it is GTK2 or Windows API. ...
    (comp.lang.java.programmer)
  • Re: C++ vs. C# (new to windows programming)...
    ... IMHO it's more straightforward and somewhat easier in C# and other managed languages to code a GUI application. ... The compiled C++/CLI library can be easily used from any .NET language and additionally you have separated your GUI from the other code. ... C++/CLI will compile to faster IL code, no doubt, but I doubt that you will see a relevant speed difference for your managed GUI. ... If you need speed and supporting native code then C++/CLI is the way to go. ...
    (microsoft.public.dotnet.languages.vc)