C/C++ und size_t/size_type

[Meta123Tron]

Hallo.

Bisher habe ich bei der Indizierung von Arrays immer int, bzw halt unsigned int genommen. Inzwischen habe ich aber den Eindruck, daß man für solche Dinge besser size_t oder size_type nehmen sollte.
Was ist denn der Unterschied zwischen den beiden? Diverse Hilfeseiten im Internet schreiben, daß size_type meistens nur eine typedef von size_t ist. Allerdings ist size_type in der string Klasse enthalten. size_t weiß ich jetzt gar nicht wo das definiert ist. Ist size_type also nur die C++ Variante von size_t?

Und wo verwende ich diese Typen genau? Ich habe zB eine Funktion, der wird eine Zahl übergeben, >= 0. Verwende ich dafür unsigned int oder size_t? Diese übergebende Zahl gibt an, mit wievielen "Würfeln" die Funktion würfeln soll. Es ist also eine Mengenangabe.

Der Rückggabewert der Funktion ist das Ergebnis des Würfelns, also eine Summe, keine Mengenangabe. Rein von meinem Verständnis der Lesbarkeit des Codes sollte der Rückgabewert also ein unsigned int sein, eine "echte Zahl", während die Mengenangabe dann eben so ein size_t sein sollte.

Danke für ein paar klärende Worte!

 

[Ricky Spanish]

Müsste in der stddef.h definiert sein. Soweit ich weiß als long unsigned int.
Ich hab size_t bisher nur in ganz wenigen Ausnahmefällen
verwendet, von denen mir aktuell kein einziger mehr einfällt. Für die meisten Fälle dürfte unsigned int vollkommen genügen.

 

[The_Company]

size_t is der Wert, den man an malloc übergibt und der von sizeof() zurückkommt - nämlich um Grössen von etwas anzugeben. Also sollte size_t gross genug sein um die Differenz von 2 Pointern zu halten.
(unsigned) int war der schnellste Typ auf der CPU und ist inzischen de facto 32bit weil zuviele Programme sonst nicht funzen würden.
(unsigned) long ist sowas wie grösster Typ auf der CPU, weshalb er meistens (immer?) gleich gross ist wie size_t, da er so gross ist wie ein Pointer (Architekturgrösse halt).
Und natürlich gibts noch ptrdiff_t, was praktisch die signed Version von size_t ist und Das Ding, was man bekommt, wenn man Pointer voneinander abzieht.
So, das sind die C Typen, von C++ hab ich kA.

