Thread: Providing my own simple iterators

Your begin and end functions should return your iterator, not vector's iterator. Although in this example, returning it directly works just fine because all you're doing is creating a wrapper around it.

I felt what you say when I was writting the code. So, if I do only the typedef (notice that I had it in my previous code as a comment), then I am ok (without writing the wrapper), right?

Yes. But again, I don't think it makes sense to "iterate" a point. It would be better to use appropriate names for the member functions that iterate the point (i.e. don't name them begin and end).

Ok, thanks everybody and sorry for my latency to get the idea.

This strikes me as silly.

Can you explain why a Point class would need to contain a vector, and why it would need to permit the caller to iterate over that vector?

By giving your Point class operators that expose iterators that act on the vector, you're exposing the private vector anyway.

Rather than defining an internal class, all your Point class needs to do is expose a few typedefs, such as

Code:

typedef std::vector<double>::iterator PointsIterator;

and a few forwarding functions, such as

Code:

PointsIterator begin() {return v.begin();}

It all still strikes me as being a pointless exercise, and (even if one accepts the premise that it is not pointless) one you've made much more complicated than it needs to be.

Yep. that's what we said above! A typedef, end() and begin() seem to be enough.

The Point has coordinates. Iterator allows the derived class to produce more efficient code, because of some reasons that are out of scope.

(However, I am not arguing that what I do is the best approach, but I have to start from somewhere )

Yeah, but typically one does not iterate coordinates. It's usually bundled in some sort of struct and returned by some function GetCoordinates.

And what GetCoordinates return? Maybe a pointer to the vector of coordinates?

O_o

I knew it.

No more piecewise bull........ std10093, post a complete and meaningful example in pseudocode.

Why pseudocode? Because you aren't C++ well enough to post C++ code.

Soma

Originally Posted by std10093

And what GetCoordinates return? Maybe a pointer to the vector of coordinates?

Code:

struct Coordinates
{
    float x, y, z;
};

class XMyClass
{
    // ...

    Coordinates GetCoordinates() const { return m_Coordinates; }

    // ...

    Coordinates m_Coordinates;
};

As an aside, can we std::move() it, move it?

Code:

struct Coordinates
{
    float x, y, z;
};
 
class XMyClass
{
    // ...
 
    // Is this Kosher?


    Coordinates GetCoordinates() { return std::move(m_Coordinates); }
 
    // Or does return value optimization already kick in here?

    // ...
 
    Coordinates m_Coordinates;
};

Also, a 12 byte structure seems like it'd be awful for alignment, right? Can we just pad our structure with an extra 4 bits for easier alignment in memory? Is this even a thing? I think I read about it but I feel compelled to ask to improve potential performance of the code.

Edit : I'm an idiot. You should never use std::move() in this context because you want to actually keep m_Coordinates in a specific state, duh! But my question should rather be, what if I have a function that takes 3 floats as input and returns a point? Is std::move() okay there? Consider,

Code:

struct point {
    float x, y, z;

   point(float x, float y, float z) {
       this->x = x; this->y = y; this->z = z;
   }
};

point make_point(float x, float y, float z) {

    return std::move(point(x, y, z));
}

This is a poor and trivial example, I do suppose. Hmmm... Maybe constructors just really are the answer... I was just wondering if it's ever okay to use return statements with std::move()...

o_O
Moving an internal variable is wrong, wrong, wrong. By moving it, you saying, "I don't need this anymore, so let the new copy just steal my memory/resources/state." We are returning a copy of it here because we don't want the client to modify the coordinates, let alone destroy them! You should only move temporaries because that's what it's for. Member variables aren't temporaries.
Furthermore, you gain nothing on moving here since it will be the same as a copy. Tell me: how do you implement move semantics on this struct?
Lastly, let the compiler do its job: if it feels like it should pad the structure, then let it do it. Don't bother yourself. The compiler often knows better.

Originally Posted by MutantJohn

Edit : I'm an idiot. You should never use std::move() in this context because you want to actually keep m_Coordinates in a specific state, duh! But my question should rather be, what if I have a function that takes 3 floats as input and returns a point? Is std::move() okay there? Consider,

Code:

struct point {
    float x, y, z;

   point(float x, float y, float z) {
       this->x = x; this->y = y; this->z = z;
   }
};

point make_point(float x, float y, float z) {

    return std::move(point(x, y, z));
}

This is a poor and trivial example, I do suppose. Hmmm... Maybe constructors just really are the answer... I was just wondering if it's ever okay to use return statements with std::move()...

Returning a local variable is an implicit move in C++11, so you don't need to do it.

Because you are wondering...

Code:

A DangerousFunction(A& a)
{
    return std::move(a); // Legal, but beware that a is left in a "zombie state", so the caller must not use a after this function
}