Talk:Comparison of C Sharp and Java/Archive 3

Archive 1

Archive 2

Archive 3

Value types

C# value types are not syntactic sugar. To meet that definition you would have to demonstrate what kind of code is really generated which you could have written yourself. You cannot do that with value types as they exhibit copy semantics - i.e. they are stack allocated and new copies are created when assigned or passed as parameters. Apart from that, being "syntactic sugar" is not an impeachment. Every single programming language is rife with "syntactic sugar". For loops are syntactic sugar: You can demonstrate how the resulting code can be generated as a result of statements and a while loop (or vice versa). Syntax matters. Useerup (talk) 22:26, 25 October 2010 (UTC)

Response: Value types are not a language feature,end of story, your wrong , give it up. Nobody outside Redmond and MS Fanboys cares about value types. They are not defined in any computer science literature, they are an invented type by MS. Not once in programming in C/C++/python/ruby/java/ADA/perl have I ever heard someone say 'geez wiz I wish I had value types'. You really need to stop arguing with everyone on this page. You keep reverting peoples changes, pretty much disagreeing with everyone where they are saying there is bias. How are we suppose to get rid of bias if you are allowing any real changes? —Preceding unsigned comment added by Bongey (talk • contribs) 14:46, 26 October 2010 (UTC)

C#/MS aren't the first once that use the naming 'value' and 'reference' types for their objects, let me just name ECMAScript (or more commonly known as javascript), which was there long before, and used that including the name. Before you make assumptions, here's a technical (though easy to understand) explanation of what a value type actually is: http://stackoverflow.com/questions/1113819/c-arrays-heap-and-stack-and-value-types/1114152#1114152. Try to link that to C++ and you'll see that a reference type is actually nothing but a pointer to an object (which is stored on the heap) that is stored on the stack, and with value types, the actual object is stored on the stack. So under different names, this feature is present in a lot of programming languages. Aidiakapi (talk) 10:02, 15 September 2011 (UTC)

"Value types" is a kind of language feature.

In Java, they are called primitives.
In C++, the difference can be summed as "Do I own the object directly, or through a (smart of not) pointer?". The difference is very important, as in C++, the last thing you want is to allocate everything through a new, if only because of performance reasons. But I should not have to explain you this, as you claim extensive experience in C++.

Anyway, this is exactly the reason why in Java primitives are not objects (I was told they tried having all primitives being true objects at first, but turned back because of performance).
In C#, they made Value Types derived from Object, but still made them "primitives" as understood by Java.

So Value Types are, as primitives, a language feature.

Fact is, Value Types as understood by C# are a first-class citizen of C#, when their equivalent (primitives) are not in Java:
C# handles boxing/unboxing when needed, and does not impose boxing/unboxing when it is not needed, for example.
Java is unable to handle primitives correctly without always boxing them first (for example, in generics).

Thus, the difference in handling Value types/primitives by the two languages is very important, and should be explicit in the current article.
Paercebal (talk) 13:05, 23 April 2011 (UTC)

I fail to see what's specific in Value Types, except Microsoft's marketing maybe. In .NET value types are also boxed / unboxed, because .NET really wraps the primitive values in Objects, and this operation cost a lot, like in Java. Also transparent boxing / unboxing of primitives is also managed in Java, for example this is perfectly valid Java code:

List<Integer> list = new ArrayList();
list.add(2);
int value = list.get(0);

More than that, if you try to code the same examples provided by Microsoft to explain how Value Types are working, these examples also work in Java, with an almost identical syntax.Hervegirod (talk) 21:41, 24 June 2011 (UTC)

You are mistaken, value types are not boxed/unboxed in .NET like they are in Java. This would be the code in C#:

var list = new List<int>();
list.Add(2);
int value = list[0];

And it would not involve the relatively expensive boxing and unboxing conversions. This goes for any primitive and value type (primitive types are just a subset of value types). int is a value type, and in C# you can define new value types. Only when value types are treated like objects (reference types) are they boxed. You may declare arrays of custom value types and the array will contain the actual values not a boxed references to values. Useerup (talk) 23:23, 26 June 2011 (UTC)

