Simple C++ Questinon

[Mattz]

for me it's:
CODE


SDL_Surface* Surface




as I see the type as two things, the pointer version of the type and the normal version of the type.

 

[dflemstr]

for me it's:
CODE

SDL_Surface* Surface




as I see the type as two things, the pointer version of the type and the normal version of the type.
I don't want to discuss this
But the typcial example is the following:
CODE

int* x, y, z;

What type is y and z? you think it is int*? No, it's int. The * belongs to the variable, not the type.
EDIT: there was a whole thread about this a while ago, search the forums.

I'm interested in doing some Pandora developing but I want to check out the device first before I start anything. I've currently done some Java and C# programming, but since both are reference-based, I'm a bit rusty when it comes to explicitly separating objects and pointers.

I'm actually making a game myself in Scala (which compiles to Java bytecode, so I could do it in Java), with lwjgl and jBullet. It's not a problem if you want to use Java on the Pandora; it works. I'll open-source my code when I've got it a little more structured, if you need inspiration (but my Scala code can become pretty unreadable at times )

 

[Exophase]

EDIT: there was a whole thread about this a while ago, search the forums.

Not to mention that I already said what you said in your post, in this thread :/

 

[dflemstr]

Not to mention that I already said what you said in your post, in this thread :/


Hmm, oops...
I should pay more attention when posting, and read through the thread first, eh?

 

[Kramy]

Since it's a pointer, it doesn't make any sense to say, "optimizedImage.format" because optimizedImage is just a number.

Actually, it does make sense. A pointer is just a pointer(usually a 32bit integer) - it has no methods or other data contained within, so logically anything accessed with a '.' would be from the object it's pointing to.

Java made this leap, and simplified "->" into "." as do most (all?) scripting languages.

But I've learned that in C/C++, if they can use more symbols rather than less, they do. That's my only beef with the language.

 

[dflemstr]

But I've learned that in C/C++, if they can use more symbols rather than less, they do. That's my only beef with the language.

C isn't constructed in a way that 'makes sense' to us humans, but in a way that makes sense to the CPU. In machine code, "->" and "." are two very different operations(the first is usually 2 operations, actually). If C would have simplified "->" into "." as you say, then what happens when you don't have a pointer, but you have a variable that IS the object/struct itself? How would you access it's members then? etc...

I watched a great video about all this once, I think it was from Stanford somewhere on this youtube playlist:
CODE
http://www.youtube.com/view_play_list?p=FE6E58F856038C69

...and that link is a very good source for learning C++ by the way, so you have nothing to lose following it anyways (it's free university lectures! Online tutorials can't become better than this )

Hm and btw don't treat me like I know alot about C/C++, those languages are not my 'primary' languages; I focus more on Java/Scala at the moment.

EDIT: Spelling fixes. I should really sleep now.

 

[bencoder]

then what happens when you don't have a pointer, but you have a variable that IS the object/struct itself? How would you access it's members then? etc...

the compiler can look at the type of the object and put in the correct machine code instruction equivalent, of course. Or you could have all objects as references, like most sensible languages.

 

[Exophase]

then what happens when you don't have a pointer, but you have a variable that IS the object/struct itself? How would you access it's members then? etc...

the compiler can look at the type of the object and put in the correct machine code instruction equivalent, of course. Or you could have all objects as references, like most sensible languages.


All objects as references means all objects are heap allocated, which doesn't fit with C/C++'s memory allocation model.

 

[dflemstr]

the compiler can look at the type of the object and put in the correct machine code instruction equivalent, of course. Or you could have all objects as references, like most sensible languages.

All objects as references means all objects are heap allocated, which doesn't fit with C/C++'s memory allocation model.
@bencoder And if the compiler would 'hide' the difference between reference variables and direct access variables behind the scenes, then you lose some control over the memory management that is needed sometimes in C. Remember: In C++, there's no real difference between an int and, say, a class with 4 byte-sized members. To the compiler, a pointer is just yet another number; everything is just a stack of bytes. C++ is very down-to-the-hardware, and simplifications like you describe them would not be possible.

 

