Bitte entweder um Korrektur der FAQ oder um Begründung der Antwort [Thema: long und POD]

*D*Evil

POD steht für Plain Old Data. Jetzt überlegst du mal wie breit/groß ein long mindestens ist und denkst dann nochmal über deinen Beitrag nach.

LordJaxom

(D)Evil schrieb:

POD steht für Plain Old Data. Jetzt überlegst du mal wie breit/groß ein long mindestens ist und denkst dann nochmal über deinen Beitrag nach.

Doch, Du magst es eindeutig, in Rätseln zu sprechen.

Swordfish

Könnte man nicht einfach sagen, ein POD ist alles, das nicht konstruiert und destruiert wird?

greetz, Swordfish

queer_boy

mich stört in dem FAQ-beitrag mehr, das

Sie sind kompatibel zu C-Strukturen, deswegen werden sie immer dort eingesetzt wo man mit C APIs/Konstrukten Arbeiten muss.

es gibt einige garantien für POD typen, die auf dieses statement hinauslaufen können, solange der entsprechende C-code vom selben (C++) compiler kompiliert wurde, und der muss nicht zwangsweise ABI-kompatibel mit C-structs sein.

@Swordfish: und keinen zuweisungsoperator hat, und keine basisklassen hat, und keine virtuellen methoden, und keine zeiger auf memberfunktionen, und keine member, die eine der vorangehenden bedingungen erfüllen.

/ps: aber ja, es geht wohl darum, dass eine POD-struktur immer zur verwendung bereit ist und sie nicht (z.b. durch einen destruktor-aufruf) plötzlich kein POD mehr ist (das ist z.b. wichtig für die goto garantie für PODS).

asc

queer_boy schrieb:

mich stört in dem FAQ-beitrag mehr, das...

Mich stört am FAQ-Beitrag deutlich das er sehr missverständlich formuliert ist, und aufgrund des Textes long kein POD ist. Dem Gegenüber steht bereits die von mir zitierte Stelle des Standards:

Arithmetic types (3.9.1), enumeration types, pointer types, and pointer to member types (3.9.2), and cvqualified versions of these types (3.9.3) are collectively called scalar types. Scalar types, POD-struct types, POD-union types (clause 9), arrays of such types and cv-qualified versions of these types (3.9.3) are collectively called POD types.

cu André
P.S: Und den Beitrag von (D)Evil find ich noch mehr erklärungsbedürftig als den FAQ-Beitrag ;P

queer_boy

asc schrieb:

queer_boy schrieb:

mich stört in dem FAQ-beitrag mehr, das...

Mich stört am FAQ-Beitrag deutlich das er sehr missverständlich formuliert ist, und aufgrund des Textes long kein POD ist. Dem Gegenüber steht bereits die von mir zitierte Stelle des Standards:

abgesehen von den rechtschreibfehlern, ja. aber um pedantisch zu sein, Gerard schreibt in seinem FAQ-beitrag auch immer nur "PODs" - was im allgemeinen die abkürzung für plain-old-data structures ist

wie auch immer, natürlich bin ich deiner meinung - der beitrag gehört gründlich überarbeitet, womöglich auch mit aussicht auf die änderung in der definition von POD im neuen standard.

P.S: Und den Beitrag von (D)Evil find ich noch mehr erklärungsbedürftig als den FAQ-Beitrag ;P

dito

camper

Ich weise mal darauf hin, dass das nicht der einzige FAQ-Beitrag zu diesem Thema ist.

Swordfish

queer_boy schrieb:

und keinen zuweisungsoperator hat, und keine basisklassen hat, und keine virtuellen methoden, und keine zeiger auf memberfunktionen, und keine member, die eine der vorangehenden bedingungen erfüllen.

Für die built-ins sind Zuweisungsoperatoren auch definiert und sind trotzdem PODs. Alles, das eine Basisklasse hat, hat zwangsläufig auf einen Konstruktor, wenn ich mich nicht ganz täusche, oder?

greetz, Swordfish

queer_boy

selbstdefiniert, ok. auch POD-strukturen haben einen zuweisungsoperator.
aber so argumentiert haben PODs auch destruktoren:

struct POD
{
  int a, b, c;
};

int main ()
{
   POD pod;
   pod.~POD();

   return 0;
}

~(und die preisfrage: wo endet pods leben?)~

camper: wenn ich mich jetzt nicht verlesen habe, fehlt "ohne zeiger auf methoden" bei deinen POD-bedingungen?

abgesehen davon fehlt in beiden beiträgen ein hinweis auf die besonderheiten von PODs jenseits von C-layoutkompatibilität.

camper

queer_boy schrieb:

aber so argumentiert haben PODs auch destruktoren:

