Self teaching myself C++
Ive been trying to learn C++ for a couple of weeks now. Ive got 2 days a week free to study and 4 hours each day allocated.
The problem is ive been trying to organise everything into modules. This is proving difficult because im obviously new to the language so im not sure what to put into these modules and in what order to study them.
I would like to know if anyone has self taught themselves and what worked and didn't work. Or which way they found easist to learn such a large language.
EDIT: I have no shortage of books to learn from so i dont need book recomandations as ive posted about that before.
if you want to be a painter, paint.
if you want to be a writer, write.
if you want to be a coder, code! you will learn 1000% more by sitting down and attempting to write some programs than you ever will from reading about it.
If you have books to learn from, try working through the problems in the books. Post your solution here and we'll critique it for you.
I taught myself C++. I didn't actually use any books, instead I used tutorials from the internet (I found the CProgramming.com tutorials extremely helpfull) and went through examples, changing parts of them to see what happened.
Obviously this is just how I learnt and i'm not saying you should also learn like this. However, I would like to suggest that instead of sitting down and learning the language; you take ChoasEngine's advice and learn by doing, using the written stuff purely as reference.
I'm in the process of teaching myself C++ as well. I have a nice Deitel book that's perfect for self teaching. I'm still in the early stages, but what has helped me is to copy down example code and study and modify it. I always try the questions in the book, and post any questions here. This forum has really helped me, I must say.
I agree with what ChaosEngine said, however, i would say get a good book to Start with, such as Teach Yourself C++ in 21 Days (what i used), i've heard nothing but good things about C++ Primer. Use these books to get to know the basics, then go onto online tutorials, and as was said, most importantly, just coding and trying new things. This forum is honest-to-god the greatest resource you'll Ever find.
I learned C++ after years of being a C programmer, back in the late 80's when C++ was new. Since my school days were long over, I suppose I could say I was self taught, but since I was also had formally studied computer science, I wasn't really a beginner.
The viewpoint I had was unfortunate, and paradoxically the precise target of the language's design. C++ was envisioned as a way to invite C programmers into object oriented design and programming. That made me one of it's prime targets.
Unfortunately, it also meant that I had to unlearn as much as I needed to learn. The C style of doing things is actually counterproductive to some degree, and learning to take advantage of the leverage objects provide is a readjustment in thinking that new students don't have to undergo.
Familiarity with another OOP language is helpful, but not required. Stroustrup suggested in his book "The Design and Evolution of C++" that the learning curve for C++ was about 18 months (as of C++ 2.0, I think). It can take longer for some of the concepts to really gel, though.
I recall that it was about 5 years before I was really as 'solid' as I've been for the past decade or so.
Once you're familiar with the syntax and the features of objects, virtual functions, the STL (or something at least similar), you're finally able to think in objects instead of functions. This, to me, is key.
High minded notions like polymorphism and encapsulation, while important, don't really mean as much to the student as to the professional. While they are part of the definition of OOP, what that looks like and how one thinks about design and development is what really matters. Debates are all over boards like this on the notion of implementing objects in C vs C++, and many debate the advantages of language features in Java, C#. Still, the underlying process of thought is what's consistent, given leverage by features of a particular language.
In my view, the advantage in objects is how they simulate real work components of a machine. Without objects, software is written as a set of functions, and that is the focus of thought. Objects can be metaphors for concepts that are a implemented as a group or family of functions, combined with data common to the logical representation of metaphor (the simulation or implementation of something).
For the C programmer this can seem to be more of a burden at first, which is one reason many C programmers rejected the notion (even to this day).
For those that stuck through that phase (which can take a while), benefits are considerable. At some point, if you looked back at earlier work, you'll think of it as a jumble of unrelated functions without backbone.
Objects create a sense of structure and organization. At some point you'll develop a sense of where things should go based on what you're making. My own mental picture is based on the notion that I'm making a machine out of logic. Each object is a part (and sometimes arrays of parts, strings of parts, trees of parts) that fit together.
The object is like an electronic component, with defined input jacks, output displays, output wires and control knobs. Connected to other objects of various purposes, an application is then constructed as if option cards plugged into a motherboard - where I have the freedom to design and build them all.
One bargain that comes from this is the fact that whenever I design a solution, I make the object as generic as possible so that solution is applicable to other applications. I've read many who claimed this turned out to be a failure of C++, as though the concept just doesn't work.
In the 15 years I've written applications with C++, I've witnessed this claim to be true, however. The key there is to learn how problems are solved generically. MFC, WTL, wxWidgets, QT are all GUI application frameworks. They are an exact representation of the kind of C++ library I'm describing, and certainly they do work.
Those solutions have already been found, however, and so as a C++ engineer I elect to use one or more of them, rather than make my own. In the early days of templates, however, there wasn't so much choice for containers.
Today, the STL is considered the standard container for C++ development. When templates were first introduced, there was no STL, and the first thing most of us did was to make our own. That's precisely one of the things templates were made to do. As such, I had my own solutions for vectors, linked lists, sorted trees and smart pointers long before the STL and boost libraries were released, and I used them in dozens of applications (more like hundreds). I rely on many of them to this day, because no other framework has provided satisfactory solutions to some of the problems I solved for myself years ago.
Threading is one example. Even now, threaded development seems to pose challenges for programmers. Back when '95 and Windows NT 4 were new (even when OS/2 mattered), the puzzles of threaded development came to my desk. My first solutions were specific to one application. Creating a thread, giving it some work to do, closing it down.
By the time I write my third application that needed threads, it was obvious I was repeating myself. Each time I solved the issues, slightly new notions came to mind. This is exactly what those who claim 'code re-use doesn't work' identify. Try as they might, it seems they had to modify their objects for each application - to them, code re-use was a farce.
What turns out to be key, however, is to clearly identify what is generic about the problem, and what isn't. One might even have to structure the solution and even the definition of the problem in order to factor out common, generic points in design.
By that third application, I realized I needed a thread object. The mere act of creating one, one the stack or as a member of another object, meant a thread was launched - waiting.
Then I cobbled together a template class that represents a pointer to a member function, along with permutations of parameters required by that function. Giving the thread object a queue, I was able to toss of functions into threads on a whim. From that day until now, threads are as simple as:
I've not checked that code snippet through a compiler, but the basic notion is complete. that's all I need do to get SomeFunc to run in a thread. It works for Linux, Windows and MAC.
que.Call( &AnObject::SomeFunc );
When I developed new applications, there would arise situations unique compared to this humble beginning. I would take a moment to analyze what was generic (fundamental) about the uniqueness of the requirement, and extended the QueProcessor to support that, or, if required (which it was) develop derivatives or partners in the family of QueProcessor to deal with new circumstances.
For example - many times one threads an algorithm by simple partitioning of the job. An AlphaBlend is a candidate. The operations on an AlphaBlend can be divided equally among the cores on a machine, each one being given that portion. The trick is, however, to write that so it can respond to load at any moment, and to present the application code the same 'view' it gets on a single processor. That is, a single function that blocks until the job is done.
As such, there must be checks on 'available' processors, and, when the job is completed, the 'executive' that schedules the other cores must wait until all threads are done before returning to the caller.
At first it seemed like code to make in the application, each time this came up. However, with a couple of objects, I was able to fashion a generic solution to this scheduling problem, and now it's usually trivial to implement.
This means that, over time, one's library grows to encompass an increasing coverage of the fundamental problems, such that the library eventually stabilizes, and is perpetually useful.
Thinking in terms of making a machine out of logic, made of components that function independently but connect and work together as a whole, and to write generic solutions that can be re-used - these are key skills and methods in my thinking.
How about tring out my blog
I am frequently adding new articles to the blog(nearly everyday) so you might find some good articles here(well i hope so.)
Most of the articles are related to C++ progtramming.
I hope the moderators don't take this as a spam.
The best way to learn is to experiment. Write a lot of code and read a lot of code that others write. Pick up the best and improve. Concentrate on technique.
>> How about tring out my blog
I didn't read all your entries, but your example code is old-style and non-standard C++. I'm also not particularly fond of teaching that swapping trick, since it is relatively useless even when it does work. Feel free to continue learning and improving your blog, but I'd recommend somebody learning C++ to use a book or a more modern and established tutorial.
I taught myself C++ also, I learned everything I know from books. I say read to your heart's content, there is no way I would be as updated in the language as I am now without books. If you read these posts, it's well worth while to read books. I am still reading books on different aspects such as OpenGL and Direct X, etc.. A good book can teach you much more than you could find without heavy searching across the internet and multiple spans. Also being new to the language you will lose interest quickly just by experimenting if you don't learn much from other sources. You really can't do much in the beginning, especially without the STL Library or Boost, and there are many many books covering these topics.
If you look through the books you already have you should be able to find the solution your looking for, it mostly goes by the programmer, however it's fine to take on whatever the author of the book has done.