PDA

View Full Version : C++/Java/C#



Pages : [1] 2 3

C_ntua
06-25-2008, 11:58 AM
For a C programmer, knowing the basics of OOP, which of the title's language you think is better?
If you cannot define better, then which is more easy to use knowing plain C? For example, should somebody learn C++ or just go to the newer C#?

Elysia
06-25-2008, 12:05 PM
I vote C++.
C# is tied to dotNet, which, at the moment, is unportable.
Further, it is slow, it is easily reverse engineered, it gives no control over memory (uses a garbage collector) and the language itself is flawed, especially in the eyes of many C++ programmers.
Java is also interpreted which means easy reverse engineering and slow execution.

No, C++ is the best language today IMO, because it gives you control over what you want to do and how.
C# limits you to a slow framework, limiting your options.
C++ is as fast as, or faster, than C. It is also backwards compatible with C. And C++ has a great deal of pre-written code.
This means you can fall back to C if you need to communicate with hardware, for example, and yet you can program in high-level programming without sacrificing much speed.

cpjust
06-25-2008, 12:34 PM
If you already know C, then C++ is definitely the easiest to learn (all you need to learn is the ++ ;) )
Java has these things they call "references", which aren't really references, they're more like pointers, but not quite. It also doesn't have a lot of basic things like a const keyword, destructors, and the option of whether you want to pass by value or by reference...

Daved
06-25-2008, 12:43 PM
I would learn Java or C# rather than C++. It would be too easy to get stuck using C habits if you moved on to C++, and it would be easier to learn C# or Java without that burden.

Once you learn either of those two language you can always go back and learn C++ with a different mindset and combine that with your C experience to get the most out of C++.

medievalelks
06-25-2008, 01:00 PM
What kind of development do you want to do? A lot depends on that.

C_ntua
06-25-2008, 03:35 PM
Yeah, everything depends on what you do. Well, don't have anything in mind. I just like "thinking in simple way". Thus more like in C. But I would also want to "upgrade" to something more modern so I can use more modern libraries and all the such.

What you say Dave is the best thing to do. I would advise it for someone new in programming. But since I have learned to program in C I would like first to go to something similar, learn its new features but still programming C-like. Then little by little I ll learn more and more features more and more functions and have a more varied way of programming.

The 3 languages just look very similar to me. And I am kind of indecisive :) But I ll listen to most advises to go to C++.

Daved
06-25-2008, 03:41 PM
>> But since I have learned to program in C I would like first to go to something similar, learn its new features but still programming C-like.

The problem is that to get the most out of C++ you need to avoid many of the habits you learn from C. Modern C++ is very different from C even though you can still code with C style in a C++ program. New C++ programmers with C backgrounds often fall back on their C knowledge instead of learning the new (and usually better) solutions available in C++. This is why I suggest starting with a language that won't let you fall into that trap.

AaronHall
06-25-2008, 11:05 PM
Then would you suggest learning Java before C++?

laserlight
06-25-2008, 11:29 PM
I'd say it is a tough call, if all you want is to learn more programming languages. Daved's argument is that learning C++ right after learning C tends to cause the learner to stick to C techniques, thus missing out on C++ techniques. On the other hand, learning Java next would mean that you may pick up habits in Java that do not normally apply to C++.

In the end, I think that the choice does not really matter: you will always have to "unlearn" something that does not apply.

AaronHall
06-26-2008, 12:01 AM
C++ is my first language I am learning. I am doing the tutorials online and will be taking C++ classes at my local college soon. After C++, I plan to try and tackle Java.

Daved
06-26-2008, 12:11 AM
>> Then would you suggest learning Java before C++?
In reference to the original question, yes I would choose Java or C# first because the OP already knows C. In general, it really depends. There's nothing wrong with learning C++ first, especially if you've already started.

I think the choice matters, but it won't stop you from being a good programmer, it will just take you down a different path. I would suggest learning a language well enough to use it to learn broader programming concepts before moving on to another language.

CornedBee
06-26-2008, 02:21 AM
You could learn something radically different from C, if you just want to broaden your horizons. You could learn Smalltalk. You could learn Lisp. You could learn Haskell.

Java and C# are pretty much purely object-oriented, but they're still strictly typed (more strictly than C, actually), they use C-style syntax, and generally have a lot of C heritage.

