yes it proberbly was not the best example, but my point is that you can do it any way you want, in C# i found that certain stuff had to be done a certain way, wheres C++ does not really have a certain way of doing stuff.

Parse error at line 1. Still, inferring as best I can I think you are mistaken. A more accurate analysis is that modern languages give you really good support to lots of things, and the support encourages you to do things a certain way. C++ tends to give you little or no support, so people have gone and done things in many ways.

It is erroneous to go from there to the idea that C++ gives you more options - it does not. As a language, it gives you less options. The fact that library developers have improved the situation is irrelevant - the same could be done on managed languages like C#.

For example, C++ does not have any concept of threads*. As a result many libraries were created to rectify this. Modern managed languages such as C# have built-in threads, and give you tools designed to use them a certain way. They aren't always exhaustive (though they are certainly comprehensive). However, there is nothing stopping you from writing libraries for C# that do other things with threads. The fact that few exist owes mainly to how much you can do with the built-in support.

Replace "threads" with almost any other concept and the above statement is still usually true.

A notable exception might be 3D graphics. There were a number of abortive "official" attempts to add support for 3D graphics to managed languages like Java and C#. Most have failed (except for XNA - which isn't strictly 3D graphics so I'll ignore it). In the absence of built-in support, the communities involved have created libraries.

* [size="1"]Ignoring C++0x for the moment
[/quote]

Not strictly speaking true; the language spec for C# just defines the language itself, whereas threads are part of the .NET framework. In effect, support for threads is provided by a library (or at least by the .NET analogue of a library) although in practice one could be forgiven for seeing the lines as being a little blurred with this example.

Take graphics. The "attempts to add graphics to the language" were not actually adding graphics to the language at all either. Again, it's a .NET assembly (still assuming C#) which is the .NET analogue of a library.

For the benefit of people who aren't experienced in other languages, can you explain what you mean?

For example, from what I've seen of Java, I don't really see how it's designed for a non OOPS paradigm. The only thing I can think of is that Java has a primitive form of closures due to inner classes.

Sure, but I am going to take the lazy way out. Let me present a list of languages/paradigms they support courtesy of the all knowing brain Wikipedia. Granted, there are some oddities on this list ( it treats generic and metaprogramming as different, and the same, depending on langauge and it massively sells javascript short, as prototype itself should be considered a paradigm IMHO, plus it is capable of metaprogramming ) but generally it is a good starting place. Also, it misses some completely.

Java is the goto language of corporate America and much of academia, so it is often the birthplace of new paradigms. Additionally, the Java ecosystem is startlingly capable of overcoming inherit flaws of the language. Java for example has taken service oriented programming to a new level. Aspect Oriented programming began life on Java for example.

Far be it from me to defend Java though, with the exception of some work with EDS in the past, some experimentation when Java was first released ( applets, like everyone else at the time ) and a brief foray into Android land I have minimal experience. I am by no means an expert in Java, so somebody else would probably be better served addressing this question in greater detail.

All told, I am actually not much of a Java fan. It is functionally similar enough to C# that I can work in it, but I find using it frustrating. Now, 95% of the time, if given the choice between C++ and Java, I would take Java, but 100% of the time if given the choice between C# and Java, I would take C#.

Serapth,

Nice story. Really enjoyed it. For about 8 years I worked at a small-ish company never really feeling like a "real" programmer because 1) I didn't have a degree and 2) I was working in a small company and felt had I been "good enough" some larger corporation would want me. Recently I got into a larger corporation and noticed everyone was more or less just like me and that I had been a "real" programmer all along.

Very encouraging stuff!

C# sucks because it prevents you from getting down-n-dirty with the bits and bytes when you need to.

Negative!! Unsafe code to the rescue.

Not strictly speaking true; the language spec for C# just defines the language itself, whereas threads are part of the .NET framework. In effect, support for threads is provided by a library (or at least by the .NET analogue of a library) although in practice one could be forgiven for seeing the lines as being a little blurred with this example.

