C Frage ist folgendes zulässig?

Es sei der Einfachheit halber folgende structure gegeben:

struct test { char *name; } structure, *pointer;

ferner

pointer = (struct test *) malloc(sizeof(struct test));

Dann geht es folgendermaßen weiter:

structure.name=(char *) malloc (sizeof("Emily"+1));

strcpy (structure.name,"Emily");

..

Folgendes Problem: im ersten malloc wird eine Anzahl von Bytes (bei mir sind es 4) für die struct test reserviert.

zu diesem Zeitpunkt steht aber noch nicht fest, wie lange der String structure.name wird.

Die Reservierung von Speicherplatz für "Emily", das sind noch einmal 6 Bytes, also mehr Bytes als die Struktur insgesamt zugewiesen bekommt (Bei mir eben 4 Bytes).

Insofern sprengt das 2. malloc den Speicherplatz für die Struktur insgesamt (1. malloc).

Daher frage ich mich, ob das überhaupt so zulässig ist.

Ich meine funktionieren tut es trotzdem und ich habe in meinem Buch eben ein solches Beispiel gefunden.

trotzdem finde ich dieses malloc für die Gesamtstruktur (1. malloc) nicht so toll.

okay verstehe, in der Struktur ist ja nur ein Pointer.

Sorry, ist ein alter Thread, aber muss hier trotzdem mal meinen Senf geben:

Zitat von MOS

struct test { char *name; } structure, *pointer;

Das ist soweit zwar korrekt, aber schwer/schlecht lesbar. Mehrere Deklarationen auf einmal sollte man für sauberen Stil besser vermeiden, solche Praktiken stammen noch aus den Zeiten, als man auf 80x25 text screens programmiert hat Für den resultierenden Code ist es egal, und folgendes ist besser lesbar:

Oder man nimmt ein typedef dazu um dem Typen einen Namen im normalen Namespace zu geben, dann kann man sich das `struct` später sparen. Auch die Variablenbenennung ist "fragwürding", ein pointer ist wohl sehr allgemein.

Zitat von MOS

pointer = (struct test *) malloc(sizeof(struct test));

Das ist auch nicht falsch, aber unnötig kompliziert und auch eine klassische Fehlerquelle. Erstens ist in C (nicht in C++!) die Konvertierung eines Pointer-Typs von oder zu void * implizit, der Cast ist also überflüssig. void * fungiert hier als "generischer" Typ. Da Pointer-Casts in C potentiell gefährlich sind (der resultierende Code könnte die "strict aliasing rule" verletzen) sollte man Casts, die nicht nötig sind, auch nicht schreiben -- und dann alle anderen als Alarmsignal sehen und den Code genau überprüfen. Zweitens kennt der malloc operator zwei verschiedene Formen: Mit Klammern und einem Typnamen, oder ohne klammern mit einer Expression. Der bevorzugte C-Stil für diese Zeile sieht so aus:

In dieser Form bezieht sich sizeof auf die Storage-Größe des Typs der Expression *pointer, das ist genau der gewünschte Typ struct test. Der Vorteil dieser Schreibweise, neben der besseren Lesbarkeit, ist, dass sie auch noch korrekt ist, wenn man später den Typ von pointer ändert. Mit der Syntax weiter oben müsste man dann auch den Operanden zu sizeof ändern -> leicht zu übersehen, damit eine Quelle für Bugs.

Zitat von MOS

structure.name=(char *) malloc (sizeof("Emily"+1));

Diese Zeile ist völlig falsch!. Ein String literal in C hat den Typ char[], damit würde das passen, aber durch das +1 wird das Array Teil einer Expression, in der es zu einem Pointer evaluiert. "Emily"+1 ist ein Pointer (Typ char *) auf das m, damit liefert dieses sizeof die Größe eines Pointers -- höchstwahrscheinlich weniger als 6.

Gemeint war wohl sizeof("Emily")+1, das wäre korrekt, würde aber ein Byte verschwenden -- ein String literal enthält bereits das abschließende NUL Byte, sonst wäre es im Sinn von C gar kein String.

Bevorzugte Schreibweise:

Die Klammern zu sizeof sind überflüssig, weil wieder eine Expression verwendet wird und nicht der name eines Typs (das wäre hier dann char[6]).

Die eigentliche Frage wurde ja schon beantwortet, aber diese Anmerkungen finde ich durchaus noch wichtig

Das ist ein "C++-ism" (genau wie der cast von void *)

