I have no experience and no interest in C#. I think in the long run, C# could become more popular than among first-time and average Windows programmers. Nonetheless, C/C++ with help from MFC and Win32 API will be around for a long time.

Microsoft will try to use C# for its upcoming Windows OSs, thus pushing C# popularity.

Personally, I am staying away from C#. Remember, C# is "managed" C++. C++ is currently the most dynamic, most extensible programming language. C++ inherits both low-level (C) and high-level (OOP) paradigms. We all know C is used for OS at the kernel level.

Kuphryn

quote:Original post by kuphryn
Remember, C# is "managed" C++.

Uh, I don''t know enough about .Net to be 100% sure about this, but I think that''s wrong. Managed C++ != C#

Btw, does anyone use managed C++? Is it worth it? Do we have to actually port our code, or does managed C++ stay fairly close to unmanaged C++?

Cédric

quote:C# is not manage C++, it is a seperate language, but it IS managed. It runs on a VM and thus it is slower than native code. And you are correct that there isnt any use for MFC in C#. In C#, you are 'supposed' to use the .Net Framework to do everything that MFC used to handle.

No, C# does NOT run on a VM. It is not an interpreted language like Java - it uses JIT (Just in time) compiling, meaning that the code is still eventually compiled to native code; therefore, I have to challenge your assertion that "it is slower than native code."

Here's a good article on .Net: http://arstechnica.com/paedia/n/net/net-1.html

[edited by - ares32585 on August 31, 2002 4:34:40 PM]

[edited by - ares32585 on August 31, 2002 4:35:14 PM]

Lots of questions... If anyone cares to enlighten, I would be greatfull, otherwise I''ll just wait until all the hype dies down and we see if C# is just another J++.

I don''t know very much about C# and what it might be used for. Microsoft must have designed it with some niche in mind, or some grand vision of what it would replace or how it would be used...

What is the intended purpose of C#? Is it a RAD tool like Visual Basic but with C++ as a base language? Is it the next M$ attempt to try to supplant Java and in what areas?

Does C# have an interpreter/VM like Java that needs to be rewritten/reimplemented for each OS? I would guess it doesn''t have an OS independent GUI library like Java''s Swing/AWT, and this strongly limits it use. Does it have built in support for threading like Java, or do you have to use the OS-specific threading APIs? I guess what I''m getting at, is how cross platform is it truely?

One other thing I was curious about, is how much support is there for running managed .NET code on Linux? People keep going on about how about how .NET is a cross platform, cross OS standard.

Here's an article on C# MS C# Also, the article I linked above should answer lots of questions about .Net. Lastly, I don't know whether .Net would be considered "OS-independent," but I do know that a Unix version of the .Net framework is being developed: Mono

[edited by - ares32585 on August 31, 2002 5:05:03 PM]

Z01:
If you only use managed code (no P/Invoke or other platform-specific code) then your DLLs/EXEs will be binary compatable on any computer that has a .NET framework. Microsft''s framework runs on Windows (from 98 through Windows.NET 64) and they''ve released a BSD version (with source). The group that writes Gnome for linux is porting the framework to linux (the ::mono project).

The framework is also designed to be language-independant (C#, VB.NET, Managed C++, J#, COBOL.NET, Delphi.NET, etc) and just-in-time compiled whereas java byte codes were designed to be interepreted and used by one language.

The .NET framework is HUGE...full threading control, thread pools, graphics and drawing, "windows" forms, crypto, dynamic code generation and compilation, regular expressions, many layers of network abstraction (from HTTP objects down to sockets), web forms, XML (SOAP, "standard", and custom) serialization and deserialization, runtime security, debug/tracing, performance counters, event logs, full runtime reflection, and a whole bunch of other stuff.

The only reason I''ve needed to use platform-specific things is because of 3rd party APIs...which is just for my ease...luckily said 3rd parties are slowly starting to dev things in managed code.

I certainly wouldn''t take my word about .NET though...try it for yourself: Download the free SDK (includes full VB.NET and C# compilers) and take it for a spin...

Epolevne