unverständliche C++ Codeabschnitt

Sami Gast 16.02.2016 10:31 #4470745

Lesenswert?

•

Hallo zusammen:
Ich habe einen Projekt von einen Kollegen übernommen.
Dieses Projekt beinhaltet leider keine Dokumentation.

Ich bin auf einen Codeabschnitt gestossen, die ich nicht verstehe:

#define pmaGetAClass()        ((AClass *)m_pvAClass)


Was passiert eigentlich?
Ist dieses Macro nötig?
Kann ich das anders schreiben?
Was bekomme ich, wenn ich pmaGetAClass() aufrufe?

Der zweite Abschnitt sieht so aus:

#define pmaGetBClassBySlot(a)  (&((CBClass *)m_pvBClassPool)[static_cast 
<int>(a)])

Hier ist auch das gleiche.
Was passiert?
Ist das nötig?
Kann ich das anders schreiben?

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Rufus Τ. F. (rufus) 16.02.2016 10:36 #4470753

Lesenswert?

•

▲
▼

Sami schrieb:
> Ist dieses Macro nötig?

Wenn es benutzt wird: ja, natürlich.

> Was passiert eigentlich?

Na, das steht doch da. Die Membervariable m_pvAClass wird in einen 
Pointer auf AClass gecastet.

Welchen Typ hat m_pvAClass?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Sami Gast 16.02.2016 10:41 #4470760

Lesenswert?

•

▲
▼

Rufus Τ. F. schrieb:
> Welchen Typ hat m_pvAClass?
void *m_pvAClass;
void *m_pvBClassPool;

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Rene H. Gast 16.02.2016 10:42 #4470761

Lesenswert?

•

▲
▼

Rufus Τ. F. schrieb:
> Welchen Typ hat m_pvAClass?

Das wird vermutlich ein void * sein. Das ist aber nur eine Vermutung.

Grüsse,
René

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Jay Gast 16.02.2016 10:43 #4470763

Lesenswert?

•

▲
▼

Macros sind nie absolut "nötig", man kann den Code auch direkt x-fach 
kopieren und hinschreiben - was aber ziemlich nervig ist. Bei C++ gibt 
es in vielen Fällen auch bessere Alternativen zu Macros, z.B. Templates. 
Soviel zur Sinnfrage - die Macros "nötig" sein oder auch nicht.

Ansonsten sind das sehr einfache C++-Konstrukte. Bist du sicher, dass du 
C++ kannst und Casting verstehst?

Zu eigentlichen Code kann man nicht viel sagen, also da wo die Macros 
verwendet werden, da du den Code nicht gezeigt hast. Man kann vermuten, 
dass man insgesamt den Code vernünftiger aufbauen kann, z.B. in dem von 
vorne herein auf Typkompatibilität geachtet wird. Vielleicht bietet sich 
auch ein Operator-Overloading von [] an, und zur Not Templates.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Sami Gast 16.02.2016 10:50 #4470778

Lesenswert?

•

▲
▼

Jay schrieb:
> Ansonsten sind das sehr einfache C++-Konstrukte. Bist du sicher, dass du
> C++ kannst und Casting verstehst?

Ja das verstehe ich.

Dieses Casten ist aber c-spezifisch sollte man vielleicht nicht c++ 
spezifisch casten?

--> Das ist eigentlich der saubere Weg denke ich

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Rene H. Gast 16.02.2016 10:52 #4470786

Lesenswert?

•

▲
▼

Sami schrieb:
> Dieses Casten ist aber c-spezifisch sollte man vielleicht nicht c++
> spezifisch casten?
>
> --> Das ist eigentlich der saubere Weg denke ich

Natürlich sollte man. Man sollte aber auch void* vermeiden ;-). Das 
lässt sich garantiert besser implementieren.

Grüsse,
René

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Rolf M. (rmagnus) 16.02.2016 11:09 #4470825

Lesenswert?

•

▲
▼

Sami schrieb:
> Dieses Casten ist aber c-spezifisch sollte man vielleicht nicht c++
> spezifisch casten?

