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.
If it is a wrapper, which is odd because that's not what I read from the description of the problem, then you might as well make PointsIterator a typedef of the vector<double>::iterator. I thought that something more complex was happening.
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?
Code - functions and small libraries I use
It’s 2014 and I still use printf() for debugging.
"Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson
Ok, thanks everybody and sorry for my latency to get the idea.
Code - functions and small libraries I use
It’s 2014 and I still use printf() for debugging.
"Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson
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
and a few forwarding functions, such asCode:typedef std::vector<double>::iterator PointsIterator;
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.Code:PointsIterator begin() {return v.begin();}
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 )
Last edited by std10093; 04-27-2014 at 03:20 AM.
Code - functions and small libraries I use
It’s 2014 and I still use printf() for debugging.
"Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson
And what GetCoordinates return? Maybe a pointer to the vector of coordinates?
Code - functions and small libraries I use
It’s 2014 and I still use printf() for debugging.
"Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson
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
“Salem Was Wrong!” -- Pedant Necromancer
“Four isn't random!” -- Gibbering Mouther
As an aside, can we std::move() it, move it?
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.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; };
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,
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()...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)); }
Last edited by MutantJohn; 04-27-2014 at 12:03 PM.
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.
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 }
I googled around and it seems like other people thought they were being clever as well. You're right, using std::move() with a return statement is entirely unnecessary. It's very interesting. I'm glad I asked though because I'm always curious about using things like these and where they're well-suited. Gratned, std::move()'s semantics are entirely over my head. I miss the days when l- and r-value references really were just left and right lol.