bull****, don't listen it

Sure, even in very good game engines, there might be class/structs to encapsulated "objects"... but as you suggested, virtual calls are a big no-no.

But even beyond those things that create very poor machine code (e.g. vtables, RTTI, exception handling, etc... ), typical OO design philosophies are often at odds with the realities of modern computer architectures. In particular I'm talking about the gulf that has developed between CPU processing power and memory bandwidth.

In most non-trivial apps, memory bandwidth has become the most important performance consideration.... and this means that "data access"-centric design beats out object-centric design. For examples, a "structure of arrays" data structure is often the best performance choice but you'd never hear about such a thing from any OO book/whitepaper/class.

My brother says this is a great website:
http://www.learncpp.com/

http://publications.gbdirect.co.uk/c_book/

This is a good short book. It describes ANSI C programming with a nice level of precision. Very useful for c++ imo.

Considering copies are available for like 5 bucks shipped, why not?

Lol good luck learning programming if you don't want to read a 1280 page book. I were to add up all of the blog posts, articles, tutorials, and books I read in my first year of programming it would probably be between 5,000 and 7,500 pages.

I read far less than that, I think it depends how you want to learn. I definitely wouldn't want to read a 1,280 page book! But that might just be me.

People learn in different ways, but with C++ in particular, I think sitting down with one source that thoroughly covers how C++ handles OOP and slogging through it is unavoidable. I started learning C almost 20 years ago, and picked up bits and pieces of C++ from reading other peoples code or articles/tutorials on the web, but never really could wrap my head around the nuances of virtual functions and polymorphism.

It wasn't until I started learning Qt and picked up that 1280 page book that everything came together for me. With Qt you have a very well designed and documented OOP framework to find real world examples, and Core C++ helped me organize and understand many of the subtleties and details. So I would recommend to anyone progressing past the basics of C/C++ to try learning a good C++ library (I can only recommend Qt, I'm sure others on here have some recommendations, and I would recommend avoiding messing around with the STL as a beginner) along with a good book on C++ (more than a few have been mentioned).

correct me if im wrong, but library's the things you put at the top? if so ive been learning / using these so far:

#include "stdafx.h"
#include <stdlib.h>
#include <time.h>
#include <iostream>
#include <string>

the main thing im worried about is learning something I shouldn't be learning for fear of developing bad habits. for instance iv been using "using namespace std ; " since i started a week or so ago and and now im reading about how this is horrible because it replaces all instances of something or other

any tips on things i should NOT be doing?

also, grats man you sold me ill buy your 10lbs book but ill get it used like someone suggested. xD

time.h is ctime and stdlib.h is cstdlib in C++. The time.h and stdlib.h is from its C heritage, the cpp versions remove the .h and adds a c at the beginning

I was taught in school to add using namespace std; so I don't think its wrong as such. Maybe some consider it bad practice but I think its quite common. Most modern text books use that line in the sample code.

Library writers should probably think long and hard before they declare a class with a name that duplicates one from namespace std.

THis is true.. In that sense it would prob be better to do for example std::cout or whatever the syntax is...

is it bad manner to use switches in c++ ?

You mean switch case? No

This may be relevant to your interests...

http://stackoverflow.com/questions/1...er-should-read

Yah, the first three includes are C standard library (stdlib) header files which basically tell the compiler to insert all of the functions/classes declared in the headers. The last two are C++ stdlib headers.

The main problem with just using 'using namespace std;' is that it's easy to pass over learning about how the C++ namespace works. For example, the string object defined in <string> is part of the 'std' namespace, and might be declared like

namespace std {

class String { ... };

}

and you need to use the namespace resolution operator 'std::String' whenever you reference a String object in your code. The 'using namespace std;' statement allows you to just use String without the :: operator, like if I wanted to declare a string object as 'String hello("hello!");' but it also imports every other variable and function name in the std namespace from any included stdlib headers, which might conflict with ones you're using. Not a big deal when you're doing simple programs, but if you're writing something that might include library files that might use the same names, or if your code is part of a library other people will include, you don't want to "pollute" the namespace by introducing all of those std namespace names.

But imagine if you want to make your own String class and for some reason also want to use the stdlib String class, perhaps by extending std::String through inheritance, you can do the following:

class String : public std::String { ... };

Something I typically do if I'm using a single function from a library header, is to use something like 'using std::String;' which has the same effect as 'using namespace std;' without importing all of the names from the library I won't need. It also acts as a form of documentation, where you can look at the top of a source file and see what exactly is being used from any included headers.

It takes a while to get used to how libraries work with C++, particularly when you start using libraries outside the standard library and have to learn about the linking phase of compilation, and the difference between static and dynamic libraries, and it's one of the annoyances of dealing with C++.

No, and switches have advantages over if-else statements. You see switches implemented a lot when the program needs to display a menu to the user.

Good post on namespace btw, learned something

Reading back over this... you shouldn't be 'using namespace whatever' in any header files, because you'll end up removing namespace protections in every source file those headers are included in.

Using it in your .cpp files is fine.

Also one thing I cant find the answer to is on the topic of if / else if / else.
say the user is prompted to enter "1" "2" or "3" (and assume he never enters anything else for the sake of argument) and then we will spit that number back out at him.

is there a difference between:
if 1 , output 1
if 2, output 2
if 3, output 3

and

if 1 , output 1
else if 2, output 2
else output 3

and

if 1 , output 1
if 2, output 2
else output 3

i think i see how the else is useful for if he enters "4" on accident, but why else if? i dont see how 'if' followed by an 'else if' is different from an 'if' followed by another 'if'

The reason I ask is because I have read in multiple places that "goto" is bad, and the switches / breaks kinda felt like they were in the genre as goto.

edit:

also, thanks a lot for answering my noob questions guys xD

A switch statement is just syntactic sugar on an if-else block:

http://www.eecs.wsu.edu/~cs150/reading/sugar.htm

and no more related to "goto" than if statements.

deciding when and how to use

if
if
if

if
else-if
else-if
else

if
....

is one of those things I wish I could explain. It's so code dependent that sometimes I swear one thing should work, but then it doesn't. This is one of those things you can experiment on quite a bit and find out many strange things.

Just don't do:

if{
[code here]
}else{
// commented out for readability and nothing else really....
}

I generally program in c# but an example I just came up with

if (a < 10)
Console.WriteLine();
else if (a < 20)
Console.WriteLine();
else
Console.WriteLine();

I know its not exactly clear but I apologise it is 7am here and I have just spent the last 12 hours working out bitwise manipulation and my brain is fried. Code a similar problem and see what happens when you step through if you don't understand.

EDIT: I guess I like to use them when the statements are related and it allows me to follow the trace more clearly....

A couple reasons come to mind:

1) Performance. If you're not breaking or returning a function, using if/else avoids evaluating some of the conditionals some of the time. You can put the most commonly followed conditional first.

2) Error handling. It's good practice (when appropriate) to add an else statement at the end of if/else if blocks and throw an exception or log an error when you do get an unexpected value.

3) Readability/self documentation. Using if/else if blocks makes it obvious that only one of the conditionals should evaluate.

4) Error prevention. Prevents you from modifying the value used for the conditional in one of the blocks and accidentally evaluating two of them.

This is actually not completely true in C++. The labels in a switch must be constants, whereas in an if/else you're free to compare with things that are evaluated at runtime.

http://thenewboston.org/list.php?cat=16
perfect for starting, around 70 short videos giving you precise instructions in a very friendly manner!