VC++.Net VS C#

[Fuzzy Bear]

Is c# really worth learning or is managed c++ just as good or better? . What are the advantages and disadvantages between the two? Is vc++.net just like vc++6? Would you consider learning c# and why? Do you need to know managed c++ to use vc++.net?

[dandman]

VC++.Net VS C#

(Here we go :-))

Is c# really worth learning or is managed c++ just as good or better?

With managed extensions, VC.Net becomes a .Net compliant language, and since all .Net compliant languages execute via the Common Language Runtime, I would say that on a ".Net" level, the languages are the same.

. What are the advantages and disadvantages between the two?

VC.Net is the only language (so far), that you can intermix managed and unmanaged code, and compile to the same assembly. With this, you can preserve existing investments in code by "wrapping" to __gc classes.

... C#, perhaps has one up on VC.Net with it's visual Windows Forms designer, something the VC community has sought after ever since VB came around (... and especially the MFC folks) with it's RAD capabilities.

Is vc++.net just like vc++6?

Improvements have been made to the compiler and the optimizer, and VC.net seems to be more ansi compliant. This is a good thing if you plan to port apps to other platforms.
As far as the IDE... I feel the changes to be rather pleasant. It takes some getting used to, but everything seems to be "right there" (... after you find it). The workspace view shows macros and contants, and you can traverse a hierarchial object model in it or the object browser.

Would you consider learning c# and why?

Of course. If you have the time... why not learn it? It would only be another tool in your arsenal of programming skills. The IT world is constantly changing, always dynamic. We all must keep up with the times... however, not at the expense of the moment.

Do you need to know managed c++ to use vc++.net?

No. As stated earlier, managed extensions simply extend C++ to be .Net compliant, and that's not to say you have to use it at all. The only time you need to use managed extensions is when you want to have some type of involvment with the .Net framework. Otherwise, you can still build ATL, MFC and Win32 apps (to name a few...) that you could in VC6.

Good luck, Dan I

[Manish Malik]

Originally posted by dandman
VC.Net is the only language (so far), that you can intermix managed and unmanaged code, and compile to the same assembly. With this, you can preserve existing investments in code by "wrapping" to __gc classes.

yup. This is one of the greatest advantages till yet...it lets you exploits a lot of areas with much ease.

[Justis]

I'm having a problem doing just that.
I have non-managed code I would like to compile as a .NET assembly.
If I try to convert the participating classes to __gc classes, all **** breaks loose.
Is there any other way of creating an assembly out of non-managed code?
I should mention that I use STL containers as well, and they particularily cause me problems with the conversion between managed and non-managed codes.

Thanks,
j.

[vicodin451]

I use STL containers as well, and they particularily cause me problems with the conversion between managed and non-managed codes

Why not use some of the container classes in the .NET Framework?

[Justis]

Becuase I wish not to totally rewrite the code.
Plus, correct me if I'm wrong, if I use .NET containers, I could only store managed objects in them, which would result in even more rewriting of code.

Also, I have made some research and read about the cc command line compiler that allows C++ code to be compiled to an assembly. (It generates the IL and everything for you.)
Anyone experienced doing that?

And on another note, if I cant use STL or my unmanaged code within .NET, then where's the interoperability and compatibility promises gone?
j.

[vicodin451]

Originally posted by Justis
And on another note, if I cant use STL or my unmanaged code within .NET, then where's the interoperability and compatibility promises gone?
j.

I never said one couldn't do that; you said you had problems getting the STL into a mixed environment, and I immediately thought "why not use the framework container classes?". Now I know why you don't wish to do so...

[Justis]

How would one mix STL in a .NET environment then, assuming STL containers cant hold managed objects and the complexity of using non-managed objects with .NET?

Thanks,
j.

[vicodin451]

How would one mix STL in a .NET environment then, assuming STL containers cant hold managed objects and the complexity of using non-managed objects with .NET?

I guess I wasn't envisioning intermingling managed objects and the STL containers directly. I can easily see an assembly with managed/unmanaged code; Parts of the unmanaged code are using the STL, including containers; parts of the managed code are using the containers and other classes provided by the framework. It's generic and probably overly general, and probably doesn't match what you are trying to do, but it fits the general "mixing STL in a .NET environment" scenario, at least in my eyes.

[kasracer]

Originally posted by dandman
... C#, perhaps has one up on VC.Net with it's visual Windows Forms designer, something the VC community has sought after ever since VB came around (... and especially the MFC folks) with it's RAD capabilities.

Uh.... try to make a VC++ .NET managed Windows application. It has the EXACT same form designer.