sizeof auf strukturmember

Grrrr schrieb:
> Vlad Tepesch schrieb:
>> gibt es keine Möglichkeit diese Größe ohne eine Instanz zu ermitteln?
>
> Klar.
> ...

Ja gut, das ist auch nur ein Workaround, keine Lösung.
Erfordert zudem eine Anpassung des Headers in dem die Struktur definiert 
ist.

wenn ich mich recht erinnere gibt sizeof(...) immer nur die größe des 
typs, ganz unabhängig vom wert zurück.

dynamische objekte gibts hier nicht.

eventuell wäre folgendes denkbar:

1

uint32_t teilgroesseC  = sizeof( ((A*)0)->c );

sieht zugegebenermaßen nicht sehr schön aus, sollte aber keine 
Laufzeitprobleme geben, da sizeof zur Compiletime aufgelöst wird.

Di Pi schrieb:
> wenn ich mich recht erinnere gibt sizeof(...) immer nur die größe des
> typs, ganz unabhängig vom wert zurück.
>
> dynamische objekte gibts hier nicht.

Das ist klar.
Es hat niemand etwas anderes behauptet.

Vlad Tepesch schrieb:
> eventuell wäre folgendes denkbar:
>
>

1

> uint32_t teilgroesseC  = sizeof( ((A*)0)->c );

2

>

>
> sieht zugegebenermaßen nicht sehr schön aus,

müsste gehen.

> sollte aber keine
> Laufzeitprobleme geben, da sizeof zur Compiletime aufgelöst wird.

Ist auch vom C-Standard gedeckt (oder wars der C++ Standard?) Irgendwo 
bei den Pointern gibt es einen Passus, dass bei einem sizeof das 
'vermeintliche Dereferenzieren' eines 0 Pointers erlaubt ist und dass 
das kein echtes Dereferenzieren darstellt sondern nur von der 
Schreibweise her so aussieht.

(Müsste C++ sein, da in C der sizeof ja mitlerweile nicht mehr 
notwendigerweise eine Compiletime Angelegenheit ist)

Grrrr schrieb:
>

1

uint32_t teilgroesseC  = sizeof( ((A*)0)->c );

2

>

>
> Hauptsache keine Workarounds. Nee, klar. ;-)
> Der nächste Lint-Lauf wird dann auch noch was dazu sagen.

Seine Lösung ist trotzdem besser als deine.

Wenn immer möglich möchte man beim sizeof die Variable angeben und nicht 
den Datentyp.
Sonst hätte er ja auch gleich

uint32_t teilgroesseC2  = sizeof( int );

schreiben können, wohlwissend dass A.c ein int ist. Nur: Ändert A.c 
seinen Datentyp, so passt sich die Pointer Lösung selbst an. In diesem 
Sinne wird daher mehr Arbeit an den Compiler delegiert, was gut ist, 
weil der bei solchen Sachen keinen Fehler macht.

Karl heinz Buchegger schrieb:
> (Müsste C++ sein, da in C der sizeof ja mitlerweile nicht mehr
> notwendigerweise eine Compiletime Angelegenheit ist)

Ist das nicht bei c++ so, dass der sizeof Laufzeitanhängig sein kann?
bei c gibts doch kein RTI
Wäre das bei C der Fall, würde ja aber heißen, das das dereferenzieren 
an der Stelle doch falsch wär.

der Visual c++ compiler schluckt die sache mit dem sizeof(A.c) keine 
Ahnung, ob das eine Eigenheit oder C++ Standard ist. Hab grad kein 
visual C projekt und kein gcc c++ projekt zu Hand.

Vlad Tepesch schrieb:
> Karl heinz Buchegger schrieb:
>> (Müsste C++ sein, da in C der sizeof ja mitlerweile nicht mehr
>> notwendigerweise eine Compiletime Angelegenheit ist)
>
> Ist das nicht bei c++ so, dass der sizeof Laufzeitanhängig sein kann?
> bei c gibts doch kein RTI

Aber bei C gibt es seit C99 dynamische Arrays

int foo( int i )
{
  char array[i];

  j = sizeof( array );
}

Sauger schrieb:
> schau dir mal offsetof(x,y) an.

Lustigerweise ist das Macro offsetof bei GCC genau mit Vlads Methode der 
Dereferenzierung eines gecasteten Null-Pointers definiert.

Sauger schrieb:
> offsetof(struct,Element "Dahinter") minus offsetof(struct,Element
> "Davor") lassen sich längen berechnen.

Das ist natürlich auch nicht das Wahre, da der Code dann abhängig davon 
ist, dass die Strukturmember immer hintereinander sind und nicht 
verschoben werden.

Sauger schrieb:
> Vlad Tepesch schrieb:
>> Das ist natürlich auch nicht das Wahre, da der Code dann abhängig davon
>> ist, dass die Strukturmember immer hintereinander sind und nicht
>> verschoben werden.
>
> Welcher Entwickler macht denn sowas? Die Konsequenzen beim umstellen
> sollte man schon im Hinterkopf haben :-)

Ich glaube du hast das Missverstanden. Was ist, wenn man die 
Konsequenzen grad nicht im Kopf hat? Und eben was umstellt und einen Tag 
nach dem Fehler sucht?

Sauger schrieb:
> Vlad Tepesch schrieb:
>> Das ist natürlich auch nicht das Wahre, da der Code dann abhängig davon
>> ist, dass die Strukturmember immer hintereinander sind und nicht
>> verschoben werden.
>
> Welcher Entwickler macht denn sowas? Die Konsequenzen beim umstellen
> sollte man schon im Hinterkopf haben :-)

Idealerweise kann man in einer Struktur umstellen wie man lustig ist, 
solange diese Struktur nicht als Bindeglied zu einem anderen Programm 
fungiert, also eine I/O Struktur ist.
Bei letzterem heißt es sowieso besondere Vorsicht walten zu lassen und 
da ist dann auch ein Kommentar angebracht, dass die Struktur genauso 
aussieht wie sie aussieht, weil sich fremde Programme oder Fileaufbauten 
darauf verlassen.

In allen anderen Fällen sollte man sich der Konsequenzen eines 
Strukturumbaus bewusst sein, wie du richtig sagst aber den falschen 
Schluss ziehst, und den Code so aufbauen, dass sich eine Änderung nicht 
auswirkt.

Karl heinz Buchegger schrieb:
> Idealerweise kann man in einer Struktur umstellen wie man lustig ist,

das sollte nicht der Ideao

Karl heinz Buchegger schrieb:
> Aber bei C gibt es seit C99 dynamische Arrays

gibt es eigentlich schon (nach 11 Jahren) Compiler, die das können?

Vlad Tepesch schrieb:

> Karl heinz Buchegger schrieb:
>> Aber bei C gibt es seit C99 dynamische Arrays
>
> gibt es eigentlich schon (nach 11 Jahren) Compiler, die das können?

GCC