Wie void pointer auf new struct umbiegen

asc

Ich glaube ohne eine Rückmeldung vom OP macht die Diskussion wenig Sinn.

Einen Grund den ich mir Vorstellen könnte der gegen Polymorphie sprechen könnte wäre die Festlegung auf POD-Strukturen die von/nach einer C-Schnittstelle kommen. Aber selbst das liese sich mit einer minimalen Wrapperklasse (die polymorph ist) lösen.

cu André

Pyro Phoenix

Also um noch ein wenig klarheit zu schaffen:

struct sfm_key
{
	int32_t			frameType;
	int32_t			frameOriginX;
	int32_t			frameOriginY;
	int32_t			frameWidth;
	int32_t			frameHeight;
	uint8_t			*data;
	void			*prev_frame; // sfm oder gfm key
	void			*next_frame; // sfm oder gfm key
};

struct gfm_key
{
	int32_t			frameType;
	int32_t			numIntervall;
	float			*intervall;
	int32_t			frameOriginX;
	int32_t			frameOriginY;
	int32_t			frameWidth;
	int32_t			frameHeight;
	uint8_t			*data;
	void			*prev_frame; // sfm oder gfm key
	void			*next_frame; // sfm oder gfm key
};

Mit 'new' wird dann je nach Bedarf eine der beiden Strukturen als 'root' erstellt.
Und dann gehts je nach Fall weiter; Nach dem Double Linked-List Prinzip.

Mit polymorphie hab ich mich noch nicht beschäftigt. So weit war ich noch nicht

Simon2

@Badestrand:

Pyro Phoenix schrieb:

Was gibt es für alternative Lösungen? Abgesehen von polymorphismus.

Pyro Phoenix schrieb:

...
Mit polymorphie hab ich mich noch nicht beschäftigt. So weit war ich noch nicht

Siehtste ? :p

@Pyro: Sind diese structs von Dir entworfen oder vorgegeben ?
Wenn Ersteres, würde ich da noch mehr "Typsicherheit reindesignen" und z.B. die "Listeneigenschaft" (prevFrame, nextFrame) auslagern.
Ein

struct sfm_key
{
    int32_t            frameType;
    int32_t            frameOriginX;
    int32_t            frameOriginY;
    int32_t            frameWidth;
    int32_t            frameHeight;
    uint8_t            *data;
};

typedef std::list<sfm_key> sfm_key_list;

sollte es besser tun.
Außerdem scheint sich hier tatsächlich Polymorphie anzubieten.

Und die externe Referenz auf "data" könnte man bestimmt auch besser konkretisieren (es sei denn, es handelt sich tatsächlich um einen Verweis auf ein externes uint8_t Objekt).
...

Naja, nur so ein paar Ideen von mir.

Und selbst, wenn Du die structs nicht verändern kannst, kannst Du Deinen Zugriff auf sie trotzdem mit Overloading oder Polymorphie(wrapper) machen...

Gruß,

Simon2.

P.S.: Bist Du sicher, dass Du in "C++" programmierst und nicht in "C" ?

Badestrand

Simon2 schrieb:

@Badestrand: Siehtste ? :p

Ach Mist, wäre jetzt natürlich schön für mich gewesen, wenn's zwei absolut artfremde Typen wären

Pyro Phoenix

Simon2 schrieb:

@Pyro: Sind diese structs von Dir entworfen oder vorgegeben ?

Eigentlich trifft beides zu. Ich habe eine Datei mit einem bestimmten Format. Aber wie ich es lade bleibt mir überlassen. Ich könnte auch einfach den sfm_key weglassen und im falle eines sfm frames die Zwei zusätzlichen Variablen NULLen, aber das find ich irgendwie suboptimal. Was ich auch nicht weiß, weil es nirgends Dokumentiert ist, ob auch wirklich beide Frametypen in einer Datei vorkommen können / sollen / dürfen.

Simon2 schrieb:

Wenn Ersteres, würde ich da noch mehr "Typsicherheit reindesignen" und z.B. die "Listeneigenschaft" (prevFrame, nextFrame) auslagern.
Ein
struct sfm_key
{
    int32_t            frameType;
    int32_t            frameOriginX;
    int32_t            frameOriginY;
    int32_t            frameWidth;
    int32_t            frameHeight;
    uint8_t            *data;
};

typedef std::list<sfm_key> sfm_key_list;
sollte es besser tun.
Außerdem scheint sich hier tatsächlich Polymorphie anzubieten.

Hmm ... eine STL List ... neee dann müsste ich den ganzen Code re-designen.

Simon2 schrieb:

