Structure pass-by-reference - help?

**quzah** · 08-20-2005

Well since you re-edited this agin, I'll re-post my earlier post:

Originally Posted by Tonto

Okay. I was also interested in this, so I did a little debugging.

Code:

void a(int& x) { x += 2; }
int main() { int b = 2; a(b); }

This isn't valid C. It's C++. So while your compiler (C++) may treat them the same, it doesn't really matter, because it's not C.

Quzah.

**valis** · 08-20-2005

It's the same argument as saying pointers and arrays are the same thing

Well, they are almost functionally the same, you either have an address into the heap which the cpu converts to a physical address, or an offset into the stack with esp or ebp, they are both just addresses.
So depending on how you look at it they are the same, then again, your going to overflow if you try to make an array with 1024*1024*16 elements. In fact, if you really want to get technical, all variables are the same, nothing is stopping you from moving 32 bits of data into the address your char resides at (of course you will spill into your other locals), and nothing is stopping you from storing a horribly inprecise float into a byte. Then again, you'll likely have horribly unaligned data. MMX is a good example of the fact it's just addresses and interpretation.

**quzah** · 08-20-2005

Originally Posted by valis

Well, they are almost functionally the same, you either have an address into the heap which the cpu converts to a physical address, or an offset into the stack with esp or ebp, they are both just addresses.
So depending on how you look at it they are the same, then again, your going to overflow if you try to make an array with 1024*1024*16 elements. In fact, if you really want to get technical, all variables are the same, nothing is stopping you from moving 32 bits of data into the address your char resides at (of course you will spill into your other locals), and nothing is stopping you from storing a horribly inprecise float into a byte. Then again, you'll likely have horribly unaligned data. MMX is a good example of the fact it's just addresses and interpretation.

Some one needs to go read the FAQ.

Quzah.

**Prelude** · 08-20-2005

>they are both just addresses
*sigh* Okay, let's just say that everything is the same because it's all binary. Hell, if you have to go down to the implementation (which varies) and then the hardware (which also varies) in a futile attempt to win an argument, we might as well go for broke, right?

You can post assembly. You can talk about memory and addresses until you're blue in the face. But in the end, you're wrong. Oh wait, you're not entirely wrong because you used "almost" to cover your ass.

**Tonto** · 08-20-2005

>> So my findings conclude they are exactly the same. (Myself)

That was a premature statement to make on my part, and hardly researched. Pre-mature "findings".

>> It's the same argument as saying pointers and arrays are the same thing (Salem)

Although (I think) I see you are saying, it seems somewhat irrelevent. The issue in that case is that if you were to just pass the **pointer than the compiler would have no idea how to handle something like point[5][0] because it really doesn't know where the hell "5" should offset to.

>> This isn't valid C. It's C++. So while your compiler (C++) may treat them the same, it doesn't really matter, because it's not C. (quzah)

Yeah, I know, it's been said pass-by-reference isn't valid C. So technically this should be in the C++ section. But it isn't.

Okay, so, from what I saw, passing "by reference" always results in a "reference", which is a pointer to the data to the data being passed, being passed to the function. Then, it is dereferenced ([someregister]) in order to be used, just like as if I had said:

Code:

int func(int* passedData) { *passedData = 5; }

Even though on a higher level, in the real code, I just said:

Code:

int func(int& passedData) { passedData = 5 }

A reference is just a pointer to the data being passed. A function parameter in C, like an int*, is used to dereference the "reference" passed to it. In C++ pass-by-reference however, it just allows you to use the variable like a normal one, and the dereferencing is done at compilation.

>> Oh wait, you're not entirely wrong because you used "almost" to cover your ass.

I do a lot of that

**orbitz** · 08-20-2005

So, my findings conclude that they are exactly the same

Your conclusions are based on insatisfactory data. For starters, the C standard does not define any assembly instructions or opcodes, so your disassemblies have no bearing on the semantics of the language. Secondly, How your compiler implements a language feature is irrelevant to the features of the language. If your compiler implements arrays in terms of pointers are you now in a position to state arrays are pointers? Of course not, the semantics are different and that is what is being argued here. Finally, one specific instance of a compiler on one specific instance of a processor is certinaly not statistically enough to justify any sort of formal generalization. Certinaly other compilers exist and so do other processors. Please do not let limited usage of the language define the rest of the worlds implementations.

**Prelude** · 08-20-2005

>A reference is just a pointer to the data being passed.
Kinda sorta, but not really. That may be how a C++ implementation treats it, but on a level that's more useful to us, saying that they're the same is akin to saying that pointers and arrays are the same. It's a fundamental misunderstanding of the language concepts, and that makes life harder.

>I do a lot of that
I'm a fan of "typically" and "generally", myself.

**Tonto** · 08-20-2005

>> It's a fundamental misunderstanding of the language concepts

I think I have one of those. Google results don't give me many results in comparison to the arrays vs. pointers argument, where there are resources aplenty. It's making life harder.