Microsoft documentation says: "Boxing operations occur when you pass a value type to a method that takes a System.Object as an input parameter."[1]. Which is the case for List.[2]. There is a lot of syntactic sugar in C#. Hervegirod (talk) 12:39, 15 January 2012 (UTC)

This thread is more than six months old, so I wouldn't expect much response. However, the documentation you linked says "..takes a System.Object as..". Generic list does not take System.Object as input parameter, indeed, the lack of boxing is one the main reasons for generics to exist and why generic collections are faster than their nongeneric counterparts. List<T> differs from ArrayList (which inherits from IList interface) by strong typing of the collection objects. --Sander Säde 12:59, 15 January 2012 (UTC)

As Sander Säde says, you are linking to the non-generic version (comparable to a "raw" type in java). C# has generic versions of collections and in there you will find a List<T> as was demonstrated to you in the example above. Repeat: Value types are first-class citizens and unlike in Java no boxing is performed when stored in a generic collection of the same type. It has to do with the fact that C# has reified generics and does not erase the type of generics parameters.--Useerup (talk) 16:52, 16 January 2012 (UTC)

Trying to implement a Complex type in C# is a good exemple of what C# can do with value types and operator overloading (kind of new primitive types). It is impossible in Java. — Preceding unsigned comment added by 193.8.222.12 (talk) 10:53, 17 January 2012 (UTC)

Incorrect/Outdate Comparison Chart

It seems that the comparison chart has some mistakes or it's outdated, it needs a java expert to revise it. I think java has some features but in the article it's said it doesn't such as : Implicit conversions,Explicit conversions, Events, Rectangular (multidimensional) arrays, Unified arrays and collections, ...

Also it seems that features of C# is listed, then it compared to java, which is a completely wrong approach since in many cases java has a better and more smart workaround for a problem without needing to have a feature for it. For example java never needs Explicit interface implementation, since it has co-variant return types. — Preceding unsigned comment added by 83.166.30.230 (talk) 17:19, 14 December 2011 (UTC)

The purpose of explicit interface implementation in C# is to hide functionality unless an instance is explicitly casted to the interface type, or to stack method or operator implementation that would otherwise clash (such as IList vs. IList<T> member implementation). So co-variant return types in Java is not equivalent. Dahvyd (talk) 06:28, 15 January 2012 (UTC)

The table is correct:

• Implicit/explicit conversions: Perhaps they should be termed custom implicit and explicit conversions. Java does not allow you to create a new type (class) and define conversions to be used automatically when resolving parameter types (implicit conversions) or custom "casting" logic (explicit conversions). In C# implicit conversions have been used to allow automatic "promotion" from e.g. int to the decimal.
• Events in Java exist in the BCL, but it is not a language feature as it is in C# (this WP article is about the programming languages). C# events generate "adders" and "removers" automatically much like automatic properties.
• Rectangular arrays: No, Java does definitively not have those. Both Java and C# have "arrays of arrays" (also called "jagged" arrays), but only C# has rectangular arrays. Their usefulness can be discussed; they have certain advantages (sometimes better performances under random access) and drawbacks (overhead under sequential access) compared to arrays of arrays.
• Unified arrays/collections: C# allows a "list" view on arrays and the "foreach" loop uses the unified IEnumerable interface which both arrays and collections implement. In Java, arrays and collections have not been unified; rather the "for" loop has been extended to accept both collections and arrays with the "for each" syntax. But they are actually different statements and you cannot pass an array where a list is expected. You can in C#

Maybe the table needs to be supported by more examples? --Useerup (talk) 16:46, 16 January 2012 (UTC)

Tooo looong... to navigate... comfortably...

Hi all,

When I read this article, I found that I had to skip several sections in order to reach the stuff I was looking for. I got suspicious and downloaded the source code—a whopping 103 KB of plain text! What's worse, it's got several problems like neutrality, original research... and the first section is huge!

