Can Java Programmer Learn C++ Quickly?

[Ann]

I realize that this is not entirely a Java question but I am hoping that
some of the people reading this newsgroup are Java programmers who went on
to learn C++.

I am giving some thought to applying for some jobs that want people with
Java and C++ experience. I have been writing Java for several years and am
fluent enough that I don't have to post questions here very often. I have no
real C++ experience and not much C experience for that matter.

Did you consider C# instead of C++?

 

[Sudsy]

Did you consider C# instead of C++?

Why on earth would you propose considering a proprietary language?
This /is/ c.l.j.p after all. Where's the ASCII symbol for a flat
again? ;-)

 

[bugbear]

However, the core Java statements are "borrowed" from C and C++ has often
been called "C with classes". It seems to me that it shouldn't take very
long to get up to speed on C++ if I am already fluent with Java and have at
least some knowledge of C.

Two things will hurt you. Badly.

1) Memory management - disciplined and careful use
of constructors and destructors will help here, although
the whole idiom of carefully KEEPING references
around so you use them do deallocate memory will be
extremely "backwards" to a java programmer.

2) Libraries. Java is a tiny and simple langugage. Most of
the complexity and learning is in the assorted libraries.
Java has the advantage of a single, large, set of libraries,
so it's worth learning this. In C++, the libraries are more
varied, and less universal.

You won't be able to design an "industry grade" C++ program
until approx 12 months of study/use IMHO.

BugBear

 

[Chris Smith]

Please point out where I said it would take months to 'get' pointer
arithmetic.

I don't believe you did. I'm responding to the general idea, expressed
at several points in this thread, that it would take months (or even
years) to understand this stuff.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

Did you consider C# instead of C++?

Huh? If the job requires Java and C++, why would you learn C# instead
of C++? That's like learning Spanish so that you can travel to Quebec.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Riesbeck]

... IMHO, the library is a disaster in C++, but it
is very *in* to vault the STL. In practice, I'd say that you do have to
know the tradeoffs with regards to the containers (vector, deque and map
are the ones I use most often -- almost never list). On the other hand,
I've found very little use for most of the algorithms in practical code.

...

Once the basic syntax is mastered, I'd strongly recommend Scott Meyers'
three books. The first one ("Effective C++"), particularly, addresses a
number of classical issues that you just have to know.

