Design für vector-Klasse gesucht

[Fytch]

rapso schrieb:

otze schrieb:

@rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

[rapso]

asfdlol schrieb:

rapso schrieb:

otze schrieb:

@rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

ich seh nicht wo etwas nicht POD sein soll.

[Fytch]

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

otze schrieb:

@rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

ich seh nicht wo etwas nicht POD sein soll.

ist nicht pod, da:
1. vererbung
2. member in private

[rapso]

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

otze schrieb:

@rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

ich seh nicht wo etwas nicht POD sein soll.

ist nicht pod, da:
1. vererbung
2. member in private

fuers layouten der klassen sind es PODs, es gibt keine member oder sonst etwas was ein alignment bzw. padding enforcen wuerde auf nachfolgende elemente.
solange du nicht per hand eingreifst ist das layout wohl definiert und wird von jedem c++ compiler gleich umgesetzt.

[Fytch]

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

otze schrieb:

@rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

ich seh nicht wo etwas nicht POD sein soll.

ist nicht pod, da:
1. vererbung
2. member in private

fuers layouten der klassen sind es PODs, es gibt keine member oder sonst etwas was ein alignment bzw. padding enforcen wuerde auf nachfolgende elemente.
solange du nicht per hand eingreifst ist das layout wohl definiert und wird von jedem c++ compiler gleich umgesetzt.

das stimmt in meinen augen für vererbung nicht:

N1905 §10.0.4 schrieb:

The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified. [Note: a
derived class and its base class subobjects can be represented by a directed acyclic graph (DAG) where an arrow means
“directly derived from.” A DAG of subobjects is often referred to as a “subobject lattice.”
Base
↑
Derived1
↑
Derived2
5 The arrows need not have a physical representation in memory. — end note ]

[rapso]

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

otze schrieb:

@rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

ich seh nicht wo etwas nicht POD sein soll.

ist nicht pod, da:
1. vererbung
2. member in private

fuers layouten der klassen sind es PODs, es gibt keine member oder sonst etwas was ein alignment bzw. padding enforcen wuerde auf nachfolgende elemente.
solange du nicht per hand eingreifst ist das layout wohl definiert und wird von jedem c++ compiler gleich umgesetzt.

das stimmt in meinen augen für vererbung nicht:

N1905 §10.0.4 schrieb:

The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified. [Note: a
derived class and its base class subobjects can be represented by a directed acyclic graph (DAG) where an arrow means
“directly derived from.” A DAG of subobjects is often referred to as a “subobject lattice.”
Base
↑
Derived1
↑
Derived2
5 The arrows need not have a physical representation in memory. — end note ]

das ist aber ein POD fuers layout.

A type that is standard-layout means that it orders and packs its members in a way that is compatible with C. A class or struct is standard-layout, by definition, provided:
It has no virtual functions
It has no virtual base classes
All its non-static data members have the same access control (public, private, protected)
All its non-static data members, including any in its base classes, are in the same one class in the hierarchy
The above rules also apply to all the base classes and to all non-static data members in the class hierarchy
It has no base classes of the same type as the first defined non-static data member

A class/struct/union is considered POD if it is trivial, standard-layout, and all of its non-static data members and base classes are PODs.

[Fytch]

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

otze schrieb:

@rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

ich seh nicht wo etwas nicht POD sein soll.

ist nicht pod, da:
1. vererbung
2. member in private

fuers layouten der klassen sind es PODs, es gibt keine member oder sonst etwas was ein alignment bzw. padding enforcen wuerde auf nachfolgende elemente.
solange du nicht per hand eingreifst ist das layout wohl definiert und wird von jedem c++ compiler gleich umgesetzt.

das stimmt in meinen augen für vererbung nicht:

N1905 §10.0.4 schrieb:

The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified. [Note: a
derived class and its base class subobjects can be represented by a directed acyclic graph (DAG) where an arrow means
“directly derived from.” A DAG of subobjects is often referred to as a “subobject lattice.”
Base
↑
Derived1
↑
Derived2
5 The arrows need not have a physical representation in memory. — end note ]

das ist aber ein POD fuers layout.

A type that is standard-layout means that it orders and packs its members in a way that is compatible with C. A class or struct is standard-layout, by definition, provided:
It has no virtual functions
It has no virtual base classes
All its non-static data members have the same access control (public, private, protected)
All its non-static data members, including any in its base classes, are in the same one class in the hierarchy
The above rules also apply to all the base classes and to all non-static data members in the class hierarchy
It has no base classes of the same type as the first defined non-static data member

