Game Maker's Garage Forum

Game Creation => Code Exchange => Topic started by: Gan on January 23, 2011, 10:22:33 AM

Title: Objects
Post by: Gan on January 23, 2011, 10:22:33 AM
One of Sc's greatest weaknesses is the lack of objects.

So what do I mean?

An object is like a normal variable. Like an int or a string. Except it can hold multiple numbers and strings. Here's an example.

Bad Guy Object Contains:
Name
HP
STR
DEF
Weapon

If Sc worked with objects it'd look like this:
Code: [Select]
//This creates the object
LET badGuy = new BadGuy
badGuy.name = "Darktanyon"
badGuy.hp = 5
badGuy.str = 3
badGuy.def = 6
badGuy.weapon = "Whip of Misfortune"
//Now that the bad guy is all set lets add him to an array
APPENDARRAY badGuyArray, badGuy

You see how useful this is? One object holds many variables that you can store in a single array.

So I'm thinking just like we artificially created arrays before Sc officially got them, we should artificially create objects.
Anyone have any ideas?
Title: Re: Objects
Post by: WarHampster on January 23, 2011, 10:29:36 AM
They wouldn't be real objects, the best we could fake would probably be structs.

Here's how it would have to work:

SC doesn't support arrays of arrays, so we'd have to use strings to store all the local variables. We could do what we used to do for arrays, write a method to process a specially formatted string as an struct. Then you could store the "structs" in an array.

Ok so we would make a method for each class. "MAKESTRUCT localvar1 localvar2... string$"

Then the method would format the string parameter as an enemy struct and return it.
Title: Re: Objects
Post by: Connors on January 23, 2011, 11:25:31 AM
I like it! I say we try out his idea! XD
Title: Re: Objects
Post by: Charlo on January 23, 2011, 11:38:36 AM
In Bricker I used parallel arrays to achieve something like objects for the bricks.  Each brick had the following properties:

x
y
height
width
r value
g value
b value
solidness (1 or 0)

I started out by defining brick strings in an array like brick$(1) = "20, 20, 50, 50, 255, 0, 0, 0" etc.  I then used a method to parse the first value of each brick string into a brickx array.  So now the brickx array contains the x coordinate of every brick.  I did the same for every other attribute, so now I've got 8 arrays in parallel.  Referencing, say, the seventh item in each array gave me all the information for the seventh brick, and I could change them all individually.  

The problem would be that there would be way too many arrays if you wanted to make an RPG where EVERYTHING was an object.  Obviously you also wouldn't be able to do anything resembling "objectname.property" syntax either.

*Edit* Silver's idea is roughly the same as mine (I think), although I try to avoid string manipulation as much as possible so storing variables long term in strings doesn't sound good to me.
Title: Re: Objects
Post by: EqwanoX on January 23, 2011, 02:23:09 PM
you can easily already do this with string arrays and you can have as many dimentions as you want by useing seperators

in one of my games i store all enemy locations in one string

let enemyxy$="3-2,3-4,6-7,8-6"

let xy=val(nthfield$(enemyxy$,",",1))   //this would return the "3-2"

//then just can split the x and y  with nthfield by changine the seperator to "-"

this is also how i store the enemy stats in gangwars

//1-2 xy on map, 3-4 xy on sprite sheet, 5 damage, 6 hp, 7evade, 8 accuracy,
let npc$(1)="3,6,2,8,6,90,20,10"

you can take it even further, this is basically exacly what gan described:

//stats are stored from the fifth digit allowing four spaces for a label
let npc$(1)="xmap3,ymap6,xspr2,yspr8,dam-6,hp--90,evd-20,acc-10"

let x$=nthfield$(npc$(1),",",6)    //returns the 6th field "hp--90"
let hp(1)=val(mid$(x$,5,5))       //returns 5 digits starting from the 5th digit
Title: Re: Objects
Post by: Gan on January 23, 2011, 02:34:51 PM
I've made a working artificial objects test:
http://cl.ly/0c1w1p2q3D1X3R3H0O0n

In Open Game:
Code: [Select]
//Set up bad guy object
LET BadGuy = 5
LET BadGuyName = 1
LET BadGuyHp = 2
LET BadGuyStr = 3
LET BadGuyDef = 4
LET BadGuyWeapon = 5


