C#: DON'T DO IT!!!
-
Real men only use C/C++. Thanks to Microsoft for their language tools, but I can take care of my pointers, have done it before. Don't need any help on that. I believe that the only way .NET can survive is to write DLLs and Components in MFC/ATL and use them in .NET, and use .NET only as a front-end. That way you can satisfy stupid management that the code is written in C#/.NET. .NET is a complete waste of time. Just say NO to .NET! this is this.
That's great. You have fun with those pointers and memory leaks. In the meantime I'm going to concentrate on implementing functionality, not plumbing. cheers, Chris Maunder
CodeProject.com : C++ MVP
-
Real men only use C/C++. Thanks to Microsoft for their language tools, but I can take care of my pointers, have done it before. Don't need any help on that. I believe that the only way .NET can survive is to write DLLs and Components in MFC/ATL and use them in .NET, and use .NET only as a front-end. That way you can satisfy stupid management that the code is written in C#/.NET. .NET is a complete waste of time. Just say NO to .NET! this is this.
Well, when C/C++ came around, people would have been saying "Real men use assembly language", before that "Real men use machine language" and so on. If you get a platform that offers you a lot of power and ease of use, I'd say go with it *when it is appropriate*, instead of clinging on to something you know. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
Well, I have pretty much the following comment. The performance of any language is based equally, if not more so, on the skill of the programmer.
Tom Ollar wrote:
If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
:laugh: :rolleyes: Marc VS2005 Tips & Tricks -- contributions welcome!
-
Real men only use C/C++. Thanks to Microsoft for their language tools, but I can take care of my pointers, have done it before. Don't need any help on that. I believe that the only way .NET can survive is to write DLLs and Components in MFC/ATL and use them in .NET, and use .NET only as a front-end. That way you can satisfy stupid management that the code is written in C#/.NET. .NET is a complete waste of time. Just say NO to .NET! this is this.
Real men don't use computers, they use there own brain power... Seriously though, while you take out the garbage I'll add functionality. I'm not saying unmanaged code is useless. Its a tool, tools are supposed to make our lives easier. Why use stone and chisel when you can use pencil and paper. Matt Newman
Even the very best tools in the hands of an idiot will produce something of little or no value. - Chris Meech on Idiots
-
C# and the .NET core framework are fully capable of performing at a level that is competitive with that of native code. Initially I was worried that that would not be so, but the more I work with it, the more I find that, if you do things right, it is fully capable of good performance. But that "if" is very important. Firstly, C# lets you write code and design object-oriented libraries more easily, and at a higher level. This can cause many people to think less about the lower-level aspects of their application or component (performance, memory, etc) - until they have already coded it, and the performance problems hit them in the face. You have to keep those concerns in mind at all times - just as you would have to do when writing C++ code. You have to consider the performance implications of each design choice. Secondly, the .NET Framework is a different paradigm from what people coming from other backgrounds expect. To write performant code, you have to understand what is going on behind the scenes, and the dynamics of the framework that you are working with. But those dynamics are different from what people are used to. Each new way of doing things has both a good side and a bad side - and you have to consider both. I've seen even a lot of experts say things that demonstrate a lack of understanding of how the .NET framework works - simply because they have not yet had time to fully understand it. Now, that being said, there are, indeed, notable performance flaws in the non-core part of the .NET BCL, mainly having to do with native-to-managed interop wrappers. The .NET sockets implementation at least used to have scalability problems related to large numbers of transient connections, because of the way pinned objects were used. The Windows Forms wrapper suffers from a fair bit of slowness both because of interop and because the control classes derive from MarshalByRefObject, which does not benefit from a number of optimizations. The GDI+ wrapper would be much faster if it were not for the fact that interop is done in a very poor way performance-wise - buffer copies where they are not needed, poor use of caching, etc. Frank Hileman has considered abandoning the System.Drawing wrapper completely in favor of writing a custom GDI+ wrapper to get better performance by writing more efficient interop code. However, this is not a C# or core runtime problem, but a problem with the BCL, and even with the comparative slowness of the wrapper due to the way it is written, he has created a
Well said, I have a question for you. What profiler do you use? I used the analysis tool that was in the Betas but I can't find it in the Pro version (guessing they put it in Team System) but I am looking for one. Matt Newman
Even the very best tools in the hands of an idiot will produce something of little or no value. - Chris Meech on Idiots
-
That's great. You have fun with those pointers and memory leaks. In the meantime I'm going to concentrate on implementing functionality, not plumbing. cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
That's great. You have fun with those pointers and memory leaks. In the meantime I'm going to concentrate on implementing functionality, not plumbing.
Did we code one too many lines of FORTRAN (yes, it deserves capital letters ;P ) Chris? Or, perhaps, you just weren't man enough to handle pointer arithmetic? ;)
-
I place this as a warning. If you are thinking about building a "rich client" on the C# .Net Platform - think again. It's slow. So slow that the guys in Redmond lapsed into stunned silence when I explained the kind of things my company does with C#. I heard this: "But what about performance?" "How's performance?" "You're using GDI+?" "So, how many objects get created with that code?" - in an admonishing tone, of course. and again - "What about performance?" These questions, coupled with the "Visual C++ - The Ultimate Language" poster on the second floor of building 41, kind of made me think that C# was a second class citizen, or worse... So just don't do it. Who cares about "managed code" and all that OOP crap - a 23mb Framework that's not installed ANYWHERE except stupid Windows Server 2003 and all that slow, slow, slow code simply isn't worth it. If you must have awesome UI use Flash and port it over to some PC emulator thingy - hell - ANYTHING is better than C#/Framework... Well that's it. You've been warned. If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
-
Well, I have pretty much the following comment. The performance of any language is based equally, if not more so, on the skill of the programmer.
Tom Ollar wrote:
If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
:laugh: :rolleyes: Marc VS2005 Tips & Tricks -- contributions welcome!
On his defence, if its GDI+ that is his problem , he's quite right about performance problems. gdi+ is 100% software rendered and slow as crap compared to real native gdi. (even if people claim gdi+ to be a wrapper over native gdi which I would claim it isnt since it doesnt allocate gdi resources in your process (ok, it does in some cases eg if you get a hdc or hfont etc) and yes , i know its very possible to get decent rendering speeds with hardcore smart redraw optimizations in gdi+. (and Ive seen vg.net) but you can get better rendering speed in native gdi w/o any optimizations at all. So I will agree with him and say that gdi+ is slow as crap. but on the other hand , that has nothing to do with c# :)
-
Well said, I have a question for you. What profiler do you use? I used the analysis tool that was in the Betas but I can't find it in the Pro version (guessing they put it in Team System) but I am looking for one. Matt Newman
Even the very best tools in the hands of an idiot will produce something of little or no value. - Chris Meech on Idiots
For memory-related profiling, I've always used the CLR Profiler[^]. It has a whole bunch of memory-related graphs and statistics. For CPU-usage-related profiling, at first I just used timing code inserted at various points. Then I started using NProf[^] (which seems to be perpetually in 'alpha' stage :rolleyes: ). It gives you basic statistics related to performance each method in your application (time taken for each is given as a percent of the overall time). Then I started using the VS2005 profiler, which is very convenient and pretty good as well - but now that I've upgraded to the RTM it's gone. :(( I've heard that the Ants Profiler[^] is good, so I think I'm going to check it out.
-
On his defence, if its GDI+ that is his problem , he's quite right about performance problems. gdi+ is 100% software rendered and slow as crap compared to real native gdi. (even if people claim gdi+ to be a wrapper over native gdi which I would claim it isnt since it doesnt allocate gdi resources in your process (ok, it does in some cases eg if you get a hdc or hfont etc) and yes , i know its very possible to get decent rendering speeds with hardcore smart redraw optimizations in gdi+. (and Ive seen vg.net) but you can get better rendering speed in native gdi w/o any optimizations at all. So I will agree with him and say that gdi+ is slow as crap. but on the other hand , that has nothing to do with c# :)
Yes - GDI+ is not hardware accelerated, and then on top of that, the wrapper is poor too. I wish there was something better out there for .NET - I have my hopes up that if a wrapper could be created for AGG, it would be at least a fair bit faster. But with optimizations such as updating only the areas of the screen that have changed, GDI+ can do pretty much anything you need it to in the way of normal UIs (i.e. not complex animation) - even if those UIs are complex. The problem is in the implementation - the optimizations can be time-consuming and complex to do. I think if Tom had talked about the problems of GDI+ or the System.Drawing wrapper, he would have gotten a better response - assuming that the drawing side of things was what he was referring to - but I don't know for sure if it was. I think all of us who have worked with System.Drawing have been pained at one point or another with speed problems.
-
I agree about the pointers. I can deal with those myself, and when I don't, I get a nice, easy to interpret GPF message ;) which indicates I need more coffee. Maybe it's a power trip, but I'd rather have the option of shooting my foot off with pointers, than having someone collect my garbage. It makes you more responsible, so you have to think about what you're doing. As far as writing components in MFC/ATL and using them in .NET, that's essentially going back to the VB6 days. C#/VB.NET is the next evolution of VB6, in my mind. I can't help thinking C# was created so people would think "oh, it's not BASIC" or "I know C++ now", just to satisfy management and curious end-users. Wrong! Suck it up and learn C++! P.S. .NET is too sloooow! Scott me up beamy!
Steve Echols wrote:
I agree about the pointers. I can deal with those myself, and when I don't, I get a nice, easy to interpret GPF message which indicates I need more coffee. Maybe it's a power trip, but I'd rather have the option of shooting my foot off with pointers, than having someone collect my garbage. It makes you more responsible, so you have to think about what you're doing.
Interesting. Have you tried using auto_ptr or one of the boost _ptrs? "When you know you're going to eat crow, it's best to eat it while it's still warm." - Reader's Digest
-
That's great. You have fun with those pointers and memory leaks. In the meantime I'm going to concentrate on implementing functionality, not plumbing. cheers, Chris Maunder
CodeProject.com : C++ MVP
Pointers and memory leaks are pretty easy to avoid if you design in the right way. I can't remember the last time I was bitten by either of them. The real nasties are multithread synchonisation issues, and no framework can insulate you from them totally... Speaking personally, .NET would be great if it offered us what we wanted. Unfortunately, it doesn't right now, and I can't see that changing anytime soon - if at all. The discussions we had with MS people at the VS2005 launch event in London last week confirmed that. Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
Real men only use C/C++. Thanks to Microsoft for their language tools, but I can take care of my pointers, have done it before. Don't need any help on that. I believe that the only way .NET can survive is to write DLLs and Components in MFC/ATL and use them in .NET, and use .NET only as a front-end. That way you can satisfy stupid management that the code is written in C#/.NET. .NET is a complete waste of time. Just say NO to .NET! this is this.
No, real men use assembly language (not to be confused with .NET assembly). It is a well-known fact that C/C++ is for wussies. -------- "I say no to drugs, but they don't listen." - Marilyn Manson
-
Well said, I have a question for you. What profiler do you use? I used the analysis tool that was in the Betas but I can't find it in the Pro version (guessing they put it in Team System) but I am looking for one. Matt Newman
Even the very best tools in the hands of an idiot will produce something of little or no value. - Chris Meech on Idiots
Did you try using DevPartner[^]? It's free, integrates with VS .NET and worked pretty well for me. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
Real men only use C/C++. Thanks to Microsoft for their language tools, but I can take care of my pointers, have done it before. Don't need any help on that. I believe that the only way .NET can survive is to write DLLs and Components in MFC/ATL and use them in .NET, and use .NET only as a front-end. That way you can satisfy stupid management that the code is written in C#/.NET. .NET is a complete waste of time. Just say NO to .NET! this is this.
Pointers are available in C#. C# people just don't use them too often when a better alternative (garbage collected "pointers"; references) is there. And let's not get elitist here; elitism already plagues too many of us, especially when it comes to languages and operating systems. To be elitist and say garbage collection is not for real men would be hypocritical; let's not forget our beloved COM uses reference counting and Boost makes extensive use of garbage collected smart pointers. We also should not forget that not too long ago was this same argument posted, only saying that C++ is for wussies, real men code in C. Or Assembler. Heck, maybe we ought to just revert back to punch cards.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Bought a House! Judah Himango
-
For memory-related profiling, I've always used the CLR Profiler[^]. It has a whole bunch of memory-related graphs and statistics. For CPU-usage-related profiling, at first I just used timing code inserted at various points. Then I started using NProf[^] (which seems to be perpetually in 'alpha' stage :rolleyes: ). It gives you basic statistics related to performance each method in your application (time taken for each is given as a percent of the overall time). Then I started using the VS2005 profiler, which is very convenient and pretty good as well - but now that I've upgraded to the RTM it's gone. :(( I've heard that the Ants Profiler[^] is good, so I think I'm going to check it out.
We use Ants here. Excellent profiler, you'll be spoiled by it. :)
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Bought a House! Judah Himango
-
Tom Ollar wrote:
If you are thinking about building a "rich client" on the C# .Net Platform - think again.
I have done, sorry. My app does image processing, captures images from still and video cameras, processes video as well, etc.
Tom Ollar wrote:
So slow that the guys in Redmond lapsed into stunned silence when I explained the kind of things my company does with C#.
Like what ? Seriously, managed DirectX runs at 95% of the speed of C++ DirectX. All C# code gets compiled the first time it gets run, then it's native code. I'm interested to know what application you've written that cannot be optimised to work with C#. I would still be an advocate for C# being one possible tool, and C++ being a better one in some cases. Yours may well be a case for C++ as the best tool. I doubt, and my experience disproves, the idea that
Tom Ollar wrote:
Who cares about "managed code" and all that OOP crap - a 23mb Framework that's not installed ANYWHERE except stupid Windows Server 2003 and all that slow, slow, slow code simply isn't worth it.
is a reasonable statement. Wait a minute - you're saying that OOP is a waste of time ? Christian Graus - Microsoft MVP - C++
Christian Graus wrote:
I have done, sorry. My app does image processing, captures images from still and video cameras, processes video as well, etc.
Hi Christian, OOI, that sounds like directshow, which isn't a part of managed directx. How did you do it? COM Interop? or wrap the (C++) directshow stuff in managed c++ ? I'm tasked with extended a C++/directshow DV processing app I wrote a while ago. I'd like to start from a clean sheet and do it in C#, and would be interested to know if you already spent some time tackling these problems Cheeers Jon PS. The nipple pointing stick thing on my laptop keyboard has successfully been repaired now, I'd like to thank you for your sympathy and support the other week when the disaster struck.
using System.Beer;
-
Pointers and memory leaks are pretty easy to avoid if you design in the right way. I can't remember the last time I was bitten by either of them. The real nasties are multithread synchonisation issues, and no framework can insulate you from them totally... Speaking personally, .NET would be great if it offered us what we wanted. Unfortunately, it doesn't right now, and I can't see that changing anytime soon - if at all. The discussions we had with MS people at the VS2005 launch event in London last week confirmed that. Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
Anna-Jayne Metcalfe wrote:
Speaking personally, .NET would be great if it offered us what we wanted. Unfortunately, it doesn't right now, and I can't see that changing anytime soon - if at all. The discussions we had with MS people at the VS2005 launch event in London last week confirmed that.
Out of curiosity, what doesn't it offer? Don't worry, I don't have any .NET/C# bent either way. I'm just wondering and hoping to learn something.
-
Well, when C/C++ came around, people would have been saying "Real men use assembly language", before that "Real men use machine language" and so on. If you get a platform that offers you a lot of power and ease of use, I'd say go with it *when it is appropriate*, instead of clinging on to something you know. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
S. Senthil Kumar wrote:
Well, when C/C++ came around, people would have been saying "Real men use assembly language", before that "Real men use machine language" and so on.
Actually, assembly language programmers were only too happy to jump onto the C/C++ bandwagon. They were only too happy to leave that level to those who really knew what they were doing and had the requisite expertise. The same will be true of a move from RAW C/C++ to .NET C#/C++/J#/VB/COBOL/WHATEVER. There are different kinds of programmers and there are different kinds and levels of skill. Use the tool you feel comfortable with and that is right for the job.
-
Christian Graus wrote:
I have done, sorry. My app does image processing, captures images from still and video cameras, processes video as well, etc.
Hi Christian, OOI, that sounds like directshow, which isn't a part of managed directx. How did you do it? COM Interop? or wrap the (C++) directshow stuff in managed c++ ? I'm tasked with extended a C++/directshow DV processing app I wrote a while ago. I'd like to start from a clean sheet and do it in C#, and would be interested to know if you already spent some time tackling these problems Cheeers Jon PS. The nipple pointing stick thing on my laptop keyboard has successfully been repaired now, I'd like to thank you for your sympathy and support the other week when the disaster struck.
using System.Beer;
Jon Hulatt wrote:
OOI, that sounds like directshow, which isn't a part of managed directx. How did you do it? COM Interop? or wrap the (C++) directshow stuff in managed c++ ?
*blush* at this point it doesn't yet capture the video 'live', and it does the still stuff via an SDK that comes with Canon cameras.
Jon Hulatt wrote:
I'm tasked with extended a C++/directshow DV processing app I wrote a while ago. I'd like to start from a clean sheet and do it in C#, and would be interested to know if you already spent some time tackling these problems
There are articles on CP on using DirectShow via COM interop, which is how I presume I'll go when I move from processing mpgs to capturing the video live. Christian Graus - Microsoft MVP - C++
