Pointer and reference

Just making sure of pointer and reference usage.

When I dissambled without optimization I got no difference between pointer and reference, since references will be compiled into pointers.

When optimization turned on, it seems those references will be "subtituded" to the original object and sometimes function calls will be inlined due to this subtitution mechanism, otherwise it will stay as pointer.

However even with optimization, exported function both reference return value and reference arguments will be compiled into pointers.

So, technically we may conclude that reference is usually pointer.

Conceptually, references are always valid and pointing to existed object, while pointers might be either valid, NULL or points to yet another uknown things.

But why no reference to static/dynamic arrays?

Why no circular reference?

It seems hard to make Node class with references.

Code:

---

class Node {
  bool empty;
  Node &previous;
  Node &next;
};

---

Quote:

---

Originally Posted by audinue

But why no reference to static/dynamic arrays?

---

Sure you can:

static int x[10];
int (&test)[10] = x;

Quote:

---

Originally Posted by audinue

Why no circular reference?

---

This question doesn't make sense. Technically, there can be no circular references because you cannot assign a reference to a reference, so it will just reference whatever that reference is referencing.

Quote:

---

Originally Posted by audinue

It seems hard to make Node class with references.

Code:

---

class Node {
  bool empty;
  Node &previous;
  Node &next;
};

---

---

Yes, it is, but what is your question?

The Node class with references seems like a bad idea -- that would give you an immutable linked list (no insertions or deletions, since references cannot be made to "point" to different things).

One would even wonder how to set up such a list, since wouldn't all the nodes have to come to existence at the same time? And how would you find the end of the list, seeing as there is no NULL reference?

If references give the compiler more optimization possibilities, it's because they are more restricted than pointers. If they weren't, those optimization possibilities wouldn't be there either.

Edit:
Ok the linked list appears to be possible. There isn't much point in it, though:

Code:

---

#include <iostream>

struct Node
{
    int value;
    Node& prev;
    Node& next;
};

int main()
{
    Node linked_list[3] = {
        {1, linked_list[0], linked_list[1] },
        { 2, linked_list[0], linked_list[2]},
        {3, linked_list[1], linked_list[2]}};

    Node* current = &linked_list[0];
    Node* previous = current;

    do {
        std::cout << current->value << '\n';
        previous = current;
        current = &current->next;
    } while (current != previous);
}

---

Hmmph, I just confused when we pass things as pointer or reference by the context and why we would do that.

Performance consideration maybe?

Quote:

---

Originally Posted by audinue

I just confused when we pass things as pointer or reference by the context and why we would do that.

Performance consideration maybe?

---

A rule of thumb with respect to performance is to avoid passing an object by value if the object is of a class type unless a copy is required. (An exception to this rule is when the object of class type is intended to be cheap to copy, as is the case for iterator types.) Consequently, in such cases you would pass a pointer (to const) or reference (to const) to the object even if you do not intend to modify the object in the function.

Now, to decide which, another rule of thumb is that if the argument could be optional, make the parameter a pointer parameter (so that a null pointer could be passed), otherwise make it a reference parameter.

You who are a C programmer among other things should know - big objects are expensive to copy. As they are in C, as well as C++.

The main problem is the size of objects may be undefined.

Today we might have 4, next week it might be 64, and next year 1024.

Hell yeah, macros done this for us (quick fix).

The next competitive problem is about copying huge datas due to design rules, yeah it passed as const pointer but to modify it you should make a copy then reset. Sounds like file mechanism :D

Nooooo! No macros! Macros are Evil™. Avoid them if you can.
Also, if the size is undefined, you can just pass them by reference to safe-guard yourself. There is another way, but it involves template trickery, which might be a little complex.
And if you need to modify something, pass it as a normal reference! No copying! Why do you need to pass it as const?

LOL, yes, I definetly hate macros since I think it's a cheat to solve problems, but they maybe useful for simple once code generator.

Code:

---

gcc -E generateclass.cppg

---

I already posted something simple, why we should return a const reference in "Tech Board > Best accessor mutator pattern implementation?"

Sorry, no links, kinda lazy copy-and-paste using my phone keypad xP

Quote:

---

The main problem is the size of objects may be undefined.

Today we might have 4, next week it might be 64, and next year 1024.

---

I once tried to use sizeof and templates to decide what to pass by value (anything up to 4 or 8 bytes) and what to pass by reference. Guess what is the sizeof std::string in MinGW's implementation.

Yeah, it's 12 for me, with the real length 1024.

Just thinking about that in xor hashing problem too.

And it was 4 for me (just a pointer to the private implementation, I guess).