LET badGuy$ = CreateObject$(BadGuy)
LET badGuy$ = SetObject$(badGuy$,BadGuyName,"Dartanyon")
LET badGuy$ = SetObjectNum$(badGuy$,BadGuyHp,5)
LET badGuy$ = SetObjectNum$(badGuy$,BadGuyStr,2)
LET badGuy$ = SetObjectNum$(badGuy$,BadGuyDef,6)
LET badGuy$ = SetObject$(badGuy$,BadGuyWeapon,"Whip of Misfortune")

PRINT GetObject$(badGuy$,BadGuyName)
PRINT GetObject$(badGuy$,BadGuyHp)
PRINT GetObject$(badGuy$,BadGuyStr)
PRINT GetObject$(badGuy$,BadGuyDef)
PRINT GetObject$(badGuy$,BadGuyWeapon)

Then I have 5 methods to handle creation, getting and setting of objects.
Method Name: CreateObject$
Parameters: object
Code: [Select]
LET returnString$ = ""
FOR i = 1 to object-1
   LET returnString$ = returnString$ + ";"
NEXT
RETURN returnString$
Method Name: SetObject$
Parameters: object$,objectVar,setVar$
Code: [Select]
LET val = COUNTFIELDS(object$, ";")//number of fields separated by ";"
IF objectVar > 1 THEN
   FOR x = 1 to objectVar-1
      LET var2$ = var2$ + NTHFIELD$(object$, ";", x) + ";"//gets each field of var$ and adds it to end of var2$ and then adds separator
   NEXT
END IF
IF objectVar+1 < val THEN
   FOR x = objectVar+1 to val
      LET var3$ = var3$ + ";" + NTHFIELD$(object$, ";", x)
   NEXT
END IF
LET object$ = var2$ + setVar$ + var3$//put it back together again
LET var2$ = ""//set variables back to nothing so they are fresh for your next change
LET var3$ = ""
RETURN object$
Method Name: GetObject$
Parameters: object$,objectVar
Code: [Select]
return NTHFIELD$(object$, ";", objectVar)
Method Name: SetObjectNum$
Parameters: object$,objectVar,setVar
Code: [Select]
LET val = COUNTFIELDS(object$, ";")//number of fields separated by ";"
IF objectVar > 1 THEN
   FOR x = 1 to objectVar-1
      LET var2$ = var2$ + NTHFIELD$(object$, ";", x) + ";"//gets each field of var$ and adds it to end of var2$ and then adds separator
   NEXT
END IF
IF objectVar+1 < val THEN
   FOR x = objectVar+1 to val
      LET var3$ = var3$ + ";" + NTHFIELD$(object$, ";", x)
   NEXT
END IF
LET object$ = var2$ + str$(setVar)+ var3$//put it back together again
LET var2$ = ""//set variables back to nothing so they are fresh for your next change
LET var3$ = ""
RETURN object$
Method Name: GetObjectNum
Parameters: object$,objectVar
Code: [Select]
return val(NTHFIELD$(object$, ";", objectVar))


How it works is that you first define the object properties. The LET BadGuy = 5 tells it how many variables are in the object. Then each variable is given a name and the number of the variable inside the object. So LET BadGuyName = 1. The first variable in the object.
You can set and get objects using the appropriate methods.
Title: Re: Objects
Post by: x on January 23, 2011, 06:26:32 PM
I get the feeling you don't actually know what OOP is. What you have created is a struct, not an object. For your information an object isn't "like a normal variable. Like an int or a string. Except it can hold multiple numbers and strings. Here's an example.". That is whats called a a reference, or pointer to an object, the object isn't a "variable" in its own right. In addition the actual programming paradigm you have created is a struct, commonly used in C programming ( http://en.wikipedia.org/wiki/Struct ), an object would enable you to encapsulate methods, static variables, and data hiding. Lack of more complex features like polymorphism, inheritance and overloading is obviously out of the question due to complexity.
Title: Re: Objects
Post by: Gan on January 23, 2011, 06:29:57 PM
Yes, yes, getting all technical.

I use the word object because it is easier to understand than struct for someone who has never programmed in anything but simple game makers.
Title: Re: Objects
Post by: x on January 23, 2011, 06:31:54 PM
Quote
Yes, yes, getting all technical.

