Nach dem FAQ-Eintrag ist long ein Built-in, aber kein POD (Da es kein benutzerdefininierter Typ wie struct, class... ist).
Nach dem Wikipediaartikel wäre long wiederum ein POD.

Entweder ist die Formulierung in der FAQ überarbeitungswürdig, und es gehört zur Klarstellung auch noch hinein das Build-Ins alleine für sich POD's sind, oder die Antworten sind falsch.

cu André
P.S: Ich würde nach dem Standard (3.9.10) eher sagen das der FAQ-Beitrag leicht überarbeitet gehört um dies (Buildin ist auch ein POD) besser herauslesen zu können.

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.

1.)

Das Gegenteil von Built-ins sind Klassen, Structs, Unions, Enums usw. sie werden vom Benutzer definiert.

Was soll in diesem Zusammenhang der Begriff Gegenteil bedeuten?

2.)

PODs sind Benutzerdefinierte Typen die:

Nicht benutzerdefinierte Typen können auch PODs sein.

3.)

Etwas ausführlicher: http://www-cpd.fnal.gov/personal/wb/boost/ISOcxx/doc/POD.html

Der Link ist tot.

D.h. der Artikel bräuchte (nicht nur) ein leichte Überarbeitung.

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.

greetz, Swordfish

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).

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 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

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

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.

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 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.

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

Ja, war ein Schnellschuss.

greetz, Swordfish

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.

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