Was bedeutet das ':' in einem typdef struct

Franklin31289

Okay, danke für die Erklärung.

Ja es werden TCP/IP Pakete abgefangen und dann wird der Header ermittelt. Aber diese Syntax war mir nicht bekannt und wusste auch nicht nach was ich im Netz suchen musste.

Perfekt!

Danke für den Link

TNA

Marthog schrieb:

EDIT: Ist im Standard eigentlich festgelegt, ob die Daten im Speicher auch direkt hintereinanderliegen?
EDIT 2: Nein, es ist festgelegt, dass gepackt werden kann, aber nicht in welcher Einheitengröße und Reihenfolge.

Das würde ja bedeuten, dass die struct so gar nicht funktionieren könnte, da die Reihenfolge der Bits im Speicher anders sein könnte als bei einem IP-Header. Das wird aber dennoch oft genau so gemacht.

Marthog

Man ignoriert den Standard und vertraut darauf, dass die Compiler das gleiche machen. Das ist genauso, wie mit #pragma once als inglude-guard. Es ist im Standard so nicht festfelegt, aber trotzdem können alle Compiler das.

Marthog schrieb:

Man ignoriert den Standard und vertraut darauf, dass die Compiler das gleiche machen. Das ist genauso, wie mit #pragma once als inglude-guard. Es ist im Standard so nicht festfelegt, aber trotzdem können alle Compiler das.

Man ignoriert nicht einfach mal eben den Standard. Wozu sollte man denn dann überhaupt etwas standardisieren? Natürlich gibts immer jemanden, der meint, dass seine Variante besser ist und davon abweicht. Aber in der Regel betrifft das sehr spezielle Dinge und die allgemeine Funktionalität ist dann noch gegeben.

Auch deine letzte Aussage, dass alle Compiler das #pragma once verstehen ist falsch. Dann hast du noch nie einen anderen Compiler verwendet.

Skym0sh0

Wer kann denn #pragma once?
Und wer kanns nicht?

Da ich hauptsächlich mit Visual Studio arbeite und der das da automatisch in neue Dateien reinpflanzt, kann er das auch.
Ich meine auf der Arbeit mal gesehen zu haben, dass der GCC das auch kann.

Wer kanns denn nicht?

Marthog

#pragma once weist den Präprozessor an, die Datei nur einmal zu inkluden, was man normalerweise mit

#ifndef PROJECT_FILENAME_H_INCLUDED
#define PROJECT_FILENAME_H_INCLUDED

// ...

#endif

macht.
Alle gängigen Compiler können das, aber es ist kein Teil des Standards, also darf es einen vollkommen korrekten Compiler geben, der das nicht kann.
http://de.wikipedia.org/wiki/Include-Guard

Marthog

#pragma once weist den Präprozessor an, die Datei nur einmal zu inkluden, was man normalerweise mit

#ifndef PROJECT_FILENAME_H_INCLUDED
#define PROJECT_FILENAME_H_INCLUDED

// ...

#endif

macht.
Alle gängigen Compiler können das, aber es ist kein Teil des Standards, also darf es einen vollkommen korrekten Compiler geben, der das nicht kann.
http://de.wikipedia.org/wiki/Include-Guard

Wo ist das Problem? Ich gebe in meinen emacs "once + TAB" ein und er macht draus

#ifndef PROJECT_FILENAME_H_INCLUDED
#define PROJECT_FILENAME_H_INCLUDED

// <- hier steht dann der Cursor

#endif /* PROJECT_FILENAME_H_INCLUDED */

Ich kann sogar "oncens + TAB" eingeben, dann macht er mir

#ifndef PROJECT_FILENAME_H_INCLUDED
#define PROJECT_FILENAME_H_INCLUDED

namespace project
{
  // <- hier steht dann der Cursor
}
#endif /* PROJECT_FILENAME_H_INCLUDED */

Gibt eigentlich keinen Grund, #pragma once zu verwenden, Schreibaufwand ist kein Grund.

Nathan

Disclaimer: Ich verwende #pragma once nicht.

