New to C#

[Guest]

Just asking for some advice.
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. Since I have a background with C++ I started
developing windows forms with C++. However, documentation sucks for C++ and
windows forms development. MSDN and most other technical literature seem to
cater to C# and .net/windows forms. This is unfortunate because I will have
to learn C# apparently (actually I love learning new computer languages
lol). 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? What is the longevity/long term plans from microsoft regarding
C++? Is there any WORTHY literature regarding C++ and windows forms? 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. Anyway, if I stick with C#, can you
recommend any good literature, especially with sockets. 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++, but I noticed XNA is pretty
exculsive to C#, which is to be expected given the nature of the structure
of C#, XNA, and .net. Hey guys sell me on C# lol Really though C# is
impressing me, 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. Thx.

 

[Peter Duniho]

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

 

[Guest]

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

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

 

[Guest]

In response to the multithreading question I had asked. I do not use managed
threading. That is one of the things I love about C++ and the WIN32 API.
There is a plethora of implementations for threading, and I find it much
easier to handle thread security, sychronization, etc., myself. You
discussed "...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)..."
Perhaps someone could direct me to documentation to accomplish the
preceeding quote.
G

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

 

[hjgvhv uhhgvjuhv]

In response to the multithreading question I had asked. I do not use
managed threading. That is one of the things I love about C++ and the
WIN32 API. There is a plethora of implementations for threading, and I
find it much easier to handle thread security, sychronization, etc.,
myself. You discussed "...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)..."
Perhaps someone could direct me to documentation to accomplish the
preceeding quote.
G

Western English is not your first language, is it.

donald

 

[Peter Duniho]

In response to the multithreading question I had asked. I do not use
managed threading. That is one of the things I love about C++ and the
WIN32 API. There is a plethora of implementations for threading, and I
find it much easier to handle thread security, sychronization, etc.,
myself.

Well, I still don't understand that comment. .NET offers plenty in the
way of the above, and simplifies many of those things as far as I'm
concerned.

But each to his own. If you find .NET threading complicated or difficult,
who am I to debate that?

You discussed "...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)..."
Perhaps someone could direct me to documentation to accomplish the
preceeding quote.

I don't know of any documentation per se. The point is that managed
C++ still "understands" the native Windows stuff as well. It's sort of
like C++ supporting all the original C constructs. There's nothing
special to using them together; you just do.

With .NET, you can add an assembly as a reference to a project. This is
like adding a library (static or import) in a non-managed project. So,
you write the C++ component, in which you want to use native Windows
stuff, include a managed class that is exported in the assembly and which
a C# project can refer to, and then add the resulting C++ assembly as a
reference to the C# project. Voila, the C# project now has access to the
managed portion of the C++ project, while that C++ project still has
access to the native Windows stuff.

