Sereious Question: Best way to learn C++

**~~CommonTater~~** · 01-09-2011

Originally Posted by jimblumberg

Normally two instances of a class will not share data between them.

Notice that the change of the variable b.yourVar does not change a.yourVar.

Ok... so there's data isolation between differently named copies of the same class.
But what about same name copies in different contexts?

Code:

// in 1. cpp
YourClass Fred;

// in 2.cpp
YourClass Fred;

Or is this what inheritance is about? I can create sort of a master class and then create classes from that to do the actual work.

The reason I keep pushing this point is that I actually do have something of an application in mind for it. Basically I will need to have a single list of information that will be used in differing parts of the program... but they all have to access that one single array of structs, updating it "on the fly"... I'm pretty sure I know how to do this in C, using a global array... but I would like to take a pop at it in C++ fairly early in the learning curve (to help me decide whether to continue working on it in C or not).

**~~CommonTater~~** · 01-09-2011

Originally Posted by \007

Not sure if my C example I posted helped or confused you, but it's really not too hard to wrap your head around.

That I got... I've played with function pointers in structs before...

**~~CommonTater~~** · 01-09-2011

Originally Posted by laserlight

If you have ever used the opaque pointer technique in C you would have done so in recognition of the value of hiding the implementation: it means that your implementation can more easily be changed without breaking client code. This same idea applies to access control in C++.

I've read about it but never implemented it... However; your reasoning makes perfect sense. I can update a class without having to rewrite other parts of the code so long as I don't change the public parts... Now that's a reason I can understand.

**laserlight** · 01-09-2011

Originally Posted by CommonTater

But what about same name copies in different contexts?

The same as in C, except that there are no tentative definitions, and that the use of an unnamed namespace is preferred to declaring them static.

**tabstop** · 01-09-2011

Originally Posted by CommonTater

Ok... so there's data isolation between differently named copies of the same class.
But what about same name copies in different contexts?

Code:

// in 1. cpp
YourClass Fred;

// in 2.cpp
YourClass Fred;

You're joking, right? (ETA: The confusion on my end is based not so much on "how stupid is he", but rather on how mystical you seem to think this whole process is. Once we start getting into the "names have power" trope, we're usually pretty deep. And it just doesn't fit your other postings.)

We still obey all the usual rules of variable names; just because I have a variable called x in function_1 doesn't mean it's the same as the variable x in function_2.

The only way these would be the same (just as with regular variables) is if they are both "global" (i.e., at file scope, i.e., declared outside any function) and one of them is marked extern.

**jimblumberg** · 01-09-2011

Ok... so there's data isolation between differently named copies of the same class.
But what about same name copies in different contexts?

As long as they are in a different scope they would be separate, the same as any POD variable.

example:

Code:

 
void funct1()
{
   int a;
   YourClass Fred;
}

void funct2()
{
   int a;
   YourClass Fred;
}

Neither 'a' or 'Fred' would share the same data because they are in different a different scope.

Jim

**~~CommonTater~~** · 01-09-2011

Originally Posted by tabstop

You're joking, right?

Ummmm... no, quite serious.... Up to this morning, when I read about classes I saw

ailqwpo8uy t2p048 oreduy 30 osau t0df;oas kdtg 76ys

... Really it was that bad.

Now, finally it's beginning to make some sense to me...

We still obey all the usual rules of variable names; just because I have a variable called x in function_1 doesn't mean it's the same as the variable x in function_2.

The only way these would be the same (just as with regular variables) is if they are both "global" (i.e., at file scope, i.e., declared outside any function) and one of them is marked extern.

Thank you! That's what I needed to know.... So you can have global classes... and extern does work on them... very cool.

(BTW... I've never seen this particular point addressed in any book or tutorial I've read...)

**tabstop** · 01-09-2011

Originally Posted by CommonTater

Ummmm... no, quite serious....

Just made an edit to that, so maybe that helps clarify where I am, anyway.

Originally Posted by CommonTater

Thank you! That's what I needed to know.... So you can have global classes... and extern does work on them... very cool.

(BTW... I've never seen this particular point addressed in any book or tutorial I've read...)