A class/struct/union is considered POD if it is trivial, standard-layout, and all of its non-static data members and base classes are PODs.

der von mir gequotete paragraph schliesst layout-pods nicht aus und deiner macht keine aussage bezüglich der anordnung - von im beispiel x, y, z und w - in der most-derived-class.

[rapso]

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

otze schrieb:

@rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

ich seh nicht wo etwas nicht POD sein soll.

ist nicht pod, da:
1. vererbung
2. member in private

fuers layouten der klassen sind es PODs, es gibt keine member oder sonst etwas was ein alignment bzw. padding enforcen wuerde auf nachfolgende elemente.
solange du nicht per hand eingreifst ist das layout wohl definiert und wird von jedem c++ compiler gleich umgesetzt.

das stimmt in meinen augen für vererbung nicht:

N1905 §10.0.4 schrieb:

The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified. [Note: a
derived class and its base class subobjects can be represented by a directed acyclic graph (DAG) where an arrow means
“directly derived from.” A DAG of subobjects is often referred to as a “subobject lattice.”
Base
↑
Derived1
↑
Derived2
5 The arrows need not have a physical representation in memory. — end note ]

das ist aber ein POD fuers layout.

A type that is standard-layout means that it orders and packs its members in a way that is compatible with C. A class or struct is standard-layout, by definition, provided:
It has no virtual functions
It has no virtual base classes
All its non-static data members have the same access control (public, private, protected)
All its non-static data members, including any in its base classes, are in the same one class in the hierarchy
The above rules also apply to all the base classes and to all non-static data members in the class hierarchy
It has no base classes of the same type as the first defined non-static data member

A class/struct/union is considered POD if it is trivial, standard-layout, and all of its non-static data members and base classes are PODs.

der von mir gequotete paragraph schliesst layout-pods nicht aus und deiner macht keine aussage bezüglich der anordnung - von im beispiel x, y, z und w - in der most-derived-class.

steht da, es ist C order.

In c werden alle memeber der deklarationsreihenfolge nach angeordnet.

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.

[Fytch]

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

otze schrieb:

@rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

ich seh nicht wo etwas nicht POD sein soll.

ist nicht pod, da:
1. vererbung
2. member in private

fuers layouten der klassen sind es PODs, es gibt keine member oder sonst etwas was ein alignment bzw. padding enforcen wuerde auf nachfolgende elemente.
solange du nicht per hand eingreifst ist das layout wohl definiert und wird von jedem c++ compiler gleich umgesetzt.

das stimmt in meinen augen für vererbung nicht:

N1905 §10.0.4 schrieb:

The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified. [Note: a
derived class and its base class subobjects can be represented by a directed acyclic graph (DAG) where an arrow means
“directly derived from.” A DAG of subobjects is often referred to as a “subobject lattice.”
Base
↑
Derived1
↑
Derived2
5 The arrows need not have a physical representation in memory. — end note ]

das ist aber ein POD fuers layout.

A type that is standard-layout means that it orders and packs its members in a way that is compatible with C. A class or struct is standard-layout, by definition, provided:
It has no virtual functions
It has no virtual base classes
All its non-static data members have the same access control (public, private, protected)
All its non-static data members, including any in its base classes, are in the same one class in the hierarchy
The above rules also apply to all the base classes and to all non-static data members in the class hierarchy
It has no base classes of the same type as the first defined non-static data member

A class/struct/union is considered POD if it is trivial, standard-layout, and all of its non-static data members and base classes are PODs.

der von mir gequotete paragraph schliesst layout-pods nicht aus und deiner macht keine aussage bezüglich der anordnung - von im beispiel x, y, z und w - in der most-derived-class.

steht da, es ist C order.

In c werden alle memeber der deklarationsreihenfolge nach angeordnet.

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.

da steht dass es mit der art wie es in C gemacht wird kompatibel ist. daraus einen schluss für vererbung zu folgern halte ich für übermütig da es in c natürlich keine vererbung gab.

[knivil]

Quote war 4tw!

[otze]

rapso schrieb:

[...]
All its non-static data members, including any in its base classes, are in the same one class in the hierarchy
[..]

betrachten wir den Code nochmal genauer:

//Klassen wie Vector2D, Vector3D, Vector4D
class Vector2D_
{
  float x,y;
public:
 float& At(size_t Idx){return Idx==1?y:x;}
};
class Vector3D_ : public Vector2D_
{
 float z;
public:
 float& At(size_t Idx){return Idx==2?z:Vector2D_::At(Idx);}
};