Smalltalk is purely object-oriented (one of the earliest object-oriented languages) - and I mean extremely pure - dynamically typed, and has hardly any similarity to C at all.

Lisp (Common Lisp in particular) is a functional/imperative hybrid with strong meta-programming capabilities. Radically different from C.

Haskell is a strictly functional language. It requires a completely different way of thinking.

cyberfish
06-26-2008, 03:27 AM
Java is also interpreted which means easy reverse engineering and slow execution.


Modern JRE's do dynamic recompilation (compiling sections of frequently run code to native code based on runtime profiling), and some people have tried to show that it can be faster than a compiled language such as C++ (with optimizations based on runtime profiling which C++ programs don't have). Theoretically true, but practically, as of now, Java can only be faster than C++ on specially crafted code. But still, while it is generally slower, it's not like 5 times slower like it used to be.

That aside, I vote for C++. C# is too proprietary for my liking, and Java is incomplete (operator overloading, and what people mentioned above). I have a feeling that Java's design assumes that programmers don't know what they are doing. While it is true that I don't know what I am doing, I don't like that feeling :). Operator overloading is an example (funny how they have to use it with their string class, but allows no one else to). Pointers, too (what are references doing in there then?).

C_ntua
06-26-2008, 04:20 AM
Not to open a different topic, but can someone tell me what are the BIG differences in Java and C++. Differences on what you can do easily and what you can't. Lets not consider the differences in performance, safety, etc etc

Elysia
06-26-2008, 04:22 AM
I can't say much details, but as some have already mentioned: Java can't overload operators and Java is purely object-oriented.
That means there are no free functions - everything is inside objects.
Numbers and strings and all that are not objects in C++ - they are data types, so you can't expect "something".length() to work, as it might in Java.

Java does not support generic programming and templates to my knowledge. And I'm sure there's more.
Oh, and Java can't do multiple inheritance, can it (C++ can)?

CornedBee
06-26-2008, 04:23 AM
Java has huge, easily available libraries for server-side web programming. So many, in fact, that learning just a few for comparison is quite a task. C++ has far fewer there, and of lower quality. So for the web, Java is the better choice.

For the desktop, C++ has the better libraries available, IMO.

Language capabilities are much more about available libraries than the language itself. The libraries tell you what you can do (with reasonable effort), while the language capabilities merely decide how you do it.

Magos
06-26-2008, 04:34 AM
C++ has crap support for classes in libraries (dlls). Compile a dll in one compiler and u get face-slapped when trying to use it in another. And you're limited to the most basic types in library interfaces, you can't use std::string as an example.



That means there are no free functions - everything is inside objects.

Static functions



Numbers are not objects in C++

Neither in java, though they have wrapper classes that objectify them



Java does not support generic programming and templates to my knowledge.

Java has generics. Both templates and generics have their pros and cons.



Oh, and Java can't do multiple inheritance, can it (C++ can)?

Multiple inheritance isn't neccessarily a good thing

pheres
06-26-2008, 06:52 AM
C++ has crap support for classes in libraries (dlls). C++ has no support for it at all. You mean operating systems specific compiler/loader/linker.



And you're limited to the most basic types in library interfaces, you can't use std::string as an example.

Why that? Thats a function of mine I call from a lot of different DLLs for example



const std::pair<int, std::string>
get_type()
{
return std::make_pair<int, std::string>(ut), std::string("T72"););
}

medievalelks
06-26-2008, 07:01 AM
Another option that hasn't been mentioned: learn a scripting language like Python or Ruby, as well as how to interface with C and C++ from said scripting language (I'd recommend SWIG (http://www.swig.org) for that).

Thantos
06-26-2008, 07:42 AM
That means there are no free functions - everything is inside objects.

Not 100% true. You can have static functions that don't require an object. You still need to put it in a class but you never need to make an instance of it.



Java has huge, easily available libraries for server-side web programming. So many, in fact, that learning just a few for comparison is quite a task. C++ has far fewer there, and of lower quality. So for the web, Java is the better choice.
For web I like PHP. Loosely typed works well for the web IMO.



You could learn something radically different from C, if you just want to broaden your horizons. You could learn Smalltalk. You could learn Lisp. You could learn Haskell.

Lisp was interesting but the overuse of parenthesis make it a bear at times. I would also recommend prolog for something different.

cpjust
06-26-2008, 07:57 AM
Why that? Thats a function of mine I call from a lot of different DLLs for example



const std::pair<int, std::string>
get_type()
{
return std::make_pair<int, std::string>(ut), std::string("T72"););
}

