Thread: Language of choice after C++

>I believe Java is not used widely outside of universities.

Really? I truly wish that was so because I am not a big Java fan, but I believe you are wrong. Just open up your newspaper and go to the jobs section. Or get on to monster.com. You will notice otherwise.

>C# is the way to go and it will prove even more evident with Longhorn.

C# is a beautiful language and I would love to develop in it, and there are certainly several jobs in C# out there right now. But as long as Microsoft isnt porting it to every platform known to man just like what has been done with Java, C# will only be used with Windows (and now with Linux since a 3rd party group ported it to Linux). It isnt fully multiplatform like Java is, and therefore there will still be a very large market out there for Java programmers. I would love to see C# become much bigger, because I like C# a lot, and I think it eventually will. But that wont be for awhile yet because Microsoft is only focusing on C# for Windows and nothing else.

How come you dislike Java so much, but love C# so much? They are as I understand quite similar.
C# has gotten much from Java.

Java has WAY too many input readers, output writers, input streams, output streams, etc. I posted a list here: http://cboard.cprogramming.com/showthread.php?t=53763

Java does not allow overloading of operators. Being able to overload operators has always made things quite convenient. For example, in C++ you can simply overload the << and >> operators using ostream and istream to output or input any type of object you want. That is a heck of a lot better that using the trillion different types of readers, writers, input streams, and output streams that Java has.

Java has always been quite bulky when it comes to typecasting, and using primitive data types is always a nuisance when you want to put them into a list or tree of some sorts because you always have to create a new object. And then when you get them out of the data structure you have to typecast out of it and then get the value using something like intValue() or whatever. This specific problem is now solved with the new features being added in Java 2 1.5.0, but they should have been added a LONG time ago. C# has never had that problem.

Also, Java's String class is gimp and can do virutally nothing. There is a class (is it StringStream...or something of that nature) that is meant to give Strings more versatility, but even it does not measure up to the string class of C#, and BOTH C# and Java's string classes dont measure up to the STL string class of C++. The STL string class of C++ is the most versatile and powerful string class I have ever seen in my life.

Originally Posted by DavidP

Java has WAY too many input readers, [...]

Java does not allow overloading of operators. [...]

Java has always been quite bulky when it comes to typecasting, [...]

Also, Java's String class is gimp and can do virutally nothing. [...]

OK, that sounds like reasonable points to prefer C# over Java.
The string class you're looking for is called StringBuffer.

These are the things I really miss in C++:

1. A larger and useful standard library (sockets etc.) C++ is virtually useless by itself.
2. Package support: #ifndef is waaay too ancient. We need real package suppo

C++ also has the disadvantage that it is a very large language with many features and is thus hard to master. (template metaprogramming, multiple inheritance).

>Package support: #ifndef is waaay too ancient. We need real package suppo

Agreed, but it's much too late to add something like that to the C++ language. The current usage of namespaces and #ifndef's will have to do for C++.


>The string class you're looking for is called StringBuffer.

Thanks. Couldnt remember the name and was in kind of a hurry so I didnt look it up.

>A larger and useful standard library (sockets etc.) C++ is virtually useless by itself.
A great deal of the complexity of a language stems from the libraries it supports natively. The core Java language is small and simple. Even a non-programmer can learn the whole of it in a short amount of time. But even expert Java developers usually don't know the whole of the standard library. That's one reason why the C++ library (as large as it is) is relatively sparse compared to the Java classes.

But the primary reason is that it's difficult to write generic, portable standard libraries for a language that doesn't provide its own virtual machine. If you've written sockets on Unix and Windows then you'll recognize the subtle differences. Now what about Mac? Or any number of other platforms that support C++? It's easier to simply allow third parties to create those libraries and have the developer choose between them.

But I agree with you to an extent. There should be a standard interface convention that those libraries adhere to so that they're easier to pick up and use quickly. Perhaps committee sanctioned libraries that aren't a part of the standard, but recommended by it...

>Package support: #ifndef is waaay too ancient. We need real package suppo
Yes! Phase out the preprocessor completely and be done with it. But I don't see that happening anytime soon. Any sensible proposals would be met with screams of rage from the unwashed masses.