I use the word object because it is easier to understand than struct for someone who has never programmed in anything but simple game makers.

Wouldn't using incorrect terminology confuse beginners even more when they start using structs and objects? Calling this a struct doesn't diminish its usefulness  :P
Title: Re: Objects
Post by: Gan on January 23, 2011, 06:38:11 PM
I'm fairly sure it won't matter. This artificial object test I made is incredibly similar to Classes which in turn is also similar to Structs. They are all close so I doubt it matters.

The goal is to make game making easier to understand and use. One reason sprites are called sprites. When in OpenGl they use textures. Unless a custom sprite class is made.

Bah, doesn't matter. Call it what you wish. It's functionality resembles both.
Title: Re: Objects
Post by: x on January 23, 2011, 06:40:51 PM
Quote
I'm fairly sure it won't matter. This artificial object test I made is incredibly similar to Classes which in turn is also similar to Structs. They are all close so I doubt it matters.

The goal is to make game making easier to understand and use. One reason sprites are called sprites. When in OpenGl they use textures. Unless a custom sprite class is made.

Bah, doesn't matter. Call it what you wish. It's functionality resembles both.

Its functionality does NOT resemble both. Thats my point. Is there any data hiding? Can I use methods? Static variables?
Title: Re: Objects
Post by: Gan on January 23, 2011, 06:47:39 PM
Classes can hold variables. Variables can be accessed, set, and read. Classes can be stored in arrays.
These artificial objects can do the same. They resemble classes even if they don't fully duplicate functionality.
They also resemble structs.

But the word object is easier to understand than struct to a beginner. For example, a weapon object. Holds the name, damage, cost, ect. Makes more sense to an untrained mind than a weapon struct. Chances are when they move to a more advanced language they'll just use classes as objects instead of structs.
Title: Re: Objects
Post by: x on January 23, 2011, 06:57:09 PM
Quote
Classes can hold variables. Variables can be accessed, set, and read. Classes can be stored in arrays.
These artificial objects can do the same. They resemble classes even if they don't fully duplicate functionality.
They also resemble structs.

But the word object is easier to understand than struct to a beginner. For example, a weapon object. Holds the name, damage, cost, ect. Makes more sense to an untrained mind than a weapon struct. Chances are when they move to a more advanced language they'll just use classes as objects instead of structs.

There are so many things wrong with this post I am actually starting to feel a little bit angry. Classes CAN'T be stored in arrays, classes CAN'T hold variables. Classes are blue prints from which you create objects. Objects usually can't be stored in arrays either, its the POINTER or REFERENCE variable that is. Time for a quick objects lesson.
When we create an object:
className foo = new className (this is pseudocode)
What we are doing is creating a reference variable called foo, which usually stores an integer value pointing to the location in memory of the object we just created. This is why in C based languges we can actually screw with references big time by doing this: foo++. We have new moved our pointer over 1 bit in memory. The actual object is not stored in the variable foo. Got it?

Now, this does NOT resemble an object. To be an object you MUST and I repeat MUST enable basic features like methods and data hiding. Which you simply do not have. But if you would stop banging your head against the wall and spewing fallacious statements at me, I could give you some ideas of how to enable these features.

Also in my opinion the word "structure" is just as user friendly as the word "object" for describing whats being done.
Title: Re: Objects
Post by: EqwanoX on January 23, 2011, 06:58:42 PM
i dont see how thats easier than just putting all the enemy stats in one string array like this:

LET badguy$(1)="dartanyon,5,2,6,whip of misfortune"

then when needed, all the stats are loaded into arrays.
Title: Re: Objects
Post by: x on January 23, 2011, 07:05:54 PM
Quote
i dont see how thats easier than just putting all the enemy stats in one string array like this:

LET badguy$(1)="dartanyon,5,2,6,whip of misfortune"

then when needed, all the stats are loaded into arrays.

It isn't, the only reason a person would use a struct over an array would be because of three reasons. You can store any type of variable (int, long, string, etc you name it), you can even store objects in structs, its easier to access than arrays since you can just go "blah.variable"; its like syntactical eye candy.