That opens a whole can of worms for support & program updates:
Chapter 63. Use sufficiently portable types in a module's interface (http://www.ubookcase.com/book/Addison.Wesley/CPP.Coding.Standards.101.Rules.Guidelines.and.Best .Practices/0321113586/ch63.html)



Not to open a different topic, but can someone tell me what are the BIG differences in Java and C++. Differences on what you can do easily and what you can't. Lets not consider the differences in performance, safety, etc etc

In addition to what I already said about Java above, Java does almost everything at runtime instead of compile time. So the "Generics" that Java has is crap... If you have a List<int> and List<String>, you only have 2 List's of objects after you compile it.

CornedBee
06-26-2008, 08:14 AM
In addition to what I already said about Java above, Java does almost everything at runtime instead of compile time. So the "Generics" that Java has is crap... If you have a List<int> and List<String>, you only have 2 List's of objects after you compile it.
Type erasure is not crap. It's less powerful than substitution generics, but has the advantage of producing much leaner code.

Mario F.
06-26-2008, 09:32 AM
Not to open a different topic, but can someone tell me what are the BIG differences in Java and C++. Differences on what you can do easily and what you can't. Lets not consider the differences in performance, safety, etc etc



In C++ you can very easily crash your computer. In Java it is a little harder.
In C++ you can very easily create unsafe applications. In Java it is a little harder.
In Java you can very easily find a job. In C++ it is a little harder.




In C++ it is very hard to find something you can't do with it. In java it is a little easier.
In C++ it is easy to interface with hardware devices. In java it is harder.
In C++ it is very easy imbue other languages or access application APIs. In java it is a little harder (not necessarily java fault in most cases, but because of a general lack of proper language specific APIs).


Off the top of my head.

Magos
06-26-2008, 09:37 AM
Why that? Thats a function of mine I call from a lot of different DLLs for example

Try to compile and use on different compilers and you'll soon notice why. I did a while back on VS and Mingw I believe with unstable results.

Shaun32887
06-26-2008, 09:46 AM
In Java you can very easily find a job. In C++ it is a little harder.



Really? That surprises me. I guess I'm looking for work as an engineer and not a programmer, but I know from experience that me and almost all of my friends were asked if we knew C++ (and/or Matlab) when applying for jobs. I don't know of anyone who was asked about Java.

Mario F.
06-26-2008, 10:03 AM
Meaning there's usually more demand for java than for C++. Not that you can't find C++ jobs.

I can though be biased my own own job market trends, although I noticed similar tends in other countries. Notably Australia, Canada and Spain.

medievalelks
06-26-2008, 11:47 AM
In certain industries - like the trading industry here in Chicago and also in NY - C++ is the preferred language. In general IT, it's Java/J2EE and C#/.NET. Still some C++ there, but not nearly as much as the others.

That's why I ask what type of programming one is interested in when asked which language to choose.

pheres
06-26-2008, 11:57 AM
That opens a whole can of worms for support & program updates:
Chapter 63. Use sufficiently portable types in a module's interface (http://www.ubookcase.com/book/Addison.Wesley/CPP.Coding.Standards.101.Rules.Guidelines.and.Best .Practices/0321113586/ch63.html)

The link says:

Typically, either you control the compiler and options used to build the module and all its clients, and you can use any typeor you don't, and you can use only platform-provided types and C++ built-in types (even then, document the size and representation you expect for the latter). In particular, never mention standard library types in the interface of a module unless all other modules that use it will be compiled at the same time and with the same standard library source image.
Fortunately I control the compiler for all modules. But it was an interesting read, so thanks.

cpjust
06-26-2008, 02:09 PM
The link says:

Fortunately I control the compiler for all modules. But it was an interesting read, so thanks.

I would still avoid using non-primitive types across modules though, because if you apply any compiler service packs, or even change some compile settings and then fix a bug in one of your DLL's and release a patch to customers, the ABI might not be compattible anymore.

Mario F.
06-26-2008, 02:30 PM
So much for the Standard template library.

Daved
06-26-2008, 02:39 PM
>> So much for the Standard template library.
Why? It's a standard interface, not a standard implementation.

