is c# better then c++?

[togerland]

What is easier to learn and does it work on linux?

[+Xinok Subscriber²]

I would argue that only professionals have any true reason to use C++. Newbies have no need for pointers, assembly, or manual memory management.

I would suggest learning C# with C (not C++) on the side. C will teach you low-level programming so you understand what's happening under the hood, while C# will teach you everything else and is the language you're more likely to use day to day.

The problem with C++ is a matter of poor design. It has so many hurdles and traps that it's a language that takes years to master.

[psreloaded]

Given the choice, Java is a better option than C# for cross-platform support.

I agree, for cross-platform support, java is better. But otherwise I find C# better. Visual Studio is a superb IDE and I find it far more polished than eclipse. Another thing to note is that Java is interpreted as far as I know while C# is not. So if you are counting on performance then Java is perhaps not the way to go.

Syntax wise, C# and Java are almost twins... libraries are obviously different though.

[GreenMartian]

I would argue that only professionals have any true reason to use C++. Newbies have no need for pointers, assembly, or manual memory management.

I would suggest learning C# with C (not C++) on the side. C will teach you low-level programming so you understand what's happening under the hood, while C# will teach you everything else and is the language you're more likely to use day to day.

The problem with C++ is a matter of poor design. It has so many hurdles and traps that it's a language that takes years to master.

I absolutely agree with this. I have seen enough horrible code in my lifetime made by coders that don't understand the underlying processes, thinking that the framework would "just do it" for them (which, most of the time it does, just not in an efficient way if you don't really know what's happening).

[MFH]

I've heard that from Herb Sutter and it's quite amusing. Yes, most of C++'s library has its complexities documented, but maybe because there isn't much more than containers and algorithms in the C++SL... Containers and algorithms in .NET also have their algorithmic complexities documented, but there is no point documenting the algorithmic complexity of a Printer or Socket class.

I think you got it wrong. Due to the fact, that .NET and Java use OO and a whole lot of interface cruft for their containers' interfaces (opposed to C++'s container definition) you actually can't rely on the complexity of the containers in them - especially if you're using collections that are returned from foreign code. For example what does the List<XYZ> guarantee in terms of complexity in Java? Well nothing really, as it's an interface, List<XYZ> may actually be an array (class ArrayList) or it may be a linked list -> totally different complexities (and memory layouts -> access patterns) are involved here! You have no way of telling which one it is based on List<XYZ>. A similar thing happens in .NET?

Let's compare that to std::list<XYZ>: what does it guarantee? Well quite a bit:

1. The elements are stored in a double-linked list - there is no way around that bit!

2. Every operation on this list has a well defined complexity that no standard conforming implementation is allowed to break

2a. Insertion at front and back: O(1)

