NZGames.com Forums
Register FAQ Calendar Mark Forums Read

Go Back   NZGames.com Forums > General > Coders' Forum
User Name
Password

Reply
 
Thread Tools
Old 12th May 2004, 15:52     #1
Hooker
 
Lightbulb C++ - Starting from Scratch

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.
  Reply With Quote
Old 12th May 2004, 18:27     #2
Azuth
 
The C++ Programming Language. By Stroustrup the guy who created the language.
  Reply With Quote
Old 12th May 2004, 21:21     #3
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.
  Reply With Quote
Old 12th May 2004, 21:24     #4
smudge
Ich Bin Ein Grey Lynner
 
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.
  Reply With Quote
Old 12th May 2004, 23:03     #5
yem
 
Accelerated C++ isn't too bad IMO.
  Reply With Quote
Old 15th May 2004, 08:53     #6
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.
  Reply With Quote
Old 15th May 2004, 09:47     #7
smudge
Ich Bin Ein Grey Lynner
 
Quote:
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.
  Reply With Quote
Old 15th May 2004, 12:06     #8
king_dick
 
Quote:
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.
  Reply With Quote
Old 18th May 2004, 01:45     #9
pkp|ex
 
keep it simple stupid
  Reply With Quote
Old 18th May 2004, 02:25     #10
DrTiTus
HENCE WHY FOREVER ALONE
 
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....
  Reply With Quote
Old 18th May 2004, 02:27     #11
DrTiTus
HENCE WHY FOREVER ALONE
 
Quote:
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
  Reply With Quote
Old 18th May 2004, 04:15     #12
MadLep
 
Quote:
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.
__________________
@madlep
I'm not Australian, I just live there
ubercharged.net - Tales of Team Fortress 2 pwnage and other hilarity
  Reply With Quote
Old 18th May 2004, 09:20     #13
smudge
Ich Bin Ein Grey Lynner
 
Quote:
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.
  Reply With Quote
Old 18th May 2004, 13:44     #14
Polarity
 
Quote:
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.
  Reply With Quote
Old 19th May 2004, 21:26     #15
Adaptation
 
Quote:
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
  Reply With Quote
Old 19th May 2004, 21:54     #16
Adaptation
 
Quote:
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'

Code:
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);
Code:
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.

Last edited by Adaptation : 19th May 2004 at 21:57.
  Reply With Quote
Old 19th May 2004, 23:22     #17
king_dick
 
o_O

Quote:
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... ?
  Reply With Quote
Old 20th May 2004, 03:59     #18
Boofhead
 
so... uh... how'd you like them apples?
  Reply With Quote
Old 20th May 2004, 12:15     #19
Hooker
 
Thumbs up

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!
  Reply With Quote
Old 20th May 2004, 13:49     #20
Polarity
 
Quote:
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.
  Reply With Quote
Old 22nd May 2004, 03:33     #21
king_dick
 
Quote:
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]

  Reply With Quote
Old 22nd May 2004, 11:37     #22
Charismo'
 
Quote:
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).
  Reply With Quote
Old 22nd May 2004, 12:50     #23
king_dick
 
Quote:
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)
  Reply With Quote
Old 22nd May 2004, 16:18     #24
Charismo'
 
Quote:
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.

Last edited by Charismo' : 22nd May 2004 at 16:22.
  Reply With Quote
Old 22nd May 2004, 19:20     #25
MadLep
 
Quote:
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).
__________________
@madlep
I'm not Australian, I just live there
ubercharged.net - Tales of Team Fortress 2 pwnage and other hilarity
  Reply With Quote
Old 23rd May 2004, 20:15     #26
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/
  Reply With Quote
Old 24th May 2004, 21:29     #27
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.
  Reply With Quote
Old 23rd March 2022, 23:28     #28
smudge
Ich Bin Ein Grey Lynner
 
Quote:
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.
  Reply With Quote
Old 4th April 2022, 18:32     #29
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.
__________________
Stay shook. No sook.
  Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump



© Copyright NZGames.com 1996-2021
Site paid for members (love you guys)