Does anyone have any ideas as to how to improve this article? I already added the {{Multiple issues}} template to replace the others. But tinkering with templates does not improve an article.

Thanks,

The Doctahedron, 02:33, 24 January 2012 (UTC)

Split the "feature" table into multiple tables and move them to sections with the text/samples. This will allow them to appear more as section summaries than a single monolith? Cropping some details? --Useerup (talk) 21:11, 25 January 2012 (UTC)

Personally, I'd make the tables sortable and collapsible. I'd also put some tables into subpages. Any suggestions on how to do that? 68.173.113.106 (talk) 19:18, 23 February 2012 (UTC)

String interning

Hello all - I think this article would benefit from a discussion on string interning and how the respective platforms deal with that. Any thoughts? — Preceding unsigned comment added by 57.66.102.70 (talk) 15:08, 17 February 2012 (UTC)

What's that? 68.173.113.106 (talk) 19:15, 23 February 2012 (UTC)

Unified type system

C# (and .NET Framework) has no unified type system. I.e. pointers and interfaces does not derive from the System.Object. Moreover, C# does not allow pointers to be encapsulated as objects.

194.54.20.58 (talk) 12:12, 1 March 2012 (UTC)

See http://msdn.microsoft.com/en-us/library/aa664638(v=VS.71).aspx Useerup (talk) 17:28, 1 March 2012 (UTC)

Did you bother to try run that code using pointers? Try to compile this:

class Test
{
  unsafe static void Main()
  {
    int i = 42;
    int* p = &i;
    Console.WriteLine(p.ToString()); // Operator '.' cannot be applied to operand of type 'int*'
    new Stack<int*>().Push(p); //The type 'int*' may not be used as a type argument
    new Stack().Push(p); //Argument 1: cannot convert from 'int*' to 'object'
  }
}

See http://msdn.microsoft.com/en-us/library/y31yhkeb(VS.90).aspx “Pointer types do not inherit from object and no conversions exist between pointer types and object. Also, boxing and unboxing do not support pointers.” 194.54.20.58 (talk) 06:18, 2 March 2012 (UTC)

Find a reliable source which says "no, C# does not have a unified type system". So far there are only sources supporting that C# has a unified type system. You are correct that the native-oriented type "pointer" does not derive from object. But the pointer type is not part of the common type system of C#. It is a type to which you only gain access when you run the extended version of the language which you get access to by compiling with the unsafe option. But it is really down to reliable sources. Remember, Wikipedia is about verifiability. --Useerup (talk) 07:07, 2 March 2012 (UTC)

I found http://msdn.microsoft.com/en-us/library/2hf02550(VS.71).aspx which says that the common type system supports value types and reference types. Reference types can be self-describing types, pointer types, or interface types. So pointers ARE a part of CTS. And pointers are just pointing to an object, they are not objects itself, they are simply an address of an object.

Anyway, if you are concerned using unsafe context, try to compile this: Console.WriteLine((object)default(TypedReference));

.NET Framework has exceptions from its rules, and these exceptions makes statement “Every type is deriving from/can be converted to object.” false. If Microsoft wrote “All types derive from the System.Object base type.” it should also write ”except pointers.” but it didn’t on that page (it did on other, the link is in my previous post). 194.54.20.58 (talk) 07:47, 2 March 2012 (UTC)

Unsigned integer types

I changed the entry for unsigned integer types. Java's char type is an unsigned 16 bit integer. I'm tired of reading that Java doesn't have any unsigned integers at all. It's clearly not true, although the number of unsigned integer types is very limited. The "simple/primitive types" section should probably also be changed. — Preceding unsigned comment added by 86.52.7.203 (talk) 12:02, 2 May 2012 (UTC)

Simplicity vs. feature richness

Wikipedia is great for beeing _SIMPLE_ not for beeing "feature rich". This article evaluates C# as better, because it has more features, than Java. The "missing" features of Java are marked red. Diplomatically speaking, this approach is not very clever. 193.165.212.242 (talk) 11:54, 14 November 2011 (UTC) (cs:User:Pteryx)

