Slashdot Mirror
Learning C++ for Java Programmers?
The Real Joe Faith asks: "The O'Reilly book 'Java in a Nutshell' used to include a really handy introduction to Java specifically aimed at C++ programmers. It meant an experienced programmer could re-use their knowledge and get up to speed quickly. But what about going the other way? I know a fair amount of Java but, for my sins, have always avoided C++. Now I need to learn it. Fast. Not just the syntax, but also about the various standard libraries out there. Now that Java is the standard language on most computer science courses I guess there will be a few people in the same boat. Can anyone recommend a good book (or any other information source)?" For those Java programmers among us who have gone this route, what books did you use to assist you in the transition to C++? How well did these books work for you?
My advice, take it or leave it...
Switch jobs fast. You do not want to get into C++. It's a freaking mess. Remember Alan Kay, father of OO? Here's a quote:
I invented the term 'object-oriented' and I can tell you I did not have C++ in mind.
-- Alan Kay
This is probably the best tutorial I've come across for the Standard Template Library.
Good luck!
I salute your your insightful/funny/offtopic/flamebait/troll FP. Oneliner that does it all.
Bravo, Sir!
Well, I can't recommend a book, since I learned C++ first, but I have a warning...there is no definitive API. I imagine that would be a stumbling block for Java-to-C++ converts.
However, might I recommend this for the STL?
I think that in searching for a book, you should probably look for one that highlights the differences between the languages. That helped me when I was learning Java, and it's probably the quickest way you can pick it up. Have a look at Amazon and just search under books for "java c++". The first few entries are aimed at this. I can't vouch for these books, but hey, that's what I found.
I made a bundle coming out of retirement back in '99 but since then me and the Mrs. have been tooling across the US of A on Route 66 but what with the price of gas so high now and the RV only getting 3.4 miles to the gallon the pocketbook is kinda thin lateley. Plus I need my third bypass operation and one of those titanium hip joints would be just dandy! So maybe I ought to be updating my resume again, put out a shingle and see if anybody needs an old fart with skills in a dying computer language. Will program for viagra!
I like C++ a lot more for learning theory. Data structures and algorithms and what not. I'm working on a project now with Java though and I love it for actual development. Easy to read API plus everything is already done, no lower level networking or serial interfacing.
I learned C++ first and I found it easy to learn. Then I learned java, and i find it similar. The only difference that might be hard to grasp is the difference pointers and references have between the two. Just look up a website listing the differences and you'll be set for C++
heres a book that was suggested by my professor here at CMU for our intro to C class: "C for Java Programmers" by Thomasz Muldner" ISBN: 0-201-70279-7 not exactly c++ but may be you can find something like it. in anycase, should help others.
Please don't code anything in C++ after learning it "fast." It's not that kind of language.
Geez, how hard was it to type in "Java for C++ Programmers"?
. as p?isbn=0201612461&redir=1
http://www.awprofessional.com/bookstore/product
C++ is an excellent language, but it gives you enough rope to hang yourself, your immediate family, and maybe a few pets. Learn it fast, and you'll learn it wrong.
Man, you don't need to learn C++, you need to learn to be more truthful during job interviews. End of sermon.
Now about c++. Boot linux, bring up kdevelop, create a console project and start writing.
What's that? You need to program windows apps! OMG!! You are a big liar!
Seriously. Java isn't the best and most modern language in existence, but C++
is substantially worse in an assortment of ways. The *only* thing it has going
for it over Java is performance, which is mattering less and less as fewer and
fewer people are trying to function on the 486SX systems with 1MB of RAM that
were prevalent when Java got its reputation for slowness.
If you want to diversify from Java and learn more languages, that's good, but
C++ isn't a good choice anymore. People are moving *away* from C++, for good
reasons. Learn Perl or Python or Ruby or Scheme, something that actually
provides some facilities Java doesn't.
Cut that out, or I will ship you to Norilsk in a box.
What I did was simply buy and read a C++ programming book, the same way many C++ programmers learned C++. The only difference is that with my knowledge of Java, I was able to skip (or quickly review) the parts of C++ that are similar to Java (and there are quite a few). The rest I learned like any other person. Knowing Java just helps you to pick up the same stuff faster.
I started learning C++ about 7 years ago (I say started because it seems like no matter how long one has been programming C++ there are always new things to learn), and I started with Java about a year and a half ago.
One thing that seems apparent to me is that it is much more inherently difficult to go from a higher level language like Java to a lower level language like C++, because starting with Java the programmer becoms accustomed to not having to think about things which become major problems in a C++ program.
As others have mentioned, the lack of a standardiezed API for C++ beyond the STL can make things seem like a major PITA going from Java to C++, just think about what it would be like trying to go from Swing to the Microsoft API or GTK+ (though Qt is REALLY nice, if you are a java programming learning C++ and want to learn a GUI API start with this first).
Famous Last Words: "hmm...wikipedia says it's edible"
My learning went from assembly ==> C ==> C++ ==> Java, and my advice to you is to not go from Java to C++. If you remember venn diagrams, imagine one circle as Java, Then draw circle next to it without intersection and call that one C. Now draw a circle that intersects Java and C, but also has its own distinct characteristics, and that circle would be C++. There is no way to learn C++ without learning C. If I were you, I'd learn C. Then once you learn C, your OO knowledge will make you question some things. Then C++ will make sense to bridge that gap. Learning C++, or C for that matter, is not going to be fast. And anyone who does learn it fast will be in trouble unless they're really talented. One thing is for sure, once you learn C/C++ you will REALLY appreciate Java. Good Luck.
mp3's are only for those with bad memories
Just be confident knowing that most of your basic skills will transfer, and get a normal C++ book. Personally, I recommend Stroustroup's book, and Dietel and Dietel is an oft used text. Most of those "Learn C++ in 24 Hours!" types of books are a waste of trees. Like others have said, it's crucial that you get something that covers STL (both the ones I mentioned will). It's C++'s version of a class library. You'll find it a little thin after working in Java, and that's where platform specific stuff enters the picture. You'll find most of your time is learning a new widget set (presuming you need GUI programming), or socket APIs (if you need 'em), or platform specific threading/synchronization etc.
Overall, coming from Java, you won't expect or know how to use fancy language features. That's Ok. Write C++ like you would Java (mmm, careful about that memory leak though). This assumes you're doing app development where you can afford to make every function virtual, every object a reference, and have accessor functions for every member variable. If that's not what you're up to and you need write tight C++, well, forget Java while you learn C++. Make sure you get your memory models straight--stack vs heap, by value and by reference, pointers vs reference, iterators vs pointers, reference counted, and on and on. You have to get the now classic "Effective C++" books by Scott Meyers. That's the best way to avoid classic stupid C++ mistakes. You'll find it a bit heavy going at first, but until it makes sense to you, you're probably writing bad C++. Good luck.
Also check out www.cppreference.com. I have found it to be significantly more useful than the STL reference at SGI.
To paraprhase Mark Twain, the rumors of the performance of C++ have been greatly exagerated. The advantage you get from cross platform compatibility and a fantastic API far outweigh a minor performance hit.
My favorite book is Accelerated C++ by Koenig n Moo. It's C++ taught as a language w/ a library. It's not taught as C w/ classes tacked on as an afterthought. Check it out.
You will spend the rest of your life learning C++, anyone who says they "know" the language is either lying or deluding yourself. After you're done w/ Accelerated C++, pick up Modern C++ Design by Alexandrescu. Also get a subscription to C/C++ Users Journal.
[o]_O
i agree with you. really, i do. the job market can be less forgiving than that though. plus there's a whole 10 and more years worth of perfectly working c++ code that has to be maintained and companies can't just afford to throw it away.
now if you're in the position of starting a project/company yourself, obviously avoiding c++ is a good thing from the start.
- tristan
After ten years of C++ programming, I'm underwhelmed with C++. It's broken, and Strostrup is in denial about its flaws. If C++ wasn't broken, we wouldn't have needed Java or C# or Objective-C, which, after all, look a lot like C++.
The basic problem with C++ is that, alone amongst major programming languages, it has hiding without safety, which is a terrible combination. C has neither hiding nor safety. Java, Perl, Python, Ada, and LISP have hiding with safety. This has nothing to do with efficiency. There are some basic bad design decisions in C++. Some of them come from C, and some of them come from early C++. The end result is a mess.
The best the C++ community has been able to do is to impose religious dogma, in the form of "patterns", on C++ usage. This sort of works, but not very well. Witness Microsoft's endless buffer overflow problems. Switching to C++ has not helped at all.
It's not getting any better, either. The C++ language development community is dominated by people who like to do really l33t things with templates.
I wish there were something decent and mainstream to program in. (And don't go on about Eiffel or Sather or Z or Haskell; those are going nowhere.)
by Timothy Budd, may be what you're looking for. My uni taught intro cs in Java but in our OO development class, C++ was the language of choice. They threw this book our way to ease the transition. It didn't hurt, although Stroustrup's book, Meyers' Effective C++ and STL, and Lippman and Lajoie's C++ Primer are more useful in the long run. Also pick up a nice STL reference like Josuttis.
The OP is quite right - I'm in exactly the same boat and no, I don't need to learn C++ because I lied in an interview, or need to develop some software quickly, but rather because I am interviewing for an academic course that teaches C++ and one of the requirements is that you be able to learn C++ quickly, so the "pre-test" as it were is for me to try and learn it in the week I had between being notified I needed to learn it, and the interview itself. Meh. They suggest Deitel & Deitel; it's looking good for me so far. "C++ for Java Programmers" looks okayish, but not as thorough; I'm going for the learning-as-if-a-newbie approach and mapping concepts on to what I already know (thank gods for all those compiler theory lectures eh?).
Use one of the first two books for syntax, and use the rest to further your knowledge quickly.
For syntax:
C++ in a Nutshell
by Ray Lischner
OR
Sams Teach Yourself C++ in 10 Minutes
by Jesse Liberty, Mark Cashman
For examples:
The C/C++ Users Journal (from the publishers of Dr. Dobbs)
http://www.cuj.com/
Effective C++ Cd: 85 Specific Ways to Improve Your Programs and Designs
By Scott Meyers
Frankly, there are a ton of similar books out there...
At some undisclosed site (Amazon.com) their data miners|web agent|sentient AI suggests:
C++ Gotchas: Avoiding Common Problems in Coding and Design
by Stephen C. Dewhurst
Other advice:
Try to find some good sample code. Take a cleanly written open-source utility or something from MSDN and try to extend a feature in the software. That's how I learn.
(yes, haha, I send cleanly written and OSS|MSDN in the same sentence...)
What do you mean my sig is repetitive? What do you mean my sig is repetitive? What do you mean....
I was in the same boat a year ago. I think (good) Java developers needs are unique when approaching C++ because we already know about 80% of the syntax and concepts, but we need a quick way to get into the STL, tips on how NOT to hang yourself (far too easy in C++), and some sense of how C++ programmers organize code.
For getting into the STL, I chose Accelerated C++ by Koenig and Moo. It is very basic at the beginning. However, it's not a 700-page behemoth (a Good Thing), it approaches C++ as OOP from the outset, and it starts using the STL from chapter 1. I'm sure you'll need a full STL reference after this book, but it serves as a decent starter. (I also have "The C++ Programming language" by Stroustrup and it's a bit too close to a language definition... good reference, bad primer)
For the tips, Scott Myers books can't be beat. Enough people have heaped praise on them that I won't bother with it here.
That leaves the last part of my education: "how do C++ programmers organize code". Unfortunately, the C++ world doesn't seem nearly as unified as the Java world. I started out doing things very Java-like, but decided that probably wasn't going to work if I eventually start coding with other people. Accelerated C++ has some tips. The C++ Programming Language also has a lengthy discussion on how to organize your code. Being the completely anal guy I am, I wanted to get it right the first time. Unfortunately, that's not possible. My style is still changing frequently as I see elements I like. I'm sure it will calm down if I ever get a job in a C++ shop.
I am sorry, I am a bit confused by your argument. Move away from C++ to what exactly. The only other languages you mentioned where Perl, Python, Ruby, or Scheme. I have yet to use Ruby or Scheme, but I did look up some things on them.
Most of those languages are scripting lanugages and aren't really what you'd program a major application in. I know I user perl for sys admin tasks and quick hacks to just 'get things done'
If you're going to beat up on C++ tell them to move away give a decent language to move to. And you never explained what Java had that C++ doesn't.
Please tell me why I want to move away from a language such a C++ or even its predecessor C. Those languages are solid, and fast. You can do most anything with them. And the cleanliness of the program is left to the programmer, so if you develope bad practices you'll write bad code. If done propertly I see nothing wrong with using C++.
Here's (on the top of head) what comes to mind when I think ab out moving from Java to C++:
In C++ you can place objects on the stack with no need to allocate an object on the heap.
The book my Koeing and Barbara Moo, Accelerated C++, is an excellent starting point in my oppinion. If you have previous programming experience, i suggest you pick this up, rather than a 500 page primer. It goes through a lot of stuff and a suprising rate. It also teaches you some basic algo's and uses STL right from the start, not the sort of backward teaching some other books use. It's very good, and i suggest you pick it up. You might also try Bruce Ekels Thinking In C++, they can be found for free (both volumes) on his site. Simply google the title and it will take you there.
After learning c++, I would recommend learning c#. I t has many of the nice features of Java, like complete OO, strong typing, automatic polymorphism, etc,, and many of the powerful features of c++ like operator overloading and the use of pointers in unsafe code blocks (only used when speed is very important).
You can't go wrong with Eckel's Thinking In C++. You can download it for free. Or buy it. It seems to have been designed for C programmers moving to C++, but for free it makes a great reference (picked up a hardcopy of an old edition on half.com for $3, just because I like hardcopies, although I keep the current softcopy nearby).
(disclaimer: one of my livejournal interests is "informed dislike of c++". ;))
Bruce Eckel has written some fairly good (IMHO) books on c++ and Java. You can download them for free from here. The thing I like best about his approach is that it tries to teach you more than just the syntax, also (as the titles suggest) how to think in that language. The only con to his writting style is that his examples are sometimes a little contrived...
As other posters have said, do try to learn the STL as soon as possible. It makes C++ far less painful and more like Java. Of course, you could be stuck in a situation where your compiler is really old (bad templates support) and/or the environment doesn't have the STL, so as nice as std::vector is, you should probably learn how to use arrays too. ;) One of the
biggest flaws in C++ to me is that it is almost
like three languages in one, any one of which
can be used to build a solution, but the best
way isn't always obvious. [Well, and manual
garbage collection sucks!]
Good luck!
News for Geeks in Austin, TX
I can' believe nobody has mentioned this book yet! It gives you a great insight into the language and why it works like it does.
You can download it from http://bruceeckel.com/. If you want you can try Thinking in Java first, as you already know the language, it will give you an insight of the kind of book they are.
Exactly my point ! The point is most propellerheads today have this Jihadish leaning towards Java. What ? You expect the framework to save your a$$e$ or something ? Good , if that were the case, then you could compile a java jvm with itself and call it well and good. Do most of you even realize that most JVM's are written a language that starts with the third letter of the English language ?
Get in touch with reality, just because you CAN do something, doesn't mean you should, or weren't the rest of your liberals listening to yourselves when you squawked that Bush shouldn't go into Iraq for this or that reason....same THING with Java. Just because SWING/SWT exist, doesn't mean they're anywhere near where other visual frameworks are in terms of richness. Exactly where do you think the concepts for templates and generic programming came from ? Cobol ? Fortran ? Smalltalk ?
Please....if you're going to berate C++, then stop use KDE, GNOME, or just about any replacement desktop ( for linux or otherwise ). Write yourself a replacement shell in Java....let's see how far we get with that. ( curious reminder of where earlier projects to produce a Java Client PC system are today ).
> Move away from C++ to what exactly.
To VHLLs, of course. I thought I was clear on that point.
> The only other languages you mentioned where[sic] Perl, Python, Ruby, or
> Scheme. I have yet to use Ruby or Scheme, but I did look up some things
> on them.
Try learning one of them.
> Most of those languages are scripting lanugages and aren't really what
> you'd program a major application in. I know I user perl for sys admin
> tasks and quick hacks to just 'get things done'
A good language is flexible enough to be used for "quick hacks" as you
put it or for full-blown applications. In fact, often a quick hack to
get something done ends up turning *into* a full-scale application over
the long haul. All four of the languages I listed are rapidly gaining
recognition as excellent choices for large-scale application development,
due largely to the excellent ratio of results to programmer time. (C and
C++ get a slighly better ratio of results to CPU time, but CPU time is
cheaper than programmer time and these days is almost never the bottleneck
for most categories of applications.)
> Those languages are solid, and fast. You can do most anything with them.
Congratulations, you've discovered Turing equivalence. Of course you *can*
do almost anything with them. The more useful questions are, how long does
it take you to write and debug the code, and how easy is it for someone else
to read and understand it? On the first question, C and C++ get abysmal
scores compared to e.g. Perl; the second question, as you point out, relates
a lot more to programming style and is largely independent of language. A
good programmer can write good code in pretty much any language he has taken
the trouble to learn, with certain obvious exceptions which deliberately defy
good programming practice. (For example, befunge is deliberately designed so
that data and code are not separate; this violates one of the basic principles
of maintainable code, so it's very hard to write good code in that language.
Similarly, unlambda is designed so that even simple problems cannot be solved
in conventional ways, but only by mind-bending paradigm gymnastics. SPL is
designed to be so absurdly verbose that no problem of any significant scope
can be solved in a section of short enough to read in one sitting. Nobody
writes good code in these languages, but it doesn't matter; that wasn't
their purpose.)
Cut that out, or I will ship you to Norilsk in a box.
You seem to be noting exceptions to practical programming languages. It's like using BrainFuck to do everything you need. It is indeed a turning complete language, but you wouldn't use it unless you just wanted to have some fun.
In reponse to writing code, and debugging it. Well if written well and I try to keep good practices, I usually don't have a problem debugging C. As programs get larger eventually CPU consumption becomes a problem. And using Perl or another scripting language just looses practicality. And C / C++ offers better memory managment that other languages just don't have.
In either case , you have to make sacrificies. CPU consumption time versus program needs.
I guess we can agree to disagree on the proper use of languages. I just can't see myself ever using perl for a industry application. I love perl just because of the flow and ease of use. It's powerful and flexible, but somethings must be written in other languages. I wouldn't write an OpenGL game in Java though it can be done, it'd be slow. I stick to what I know is fast C / C++.
As far as readablity it all depends on the progamer. I can write clean perl and clean C. Both easy on the eyes. Yet I find the flexiabilty of perl to have its down fall. You can quickly write 'ugly' perl because of its flexability. C forces a bit more stricter syntax than perl , but then again its still quite easy for me to write 'ugly' C.
When it boils down to it, all is left in the hands of the programmer, how clean or dirty he keeps his/her hands is up to him/her.
.. and I second the recommendation for Timothy Budd's "C++ for Java Programmers" (ISBN 0201612462) ... great book!
Also, this tutorial is full of useful information. However, you have to ignore the occasional bitter remarks about Java from the author, such as these gems:
Unlike Java, C++ is a fast, powerful, and flexible programming language.
Java was built as a simple-to-learn subset of C++ for set-top boxes and drooling AOL users. Now, it's time to play in the big leagues.
For me, Essential C++ was a good jumpstart book, and then
The C++ Programming Language is of course the gold standard if you need to go deeper.
I have also heard good things about Accelerated C++, but haven't looked at it myself.
Blessed are the pessimists, for they have made backups.
ML, OCaml, Haskell, Lisp etc, are all compiled languages, with runtime speeds comparable to compiled C/C++.
C/C++ memory management is unnecessarily low level. How exactly is it superior to that found in a modern garbage collected language? As an application programmer, why should I have to keep track of every bit of memory when I dont have to? Why would I even want to.
Not really. The above compiled languages are comparable to C++ for resultant executable speed. You dont need to make as much of a sacrifice as you seem to think.
Without even investigating the alternatives? There was a time when people knew the earth was flat. Just because you think your C/C++ code is fast does not mean it is. And don't forget development speed.
There are some tasks which C/C++ is suited. For most development tasks, there are better alternatives IMHO.
You may be able to keep you hands clean, but what about the other guys on the project? If you were using a language with a more uniform syntax, safer semantics or even just fewer special cases to be learnt, then it would be easier for everyone to keep their hands clean.
If strictness of the language is a major concern for you, then you would be using a language which has much stricter semantics than C/C++.
Just my 2c
My uni basically only taught Java as a programming language, which proved (not very) useful for my first real development job in c++.
Things I wished I'd realised sooner:
1) Learn how to use (or write, if you're brave) STL iterators with containers.
2) Learn the difference between the stack and the heap.
3) Use memory leak checkers (eg. valgrind), as you WILL get memory management incorrect.
4) Realise that destructors in c++ are actually useful, in that you know (more or less) when they'll be run.
I've read some code written by people claiming to know c++ with a java background. Every single object was created with the new object, including those used only in the current scope. yeeech.
Where to start...you poor misguided anonymous coward. I know...almost at the beginning.
"ML, OCaml, Haskell, Lisp etc, are all compiled languages, with runtime speeds comparable to compiled C/C++."
If you read from the introduction to Haskell itself, even THERE it clearly states that in cases where "In applications where performance is required at any cost" ( direct quote ) C( and by inference C++ ) is the better choice, and since I've yet to see a Lisp compiler generate code anywhere NEAR what a C/C++ parser itself can generate, I'd say that applies there as well.
I will, however, concede that with things like GreenCard, it may be possible to create a mixed language system that could both provide some HLL "ease" of use along with little or no compromises in speed.
If you can write perl code, and the other guys on your team can't, respectfully suggest to them that they wash their hands before they code.
Wouldn't you be better off choosing a language which is more expressive, flexible, and lets you produce a solution sooner? You can always change algorithms, or call out to lower level code if you need better performance.
These benchmarks compare many languages. OCaml and Lisp do quite nicely vs C/C++.
It comes down to using the best tool for the job. It's just unfortunate that most people only have one or two tools in their toolbox, and force problems/solutions to fit the tool.
As for your last point, I'd prefer not to write Perl code
As is the case with most college students I come across as interns.
Whomever in the python newsgroup got the impression that C++ was premature optimization obviously show little mature of character, much less of programming, or application much less algorithmic design. It's not meant as a personal affront to them, but in general. In college you have it droned into you that things be generalized as this, or that, when in reality, you'll hardly ever truly run across generalizations when developing solutions for business or practical matter. Generalizations are the strata that academia wrap themselves in so that they can have some semblance of mysticism without ever having to deal with "specifics". I loved the statement, "the solution is trivial at this point". Ever ask an anesthesiologist if the solution to how much anesthesia he applies is ever trivial ? Doubtful.
Why ? Because specificity IS the solution. All these modern pseudo-code script languages allow you to speak in generality to the solution of a problem, and use the argument that we can "throw more CPU or memory at it"...it is after all "cheaper" these days. I've not seen ONE client who's casually ( much less that dismissively ) agree that "Sure, we can buy another rack of servers each with a couple of gigs of ram, and a few 250Gb hard drives...why not, it's "cheaper" these days. Yeah, right !
Just to make the programmers life easier and let him design a program in one of those languages that doesn't require much specificity. Of course it says NO SMALL THING, that all the companies listed on the Haskell main site are companies with the revenue to push something like Haskell. But in MOST cases, that is not the case. And it will continue to not be the case, as long as there are bean counters watching IT budgets. And if anything in life is as sure as death and taxes, it'll be that accountants and comptrollers will ALWAYS have the last laugh.
Doubt me ? You don't have to look far into the past for proof, just look at DOT bust. So when in doubt, don't generalize, much less program in it.
As for perl, programming in perl is like going for a root canal in the days before NOX. You know it's going to be painful.
Wow. Brainfuck looks almost as scary as Whitespace. And I used to think APL was hard to follow.
Writing Perl is easy. Reading Perl, that's hard. (/Scotty)
You are talking as if C/C++ are the last word in programming langauges. Why not use assembly if performance is so important? You do know that Lisp is older than all languages in use, other than Fortran? And that OCaml often out performs C++? Its also generaly acknowledged that programmer time is more expensive than server time. Save yourself some of the team's time. You could the buy the equipment with some of the savings, and pocket the rest. I'm sure clients would hate that.
If you have factor in the robustness, flexibility and maintainability of the resultant system, the client may prefer to buy the extra rack of equipment, than be delivered a faster (perhaps), rigid, inflexible and brittle solution, late in C/C++. You also need to factor in maintenance costs.
I didn't think accountants had a sense of humour. I agree entirely.