Und die externe Referenz auf "data" könnte man bestimmt auch besser konkretisieren (es sei denn, es handelt sich tatsächlich um einen Verweis auf ein externes uint8_t Objekt).

Extern ? Nein. Ist ein ganz Normales char Array ( String ) in dem Später die Daten gelagert werden.

Simon2 schrieb:

P.S.: Bist Du sicher, dass Du in "C++" programmierst und nicht in "C" ?

Naja ich Arbeite eigentlich in C und erweitere den Code durch C++ Funktionen, um ihn übersichtlicher zu gestalten. Ich liebe Low-Level .
( Hat bissher immer problemloß geklappt )

Konrad Rudolph

Pyro Phoenix schrieb:

( Hat bissher immer problemloß geklappt )

Das sind die berühmten letzten Worte.

drakon

Naja ich Arbeite eigentlich in C und erweitere den Code durch C++ Funktionen, um ihn übersichtlicher zu gestalten. Ich liebe Low-Level .

Mit C++ kann man genau so low-level arbeiten, wie mit C. (Habe mal gehört, dass in bestimmten fällen das erzeugte Programm aus C++ schneller war, als wenn man es direkt in Assembler geschrieben würde..:))

Pyro Phoenix

Konrad Rudolph schrieb:

Pyro Phoenix schrieb:

( Hat bissher immer problemloß geklappt )

Das sind die berühmten letzten Worte.

Is mir schon klar, das das böhse enden kann.

Simon2

Badestrand schrieb:

Simon2 schrieb:

@Badestrand: Siehtste ? :p

Ach Mist, wäre jetzt natürlich schön für mich gewesen, wenn's zwei absolut artfremde Typen wären

Darauf wollte ich eigentlich nicht hinaus, sondern auf diesen "Hab' ich immer so gemacht und Anderes kenn' ich nicht"-Faktor.

Gruß,

Simon2.

P.S.: Es kommt doch nur seeeeeeehr selten vor, dass jemand WIRKLICH eine Funktion für vollkommen artfremde Objekte (Baumfaellen_oder_SteuererklaerungMachen()) schreibt.

Simon2

Pyro Phoenix schrieb:

...

Simon2 schrieb:

P.S.: Bist Du sicher, dass Du in "C++" programmierst und nicht in "C" ?

Naja ich Arbeite eigentlich in C und erweitere den Code durch C++ Funktionen, um ihn übersichtlicher zu gestalten. Ich liebe Low-Level...

Ich behaupte jetzt mal ganz dreist: Du kennst nur nichts Anderes ! :p
Wenn Du Deinen Code schon ohne STL-Container strukturiert hast, gehe ich mal davon aus, dass Du Dich nicht vorher mit ihnen auseinandergesetzt und auf Basis einer soliden Abschätzung gegen ihren Einsatz entschieden hast.
Macht ja nichts ... aber Du solltest Dich ruhig mal mit denen beschäftigen: Sie sind sehr "nett" und man lernt wirklich (auch konzeptionell) Neues !
Dasselbe gilt natürlich auch für overloading, <string>, <algorithm>, Exceptions, Polymorphie, Templates, ... dabei geht es natürlich nicht nur drum, möglichst schnell dieses eine Programmierproblem zu lösen, sondern es erweitert den Horizont, so dass man ein besserer Entwickler wird - und das zahlt sich auf Dauer definitv aus.

Pyro Phoenix schrieb:

...

Simon2 schrieb:

Und die externe Referenz auf "data" könnte man bestimmt auch besser konkretisieren (es sei denn, es handelt sich tatsächlich um einen Verweis auf ein externes uint8_t Objekt).

Extern ? Nein. Ist ein ganz Normales char Array ( String ) in dem Später die Daten gelagert werden....

ähh ... unter "extern" meinte ich: Daten, für die ein anderes Objekt zuständig ist:

struct A {
   int* i;
};

struct C {
   int i;
   void calc() { i = 7; }
};   

int main() {
   C c;
   A a;

   a.i = &c.i; // a bekommt einen Verweis auf das int-Member aus c
   c.calc(); // => a->i verweist auch auf einen anderen Wert
...

das meinte ich mit "A::i verweist auf ein (aus Sicht von A) externes Objekt".

Pyro Phoenix schrieb:

Konrad Rudolph schrieb:

Pyro Phoenix schrieb:

( Hat bissher immer problemloß geklappt )

Das sind die berühmten letzten Worte.

Is mir schon klar, das das böhse enden kann.

Und Konrad und viele Andere mit ihm, haben die Erfahrung gemacht, dass es das in 90% der Fälle auch tut ! (sonst wären diese letzten Worte nicht so berühmt)

Gruß,

Simon2.