Archived

This topic is now archived and is closed to further replies.

Is MFC dead now that we have C#?

This topic is 5580 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I don''t have much experience with visual C#.net. I only installed it a week ago. I liked it becasuse it is exactly what I thought it would be...a cross between visual basic and C++. That idea is in itself is appealing, but it also makes me upset because there seems to be no use for the MFC which I have also been trying to learn. C# seems to be by far the best way to quickly create powerful solutions for the windows platform. All comments are welcome, I hope this is a big discussion.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

"The Requested Information Is Unknown Or Classified" -Anonymous

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
quote:
Original post by kuphryn
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


C++ may, as a language, be more powerful than C#, (you''re right, it''s true) but that''s irrelevant. One of .NET''s greatest strengths is that it''s so easy to mix managed and unmanaged code. One would be wise to C# wherever one can get away with it, because it''s so much easier to read and write and use. If one later finds that the extra speed is needed somewhere, then one can use C++ for that section. The integration between the two is almost seamless.

MFC''s days outside of "legacy" situations are numbered, I think. Writing GUI apps with Winforms is so much easier that it''s not even funny.

I think Microsoft''s biggest mistake was in exposing win32 in the winforms API. (you don''t need to use, or even know win32 to use winforms, but you can do some neat things that the winforms API doesn''t expose if you do know it) On one hand, it makes it easy to extend the existing classes easily. But, on the other, it means that win32 is still being used, only with nicer class wrappers. So much for phasing out old crummy APIs. :\

quote:
Original post by cedricl
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++?



In my experience, no. Managed C++ is essentially C# with C++ syntax. Avoid it for "real" programming. It does, however, excel as a glue between unmanaged C++ (the real thing) and managed code. You can write managed or unmanaged code on a per-function level, as far as I can tell. Even to the point of putting inline assembly in the code. There are some issues with templates, though. The compiler tends to go bonkers when you try to use them directly in managed classes. I''ll have to play around a bit more. (obviously, managed template classes aren''t an option, but there are some issues with using, for example, STL containers in managed classes)

quote:
Original post by Z01
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.



I''ve found that C# does fill in the RAD gap quite nicely. And yes, it does seem to be intended to strike at Java. And they did a good job too. I''m hoping that Sun will realize just how good C# is, and respond with an even better Java. (competition is so cool)

Winforms is a bit too close to win32 to be easily portable, but it''s definitely possible. There are two efforts I''m aware of, GTK#, and another using wine as a base.

mono is Ximian''s effort to implement the .NET framework on linux. It''s already well under way. (you can code C# on linux, and, while the class library isn''t finished, very large portions of it are already quite usable)

On one final note, managed code is slower than native C++. I''m not entirely sure why, but I''ve seen it firsthand. Not agonizingly slow, mind you. But noticibly so.

Share this post


Link to post
Share on other sites
Thanks for all the replies

It looks like M$ may have a winner here, I''m still reading all the references...

The interesting part is that some of the important parts of .NET are based upon open standards, and M$ is moving away from its dependence on the Windows OS.

Microsoft''s traditional business strategy has been to use its OS dominance to monopolize other markets - like internet browers and office applications. They are weaking their own market position with .NET. The other M$ trick I know is they take a set of standards and modify them a bit and add other features (this was what was in that leaked M$ market strategy document a few years ago), and then their competitors software doesn''t work so well anymore... sort of what happened to Netscape. Since quite a bit of .NET is "open", they are going to have a harder time doing this.

Share this post


Link to post
Share on other sites
quote:
It is not an interpreted language like Java - it uses JIT (Just in time) compiling,
quote:
The framework is ... just-in-time compiled whereas java byte codes were designed to be interepreted
Java has been using JIT compiling for a very long time now. Heck, even Microsoft's ancient VM includes a JIT compiler. You can also staticly compile Java into native code using compilers such as JET or GCJ.

[edited by - HenryAPe on September 1, 2002 10:17:44 AM]

Share this post


Link to post
Share on other sites
quote:
It looks like M$ may have a winner here, I''m still reading all the references...


Do you get off over making the S in Microsoft a dollar sign? Because if you''re going to make the $ in MS a dollar sign, you might as well do the same thing for Sun''s ($un) name, because I''m pretty sure they''re just as interested in making money as MS is.


quote:
Java has been using JIT compiling for a very long time now. Heck, even Microsoft''s ancient VM includes a JIT compiler. You can also staticly compile Java into native code using compilers such as JET or GCJ.


Ok, I didn''t know that, but wasn''t Java originally interpreted, though?

Share this post


Link to post
Share on other sites
It was originally interpereted - even today SUN''s hotspot is more dynamic than .NET.
The .NET "JIT" is precompiling functions and storing them to disc, trying to inline subfunctions occasionally. You can go native with a tool (ngen.exe) that compiles a whole dll into the cache.

Anyhow, managed C++ is a great too lfor the glue - there are some API''s around that you just can not use easily from C# (like CAPI, for example). Here Managed C++ allows you to run some tricks - lie using (in the CPAI case) an SDK provided as C++ link llibrary :-)

Other than that (no, for GUI things in particular), switching over to C# is way easier, although VS.NET Everett will have a C++ forms generator.


Regards

Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)

