wat is de afmeting van deze structuur? en waarom?

het volgende programma geeft output 4. Ik dacht dat het 8 sizeof (int) + sizeof (unsigned int) zal uitvoeren

#include
#include
int main()
{
        struct node
        {
                int a;
                struct node * next;
        };
        struct node * p= (struct node *) malloc( sizeof( struct node));
        printf("%d", sizeof( p));
}
1
U neemt het formaat van de aanwijzer in plaats van het object zelf.
toegevoegd de auteur Mysticial, de bron
Het is ook belangrijk om te weten of u dit compileert voor 32-bits of 64-bits, want dat maakt een verschil hoe groot de int en verwijzingen zijn.
toegevoegd de auteur Raceimaztion, de bron
Het is ook belangrijk om te weten of u dit compileert voor 32-bits of 64-bits, want dat maakt een verschil hoe groot de int en verwijzingen zijn.
toegevoegd de auteur Raceimaztion, de bron

6 antwoord

In deze code is p een aanwijzer, dus u drukt alleen het formaat van een aanwijzer af (wat blijkbaar 4 bytes is in uw compiler/OS-combinatie). Als u de grootte van de structuur wilt, moet u sizeof (* p) afdrukken. Ook, zoals werd opgemerkt, zal het gebruik van "% d" voor een size_t niet altijd werken ("% zu" is correct, hoewel% d op de meeste compilers/besturingssystemen in de echte wereld zal voorkomen). Je moet er ook niet van uitgaan dat de grootte van de structuur "zou moeten zijn" 8. Pointers kunnen groter zijn, of de compiler kan de structuur op een vreemde manier opvullen of uitlijnen.

2
toegevoegd

In deze code is p een aanwijzer, dus u drukt alleen het formaat van een aanwijzer af (wat blijkbaar 4 bytes is in uw compiler/OS-combinatie). Als u de grootte van de structuur wilt, moet u sizeof (* p) afdrukken. Ook, zoals werd opgemerkt, zal het gebruik van "% d" voor een size_t niet altijd werken ("% zu" is correct, hoewel% d op de meeste compilers/besturingssystemen in de echte wereld zal voorkomen). Je moet er ook niet van uitgaan dat de grootte van de structuur "zou moeten zijn" 8. Pointers kunnen groter zijn, of de compiler kan de structuur op een vreemde manier opvullen of uitlijnen.

2
toegevoegd

p is just a pointer. Its size depends on ABI, which is in your case 4.

1
toegevoegd
Je hebt gelijk dat het de grootte van de aanwijzer is. Je vergist je om aan te nemen wat die maat is.
toegevoegd de auteur Genia S., de bron
Nee, het is de grootte van een aanwijzer, die al dan niet de grootte heeft van een niet-ondertekende int.
toegevoegd de auteur Lee Daniel Crocker, de bron

p is just a pointer. Its size depends on ABI, which is in your case 4.

1
toegevoegd
Je hebt gelijk dat het de grootte van de aanwijzer is. Je vergist je om aan te nemen wat die maat is.
toegevoegd de auteur Genia S., de bron
Nee, het is de grootte van een aanwijzer, die al dan niet de grootte heeft van een niet-ondertekende int.
toegevoegd de auteur Lee Daniel Crocker, de bron

En het juiste antwoord: uw uitvoer, indien aanwezig, is onbepaald, omdat u de verkeerde opmaakspecificatie gebruikt in de aanroep naar printf() . U had in plaats daarvan % zu moeten gebruiken - sizeof() levert een object op van type size_t .

Daarom roept je programma ongedefinieerd gedrag, op en is het vrij om alles te doen (en af ​​te drukken) wat het wil.

1
toegevoegd
Het punt is dat sizeof (x) geen unsigned int oplevert, het levert een size_t op. Op de meeste systemen is dat hetzelfde als een unsigned int , maar dat hoeft niet. % zu is de juiste indelingsspecificatie voor een size_t , terwijl % d voor vreselijke dingen kan zorgen.
toegevoegd de auteur amalloy, de bron
Ik geloof dat het converteren van een niet-ondertekende int naar int niet zal resulteren in ongedefinieerd gedrag. Het kan iets als 255 omzetten in iets als -127 op 8-bits systemen. Ik weet het niet zeker. Een bron voor het ongedefinieerde gedrag zou zeer gewaardeerd worden!
toegevoegd de auteur Atmaram Shetye, de bron

En het juiste antwoord: uw uitvoer, indien aanwezig, is onbepaald, omdat u de verkeerde opmaakspecificatie gebruikt in de aanroep naar printf() . U had in plaats daarvan % zu moeten gebruiken - sizeof() levert een object op van type size_t .

Daarom roept je programma ongedefinieerd gedrag, op en is het vrij om alles te doen (en af ​​te drukken) wat het wil.

1
toegevoegd
Het punt is dat sizeof (x) geen unsigned int oplevert, het levert een size_t op. Op de meeste systemen is dat hetzelfde als een unsigned int , maar dat hoeft niet. % zu is de juiste indelingsspecificatie voor een size_t , terwijl % d voor vreselijke dingen kan zorgen.
toegevoegd de auteur amalloy, de bron
Ik geloof dat het converteren van een niet-ondertekende int naar int niet zal resulteren in ongedefinieerd gedrag. Het kan iets als 255 omzetten in iets als -127 op 8-bits systemen. Ik weet het niet zeker. Een bron voor het ongedefinieerde gedrag zou zeer gewaardeerd worden!
toegevoegd de auteur Atmaram Shetye, de bron