Stats

An Excellent Reference for Managed C++

Book Review of Programming With Managed Extensions for Microsoft Visual C++.NET 2003

Editorial Note

This article is in the Book Review chapter. Reviews are intended to provide you with information on books - both paid and free - that others consider useful and of value to developers. Read a good programming book? Write a review!

Title

Programming with Managed Extensions for Microsoft Visual C++.NET 2003

Author

Richard Grimes

Publisher

Microsoft Press

Published

2003

ISBN

0735617821

Price

USD 49.95

Pages

583

Review

After developing stand alone Windows applications using Microsoft Visual C++ with MFC for the past several years, the transition to .NET has been frustrating, to say the least. I had purchased a few books on the topic, but starting in on my first production Managed C++ project I found them all lacking in details on the deeper subjects. What is more, Microsoft C++.NET on-line documentation in the MSDN Library was getting hard to wade through. As I’ve done in the past, I decided it was time for another trip to the book store. My hope being, if I can find just ONE book that covers a few of these topics in depth, the money will be well spent. Let me say, I was very excited to pick up Richard Grimes’ book "Programming with Managed Extensions for Microsoft Visual C++.NET", as it has exceeded all my expectations and has become a regular desk reference for this project.

Grimes’ "matter of fact" approach is refreshing and to the point. No sales pitch, no watered down glossing over the details. This book is well written, thorough and easy to understand. Pick a chapter on any topic and you will find a rich discussion with usable example code. In some cases, a subject can be addressed clearly and thoroughly in one paragraph. In other cases, when it takes 3 pages to sufficiently cover a topic, Grimes’ book delivers.

Conclusion

It may be that some or all this information lies buried within the MSDN Library somewhere, but personally, to have a tangible BOOK that I can read through, underline, dog-ear pages and sick yellow post-it notes all over is well worth the money. This is one book that will be well used, and is likely to be one of the more tattered ones on my shelf. I give it an A.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Comments and Discussions

Did the book reviewed any reason at all, mixing the highly self-contained and meta-driven language like C/C++, to IL => CLR => Fat Framework? Already people complaint about 1MB++ MFC DLL, now MS is offer us a 17MB++ framework. Of course, both of them come with the "latest" Windows OS, I just wonder if I need to patch the framework from 1.0 to X.X, do I need to supply my customer each a 64MB memory stick? Or ask the customer: "Oh, it's FREE from Microsoft web site, download yourself! Better be fast, we don't know when you will be charged!".

The reasons given by Microsoft =>
http://msdn.microsoft.com/netframework/productinfo/topten/

In my opinion, sounds more like to cheer management. It does not review difficulty in porting existing (<= VS6) system to .NET, it does not review .NET application consume a lot more memory then normal application (you know why .NET "proudly" said that the memory routine is faster then C/C++? Because the memory is reserved before you even ask for it, you call this efficient and fast?? Not me.), hardware upgrade etc etc.

Is really a heart breaking report. Are we buying VC++ to help Microsoft to conform to C/C++ standard? Or because MFC/ATL help us in many ways to produce efficient WIN32/64 software? While still enjoy programming using C/C++. While internally Microsoft will still use C/C++ (because it is still the best!!!), I bet they have a different set (or similar) of MFC/ATL/WxL?? So for dump customer like me, all I get is a compiler and linker + out dated MFC/ATL, if I want something better, I have to finance myself for Intel C/C++ compiler and buy up-to-date MFC/ATL from www.roguewave.com, DUNDAS???

Did the book also review why .NET could not exposed to C/C++ like GDI+? Instead we must be "garbage collected"? Is it once the number of C/C++ programmers is effectively cut by C#, then probably LINUX will be doomed as well? Oh..I just guess...!

I am not sure about you, or Dr.Grimes, but the C/C++ WINFORM example really make me sick, look at the structure of such source code...I don't call that C/C++ anymore, it looks like a bastard of C and JAVA (Ooops...).

I hope this book answer why people want to mix two incompatible language, different model, different perspective and yet cost so much, at the end not the customer who benefit, but Microsoft, who will still based their product on superiority of C/C++.

TW wrote:Did the book reviewed any reason at all, mixing the highly self-contained and meta-driven language like C/C++, to IL => CLR => Fat Framework?

Don't know about the book, but I needed to expose some functionality of our native C++ libraries to .NET world. I just made a component with MC++ that wraps the existing C++ library, and now .NET programmers can use it.

I mean mixing .NET class in C++ code, not interop between .NET runtime and COM object/DLL. Actually, there is nothing special about this, already we can use IDL to describe a DLL (in C++), and have VB to use it. The way .NET application structured is very different from C/C++, especially if you mix WINFORM stuff in C++..try and see for yourself. MSDN has many such horror example.

The point I tried to make is, .NET can be exposed to C/C++ just like GDI+, there is no need to "box" around, and have a garbage lorry running around. Futher more, what happen to VC++ 2002 bug? No service pack to support us (the customer!!!) this time, but was asked to upgrade..$$$..and yet, MFC/ATL has no added feature at all. Please don't tell making buffer security check is the CUSTOMER responsibility. Intel processor has the buffer locking mechanism but was not used, and Microsoft as a vendor, has the responsibility to make its product secure.

