C++ - Starting from Scratch

[Hooker]

I'm looking into C++, I haven't done ANY before.

Can any one recommend sites/ebooks/books/tutorials that can help me get into it quick?

Cheers peeps.

[Azuth]

The C++ Programming Language. By Stroustrup the guy who created the language.

[king_dick]

I started off with dietel & dietel, which was passable.
If you've got bit of programming experience, I'd recommend Stroustrup, altho it is a bit more of a reference book than a learning book (imo).

My advice would depend on how much experience you have with other languages, I guess.

[smudge]

Stroustrop wrote another book (cant remember the name) which explained the reason behind why things were like what they were. I reckon I learnt more from that than the reference.

[yem]

Accelerated C++ isn't too bad IMO.

[pkp|ex]

C++ in plain english + google + google + google + google + /usr/src + google

If you get a book (a real one) which explains the basic guts, go thru and get the basics right, then you can fruit about and make your own programs go and then away you go

IMO try to stick to procedrual C/C++ ( eg, basic normal old functions and structures ) and try to stay away from going with all the super tangy OO flavours ( eg, cin/cout, operator overloading, inheritance, and all that weirdo polymophisim shit and such like).

Going all out Mr.OO in C++ is all good in very good in theory but when its real world stuff, it can become a real pain in the arse.

[smudge]

Originally posted by pkp|ex
IMO try to stick to procedrual C/C++ ( eg, basic normal old functions and structures ) and try to stay away from going with all the super tangy OO flavours ( eg, cin/cout, operator overloading, inheritance, and all that weirdo polymophisim shit and such like).

Going all out Mr.OO in C++ is all good in very good in theory but when its real world stuff, it can become a real pain in the arse.

Why deliberately limit your chances of getting employment (if thats your intention for learning it). If youre not familiar with OO, the STL, and a shitload of other OO stuff you wont be able to get a job in c++ nowdays ime.

pk, if you get far enough into OO, it becomes pretty hard to not realize that objects and proceedures are actually the same thing, object hierarchies with virtual functions and switch statements are the same thing. They're just syntatically nicer ways of doing what good programmers do in C by hand to avoid writing spaghetti. You wont ever make the mental break thrus in understanding how to structure code in an OO way unless you force yourself to use it dude.

[king_dick]

Originally posted by pkp|ex

IMO try to stick to procedrual C/C++ ( eg, basic normal old functions and structures ) and try to stay away from going with all the super tangy OO flavours ( eg, cin/cout, operator overloading, inheritance, and all that weirdo polymophisim shit and such like).

Going all out Mr.OO in C++ is all good in very good in theory but when its real world stuff, it can become a real pain in the arse.

I couldn't disagree more. This leads to bad C, and very bad C++. If he wants to learn C, then he can get a C book and learn C. If not, then he should learn how to use C++, not a kneecapped subset.
Of course, I'm not expecting the guy to whup out all the features of C++ right from his first 'hello world' program, but advising him to stay away from those features for ever seems strange.
A good book would introduce the OO features of the language at a nice pace, so that he could learn without getting overwhelmed by it all. Hell, thats why you pay for the book.

[pkp|ex]

keep it simple stupid

[DrTiTus]

it all depends if you're working with things that come in many variants that you wanna treat the same [different protocols to do the same job, just with different equipment] or if you wanna just achieve a single task with one set of equipment that never changes....

[DrTiTus]

Originally posted by smudge
Why deliberately limit your chances of getting employment (if thats your intention for learning it). If youre not familiar with OO, the STL, and a shitload of other OO stuff you wont be able to get a job in c++ nowdays ime.

pk, if you get far enough into OO, it becomes pretty hard to not realize that objects and proceedures are actually the same thing, object hierarchies with virtual functions and switch statements are the same thing. They're just syntatically nicer ways of doing what good programmers do in C by hand to avoid writing spaghetti. You wont ever make the mental break thrus in understanding how to structure code in an OO way unless you force yourself to use it dude.

objects and procedures are not the same thing - abstracting the concepts from the implementation is what makes a good object, not just making an object that uses procedural code - here, hold still while I steal a chromosome from each cell you have - you don't need it anyway, its making you mongoloid