Alle Klassen (und nur diese) haben Konstruktoren und Destruktoren, unabhängig davon, ob es sich um PODs handelt oder nicht. Es existiert eine spezielle syntaktische Form (=Pseudodestruktoraufruf), analog zum expliziten Destruktoraufruf, die mit skalaren Typen arbeit - das bedeutet aber nicht etwa im Umkehrschluss, dass Skalare ebenfalls Destruktoren hätten.

camper: wenn ich mich jetzt nicht verlesen habe, fehlt "ohne zeiger auf methoden" bei deinen POD-bedingungen?

So eine Bedingung gibt es nicht. Zeiger auf Member sind ganz normale PODs.

abgesehen davon fehlt in beiden beiträgen ein hinweis auf die besonderheiten von PODs jenseits von C-layoutkompatibilität.

Welche?

queer_boy

camper schrieb:

queer_boy schrieb:

aber so argumentiert haben PODs auch destruktoren:

Alle Klassen (und nur diese) haben Konstruktoren und Destruktoren, unabhängig davon, ob es sich um PODs handelt oder nicht. Es existiert eine spezielle syntaktische Form (=Pseudodestruktoraufruf), analog zum expliziten Destruktoraufruf, die mit skalaren Typen arbeit - das bedeutet aber nicht etwa im Umkehrschluss, dass Skalare ebenfalls Destruktoren hätten.

das weiß ich wohl, nur war meine aussage ein einwand auf swordfish ursprüngliche aussage.

camper: wenn ich mich jetzt nicht verlesen habe, fehlt "ohne zeiger auf methoden" bei deinen POD-bedingungen?

So eine Bedingung gibt es nicht. Zeiger auf Member sind ganz normale PODs.

hm ich habe da irgendetwas aus comp.std.c++ (oder so) in erinnerung, aber tatsächlich kann ich im standard nichts dazu finden. allerdings bringt mir ein POD mit zeiger auf methode für C-schnittstellen auch nichts.

abgesehen davon fehlt in beiden beiträgen ein hinweis auf die besonderheiten von PODs jenseits von C-layoutkompatibilität.

(oder zumindest, was denn das überhaupt bedeutet)

camper schrieb:

Welche?

z.b. wann und wie ein POD initialisiert wird (goto); die sache mit reinterpret_cast, und es schadet sicher nicht auszuformulieren: konversion in char* erlaubt, memcpy funktioniert wie gewünscht, ...

/edit: damit ich mich nicht nur ständig auf goto beziehe.

struct POD
{
   int a, b, c;
};

struct NoPOD
{
   int a, b, c;
   NoPOD () {}
};

void foo (int x)
{
  switch (x)
  {
  case 0:
    POD pod;
  case 42:
    cin >> pod.a;
  }
}

void bar (int y)
{
  switch (y)
  {
  case 0:
    NoPOD nopod;
  case 23:
    cin >> nopod.a;
  }
}

foo ist gut, bar ist böse.

Swordfish

queer_boy schrieb:

das weiß ich wohl, nur war meine aussage ein einwand auf swordfish ursprüngliche aussage.

Ja, war ein Schnellschuss.

greetz, Swordfish

camper

queer_boy schrieb:

abgesehen davon fehlt in beiden beiträgen ein hinweis auf die besonderheiten von PODs jenseits von C-layoutkompatibilität.

(oder zumindest, was denn das überhaupt bedeutet)

camper schrieb:

Welche?

z.b. wann und wie ein POD initialisiert wird (goto); die sache mit reinterpret_cast, und es schadet sicher nicht auszuformulieren: konversion in char* erlaubt, memcpy funktioniert wie gewünscht, ...

Das ist zumindest bei meinem Beitrag kein Versehen - es ging mir nur um eine Übersicht, um verschiedene Begriffe zu verorten - also das was, nicht: warum ein Begriff eingeführt wird. Wenn tatsächlich diese Ausführlichkeit erreicht werden sollte, wäre das eher etwas für einen Magazinartikel und schließlich müsste man sich den anderen Typen gleichermaßen ausführlich widmen. Dann könnte ich eigentlich gleich den ganzen Standard zitieren, sonst fehlt immer etwas
Der Verweis auf C-Kompatibilität ist hier auch nicht als strenge Definition zu sehen, sondern nur als Hinweis: jede Struktur/Union, die in C geschrieben wird, erscheint (soweit zulässig) bei Verwendung in einem C++ -Programm als POD-Klasse.

queer_boy

da hast du natürlich recht. wahrscheinlich ist es das beste, auf C++09 zu warten - dann brauchen die FAQ sowieso eine generalüberarbeitung.

/edit: ich persönlich finde nur den begriff C-(layout)-kompatibel so schwammig. aber was soll's.