C# won't "take over", but it will make things interesting.
C# won't "take over", but it will make things interesting.
Which is what the trick is. The main objective behind all this is to promote their OS. So give the users a completly rad enviroment, a better language and a nice IDE to develop it all and why would anyone want to leave the OS or the enviroment. In the menatime lose complete support for C++ thus giving ppl one more reason to switch to it.As far as I know, C# can be used only in the .NET environment. When using a different platform, then .NET will not run and so you can't use C#.
Thats obviously cause c++ has been there for such a long time. Ms does allow creation of a c# compiler in their copyright stuff. So surely, there would be free c# compilers, debuggers in the future. But you do need to give ppl time to develop it. Dont u?There are many tools for software development in C++ and there are a lot of free tools. Free compilers, debuggers etc.
C# will soon get old too. I am talking not abt the current situation here but what the situation would be in a few years to come.C# and .NET are relatively new. C++ is much older and there is a lot of knowledge and experience with using C++ and its tools.
So do u agree that atleast for windows enviroment, c# is much better for development than c++?If you asked someone else who is not developing for Windows platforms, you would get reasons why to use C++ instead of C#.
Many ppl seem are sayign that but things seem to be a bit different to me. Look at the msdn site. Ms just launched Visual j#. If they wanted to eradicate java they wouldnt have done so. It seems their prime concern is to promote .NET more than anything else in the world.If you asked someone else who is not developing for Windows platforms, you would get reasons why to use C++ instead of C#.
Well, u guysare talking so much abt performance. But on the ms side that seems to be the least important thing. I said exaclty would ms would say to you. With such high processor speeds whats the need to wory abt performance?And your point would be what?Well, 2Ghz machines are out nowdays
It seems intel and ms have a pact between them to promote each others products or something.
What exactly do u mean by that?C# won't "take over", but it will make things interesting.
My main question right now- For developing windows apps isnt c# waaaay better than c++?
P.S.- This is MovingFulcrum only. Sorry not logged in right now
I'm quite certain that you will see C# move strongly into the embedded system market especially since developers are working on a lightweight .net framework in which you will be able to use VS.NET.
You must realize that the .net framework is middleware. It is simply designed to offer programmers a higher level of abstraction to build and deploy software components. The framework has a common type system and therefore C# is not a great deal different than VB.NET or C++.NET. All of these languages are managed. You can use the VS.Net debugger to compile seemlessly across any of the the managed languages as well as unmanaged C++ and code used to interface with the .net enterprise servers (exchange 2000, SQL, etc).
There is no conflict between C++ and C#. VS.Net fully supports C++. You can tag your code as unmanaged at any point if you want to use native C++, you can also make external calls to Win32 or Win64. Certainly C/C++ is more powerful than C#, however it is far less productive when put to a release schedule and it is also far more error prone, and it is certainly less portable (since it must be compiled to X86 machine code for the target OS). The .net framework Intermediate Language is portable to all operating systems that have build their own framework and have met the Ecma Common Language Infrastructure (CLI) specification.
The only thing that you can say about C# when comparing it to C++ is that the syntax is indeed much cleaner, however you should be comparing C++ with the .net framework instead of C# if you want to measure performance. Compare the C++ STL to the .net Base Class Library (BCL).
Another thing about managed code is that if I can build a powerful game with managed code, why would I want to write 5 times as many lines of error prone code in C++ to do the same thing?
Last edited by Osama Lives; 05-01-2002 at 04:58 AM.
>With such high processor speeds whats the need to wory abt performance?
Because a few apps demand it. I don't often see marketing hype from Intel/AMD stating "buy our new processor, it allows developers to code in higher level languages so your software will be less buggy/late". Higher clockspeeds makes worrying about performance less important (and lower level languages become more specialised tools), but I don't think we're at a point yet where you'll see a cutting edge game/app developed in C# using the net framework. Alot of programmers may only ever program relatively non-performance intensive apps, but that doesn't mean that the other type of app doesn't exist.
>Another thing about managed code is that if I can build a powerful game with managed code, why would I want to write 5 times as many lines of error prone code in C++ to do the same thing?<
I'd agree if you were developing a standard grey box Windows app, but I'd guess that your 5 times code saving for a "powerful game" is a slight exaggeration. Also people may not agree that your game is all that powerful when the garbage collector kicks in at some crucial moment destroying the frame rate. So you may end up writing a fair proportion of it as unmanaged (I'm not sure if there is a way of preventing this using managed code) .
Games are probably the most sophisticated type of application you can write. I have heard some talk of MS incorporating DirectX into the .net framework in a future version.
I would certainly use the framework for building Windows applications as well as web applications, but you can also use it to write games, although you will no doubt need to use Directx to interoperate with Win32, so your project will not likely be all managed. This might change though, and the framework is still new. It will be continually improved. Do not equate the BCL with MFC. Even Pretzel says that the BCL is far more richer than MFC.
I think that programmers should learn C and Win32, but I also think that they would be fools not to use middleware. You should learn Win32 only for the sake of those few things that can not be done with middleware, and than it depends on what type of application you are building. Middleware is making a strong move, look at Java. This is the proper way to program.
I also see no challenge to C/C++. Those will always be the bread and butter because they are the blueprint architecture that defines the operating system. The subsystems for USER, KERNEL, and GDI are all written in C.
>Games are probably the most sophisticated type of application you can write.
Programmers working at somewhere like NASA might disagree there.
>Even Pretzel says that the BCL is far more richer than MFC.
Yes Dean, but MFC requires you to make Win32 calls. I don't think it's ever been marketed as a substitute. Petzolds C# book, while probably very good, doesn't cover the same amount of ground as his Win32 books. Although this may be due to the imaturity of the net framework.
>This is the proper way to program.
No, as with most programming languages, it's a compromise.
>I also see no challenge to C/C++.
Then, either you don't know C++, or you've never learned how to use a library. C# offers nothing that most would consider a challenge to a reasonably competent C++ programmer (it being a dumbed down version).
>So do u agree that atleast for windows enviroment, c# is much better for development than c++?
There's no such as better. But I think that programming C# is more suitable than C++, at least, at some level. For more low level applications and applications which require more performance, I can imagine that C++ is more suitable.
>It seems their prime concern is to promote .NET more than anything else in the world.
That's correct. .NET is the main subject in their total vision on the future. I'm working in the automotive industry and MS is also trying to get in there. Also with the .NET based vision, for the automotive industry they've created an architecture called Car.NET. Currently BMW is using Windows CE For Automotive in a new series of cars. But in a different series of cars they use VxWorks and Java. I've heard that Windows CE is quite stable, so perhaps MS will succeed in getting the .NET vision in the automotive industry.
>But on the ms side that seems to be the least important thing.
You have to make a difference between applications. Sure, on a PC, performance doesn't bother most people really much. But when talking about medical applications, safety applications, performance is very important.
>I'm quite certain that you will see C# move strongly into the embedded system market especially since developers are working on a lightweight .net
>framework in which you will be able to use VS.NET.
C# is already moved into the embedded system market, but not very strongly. At this moment Java is used far more than C#. But note that when talking about these languages in relation to embedded systems, you're talking about the higher level applications in devices. Lower level software requires languages like C and C++.
>Games are probably the most sophisticated type of application you can write.
There are far more sophisticated types of applications. Like Sorensen mentioned, for example NASA. But also software for audio processing, GPS navigation, medical applications and many more applications are far more sophisticated then games.
>I think that programmers should learn C and Win32,
If they want to program MS Windows applications, then they have to know C and Win32. But don't forget that there are many programmer's who don't program for the MS Windows platform.
Last edited by Shiro; 05-04-2002 at 03:14 AM.
>>many more applications are far more sophisticated then games
I believe what he was refering to is that games will require a vast amount of knowledge about many different aspects of programming. Sophistication would be the wrong word. ... Although if you've seen some of the insides of the D3D stuff... whew!
"There's always another way"
-lightatdawn (lightatdawn.cprogramming.com)
I don't see why it makes more sense to plow a field with a rake rather than to use a tractor to do it. There are too many things C/C++ do not offer that a framework takes care of such as dll versioning and managed code to name a couple, yet I am no expert in .net, there is surely much more, not just in .net but also java and the JVM. I think it is foolish to not use middleware.
>>I think it is foolish to not use middleware
Unless of course you are programming games... Or any other application where speed is key for that matter.
>>I don't see why it makes more sense to plow a field with a rake rather than to use a tractor to do it.
But would you use a tractor in your rose garden? Everything has its pros and cons. Middleware makes it easier to develop (in most cases) but if you're looking for precision then its best to not rely to heavily on someone elses code and redundant features.
"There's always another way"
-lightatdawn (lightatdawn.cprogramming.com)
I don't see your point. I would use .net to write games or any other aplication. The great thing is that it compiles to machine code and if I need to deallocate something than I can dispose of it or else let the garbage collector do it, my choice. There is no app that I can't build.
The .net framework will open up new areas of internet development especially for games.
>The great thing is that it compiles to machine code
That's not an argument to use .NET to write software, also C and C++ compilers, and ofcourse many other languages, compile to machine code.
>There is no app that I can't build.
Really? What about an OS? Or a linux device driver? Or a piece of software for a 8051 or other microcontroller?
>The .net framework will open up new areas of internet development especially for games.
I agree with that. .NET and J2EE offer 'new' possibilities in programming. A very nice application I've seen using the JVM is remote software updating and remote software loading of devices.
You have to make a difference between applications. Sure, on a PC, performance doesn't bother most people really much.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Most people working with PC's do stuff like wordprocessing, requesting and filling databases, making calculations with spreadsheets, e-mailing etc. Then you don't care if saving a document does take a second more or less.
But when you're, for example, creating a piece of software to control a medical instrument, performance requirements are much higher. If the instrument is used to repair damages to vital organs, the software needs to be extremely accurate.
