Thread: Location of the dereference operator

  1. #1
    Registered User
    Join Date
    Nov 2008
    Posts
    6

    Location of the dereference operator

    Apparently this code works:
    Code:
    char* temp = ((ada+ind)->text);
    process(ada+ind, &temp);
    While this code doesn't:

    Code:
    char** temp = &((ada+ind)->text);
    process(ada+ind, temp);
    Does anyone have any idea why this is true? I made it work by changing it to the first way, but I really don't understand what is going on here.

    In case anyone is curious, this is part of an assignment to write a MIPS simulator. ada is a struct that contains some primitives and char text[40].
    The variable "ind" is an integer quantity. I discovered this peculiar problem when I tried to combine the two lines of code into one line and it didn't work.
    Last edited by merlin2011; 11-13-2008 at 02:10 AM.

  2. #2
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    The top one is taking the address of a variable called temp, allowing process to change what temp points to.
    The bottom one is taking the address of the text variable at position ind in the array ada, allowing process to modify what that text variable points to. Presumably modifying that turns out to be a bad thing for your program.

    These two could instead be written as:
    Code:
    char* temp = ada[ind].text;
    process(ada+ind, &temp);
    
    process(ada+ind, &ada[ind].text);
    Which I believe more clearly hilights what each it doing.
    Last edited by iMalc; 11-13-2008 at 02:27 AM.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  3. #3
    Registered User
    Join Date
    Nov 2008
    Posts
    6
    I'm a little bit confused. My understanding is that
    Code:
    char* temp = ada[ind].text;
    causes temp to point at the same thing text is pointing to.
    Doesn't that mean I'm modifying what text is pointing to in either case?

    Incidentally, that IS the intent of process - to put something useful into the char array that text is pointing to.

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    So perhaps you should post the code of "process", since it may be important to understand what it actually does.

    Also the initialization of the ada.text fields would be helpfull.

    Finally, what actually happens, and how is that different from what you expect?

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by merlin2011 View Post
    I'm a little bit confused. My understanding is that
    Code:
    char* temp = ada[ind].text;
    causes temp to point at the same thing text is pointing to.
    Doesn't that mean I'm modifying what text is pointing to in either case?
    Yes, but that's what your code always has been doing, just with a slightly different code. But nevertheless the same.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    Yes, but that's what your code always has been doing, just with a slightly different code. But nevertheless the same.
    I'm not quite convinced what you mean, but I'd say that "slightly different location" is a better statement than "slightly different code".

    If we take the two first code-segments, and rewrite them to be more clear:
    Code:
    char* temp = ((ada+ind)->text);
    char **ptemp = &temp;
    process(ada+ind, ptemp);
    ptemp points to the address of the temp variable, which holds a COPY of text. Changing *ptemp will change the value of temp, but not the value of text.

    Code:
    char** temp = &((ada+ind)->text);
    process(ada+ind, temp);
    temp points to the address of text. Modifying *temp will change the value of text.

    --
    Mats
    Last edited by matsp; 11-13-2008 at 07:28 AM.
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    This...
    Code:
    char* temp = ((ada+ind)->text);
    process(ada+ind, &temp);
    ...is the same as...
    Code:
    char* temp = ada[ind].text;
    process(ada+ind, &temp);
    ...which is the same as...
    process(ada+ind, &ada[ind].text);
    The first two are the same, yes, the third one doesn't pass the address of temp, but rather the address of text - which is different.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  8. #8
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    This...
    Code:
    char* temp = ((ada+ind)->text);
    process(ada+ind, &temp);
    ...is the same as...
    Code:
    char* temp = ada[ind].text;
    process(ada+ind, &temp);
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #9
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Agreed.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  10. #10
    Registered User
    Join Date
    Nov 2008
    Posts
    6
    First of all, the declaration of the struct.
    Code:
    typedef struct instruction{
    char opcode, rt, rs, rd, sa;
    short int immed;
    unsigned int target;
    char* label;
    char text[40];
    }
    inst;
    Declaration for ada
    Code:
    inst ada[2000];
    Note that ada is statically initialized in the header, not in a method.

    The process method just has a bunch of statements like the following (more than I'd care to list)
    Code:
    void process (char ** text){
    strcpy(*text, "blah blah");
    strcat(*text, "some value");
    strcat(*text, "more value");
    }
    Hope that helps.

  11. #11
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Ok, so first question is why you need to pass the address of a pointer in the first place - if the code is as you describe, then you only need the address of the char array itself, not the address of an address of it.

    Secondly, using & on the text field in that structure doesn't work as you'd expect it to - it still gives you the address of the char array, not the address of a pointer to it.

    Code:
    #include <stdio.h>
    
    int main() 
    {
      struct A
      {
        char text[100];
      } a;
      char *temp;
    
      temp = a.txt;
      printf("&a.text = %p, a.text = %p\n", &a.text, a.text);
      printf("&temp = %p, temp = %p\n", &temp, temp);
      return;
    }
    Try this on your machine, and you'll see that both are the same thing in the first line of output, but not in the second row.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  12. #12
    Registered User
    Join Date
    Nov 2008
    Posts
    6
    I think the last point was what I didn't realize, but suspected was true. I have no idea why the "address of" operator doesn't work on the name of an array, but I guess that's just the way it is.
    Thanks everyone who replied. Your comments helped me better understand.

    As to why I was passing the address of the pointer, that was because the previous version of my code was using dynamic memory allocation instead of static. For this, I needed to modify the pointer "text" to point at new memory I was allocating. That is, my struct held char* text, instead of char text[40].
    Of course you're right though, as my code currently stands, I can just pass the address of the array, and use that directly, since it is now a static value.
    Thanks again for everyone's help!

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Failure to overload operator delete
    By Elysia in forum C++ Programming
    Replies: 16
    Last Post: 07-10-2008, 01:23 PM
  2. Smart pointer class
    By Elysia in forum C++ Programming
    Replies: 63
    Last Post: 11-03-2007, 07:05 AM
  3. Screwy Linker Error - VC2005
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 06-19-2007, 02:39 PM
  4. Operator Overloading (Bug, or error in code?)
    By QuietWhistler in forum C++ Programming
    Replies: 2
    Last Post: 01-25-2006, 08:38 AM
  5. operator overloading and dynamic memory program
    By jlmac2001 in forum C++ Programming
    Replies: 3
    Last Post: 04-06-2003, 11:51 PM

Tags for this Thread