Le sugiero que utilice un boost::shared_ptr para estas estructuras de posición. De esta forma, no tiene que preocuparse por la eliminación y puede usarlo como un puntero que se comparte con el objeto del motor del juego o como un puntero independiente.
Como hay sobrecarga para estos, es posible que desee limitar la relación de datos a puntero. En otras palabras, no guarde shared_ptr para cada coordenada, sino shared_ptr en el vector de posición y shared_ptr en la representación de rotación, o shared_ptr en una transformación o marco homogéneo (sistema de coordenadas, fotograma cinético o fotograma cinético)
Por ejemplo, usted podría tener esto:
class object {
public:
typedef boost::shared_ptr<Vector3D> pVector3D;
private:
pVector3D position;
public:
object(pVector3D aPos = pVector3D(new Vector3D(0.0,0.0,0.0))) : position(aPos) { };
};
La propiedad cuenta automática y referencia de la shared_ptr lo hará de manera que no tendrá que preocuparse de poner una instrucción de eliminación (automático) y hay no hay peligro de que el objeto desaparezca del motor del juego, mientras que el motor de física aún necesita esas variables (el conteo de referencias garantiza que se eliminarán solo cuando se eliminen también todos los objetos que lo necesitan).
EDITAR
preferiría no utilizar impulso. Sin embargo, no me opongo a una solución que requiere una plantilla. Además, con este siendo parcialmente una optimización de rendimiento , boost :: shared_ptr, does no parece ser la solución correcta.
Bueno, shared_ptr/shared_array también se puede encontrar en el informe técnico de la biblioteca estándar 1 (TR1) (por lo que es std::tr1::shared_ptr lugar, por lo que no es necesario usar Boost para usar esos). En cuanto a la optimización del rendimiento, es por eso que recomiendo una relación bastante alta de datos a puntero.La sobrecarga de shared_ptr es principalmente una sobrecarga de memoria y algo indirecto durante la eliminación y copia (que son dos operaciones que no se realizan con tanta frecuencia), no creo que haya demasiados gastos indirectos en el acceso a los datos a los que apunta en comparación con un puntero o una referencia. Tienes que aceptar que, incluso al usar referencias, estás intercambiando gastos indirectos de copia de datos con sobrecarga indirecta de acceso a datos (también estás sacrificando la localidad de memoria, ¡lo cual es un gran problema!). Diría que la caída en el rendimiento relacionada con la ruptura de la localidad de memoria va a ser mucho peor que solo la indirección. Por lo tanto, cuando se trata de acceder a elementos, IMO, shared_ptr, punteros sin formato y referencias tendrán muy poca diferencia en el rendimiento. En muchos algoritmos que usan estas variables compartidas, probablemente sería mejor copiar los datos apuntados por el puntero/referencia a variables locales, calcular con y sobre esas variables locales, y luego copiarlas de nuevo a la memoria apuntada por el puntero /referencia.
Te recomiendo que hagas algunas pruebas tuyas sobre el rendimiento cuando usas cualquiera de las soluciones (usando shared_ptr, usando referencias o punteros crudos, y copiando los datos entre el motor del juego y el motor de física) y verás por ti mismo, podrías sorpréndete con lo que encuentres
Edit2
Ha considerado el uso esquema de herencia múltiple. Este problema puede ser probablemente muy bien servido con un esquema de herencia de diamantes:
class PositionedObject {
protected:
float Position[3];
public:
PositionedObject(float x,float y, float z) { Position[0] = x; ... };
virtual ~PositionedObject() { };
};
class VisibleObject : virtual public PositionedObject { //note that the "virtual" keyword is critical here.
... rendering-related code ... i.e. the game-engine side of the implementation
};
class RigidBody : virtual public PositionedObject { //again "virtual" is very important.
... physics code here ...
};
class MyObject : public VisibleObject, public RigidBody {
... code specific to MyObject ...
};
esto por encima de los esquemas hacen que el objeto de la física y la cuota objeto de juego-motor de los mismos datos de posición (con poco indirecta, poca memoria, los gastos generales y poco problemas de localización de memoria). Estoy bastante seguro de que esto sería más eficiente que cualquier otro esquema, pero los argumentos sobre el rendimiento solo pueden responderse con los resultados de las pruebas que tendrá que hacer usted mismo si el rendimiento es realmente su principal preocupación (asegúrese de que no está haciendo optimización prematura!).
Esto es lo que terminé haciendo, gracias. –