Man sollte es so umschreiben, dass man keinen Cast braucht.
In C++ braucht man eigentlich nur selten Casts - oder Makros.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Rufus Τ. F. (rufus) 16.02.2016 11:10 #4470827

Lesenswert?

•

▲
▼

Sami schrieb:
> Dieses Casten ist aber c-spezifisch sollte man vielleicht nicht c++
> spezifisch casten?

Allerdings; dieser "C++"-Code ist aus C++-Sicht ziemlicher Pfusch und 
bei sauber geschriebenem C++ so auch absolut unnötig.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Tom Gast 16.02.2016 11:10 #4470828

Lesenswert?

•

▲
▼

Rene H. schrieb:
> Das
> lässt sich garantiert besser implementieren.

Könnte man. Aber im geerbten Projekt erstmal alles "aufzuräumen", ist 
vielleicht etwas für Menschen, die etwas erfahrener sind.
Wenn es läuft: so lassen. Wenn man es nicht ganz versteht: so lassen. 
Wenn man es irgendwann sowieso anfassen muss oder wenn Zeit für 
Refactoring ist: besser machen, falls man verstanden hat, wie es besser 
geht.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Eric B. (beric) 16.02.2016 11:29 #4470865

Lesenswert?

•

▲
▼

Sami schrieb:
> #define pmaGetBClassBySlot(a)  (&((CBClass *)m_pvBClassPool)[static_cast
> <int>(a)])

Interessant ist allerdings dass hier einmal "C-Style" gecastet wird und 
einmal "C++-Style". Da hat wohl ein C-Programmierer C++ Code schreiben 
wollen oder müssen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Sami Gast 18.02.2016 09:40 #4473712

Lesenswert?

•

▲
▼

Rene H. schrieb:
> Man sollte aber auch void* vermeiden ;-)

zu verstehen: Warum sollte es einen void* vermieden werden?
Danke

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Daniel A. (daniel-a) 18.02.2016 11:01 #4473812

Lesenswert?

•

▲
▼

Man sollte void pointer vermeiden, weil man nicht weiss auf welchen 
Datentyp er zeigt. Es gibt sinvolle Anwendungsfälle dafür, wie z.B. bei 
functionen wie memset, memcpy wo der Datentyp keine rolle spielt. Für 
alles andere muss man den void pointer in den eigentlichen Datentyp 
casten, und wenn man den falchen erwicht ist man aufgeschmissen. In C++ 
kann man die meisten void pointer vermeiden, indem man den möglichen 
Typen die selbe Basisclasse für ein einheitliches Interface hat oder 
Templates einsetzt.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Robert L. (lrlr) 18.02.2016 14:44 #4474126

Lesenswert?

•

▲
▼

>weil man nicht weiss auf welchen
>Datentyp er zeigt.

das verhindert man mit:


>indem man den möglichen
>Typen die selbe Basisclasse

verwendet

aber auch nicht automatisch


d.h. man sollte einen CAST immer nur mit dynamischer TypPrüfung machen..

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Daniel A. (daniel-a) 18.02.2016 15:08 #4474176

Lesenswert?

•

▲
▼

@Robert L. (lrlr)
Das mag ja sein, dennoch entfällt durch eine Basisklasse mit sauberem 
Interface und einigen virtuellen Methoden meistens die Notwendigkeit den 
eigentlichen typ zu kennen. Ansonsten traue ich den Dynamic cast 
geschichten nicht wirklich und versuche solche Situationen immer zu 
vermeiden.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

lrlr Gast 18.02.2016 15:16 #4474196

Lesenswert?

•

▲
▼

stimmt auch wieder..

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Sven B. (scummos) 18.02.2016 17:25 #4474397

Lesenswert?

•

▲
▼

> Ansonsten traue ich den Dynamic cast
> geschichten nicht wirklich und versuche solche Situationen immer zu
> vermeiden.

??

Robert L. schrieb:
> d.h. man sollte einen CAST immer nur mit dynamischer TypPrüfung machen..

???

Antwort Zitieren Bearbeiten Löschen Beitrag melden

unverständliche C++ Codeabschnitt

Antwort schreiben