Man kann natürlich in jeder Sprache so schreiben, wie man will -- die übliche Philosophie in C ist allerdings, dass eine Deklaration möglichst genau so aussehen soll, wie die Verwendung. Der * wird dabei als eine Art "type modifier" gesehen und bindet entsprechend auch an den Identifier, nicht an den Typ. In C deklariert man also quasi den Typ des dereferenzierten Pointers, daher die vorgeschlagene Schreibweise oben.

In C++ ist die Philosophie, Typ und Identifier klar voneinander zu trennen -- das erscheint zunächst logischer und ist in C++ auch die übliche Notation. Leider wird es in C++ unlogisch, wenn man sowas hat: char* x, y; -- die Deklaratoren sind hier kompatibel zu C, also deklariert das nicht zwei Pointer sondern nur einen plus ein char. Wenn man natürlich der Empfehlung folgt, nicht mehrere Dinge auf einmal zu deklarieren, spielt es keine Rolle, aber es ist ein wenig unschön

Zitat von androSID

Randnotiz: In den meisten Projekten (an denen ich mitarbeiten durfte) war es sogar explizit verboten worden, mehrere Variablen in einer Zeile zu deklarieren.

Ja, das ist ja auch sinnvoll, würde ich in jeder coding guideline so unterstützen Ich wollte nur darauf hinweisen, dass Stroustrup hier etwas inkonsequent ist: Er wollte C++ möglichst C-kompatibel halten, deshalb bindet auch in C++ der * in einer Deklaration an den Identifier und nicht an den Typ (obwohl er zum Typnamen gehört), propagiert aber trotzdem eine Schreibweise, die suggeriert es sei umgekehrt.

Persönlich bleibe ich beim üblichen C-Stil wenn ich C schreibe, und in den seltenen Fällen, dass ich C++ mal anrühre (bin kein großer Fan dieser Sprache) versuche ich daran zu denken, dort den in C++ bevorzugten Stil zu schreiben

Zitat von androSID

Und wie gehst du bei Projekten vor, die intern in C++ aber extern (also am API) in C programmiert sind?

Sowas habe ich bisher nie gemacht. Nur mal ein C Projekt, in dem ein Teil in C++ war (wegen Nutzung von Qt) und dieser Teil eine interne C API hatte (ist bisher sowieso unvollendet geblieben) -- da hab ich komplett den typischen C Stil verwendet

Man könnte sich überlegen, dort auch in den .cpp Files den "Stroustrup-Stil" zu nehmen.

Zitat von androSID

Daher bleibe ich grundsätzlich beim C++ Stil.

Hatte ich ja auch gleich geschrieben: Jeder kann es schreiben, wie er es besser findet (solange man sich nicht an existierende coding guidelines halten muss).

Ich würde aber empfehlen, sich an den in der jeweiligen Sprache bevorzugten (bzw verbreitetsten) Stil zu halten. Projekte, in denen verschiedene Sprachen gemischt sind, sind dann natürlich ein Grenzfall

Übrigens, ein weiteres Argument für die klassische C Schreibweise ist auch, dass es konsistent mit der Deklaration von Arrays ist. Also z.B. bei der Deklaration int x[5]; ist der Typname int[5], ich kann aber trotzdem nicht int[5] x; schreiben...

Zitat von ogd

Was kann denn da Schlimmes passieren?

§6.5 p7, auch "strict aliasing rule" genannt. Kurz gesagt verbietet sie mit wenigen Ausnahmen, ein Objekt mit einem Pointer eines anderen Typs zu lesen oder zu schreiben.

Ein Compiler darf beim optimieren natürlich annehmen, dass der Code korrekt ist, also unter anderem auch die "strict aliasing rule" befolgt. Das kann dann zu solchen lustigen Sachen führen. Das ist natürlich ein sinnloses konstruiertes Beispiel, aber man sieht sehr schön im Assembler-Code, dass diese Funktion grundsätzlich 42 ausgibt (Zeile 8 im asm) obwohl die beiden Zuweisungen (Zeilen 6/7 im C code) sequenced sein müssten -- der Compiler darf aber annehmen, dass Zeile 7 den Wert von *intval nicht verändert

Deshalb ist in C ein pointer-cast immer eine Stelle, die man genau überprüfen muss, ob das so auch valide ist -- ein "red flag" im Code. Also argumentiere ich, unnötige pointer-casts besser wegzulassen. In C++ ist es ein bisschen anders, hier ist es immer erlaubt, auf einen Pointer einer Basisklasse zu casten, die umgekehrte Richtung ist ebenfalls erlaubt wenn das Objekt tatsächlich den konkreteren Typ hat. Der Code oben wäre natürlich auch in C++ "Murks"