Elysia
06-26-2008, 02:46 PM
It's quite disgusting to see that you cannot use standard library types in an interface.
Then what is the whole point of using C++? It is, maybe, the single, biggest flaw in the entire language.
Use any types except for the standard library types and it works well.
It severely limits C++ interfaces.

Daved
06-26-2008, 02:53 PM
>> Use any types except for the standard library types and it works well.

This is wrong. The problem exists for any non-primitive type.

Elysia
06-26-2008, 02:55 PM
True, in a sense, but not as much.
They are more compatible, although may still cause some problems.
But that's just another thing to add to the list of things C++ can do better.
It's pretty inexcusable for a modern language not to be able to create a stable interface.

Daved
06-26-2008, 03:12 PM
>> They are more compatible, although may still cause some problems.
I don't understand what you're trying to say. Any library type will cause problems if you link to different implementations of that library. The only reasons the standard library is used as an example are that it is used often and there are different library implementation available.

>> It's pretty inexcusable for a modern language not to be able to create a stable interface.
You can create a "stable" interface, just not one using all the library additions you'd like to. I'm not saying that these issues aren't a burden, but you're making things up to complain about.

Elysia
06-26-2008, 03:17 PM
>> They are more compatible, although may still cause some problems.
I don't understand what you're trying to say. Any library type will cause problems if you link to different implementations of that library. The only reasons the standard library is used as an example are that it is used often and there are different library implementation available.
Well, the idea was that in implementation X, std::string has a member called, say, m_str of type const T*, and then a size of type size_t.
In implementation Y, those are switched, so it would likely cause rubbish data or a crash when passing it through an interface between those two.
However, if it were a custom data type, this would not occur because they would always be placed at the same location.
What might cause problems may be padding or such.
Thus custom data types are not as prone to errors as standard library types. They're less error prone, but still error prone.


>> It's pretty inexcusable for a modern language not to be able to create a stable interface.
You can create a "stable" interface, just not one using all the library additions you'd like to. I'm not saying that these issues aren't a burden, but you're making things up to complain about.
No, not really. You would expect to be able to pass C++ types across boundaries, but the fact that you cannot makes this a big deal that is worth complaining about.
I haven't heard of many such issues with other languages. Especially not Java, C# and the like.
C++ cannot compare to those languages in this respect and it's a real drawback that is limiting the language's potential.

Am I overreacting?

Daved
06-26-2008, 03:24 PM
>> However, if it were a custom data type, this would not occur because they would always
>> be placed at the same location.

This is (again) missing the point. Any custom type will have a problem if you link to different implementations of it. Of course it will be less of a problem if you completely control the building of your own custom type, but that wasn't my point. My point was that all libraries have this potential issue, it is not specific to the standard library. There are many other libraries available that you do not control and you will can have the same problem with those. The problem is not with the standard C++ library, the problem is with the language itself and the lack of ability to ensure a consistent implementation.

>> You would expect to be able to pass C++ types across boundaries, but the fact that you
>> cannot makes this a big deal that is worth complaining about.

Sure, but you're complaining about the wrong thing and basing it off of (or backing it up with) erroneous information.

Elysia
06-26-2008, 03:39 PM
The problem is not with the standard C++ library, the problem is with the language itself and the lack of ability to ensure a consistent implementation.

Ah well, in the end it boils down to that. And that is the problem, indeed.
And that is the problem they really must address.
The End :)

Mario F.
06-26-2008, 03:53 PM
>> So much for the Standard template library.
Why? It's a standard interface, not a standard implementation.

The code example provided that spurred this last discussion was entirely made of built-in types and STL interfaces (an int, an std:: pair and a std:: string). Naturally I couldn't agree more with you when you mention this is necessarily a problem with any libraries that provides an interface to built-in types.

However, I think this should be addressed exclusively from the perspective of different programming languages (where the argument does make a lot of sense). Not for fear of different C++ implementations. The STL interface should be only one, the implementation however can vary.

Hence my comment. It was an alert that it shouldn't be discussed as the latter.

EDIT: In the interest of portability I'm of course happy to ignore my own comments on this. And I'm glad I was following this thread when the comment from cpjust came. I hade never thought of it before. But I cannot ignore the irony behind what now becomes lack of portability feature of the STL, according to the text.

