I confess. I'm an absolute beginner at programming. The last time I wrote code was in the early 1980s on a Trash80 using BASIC.

I want - no, NEED - to learn C++ if I am ever going to get the job I want.

I've heard buzzwords like 'toolchain', 'compiler', 'linker', 'assembler', 'debugger' and 'object oriented programming' but they're like a foreign language to me. I have no clue as to what they mean, which ones are necessary, and why they're necessary.

Can anyone recommend an absolute beginner's book on C++? Ideally, one that starts with explanations of the above terms (and any others) and why they're important and then goes on to teach C++. No book is too basic for me. I'm willing to plumb the deepest depths of 'programming basics'. I'm desperate and don't know where to start. I bought a copy of C++ for dummies and it seems okay from the C++ side but it doesn't go into the above stuff about toolchains, etc.

Any help you can give is appreciated.

Kind regards

A "toolchain" refers to a set of tools available to the user - in this case, your toolchain (aside from a text editor or IDE) would be the compiler, linker, assembler and debugger.

I wish I could provide some examples along with an explanation of what "object oriented programming" is, but given your knowledge of 1980s-era BASIC, I am afraid it would just be wind to your ears.

A compiler takes the human-readable source code and translates it to lower-level code - sometimes byte-code, and sometimes "native" code (code that is completely in operating-system-specific binary). A compiler like GCC also calls on a "linker" - which I don't know too much about, but pretend it's like a "code finalizer".

Without further going on into topics for which I have little knowledge, and thus sounding like a complete, blithering idiot, I suggest you look at Wikipedia for definitions of "assembler", "linker" and "compiler".

A debugger lets you run a program step-by-step so you can see what exactly your code is doing - but this is usually in a lower-level language than C++ (usually assembly).

I do not program in C++ (as I have never had a need to), but the only book I have on the subject is "C++ for Dummies"; it does not explain pointers well, though. With "C++ for Dummies," I highly suggest picking up "The C Programming Language" (for its sane explanation of pointers) and, perhaps, the book by the creator of C++, Bjarne Stroustrup, "The C++ Programming Language".

It's arguable, but maybe you first need "C".

If you dealt only with BASIC, most likely you haven't dealt with serious programming concepts/issues.

So, look up names/books by Knuth, Wirth, Dijkstra.

Start reading about data structures, remembering that Wirth wrote a book called

Algorithms + Data Structures = Programs.

IMO it's kind of even the other way round:

Data Structures + Algorithms = Programs

, i.e. there is no sense thinking about an algorithm unless it is clear on what data structures is is going to work.


My point is that knowing just a programming language alone does not save you from creating really bad programs, even if they appear to work.

By the way, try to rely as little as possible on debuggers - heavy reliance on debuggers makes bad programmers IMO. The same is even more true WRT IDEs. The latter is like driving a fancy car - sooner or later it breaks and you have no clue what to do next.

And in the areas where C/C++ usage in mandatory/critical (say, real time) debuggers (at least, pure SW ones) are practically useless.

You will have to understand what linking and libraries are.

Hi, Shagbag -

