Does any one here remember when microsoft made the change from DOS to Windows 95, I say this becouse Windows 95 is a 16 bit OS. it splits 32 bit operations that it takes "natively" into two or more 16 bit operations. This was doen becouse they were "trying" to make the transition a bit better. Based off of microsoft trends i belive that Longhorn will be almost fully compatable and Performing with native win32. However the version after Longhorn will be the win98 of "Next Gen OS" it will probly be the first one to really impose restrictions upon win32 programmers. I still look at Longhorn as a bad move on Microsofts part but hey it could just be because i dont like it when Corporations try to rape developers. As for the first poster your dumb, ignorant and ill informed the title of the thread tells us that much. You make a statement in the form of a badly worded question. also known as normalme == Stupid 10 year old AOL''er. if this posting has offended anyone, good it was ment to.

quote: Original post by HippieHunter
Based off of microsoft trends i belive that Longhorn will be almost fully compatable and Performing with native win32. However the version after Longhorn will be the win98 of "Next Gen OS" it will probly be the first one to really impose restrictions upon win32 programmers.

Please note Longhorn already imposes restrictions. Using the /CLR switch allows a developer to compile managed even though they lose some performance. But if you compile and keep in native you get the performance hit as well as the security warnings and based on users settings it may not even run.

quote:
I still look at Longhorn as a bad move on Microsofts part but hey it could just be because i dont like it when Corporations try to rape developers.

That just shows that you don''t have much knowledge about professional development. Not a bad thing, just that you shouldn''t be making statements about it since you don''t understand.

Computers and their software is made for END USERS. Microsoft does not make an OS thinking "wow the developers will love this!".. they are thinking "wow the end-users will love this, and we will sell more copies". When speaking about desktop usage they are not scared of losing any marketshare, they have everyone and it will stay that way.

Now you say corporations are raping developers? Please note that DEVELOPERS CAUSED THIS SHIFT. If all developers could actually code without leaving memory leaks, buffer problems, security issues, etc.. than guess what, we wouldn''t need a managed system would we?

Since projects are getting larger and harder to manage, and a lot of the newer developers are lazy or have bad practice, we NEED a managed system.

By having a managed system users can no longer blame Microsoft for problems created by 3RD party developers. I have seen people complain about Win2k and XP (which are the most rock-solid desktop OS''s currently), when it has nothing to do with the OS, but obviously a driver or 3rd party application error causing this. Microsoft will no longer be blamed, because these security flaws, stability issues, etc are no longer allowed to happen.

quote: Original post by Anonymous Poster
Imperil against the world!

Sometimes it seems that way =]

But if you look at the thread it is not only me. It is basically a few professional developers stating facts and what they think will happen.. and debating with each other... and then also arguing with a bunch of children yelling "C++ 4 teh win! we r own!".

Stupid on both sides, but this week I have a lot of time at work to kick back =]

quote:
That is one of the problems with C++, the constant focus on execution speed by its fanatics.

Actually, game programmers care. And ironically enough, you''re on a game programming forum. Games like Quake, Doom and Unreal try to squeeze as much juice as they can out of the language, creating blazingly fast, yet stunningly beautiful games.

.. and yes, I know all about the productivity and this and that about C# vs C++. The point of my post was not to debate what language was best, but rather to try and get those debating to prove their cases. People say this, people say that. All C++ programmers care about is speed. Unless proof is shown (benchmarks) that C# is just as fast as C++, they will continue to scream "C++ is teh ubah."

We all know about Quake .NET, and in the uneducated mind of someone who doesn''t know .NET very well, they will see this as a win for C++ as it proves just how much slower .NET is. So until another app comes along and shows them proof (although Quake .NET wasn''t proof, but again someone who doesn''t know .NET doesn''t know the difference), they will continue to see C++ as superior.

quote:
ASM was originally what people used and did so all the way up until about 1996.. this is where you saw a change.

People started developing games (I am talking about professional games here not Little Jimmy''s pong version 2984) in C and did so until about 2000-2001.

I think your dates are off by a few years. WarCraft was released in 1994, and while I have no doubt that ASM was used, I bet it was mostly made in C. This, IMO, is about when games started switching from ASM to C.

I have no proof to show when games switched from C to C++ as the standard, but if I had to guess, I''d say about 1998. I''m curious as to where you''re getting your info from?

quote:
Also please note that it has been stated, shown, benchmarked, etc that C# gains ENORMOUS performance benefits when using C# 2.0 (VSNET Whidbey) and running on Windows Longhorn, it has even been shown to run 20-30% faster than it''s native unmanaged C++ counterpart... so please bring evidence to the table before you post lies and garbage.

Okay, you gave links to the Axiom and OGRE engine so we can benchmark and see for ourselves. Cool, that''s acceptable. But what about what you''re talking about here? This, IMO, is nothing more than speculation unless you can give a link. Until then, C# and C++ performance on the next version of Windows cannot be predicted (especially since it''s not even finished in the first place). So our discussions about how well C# performs in comparison to C++ much involve the present, not the future. It is the only hard evidence that we can go off of.

quote:
I searched around on net for awhile and found a few performance comparisons:
http://www.osnews.com/story.php?news_id=5602&page=3
http://www.kuro5hin.org/story/2002/6/25/122237/078
http://www2.hursley.ibm.com/decimal/telco.html
http://www.windevnet.com/wdn/webextra/2003/0313/
http://www.javaperformancetuning.com/news/qotm028.shtml

The Great Win32 Computer Language Shootout:
http://dada.perl.it/shootout/

Source of a c-sharp benchmark I don''t have a compiler :/
http://www.ocf.berkeley.edu/~cowell/research/benchmark/code/Benchmark.cs