For someone with Java (or C#) experience, I'd also recommend
Koenig and Moo's Accelerated C++, because it quickly jumps
into writing good clean modern maintainable C++ code, practically
from page 1, making heavy use of the STL and some of those
algorithms you've found little use for.

 

[James Kanze]

Ever seen perl code ?

Point taken. Perl makes C++ look like a model of simple elegance and
readability. On the other hand, while Perl is significantly less
readable than if average C++, it probably contains less traps for the
unwary than C++.

You might characterize Perl as a write only language -- it's not that
difficult to get a somewhat working application, but God help the poor
soul who has to read and understand it. Whereas C++ tends to other
direction -- a well written C++ program can be a joy to read, but there
are quite a few little things you have to know and to pay attention to
to get there.

And to get back on topic, I'd rate Java between the two, albeit much
closer to C++ than to Perl. Well written Java is quite readable -- not
as much as C++, but still, not bad. And while Java is lacking in many
of the more basic things you need to write really robust applications
(e.g. static linking, so you can test what your customer actually runs),
things like garbage collection and a well designed set of libraries do
mean just that much less that the programmer has to do.

 

[James Kanze]

James Kanze wrote:

Right, but it's not something a Java (or VB) programmer would have
thought about. So for you it's no problem, but the OP asked the question
from the point of view of someone learning the language.

I'd argue that this isn't true if he has been writing good Java.
Garbage collection no, you do have to think about lifetime of object
issues at the design level, as part of the design.

In Java, most of the time, your work stops there. A quick evaluation,
just to be sure that garbage collection IS adequate, and no real code to
write, except in the exceptional cases (somewhere between 5% and 10%)
where it for one reason or another, you do need determinist disposal.

In C++, when you've handled the design aspects, your work has just
started. BUT... if you get the design aspects right (which you should
be doing in Java as well), most, if not all of the extra work is just
grunt work -- it doesn't require much thought, and while it often
requires more code than one would like, C++ does have several
techniques, such as destructors, which make it actually superior to Java
when you need determinstic disposal.

No so much difficult as unforgiving.

If you mean that a small mistake can do a lot of damage...

But that's the design philosophy of C and C++, isn't it? That
programmers never make an error, so if they in fact do...

IIRC, the containers use pointer arithmetic for iterators.

It depends. Some of the containers have iterators which allow
arithmetic which behaves somewhat like pointer arithmetic. All of those
containers also support indexation, however, so once again, you're not
obliged to do stupid things if you don't want to.

When it comes down to it, of course, neither C++ nor Java can be taken
as models with regards to their collections and iterators. C++ uses
really stupid names, like ++ and *, rather than a simple, understandable
next() and element() (or something along those lines), but that's just a
naming convention. Java combines access and incrementation, which is
very constraining, and not at all nice. But C++ takes the cake by
requiring two iterators -- try using one function to determine the range
that you want to pass to another function, and you'll pull your hair
out.

What I really don't understand in all this, of course, is that most
pre-Java and pre-STL libraries used pretty good, straightforeward
iterators -- like those described in the GoF Design Patterns book, for
example, or those in the OSE C++ library. Given that we knew well how
to do it before the STL or Java, it's hard to understand the design
decisions in these libraries. (The Java Collections, in fact, implement
the iterators in the USL C++ library almost exactly. Something that C++
users knew was a mistake as early as 1990.)

Still, if you are going to learn C++, you probably have to count on
investing a bit of time learning the STL. And THAT isn't easy. There
are alternatives, like the OSE library, but they aren't widely used, and
as a beginning C++ programmer, you probably won't be able to impose them
on your employer. (I have yet to succeed in imposing them, and I'm far
from a beginner when it comes to C++.)

As you don't offer up your alternative, I'll just take that as a
personal slur.

Sorry. Today, of course, std::string is pretty much standard. I don't
know of a compiler which doesn't support it, and I don't know of any new
code which doesn't use it.

Before around 2000, of course, this wasn't so true. But I've still
never seen a C++ application which didn't use some sort of String class.
Historically, it was the first class you wrote; even today, a simple
String class is a good exercise for a value oriented class.

Think of it from a Java point of view. If the language didn't provide
java.lang.String, would you really use Char[] with a '\0' terminator?
Or would you write your own String class?

The OP mentioned jobs that ask for C++ experience. Often that means that
they have an existing code base, and often the programmer who proceeded
you used STL.

That depends. Real support for STL has only appeared in the last few
years, so if the code base goes back some, they more likely have some
third party library, or their own. And if they have their own, you'll
find real resistance to the STL, even if their own is worse (and believe
me, I've seen lots worse that the STL).

On the other hand, one of the major motivations today for taking on new
C++ programmers is to acquire knowledge of these new techniques.
Personally, at the application level, I"ve yet to find the slightest use
for template meta-programming (although it's fun -- very intellectually
challanging), and I find the STL a disaster. But... good knowledge of
the two will almost certainly land you a job.

I like the associative containers for parsing lvalue,rvalue pairs into.

Agreed. Although as usual, the interface is a bit twisted. This is one
point where Java is definitly better, although when I did Java daily, I
missed the lack of type safety.

Yep, second the Meyer's book.

It's the Meyers' books. "Effective C++" and "More Effective C++" for the
language, and "Effective STL" for the library.

 

[Ian T]

I'd argue that this isn't true if he has been writing good Java.
Garbage collection no, you do have to think about lifetime of object
issues at the design level, as part of the design.

It's not so much the lifetime of the object, but the ambiguity as to
where an object may end its life. For most objects, there is no
ambiguity, but occaisonally there is. In those cases, the garbage
collector acts as a safety net, but in C++ you don't get that.

A bit of extra work, but not something


If you mean that a small mistake can do a lot of damage...

I mean that you may have one tiny, almost unnoticeable memory leak in an
application that runs as a 'daemon' or 'service', and the application is
expected to run continously, so 3 months down the track it can take the
whole server down when it uses up the entire heap. Not that it's ever
happened to me of course , but it's an extra level of long term risk
that the garbage collector can mitigate somewhat.

Sorry. Today, of course, std::string is pretty much standard. I don't
know of a compiler which doesn't support it, and I don't know of any new
code which doesn't use it.

Right. I use std::string, but there is still a huge codebase out there
(which someone has to support for the next 10-20 years) that uses
null-terminated character arrays, including the Win32 API. And of course
the std::string implementation uses ntcas as well.
I'm not at my development computer, but just doing a search through some
of the open source C++ code I've downloaded reveals that there are still
plenty of people who have not moved entirely to std::string.

Think of it from a Java point of view. If the language didn't provide
java.lang.String, would you really use Char[] with a '\0' terminator?
Or would you write your own String class?

I'm trying to imagine how I would create my own string class without
using null terminated character arrays. Use std::string?

It's the Meyers' books.

Those damn apostrophes!!!!!

"Effective C++" and "More Effective C++" for the
language, and "Effective STL" for the library.

I have 1 and 2, what's "Effective STL" like?

Ian

 

[Ian T]

I don't believe you did. I'm responding to the general idea, expressed
at several points in this thread, that it would take months (or even
years) to understand this stuff.

Right. I think it takes months (or years) to write robust code and for
it to be second nature, but understanding and doing are two different
things.

Anyway, this is a java language group, so I think I'll stop now.

Ian

 

[Dimitri Maziuk]

Ian T sez:

Right. I think it takes months (or years) to write robust code and for
it to be second nature, but understanding and doing are two different
things.

The problem is the Java is a platform -- it says so right in the name.
To learn C++ one has to first learn about the basic platform under
modern stack-based languages, in particular memory management concepts
that Java platform hides from you (including the whole idea of stack
vs. heap).
Then you learn the language, including several incompatible standards.
Then you learn the details of your target OS platform.
And if you want to write protable code, you learn the details of several
other OS platforms and mutually incompatible "features" of several
popular compilers.

Pointer arithmetics is simple. It's all the other stuff you need to know
to understand pointer arithmetics that makes it hard.

Dima

 

[James Kanze]

James Kanze wrote:

It's not so much the lifetime of the object, but the ambiguity as to
where an object may end its life. For most objects, there is no
ambiguity, but occaisonally there is. In those cases, the garbage
collector acts as a safety net, but in C++ you don't get that.

Not only. Garbage collection is IMHO more than just a safety net.
There are a lot of cases where having done the design, it becomes
apparent that the exact end of lifetime isn't important. You have to do
the design, to know this, but once you know it, if you have garbage
collection, your work is done. Whereas in C++...

I mean that you may have one tiny, almost unnoticeable memory leak in an
application that runs as a 'daemon' or 'service', and the application is
expected to run continously, so 3 months down the track it can take the
whole server down when it uses up the entire heap. Not that it's ever
happened to me of course , but it's an extra level of long term risk
that the garbage collector can mitigate somewhat.

Curiously, I've had more problems with memory leaks in Java than in C++.
There's a psychological aspect at work -- in Java, you don't give it a
thought, so you slip up and forget for that JButton to deregister
somewhere. (Especially easy since the designers of Swing slipped up,
and forgot to inform the JButton that the window was being disposed.)
Whereas in C++, you know its a problem, and you make double sure that
all of your memory gets freed. Sometimes before your done with it, of
course, but that's another problem.

Just a fancy way of saying that in practice, I've seen more problems
with dangling pointers in C++ than with memory leaks. (And one of my C++
applications runs 24 hours a day, 7 days a week, with contractual
penalties over something like 5000 Euro per minute for downtime.)

[...]

Right. I use std::string, but there is still a huge codebase out there
(which someone has to support for the next 10-20 years) that uses
null-terminated character arrays, including the Win32 API.

It's true that C++ often interfaces directly to C level API's. And of
course, you have to use null terminated strings there. But that use is
generally limited to the interface level itself.

And of course
the std::string implementation uses ntcas as well.

Not at all. The exact details vary from one implementation to the next,
but the basics are often fairly similar to the implementation of
java.lang.String.

I'm not at my development computer, but just doing a search through some
of the open source C++ code I've downloaded reveals that there are still
plenty of people who have not moved entirely to std::string.

Looking at the open source code I've got on my machine... I find it
hard to find any C++ at all. All of Linux is in C, for example. As is
g++ -- it compiles C++, but was written in pure C.

And of course, in C, you don't have any real alternatives.

Think of it from a Java point of view. If the language didn't provide
java.lang.String, would you really use Char[] with a '\0' terminator?
Or would you write your own String class?

I'm trying to imagine how I would create my own string class without
using null terminated character arrays. Use std::string?

The sources of java.lang.String are available somewhere. My
pre-standard String class (dating from 1991) looked almost exactly like
it -- the main difference was that I used reference counting for garbage
collection, and I supported value semantics (but the only way to modify
a String originally was assignment -- I had a StringBuilder class which
worked a lot like StringBuffer).

Those damn apostrophes!!!!!

Actually, the error I was picking on was "book" instead of "books".

I have 1 and 2, what's "Effective STL" like?

It's probably the best practical book on the STL that I've seen. Like
the other books, it supposes some previous knowledge of the basics, then
goes on to point out all of the things you really have to pay attention
to.

Still, if I had my choice, I'd be using the OSE or my own library,
rather than the STL.

 

[Ian T]

Not only. Garbage collection is IMHO more than just a safety net.
There are a lot of cases where having done the design, it becomes
apparent that the exact end of lifetime isn't important. You have to do
the design, to know this, but once you know it, if you have garbage
collection, your work is done. Whereas in C++...
EXACTLY!


Curiously, I've had more problems with memory leaks in Java than in C++.
There's a psychological aspect at work -- in Java, you don't give it a
thought, so you slip up and forget for that JButton to deregister
somewhere. (Especially easy since the designers of Swing slipped up,
and forgot to inform the JButton that the window was being disposed.)

Interesting. I'm not far enough into Java to be using the swing
libraries as yet, but I'll keep that in mind for a future 'gotcha'.

Just a fancy way of saying that in practice, I've seen more problems
with dangling pointers in C++ than with memory leaks.

Which often cause segfaults at some later stage.

(And one of my C++
applications runs 24 hours a day, 7 days a week, with contractual
penalties over something like 5000 Euro per minute for downtime.)

Mmmmm, contractual penalties.

It's true that C++ often interfaces directly to C level API's. And of
course, you have to use null terminated strings there. But that use is
generally limited to the interface level itself.

Often you still need to know the problems with ntca's when using some of
those interfaces. Some of the more, shall we say 'baroque', win32 APIs
can get you into a lot of trouble without an understanding of char buffers.

All of Linux is in C, for example.

How do you define 'All of Linux'. Is it every application written for
Linux, or just the kernel and gnu tools?

The sources of java.lang.String are available somewhere. My
pre-standard String class (dating from 1991) looked almost exactly like
it -- the main difference was that I used reference counting for garbage
collection, and I supported value semantics (but the only way to modify
a String originally was assignment -- I had a StringBuilder class which
worked a lot like StringBuffer).

Did you implement the "+" operator with 'malloc' or 'new'?

And the Length() function, did you use strlen, or did you have some
other mechanism that kept track of the character length?

Ian

 

[Chris Smith]

Interesting. I'm not far enough into Java to be using the swing
libraries as yet, but I'll keep that in mind for a future 'gotcha'.

It definitely is a potential problem, but it's often overstated. This
comes up when you have a listener which is supposed to be shorter-lived
that the object it's listening to. If the listener is supposed to last
the entire lifetime of the object it listens to, then you don't need to
worry about it. For that reason, it's rarely a problem with listeners
on GUI components, and I question the danger of listeners on a JButton.
However, when you start working with attaching component model adapters
to application data, it DOES become a concern and deserves your full
attention.

How do you define 'All of Linux'. Is it every application written for
Linux, or just the kernel and gnu tools?

Linux is a kernel, and it is written in C. The GNU tools are not a part
of Linux, but they are still written *mostly* in C, with some extra
languages here and there. Of course, applications are written in many
languages for Linux-based operating systems (to use very precise
terminology).

The general point, though, that most open-source is in C is still true.
There's a fairly large open-source Java community, but it doesn't come
close to the amount of C code out there. C++ is almost non-existent in
open-source, in my experience, probably because once you're that close
to C, people start asking why you don't use C.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Ian T]

Linux is a kernel, and it is written in C.

And assembler.

The GNU tools are not a part
of Linux, but they are still written *mostly* in C, with some extra
languages here and there.

C++ is almost non-existent in
open-source, in my experience, probably because once you're that close
to C, people start asking why you don't use C.

Some projects (such as wxWindows) started their life as C, and evolved
into C++. And then there are the wrappers for C libraries like gtk--.

A quick look on sourceforge shows 14269 "projects" that use C++.
Filtering those further to those at Development Status: 5 -
Production/Stable leaves 2440 projects.

Removing those projects that also are done in C leaves 1801, production
level projects in C++. Which is a reasonable distance from "almost
non-existent".

Anyway, not looking for an argument, just a worthwhile discussion.

BTW, is your position at MindIQ mostly Java or C++ ?

Ian

 

[Chris Smith]

Removing those projects that also are done in C leaves 1801, production
level projects in C++. Which is a reasonable distance from "almost
non-existent".

Guess I just don't see them.

BTW, is your position at MindIQ mostly Java or C++ ?

If you're curious, we use Java almost exclusively here. If you count
JavaScript as a programming language (which I do) then there's also some
of that. There's a small bit of C (via gcc on linux) and even Visual
Basic, but it hasn't been used for ages. No C++ at all, to my
knowledge.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[jeffc]

However, the core Java statements are "borrowed" from C and C++ has often
been called "C with classes". It seems to me that it shouldn't take very
long to get up to speed on C++ if I am already fluent with Java and have at
least some knowledge of C. Then again, I understand that Java and C++ use
classes a bit differently; for instance C++ allows multiple inheritance
while Java allows only single inheritance but allows for multiple interfaces
as compensation. I'm not sure how long it would take to get fluent with
multiple inheritance after several years with Java.

I really don't think that sort of thing is going to be your major problem. It's
such an easy to understand abstract principle that you will easily be aware of
the differences when designing/coding. I think the things that will cause you
more problems are the nuts and bolts of normal programming, such as memory
management, declarations vs definitions, references vs pointers, etc. Garbage
collection is an easy concept to understand, but you can easily forget where you
need to pay attention to who owns memory in C++. C++ is also just a trickier
language syntactically. Basically, it's just plain easier to get into trouble I
think. There is also a book called Java/C++ Cross Reference or something like
that that might be of help.

 

[jeffc]

Rhino wrote:


I taught myself the fundamentals in a weekend. Weird stuff like templates
took a bit longer. Granted, I had seen C++ many years ago but didn't like
it as it didn't FORCE you to use object orientation. I wasn't surprised
when Forester Research suggested that some 85% of "C++" was actually
procedural C.

But there's nothing at all wrong with that necessarily. You say it like it's a
bad thing. The fact of the matter is that a lot of people simply don't
understand what parts of C++ (that are different from C) are OO, and which are
simply basic C++. Even if programmers wanted to write procedural code, I think
C++ would be a far better language to use.

 

[jeffc]

Well written C++ isn't necessarily difficult, but it is different from
Java. And while poorly written code is poorly written code in any
language, C++ does seem to have a particular gift for encouraging it.

Right.

 

[jeffc]

Wait till you first bump into trying to make a virtual function call
from a constructor or destructor...

That works in Java?