Moving from Java to C++

[Rui]

Hello everybody,

I have some experience in Java, I understand the concepts related to OO programming, and I want to learn C++. I already have experience in C, so it seems a good background. But it seems hard to find information or tutorials explaining the major differences between Java and C++ from a technical point of view, I'm trying to research for something like "in Java this is done this way, in C++ it's done like this", but appears not easy to find good info. I believe I'm not the first one trying to make this passage from Java to C++. Can anyone suggest some good resources the way I explained if they exist, or it's definitely better to start normally from a C++ book, that of course has many starter concepts I would like to jump?

Thanks

[kasper]

Hi

• Google gave me Essentials of C++ for Java Programmers. I haven't used it, but after skimming it, it appeared to be useful. [edit]They completely forgot about templates (a.k.a. generics in java). A major omission.[/edit]
• I like The C++ Programming Language by Bjarne Stroustrup (@amazon). Still my favourite C++ book on my shelf. It's a good reference book, not specifically for the switch from Java to C++, though.
• Effective C++ by Scott Meyers (@amazon) is also nice. Its oriented to those who already know C++, but want to improve their C++ coding.
• Finally, Large Scale C++ Software Design by John Lakos (@amazon). Again for the immediate upto advanced C++ programmer. It's about doing large projects in c++, an OS would certainly count. The book contains information about keeping compile time low, being able to test your project, etc.

The other C++ books on my shelf I wouldn't recommend. Although none of the books above is specifically for the switch from Java to C++ and neither is any specifically about OS development, I still hope this information is useful to you.

Kasper

[Rui]

Useful information kasper, thanks a lot for the quick reply

[Solar]

Scott Meyers (Effective C++, More Effective C++, Effective STL) provide valuable advice and insight.

Things you have to understand to use C++ properly:

• Headers, and how to use them efficiently - both from a syntactic point of view (only write what is really necessary into the header), and from an organisational point of view (putting them into a seperate directory so they provide the "public face" of your code).
• Pointers; how to use them, but more importantly, how not to use them. In Java, everything is "new" this and "new" that, whereas good C++ code can go a long way without new / delete.
• References; and how they solve many problems you would need pointers for otherwise.
• Iterators; how they are used (which is somewhat different from Java's getNext() / hasMoreElements()), and how they empower you to use the stuff in the <algorithm> header on just about any data collection.
• Functors (that's a class with operator() overloaded so an object of that class can be called like a function); and how they allow the stuff in <algorithm> to do whatever you like.

That's ad-hoc; if you have any more specific questions, fire away...

PS: Yes, templates are what gives C++ its power. But while you are using them every day in library functions, you can go a long way without actually having to implement one, so I consider them stuff for the "Advanced" course.

[DeletedAccount]

A free book that is quite good is Thinking in C++ , by Bruce Eckel . . IMHO , the best way to learn any language is to read lots of code and write lots of code .

Regards
Shrek

[stephenj]

I'm trying to research for something like "in Java this is done this way, in C++ it's done like this", but appears not easy to find good info.

There's a good reason for this, you don't want to treat the issue like a one-to-one mapping. If Java and C++ were so similar that you could do that, then what would be the point of learning both? You would just be writing Java programs in C++. Which would just be a waste of your time.

What you want to learn are the differences between C++ and Java. Starting from the ground up (Java forces a certain orthodoxy that you should try to unlearn). You have a lot more options in C++, and a lot more is possible.

As an aside, if this is your second language, then you may want to learn Python, Perl or Ruby before C++. Most people I know that have learned one of them rarely go back to Java, and you'll have to find out why yourself.

[Solar]

You would just be writing Java programs in C++. Which would just be a waste of your time.

Not to mention one very frequent mistake made by former Java programmers that makes C++ coders groan in pain and frustration when they get to look at your code.

Seriously. There is a very typical "style" of C++ coding done by Java converts, and just as the also typical style of C converts, it's woefully inefficient, and a pain to refactor.

Java does "new" at every corner because that's the way to go with a garbage collector. C does "malloc" at every corner because that's the way to go when you don't have any automatisms to do memory management for you.

In C++, I claim that any "new" outside a constructor, or any "delete" outside a destructor, is a programming mistake in over 90% of all cases.

[DeletedAccount]

Seriously. There is a very typical "style" of C++ coding done by Java converts, and just as the also typical style of C converts, it's woefully inefficient, and a pain to refactor.

just out of curiosity , what would be the java /C# coding style of a C++ coder ? Where should a C++ coder be careful ( consider someone who is more inclined towards C , than C++ ) ? .


edit: grammar mistake corrected
Regards
Shrek

[Solar]

I don't really understand your question. "what would be the style of a java /C# coding style of a C++ coder"? You might want to rephrase that.

In one sentence:

• C coder gone C++: Uses char[] and linked lists instead of <string> and <vector>. Uses return values of -1 instead of exceptions. Uses pointer type arguments where references would do.
• Java coder gone C++: Uses "new" where there is no reason to do so. Uses member functions where an overloaded operator would be better (add()). If you are lucky, iterates through a container using size_t i < container.size(). If you are not lucky, writes wrapper classes with next() and hasMoreElements(). (Been there, seen that, more than once.)

In case you asked about how a C++ coder would betray himself in Java... I don't know really, I'm not good enough at Java I'll admit.

[Combuster]

[*] C coder gone C++: Uses char[] and linked lists instead of <string> and <vector>. Uses return values of -1 instead of exceptions. Uses pointer type arguments where references would do.

I'd add "Uses malloc rather than new"

In case you asked about how a C++ coder would betray himself in Java... I don't know really, I'm not good enough at Java I'll admit.

I think, the key things in C/C++ are invalid in Java, while the reverse doesn't hold. I kindof expect traits like not using the JRE to the fullest, by skipping the things that are not in C++' STL and rewriting things like tree structures, not using equals/hashcode etc.

I think many would be more frustrated for the lack of some features.

[Solar]

ACK.

A sentiment I have heard repeatedly by Human Resources types was, knowing C++ and learning Java is much easier than vice versa.

[Colonel Kernel]

In C++, I claim that any "new" outside a constructor, or any "delete" outside a destructor, is a programming mistake in over 90% of all cases.

I agree about delete, but I disagree about new. I think it depends a lot on what type of system you're building.

If you're writing applications in C++ and you control all the threads and all the global state, then I think you can get away with using "new" a lot less. But consider the case where you're implementing a shared library that has to conform to some standard API (e.g. -- an ODBC driver). A lot of these APIs have primitives like "allocate resource x," "free resource x," and "use resource x to do y". In these cases, the lifetime of a resource is determined by calling code that you can't control, so it must be allocated dynamically.

Now, if you're just talking about hiding "new" behind a factory method, that's a different story. Just don't make the mistake of assuming that all of your experiences in C++ apply to everyone. C++ is a broad language that can be applied in a variety of ways to a variety of domains, many of which are unfamiliar to you (and me, for that matter).

[Solar]

If you're writing applications in C++ and you control all the threads and all the global state, then I think you can get away with using "new" a lot less. But consider the case where you're implementing a shared library that has to conform to some standard API (e.g. -- an ODBC driver). A lot of these APIs have primitives like "allocate resource x," "free resource x," and "use resource x to do y". In these cases, the lifetime of a resource is determined by calling code that you can't control, so it must be allocated dynamically.

Agreed. It the interface is defined by someone else, you're in trouble. On the application side you can get away with a thin wrapper layer, but I imagine it's much less fun on the library side.

Just don't make the mistake of assuming that all of your experiences in C++ apply to everyone. C++ is a broad language that can be applied in a variety of ways to a variety of domains, many of which are unfamiliar to you (and me, for that matter).

100% ACK. C++ can be used in virtually every niche you can think of, and you cannot be master of all. But generally you start on the application side, slowly moving into libraries and interfaces and such things, so by the time you get there you don't need Java <-> C++ help anymore.

[Colonel Kernel]

But generally you start on the application side, slowly moving into libraries and interfaces and such things

Not me, I was thrown straight into multithreaded middleware/server code, and from there into database drivers. In my experience, few applications are developed in C++ anymore... it's usually C# or Java these days.

[AndrewAPrice]

If you're starting out C++ and not use to cleaning up after yourself, find a simple smart pointer class! One with a reference counter (they automatically delete when they loose scope!), and you can kind of treat them the same as in a native-GC language like Java.

In my experience, few applications are developed in C++ anymore... it's usually C# or Java these days.

Umm.... that's just your experience. In my experience in the video game industry C++ is used near universally in game frameworks, game code, and related development tools. C# is SLOWLY catching on (you find the odd editor or compile tool written in C#) but it's not common enough for me to rank as "usually".

And it's not just because of legacy code either. Everyone once in a while frameworks get re-written from scratch (that's why some projects start 4 or so years before they're released).

There are a few reasons why I think the video game industry sticks with C++:
- The APIs (Direct3D, OpenGL, PhysX, Havok, Speedtree, etc) are all C/C++ based (so I guess it is kinda for legacy stuff in a way).
- Everyone else in the industry knows C++ (imagine how much harder it would be to get a job if languages were an extra criteria).
- Even if a language isn't hard to pick up (Java/C#/D for a C++ programmer), a team would rather use a language that everyone knows all the ins and outs of when they're working to a deadline and have to write performance critical and stable code, rather than spend the time experimenting the different features of the language.

I'm all welcome for change, but since C++ has established itself I don't see it moving for a quite a long time.

I know D has certainly proved itself in performance (and simple to interop with C/C++ libraries), but the community is still rather small and I don't see any mainstream developers (or middleware developers - who can force you to use a certain language if your manager is set on using their framework) pushing it (or any other language) for it to become a major influence.

I don't know of what general application development or systems programming is in general, but I'm guessing it's the same scenario.