trifft das hier zu? z ist in einer anderen klasse als x und y. oder leg ich den Teil gerade falsch aus?

[dot]

Der C++ Standard garantiert im Fall eines standard layout struct zwar, dass die Member in Deklarationsreihenfolge im Speicher liegen, das ist aber nicht hinreichend für lineares Layout der Member. Zumindest afaik gibt es, von Arrays abgesehen, keinen standardkonformen Weg, dies sicherzustellen. Falls jemand tatsächlich einen standardkonformen Weg kennt, so wäre ich ebenfalls sehr daran interessiert, suche seit Jahren nach einer Lösung für das Problem...

[hustbaer]

@dot
Geht's dir hier um das sog. "structure packing"? Also dass bei

struct foo { char c; int i; };

üblicherweise sizeof(int) - 1 Bytes zwischen c und i freigelassen werden?

Vielleicht sollte man dazu einfach das #pragma pack von MSVC standardisieren.

[dot]

hustbaer schrieb:

@dot
Geht's dir hier um das sog. "structure packing"? Also dass bei

struct foo { char c; int i; };

üblicherweise sizeof(int) - 1 Bytes zwischen c und i freigelassen werden?

Mir geht es vor allem darum, dass der Standard keine Garanie bietet. Dass es unter allen möglichen Compilern natürlich trotzdem funktionieren wird, ist eine andere Geschichte...

hustbaer schrieb:

Vielleicht sollte man dazu einfach das #pragma pack von MSVC standardisieren.

Zumindest afaik unterstützten die wenigsten Architekturen unaligned Memory Access, x86 is da eher eine Ausnahme als die Regel und selbst unter x86 geht das nur bedingt. Und bereits unter x86/MSVC bedeutet #pragma pack potentiell weniger effizienter Code. Das zu standardisieren, halte ich für sehr problematisch. Selbst wenn man den Compiler Code generieren ließe, der die einzelnen Bytes aus größeren Blöcken abschält, wird man z.B. im Zusammenhang mit Concurrency dann wohl auf Probleme ähnlich zu denen mit Bitfeldern stoßen. Und selbst wenn wir so etwas wie #pragma pack hätten, haben wir unser eigentliches Problem (wir wüden gerne per Name und per Index zugreifen) noch nicht gelöst...

Wenn du mich fragst, wäre es sinnvoller, einfach im Standard zu garantieren, dass aufeinanderfolgende struct Member von gleichem Typ per union auf ein Array aliasen dürfen und umgekehrt. Es gibt ja bereits in C++11 die Sache mit standard layout unions von standard layout structs mit einer common initial sequence. Die ist nur leider für unseren Fall hier noch nicht ausreichend...

[fail0r]

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

otze schrieb:

@rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

ich seh nicht wo etwas nicht POD sein soll.

ist nicht pod, da:
1. vererbung
2. member in private

fuers layouten der klassen sind es PODs, es gibt keine member oder sonst etwas was ein alignment bzw. padding enforcen wuerde auf nachfolgende elemente.
solange du nicht per hand eingreifst ist das layout wohl definiert und wird von jedem c++ compiler gleich umgesetzt.

das stimmt in meinen augen für vererbung nicht:

N1905 §10.0.4 schrieb:

The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified. [Note: a
derived class and its base class subobjects can be represented by a directed acyclic graph (DAG) where an arrow means
“directly derived from.” A DAG of subobjects is often referred to as a “subobject lattice.”
Base
↑
Derived1
↑
Derived2
5 The arrows need not have a physical representation in memory. — end note ]

das ist aber ein POD fuers layout.

A type that is standard-layout means that it orders and packs its members in a way that is compatible with C. A class or struct is standard-layout, by definition, provided:
It has no virtual functions
It has no virtual base classes
All its non-static data members have the same access control (public, private, protected)
All its non-static data members, including any in its base classes, are in the same one class in the hierarchy
The above rules also apply to all the base classes and to all non-static data members in the class hierarchy
It has no base classes of the same type as the first defined non-static data member

A class/struct/union is considered POD if it is trivial, standard-layout, and all of its non-static data members and base classes are PODs.

der von mir gequotete paragraph schliesst layout-pods nicht aus und deiner macht keine aussage bezüglich der anordnung - von im beispiel x, y, z und w - in der most-derived-class.

steht da, es ist C order.

In c werden alle memeber der deklarationsreihenfolge nach angeordnet.

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.

