ich bin gerade dabei box2d in mein spiel zu integrieren. Um auf collisionen richtig reagieren zu können bietet box ein interface an, welches ein userdatapointer über void anbietet. Ich bin jetzt nicht sicher in wie weit ich legale sachen mache. Zuerst hab ich das probiert:

class Actor : public Interface1, public Interface2
{
	...
	b2Body *body = world.CreateBody(def);
	body.userData = this; // userData ist ein void*
}

class MyContactListener : public b2ContactListener
{
	virtual void BeginContact(b2Contact* contact)
	{
		...
		Interface2 *entity = static_cast<Interface2*>(userDataB);
	}
}

jetzt war allerdings die vtable falsch, ich hab nur die funktionen vom interface1 gesehen, nach ein bischen nachforschen hab ich rausgefunden das man von void* nur auf die konkrete klasse casten kann die man reingesteckt hat(stimmt das?), also hab ich

body.userData = static_cast<Interface2>(this);

gemacht, funktioniert auch aber ich frag mich ob das ok ist oder ob ich da im UB land bin? Und wenn das nicht ok ist, wie dann?

Gruß

interfacierer schrieb:

das man von void* nur auf die konkrete klasse casten kann die man reingesteckt hat(stimmt das?)

Ja. (edit)

interfacierer schrieb:

also hab ich

body.userData = static_cast<Interface2>(this);

gemacht, funktioniert auch aber ich frag mich ob das ok ist oder ob ich da im UB land bin? Und wenn das nicht ok ist, wie dann?

Ich bezweifle, dass das funktioniert. Erst mal, wie gesagt, muss es -> statt . heißen, außerdem muss der Typ Interface2***** sein, also insgesamt:

body->userData = static_cast<Interface2*>(this);

oder bei void* ausnahmsweise mit der Schreibweise oben (wobei ich static_cast sonst für aussagekräftiger und besser ersichtlich halte)
Das ist jetzt "perfectly defined"..

edit: Viele kleine Leichtsinnsfehler machen wenn das Internet gerade langsam ist, kann nervig sein..
Was ich noch sagen wollte: In vielen (aber nicht allen) Fällen zeugt es von schlechtem Design/Stil, wenn man void* benutzt, da man damit ein wenig Typprüfung verschenkt (eben weil die cast-Bedingungen da so lax sind). Wenn die Art der Daten bekannt sind, sollte man als Zeigertyp einen auf deren (gemeinsame Ober-) Klasse verwenden.

n hab ich rausgefunden das man von void* nur auf die konkrete klasse casten kann die man reingesteckt hat(stimmt das?)

richtig.

interfacierer schrieb:

also hab ich

body.userData = static_cast<Interface2>(this);

gemacht, funktioniert auch aber ich frag mich ob das ok ist oder ob ich da im UB land bin? Und wenn das nicht ok ist, wie dann?

Das ist ok so (Syntaxfehler ignoriert). Es könnte allerdings sinnvoll sein, den Zugriff auf userData geeignet zu kapseln.

interfacierer schrieb:

das man von void* nur auf die konkrete klasse casten kann die man reingesteckt hat(stimmt das?)

Nein, auch auf Oberklassen.

Casten kann man nat. fast beliebig. Nur entspricht eine Sequenz der Form
T* ->(implizit)-> void* -> (static_cast) -> U*
Semantisch und in Hinblick auf Definiertheit einem direkten
T* -> (reinterpret_cast) -> U*
und ist für Casts innerhalb einer Vererbungshierarchie i.d.R.*) undefiniert.

Ausnahmsweise ist es mal bei Klassen mit Standardlayout erlaubt - aber selten sinnvoll.

Was ich noch sagen wollte: In vielen (aber nicht allen) Fällen zeugt es von schlechtem Design/Stil, wenn man void* benutzt, da man damit ein wenig Typprüfung verschenkt (eben weil die cast-Bedingungen da so lax sind). Wenn die Art der Daten bekannt sind, sollte man als Zeigertyp einen auf deren (gemeinsame Ober-) Klasse verwenden.

Das kann ich ja leider nicht ändern, das interface ist ja von box2d vorgegeben.

camper schrieb:

Das ist ok so (Syntaxfehler ignoriert). Es könnte allerdings sinnvoll sein, den Zugriff auf userData geeignet zu kapseln.

Hmm was schwebt dir denn da vor? Ich wüßt gerade nicht wie ich das sinnvoll machen würde.

In C++ kann nur implizit von void* gecastet werden (Kompabilität zu malloc), aber nicht nach void*.

Ne, ist genau umgekehrt. Es kann implizit nach void* konvertiert werden, aber nicht von void*. Und dass es eben keine Kompabilität zu malloc gibt ist eines der Paradebeispiele dafür, warum nicht jeder C Code von einem C++ Compiler geschluckt wird.

Stimmt. Also void* sollte man wenn irgendwie möglich vermeiden. Mir ist auch derzeit, abgesehen von vordefinierten Interfaces kein sinnvoller Anwendungsfall untergekommen, wo es keine andere Lösung als void* gab...