[MadLep]

Originally posted by pkp|ex
keep it simple stupid

OO often is simpler for some things. As usual, right tool for the job etc etc.

[smudge]

Originally posted by DrTiTus
objects and procedures are not the same thing - abstracting the concepts from the implementation is what makes a good object, not just making an object that uses procedural code -

You're missing my point. Keep at the oo coding, you might eventually agree with me, you might not. meh.

oo can be used for more than just defining interfaces and abstracting code, if thats the way you think, then you're missing half of it imo.

[Polarity]

Originally posted by smudge
You're missing my point. Keep at the oo coding, you might eventually agree with me, you might not. meh.

oo can be used for more than just defining interfaces and abstracting code, if thats the way you think, then you're missing half of it imo.

While I agree with your sentiment, objects are not the same thing as procedures and neither are switch statements the same thing as object hierarchies with virtual functions. Maybe you could explain the other "half" that some people appear to be missing.

[Adaptation]

Originally posted by smudge
Stroustrop wrote another book (cant remember the name) which explained the reason behind why things were like what they were. I reckon I learnt more from that than the reference.

That would be The Design and Evolution of C++ http://www.research.att.com/~bs/dne.html
I haven't actually read it, so can't comment on it.

Hooker - I suggest you have a look at: http://www.cuj.com/corner/read.htm

[Adaptation]

Originally posted by Polarity
While I agree with your sentiment, objects are not the same thing as procedures and neither are switch statements the same thing as object hierarchies with virtual functions. Maybe you could explain the other "half" that some people appear to be missing.

Here we go into the lands of offtopic with 'Switch statements and object hierarchies with virtual functions 101'

int eat_apple() {
	// eat an apple
	return 1;
}

// eat a food type, return 0 if we don't know the food type
int eat_food(int food_type) {
	switch (food_type) {
	case APPLE:
		return eat_apple();
	// etc etc
	default:
		return 0;
	}
}

// somewhere in code
int food_type = APPLE;
int eaten = eat_food(food_type);

struct Food {
	// eat a food type, return false if we don't know the food type
	virtual bool Eat(void) { return false; }
};

struct Apple : public Food {
	bool Eat(void) {
		// eat an apple
		return true;
	}
};
// etc etc

// somewhere in code
Apple apple;
Food* food = &apple;
bool eaten = food->Eat();

As for objects not being the same thing as procedures go do a search for functor's.

[king_dick]

pk, if you get far enough into OO, it becomes pretty hard to not realize that objects and proceedures are actually the same thing, object hierarchies with virtual functions and switch statements are the same thing.

Are you saying that because they can be used to do the same thing that they *are* the same thing?
I think I'm missing something... ?

[Boofhead]

so... uh... how'd you like them apples?

[Hooker]

Awesome replies guys, just to let ya know I'm going over the fundamentals using the Skill Builder CD's by NetG. Quite well done and it asks questions through each topic and an assessment once a topic is covered. 6 Cd's all together.

I think I'll learn a lot more once doing the practical - as going over the theory is relearning etc - but going over it for the syntax/different conventions.

Thanks guys!

[Polarity]

Originally posted by Adaptation
[b]Here we go into the lands of offtopic with 'Switch statements and object hierarchies with virtual functions 101'
...