da steht dass es mit der art wie es in C gemacht wird kompatibel ist. daraus einen schluss für vererbung zu folgern halte ich für übermütig da es in c natürlich keine vererbung gab.

Du hast eine interesante Haltung, aber der zu folgen ist noch übermütiger.

[volkard]

fail0r schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

otze schrieb:

@rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

ich seh nicht wo etwas nicht POD sein soll.

ist nicht pod, da:
1. vererbung
2. member in private

fuers layouten der klassen sind es PODs, es gibt keine member oder sonst etwas was ein alignment bzw. padding enforcen wuerde auf nachfolgende elemente.
solange du nicht per hand eingreifst ist das layout wohl definiert und wird von jedem c++ compiler gleich umgesetzt.

das stimmt in meinen augen für vererbung nicht:

N1905 §10.0.4 schrieb:

The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified. [Note: a
derived class and its base class subobjects can be represented by a directed acyclic graph (DAG) where an arrow means
“directly derived from.” A DAG of subobjects is often referred to as a “subobject lattice.”
Base
↑
Derived1
↑
Derived2
5 The arrows need not have a physical representation in memory. — end note ]

das ist aber ein POD fuers layout.

A type that is standard-layout means that it orders and packs its members in a way that is compatible with C. A class or struct is standard-layout, by definition, provided:
It has no virtual functions
It has no virtual base classes
All its non-static data members have the same access control (public, private, protected)
All its non-static data members, including any in its base classes, are in the same one class in the hierarchy
The above rules also apply to all the base classes and to all non-static data members in the class hierarchy
It has no base classes of the same type as the first defined non-static data member

A class/struct/union is considered POD if it is trivial, standard-layout, and all of its non-static data members and base classes are PODs.

der von mir gequotete paragraph schliesst layout-pods nicht aus und deiner macht keine aussage bezüglich der anordnung - von im beispiel x, y, z und w - in der most-derived-class.

steht da, es ist C order.

In c werden alle memeber der deklarationsreihenfolge nach angeordnet.

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.

da steht dass es mit der art wie es in C gemacht wird kompatibel ist. daraus einen schluss für vererbung zu folgern halte ich für übermütig da es in c natürlich keine vererbung gab.

Du hast eine interesante Haltung, aber der zu folgen ist noch übermütiger.

Sehe ich auch so.
~Wollte eigentlich mal nur den Fullquote weiterbringen, wie tief schaffen es Forensoftware und Browser wohl?~

[hustbaer]

dot schrieb:

Wenn du mich fragst, wäre es sinnvoller, einfach im Standard zu garantieren, dass aufeinanderfolgende struct Member von gleichem Typ per union auf ein Array aliasen dürfen und umgekehrt. Es gibt ja bereits in C++11 die Sache mit standard layout unions von standard layout structs mit einer common initial sequence. Die ist nur leider für unseren Fall hier noch nicht ausreichend...

Ach den Teil meinst du.
Ja, das wäre vermutlich sinnvoll!

Das mit non-alinged Zugriffen ist natürlich doof wenn das die meisten CPUs nicht können. Ich hab' mich mit dem Thema ehrlich gesagt nicht wirklich befasst, ich hätte angenommen dass es eher unproblematisch ist.
In dem Fall macht es wohl weniger Sinn #pragma pack zu standardisieren. Weil ich nur zwei Möglichkeiten sehe, die beide nicht gut sind.

1. Der Standard schreibt keine Werte vor die unterstützt werden müssen. Ist dann doof, weil nur sehr begrenzt nützlich.

2. Der Standard schreibt den Wertebereich vor (z.B. alle 2^N von 1 bis 16), und die Compiler müssen dann u.U. langsamen Code generieren. Wenn sich alle Programmierer über den Impact im klaren wären, wäre das OK. Weil immer noch nützlich in vielen Situationen. z.B. wenn man bestimmte Binärformate parsen oder schreiben muss - da wäre dann egal dass der Code nicht superschnell läuft, weil der Code den man sonst schreiben müsste es auch nicht schneller machen wird. Nur dummerweise kann man sich sicher sein, dass viele Programmierer es misbrauchen werden.

Schade.

[fullquote_plz]

hustbaer schrieb:

Nur dummerweise kann man sich sicher sein, dass viele Programmierer es misbrauchen werden.

Schade.

Wenn Missbrauchsgefahr ein Argument wäre, etwas nicht anzubieten, würde C++ nicht existieren und die [quote]-Funktion des Forums auch nicht:

volkard schrieb:

fail0r schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

