unverständliche C++ Codeabschnitt

Gast #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?
Gast #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.
Gast #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
Gast #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é
Gast #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.
#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.
#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 schreiben

Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. Bitte hier nur auf die ursprüngliche Frage antworten, für neue Fragen einen neuen Beitrag erstellen.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.