How you handle the "glue" internally to the C++ project is up to you.
Simple types convert automatically, while .NET also provides ways to
"marshall" data back and forth (similar to what is required for
cross-process COM/OLE calls, if you're familiar with that).

Pretty much anything you can do this way can also be done using p/invoke,
as far as I know. The problem for me is that (as I mentioned before)
documentation for p/invoke is pretty thin and I have found it very
challenging to find any reference that gives good guidance regarding the
magical incantation to use when using p/invoke. For simple things, it's
pretty straightforward, but there are lots of places where things are not
so simple and I've given up (for the moment) trying to figure it out. I
just write a C++ wrapper that exposes the functionality I need and then
access the native Windows API directly from there (as I described above).

Pete

 

[Peter Duniho]

Western English is not your first language, is it.

Whether it is or not, how is that relevant?

 

[hjgvhv uhhgvjuhv]

Whether it is or not, how is that relevant?

Big run on sentences are hard to read.

You were asked to used line breaks, but you ignored that as well.

I hope you do not write your code this way.

But, you are right, its not relevant. Just an observation.

donald

 

[Peter Duniho]

Big run on sentences are hard to read.

I agree. I don't see what that has to do with a person's native
language. Plenty of people who are native English speakers don't know how
to use the language properly.

You were asked to used line breaks, but you ignored that as well.

I was? I did?

If you're going to go around criticizing people, you ought to at least
keep straight who you're criticizing.

I hope you do not write your code this way.

But, you are right, its not relevant. Just an observation.

I find it odd you felt a need to voice the observation out loud.

Pete

 

[Guest]

Thank you Peter, I do appreciate your feedback.

I do apologize for the less than perfect formatting in my posts. Western
English is my first language, and C++, Pascal, Fortran, Assembly, Basic,
PHP, HTML, CSS, (and now C#) and a host of other programming/scripting
languages are my secondary languages.

Perhaps being anal about the formatting of how people post is a little
trivial and immature, when the criticism is taken to the extent that hjgvhv
uhhgvjuhv has done so.

I do respect your feedback Peter and will attempt to format more
appropriately.

What is significant is that I have less time than I desire to work on
projects that I enjoy, and the posts that you see here are frequently done
late at night before bed. At that point in the day I am tired and personally
I do not care what the formatting looks like. You will find that the
spelling is done well in addition to the grammatical usage. That is what
matters.

So thank you Peter for your feedback and advice and hjgvhv uhhgvjuhv you
need to get a life or go be an English teacher.

Remember, the purpose of the NG is to help others, not to teach them English
and grammar. We get enough syntax errors from our compilers to worry about
it here.

G

 

[Guest]

And I am enjoying my .net experience
G

Thank you Peter, I do appreciate your feedback.

I do apologize for the less than perfect formatting in my posts. Western
English is my first language, and C++, Pascal, Fortran, Assembly, Basic,
PHP, HTML, CSS, (and now C#) and a host of other programming/scripting
languages are my secondary languages.

Perhaps being anal about the formatting of how people post is a little
trivial and immature, when the criticism is taken to the extent that
hjgvhv uhhgvjuhv has done so.

I do respect your feedback Peter and will attempt to format more
appropriately.

What is significant is that I have less time than I desire to work on
projects that I enjoy, and the posts that you see here are frequently done
late at night before bed. At that point in the day I am tired and
personally I do not care what the formatting looks like. You will find
that the spelling is done well in addition to the grammatical usage. That
is what matters.

So thank you Peter for your feedback and advice and hjgvhv uhhgvjuhv
you need to get a life or go be an English teacher.

Remember, the purpose of the NG is to help others, not to teach them
English and grammar. We get enough syntax errors from our compilers to
worry about it here.

G

 

[Kevin Spencer]

Hi Peter,

I have found the follwoing web site very instructive regarding using
PInvoke:

http://www.pinvoke.net/index.aspx

It isn't so much the code that is posted there, but the methodology that you
can see demonstrated. From studying the examples there, I've gotten a pretty
good handle on PInvoke, and can write my own whenever I need to now.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[mirko]

impressing me, 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. Thx.

worked for years in C++, now for years in C#, never regreted it.

 

[Andy]

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.

It should be failry easy to call out to C++ COM code using interop. I
wouldn't do that for multithreading or sockets though, because the
managed framework already provides those capabilities for you.. so
theres really no reason to make things more complex by trying to use
interop for something you can do natively in the framework.

One thing to consider moving forward; MS plans to phase out the Win32
API, probably sooner than later. Their end goal from what I
understand is to replace that API. So think of .Net as Win32s from
the Win3.1x days; its the newer API backported to the older OS to
allow developers to target the newer API and still run on the older
platforms.

 

[Peter Duniho]

I have found the follwoing web site very instructive regarding using
PInvoke:

http://www.pinvoke.net/index.aspx

Thanks...I'll give it a look.

Odd that one would have to go to a third-party site for documentation of
p/invoke. And I still wish that there was a comprehensive document on
MSDN that clearly gave all of the various syntax and options for
p/invoke. But hopefully this pinvoke.net site will do the trick. Thanks!

Pete

 

[Peter Duniho]

I have found the follwoing web site very instructive regarding using
PInvoke:

http://www.pinvoke.net/index.aspx

Doh. Figures. I can only get that web site to work under IE. Opera and
Safari (the two browsers I use daily), the navigation bar on the left
doesn't work at all. Fortunately, search still seems to work okay, but it
does limit the usefulness of the site, since one can't really browse
without the navigation bar working.

Still, it may be the best resource out there at the moment. I suppose
that's something.

Pete