Title: Re: Objects
Post by: Gan on January 23, 2011, 07:23:41 PM
Call it whatever you want, a name is not worth fighting over.

@Eq: It's the same as your string array method, just a bit more advanced. It gives a name to each piece of data inside the string array. Allowing for easier organization. Also includes one line getting and setting of certain values inside the string array.

P.S. I've never used a struct, only Classes. The functionality I've duplicated in this I have taken directly from Classes.
Title: Re: Objects
Post by: Charlo on January 23, 2011, 07:36:56 PM
X is right, what we're doing here is replicating the functionality of the attributes of objects.  All other things that he mentioned (like data hiding, polymorphism and methods) would be significantly harder to achieve, and until we do all those things we don't have objects.

For instance methods you could try defining a global method which takes as parameters both the normal method parameters and a parameter for the object that is calling it.  Then the method is executed ONLY if the caller object is correct.  The same could be done for data hiding, making getter and setter methods for every instance variable and only returning the value of the variable if the caller object is correct.  Of course, since there is no "private" in SC, no data is ever truly hidden.

I can't think of any way to do polymorphism.  At this point I think I would just want to program in Java or something.
Title: Re: Objects
Post by: x on January 23, 2011, 08:03:21 PM
Basically all you have done is replicate the functionality of a struct, and claim its an object because the name is less confusing (which is more confusing in and of itself).

Data hiding is plausible, just make sure all the values are stored in your array string and marked as either public or private. And make your getter method only return public ones.

"private foo=100,public bar=10"

For methods it could be done very simply as follows. Have a function that takes an object (they are objects now if they have data hiding and methods) as its parameter, checks if its the right object type and uses that objects attributes to perform the method:

CLASSNAMEMETHODNAME(object)

Polymorphism would be easy, just do a type check in the method. Done.

Inheritance is the hard bit.
Title: Re: Objects
Post by: Gan on January 23, 2011, 08:12:05 PM
In a non-C related programming language where other terms aren't known, the name object makes complete sense.
An object has attributes, certain definable characteristics.
This is what my code accomplishes.
For example there's a cube in front of you. Lets say it's the color red, is 5 inches in length, and is 1 pound.
In Sc that cube would be an object with those attributes defined.

From an inexperienced user's viewpoint this name makes perfect sense.
I'm sure you guys are correct in your terminology.
Title: Re: Objects
Post by: x on January 23, 2011, 08:13:38 PM
Quote
In a non-C related programming language where other terms aren't known, the name object makes complete sense.
An object has attributes, certain definable characteristics.
This is what my code accomplishes.
For example there's a cube in front of you. Lets say it's the color red, is 5 inches in length, and is 1 pound.
In Sc that cube would be an object with those attributes defined.

From an inexperienced user's viewpoint this name makes perfect sense.
I'm sure you guys are correct in your terminology.

You are incorrect, a STRUCT has attributes and certain definable characteristics. An object also has methods and data hiding, as ive said multiple times.

You are calling an apple and orange because you claim it makes more sense.

Anyways, in my above post I gave ideas how you could fake actual objects.
Title: Re: Objects
Post by: Gan on January 23, 2011, 08:18:32 PM
Quote
In a non-C related programming language where other terms aren't known, the name object makes complete sense.
An object has attributes, certain definable characteristics.
Reread?
Title: Re: Objects
Post by: x on January 23, 2011, 08:22:14 PM
Quote
Reread?
I have read it, its still wrong.

A struct is a generic programming paradigm. So is an object.

Theres an easy solution though, make them into real objects instead of struct by follow the advice Charlo and I gave.
Title: Re: Objects
Post by: x on January 23, 2011, 08:44:57 PM
Interesting, you could theoretically define an object within and object and have an array within an array here. Hence 2d arrays.
Title: Re: Objects
Post by: WarHampster on January 23, 2011, 09:30:43 PM
Step one: leave for a year

Step two: come back all wise and cynical

Step three: ???

Step four: profit

Chill, x.
Title: Re: Objects
Post by: Gan on January 23, 2011, 09:52:45 PM
@WarHampster,(unrelated question) by any chance have you read this article? http://arstechnica.com/science/news/2011/01/this-space-left-blank-the-role-of-placeholders-in-science.ars