asfdlol schrieb:

rapso schrieb:

otze schrieb:

@rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

ich seh nicht wo etwas nicht POD sein soll.

ist nicht pod, da:
1. vererbung
2. member in private

fuers layouten der klassen sind es PODs, es gibt keine member oder sonst etwas was ein alignment bzw. padding enforcen wuerde auf nachfolgende elemente.
solange du nicht per hand eingreifst ist das layout wohl definiert und wird von jedem c++ compiler gleich umgesetzt.

das stimmt in meinen augen für vererbung nicht:

N1905 §10.0.4 schrieb:

The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified. [Note: a
derived class and its base class subobjects can be represented by a directed acyclic graph (DAG) where an arrow means
“directly derived from.” A DAG of subobjects is often referred to as a “subobject lattice.”
Base
↑
Derived1
↑
Derived2
5 The arrows need not have a physical representation in memory. — end note ]

das ist aber ein POD fuers layout.

A type that is standard-layout means that it orders and packs its members in a way that is compatible with C. A class or struct is standard-layout, by definition, provided:
It has no virtual functions
It has no virtual base classes
All its non-static data members have the same access control (public, private, protected)
All its non-static data members, including any in its base classes, are in the same one class in the hierarchy
The above rules also apply to all the base classes and to all non-static data members in the class hierarchy
It has no base classes of the same type as the first defined non-static data member

A class/struct/union is considered POD if it is trivial, standard-layout, and all of its non-static data members and base classes are PODs.

der von mir gequotete paragraph schliesst layout-pods nicht aus und deiner macht keine aussage bezüglich der anordnung - von im beispiel x, y, z und w - in der most-derived-class.

steht da, es ist C order.

In c werden alle memeber der deklarationsreihenfolge nach angeordnet.

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.

da steht dass es mit der art wie es in C gemacht wird kompatibel ist. daraus einen schluss für vererbung zu folgern halte ich für übermütig da es in c natürlich keine vererbung gab.

Du hast eine interesante Haltung, aber der zu folgen ist noch übermütiger.

Sehe ich auch so.
~Wollte eigentlich mal nur den Fullquote weiterbringen, wie tief schaffen es Forensoftware und Browser wohl?~

[volkard]

hustbaer schrieb:

Wenn sich alle Programmierer über den Impact im klaren wären, wäre das OK.

Sind sie sich nicht. Vielleicht baut nächstes Jahr einer einen Supa-Dupa-Prozessor (nennen wir ihn einfach mal Itanium-Pro), der komplett alte Zöpfe abschneidet (und deswegen stromsparender als ARM und schneller als Intel-amd64 wird), der misalignte Zugriffe schlicht nicht unterstützt. Dann fliegt ne Hardware-Exception und das BS *kann* gerne den Code anschauen und per Software solche Zugriffe emulieren, kostet halt 1000 Takte pro misaligned-Zugriff.

[blard]

Ist das nicht alles eine ein akademische Diskussion? In der Realität benutzt jeder einen simplen struct der Form

struct vec2{ 
 float x, y; 
 float& operator[](int i){assert(x < 2); assert(x >= 0); return (&x)[i];}
};

mit ein paar praktischen Konstruktoren und überladenenen Operatoren ohne sinnlosen template unsinn und unions usw. Das einzige wozu das führt ist weniger Übersicht im Debugger, weil man in MSDEV/Xcode mehr aufklappen muss, länge namen hat und der Compiler langsamer wird.

Und da man Vektoren nur für 2D, 3D, 4D braucht kann man das auch mal eben kopieren. Für Quaternionen und Plückercoordinaten kann man die templates eh kaum nutzen.

Beispiele von erfolgreicher Software die vektoren ohne komischen c++ voodoo hat:

Doom4 (idTech4): https://github.com/TTimo/doom3.gpl/blob/master/neo/idlib/math/Vector.h

C4 Engine: http://www.terathon.com/docs/Math/Vector2D.html

Torque3D Engine: https://github.com/GarageGames/Torque3D/blob/master/Engine/source/math/mPoint2.h

ogre: https://github.com/ehsan/ogre/blob/master/OgreMain/include/OgreVector2.h

ilmmath (Industrial Light & Magic): https://github.com/openexr/openexr/blob/master/IlmBase/Imath/ImathVec.h

tgt (Benutzt zur medizinischen Visualisierung): https://github.com/lathen/voreen/blob/master/ext/tgt/vector.h

(+ diverse Lösungen, die nicht ohne lizenzen einsehbar sind)