We might as well try and keep the terminology as straight as we can in this thread: no such thing as a global class. You can have global variables (and if you're the sort of person who needs to call a variable of class type an "object", then you can have global objects). But global is a property of that particular variable, not of the class as a whole.

**laserlight** · 01-09-2011

Originally Posted by CommonTater

Basically I will need to have a single list of information that will be used in differing parts of the program... but they all have to access that one single array of structs, updating it "on the fly"... I'm pretty sure I know how to do this in C, using a global array... but I would like to take a pop at it in C++ fairly early in the learning curve (to help me decide whether to continue working on it in C or not).

There is nothing in this description that makes it sound like full blown OO techniques (I'm thinking of inheritance and polymorphism) will really be useful. If you will be reaching for the struct keyword in C, then you can correspondingly write a class in C++ and benefit from language enforced encapsulation, but that is about it on that front. If you will be using a global array in C, then you will still be using a global array in C++, whether or not you choose to implement the singleton pattern to make for a single point of access (you'll still have global state either way). Oh, if you will be using a dynamic array then std::vector from the C++ standard library will help.

**~~CommonTater~~** · 01-09-2011

Originally Posted by tabstop

(ETA: The confusion on my end is based not so much on "how stupid is he", but rather on how mystical you seem to think this whole process is. Once we start getting into the "names have power" trope, we're usually pretty deep. And it just doesn't fit your other postings.)

Well, when it comes to OOP, I guess I am pretty stupid.

Really... I've tried and bounced off this about 10 times over the past 4 or 5 years. Books and tutorials didn't help... in fact, some made it worse. It just seemed that everytime I got within an inch of the goal, I would somehow fail and not "get it".

Today I've gotten answers to 3 of the major "mysteries":
1) You communicate with classes by calling methods (functions).
2) Classes are a type of structure that is declared like a variable.
3) Classes follow rules of scope just like other variables.

And yes, I did think it was pretty mystical, given my total inability to grasp it.

**~~CommonTater~~** · 01-09-2011

Originally Posted by tabstop

Just made an edit to that, so maybe that helps clarify where I am, anyway.

We might as well try and keep the terminology as straight as we can in this thread: no such thing as a global class. You can have global variables (and if you're the sort of person who needs to call a variable of class type an "object", then you can have global objects). But global is a property of that particular variable, not of the class as a whole.

Ok... I'm still stuck on C terms here... But I get the concept.

**laserlight** · 01-09-2011

Originally Posted by CommonTater

Today I've gotten answers to 3 of the major "mysteries":
1) You communicate with classes by calling methods (functions).
2) Classes are a type of structure that is declared like a variable.
3) Classes follow rules of scope just like other variables.

You might want to refer to tabstop's post #53. Basically, you are confusing classes and objects in your terminology. You could refer to Stroustrup's C++ online glossary:

class - a user-defined type. A class can have member functions, member data, member constants, and member types. A class is the primary mechanism for representing concepts in C++.

object - (1) a contiguous region of memory holding a value of some type. (2) a named or unnamed variable of some type; an object of a type with a constructor is not considered an object before the constructor has completed and is no longer considered an object once a destructor has started executing for it. Objects can be allocated in static memory, on the stack, on on the free store.

**~~CommonTater~~** · 01-09-2011

Originally Posted by laserlight

There is nothing in this description that makes it sound like full blown OO techniques (I'm thinking of inheritance and polymorphism) will really be useful. If you will be reaching for the struct keyword in C, then you can correspondingly write a class in C++ and benefit from language enforced encapsulation, but that is about it on that front.

Ok... that makes sense, I think... I didn't think this needed to be done in classes, but since I have it more or less roughed out in C, it's fresh on my mind and struck me as a good first project. It's pretty simple code, so perhaps a good first experiment.

If you will be using a global array in C, then you will still be using a global array in C++, whether or not you choose to implement the singleton pattern to make for a single point of access (you'll still have global state either way). Oh, if you will be using a dynamic array then std::vector from the C++ standard library will help.

I was thinking mostly about using a class to centralize (standardize) the function calls that operate on the array...

**laserlight** · 01-09-2011

Originally Posted by CommonTater

I was thinking mostly about using a class to centralize (standardize) the function calls that operate on the array...

The problem is that if every function will have direct access this array, then you end up with this huge monolithic class that really does not add any value. All that would happen is that instead of using free function calls, you use member function calls, but that's mere syntax.

**~~CommonTater~~** · 01-09-2011

Originally Posted by laserlight

The problem is that if every function will have direct access this array, then you end up with this huge monolithic class that really does not add any value. All that would happen is that instead of using free function calls, you use member function calls, but that's mere syntax.

Well, the list is only one part of the project... There's still some calculations, a couple of dialogs for setup and such... but you are right, probably 1/4 of the code will be dealing with that array.