@X, In my last 2 posts I was defining a real world object. Not a C or other programming language object.
I was trying to say that an object is something with physical attributes. I.E. a cube that's red, ect, ect.
The reason I named this code an object is because it relates with what a beginner programmer knows. Objects in the real world. See where I'm coming at?
Title: Re: Objects
Post by: WarHampster on January 23, 2011, 10:12:06 PM
Gan - I hadn't, but I have now. Very cool stuff. I love how they described Bohr's use of neutrinos as a "hack."

Also, x, SC calls its functions "methods," which they are technically not because they do not belong to classes.
Title: Re: Objects
Post by: x on January 24, 2011, 04:28:10 AM
Quote
Gan - I hadn't, but I have now. Very cool stuff. I love how they described Bohr's use of neutrinos as a "hack."

Also, x, SC calls its functions "methods," which they are technically not because they do not belong to classes.
The method thing is a bit iffy too. But my problem is not with syntax, its with semantics, plus thats not what this thread is about. Also I was wise (not really) and more-so cynical (not too mention opinionated!) at least a year or two before my year long exodus, so your argument and humorous 4chan culture reference is invalid. (http://www.thebuzzmedia.com/wp-content/uploads/2008/05/my-hair-is-a-bird-argument-invalid.jpg)

@Matt: I was never saying it had anything to do with C programming. Objects are found in more than just C oriented languages, in fact OOP is pretty much ubiquitous. You claim that you are trying to make it easy for beginners by calling it and object, in my opinion thats exactly the kind of confusing cr*p that puts intermediate programmers off learning new languages, or starts bad habits. Call it what you want, but don't claim its an object. This is NOT OOP. Whats the problem with calling it a structure, which is what it actually is... Besides it makes just as much sense to call a cube a structure.

Don't take any of this personally, I just hate things that are mislabeled.
Title: Re: Objects
Post by: Silverwind on January 24, 2011, 07:10:50 AM
An object, such as a weapon, a dragon or a castle, is a thing with characteristics, such as size, shape, colour etc. Therefore I doubt the name "object" will confuse anyone when used to refer to the collective group of variables that represent the object.
Title: Re: Objects
Post by: x on January 24, 2011, 07:13:01 AM
Quote
An object, such as a weapon, a dragon or a castle, is a thing with characteristics, such as size, shape, colour etc. Therefore, I doubt there'll be any confusion in referring to the collective group of variables which represent an object's characteristics as an "object".

check out struct: http://en.wikipedia.org/wiki/Struct_(C_programming_language)
Is that not exactly what this is?

My point was that there WILL be confusion when someone goes to learn a proper OOP language and sees objects, then they don't work at ALL the way they learnt them. A "struct" is the programming paradigm which has been created/described here, is a castle not a structure as much as its an object? Wouldn't it make sense to name this using the correct programming paradigm?


Which I have already said before.

Please read my posts before you criticize me for a moot point.  :P
Title: Re: Objects
Post by: Silverwind on January 24, 2011, 07:23:07 AM
I can only speak for myself, Gnome and Eq, but none of us were very surprised to learn that our simplistic card based development systems used dumbed down commands and features from the high level languages they were built in, whilst retaining the names they were based on.

I've never met a kid with a cork-pop riffle who couldn't understand why people referred to it as a gun, when clearly it was a toy. In the same way, this list of variables represents an object, thus the naturally obvious thing to name it is an object.
Title: Re: Objects
Post by: x on January 24, 2011, 07:25:09 AM
Quote
I can only speak for myself, Gnome and Eq, but none of us were very surprised to learn that our simplistic card based development systems used dumbed down commands and features from the high level languages they were built in, whilst retaining the names they were based on.

I've never met a kid with a cork-pop riffle who couldn't understand why people referred to it as a gun, when clearly it was a toy. In the same way, this list of variables represents an object.


AHHH SYNTACTICAL ERRORS EVERYWHERE.. CANT... FUNCTION... NEED... CORRECT... TERMINOLOGY.....

Sorry for being so unnecessarily anal, but this mimics the functionality of a struct not an object! Which was my point by the way. I wish to clarify that my problem is not that this doesn't have advanced OOP features.
Title: Re: Objects
Post by: Silverwind on January 24, 2011, 07:32:34 AM
Quote
is a castle not a structure as much as its an object? Wouldn't it make sense to name this using the correct programming paradigm?
Clearly to you it would, as you think it would be sensible if the term was correct with other languages, but I think it would be more sensible if the term was immediately understandable, and I think object is considerably more obvious than struct.

Nobody's wrong here, there's just a disagreement on what's sensible.

Quote
Please read my posts before you criticize me for a moot point.  :P
I don't mean to criticize you, and I did read your posts.
Title: Re: Objects
Post by: x on January 24, 2011, 07:34:54 AM
Quote
Clearly to you it would, as you think it would be sensible if the term was correct with other languages, but I think it would be more sensible if the term was immediately understandable, and I think object is considerably more obvious than struct.

Nobody's wrong here, there's just a disagreement on what's sensible.

I don't mean to criticize you, and I did read your posts.

Well if we're going to call it an object, we not take my aforementioned advice and allow methods and data hiding so it actually IS syntactically correct fake OOP?
Title: Re: Objects
Post by: Silverwind on January 24, 2011, 07:35:56 AM
x, it is you that doesn't understand! ;D I'm talking about real objects, not the programming sense of the word. I'm talking the chair your sitting on, the glass of milk you're sipping, and the clock that's just made me aware of how late I am! Fare thee well!
Title: Re: Objects
Post by: x on January 24, 2011, 07:37:32 AM
I agree, no-one is wrong, we're just arguing semantics I guess.

Quote
x, it is you that doesn't understand! ;D I'm talking about real objects, not the programming sense of the word. I'm talking the chair your sitting on, the glass of milk you're sipping, and the clock that's just made me aware of how late I am! Fare thee well!

I know that! I'm just saying that seems silly too me since these things are also structures are they not? So we may as well use the correct programming term! Although the term object does make a little more sense to be fair, I just can't stand incorrect terminology, which is a fairly odd character flaw I must admit. And good day too you sir, sleep well and try not too lucid dream, I hear its very tiring  ;)
Title: Re: Objects
Post by: Tireas Dragon on January 24, 2011, 10:11:12 AM
I think I understand what the argument is. Silverwind is programming the chair by saying their is a chair there and it has these features. x is arguing that the chair is an object with these chair features like all other chairs in the chair object.
Title: Re: Objects
Post by: Gan on January 24, 2011, 12:49:10 PM
If it helps, I just realized you can put artificial objects inside artificial objects.