[3. Compared to Java: this list is really type safe (opposed to Java's type erasure "hack") - at least that one Microsoft got right?]

[georgevella]

I think you got it wrong. Due to the fact, that .NET and Java use OO and a whole lot of interface cruft for their containers' interfaces (opposed to C++'s container definition) you actually can't rely on the complexity of the containers in them - especially if you're using collections that are returned from foreign code. For example what does the List<XYZ> guarantee in terms of complexity in Java? Well nothing really, as it's an interface, List<XYZ> may actually be an array (class ArrayList) or it may be a linked list -> totally different complexities (and memory layouts -> access patterns) are involved here! You have no way of telling which one it is based on List<XYZ>. A similar thing happens in .NET?

Let's compare that to std::list<XYZ>: what does it guarantee? Well quite a bit:

1. The elements are stored in a double-linked list - there is no way around that bit!

2. Every operation on this list has a well defined complexity that no standard conforming implementation is allowed to break

2a. Insertion at front and back: O(1)

[3. Compared to Java: this list is really type safe (opposed to Java's type erasure "hack") - at least that one Microsoft got right?]

List<T>, ArrayList and LinkedList<T> are three different implementations in .NET, not interfaces; you are probably thinking about IList<T>, ICollection<T> and co. If you go through the MSDN documentation of each class you will see that their complexities are well documented.

[MFH]

List<T>, ArrayList and LinkedList<T> are three different implementations, not interfaces; you are probably thinking about IList<T>, ICollection<T> and co. If you go through the documentation of each class you will see that their complexities are well documented.

1. I was talking about Java -> look it up these are the names of an interfaces (List) and two implementations (ArrayList, LinkedList)

2. In your code you have the following function:

public List<XYZ> getXYZList();
[/CODE]

What guarantees do you have for the result of [i]getXYZList[/i]? [b]None![/b] You have no idea what complexities the methods on this object actually have!

[Ambroos]

1. I was talking about Java -> look it up these are the names of an interfaces (List) and two implementations (ArrayList, LinkedList)

2. In your code you have the following function:

public List<XYZ> getXYZList();
[/CODE]

What guarantees do you have for the result of [i]getXYZList[/i]? [b]None![/b] You have no idea what complexities the methods on this object actually have!

Ehm. Does it matter what complexities or whatever the things have? You know that whatever the result might be, it always has all the functionality specified in the List interface. If you want to be sure check what it is with an instanceof, or just create an ArrayList or whatever, and fill it up by iterating over everything in the List.

[MFH]

Ehm. Does it matter what complexities or whatever the things have?

If you care about performance: definately yes! if you don't care about performance: F*** you! You're one of those scumbags that slow down PCs worldwide!

You know that whatever the result might be, it always has all the functionality specified in the List interface.

Which doesn't help at all in terms of performance?

If you want to be sure check what it is with an instanceof, or just create an ArrayList or whatever, and fill it up by iterating over everything in the List.

Hardly useable considering there are countless implementations of an interface. Don't forget: it's highly unlikely you're implementing everything in the application => you'll get objects via interfaces where you'll have no idea about their implementation in Java and .NET?

[+Majesticmerc MVC]

I would argue that only professionals have any true reason to use C++. Newbies have no need for pointers, assembly, or manual memory management.

I would suggest learning C# with C (not C++) on the side. C will teach you low-level programming so you understand what's happening under the hood, while C# will teach you everything else and is the language you're more likely to use day to day.

The problem with C++ is a matter of poor design. It has so many hurdles and traps that it's a language that takes years to master.

I disagree. IMO all developers should know the concept of the stack vs heap and memory management, especially given that it's a core part of how most object-oriented languages work (C# included). Knowledge of memory management, even at a basic level gives understanding of how GC works, the difference between value types vs reference types in .NET, and so on.

However, for people just looking to make quick apps, learning a lower level language is probably excesive. If the user is looking at taking it up programming as a profession, knowledge of how this stuff works at a lower level should be mandatory (again, IMO). The OP didn't really specify though, so it's hard to give a good answer.

I don't think there's any value in learning C over C++ either. C++ is basically everything that C is, but you get all the benefits of OOP.

There are pointers in C#. And reference vs value types is basically the same idea as pointers vs values in C/C++.

Just because you can, doesn't mean you should. Doing pointer stuff in C# is a sin :p.

[JonathanMarston]

I'm surprised nobody has said Java yet. Eclipse is a great free Java IDE, Java and C# are almost the same language, and Java is perfectly cross-platform, including GUI's.

I'm studying Applied IT and have been writing Java since september now. I've always used Eclipse with it, but I feel right at home in Visual Studio using C#. No reason to limit yourself to Microsoft with C# right from the beginning.

(in fact, C# is strongly 'inspired' on Java. But Java sort of forces you to write cleaner code (in my opinion), which will help you later on)

Java and C# are similar, but not at all the same languages. Java is missing so many language features that I use on a daily basis that I don't know if I could ever go back to Java after coding in C# for the last few years.

Properties, delegates, lambdas, events, anonymous classes, partial classes, reified generics, generators (yield return), extension methods, expression trees, and language-level async support (in .NET 4.5) are just a few of the C# language features that would be hard to live without; not to mention some of the functionality in the .NET framework like LINQ, Parallel Extensions, Entity Framework, MVC, etc...

About the only things I prefer about the Java language are the way they handled enums and enforcing exception handling at build-time.

[georgevella]

1. I was talking about Java -> look it up these are the names of an interfaces (List) and two implementations (ArrayList, LinkedList)

2. In your code you have the following function:

public List<XYZ> getXYZList();
[/CODE]

What guarantees do you have for the result of [i]getXYZList[/i]? [b]None![/b] You have no idea what complexities the methods on this object actually have!

Ahh Java, sorry missed that. I've thought a lil bit more about what you said and I do understand your reasoning now. Thing is one of the roles of interfaces is to hide implementation details. There is not much you can do in .NET (or Java) if a 3rd party library returns an IList<T> to the caller instead of a List<T>.

[MFH]

Thing is one of the roles of interfaces is to hide implementation details.

True, but once you try to develop efficient - performance/watt - you sooner or later realize that heavy abstraction as provided by interfaces is actually the worst thing you can do! It's not even the dynamic dispatch (virtual function call) [though I even experienced that one too to become a problem?] , but the fact that you abstract away any information that will be suitable for creating the most efficient solution (e.g. linked-list vs array -> I think I don't have to say anything?)

[+Xinok Subscriber²]

I disagree. IMO all developers should know the concept of the stack vs heap and memory management, especially given that it's a core part of how most object-oriented languages work (C# included). Knowledge of memory management, even at a basic level gives understanding of how GC works, the difference between value types vs reference types in .NET, and so on.

However, for people just looking to make quick apps, learning a lower level language is probably excesive. If the user is looking at taking it up programming as a profession, knowledge of how this stuff works at a lower level should be mandatory (again, IMO). The OP didn't really specify though, so it's hard to give a good answer.

I don't think there's any value in learning C over C++ either. C++ is basically everything that C is, but you get all the benefits of OOP.

That's why I suggested learning C, so you learn how things work "under the hood". The reason I recommend C over C++ is, as I said, poor design. C++ only overcomplicates things like object-oriented programming, things which would be much easier to learn in C#. C is also more low-level, requiring you to use malloc / free instead of new / delete, printf instead of cout << endl, structs instead of classes, and so forth.

[MFH]

C++ only overcomplicates things like object-oriented programming, things which would be much easier to learn in C#.

Is it possible you only focus on the negative side of C++? How about the stricter type system - something that C could 99% of the time take a real advantage of - or the lack of stupid features (VLA come to mind?) . Or the fact that C++ is still relevant outside of kernels and embedded system - hell even there C++ is gaining ground (sans the "heavy" features [exceptions, virtual calls,?])?

requiring you to use malloc / free instead of new / delete, printf instead of cout << endl,

Apart from minor differences these solutions are interchangeable - i prefer the iostream-approach as it is way cleaner and typesafe? (I despise C-style IO)

structs instead of classes

they are virtually the same?

[+Xinok Subscriber²]

Is it possible you only focus on the negative side of C++? How about the stricter type system - something that C could 99% of the time take a real advantage of - or the lack of stupid features (VLA come to mind?) . Or the fact that C++ is still relevant outside of kernels and embedded system - hell even there C++ is gaining ground (sans the "heavy" features [exceptions, virtual calls,?])?

Apart from minor differences these solutions are interchangeable - i prefer the iostream-approach as it is way cleaner and typesafe? (I despise C-style IO)

they are virtually the same?

That's why I suggested learning C, so you learn how things work "under the hood". The reason I recommend C over C++ is, as I said, poor design. C++ only overcomplicates things like object-oriented programming, things which would be much easier to learn in C#. C is also more low-level, requiring you to use malloc / free instead of new / delete, printf instead of cout << endl, structs instead of classes, and so forth.

I'm recommending C# for regular development, and C only for LEARNING low-level programming. C++ is such a hassle that there's no reason for a newbie programmer to use it over C#. C is a better language to learn how things work under the hood because it's much more exposed (e.g. there is no 'delete' keyword to automatically destruct an array of objects).

[+LogicalApex MVC]

...

Mono is an implementation of open standards just like gcc or clang. I don't know what you mean by "pure C#", as Microsoft's .NET itself is written in C++.

...

What part? As the CLI (JIT Compiler) is C++ and Assembly, but the framework itself is C#... You can see this using .NET Reflector or the .NET symbols when debugging in Visual Studio...

Also: http://stackoverflow.com/questions/1324919/what-language-is-net-framework-written-in

[Andre S. Veteran]

I think you got it wrong. Due to the fact, that .NET and Java use OO and a whole lot of interface cruft for their containers' interfaces (opposed to C++'s container definition) you actually can't rely on the complexity of the containers in them - especially if you're using collections that are returned from foreign code. For example what does the List<XYZ> guarantee in terms of complexity in Java? Well nothing really, as it's an interface, List<XYZ> may actually be an array (class ArrayList) or it may be a linked list -> totally different complexities (and memory layouts -> access patterns) are involved here! You have no way of telling which one it is based on List<XYZ>. A similar thing happens in .NET?

If you specify a container type as IList<T> (in .NET), you are specifying that you don't care what the concrete type of container and its performance characteristics are! If you do care, then you should write LinkedList<T>, List<T>, etc., which are concrete types with documented complexities just like the concrete types std::list and std::vector.

The fact that collections in Java and .NET implement interfaces simply mean that it's possible to treat them as more generic types while ignoring their performance characteristics, not that this is necessarily what you want to do. So I don't really understand your point. I don't think the design of the .NET class library in general (can't speak for Java) makes it difficult to know what the concrete type of collections are; generally, when a method returns a container, it is a concrete type.

Just because you can, doesn't mean you should. Doing pointer stuff in C# is a sin :p.

Well, it's not idiomatic, but it enables some high-performance features to be done in C# like bitmap manipulation in Paint.Net or the like. At least C# makes it clear with all the syntactic evilness (unsafe, fixed, stackalloc, etc) that you'd better know what you're doing when you use pointers.

As for C vs C++ for the purpose of learning pointers and manual memory management, I think I'd side with Xinok on the issue; C is a simple and coherent language which can't be said of C++. How many different ways are there to create a pointer in C++11?

C-style (evil, deprecated, don't use! but wait all the standard library uses it...)

auto_ptr (bad, deprecated, don't use!)

reference (almost the same thing but not quite, if you can use it use it)

unique_ptr (expresses ownership of the resource - what happens when you copy it exactly? Stroustrup himself was confused on the issue at a recent talk)

shared_ptr (expresses shared ownership of the resource - but may lead into leaks because of reference counting cycles, for which there is...)

weak_ptr (breaks cycles of shared_ptr)

Ugh... what's a pointer again?

[Andre S. Veteran]

What part? As the CLI (JIT Compiler) is C++ and Assembly, but the framework itself is C#... You can see this using .NET Reflector or the .NET symbols when debugging in Visual Studio...

Also: http://stackoverflow...work-written-in

Correct, I was over-generalizing. The point still stands that .NET is not "pure C#" in the sense of being purely written in C#.

[+LogicalApex MVC]

Correct, I was over-generalizing. The point still stands that .NET is not "pure C#" in the sense of being purely written in C#.

Agreed. I was merely offering clarification, but the base point is correct.

[MFH]

The reason I recommend C over C++ is, as I said, poor design.

I honestly disagree! It may be true - to some extend - for C89 (aka ANSI-C), but IMHO any later standard is just an abomination?

C++ only overcomplicates things like object-oriented programming, things which would be much easier to learn in C#.

I disagree again! C++ is not about OO, C++ is about effective abstraction! The people that think that C++ is just about OO are those that actually are getting it wrong - just as those who think that OO means: "everything has to be a class/method"?

C++ is such a hassle

Actually it's easier to learn than C - provided you learn idiomatic C (which more or less requires not to learn C as C++ got all the features that make C good, yet avoids some of it's deadliest pitfalls via a stricter type system? Sure if you learn C and try to use C with Objects you're lost. People that follow that path are those that overuse new and delete - something that's rarely used in modern C+!

(e.g. there is no 'delete' keyword to automatically destruct an array of objects).

There's free? And as I said modern C++ does not rely on new/delete in usercode?

If you specify a container type as IList<T> (in .NET), you are specifying that you don't care what the concrete type of container and its performance characteristics are! If you do care, then you should write LinkedList<T>, List<T>, etc., which are concrete types with documented complexities just like the concrete types std::list and std::vector.

Well that doesn't work as the way of thinking - at least in the Java world - is that you should NEVER use the concrete type in the interface?

generally, when a method returns a container, it is a concrete type.

Nope, it's an implementation of an interface which is no concrete type for which you can rely on for complexity guaranties?

How many different ways are there to create a pointer in C++11?

It depends! (The beauty of options?) Do you mean raw pointers or smart pointers? (There's a reason for the distinction!)

C-style (evil, deprecated, don't use! but wait all the standard library uses it...)

Nope, if you know what you're doing they're perfectly valid - you shouldn't overuse them.

auto_ptr (bad, deprecated, don't use!)

Deprecated yes, but if you know it's limitations - which boils down to one fatal in certain situations - you may still use it. Whilst auto_ptr has it's problems it's still a tool that can be used in certain situations. Given the option, one should prefer unique_ptr?

reference (almost the same thing but not quite, if you can use it use it)

Actually references are more like aliases - but hey it all boils down to memory addresses anyways?

[MFH]

unique_ptr (expresses ownership of the resource - what happens when you copy it exactly? Stroustrup himself was confused on the issue at a recent talk)

He is? (source??) Well let's look into the spec: Hey, unique_ptr is NOT COPYABLE, which makes sense as it's expressing sole ownership?

shared_ptr (expresses shared ownership of the resource - but may lead into leaks because of reference counting cycles, for which there is...)

weak_ptr (breaks cycles of shared_ptr)

So you're arguing we should use a tried and tested way to manage cyclic dependencies without having the burden of a garbage collector?

Ugh... what's a pointer again?

A memory address, every smart pointer you listed is there for a purpose. The purpose is simply: to simplify the memory management of the application! Compare it to C: you only have raw pointers. How do you free the following structure:

int * ptrs[1000];
[/CODE]

Every ptr in ptrs points to a random object in memory, it's possible (actually likely) that several pointers point to the same object.

For comparison in C++

[CODE]
std::array<std::shared_ptr<int>, 1000> ptrs;
[/CODE]

will be deleted automatically if it goes out of scope [RAII]?

[Andre S. Veteran]

I wouldn't recommend using C# or dotnet outside of Windows. Its support is sketchy at best, and most Linux distributions are blacklisting it (Mono) due to precarious licensing issues. Furthermore, the proprietary Windows Forms also won't be available outside of Windows, so if you intend on writing a GUI application, you will have to use something else.

The most popular Linux distribution shipped with two Mono-based applications until just recently, and the reasons for replacing the apps with native ones were based on their own merits. Mono is used on several commercial projects including by large companies such as EA, has been actively developed for almost as long as Microsoft's .NET by a team of professionals, and for all the fear-mongering about Microsoft patents, after ten years Microsoft is, if anything, showing more openness towards open-source than ever, recently making ASP.NET open-source for instance.

You will have to use a cross-platform GUI toolkit for writing cross-platform applications regardless of language choice, so the point that WinForms (or WPF) isn't cross-platform is kinda moot. It's also inexact since Mono does implement Windows Forms (if poorly).

In fact, .NET is currently one of the best cross-platform solutions, especially for games: I don't what other environment allows you to target Windows, WP7, Xbox360, Mac OS, Linux, Android and iOS with the same code and that's exactly what XNA/MonoGame does.

[Andre S. Veteran]

Well that doesn't work as the way of thinking - at least in the Java world - is that you should NEVER use the concrete type in the interface?

That's a blanket statement and I'm sure you can find plenty of counter-examples in the Java library itself, which I'm not familiar with - in .NET, off the top of my head, File.ReadAllLines returns an array of string, not an IEnumerable<string> or whatever. You don't want to use a concrete type if what you want is flexibility at the expense of not knowing the concrete type (and its performance characteristics); if you don't need the flexibility then why use anything else than a concrete type? That seems like an extreme design rule, and certainly not a limitation of the .NET (and probably not of the Java) library.

It depends! (The beauty of options?) Do you mean raw pointers or smart pointers? (There's a reaso

I understand why there are many options in C++, but what I'm arguing is that from the perspective of learning pointers, having all these options is counterproductive because it creates confusion.

He is? (source??) Well let's look into the spec: Hey, unique_ptr is NOT COPYABLE, which makes sense as it's expressing sole ownership?

http://channel9.msdn...sk-Us-Anything- at around 33:45. I spoke a bit quickly, Stroustrup was confused about passing a unique_ptr by value, not specifically copying it. Still, if the language designer is unsure about how his own feature works, how do you expect someone learning pointers to make sense of all that?

So you're arguing we should use a tried and tested way to manage cyclic dependencies without having the burden of a garbage collector?

Again, I'm just saying that all these options are confusing to someone learning pointers, and that they would be better served, for that purpose, with a much more simple language.

[KomaWei]

C# is easier than C++, but C++ has a better gui framework for multiple OSes while C# doesn't. It does have Gtk# for it, but it's documentation is horrible and so is the look of Gtk#.

[Andre S. Veteran]

C# is easier than C++, but C++ has a better gui framework for multiple OSes while C# doesn't. It does have Gtk# for it, but it's documentation is horrible and so is the look of Gtk#.

I assume you're talking about Qt - aren't there .NET bindings for that?