Was bedeutet das ':' in einem typdef struct

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.