The tone of the article makes it seem heavily biased towards C# because it has features that Java doesn't - ignoring whether Java would actually benefit from these features or not, and the fact that the vast majority of them were deliberately left out because of design principles of the language. Then lo and behold when a feature comes along that's in Java and NOT in C# (checked exceptions for instance) the article launches straight into talking about all the disadvantages of checked exceptions! And when the opposite happens, such as with LINQ, the article discusses all the positives about it.

This article has the potential to be good, however at the moment it's nothing more than a load of biased waffle. I use both C# and Java extensively and have no bias towards one or the other, but this page definitely does. 86.26.141.146 (talk) 17:31, 1 January 2012 (UTC)

Once again (see below): this article compares two languages by listing their features and mentioning alternatives on the other side. Because C# has more features than Java, C# comes out as ... well, having more features. There is no bias in that whatsoever. Commenters like you keep coming here on how the article is 'biased towards' C#. I don't see any such bias. Please point it out. There definitely needs to be an opinion piece to explain to people using software that more features doesn't always equate better, but this article is not the place for that, I think. Rp (talk) 18:05, 3 January 2012 (UTC)

Article.isBiased() == false; C# is simply a newer language than Java and thus has more features, because the C# programmers thought of stuff that the Java guys didn't. But that doesn't make it better. How it's used is important as well. Cheers, The Doctahedron, 00:42, 24 January 2012 (UTC)

I use both Java and C#. I prefer C# solely for its support of events. Now I've seen events in old Pascal code, so they aren't exactly a new concept - I know that this is just one example of a feature that Java is missing, but is it really that biased to point it out? After all, C# support on mobile phones is inexistent in most cases, and poor on Android - is there any free C# compiler for Android? This "missing feature" for C# is also pointed out in the article, along with arbitrary-length floats. Yes, Java has a lot of red boxes in that list, but that doesn't mean that the list is biased - just that Java has less features than C#. We could compare C# and Java to x86 assembly, and assembly would be almost a solid pane of red boxes - but this doesn't mean that it is worse or inferior, just that it is intended for a different purpose. 90.194.203.69 (talk) 12:39, 16 February 2012 (UTC)

My understanding was that this is supposed to be a discussion about the semantics of the language, and that the underlying platforms were compared elsewhere. C# has language-level support for a lot of things Java doesn't, so a feature-comparison (an objective way to compare the two) will intrinsically favor C#. — Preceding unsigned comment added by 152.23.122.74 (talk) 20:59, 2 May 2012 (UTC)

I used both C# and Java after a long time with C++. I think the debiasing of the article should be done by explaining the differences of the two languages, not only enlisting them, which has been done at some places where it is written that delegates, for instance, have been deliberately left out. Like in this example, if Java is "missing" some features because it is older, this should be clearified and referenced. If a feature has been deliberately left, again, a referenced information is needed. And I propose to use a four-colour scheme so that deliberately left out features are marked with a colour different than green, yellow, or red.

I think this discussion here shows that the article seems to be biased, but actually lacks referenced clarifications. As I used Java around two years and C# less than a year in projects, I think others with more experience would be more appropriate for the job of adding the missing information. To the experts: Please, please do not forget that you are writing for an encyclopedia. I plead to the prophets of both languages to add facts, if they are interested to add anything, and not a list of dogmas. Sae1962 (talk) 10:25, 3 September 2012 (UTC)

I think that the article is no more biased. I plead to remove the marking that it is biased. Sae1962 (talk) 15:06, 12 September 2012 (UTC)

Be bold, go ahead and remove it. I do think the article still has other issues, though. Mostly structural, but there is also the pesky problem of agreeing on where the language stops and the framework begins. Useerup (talk) 19:19, 12 September 2012 (UTC)

Please PR this page

Please Peer Review this page. Thanks! 68.173.113.106 (talk) 01:13, 10 March 2012 (UTC)