Why does MS keeps maintaining such a language that caused so many buffer overflows, and generally was not as secure as C# or Vb.NET.
The only + point for C++ is that it compiles into machine code directly, and if we can get C# to do that, then there is no need for a language like C++.
I was wondering why C++ still exists when C# is that good of a language.
MS, why not retire C++, and just focus on C# and Vb.NET and F#?
Expand C# capabilities, and get rid of P/invoke and replace it with a new kind of mechanism to call dlls outside the .NET framework.
Finally, make the .NET framework really .NET, in the sense that it is distributed in terms of processing power, by enabling sharing. So that my application could use the processor that is Idle in a second room in the the house, automatically through the use of Remoting in LAN.
Kill C++, and lets all be on one page, with C#.
Its confusing many people, and things needs to be simpler, with few languages. C# for experts, VB.NET for beginners and intermediates.
That is all.
Name:
Anonymous2007-12-03 2:23
I hope to god this is a troll...
Name:
Anonymous2007-12-03 2:24
The possibility of C++ staying strong without MS maintaining a compiler for C++ is a good reason to keep maintaining it.
>>1
I'm hoping I just missed the sarcasm in that comment.
Even if we assume, as you seem to, that C++ is an obsolete and uselss language then there are still billions of lines of C++ code out there that work and do the job they were designed, and purchased, to do. There is absolutely no chance that all of that investmen is just going to vanish any time in the next several decades. C++ will be with us through the remainder of any of our careers and well beyond.
Since someone will be maintaining C++ code for the next 3 decades at least, Microsoft has, wisely, decided to make more money by selling modern tools to those developers.
PS: I still find C++ to be pretty useful in some circumstance. I'm just ingroning that for this post.
Name:
Anonymous2007-12-03 7:38
C++ for Games Programming. Give us a few years and we can consider C# perhaps.
Name:
Anonymous2007-12-03 10:31
OO IS FOR FAGGOTS
Name:
Anonymous2007-12-03 14:13
Why does GNU keeps maintaining such an editor that caused so many buffer overflows, and generally was not as secure as vi or ed.
The only + point for Emacs is that it edits bindings through lisp directly, and if we can get vi to do that, then there is no need for an editor like Emacs.
I was wondering why Emacs still exists when vi is that good of an editor.
GNU, why not retire vi, and just focus on vi and ed and nano?
Expand vi capabilities, and get rid of lisp and replace it with a new kind of mechanism to call dlls outside the gcc framework.
Finally, make the gcc framework really gcc, in the sense that it is distributed in terms of processing power, by enabling sharing. So that my application could use the processor that is Idle in a second room in the the house, automatically through the use of Remoting in LAN.
Kill Emacs, and lets all be on one page, with vi.
Its confusing many people, and things needs to be simpler, with few languages. vi for experts, ed for beginners and intermediates.
I suffered with C++/MFC development and it sucked ass. There were libraries for all the things I needed like sockets, threading, localization, encryption, GUI dev, but it was just really clunky and a pain in the ass to manage. When .Net came out I was hopeful they were re-hashing their dev libraries, but they tied it to this whole managed code movement which really has some baggage that doesn't seem necessary like the garbage collection and byte code. The situation now is deal with the baggage because for windows dev there really isn't any other option. C#/.Net is amazing productivity wise, very polished, no headaches, compiler, versioning, or localization problems. Just the damn performance which seems like something they could fix if they put their mind to it.
Name:
Anonymous2007-12-03 21:15
>>16
Garbage collection may not be "necessary", but why wouldn't you want it (embedded programmers stfu).
Name:
Anonymous2007-12-03 21:48
You're right I've been doing c# long enough that I would not want to go back to managing my own memory and the endless problems that come with that. I'm trying to convey that speed wise its just not there. I ported a large VB6 app over to VB.Net and I basically watch the GUI build itself as it loads up, VB6 was lightning quick. Traversing bitmaps get/set bit is also horrendously slow, I have no option but to use unsafe{} when I need fast drawing. GDI+ as well (not .Net, but new) isn't hardware accelerated which blows my mind. I have apps taking in camera data 30fps and piping it though gdi+ I can get maybe 5fps. I have to fall back on GDI also for drawing. Network data processing is another area with some slowdowns because you can't map structs to arbitrary memory, but I've worked around that pretty well so no big deal.
All this taken into account C#/.Net is still the most productive and stress free solution to my many projects. I really wish it existed when I started out coding I would of had a lot less head aches *fucking compilers*
Name:
Anonymous2007-12-03 21:57
>>18 Network data processing is another area with some slowdowns because you can't map structs to arbitrary memory, but I've worked around that pretty well so no big deal.
How?
When I code I get shit done. If you can keep up with the speed I dev with C++ while maintaining high standards of quality I'd like to see it.
How? If you mean network code, the Socket class (like most) re-uses buffers for sending/receiving so there's no need to continually allocate memory. The big advantage to writing network apps in .Net it using the default overlapped IO implementation which is verrry fast.
It sounds like you wanted to know how to map structs to arbitrary memory though, and that's not my solution to networking because fixed length protocols suck for extendability and interoperability which I need. But if you reallly wanted to you could do this, which is more for legacy purposes (win32 stucts, etc...) if you wanted to turn classes to binary I'd look at serialization, again you're probably going to have future versioning problems if you use stuff like that.
-----------------------------------------------------------
unsafe struct packet{ ... }