[C++] Problems with templates and friends

Note that Tween is a completely different type than Tween so you can't have Tween* without the template type. You must always specify the type. What you can do is having a abstract base class that all your Tween inherit from.
Something like this:
class TweenBase
{
public:
virtual void update(int time) = 0;
};

template <typename T>
class Tween : public TweenBase
{
public:
virtual void update(int time) { .. };
};
Then you can have an std::vector to store the pointers in.

I don't understand exactly why you want to use a friend. What protected data are you talking about?

The protected data that I was talking about would be members of an Object or Sprite class, like its (protected) position or scale variables. I was looking to give the Tween a reference to a member variable at the Tween's instantiation, and just let it run until it dies. Then on each render cycle, the object would be drawn using its member variables, which have been manipulated by the Tween in its Update() function.

The idea of using the abstract base class is something I will explore when I go back to it tonight, thanks for your help.

The friend keyword allows class A to access class B's private members by going through class B.

That is:

class A
{
private:
int myPrivInt;

// allow A to see my internals
friend class B;
};
class B
{
A myA;

void SomeFunc()
{
// I can reach myPrivInt through A, because it declared me as a friend
myA.myPrivInt = 5;
}
}



That's not what you're doing though. You're binding a pointer to m_position.Y. This allows anyone owning that pointer to modify m_position.Y without going through A. You don't have to do anything with friends. If you have a pointer to something, you can change it, even if it's a private member within a class.

Note that this breaks encapsulation and is typically seen as bad OO programming. You're bypassing the very reason for making m_position private in the first place. That doesn't mean it should always be avoided. We often write code like this because it's more efficient than alternatives that are more OO.

In this case, I think you're safe as long as you make sure that Object maintains strict ownership over the Tween objects. I recommend you enforce this by making tweenVec a boost::ptr_vector, but in the absence of boost I'd just make sure you're deleting each tweenVec object in the Object destructor.

I'm having trouble thinking of good ways of doing this without breaking encapsulation. You could do something with shared_ptrs and boost::functions to retrieve and set the current value, surely, but I don't think it would end up being very nice.

Great explanation of friend classes thank you. That is exactly what I thought they did, but I did not realize that you could get around variables being private through pointer use (as bad practice as it may be).

In this case, I think you're safe as long as you make sure that Object maintains strict ownership over the Tween objects. I recommend you enforce this by making tweenVec a boost::ptr_vector, but in the absence of boost I'd just make sure you're deleting each tweenVec object in the Object destructor.

Yes, the object itself will instantiate the Tween objects, add them into its vector, and delete them when they finish (and delete any remaining when the object's destructor is called). No other objects will have access to this vector or the individual Tweens.

I'm having trouble thinking of good ways of doing this without breaking encapsulation. You could do something with shared_ptrs and boost::functions to retrieve and set the current value, surely, but I don't think it would end up being very nice.

This was somewhat like an approach my partner and I discussed, where upon Tween instantiation you would pass it a function pointer that would later be used to pass the tween'd value back to the object every Update(). This approach would have worked, but I am trying hard to maintain the simple/clean interface for the Tween class, and felt that the function pointers made it feel sloppy and unnecessarily abstract.

Thanks again for the assistance.

Also, is this concept something that is done regularly but I just never ran across? It seems like a real handy class to have around, but I have never seen it before.

The typical solution is to implement tweening as a templated free function, not a class. Then you just invoke Tween(startFoo, endFoo, startT, endT, currentT, interpolationMethodEnum); and you're done.