Re: New to C#

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Thank you for your response. Posted late at night, I hope I was clear with my questions. One last question perhaps. How easy is it to integrate WIN32 code from C++ and C# .net. An example might be multithreading with C++ and sockets with C++, and the UI with C# .Net.
G



"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message news:op.trre3yiz8jd0ej@xxxxxxxxxxxxxxxxxxxxxxx
On Wed, 02 May 2007 22:38:15 -0700, <gsx@xxxxxxxxxx> wrote:

Just asking for some advice.

Okay. Here's some: use a paragraph break once in awhile. :)

Seriously though...

I am a VS C++ developer. I develope using the WIN32 API, and frankly I love developing with C++. I do not program for MFC, MFC is pretty lame. In fact I have always steered clear of any managed code programming. However, I started messing with windows forms/.net and I really am liking it, for once managed code seems doable.

MFC isn't really managed code, but yes...I had the same reaction. I didn't like MFC very much, as it didn't seem to offer much to me that I couldn't do as easily using native Windows APIs. I also didn't like its use of C++ templates, or C++ templates in general, but C# generic types are much better. .NET is the first Windows API wrapper I've used where I felt I really got a significant reduction in development time, while not sacrificing important implementation capabilities.

[...] Anyway since most example code and documentation seems to cater to C# and not C++, would you all recommend a migration to C# for managed code programming?

Either to C# or VB.NET. Managed code in C++ is terrible IMHO, because the syntax is so weird. The usual C++ stuff has to coexist with .NET managed references, which results in a bunch of unwieldy code with ^'s all over the place. It's not really all that much more typing, but it just looks ugly to me.

Because I still haven't found any decent documentation for p/invoke stuff, I still do C++ stuff because it turns out that's often an easy way to accomplish the same thing (accessing native Windows stuff from C++ is *lots* easier than from C#, and you can use managed C++ to wrap up native Windows stuff without too much trouble). But for anything that's just managed code, I use C# all the time and think it's great.

What is the longevity/long term plans from microsoft regarding C++? Is there any WORTHY literature regarding C++ and windows forms?

All of the MSDN documentation has code samples in all languages supported by VS. That includes C++, and I doubt C++ is going way any time in the near future, and probably not even in the distant future. There are still too many situations where C++ is useful, and as long as anyone is writing non-managed applications I think C++ will be the language of choice.

But if you're writing managed code, you might as well go with C# instead of C++.

To be honest I am very impressed with C# so far, I have writtin a couple of test applications including a small client app for a server app I am developing. Just curious. One thing I do not like is the multithreading implementation in C# / .net, C++ does this much better.

Here I have no idea what you're talking about. Managed multi-threading in C++ is exactly the same as in C#. It's true that you can't as easily do unmanaged multi-threading in C#, but you shouldn't really be trying anyway. I find multi-threading in C# at least as easy as in C++, and for the most part more so because of the managed aspect of it.

Anyway, if I stick with C#, can you recommend any good literature, especially with sockets.

I can't say that I know of any good reading for .NET or C#. Practically everything I know about writing .NET, I learned from the MSDN documentation. Not the best way, I agree...but if you've already done Windows programming, and spend some time learning how the MSDN documentation is structured, it turns out to not be too bad. There's an art to figuring out where things are in the documentation, but I've found that at least 70-80% of the important information is readily accessible there.

As far as sockets particularly go, based on the questions I've seen here, much of what trips people up writing for the .NET Socket class is the same stuff that trips people up writing for any other socket API. #1 mistake is still failing to recognize TCP as stream-based rather than datagram (message) -based. IMHO the best thing someone could do before writing .NET Socket code is to read the Winsock FAQ. It has nothing to do with .NET, and yet all of the advice still applies.

Might as well make it literature for .net 3.0. And I would have really preferred all the support for developing games to be with C++,

It's true there's no straight-forward DirectX in .NET, if that's what you mean (other than DirectX I don't see that there's any "support for developing games" in C++...the language itself certainly has no game-development-specific features). But the latest .NET, v3.0, is supposed to have good 3D and animation support. If you're writing a FPS, I suspect native code is still better, but for a lot of games I'll bet WPF in .NET provides plenty of performance and is a lot quicker to write, once you've learned it (I haven't learned it yet, so my observations are purely hypothetical :) ).

[...] maybe some of you who have experience programming both C++ and C# can educate me regarding efficiency, flexibility, and other areas regarding the two languages.

I have lots more experience with C++ native Windows API than C# managed .NET API. So my insights into managed code are less than stellar. :) But as I've mentioned before in similar threads, one of my biggest enjoyments in writing .NET code is not wasting hours upon hours on implementing UI. Basic stuff is handled trivially with forms, and more elaborate UI can be done much more quickly in .NET, IMHO.

There are lots of other great leveraging technologies in .NET as well -- for example, automatic use of IOCP for Winsock through use of the .NET Socket class -- and I don't want to discount those. But UI is the one thing everyone will run into, and as such it's the easiest, most common example to point out.

Pete

.

Relevant Pages

  • Re: New to C#
    ... There is a plethora of implementations for threading, and I find it much easier to handle thread security, sychronization, etc., myself. ... Windows stuff without too much trouble)..." ... However, I started messing with windows forms/.net and I really am liking it, for once managed code seems doable. ... There are still too many situations where C++ is useful, and as long as anyone is writing non-managed applications I think C++ will be the language of choice. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: New to C#
    ... I do not program for MFC, ... However, I started messing with windows forms/.net and I really am liking it, for once managed code seems doable. ... I didn't like MFC very much, as it didn't seem to offer much to me that I couldn't do as easily using native Windows APIs. ... There are still too many situations where C++ is useful, and as long as anyone is writing non-managed applications I think C++ will be the language of choice. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Passing arguments on Windows (XP)
    ... getting the prgram to read from a socket and writing the arguments to ... However, I'm on Windows, and the manual says that reading/ ... writing from/to a socket doesn't work on Windows. ... exec yourprogram << $value ...
    (comp.lang.tcl)
  • Passing arguments on Windows (XP)
    ... which reads from stdin. ... getting the prgram to read from a socket and writing the arguments to ... However, I'm on Windows, and the manual says that reading/ ... writing from/to a socket doesn't work on Windows. ...
    (comp.lang.tcl)
  • Re: Passing arguments on Windows (XP)
    ... getting the prgram to read from a socket and writing the arguments to ... However, I'm on Windows, and the manual says that reading/ ... writing from/to a socket doesn't work on Windows. ... exec yourprogram << $value ...
    (comp.lang.tcl)