C++/CLI and C#

[irtaza]

GRRRRRRRRRRRRRRRRR!!!!!!!!!!!!

 

Im so double minded on whether to go with C++/CLI or C#. I dont know what to do.. :(

 

Any advice guys?

 

Im looking to develop Windows Forms App's with Power and ease. I have C++ Knowledge but seeing that there arent many resources for C++/CLI, im thinking about going with C# like the many C++ Programmers out there who are...Not that i dont like C++/CLI or C++, its just that C# is a "pure" .NET Language and will always be supported by Microsoft.I feel as if im being left out of the crowd by continueing to use C++/CLI because people are going to C# these days..

[David Anton]

The C++/CLI movement is gaining momentum...

It's going to be far more popular one year from now.

 

However, I doubt if anything in the .NET world can catch C# over the next couple of years though.

[irtaza]

I agree that C++/CLI will be more popular in an year, but overall its true to say that C# is the backbone of .NET.Dont forget that Next year C# Developers will be looking forward to C# 3.0 and LINQ, as well as VB.NET Developers.

[PlausiblyDamp]

If I didn't need to use C++/CLI then C# would be a far easier language to develop in and learn.

 

However in .Net 2 the syntax for C++/CLI does look a lot cleaner and easier to use than the previous versions.

[mskeel]

Give C# a try to see what all the buzz is about for yourself. If you like it, then great; if you don't, then nothing�s lost -- you can always go back to C++ or C++/CLI. If my project didn't have need for C++, I'd go with C# personally. Coming from C++, I found it very easy to learn C#. The syntax was familiar and there weren't as many rules such as all the various pointer operators. At the same time, you still put a semicolon at the end of each statement which just feels right in my opinion.

[irtaza]

Looks like im going with C#, very easy and at the same time powerful :D

[Arch4ngel]

Okay... here is my piece of advice.

 

I'm a C#/VB.NET programmer. I do Web/Desktop development and I'm pretty happy with the RAD I have now. However... I know that the .NET framework is still not "the way to go" with non-Microsoft OS. So... learning .NET platform was only for Microsoft-using customer. Good or bad choice? Dunno... but there is one thing that is still getting on my nerve today... I don't know C++. I want to learn it. I know that this language going to be compatible with Linux/Windows. The only thing that might change in between is the libraries.

 

You see? Since C++ is CLI compliant, you have an edge over me. I'm saying... learn the C++/CLI "proper way" and extrapolate exemples found in C#. You'll find yourself with more exemples than you can handle.

 

And for C++ .NET tutorial... take a look there: http://www.functionx.com/vcnet/index.htm

 

I would say to keep with C++ since you it's going to be needed for a long time and you can always convert your code to .NET. And while you process this quick conversion... you can always learn C# and take your time.

 

Cheers

[Denaes]

About once a month I want to learn C++. I have a on how to make RPGs with it.

 

I take down the book and I get to code that has "->" in it instead of a "." and I put the book away and say "Why the hell would I want to be pressing two keys for a '.' all day?".

 

True, I could remap my keyboard to make an arrow like that the '.' types '-' and '>', but it just annoys me.

 

Also my book is probobly now like 5+ years old and it gives examples in VC++ from the VB6 era. I think I'd get lost trying to use it with C++.Net/CLI

[irtaza]

Okay... here is my piece of advice.

 

I'm a C#/VB.NET programmer. I do Web/Desktop development and I'm pretty happy with the RAD I have now. However... I know that the .NET framework is still not "the way to go" with non-Microsoft OS. So... learning .NET platform was only for Microsoft-using customer. Good or bad choice? Dunno... but there is one thing that is still getting on my nerve today... I don't know C++. I want to learn it. I know that this language going to be compatible with Linux/Windows. The only thing that might change in between is the libraries.

 

You see? Since C++ is CLI compliant, you have an edge over me. I'm saying... learn the C++/CLI "proper way" and extrapolate exemples found in C#. You'll find yourself with more exemples than you can handle.

 

And for C++ .NET tutorial... take a look there: http://www.functionx.com/vcnet/index.htm

 

I would say to keep with C++ since you it's going to be needed for a long time and you can always convert your code to .NET. And while you process this quick conversion... you can always learn C# and take your time.

 

Cheers

 

C++/CLI doesnt have alot of books and resources.Plus,C# is more RAD.For cross platform development,there are more Java jobs out there than C++, so i would go for Java on that 1.

[mskeel]

I take down the book and I get to code that has "->" in it instead of a "." and I put the book away and say "Why the hell would I want to be pressing two keys for a '.' all day?".

It's not THAT bad. Are you a VB guy? It's no worse than having to type Function, End Function, Next, Dim, As, or any other large amount of letters in VB. C# is virtually identical except for the . versus ->/* thing but you do get some extra power with that so I think it's worth it.

[snarfblam]

-> is actually a shortcut. It is two operators in one: first it dereferences a pointer, then performs a member access. I would rather type var->member than (*var).member.

 

It becomes necessary in C++ because C++ makes a bigger distiction between the concept of a reference and an object. (This actually became a big topic of discussion a while ago. Should == compare for value equality or reference equality? In C# it can go either way, but in C++ it is clear cut: var == var2 compares pointers and *var == *var2 compares values.) Besides, if you don't like the -> operator, you don't have to use pointers. You can actually write code like this:

// No need for ->...
MyClass myVar;
myVar.Function(); 

// ...unless you want to use pointers and save some typing.
MyClass * pMyVar;
(*pMyVar).Function(); //I'm not positive that the parentheses are required
pMyVar->Function();