I think it's the other way round. I mean, statistically people who first learn well C++ are more successful in Java than people who first learn Java (and not knowing even "C") are successful in C++.

Hear! Hear!

This statement oozes truthiness. My campaign to get local university instructors to teach C/C++ and the standard C library before (or instead of) Java have fallen on deaf ears.

Even when presented with dozens of examples of potential employers requiring C/C++ knowledge and preferably experience, they are still pushing Java like crazy and telling their students that C/C++ are overrated in the marketplace. Unfortunately, there is very little full-time work available for those who aren't fluent in C/C++ and recent graduates are turning to internships and additional courses to fill this hole in their (expensive) education.

I spend much more time coaching interns through un-learning bad habits acquired in Java classes (pun intended) than I would like. Interns who have at least a passing familiarity with C and the standard C library fare far better.

Statistically? I would not mind seeing those statistics so please post them.
As I said - if you learned java properly = not the way it is taught in the typical "Java in 24 hours" books. A proper education in java starts from the basics, teaching stuff such as data types, promotion, demotion, bit shifting, encodings, control and data structures, etc. before introducing object oriented features.

What is wrong with teaching the two side by side? I know for a fact that most European universities require their students to specialize in at least three programming languages...

Because, as a rule, they are. Where I live, I can get fifty jobs that require Java or .NET versus one that requires C(++) - and that is not difficult to support with statistics. The need for Java/.NET developers is such that our government is offering publicly financed training programs to anyone with a good brain who is even half interested. And as computing keeps shifting in the direction of networking, the need for Java/.NET will only increase. Sure, you can quote some complaints from hardware manufacturers like Intel bewailing the neglect of C++. But ask yourself, what percentage of graduates are they likely to employ?

While I think 50:1 is an exaggeration, I will agree there are more jobs in Java and .NET (note that these are not even close to the same thing) than in C or C++. That is true in my area too.

However, when I look at the rate I can get working a Java or .NET job, vs the rate I do get using C for what I use C for, I think I'll stick with C. I am making anywhere from 2 to 3 times per hour what I could get programming either Java or .NET. Mostly, of course, that is because what I am doing involves a relatively uncommon skill set. But I am not certain at all that I could even do most of it in Java, and doing it in .NET would just be painful.

Well, of course. But imagine what would happen if universities started pushing C and C++. The only ones who would not see their income drop dramatically would be the ones who, like you, have and additional skillset to thow in. Just consider what happened when IBM started its C training campaigns. As I said, most IT graduates over here do know C, C++ and .NET in addition to Java (because it is the job of a university to teach fundamentals first and specific implementations only second) - yet the large majority end up doing Java and .NET exclusively. For most purposes, the relative convenience and stability of managed code is a lot more attractive (cheaper), even if it means that one will have to invest in more hardware to achieve the same performance. Which would be cheaper? An extra server or an extra developer? Obviously, in some cases it is vital to make do with the least hardware possible - but that is not the rule. And if something like LHC is programmed in Java, it should be obvious that the language is a lot more flexible than generally assumed. Unless you take it for granted that the whole things is run by nitwits (not very likely).
Ironically, people who love C or C++ should refrain from pushing for more C/C++ education. Having what is a minor market swamped with a growing number of candidates would only reduce the likelihood of their finding a job that requires C or C++.

Anyway, the point I was trying to make is I do not see why anyone should choose between C or C++ as I found both quite easy to pick. I think it may make more sense to learn C first, alhtough I went the other way.

Guys, I'm sure Java is wonderful. Whatever works for you. I just have problems with it, I'm not trying to start a flamewar here.

Artists and web-designers needed even more often than Java and .NET programmers, but "which job pays better" has nothing to do with this thread.

You still didn't say what about Java you don't like. That might inform the advise we should give you about C vs. C++. Aside from the semi flamewar, we also are trying to provide some useful information.

What I don't like in Java:

1) The results will run a lot slower than in C or C++.

2) Garbage collect memory management.

3) Lack of multiple inheritance.

4) Lack of pointers (though Java references act a bit more like pointers than C++ references do).

5) IIRC, lack of embedded structures (vs. references).

For a beginner, I think the biggest problem in Java is that both the syntax and the documentation tend to mask the actual behavior of references.

If you have previous experience in a language (such as C or C++) that has pointers, you just need to understand a reference is internally a pointer. When you work with pointers, you must understand the distinction between the pointer itself and the object it points to. The syntax of pointers focuses attention on that difference. When you work with references you still need to understand the distinction between the reference itself and the object it references. The syntax hides that distinction, but if you understand the language the distinction is still there. You just need to know which syntactic constructs operate on the reference itself vs. the referenced object. After a little time programming in Java, it becomes natural to think pointers while coding references.

