Re: REFERENCES REVEALED

From: Old Wolf (oldwolf_at_inspire.net.nz)
Date: 06/01/04 

Date: 1 Jun 2004 14:42:44 -0700

JKop <NULL@NULL.NULL> wrote:

>I finally understand reference variables perfectly!! It's the way that they
>were described to me that had me all confused. The books I've learned from
>have never just stated plainly:

>A reference variable is just a pointer variable.

I should hope not, since they would be wrong.
Look man, several people with many years of practical C++ experience
have told you that you are wrong. Maybe you should start listening to them?

> struct Jeep
> {
> std::Vector& a;
> std::Vector& b;
> };
>
> int main(void)
> {
> Vector j;
> Vector k;
>
> Jeep jeep = {j, k};
> }

> Then explain the above. If it's just another name for a variable, then what
> the hell are a and b ?

'a' and 'b' are other names for variables, as you say.

If you consider this slightly modified (and compilable) example:

struct Jeep
{
    std::vector<int> &a;
    Jeep(std::vector &a_): a(a_) {}
};

int main()
{
    std::vector<int> v;
    Jeep j(v);

    j.a.push_back(10);
    v.push_back(12);
}

"j.a" and "v" mean exactly the same thing. If you picture the memory
location of the vector in your mind, think of it as having two labels
"j.a" and "v". These two terms are completely interchangeable, in
any expression. If you think about it for a moment, you would realise
that the same is not true of pointers.

>
> Pointers is what they are, and on a 32-Bit Memory Model platform, sizeof
> (Jeep) will be 64 Bits, which proves my point.

It would be difficult for the compiler to maintain a list of which
label refers to which object, by any means other than storing the
address of that object with that label. Implementations use addresses
internally when remembering what references are bound to.

Implementation details do not "prove your point". (On one of my
systems, sizeof(int) is 2. Does this prove that ints have 16 bits?)

It's good that you have something in mind that gives you a better
handle on references. But you should bear in mind that this is
an imperfect description, and you will become confused in future
when you encounter problems with it. For example, as you pointed
out yourself,

  int Monkey() { return 42; }
  int main()
  {
    int const &k = Monkey();
    std::cout << k << std::endl;
    return 0;
  }

How would you write that with const pointers? What is &k?

It's like the "dump-truck" analogy for electricity (each electron is
loaded up with power, and as it passes through the bulb, it dumps all
its power so the bulb glows). Seems like a good idea, but is actually
totally wrong, and worse than useless.

Relevant Pages

  • Re: bad_alloc in new
    ... int* p = newint; ... and allocation fails, new will return NULL which will too be stored in p. ... new itself doesn't change any pointers (whether it succeeds or ... Never mind. ...
    (microsoft.public.vc.language)
  • Re: A taxonomy of types
    ... I am describing how to represent the representation (and, ... if the system follows static typing rules (such as in a compiler), ... so, the hardware sees pointers and pointer arithmetic, but the compiler ... "Besides the char types, up to three sizes of integer, declared short int, ...
    (comp.lang.misc)
  • Re: A Disassembly Problem for Rene to Consider
    ... What happens if the table isn't a simple table of pointers to code, ... > on the fly and the new gotten branch label ... In particular, the disassembler cannot determine ... you run into the halting theorem. ...
    (alt.lang.asm)
  • Re: Malloc code
    ... int xxx; ... As for not using the void pointer, I will have to do some further testing ... I just needed some insight on passing arrays of pointers. ... struct MCB *r1; ...
    (microsoft.public.vc.language)
  • I want my segmentation fault!
    ... no occurrences of free and a lot of routines returning pointers to ... the pointer returned by the allocator (either directly or as a component ... int length_of_list; ...
    (comp.lang.c.moderated)