Another source of a few languages I guess:
http://rotor.cs.cornell.edu/SciMark/

Article or discussion about DirectX and C#:
http://weblogs.asp.net/jdavis/archive/2003/05/21/7344.aspx


They don''t really prove that C# is as fast as people on this fourm are saying it is; but I will let you be the overall judge.

If I had to use those links as my judge, then I''d say that C# can be anywhere from nearly as fast to quite a bit slower than C++. But, none show C# to be just as fast or faster than C++. So I must conclude (based on those benchmarks) that C# is slower, even if by just a little bit.

quote: Original post by wyrd
Until then, C# and C++ performance on the next version of Windows cannot be predicted (especially since it's not even finished in the first place).

Sorry I can't do that while under NDA. I can say how great the differences are, what it's like, but I can't quote actual numbers, stats, graphs, etc.

As an ISV I can't release evidence-based information to the public hence I am breaking my license.

Trust me I would love to show screenshots and benchmarks, but I cant =[

quote:
If I had to use those links as my judge, then I'd say that C# can be anywhere from nearly as fast to quite a bit slower than C++.

It really depends on if you know what is happening with the language, have read the updated specs, and have used the 2.0 version in Whidbey.

You see the parts you see now that are "quite a bit slower".. well those are known problems due to boxing/unboxing (solved with generics), as well as needing iterators, anon methods, etc. You will see the performance jump up quite a bit in C# (as I already have) when using these new parts of the language. These features were designed to be implemented into C# from day one.. they were just slated to appear later on the roadmap. They are not quick hacks like the STL for C++.

quote:
But, none show C# to be just as fast or faster than C++. So I must conclude (based on those benchmarks) that C# is slower, even if by just a little bit.

You are correct and I even stated this. Currently on an unmanaged operating system, unmanaged C++ will run faster than managed C# with SMALL BENCHMARKS.

Currently with real-world applications we are seeing the opposite. Why? Probably due to the better design, type-safety, structure, etc. I mean that is the only way to really explain the speed difference... applications are more FORCED to be written correctly.

I mean if C# can provide 95-98% performance on a system that it is not native too.. you really can't see what will happen on a system it is native too? .. it is quite obvious.


[edited by - Imperil on January 15, 2004 1:38:54 PM]

quote:
Sorry I can''t do that while under NDA. I can say how great the differences are, what it''s like, but I can''t quote actual numbers, stats, graphs, etc.

As an ISV I can''t release evidence-based information to the public hence I am breaking my license.

Trust me I would love to show screenshots and benchmarks, but I cant =[

Then why continue to argue? It''s obvious that the nutty C++ people aren''t going to believe you unless they see it for themselves. I love C# and I love the fact that it simplifies a lot by a great deal, and also makes me way too productive for my own good. But let''s face it - in the argument of speed, C++ is going to be hailed king until proof shows otherwise.

quote: Original post by wyrd
Then why continue to argue? It's obvious that the nutty C++ people aren't going to believe you unless they see it for themselves. I love C# and I love the fact that it simplifies a lot by a great deal, and also makes me way too productive for my own good. But let's face it - in the argument of speed, C++ is going to be hailed king until proof shows otherwise.

I don't argue to change the minds of any of the "c++ 4 teh ownz0r" people. They are set in their way and will continue to say that until they see benchmarks. Once Longhorn is released and they see benchmarks they will probably be the first people in the crowd to start posting "C# 4 teh ownz0r".

The reason I post is so that people that are interested in using the C# language do not get scared away from blatant lies. I mean seriously.. read through this full thread and I can find at least ten or more made up facts by C++ programmers to deter people from using C#. I won't lie.. I used to be like that back in the day saying THE SAME THING ABOUT C++.. and guess what happened? (this reason is why I learned to start adopting technology and changes rather than deny them) =]

Sure speed is impossible to prove right now.. but put it this way.. people should stop comparing unmanaged C++ to C#. Unmanaged C++ is dead on Windows in 2 years or so, except for writing drivers, and low level operations.

The real comparison should be managed C++ vs. C#. Now go compare those benchmarks that are freely available.. even without generics and 2.0 features. Although people will probably complain that it is not a correct comparison because managed C++ gets trampled on. I mean no matter how you slice it, a language build for developing managed applications on a managed system is going to perform the best.

As well people will probably keep saying unmanaged C++ will still be used on the Windows desktop.. just like these same types of people did when people were ditching ASM for C coding DOS applications. Now how many full applications are written in ASM for Windows?


[edited by - Imperil on January 15, 2004 3:13:54 PM]

Im glad everyone liked my links

Perhaps someone will make 2 differnt apps which calculate speed and post it maybe that would decrease some of the agruments, its really hard to say what is faster or slower, C# isn't a finished langauge.

And sometimes seeing somthing acutually perform the benchmark can be more proof then articles themselfs.

I could care less which way it goes it could be C# fine it could be C++ fine, it could be both; doesn't bother me, either way is fine... its not like they are hugely differn't either way.

Only thing I think is somewhat messed up is that Microsoft is once again selling an unfinished product but then again they always seem to sell there software unfinished.

More or less likely C++ is going further I read an article about how C++ is being planned on being improved in the years to come by improving managed C++ and making it more efficant, and possibly converting it to the CLI PE structure instead of its current file structure. So more or less likely you will see a new edition of C++ coming out with longhorn which I bet will be a very nice; however there is nothing wrong with learning C# and C++, its just another language you can put on your list there are going to be serveral changes to C++ when it converts to longhorn and during those changes you will see C++ improve in overall performance; I read this stuff on Microsofts website for those of you who are wondering.

Imperil however not being mean but you could lighten up a bit

[edited by - DevLiquidKnight on January 15, 2004 4:00:45 PM]