Fair enough. It might sound silly, but here are my reasons for not liking Java (needless to say, I didn't get very far into it, but this is it):

• Slow
• No pointers (I've never heard of "references")
• Can't be compiled (at least, not efficiently - Python has the same problem)
• I don't like Swing (laugh if you want, I don't like it)

Not too solid, but I saw disadvantages to using it from the beginning. And the syntax wasn't much fun to try and learn.

• Slow: True, but that matters a lot less often than you might expect. I tend to work on projects where the speed is important. In the majority of programming speed isn't important.
• No pointers: What do you want to do with pointers? Much of that can be done with references in Java. In Java, most names that seem syntactically to be objects are actually references to objects. Like a pointer, a Java reference can be changed to refer to (point to) a different object, and like pointers, multiple references can point to the same object. If you learn some decent subset of C++, you don't really need to learn about references, but they are a useful feature.

Most Java syntax is C syntax and C++ syntax. C++ has lots of extra syntax possibilities and rules that may make it even harder to learn, though much of that is for features you don't really need to learn.

It is seldom that someone writes something in a technical forum with which I disagree so thoroughly.

Speed is ALWAYS important - always! The attitude that speed isn't important invariably leads to bloated software that sucks CPU cycles that it doesn't need to suck. The consequence is that systems get bogged down when it shouldn't happen. This results in more/bigger/more power hungry machines being deployed - and all because the programmer was too lazy to take speed into consideration.

You should always program as if your software was to run acceptably on a 1 MHz 8088 processor.

Go fast. Next question?

I agree with jiml8, while I understand that speed isn't always a huge factor in programs I'd like to use something fast just so that later on, if I need something fast I can make it.

I understand a pointer as being a reference to a location in memory, which I see lots of useful applications for. Since I don't really understand references, I'm not sure I could really do the same things with them.

The compiling point is a big one too. I would strongly like something that can compile without packaging an interpreter into the EXE. Java, AFAIK, can't do that.

Really, I'd like to know if it's even worth learning C++ knowing that most things are done with VC++ nowadays. I've searched how to do some stuff in C++ (and C) just to see how available information is for each language, and there are some things in C++ (for instance, loading a DLL) where they're pretty much assuming you have VC++ in every example I can find. If I learn C++ with MinGW, am I going to be able to find information on how to do these types of things without using MFC and ATL libraries?

Small wonder you found only references to VC++ when you looked into DLLs; they are a windows feature (NIX uses shared objects instead). Which should be enough to stress the real drawback of compiled languages: you cannot trust that your code will run on any CPU or operating system - in fact, as a rule it will not.

I am almost always on the other side of that argument and my position hasn't shifted, so I think you are expressing an viewpoint very far from the mainstream.

When you expect speed to matter, most experienced software engineers think the best approach is to select algorithms for speed, but still code as if speed doesn't matter (most of them see a cleaner distinction between "algorithm" and "coding" than I see). Then, if the speed isn't good enough, profile the program and tighten the coding only where the profile says it is important.

I believe in developing and exercising good judgement about where in your program speed will matter and coding all those areas with execution speed in mind, even before a profiler tells you where that hot spots are.

There are sections in any program that will be executed at most once per run of the program. In most programs there are large sections executed only a few times. Do you really want to squeeze the last few nanoseconds out of those sections of code? That is a total waste of effort.

There are sections of the programs I work on that may be executed many billions of times per run of the program. Every nanosecond I squeeze out there is many seconds of savings per run for the end user.

Sorry, but that is absurd. If you were really designing for a computer thousands of times slower than current ordinary computers, you would cut feature after feature from your design. Features that are nice to have and perfectly practical now would be too slow to be worth using on computers ten times slower, not to mention thousands of times slower.

At work, I am often criticized for focusing too much on execution speed. I'm used to coding for speed. In many cases where speed doesn't matter, I code in a way that will execute faster, because it is no extra effort for me. When speed does matter, I put in the extra effort to get the best speed from the very beginning of coding. But even I code very differently when speed matters than when it doesn't and even code differently yet again when I coded for speed the first time, but profiler results show room for improvement.

If you put that focus into speed for every line of code, you would get only a fraction as much work done and you would produce an unmaintainable mess of code. That is not the way to do software engineering.

Perhaps. But look at the huge quantity of bad software out there. Look at the continual push toward bigger and faster computers - not in order to run radically new software that brings more and more power to the table, but to run "upgrades" of existing software, which is bulkier and bulkier, and slower and slower.

I've been doing this for over 35 years; if I am now espousing a minority opinion, then I am proud to. These machines are being poorly utilized when the idea is that "speed doesn't matter".

The ones saying that are the same ones who buy giant SUVs to go to the grocery store.

It is an extraordinarily wasteful philosophy.

And the really experienced software engineers will start with a design that considers speed as an important parameter. Or, will consider the tradeoff between size and speed at all points. Then, when they profile their code looking for bottlenecks, they will do so knowing that they've already taken steps to optimize (as opposed to maximize) speed.

Like I said...

And - as I said - speed is ALWAYS important. Speed should NEVER be neglected in a design. At any point, even if that segment of code only runs once. But considering speed as an important parameter is not the same as saying that speed must always be optimized.

It is, however a big step between what I said - that speed is ALWAYS important - and what you said - that speed doesn't matter in most programming.

So please don't set up strawmen, and don't try to shift the ground on which we are discussing, and don't misinterpret what I said.

It is a decent rule of thumb, not to be taken TOO literally because, yes, later generation processors have capabilities that can't be matched at all in an early generation processor. But the concept is the same. If you can, make it go faster. Certainly NEVER accept the argument that "speed doesn't matter."

In fact, if you are working for me, you'd better never even advance the argument.

Actually, at the present time I am implementing a system where I have actually - gasp! - gone to lookup tables to handle both square roots and base 10 logarithms, because I don't want to incur the processor cost of computing them on the fly, and I can accept the slight loss of precision that the lookup tables cost me in exchange.

How I code varies according to HOW IMPORTANT speed is. but speed is NEVER unimportant. Other things might be more important in a given context, but speed is ALWAYS important.

More strawmen.