Ein erster Ansatz wäre wohl, einfach den Typ zu nehmen, den die Daten tatsächlich haben. Also den userdatapointer vom Typ userdata* zu machen, statt void*. Da es so aussieht, als solle hier Polymorphie gemacht werden, nehme man einen Zeiger vom entsprechenden Basisklassentyp (Interface2?^*).
Anderer Ansatz, falls void* hier benutzt wird, um ein Funktion universell für mehrere Datentypen anzubieten, wären natürlich Templates.

Das sind die beiden Standardansätze zur Vermeidung von void* (der zweite eher als der erste, denn beim ersten wäre der void* auch in C komisch benutzt und das Problem läge tiefer).

^*: Leider ist das Codebeispiel bei all der Vererbung und Pointerei etwas schwer zu durchschauen. Zudem stark verkürzt. Ich bin mir nicht sicher, was hier wie zusammen hängt und was überhaupt erreicht werden soll.

Stimmt. Also void* sollte man wenn irgendwie möglich vermeiden. Mir ist auch derzeit, abgesehen von vordefinierten Interfaces kein sinnvoller Anwendungsfall untergekommen, wo es keine andere Lösung als void* gab...

void* ist die höchste Stufe von Type-Erasure und immer anzustreben um gegen Template-Bloat vorzugehen und die Compilezeiten herunterzuschrauben.

Was nichts daran ändert, dass ein void* im Interface nichts zu suchen hat.

Im gegebenen Fall bin ich auch gegen das Listener-Pattern, das kann alles in ohne explizite Vererbunghierarchie gelöst werden
C++03/11-Lösung: http://www.boost.org/doc/libs/release/doc/html/signals/tutorial.html
C++11-Lösung: std::vector<std::function<>>
Warum kein Observer: http://stackoverflow.com/questions/11619680/why-should-the-observer-pattern-be-deprecated

virtual void BeginContact(b2Contact* contact)

im b2Contact stehen dann die zwei kollidierenden fixtures. Die einzige möglichkeit von der kollision auf mein eigenes objekt zu schließen ist der userData pointer. D.h. ich setz im actor bei der erstellung des bodies den userData pointer auf "this" (das war halt mein eigentliches problem, wo ich nicht wussete ob ich da UB habe wenn ich das rumcaste). Ich seh jetzt nicht wie ich das eleganter lösen könnte, bin aber gerne offen für vorschläge

Nochmal mit ein bischen mehr code zur verdeutlichung

class MyContactListener : public b2ContactListener
{
	void BeginContact(b2Contact* contact)
	{
		// try to notify A
		void *userDataA = contact->GetFixtureA()->GetBody()->GetUserData();
		if(userDataA)
		{
			PhysicBodyEntity *entity = static_cast<PhysicBodyEntity*>(userDataA);
			entity->BeginContact(contact);
		}

		// then try notify B
		void *userDataB = contact->GetFixtureB()->GetBody()->GetUserData();
		if(userDataB)
		{
			PhysicBodyEntity *entity = static_cast<PhysicBodyEntity*>(userDataB);
			entity->BeginContact(contact);
		}

	}

	void EndContact(b2Contact* contact)
	{
		...
	}
}

class Actor : public DrawableNode, public Drawable, public PhysicBodyEntity
{
	Actor(b2World &world)
	{
		b2BodyDef bodyDef;
		...
		bodyDef.userData = static_cast<PhysicBodyEntity*>(this);
		world.CreateBody(bodyDef);

		...
	}
}

int main()
{
	MyContactListener contactlistener;
	b2World world(b2Vec2(0, -10));
	world.SetContactListener(&contactlistener);

	Actor actor(world);

	// hier gibt mir box dann über den listener die collisionen zurück
	world.Step(...);
}

Ausnahmsweise ist es mal bei Klassen mit Standardlayout erlaubt - aber selten sinnvoll.

Es ist zudem auch erlaubt, den Zeiger zu ihrem (der Deklarationsreihenfolge nach) ersten Member zu casten.
(Um die Liste vollstaendiger zu machen)

D.h. ich setz im actor bei der erstellung des bodies den userData pointer auf "this" (das war halt mein eigentliches problem, wo ich nicht wussete ob ich da UB habe wenn ich das rumcaste).

Ich kann grad' den Thread nicht komplett durchlesen... daher bitte ignorieren falls unpassend: Du brauchst die Adresse der Body-Basisklasse (bzw. des Basisklassen-Subobjekts)? Die kannst du doch direkt bekommen.

Ausnahmsweise ist es mal bei Klassen mit Standardlayout erlaubt - aber selten sinnvoll.

Es ist zudem auch erlaubt, den Zeiger zu ihrem (der Deklarationsreihenfolge nach) ersten Member zu casten.
(Um die Liste vollstaendiger zu machen)

Allerdings ist das kein Cast innerhalb der Vererbungshierarchie, auf die ich mich (nur) bezogen habe.

Nein, auch auf Oberklassen.