I should probably make an example game that uses this.
Title: Re: Objects
Post by: x on January 24, 2011, 06:39:37 PM
Quote
I think I understand what the argument is. Silverwind is programming the chair by saying their is a chair there and it has these features. x is arguing that the chair is an object with these chair features like all other chairs in the chair object.

Not even close haha.

@Gandalf: Yeh, pretty cool right? I posted about that before, it means 2d arrays are possible, which might make a grid system more elegant.
Title: Re: Objects
Post by: WarHampster on January 24, 2011, 07:20:40 PM
Quote
I think I understand what the argument is. Silverwind is programming the chair by saying their is a chair there and it has these features. x is arguing that the chair is an object with these chair features like all other chairs in the chair object.


THE ARGUMENT: Chairs are things with chair-like properties that are shared by all other chairs within a chair, recursing to infinity.

8)
Title: Re: Objects
Post by: x on January 24, 2011, 07:24:19 PM
Quote


THE ARGUMENT: Chairs are things with chair-like properties that are shared by all other chairs within a chair, recursing to infinity.

8)

Which then causes a stack overflow crashing GMG.
Title: Re: Objects
Post by: Gan on January 24, 2011, 08:26:40 PM
And my brain.
Title: Re: Objects
Post by: GMG Kurt on September 04, 2011, 04:30:18 PM
Quote
I agree, no-one is wrong, we're just arguing semantics I guess.


I know that! I'm just saying that seems silly too me since these things are also structures are they not? So we may as well use the correct programming term! Although the term object does make a little more sense to be fair, I just can't stand incorrect terminology, which is a fairly odd character flaw I must admit. And good day too you sir, sleep well and try not too lucid dream, I hear its very tiring  ;)

I would like to point out that in C++ both structs and classes are exactly the same. class is just a C++ struct in which the default access to it's variables is private instead of public, like a struct.

