passing std::vector and optimisation

The current code i have right now:

Code:

class main {
public:
 std::vector<std::string> &get_vector() { return m_vector; }
 const std::vector<std::string> &get_vector() const { return m_vector; }

private:
 std::vector<std::string> m_vector;
};


class subclass {
private:
 main &m_main;
 void somefunction() {
	std::vector<std::string>::iterator from = m_main.get_vector().end() - 2;
	callsomefunc(std::vector<std::string>(from, m_main.get_vector().end()) ); //call somefunc and pass vector with last 2 elements
 }
};

I want to redesign it to:

Code:

class main {
public:
 std::vector<std::string> get_last_elements() { return std::vector<std::string>(m_vector.end() - 2, m_vector.end() ); }

private:
 std::vector<std::string> m_vector;
};

class subclass {
private:
 main &m_main;
 void somefunction() {
	callsomefunc(m_main.get_last_elements());
 }
};

but I have some preformance considerations on second design.. Will it be slower because of passing value directly instead of reference?
Or will my compiler optimise that? Which design should I go for if theres a lot of copying in my application?

Many thanks in advance!

1) Yes, it's slower because it will create a temporary object, invoke copy constructor and return, then create a new object, invoke copy constructor again and finally invoke destructor and destroy temporary object. Can the compiler optimize it? Yes, it can.
2) You want to make sure the compiler supports the optimization or go with the reference.

Originally Posted by l2u

Which design should I go for if theres a lot of copying in my application?

A design that doesn't copy around private members all over the place. In short, prefer...

foo.doWork();

...to...

baz b = foo.getB();
bah h = foo.getH();
// Do something with b and h to create r
foo.setResult(r);

The second version seems somewhat better. At least subclass doesn't need to know that its the last two items in the main vector that are special.

If this really is bad for performance, then I guess working through iterators might be more effective.

But the main question is: cannot main implement somefunction instead of subclass (so it won't need to give out its vector or part of it at all)?

Wait... You have a class called "main"??? No, now that's... That's just wrong... Evil and wrong. Does it actually compile?

Wait... You have a class called "main"??? No, now that's... That's just wrong... Evil and wrong. Does it actually compile?

It is allowed if the main class is not in the global namespace.

Originally Posted by cpjust

Wait... You have a class called "main"??? No, now that's... That's just wrong... Evil and wrong. Does it actually compile?

Forget about main class, I only called it main for this example.

I would think a better design might look something like:

Code:

class vecClass{

public:

  //...

private:

  std::vector<whatever> mVector;
};

void someFunction( std::vector<whatever>& aVector ){

  // ... Do whatever
}

int main(){

  vecClass mVec;

  // ...

  someFunction( mVec );

  return 0;
}

But hey, that's just me...

I would think a better design might look something like:

someFunction() is declared as taking a std::vector<whatever> as its argument, but you pass a vecClass to it in main(). In other words, someFunction() may need to be a friend, but if so then perhaps it could just as well be a member.

Oh yea, typed a little too fast w/out thinking, I meant for it to take a ( vecClass& aVecClass ); Pretend it was that.

so look like this:

Code:

someFunction( vecClass& aVecClass ){

  // If getLasTwo() is a member function then:

  std::vector<std::string> anotherVec = aVecClass.getLastTwo();

}

I don't know your design requirements, but I prefer the second way. I mean, why bother having a class at all in your first design?

I think the thing that is more under question is whether the getLastTwo function is effective or needed in the first place. Perhaps the OP has some reason to store a reference to the other class rather than pass the reference to only SomeFunction (e.g the referred object has to remain the same for this instance).