Naja, das Problem mit den Includeguards ist halt das Makro.
Da braucht man schon so etwas wie
MYPROJECT_MAINFOLDER_SUBFOLDER_FILENAME_HPP_INCLUDED oder so.
Aber einen wirklichen Grund für #pragma once gibt es nicht, abgesehen vielleicht vom einfacheren Lesen o.ä.

Marthog

Dafür: Einfach zu lesen, schnell zu schreiben,man spart sich ein Makro und hat auch keine Makroüberschneidungen.

Dagegen: Es ist kein Standard und der Compiler müsste beim Überprüfen des Dateipfads auch Abkürzungen und Hardlinks mitbeachten.

Ich finde das Kontraargument aber unnötig (wer benutzt schon Hardlinks in Projektverzeichnissen und wenn doch, dann selbst Schuld) und hätte gerne #pragma once im Standard.

Sone

Der Standard sagt:

A memory location is either an object of scalar type or a maximal sequence of adjacent bit-fields all having non-zero width.

Zwei aneinander liegende Bitfiels sind also eine memory location.
Weiter:

Thus a bit-field and an adjacent non-bit-field are in separate memory locations, and therefore can be concurrently updated by two threads of execution without interference. The same applies to two bit-fields, if one is declared inside a nested struct declaration and the other is not, or if the two are separated by a zero-length bit-field declaration, or if they are separated by a non-bit-field declaration. It is not safe to concurrently update two bit-fields in the same struct if all fields between them are also bit-fields of non-zero width.

Das impliziert bereits, dass zwei Bitfields in einem Byte liegen können.

Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit.

Wutz

Marthog schrieb:

Man ignoriert den Standard und vertraut darauf, dass die Compiler das gleiche machen. Das ist genauso, wie mit #pragma once als inglude-guard. Es ist im Standard so nicht festfelegt, aber trotzdem können alle Compiler das.

Aus welchem Hinterwäldlerbergdorf bist du denn entsprungen?
Du hast keine Ahnung, also halte die Klappe mit deinem zusammengegoogelten Halbwissen und begrenztem Horizont und trolle dich.

Wutz schrieb:

Du hast keine Ahnung, also halte die Klappe mit deinem zusammengegoogelten Halbwissen und begrenztem Horizont und trolle dich.

Wutz, du bist ein Idiot. Halt den Mund wenn es nicht freundlicher geht. Auf deine unproduktiven und überheblichen Kommentare kann hier jeder gern verzichten, eine Sperrung deines Accounts wäre nur gerechtfertigt. Der einzige Troll in diesem Thread bist am ehesten du.

otze

Marthog schrieb:

Man ignoriert den Standard und vertraut darauf, dass die Compiler das gleiche machen.

Hab ich mal gemacht, war ne scheiß idee. Bei 5 compilern liefs, der 6. war vc08 der bestimmte Kleinigkeiten in der Standardbibliothek grotesk dumm implementiert. Seitdem halte ich mich an den Standard, dann kann ich wenigstens bei solchen Bugreports antworten, das es ein Problem des Compilers ist

Marthog

Sone schrieb:

Das impliziert bereits, dass zwei Bitfields in einem Byte liegen können.

Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit.

Können, ja, sonst würde das ja niemand so machen. Es ging mir aber darum, ob festgelegt ist, ob die Bit-fields immer gleichartig hintereinander liegen müssen und ich habe

Note: Bit-fields straddle allocation units on some machines and not
on others. Bit-fields are assigned right-to-left on some machines, left-to-right on others. —end note

so verstanden, dass es von der Implementierung abhängt.

Sone

Marthog schrieb:

Sone schrieb:

Das impliziert bereits, dass zwei Bitfields in einem Byte liegen können.

Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit.

Können, ja, sonst würde das ja niemand so machen.

Aus meinem Post ist das zwar nicht ersichtlich, aber ich bezog mich auf das obere Zitat, in dem die thread-safety erwähnt ist. Wenn man nicht auf eine memory location in zwei Threads zugreifen kann, heißt das für mich, dass man möglicherweise auf dieselben Bytes zugreift.