Take graphics. The "attempts to add graphics to the language" were not actually adding graphics to the language at all either. Again, it's a .NET assembly (still assuming C#) which is the .NET analogue of a library.

The language spec provides definition for the lock statement, which does rely upon the .NET framework to implement the critical section, but is also part of the language proper. But let's be honest here, C++'s standard library doesn't even have a concept of threads (C++0x not withstanding).

What about Boost? It seems to me that it's popular enough to practically be a standard, and some parts are being added in C++0x.

[quote name='rip-off' timestamp='1307443994' post='4820463']

yes it proberbly was not the best example, but my point is that you can do it any way you want, in C# i found that certain stuff had to be done a certain way, wheres C++ does not really have a certain way of doing stuff.

Parse error at line 1. Still, inferring as best I can I think you are mistaken. A more accurate analysis is that modern languages give you really good support to lots of things, and the support encourages you to do things a certain way. C++ tends to give you little or no support, so people have gone and done things in many ways.

It is erroneous to go from there to the idea that C++ gives you more options - it does not. As a language, it gives you less options. The fact that library developers have improved the situation is irrelevant - the same could be done on managed languages like C#.

For example, C++ does not have any concept of threads*. As a result many libraries were created to rectify this. Modern managed languages such as C# have built-in threads, and give you tools designed to use them a certain way. They aren't always exhaustive (though they are certainly comprehensive). However, there is nothing stopping you from writing libraries for C# that do other things with threads. The fact that few exist owes mainly to how much you can do with the built-in support.

Replace "threads" with almost any other concept and the above statement is still usually true.

A notable exception might be 3D graphics. There were a number of abortive "official" attempts to add support for 3D graphics to managed languages like Java and C#. Most have failed (except for XNA - which isn't strictly 3D graphics so I'll ignore it). In the absence of built-in support, the communities involved have created libraries.

* [size="1"]Ignoring C++0x for the moment
[/quote]

Not strictly speaking true; the language spec for C# just defines the language itself, whereas threads are part of the .NET framework. In effect, support for threads is provided by a library (or at least by the .NET analogue of a library) although in practice one could be forgiven for seeing the lines as being a little blurred with this example.

Take graphics. The "attempts to add graphics to the language" were not actually adding graphics to the language at all either. Again, it's a .NET assembly (still assuming C#) which is the .NET analogue of a library.
[/quote]

This is like saying iostream isn't part of C++ because it is provided by a library. Threading is a core part of the .NET library, and is part of the language spec.

It's a bit confusing by the naming conventions used, but C# is covered by ECMA-335 ( warning, 8MB PDF link! ) Its partition 4, section 5.3 that is most relevant, which addresses the Base Class Library, which primarily composes the standard library ( and is implemented by Mono ) and is unencumbered by patents. Anyways, you will notice System.Threading is part of the BCL.

Keep in mind, the .NET framework is an implementation of ECMA-335, plus some libraries which are not included ( WinForms & ASP.NET being most prominent ).


Anyways, the .NET equivalent of the C++ Standard libraries very much DO include threading. Plus as Telastyn stated, the language includes the lock keyword.


EDIT: For clarity, the 'language' itself is covered by ECMA-334.

Real programmers, hires monkeys to make the best code possible

What about Boost? It seems to me that it's popular enough to practically be a standard, and some parts are being added in C++0x.

I think I would have gone with pthreads before boost when talking about standards.

Not strictly speaking true; the language spec for C# just defines the language itself, whereas threads are part of the .NET framework. In effect, support for threads is provided by a library (or at least by the .NET analogue of a library) although in practice one could be forgiven for seeing the lines as being a little blurred with this example.

Take graphics. The "attempts to add graphics to the language" were not actually adding graphics to the language at all either. Again, it's a .NET assembly (still assuming C#) which is the .NET analogue of a library.
[/quote]
C# is thread aware, the language spec makes references to threads, even if the language itself doesn't provide the ability to create/manipulate them. It is necessary for defined memory semantics when threads are created. Yes, graphics is more obviously external, I did put official in quotes though.

Point taken, but for the purposes of the debate I'm not particularly bothered with this distinction.