The point I tried to make is, .NET can be exposed to C/C++ just like GDI+, there is no need to "box" around, and have a garbage lorry running around.

I like the expression "have a garbage lorry running around"
Good imagination.

.NET is like a Java. No doubt about. Even the author of the language call C# a Cava.

But what ever is it. .NET will bring good effect to the IT society. May be it is consider as slow in execution speed with our present hardware configuration but it do have some points of it's existent. I mean the .NET.

I am not writing these comments because I am anti-MS, without C/C++ supporting Windows all these years, MS could have not come this far. Now, look at the future of C/C++ on Windows?!

A good engineer armed with solid C/C++ knowledge can go any platform. You really think .NET will exist on other platform without a "flying window" logo? MS is using its dominant to "__box" developers around the world into "MS asset". MS knows C/C++ is too capable to cross platform, which is the spirit of LINUX...think twice!

One final thing I would to share here is, MS is pushing hardware vendor to embedded a chip for "security reason" (Ah.ha!). Like it or not, YOUR COMPUTER IS ALWAYS MONITORED. This is in many way similar to pushing .NET software development, effectively sideline any "non-MS favor development tools", and .NET design often required you to buy many extra MS server software.

I understand the memory management of .NET or Java VMM. Just that it is funny to picture it using a garbage truck(the one you mentioned).

One final thing I would to share here is, MS is pushing hardware vendor to embedded a chip for "security reason" (Ah.ha!). Like it or not, YOUR COMPUTER IS ALWAYS MONITORED. This is in many way similar to pushing .NET software development,

I think this is to protect the software from piracy which eventually benefit us, the programmer or developer.

.NET is meant for development within internet domain. It will save you time in term of coding and maintenance. Imagine how easy is it to use .NET to do web service than to use other languages. The future is web service where components are flying here and there in the internet. It might not seems feasible of doing web service at the present network infrastructure but I believe it will catch very soon.

Try SOAP toolkit 3.0. Web service in C/C++ can be very easy and extensible. Also ATL 7 has great web service supports, great if you want highly customize web service server, can you do this with .NET? I doubt because .NET often impose heavy framework requirement on your design. You cann't easily mix different class like C++ template. You end up learning a framework by MS, not a development language. You get it?

Actually, SOAP is just like HTTP but with format in XML, hence component will be where they suppose to be. They won't fly around like ActiveX/Applet on the internet. Hence, you can easily substitude SOAP with ordinary HTTP request/response. You need to be careful when company like MS has to say about "future" technology, often the "future" is theirs, not yours. They push you to buy, you end-up resell to your customer, but the fact is, your customer doesn't really need .NET to run his business!

That's why it is important not to blend C/C++ with .NET, C/C++ should NEVER EVER bound to any framework!!!

As you know, .NET MM has 3 layers with different generations, much like a city. I guess the truck travel to see who pay who didnt pay for a MS license..ha!

I think this is to protect the software from piracy which eventually benefit us, the programmer or developer.

No doubt, piracy is a crime, but the fact is, without these software piracy, Windows could not "split" this far. Also, you can be sure the cost of implementing Windows system will jump at least one fold. If the core cost is too high, there is nothing left for developer. Think again.

There need to be a solution in fighting piracy, but definitely not at the cost of user. If you have done mass system supports, you will know what I meant if XP/Office is machine bound, you will have big headache in moving, troubleshooting, activate (sh*t!), 1 x cost to upgrade each time...etc etc. So, what's next for this "chip"??? Remember the PASSPORT bug recently? You should think more about deployment and supports, *remember there is no way MS will support you like you support your customer*, if your customer is very unhappy about this "chip", or suspicious about it when something happen, it will prove to be a very difficult situation to dealt with.

Example, we have problem supporting NT4, MS stops supporting NT4 but customer still wants it running. I still remember how desperate MS is; while introducing NT4, giving all kind of discount and promises. Now all these goes under the carpet. Would VC goes the same?

Are you sure these unfair policy impose by MS, will benefit us (the customer!!) at the end of the day? Think again and good luck!

My reason for buying this book had somewhat to do with your question. In my case, I have a small staff (just me!) and lots of code I've written with C++/MFC. Personally, I didn't WANT to go the .NET platform because IMHO C++ 6.0 and MFC works just fine for my applications. But feeling like Microsoft has turned a deaf ear toward developers like myself who still write stand-alone Windows applications (i.e. no internet, no web services, no COM...), I felt forced to write our next application in C# so I'm not completely left unsupported. Since I, like you, feel C++ is still the best language, I thought I'd just wrap my old C++ DLL's in managed extensions and use them with C#. That turns out easier said than done -- so my next decision was "all right, then, I'll just re-write them with Managed Extensions and write the user interface in C#." Digging in to the MSDN Library to figure out how to write in C++ with Managed Extensions turned into a huge "time sink". That's where this book came in. For me, it seemed like every question I came up against was clearly explained. Hence my positive report.