NZGames.com Forums

NZGames.com Forums (https://forums.nzgames.com/index.php)
-   Coders' Forum (https://forums.nzgames.com/forumdisplay.php?f=19)
-   -   C++ - Starting from Scratch (https://forums.nzgames.com/showthread.php?t=59091)

Hooker 12th May 2004 14:52

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.

Azuth 12th May 2004 17:27

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

king_dick 12th May 2004 20:21

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 12th May 2004 20:24

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 12th May 2004 22:03

Accelerated C++ isn't too bad IMO.

pkp|ex 15th May 2004 07:53

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 15th May 2004 08:47

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.

king_dick 15th May 2004 11:06

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.

pkp|ex 18th May 2004 00:45

keep it simple stupid :)

DrTiTus 18th May 2004 01:25

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 18th May 2004 01:27

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

MadLep 18th May 2004 03:15

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.

smudge 18th May 2004 08:20

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.

Polarity 18th May 2004 12:44

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.

Adaptation 19th May 2004 20:26

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

Adaptation 19th May 2004 20:54

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.

king_dick 19th May 2004 22:22

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... ?

Boofhead 20th May 2004 02:59

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

Hooker 20th May 2004 11:15

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 20th May 2004 12:49

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.

king_dick 22nd May 2004 02:33

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]

:)

Charismo' 22nd May 2004 10:37

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).

king_dick 22nd May 2004 11:50

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)

Charismo' 22nd May 2004 15:18

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.

MadLep 22nd May 2004 18:20

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).

Polarity 23rd May 2004 19:15

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 24th May 2004 20:29

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 23rd March 2022 22:28

Quote:

Originally Posted by DrTiTus (Post 1067398)
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 4th April 2022 17:32

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.


All times are GMT +13. The time now is 08:51.

Powered by Trololololooooo
© Copyright NZGames.com 1996-2023
Site paid for by members (love you guys)