Share this post


Link to post
Share on other sites
I understand what C# is for, and what it''s "purpose" is. And I like it. It''s like a next level of Java, and seems pretty powerful, but what is the point of managed C++? It''s not portable, there''s no way to make compiled code portable. So what does it do? What do you have to type in differently that makes it "managed"? That''s probably the only thing I don''t understand about .NET.

Also, a side point to the talk about mono, FreeBSD, and .NET. I havn''t been able to find any mention in some quick searching that said that M$ is making the port to FreeBSD. I''ve read that they will allow a port, but not that they personally are making the port. Anyone have a link on that one? Also, mono is not connected with M$ in any way. I want to make sure people understand this, they are making a linux port on their own. They have no connection. First time reading through the posts, I almost thought someone meant that and I want to try and help clear that up.

On a completely OT point. Writing M$ to refer to Microsoft is not childish. Personally it is my way of making a small statement about how I feel about their business practices and to express my discontent about them. It is not about them wanting to make money, it is about them wanting to crush anyone that stands in their way. I could go on, but I won''t. It would be a moot point and has been argued to death elsewhere. Just understand that for some of us, the $ is a statement of our feelings, not a childish babble.

Always remember, you''''re unique. Just like everyone else.

Share this post


Link to post
Share on other sites
One major drawback I see of C# as well as all other corporate owned programming languages and tools such as VB and Java is the fact that you have to have very specific tools to use them.

With C# and VB, you will need a Microsoft Windows OS and Visual Studio .NET. How about Linux and Mac? Although, I have very limited experience with Linux and I will probably never use a Mac.

Java is more portable, but it still requires the Java run-time.

The bottomline is you should look at a programming tool you plan to learn and use from all perspectives. For Windows, I believe C# and VB should be much easier to use than C++. I have no experience using C# or VB. For Linux, I think C/C++ a preferred programming language.

I think all programmers should know a core language such as ASM, C/C++, Pascal, etc. very well before learning a language for a specific OS like C#, Java, and VB. Furthermore, the same concept applies to programming tools like MFC and whatever Borland uses for its C++ GUI.

I use MFC to develope Windows program. The only reason I use MFC is because I do not want to mess with all the GUI Win32 API tools. I let MFC take care of the GUI and messages. However, underneith the MFC doc/view frameworks I implement core C++ algorithms. Furthermore, I could use those C++ algorithms almost anywhere including DOS and Linux.

Learn and use a programming language and tool that you feel is most extensible first. Then you could learn more OS specific languages. Otherwise, what are you going to do when corporations like Microsoft stop supporting MFC, VB, or C#? What if SUN stops supporting Java because programmers prefer C#?

Kuphryn

Share this post


Link to post
Share on other sites
quote:
Original post by kuphryn
C# as well as all other corporate owned programming languages


C# is standardized by the ECMA along with major parts of the class library.
quote:

With C# and VB, you will need a Microsoft Windows OS and Visual Studio .NET.


Compilers for both C# and VB.NET are available for free in the .NET Framework SDK. The Mono C# compiler(that should run on various UNIXes) is now selfhosting.


"When you know the LORD you have no need for masturbation!"

Share this post


Link to post
Share on other sites
quote:
Original post by Greven
On a completely OT point. Writing M$ to refer to Microsoft is not childish. Personally it is my way of making a small statement about how I feel about their business practices and to express my discontent about them. It is not about them wanting to make money, it is about them wanting to crush anyone that stands in their way. I could go on, but I won't. It would be a moot point and has been argued to death elsewhere. Just understand that for some of us, the $ is a statement of our feelings, not a childish babble.



Microsoft is a company like any other. ;P They're not out to "get you" any more than any other large corporation out there. The problem lies in the simple fact that there's no competition. Things would be just peachy (pretty awesome, in fact) if there was another evil superconglomerate that was at once on even footing with Microsoft, and in direct competition with it.

I'm hip because I say "M$" instead of "MS".

[edited by - the Speed Bump on September 1, 2002 1:42:02 PM]

Share this post


Link to post
Share on other sites
HenryApe:
.NET''s MSIL was DESIGNED to be JIT''d...whereas java''s byte code was not. The emphasis was on the original design of the byte codes (the "legacy code" if you will), not the evolution that happened afterward. This design difference leads to major differences in the use of the stack and other areas that make JIT engines faster/more efficient. It''s one of the reasons that the 1st generation .NET JITer is as fast as 4th (or more?) generation Java JITers.

Epolevne

Share this post


Link to post
Share on other sites
quote:
Microsoft is a company like any other.

Considering Microsoft''s court history, it might be correct to say that they are a company like maybe Standard Oil, but not like "any other".

quote:
It''s one of the reasons that the 1st generation .NET JITer is as fast as 4th (or more?) generation Java JITers.

Now, now, Microsoft were very early to include a JIT compiler in its IE VM, it would be surprising if they did not at least keep up with the evolution. It is a pity that they have banned the free publication of .NET performance benchmarks in their EULA, makes it hard to find any good information on the strengths and weaknesses of C# and their JIT compiler.

Share this post


Link to post
Share on other sites
quote:

It is a pity that they have banned the free publication of .NET performance benchmarks in their EULA, makes it hard to find any good information on the strengths and weaknesses of C# and their JIT compiler.


eheh. Yeah. *cough*

Looks like it''s a teensey bit faster than java, and a teensey bit better on memory too. But nowhere near C++.

I''m hip because I say "M$" instead of "MS".

Share this post


Link to post
Share on other sites
One interesting thing about those benchmarks: C# was one of the worst performers in the string concatenation test. However, if you look at the source, you will see that they perform string concatenation like this:

  
for (int i=0; i<N; i++) {
hello = String.Concat(hello, "hello\n");
}

This is of course the most idiotic way of doing a large number of string concatenations in .NET. Every single iteration of that loop will create a new String object.
Compare to the Java implementation, which uses the StringBuffer class:

  
for (int i=0; i<n; i++) {
stringBuffer.append(hello);
}

This will of course be orders of magnitude faster, since there are no object instantiations in the loop. The C# test should have done the same, using the .NET equivalent of StringBuffer called StringBuilder. The way the test is now, it is comparing apples and elephants.
And here I think we hit on some of the reasoning behind that clause in the EULA...


"When you know the LORD you have no need for masturbation!"

Share this post


Link to post
Share on other sites