|
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.
The future of VC++ ... =>
http://msdn.microsoft.com/chats/vstudio/vstudio_022703.asp
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.
Just my comment.
http://www.founder.com.my
|
|
|
|
|
"Garbage lorry running around" is not totally an imaginary expression, try understand how .NET manage memory via MSDN and JAVA VMM.
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.
You tell me .NET will bring good effect to I.T society??
|
|
|
|
|
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.
http://www.founder.com.my
|
|
|
|
|
.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.
At least this is what I think.
http://www.founder.com.my
|
|
|
|
|
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!!!
|
|
|
|
|
(modified)
C/C++ should NEVER EVER bound to any framework
Correct.
http://www.founder.com.my
|
|
|
|
|
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!
|
|
|
|
|
Simply because we are not living in a perfect world.
I remember my boss told me about a book which entitles
"There is a crime behind a great fortune"
You could check it up.
http://www.founder.com.my
|
|
|
|
|
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.
Mark.
Mark Malin
(00==[||]==00)
|
|
|
|
|
|
It is a dilemma I hated so much. It is again obviously, Microsoft is using its dominant on OS market to push people at a point only benefit them.
|
|
|
|
|
I agree! I bought the first edition (2002) and I believe it saved me a whole lot of time. I also recently purchased the current edition. I keep on at home an the other at work.
I also use the "Essential Guide to Managed Extensions for C++" by Siva Challa and Artur Laksberg as a quick reference.
|
|
|
|
|