anomalous pointer activity

I have an iterator to a class, a class whose main data structure is just an array. I set the iterator to point to the first element in the array, then i to this:
&(*iter)
where iter is the iterator and *iter will dereference the pointer (returning a const reference to the item its pointing to). However, the address that results when the above is executed is not the address of the first element in the array. Why is this so?

Sample code:

Code:

---

class A {
  int arr*;  // assume space is allocated for this in constructor
  public:
  class Iter{...};
  ...
}

A a;
A::Iter iter = a.begin();  // initializing iter to the first element in arr
&(*iter) // != a.arr

---

using vc6

Okay, the reason that is a problem is because it is wrong. *iter will give you the first class in the array. iter (note that it is not dereferrenced) will give the address of the first class in the array. &iter[0] will do the same thing.

Also:

Code:

---

class A {
  int arr*;  // <- this should be int *arr;
  public:
  class Iter{...}; // this should be class Iter[n], where n is the maximum size.
  ...
}

---

*iter returns a reference to the first element in the array. If I am not mistaken, the address of (&) operator applied to a reference will give you the address the reference is referring to. Therefore, &(*iter) should return the address of the first element in the array. If not, then why.

Have you written code for class Iter? If so, I think the answer lies in the implementation thereof. I've never actually written code for my own iterator classes though so I won't be much help.


In general an iterator is an object that acts like a glorified pointer. It points to nothing until you tell it where to point. begin() is a function commonly used in the implementation of containers, at least in STL, that will return an iterator to the first element of the container, not the first element of an array contained within the container objects. Using STL container classes and iterator classes for those containers goes like this, if I have it right:

Code:

---

class A
{
  public:
    int arr[10];//an array wrapped in a class
    void showFirst();
};

void A::showFirst()
{
  cout << arr[0] << endl;
}

vector <A> vA(5);//a vector of 5 elements of type A
vector <A>::iterator itr;//an iterator to point to elements in a vector containing elements of type A
itr = vA.begin();//assign the address of the first A in vA to itr
itr->showFirst();//using itr to access showFirst();
itr->arr; //using itr to access address of first element in arr in first element of vA.

---

Yep, i wrote the class and the iterator myself. It most likely isnt an implementation problem in iterator since there isnt much implementation to begin with, the code is extremely simple.

No one still has yet to answer the fundamental question, whether &(*iter) should evaluate to the address of the first element in the array. The answer to this question will determine where the problem lies.

Quote:

---

Originally posted by *ClownPimp*
No one still has yet to answer the fundamental question, whether &(*iter) should evaluate to the address of the first element in the array. The answer to this question will determine where the problem lies.

---

Well, I don't know much about iterators, but whatever *iter points to, the & should gets its address. Maybe someone can clarify?

To answer your question as far as I know &(*iter) would give you the first entry. But there, a bit but here, if iterator has an operator for * this would change my answer to no (unless the * operator returns the address). Also, if iterator is a template class the answer could be no. Besides, even if that does what you want that is an ugly way of going about things.

lol, your explanation reminded my of my sig.

It really doesnt matter that much. I needed to do that since I was trying to compare an "Iterator" and a "ConstIterator" and since I cant define an operator to do it, I had to use that workaround to see if they pointed to the same address. Oh well, I found a better way to do what i was trying to do anyway. Thanks anyways for your help.