Structure pass-by-reference - help?

This is a discussion on Structure pass-by-reference - help? within the C Programming forums, part of the General Programming Boards category; Well since you re-edited this agin, I'll re-post my earlier post: Originally Posted by Tonto Okay. I was also interested ...

  1. #16
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Well since you re-edited this agin, I'll re-post my earlier post:
    Quote 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.
    Hope is the first step on the road to disappointment.

  2. #17
    Dump Truck Internet valis's Avatar
    Join Date
    Jul 2005
    Posts
    357
    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.

  3. #18
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Quote 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.
    Hope is the first step on the road to disappointment.

  4. #19
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >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.
    My best code is written with the delete key.

  5. #20
    Registered User Tonto's Avatar
    Join Date
    Jun 2005
    Location
    New York
    Posts
    1,465
    >> 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

  6. #21
    Registered User
    Join Date
    Nov 2002
    Posts
    491
    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.

  7. #22
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >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.
    My best code is written with the delete key.

  8. #23
    Registered User Tonto's Avatar
    Join Date
    Jun 2005
    Location
    New York
    Posts
    1,465
    >> 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.

  9. #24
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    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.

  10. #25
    Registered User Tonto's Avatar
    Join Date
    Jun 2005
    Location
    New York
    Posts
    1,465
    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

    Quote 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:
    Quote 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.
    Last edited by Tonto; 08-20-2005 at 07:18 PM.

  11. #26
    Registered User
    Join Date
    Nov 2002
    Posts
    491
    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.

  12. #27
    Registered User Tonto's Avatar
    Join Date
    Jun 2005
    Location
    New York
    Posts
    1,465
    >> 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).

  13. #28
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    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().
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  14. #29
    Registered User
    Join Date
    Nov 2002
    Posts
    491
    Make sure to allocate space if you use strcpy

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Passing structure by reference or pointer?
    By 7force in forum C Programming
    Replies: 8
    Last Post: 12-13-2010, 06:49 PM
  2. Using Vectors. MinGW warning
    By Viewer in forum C++ Programming
    Replies: 9
    Last Post: 03-26-2009, 04:15 PM
  3. In over my head
    By Shelnutt2 in forum C Programming
    Replies: 1
    Last Post: 07-08-2008, 07:54 PM
  4. Undefined Reference Compiling Error
    By AlakaAlaki in forum C++ Programming
    Replies: 1
    Last Post: 06-27-2008, 12:45 PM
  5. Question about OpenGL/Linux
    By Ideswa in forum Linux Programming
    Replies: 12
    Last Post: 09-10-2006, 06:56 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21