3. Char und Float im Struct 8 Byte groß?

Char und Float im Struct 8 Byte groß?

  • ?

    Das ist mir klar, nur warum hat der untere Struct dann eine Größe von eins? Warum kommt es darauf an, ob man den Basisstruct als Member definiert oder ein beliebigen anderen Struct, ob das ganze zwei oder ein Byte groß ist? Warum braucht Base im oberen Beispiel ein Byte mehr, obwohl beide leer sind?

    0
  • ?

    @Q: GCC 4.6:
    sizeof(Derived) -> 2 Byte
    sizeof(AnotherDerived) -> 1 Byte

    0
  • *

    Sinnfrei?? schrieb:

    @Q: GCC 4.6:
    sizeof(Derived) -> 2 Byte
    sizeof(AnotherDerived) -> 1 Byte

    Ich weiß. Genau das find ich ja so komisch. Beides mal erbst du von leeren basisklassen und hast einen leeren member.
    SeepJ's erklärung erklärt das irgendwie nicht vollständig^^

    0
  • ?

    Btw, MSVC++ 10 sagt, dass beides 1 Byte groß ist. Also ein Compiler Bug?

    0
  • Mod

    Sinnfrei?? schrieb:

    Btw, MSVC++ 10 sagt, dass beides 1 Byte groß ist. Also ein Compiler Bug?

    Es ist eine kann Optimierung, keine muss Optimierung.

    0
  • K

    Find' ich aber trotzdem komisch. Ich denke nicht, dass die GCC-Entwickler das mit Absicht so gemacht haben. Man sollte sie vielleicht mal drauf hinweisen...

    EBCO (empty base class optimization) ist toll. Schaut man bei libstdc++ nach, wie sie unique_ptr implementiert haben, dann sieht das in etwa so aus:

    template<class T, class Deleter = default_deleter<T> >
class unique_ptr {
  tuple<T*,Deleter> data_;
public:
  ...
};

    und da der default_deleter zustandslos (leer) ist, tuple<> über Vererbung implementiert ist, und der GCC EBCO durchführt, wird sizeof(unique_ptr<T*>)==sizeof(T*) gelten. 🙂

    0
  • *

    Tuple ist über vererbung implementiert?

    Soll das heißen, dass
    Tuple<int, int> zweimal von int erbt?

    0
  • 3

    tuple<A, B, C, D, E> erbt von tuple<B, C, D, E> erbt von tuple<C, D, E> erbt von tuple<D, E> erbt von tuple<D>.

    0
  • C
    Mod

    314159265358979 schrieb:

    tuple<A, B, C, D, E> erbt von tuple<B, C, D, E> erbt von tuple<C, D, E> erbt von tuple<D, E> erbt von tuple<D>.

    Das ist eine Möglichkeit, so macht es z.B. g++; Mehrfachvererbung wäre auch möglich:
    tuple<A,B,C> erbt dann von __tuple_element<0,A>, __tuple_element<1,B>, __tuple_element<2,C> usw.
    Möglicherweise kann das eine besser als das andere optimiert werden, das wäre dann allerdings ein reines QoI-Artefakt.

    0
  • ?

    Also lohnt es sich, einen "Bug"report zu schreiben?

    0
  • C
    Mod

    C++03 schrieb:

    1.8 The C+ + object model [intro.object]
    ...
    5 Unless it is a bit-field (9.6), a most derived object shall have a non-zero size and shall occupy one or more bytes of storage. Base class sub-objects may have zero size. An object of POD4) type (3.9) shall occupy contiguous bytes of storage.

    C++11 schrieb:

    1.8 The C++ object model [intro.object]
    ...
    6 Unless an object is a bit-field or a base class subobject of zero size, the address of that object is the address of the first byte it occupies. Two objects that are not bit-fields may have the same address if one is a subobject of the other, or if at least one is a base class subobject of zero size and they are of different types; otherwise, they shall have distinct addresses.4

    1. Under the “as-if” rule an implementation is allowed to store two objects at the same machine address or not store an object at all if the program cannot observe the difference (1.9).

    Das Verhalten von msvc ist möglicherweise beim alten Standard noch zulässig, einen Bug-Report halte ich hier nicht für besonders sinnvoll. Im Zweifelsfall ist das bei Microsoft sowieso eher ein Feature.
    Hier ist ein verwandter Report, mit Änderungsdatum März 2011. Trotzdem ist dieser Teil offenbar danach noch einmal geändert worden. Die gegenwärtigen Regeln sind also noch ziemlich neu.

    0
Anmelden zum Antworten