"a[x]" ist equivalent (ich glaub das steht sogar so in der C spec zu "*((a) + (x))", womit x idealerweise size_t sein sollte. Aber wenn man weiss, dass das array kleiner als INT_MAX ist, tuts natürlich auch nen int.

 

[Meta123Tron]

OK, ich werde dann weiter int verwenden, ist auch irgendwie deutlich lesbarer im code.

 

[voelkerballtier]

also ich jetzt alles andere als ein experte, aber ich nehm size_t für alles, was mit array (vector usw.) indizierung zu tun hat, also laufvariablen in for schleifen zBsp - aber mit int machst du da auch nicht wirklich was falsch, glaub ich.

 

[doMi-]

Hallo.

Bisher habe ich bei der Indizierung von Arrays immer int, bzw halt unsigned int genommen. Inzwischen habe ich aber den Eindruck, daß man für solche Dinge besser size_t oder size_type nehmen sollte.
Was ist denn der Unterschied zwischen den beiden?

ich habe das gefühl, dass du dir wirklich gedanken gemacht hast und dich gut informiert hast. der eindruck ist ja sicher nicht auf dem klo über dich gekommen

 

[EnimaN]

wirft der compiler nicht sogar ne warnung, wenn man sowas schreibt:

vector<int> feld;
for( int i=0; i<feld.size(); ++i)

da der vergleich probleme machen kann, da ja size() nen size_t zurückgibt?

 

[voelkerballtier]

wirft der compiler nicht sogar ne warnung, wenn man sowas schreibt:

vector<int> feld;
for( int i=0; i<feld.size(); ++i)

da der vergleich probleme machen kann, da ja size() nen size_t zurückgibt?

nur bei -Wall

 

[Starfire]

war size_t nicht irgendwie variabel was die plattform anging?
also dass es sich an 32bit und 64bit anpasst.

http://msdn.microsoft.com/en-us/library/3b2e7499(VS.80).aspx

 

[The_Company]

Ja war es.
Wüsstest Du sogar, wenn Du meinen Beitrag gelesen hättest

 

[Shihatsu]

nur bei -Wall

ich hab echt null ahnung von c und so, aber das ist ja mal krass hier - dh der compiler meckert erst bei einer bestimmten einstellung, das da zwei datentypen nicht zusammenpassen? wie gesagt, nicht hauen wenn die frage dohv ist oder, aber in java würde sich sowas zwar problemlos compilen lassen, aber es würde automatisch nen warning geben...

 

[bog]

na klar. im nazimode (-Wall) wirft er fuer alles warnungen aus, was auch nur schief aussieht. da lamentiert er dann auch, wenn du unsigned int (idR kleinerer size_t) mit signed int vergleichst - schliesslich sind die fuer gewoehnlich gleich gross, aber haben unterschiedliche wertebereiche. in den meisten schleifen und if-abfragen ist das voellig egal, aber wenn die beiden typen auch vergleichbar sind, sind sie nicht gleich.

gibts denn in java ueberhaupt den unterschied zwischen unsigned und signed integern? wirft ein java-compiler keine warnung, wenn du float und int vergleichst?

 

[The_Company]

C compiler warnen nicht bei float und int. Die warnen nur bei gleich grossen Datentypen mit unterschiedlichen Wertebereichen wo durch einen nicht erwarteten cast alles den Bach runter ginge. Das ist aber klar definiert (der Vergleich wird unsigned durchgeführt, d.h. -1 wird zu UINT_MAX gecastet und ist grösser als alles andere (und nicht kleiner).

gcc spuckt normalerweise nur Fehler aus. Mit -Wall spuckt er alle Warnungen aus, wo er relativ sicher ist, dass Du gerade Scheisse baust. Von Nazi Mode ist das aber noch weit weg. Nazi mode ist -Wall -Wextra -Werror (plus noch nen paar andere Warnungen, die ich immer an habe).
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html falls Du Dich mal in C und dessen Fallstricke einarbeiten willst.

 

[Whcttyh]

gibts denn in java ueberhaupt den unterschied zwischen unsigned und signed integern? wirft ein java-compiler keine warnung, wenn du float und int vergleichst?

ist alles signed (ausser char). warnung dürfts keine geben, auch wenn informationen beim casting auf float verloren gehen können.

 

[Starfire]

Ja war es.
Wüsstest Du sogar, wenn Du meinen Beitrag gelesen hättest

jo, nur weil meta-tron danach geschrieben hat, dass er weiter int benutzen will.
in den fällen sollte man doch size_t verwenden, oder nicht o_O

 

[bog]

klar sollte man das (zumindest fuer stabilen code), wenn er aber weiss, dass die verwendung von normalen ints nicht zum problem wird, kann er ja seinem aesthetikempfinden nachkommen.

 

[Meta123Tron]

Also doch size_t verwenden, zumindest wenn man beispielObject.size() mit einer Zahl vergleicht. Macht auch irgendwie Sinn, aber mein Editor zB hat bei int syntax highlighting, nicht jedoch bei size_t, was mich beim Lesen immer ein wenig stört.
Danke für die Diskussion!

 

[voelkerballtier]

ja ist durchaus ne gute idee so zu programmieren, dass -Wall nicht meckert (zumindest mit gcc - beim icc reicht -w2 mMn)