I totally agree. Based on the "buzzwords" you mentioned (at least all of 'em once you got to "object oriented"), I would say they cry out "C".

Some people might say "C and C++ are pretty much the same thing". They're wrong. Using C effectively is a very, very different thing from using C++ effectively.

Let me go even further out on a limb and say that I think C++ is a very poor language for learning OO concepts. It's just too complicated, it's too easy to do the "wrong thing", and it's simply far too much effort to learn "object oriented concepts *AND* to learn the C++ language both at the same time. I honestly believe C++ is a *TERRIBLE* "first language" for a beginner.

IMO, you'd be much better served playing with Java (or Python or C#) for "object oriented", and becoming proficient with C (and assembler!) for your systems programming stuff (where the "toolchains" tend to come in).

Also IMO, Kernighan and Ritchie's class "The C Programming Language" is the single best book you can possibly get for learning - and using - C.

'Hope that helps .. PSM

Well, "C" is bad too (and I use it widely and hopefully wisely), but C++ is worse - I agree with paulsm4.

Furthermore, "C" is, strictly saying, two languages - "C" itself and its preprocessor.

C++ for that matter is three languages - the two of the "C" (plus C++ - specific OO things) plus the template language. This latter one is a functional language opposed to imperative one which "C" is.

Functional language is not bad, and often are rather good, but it just adds to C++ messiness and functional languages are quite a different mindset.

I would agree, c is a better language for beginers. Javascript is a really easy way to get into programing. Browsers have evolved to implement javascript in a messy, hodge-podge way, but it will give you a good feeling of the basics. From there I would move to c. I recommend staying away from object-oriented javascript if you want to learn c++.

If you want to go from the ground up I would recommend "Structured Computer Organization". My edition (admittedly a bit old) doesn't really go into "higher" languages like c or c++, but gives a good understanding how computers really work, which is really essential for learning how to program effectively. I know my programing has definitely improved from reading that book.

I don't think that you want, or, to be more exact, will be best served, by a beginner's book on C++. Well, you've actually got one, and while you can argue about its 'advanced content' (by which I mean, whether its advanced enough to be of any real utility), it is probably as good as most and better than some at taking a complete neophyte to a position that they know something about c++.

My arguments are:

• you need to know something about the generality of computer programming first, before that information on a specific programming language
• I'm not awfully convinced by c++ as a beginner's programming language; it can be done, of course, but it may be neither efficient nor easy

And you haven't really said enough about your final objective; it may be that c++ isn't a good final goal for that, either.

start somewhere like here http://ocw.mit.edu/OcwWeb/Electrical...ence/index.htm
and look at the Intro to Computer Science and Programming (I haven't gone through that in detail myself, but its the kind of thing that you need and nothing done by MIT is bad...) and maybe have a look at other stuff it catches your eye.

Then I'd go for a simple, quick, course on Python and maybe a separate one on Algorithms. Python is a lot easier than c++ -the nursery slopes, if you like- which should help while you are still thinking about structure. then I would say, you should be in a position to start learning something like c or c++.

Some people would prefer to learn machine code/assembler first, then c, then c++ and while that can certainly work (& work well eventually, I don't have questions about that), I don't think it does the 'student' and favours.

It is arguable that Beginner's All-purpose Symbolic Instruction Code not only simplifies, but for many students does as much harm as good. Not really in touch with the modern world.

Object Oriented Programming can be regarded as anathema in some contexts and vital in others (and maybe is neither), so without context a useful comment is hard.

Compiler, linker assembler and debugger are all tools (and therefore may constitute or be part of, a toolchain). The toolchain that you have (and must learn to use effectively) varies from language to language, so discussing this in an abstract way is hard. However, you have to get from something that you write to something that can be executed, and tools are fundamental to that process.

There are books that I could recommend, but I suspect that my taste in books might be a little too academic for where you are now.

Thanks for the responses. I hear what you're saying about learning Python or C before moving to C++, but I don't have the luxury of time. I want to get a job as a Quantitative Analyst with one of the banks here in London and they all stipulate some knowledge of C++ as a prerequisite. I've got the maths skills but not the coding skills. At this stage I just want to learn enough to get me the job, by that I feel I need to know enough to code a pricing model ie. no graphics, GUIs, etc. - just command line 'cout' stuff should be okay (touch wood).

I've gone ahead and ordered Bjarne Stroustrup's book "Programming -- Principles and Practice Using C++" from Waterstones here in the UK. I'm hoping that will help me out. To be clearer: I don't think I'm ever going to be a C++ wizard, but I need to learn enough so that I can manipulate large amounts of data mathematically.

Oooh - as long as you are doing number crunching, you should be fine! C++'s "object-oriented" style is easy to pick up (as long as you don't delve in too deep - too early on - into things like polymorphism.

It's a shame that more places do not use Lisp for this sort of thing (crunching numbers); I wrote a couple of programs for a few of the physicists here at work, for the purpose of number crunching (text-only optical systems layouts) and they love it.

Shagbag, I wish you the best of luck and I hope you get the job!

Well, I do not exactly know what data you are talking about, but my gut tells me R language

http://www.r-project.org/
http://en.wikipedia.org/wiki/R_(programming_language)

may be much more suitable.

Unless you are talking about data in real time (trading system, for example). But for trading system you do need to be a C++ wizard.

For data analysis, on the other hand, not at all.