As I said, I agreed with what he was saying, but I was being picky. They're simply not the same things! I was kind of hoping he'd back up his claims by explaining some of the benefits of OO design (i.e. http://c2.com/cgi/wiki?BenefitsOfOo) instead just telling his detractors "you're missing the point".

But as Madlep pointed out, right tool for the job still takes priority, OO or not.

[king_dick]

Originally posted by Polarity

But as Madlep pointed out, right tool for the job still takes priority, OO or not.

[mumble] the job that was being talked about was learning c++ so anything else was (because of the requirements) wrong [/mumble]

[Charismo']

Originally posted by Polarity
While I agree with your sentiment, objects are not the same thing as procedures and neither are switch statements the same thing as object hierarchies with virtual functions. Maybe you could explain the other "half" that some people appear to be missing.

Its all machine code in the end.

Could you tell from looking at machine code whether it was written OO or procedural? (be honest).

[king_dick]

Its all machine code in the end.

Could you tell from looking at machine code whether it was written OO or procedural? (be honest).

You dont have to, that's the point. Pretty much every language advance in the last 15 or so years has been in techniques to improve the writing of software, not in what happens to the code after it is compiled.
For all but the most detailed discussions of OO vs procedural programming, what happens to the code once it's written is irrelevant.
(Of course, this is all just my opinion, and I'm not a guru or anything. I would be interested to know why I'm wrong about this, if you think I am)

[Charismo']

Originally posted by king_dick
You dont have to, that's the point. Pretty much every language advance in the last 15 or so years has been in techniques to improve the writing of software, not in what happens to the code after it is compiled.
For all but the most detailed discussions of OO vs procedural programming, what happens to the code once it's written is irrelevant.
(Of course, this is all just my opinion, and I'm not a guru or anything. I would be interested to know why I'm wrong about this, if you think I am)

I know thats the point - thats why I said it. But also, because its all machine code in the end, and its functionality will be the same (or should be), you could argue that OO and procedural *are* the same once compiled - so then it is academically simply a matter of preference. We could all run out and write turing tape machine code to do the same thing as the most complex OO written program, if we wanted to, but its not intuitive to us to do that.

I find OO helps me lay out my software code in a more logical manner.

Procedural is great but only for small programs, imo.

[MadLep]

Originally posted by Charismo'
Procedural is great but only for small programs, imo.

What I've learnt about OO development is that it makes the easy things harder, and the harder things easier. There is a break even point somewhere in there once a project gets to a certain size (usually about the point where you need more than one developer working on it).

[Polarity]

General rant ...

Have a read about Design Patterns too. These apply more to OO than procedural stuff, but the concept is still the same. Design patterns can help both in the upfront design of a new program or the maintenance of an existing program, through the use of tried and true constructs to solve commonly recurring problems within a given context.

Design Patterns also aid in understanding the abstract concepts of a program. For example, through OO design w. Design Patterns, a developer maintaining code they haven't worked on previously doesn't have to immediately concern herself with the inner workings of a code base to figure out how things work - this will be made clear through design. The abstract language provided by OO/Design Patterns is useful for teams that add new people and require them to quickly get up to speed with a code base.

OO and Design Patterns also tie in nicely with Refactoring and Test Driven Development (TDD), which are basically just good things to do to help develop quality code, OO or not.

Some links:
http://www.refactoring.com/
www.dofactory.com/patterns/Patterns.aspx
http://msdn.microsoft.com/msdnmag/is...meProgramming/

[Adaptation]

Those are some nice links
A good book in that area is 'Design Patterns' by Gamma, Erich, Helm, and Vlissides (which replicates http://www.dofactory.com/patterns/Patterns.aspx ). For a more C++ centric approach to generic programming there's 'Modern C++ Design' by Andrei Alexandrescu. These books are more for experienced programmers however, especially Alexandrescu's.

As for switch statements vs virtual functions; I concede that they are not the same thing. Conceptually they are very different, but the actual generated code is similar:
A switch statement (best case) will use a jump table to indirectly jump to the relevant section/function.
A virtual function will result in an indirect jump via a vtable to the relevant function.

[smudge]

Originally Posted by DrTiTus

objects and procedures are not the same thing - abstracting the concepts from the implementation is what makes a good object, not just making an object that uses procedural code - here, hold still while I steal a chromosome from each cell you have - you don't need it anyway, its making you mongoloid

Almost 20 years later and finding this is quite funny.

These days we're writing functional javascript, where people are using only functions to replicate the few parts of OOP that are worth keeping, and most places I worked in the last few years won't let your code thru PR if there's any cases where you've used an object that could have been done functional style.

I didn't make much sense with what I was saying back then, but I think I've ended up not being far off.

[Lightspeed]

It's fascinating (fortunate/unfortunate?) the role javascript has in the contemporary development landscape. I don't think many 20 years ago would have believed it.