[Squidge]

If you don't like pointers to structures, you can always use references to obtain the same effect:

CODE

typedef struct
{
int a,b,c;
int res;
} fooble;

void adds (fooble f)
{
f.res = f.a+f.b+f.c;
}

void addp (fooble *f)
{
f->res = f->a + f->b + f->c;
}

void addr (fooble &f)
{
f.res = f.a + f.b + f.c;
}

int main(int argc, char* argv[])
{
fooble k1 = {1,2,3,99};
fooble k2 = {1,2,3,99};
fooble k3 = {1,2,3,99};

adds(k1), addp(&k2), addr(k3);
printf ("%d %d %d\n", k1.res, k2.res, k3.res);

return 0;
}



CODE

$ a.out
99 6 6

 

[Mithrildor]

Can anyone explain me what Operator Overloading is? Im stuck in a tutorial because I dont know what Operator Overloading is and I cant get the hang of how the tutorial explains it to me, now after google searches I still dont get it.

 

[PokeParadox]

Can anyone explain me what Operator Overloading is? Im stuck in a tutorial because I dont know what Operator Overloading is and I cant get the hang of how the tutorial explains it to me, now after google searches I still dont get it.


It's basically providing your own functions for standard operators (+, -, /,*,+=)

When you are writing a class, you might want to tell the compiler how it might go about adding two of your class objects together. For argument's sake we'll say this is a vector class...
CODE

MyClass MyClass:perator+(MyClass c)
{
x += c.x;
y += c.y;
z += c.z;
return *this;
}

Now you have setup the operator you can easily add this Vector to another one:
CODE

MyClass a(1,2,3);
MyClass b(1,1,1);
MyClass c(0,0,0);

c = a + b;


the instance c will have a value of 2,3,4 for x,y,z respectively.

 

[Mithrildor]

Thanks I get it now

 

[Xmas]

CODE

MyClass MyClass:perator+(MyClass c)
{
x += c.x;
y += c.y;
z += c.z;
return *this;
}

That's not a good example for operator overloading, though, because it doesn't do what the user expects from an operator+.

 

[dflemstr]

That's not a good example for operator overloading, though, because it doesn't do what the user expects from an operator+.

Yeah, it modifies the original class... So avoid that particular code. Everyone got the idea, though, most probably.

 

[PokeParadox]

CODE

MyClass MyClass:perator+(MyClass c)
{
x += c.x;
y += c.y;
z += c.z;
return *this;
}

That's not a good example for operator overloading, though, because it doesn't do what the user expects from an operator+.

Yeah... wasn't well thought out, was just very quick to give an idea.

 

[Kramy]

@bencoder And if the compiler would 'hide' the difference between reference variables and direct access variables behind the scenes, then you lose some control over the memory management that is needed sometimes in C. Remember: In C++, there's no real difference between an int and, say, a class with 4 byte-sized members. To the compiler, a pointer is just yet another number; everything is just a stack of bytes. C++ is very down-to-the-hardware, and simplifications like you describe them would not be possible.

How would you lose control? It could transparently support both.

This isn't the most complex thing for a compiler to figure out. It's more than doable to check if something is a pointer and replace a period with a '->'

C/C++ favour complexity to humans when there's no valid reason for it, because a compiler/computer can figure it out just fine. I write it off to the choices of C/C++'s creators.

I'll check out those Youtube vids.

 

[lulzfish]

You make a good point:
The "." operator has no valid meaning for a pointer,
and the "->" operator has no valid meaning for a non-pointer,

but I think the idea is that pointers are identical to integer variables, and they want there to be a clear distinction between accessing a member and dereferencing a pointer, then accessing a member.

 

[Jan-Nik]

Think of Smart Pointers like boost::shared_ptr. There the "." operator has a meaning.

 

[lulzfish]

"Think of Smart Pointers"

I try not to. I don't even know what those are for.