>> Of course not, the semantics are different and that is what is being argued here.

Righto. Would anyone mind putting in a sentence or two on the difference between:

Code:

void foo(int& bar) { bar = 5; }
void foo(int* bar) { *bar = 5; }

Because what appears to happen in the pass-by-reference case is the address of whatever is being passed, is passed, just as if I had used the '&' operator, which is not different from what we do in the second case in C.

**Thantos** · 08-20-2005

Tonto please understand that the people that are correcting you live (and sometimes breath) the C programming language. They have learned from multiple sources and have many years of experience under their belts. They are harsh because this isn't the first time this subject has come up on this board and its quite annoying to have to rehash the same arguements again and again.

My suggestion is to read some more books. Using only one source for your knowledge is a recipe for failure. I also suggest that before you start arguing with a member of this board that have been here for over 4 years and have over 5000 posts, you do a little research; you might be surprised to find they are correct.

**Tonto** · 08-20-2005

Okay, sorry, I did a board search and found this more quckly than I should have: http://www.parashift.com/c++-faq-lite/references.html

Originally Posted by it

OK. That's how you should think of references as a programmer. Now, at the risk of confusing you by giving you a different perspective, here's how references are implemented. Underneath it all, a reference i to object x is typically the machine address of the object x. But when the programmer says i++, the compiler generates code that increments x. In particular, the address bits that the compiler uses to find x are not changed. A C programmer will think of this as if you used the C style pass-by-pointer, with the syntactic variant of (1) moving the & from the caller into the callee, and (2) eliminating the *s. In other words, a C programmer will think of i as a macro for (*p), where p is a pointer to x (e.g., the compiler automatically dereferences the underlying pointer; i++ is changed to (*p)++; i = 7 is automatically changed to *p = 7).

That's all I really needed to know. References are something to make it "easier", so you don't have to dereference the pointer all the time from a pass-by-pointer case, I kept thinking there was something more complex to it than that. But that would seem to mean that what Salem said earlier isn't correct, but I don't want to take an authoritive or inflammitory stance on any of this really =/

Edit to smite me specifically:

Originally Posted by it again

Important note: Even though a reference is often implemented using an address in the underlying assembly language, please do not think of a reference as a funny looking pointer to an object. A reference is the object. It is not a pointer to the object, nor a copy of the object. It is the object.

**orbitz** · 08-20-2005

Code:

void foo(int& bar) { bar = 5; }
void foo(int* bar) { *bar = 5; }

In C++, a reference actually references the object, which means operations on the reference are the same as operations on the actual object. For your simple integer this may not seem like a big deal but consider sizeof. If you have a reference to an array then sizeof gives you a useful result. Not so with a pointer. You can also not pass an array to your function which takes a reference to an integer, you can for your pointer since pointers lose information. These differences may not seem like much to most people here, or important but that is really not important. The simple fact is they are different and if we are going to have a discussion about these things then understanding their meanings is important. If one feels we are being too technical, then take a look around, you're asking for help from experienced people on a programing forum, expect us to be technical, it's for your benefit. Rather than argue what we say with heresay and conjecture, accept or, or politly ask a question or for a reference to more information.

**Tonto** · 08-20-2005

>> The simple fact is they are different and if we are going to have a discussion about these things then understanding their meanings is important

Yeah, that was my problem. I had actually made some attempts at finding out about this in the past but I could never get the right google buzzword, pass by reference gets trash results, several other abstractions of that, I couldn't really find anything. So I made a (really poor) attempt to try and figure these things out by looking at how it's compiled to, as this normally helps me to see what is really going on. I think that I misinterpreted my results, but I don't think I was ever trying to be inflammitory or assert authority, merely trying to interpret my results. Indeed, I mix[ed] up language concepts (pointers and references) with what an implementation does with them, and probably pushed this thread in the wrong direction.

Like the FAQ said, imagining it as a macro (what I was thinking) makes everything click, even though it is truely an object itself (what I missed).

**dwks** · 08-20-2005

Okay, back to the original program, which, for reference, was this:

Code:

#include <stdio.h>

struct Common
{
	char *name;
	int age;
};

void pass(struct Common *pPC);

int main(void)
{
	struct Common PC;
	PC.name = "Phil";
	PC.age = 23;

	pass(&PC);

	printf("%s", PC.name);
	printf("%d", PC.age);

	return 0;
}

void pass(struct Common *pPC)
{
	pPC->name = "Dude";
	pPC->age = 24;
}

This:

Code:

struct Common
{
	char *name;
	int age;
};

/* ... */

	struct Common PC;
	PC.name = "Phil";

You probably meant to use strcpy().

**orbitz** · 08-20-2005

Make sure to allocate space if you use strcpy

Thread: Structure pass-by-reference - help?

Thread Tools

Search Thread

Display

Similar Threads

Passing structure by reference or pointer?

Using Vectors. MinGW warning

In over my head

Undefined Reference Compiling Error

Question about OpenGL/Linux