Class is just formally used for objects that'll take into consideration encapsulation, polymorphism, abstraction, and hierarchy.

and although the C++ struct can hold functions, in good programming practice it doesn't. That is left to objects, because of practice, and the added functionally of the copy-constructor, printing constructor, and all the rest.
Title: Re: Objects
Post by: x on September 04, 2011, 11:15:26 PM
Quote

I would like to point out that in C++ both structs and classes are exactly the same. class is just a C++ struct in which the default access to it's variables is private instead of public, like a struct.

Class is just formally used for objects that'll take into consideration encapsulation, polymorphism, abstraction, and hierarchy.

and although the C++ struct can hold functions, in good programming practice it doesn't. That is left to objects, because of practice, and the added functionally of the copy-constructor, printing constructor, and all the rest.

You assumed that an object is a data type that holds both data and functions. Thats a common incorrect assumption. The definition of an object is something that is capable of data hiding, polymorphism and inheritance. Thats the important difference between a struct and a class.

Otherwise whats the point of C++? Since C has structs...

Edit: Nice grave digging.
Title: Re: Objects
Post by: GMG Kurt on September 05, 2011, 05:49:27 PM
Quote

You assumed that an object is a data type that holds both data and functions. Thats a common incorrect assumption. The definition of an object is something that is capable of data hiding, polymorphism and inheritance. Thats the important difference between a struct and a class.

Otherwise whats the point of C++? Since C has structs...

Edit: Nice grave digging.
thanks ;) grave digging is my specialty

a C++ struct is way different than a C struct. It has added functionalities.
You just compared a C struct to a C++ class.
I was comparing C++ struct to a C++ class
Title: Re: Objects
Post by: x on September 07, 2011, 01:13:40 AM
Quote
thanks ;) grave digging is my specialty

a C++ struct is way different than a C struct. It has added functionalities.
You just compared a C struct to a C++ class.
I was comparing C++ struct to a C++ class

Well thats an annoying and pointless comparison. Lets compare a sea with an ocean while we're at it, thats just as frustratingly niggly and irrelevant.

If you look at the ASM generated, a struct and a class in C++ is the same thing from a machines point of view.
Title: Re: Objects
Post by: Gan on September 07, 2011, 08:37:14 AM
Wait, what's the difference between a sea and an ocean?
Title: Re: Objects
Post by: GMG Kurt on September 07, 2011, 12:53:01 PM
Quote

Well thats an annoying and pointless comparison. Lets compare a sea with an ocean while we're at it, thats just as frustratingly niggly and irrelevant.

If you look at the ASM generated, a struct and a class in C++ is the same thing from a machines point of view.


The comparison was meant to show that structures, and objects are so closely related. That determining a difference is impossible. The only way to distinguish is the declaration, and usage. not very 'niggly' now is it.  8)

P.S. aren't sea and ocean the same thing? Except that most (comparably) smaller bodies of water are seas.
Title: Re: Objects
Post by: x on September 08, 2011, 12:42:40 AM
Quote


The comparison was meant to show that structures, and objects are so closely related. That determining a difference is impossible. The only way to distinguish is the declaration, and usage. not very 'niggly' now is it.  8)

P.S. aren't sea and ocean the same thing? Except that most (comparably) smaller bodies of water are seas.


A sea is enclosed by land or something, I think.

Anyways thats my point - who cares? Structures in C++ aren't truly structures, they were just put there so C code is compatible with C++. The difference between a structure and an object is the difference between procedural programming and OOP, blur that line at your own risk.
Title: Re: Objects
Post by: GMG Kurt on September 08, 2011, 03:03:26 PM
oh I see we're on the same side  ;D
Title: Re: Objects
Post by: x on September 09, 2011, 06:24:04 AM
Quote
oh I see we're on the same side  ;D

Friendly fire....  :P
Title: Re: Objects
Post by: GMG Kurt on September 09, 2011, 10:21:51 PM
lol I almost forgot that phrase  ;D I've only ever heard it in video games
Title: Re: Objects
Post by: Gan on September 10, 2011, 04:00:09 AM
Yeah, it's a lot of fun. First time I ever played Halo I did it a lot.
Saw something move, trigger the rocket launcher!