Verständnisfrage Umstellung c++ struct

[Sunec]

Code:

struct mystruct
{
   int               index;
   inline char * const name( void ) const { return ((char *)this) + index; }
   int                range;
};

Bezieht sich das "this" in der inlined Funktion in diesem Fall auf die struct selbst oder auf die eingebundene Funktion?

Bei der Umstellung nach Delphi wäre es ja dann entweder die Adresse der struct oder struct + 4 Bytes (aufgerund des ersten structmembers Index).

Tue mir da irgendwie gerade schwer mit.

[Der schöne Günther]

Um die Frage zu beantworten: Auf die Struktur. Das sieht du, z.B. im Visual Studio, auch beim draufhalten mit der Maus.

Die Struktur an sich verstehe ich aber überhaupt nicht. Zwei Integer und eine Methode sich selbst auf einen Char-Pointer zu casten. Das macht keinen Sinn. Es könnte Sinn machen, wenn in der Struktur noch mehr enthalten wäre (z.B. ein Char-Array) und du uns das verschweigst

[frankyboy1974]

Hallo,

wer hat behauptet C/C++ würde Sinn machen.

mfg

[Sunec]

Danke das hatte ich mir schon gedacht. Dann scheitert es wahrscheinlich an meiner Deklaration der inlined Funktion.

Die struct ist tatsächlich etwas komplexer enthält allerdings kein Char Array.

Name ermittelt anhand des Indexes, wie der Name schon erahnen lässt, den einen Namen, der in einem anderen Speicherbereich liegt.

[uligerhardt]

Zitat von frankyboy1974:

wer hat behauptet C/C++ würde Sinn machen.

[Sunec]

Es macht schon Sinn, da der Name bereits woanders im Speicher vorhanden ist und so nicht doppelt abgelegt wird. Er wird somit nur ermittelt und die Methode Name dient als Verweis.

[frankyboy1974]

Hallo,

welcher Name ist jetzt bereits abgelegt? Der Name einer Methode (Funktion) wird eigentlch nirgends abgelegt. Ich dachte immer der Name einer Methode spielt für den Programmierer eine Rolle, der Compiler ersetzt das ganze durch eine Speicheradresse. Aus meiner Sicht ist C/C++ eine Programmiersprache, wo es eigentlich nicht mehr um zielorientierte Programmierung geht, sondern nur um Verwirrung. Noch besser ist allerdings perl, zumindestens in diesem Gebiet.

mfg

[BUG]

Zitat von frankyboy1974:

wer hat behauptet C/C++ würde Sinn machen.

Zitat von Sunec:

Es macht schon Sinn, da der Name bereits woanders im Speicher vorhanden ist und so nicht doppelt abgelegt wird. Er wird somit nur ermittelt und die Methode Name dient als Verweis.

Solche Verrenkungen sind der Grund wieso C++ so einen schlechten Ruf hat
Ein Zeiger oder eine Referenz auf den Namen (einen String, kein Char-Zeiger) hätten es vermutlich auch getan. Es sei denn, du hast da einen hochoptimierten, weggekapselten Programmteil.

Zitat von frankyboy1974:

Aus meiner Sicht ist C/C++ eine Programmiersprache, wo es eigentlich nicht mehr um zielorientierte Programmierung geht, sondern nur um Verwirrung.

[uligerhardt]

Zitat von frankyboy1974:

Aus meiner Sicht ist C/C++ eine Programmiersprache, wo es eigentlich nicht mehr um zielorientierte Programmierung geht, sondern nur um Verwirrung.

Sorry, aber das ist Delphi-Fanboi-Stuss. Erstens ist "C/C++" nicht eine Programmiersprache, sondern zwei reichlich unterschiedliche. Und im Vergleich mit C++ zieht Delphi bei vielen Dingen den Kürzeren. Gelegentlich sogar bei der Lesbarkeit.

[frankyboy1974]

Hallo,

dann ist (sind) Delphi wohl auch zwei Programmiersprachen (Pascal und ObjectPascal), wobei Delphi eigentlich nur eine Entwicklungsumgebung meint. C (als funktionale) und C++ (als objektorientierte) mögen zuweilen schneller ausgeführt werden, als Delphi-Quellcode, aber die Lesbarkeit (zumindestens im Durchschnitt) würde hier klar an Delphi (ObjectPascal) gehen. In C/C++ sind Konstrukte möglich, die ich trotz Informatikstudium schon fast nicht mehr verstehen kann (Es dauert zuweilen zumindestens Stunden bis ich das nachvollzogen habe).
Es gibt aus meiner Sicht Programmiersprachen, die den Entwickler geradezu auffordern unleserlich Code zu fabrizieren (C und C++, Perl) und welche die von Grund auf Lesbar sind (Delphi / Java).

mfg