If you want to learn C#, then learn C#. You can always come back to learn the other one some day.

02-19-2009

Elkvis

Quote:

Originally Posted by laserlight

If you want to learn C#, then learn C#. You can always come back to learn the other one some day.

Knowing C++ already, I found it very easy to learn C#. I have friends who learned C# first, and later learned C++, and most of them said it was hard to get used to the differences in C++.

02-20-2009

IceDane

Quote:

Originally Posted by Elkvis

Knowing C++ already, I found it very easy to learn C#. I have friends who learned C# first, and later learned C++, and most of them said it was hard to get used to the differences in C++.

It would not surprise me if this is a common issue for people going C#->C++, instead of the other way around.

Even in spite of C++ being(Or at least having the possibility to be) somewhat higher level than C, there are still things such as pointers, arrays and so on, which deal with things on a much lower level than you can in C#. This means that were you you start C++ with no idea of programming beforehand, you would be forced to learn the low level ways, and therefore, going a level higher will be cake.

Going the other way around; e.g. programming without ever having to deal with these things, then going to another language that's a level lower, where you do have to deal with them, will be much harder.

02-20-2009

matsp

Quote:

Originally Posted by IceDane

It would not surprise me if this is a common issue for people going C#->C++, instead of the other way around.

And not unique for C#->C++, but also applies to moving from any other language that "does memory management for you", such as Java, Python, Perl or Basic and many others.

C++ (and C) have very basic handling of memory - it requires programmer effort to maintain pointers to valid memory, and to ensure there are no memory leaks or other problems. (This is in the standard language - obviously, with sufficient code added on top of the standard language, we can CREATE the environment for "automatic memory management", e.g. Python and C# are written in C or C++, so obviously the memory management done by those languages can be written in C or C++).

Almost all other basic principles of C++ are identical between C#, Java, Python - there are some subtle differneces, but for most programmers, those are a simple case of "learning how to do it in this language".

The principles of managing your own memory is a bigger task to learn.

--
Mats

02-20-2009

Elkvis

the feedback I've heard is that it's not just memory management. knowing where to use -> and :: when you've been using the dot for everything can be confusing for some, and the fact that C++ doesn't keep track of how big an array is when you dynamically create it was frustrating for one of my friends a while back.

02-21-2009

IceDane

Quote:

Originally Posted by Elkvis

the feedback I've heard is that it's not just memory management. knowing where to use -> and :: when you've been using the dot for everything can be confusing for some, and the fact that C++ doesn't keep track of how big an array is when you dynamically create it was frustrating for one of my friends a while back.

It can be frustrating, yes, but it will in turn make you a better programmer to know how these things work. Deep down under C# and other similarly managed languages, unmanaged memory management is doing the work. Pointers are almost nonexistent in C#, but understanding them is pretty important in my opinion.

02-21-2009

Elysia

Quote:

Originally Posted by Elkvis

...and the fact that C++ doesn't keep track of how big an array is when you dynamically create it was frustrating for one of my friends a while back.

It does, if you use std::vector or std::tr1::array.
However, by default, it will not do bounds checking.
For dynamic arrays with vector, however, using the .at member function will guarantee that no out-of-bounds can be made.
boost::array also raises an assert if an out-of-bounds access is made.

02-21-2009

valaris

How about the fact that in theory, your code you write in C# should be language independent to other .net languages. IE a class you write in C# can be inherited from and expanded by a VB.net developer, and you can then take that class and use it in your app.

04-27-2009

ashinms

Yes. You helped. :)

04-27-2009

indigo0086

Quote:

Originally Posted by valaris

How about the fact that in theory, your code you write in C# should be language independent to other .net languages. IE a class you write in C# can be inherited from and expanded by a VB.net developer, and you can then take that class and use it in your app.

They're taking it a step further with C# 4.0, allowing you (with proper binding libraries of course) to call functions and instantiate objects dynamically across any language (javascript, python, ruby, etc).

That stuff is more advanced and may find little use but it's an interesting addition.

Personally I haven't done much stuff in C++ lately, would like to get back into it though. I prefer C# because of the frameworks it offers for web development (ASP.NET MVC) and desktop/web applications (WPF, silverlight).

04-30-2009

Sebastiani

C# might have a lot of connectivity features, but the truth is it's really just a big ole kludge. Besides that, any language lacking deterministic destructors just seems inherently flawed to me. I'd say stick with C++ unless you have no other choice.

04-30-2009

Cat

Quote:

Originally Posted by Sebastiani

C# might have a lot of connectivity features, but the truth is it's really just a big ole kludge. Besides that, any language lacking deterministic destructors just seems inherently flawed to me. I'd say stick with C++ unless you have no other choice.

You can still have the deterministic deallocation of resources via Dispose(). Plus, it helps improve performance -- if a large number of objects go out of scope at once, they don't need to all be destroyed immediately while your thread sits on its ass waiting. Rather, they can be garbage collected whenever there's time available to do so.

04-30-2009

laserlight

Quote:

Originally Posted by Cat

You can still have the deterministic deallocation of resources via Dispose().

hmm... I was surprised to hear that C# has deterministic destruction, but a quick check shows that Dispose() is not automatically called when the object goes out of scope, so that does not adequately address Sebastiani's point.

Quote:

Originally Posted by Cat

Plus, it helps improve performance -- if a large number of objects go out of scope at once, they don't need to all be destroyed immediately while your thread sits on its ass waiting.

A recent garbage collection discussion on the Boost mailing list gives me the impression that a well designed allocator would provide that benefit as well, though in this case it would be about delaying the freeing of memory since the objects would nonetheless be destroyed.

04-30-2009

valaris

Finalize() is called when an object is being deleted. It is in effect a destructor for C#, usually it's only used to free managed resources. Its syntax is also similar to C# as in ~ClassName();.