cpjust
06-26-2008, 09:22 PM
It's not just STL objects that have problems across modules, it's any object. Even though the API (http://en.wikipedia.org/wiki/API) of the STL (or custom) objects don't change between various compilers (or compile options), the ABI (http://en.wikipedia.org/wiki/Application_binary_interface) does.

CornedBee
06-27-2008, 02:57 AM
FUD.

Compiler vendors take great care not to change their ABI between compiler versions, especially minor compiler versions. You can safely do any micro version upgrade in GCC, for example, because the rules of development state that no such incompatibilities are allowed to exist. The same applies to minor versions, but there are a few exceptions (there was big trouble during the GCC 3.2 to 3.4 versions). Only major GCC upgrades (from 3 to 4) make no guarantees about ABI compatibility.

Pretty much the same applies to Microsoft's compilers. I don't know exactly when they break ABI compatibility, but I'll bet it's not very often.

Any vendor that breaks the ABI more than once in several years is using a completely idiotic development methodology, and that's not C++'s fault.



No, the only real problem is interoperability between different implementations.

cpjust
06-27-2008, 08:17 AM
Surprisingly, there's still a lot of companies using VC++ 6.0. If they suddenly decided to get out of the stone age and upgrade to the latest version, I'm almost certain the ABI would be different. As for minor compiler patches, sure it's unlikely they would change the ABI, but not impossible.

You never know how long a particular version of your software will be around, so unless you want to get stuck using the same compiler forever when you release product fixes, use only primitive types across DLLs...

Plus, I believe small incompatibilities can creep in even if you just change some of the compile/link settings.

medievalelks
06-27-2008, 08:31 AM
Surprisingly, there's still a lot of companies using VC++ 6.0. If they suddenly decided to get out of the stone age and upgrade to the latest version.

My client is one of them. There's just no real business case to upgrade 100s of thousands of LOC to get "out of the stone age". Some of the code hasn't been touched in 10 years but it's still running in production and bringing home the bacon.

cpjust
06-27-2008, 09:25 AM
My client is one of them. There's just no real business case to upgrade 100s of thousands of LOC to get "out of the stone age". Some of the code hasn't been touched in 10 years but it's still running in production and bringing home the bacon.

Well I highly doubt you'd need to change much of the actual code itself (unless they've been compiling with really low warning levels like my company has), but definitely the project settings.

Elysia
06-27-2008, 09:28 AM
Umm, are you missing that MSVC6 is not very standards compliant?
For example, pointers to member class functions were not fixed until 2005.
(Or maybe it's that the compiler is missing a lot of stuff, like partial template specializations.)

cpjust
06-27-2008, 09:33 AM
Umm, are you missing that MSVC6 is not very standards compliant?
For example, pointers to member class functions were not fixed until 2005.
(Or maybe it's that the compiler is missing a lot of stuff, like partial template specializations.)

But most of that should only affect if you want to downgrade to VC++ 6.0. Upgrading should be pretty backwards compatible.

Elysia
06-27-2008, 09:34 AM
Well, as I mentioned, VC2005 breaks a lot of stuff from earlier versions because it's more strict and standards compliant.
Class member functions is only one example of where it will break existing code.

pheres
06-27-2008, 11:06 AM
I would still avoid using non-primitive types across modules though, because if you apply any compiler service packs, or even change some compile settings and then fix a bug in one of your DLL's and release a patch to customers, the ABI might not be compattible anymore.
Why not just update all modules in an atomic manner, after compiler/ SP/ settings changed?
Of course, this is not doable in all circumstances. So I think the rule to avoid complex types in interfaces is a bit strict and should be only applied if the project type demands it.

For example, for lot of projects my company specifies whole buildings, containing computers, containing OS and modules (built only by us) :) Never will there be a situation there we need to upgrade single components build with a different compiler or something similar.

Mario F.
06-27-2008, 11:13 AM
Necessarily the advice needs to be taken with a grain of salt. The notion that "just because it may happen one day" is not always (rarely is from a business perspective) a good argument.

C_ntua
06-28-2008, 02:54 AM
Do the rest agree that C++ has the best libraries? Or in any case very good ones?

Also, does it has good libraries for making a GUI compared to the others?

Generally, in which fields each of the above languages would be A LOT more useful? That would help me choose :)