Om man sedan blandar in alignment så blir det mer komplext. Att välja
en datatyp (och alignment) som inte går bra ihop med arkitekturen
kan bli "kostsamt"...
C, varning datatyp
-
extradrajven
- Inlägg: 18
- Blev medlem: 1 juni 2013, 18:07:48
Re: C, varning datatyp
Jag var nog lite otydlig i mitt inlägg som gällde MISRA:s rekommendation att enbart använda typer med känd bredd.
Repetition: short int kan lagra åtminstone alla värden i intervallet [−32767, +32767]. int kan lagra åtmistone alla värden i intervallet [−32767, +32767. longt kan lagra åtmistone[/url] alla värden i intervallet [−2147483647, +2147483647]. Kompilatorn kan bredda dessa intervall. Bit-bredden för en char finns i limits.h som CHAR_BIT.
Poängen var alltså att vid de tillfällen man vet om att man klarar sig med en int eller long, ja då ska man använda en int eller long. Det blir bäst kod på flest plattformar.
Exempel 1: En for-loop som löper mellan 0 och 10.
Exempel 2: En variabel som representarer en månad.
Exempel 3: Antal dörrar på en bil.
Exempel 4, där long passar bättre: Antal mil bilen har gått.
Icecap:
Javisst ditt exempel är naturligtvis fullt legalt och uppfyller int/short/long-intervallen ovan. Jag läste på Stack Overflow för ett par dagar sedan om en person som programmerat mot en kompilator där CHAR_BIT=24 och sizeof(char)=sizeof(short)=sizeof(int)=1. Det vill säga alla hade 24-bitars-representation.
TomasL:
Det låter intressant. Källa? Ska kolla min K&R-bok imorgon, men helst skulle jag vilja ha standarden.
Nerre:
Att standarden definierar minsta intervallet var ju poängen med mitt inlägg. När man vet att man klarar sig inom intervallet så kan man använda typen, och låta kompilatorn välja representation, dvs bästa porterbarhet. Naturligtvis behöver man ha full kontroller över representationen när man arbetar mot hårdvara.
bearing:
Använd char, short eller int? Eller kanske rent av int8_fast_t.
lillahuset:
Nu förstår jag inte vad du menar. Min poäng var ju som jag skrev att standarden definierar ett _minsta_ garanterat intervall. Naturligtvis kan kompilator/ABI definiera ett större intervall.
Datatyper är ett intressant ämne att diskutera och det är inte alltid självklart vad man ska välja. Särskilt när det finns så olika saker att optimera mot, såsom prestanda, storlek och porterbarhet. För egen del använder jag de inbyggda C-typerna så långt det går, givet de värden som ska representeras, och de garanterade minsta-intervallen. När problemet som ska lösas kräver att man har kontroll på representationen så använder jag stdint.h.
Repetition: short int kan lagra åtminstone alla värden i intervallet [−32767, +32767]. int kan lagra åtmistone alla värden i intervallet [−32767, +32767. longt kan lagra åtmistone[/url] alla värden i intervallet [−2147483647, +2147483647]. Kompilatorn kan bredda dessa intervall. Bit-bredden för en char finns i limits.h som CHAR_BIT.
Poängen var alltså att vid de tillfällen man vet om att man klarar sig med en int eller long, ja då ska man använda en int eller long. Det blir bäst kod på flest plattformar.
Exempel 1: En for-loop som löper mellan 0 och 10.
Exempel 2: En variabel som representarer en månad.
Exempel 3: Antal dörrar på en bil.
Exempel 4, där long passar bättre: Antal mil bilen har gått.
Icecap:
Javisst ditt exempel är naturligtvis fullt legalt och uppfyller int/short/long-intervallen ovan. Jag läste på Stack Overflow för ett par dagar sedan om en person som programmerat mot en kompilator där CHAR_BIT=24 och sizeof(char)=sizeof(short)=sizeof(int)=1. Det vill säga alla hade 24-bitars-representation.
TomasL:
Det låter intressant. Källa? Ska kolla min K&R-bok imorgon, men helst skulle jag vilja ha standarden.
Nerre:
Att standarden definierar minsta intervallet var ju poängen med mitt inlägg. När man vet att man klarar sig inom intervallet så kan man använda typen, och låta kompilatorn välja representation, dvs bästa porterbarhet. Naturligtvis behöver man ha full kontroller över representationen när man arbetar mot hårdvara.
bearing:
Använd char, short eller int? Eller kanske rent av int8_fast_t.
lillahuset:
Nu förstår jag inte vad du menar. Min poäng var ju som jag skrev att standarden definierar ett _minsta_ garanterat intervall. Naturligtvis kan kompilator/ABI definiera ett större intervall.
Datatyper är ett intressant ämne att diskutera och det är inte alltid självklart vad man ska välja. Särskilt när det finns så olika saker att optimera mot, såsom prestanda, storlek och porterbarhet. För egen del använder jag de inbyggda C-typerna så långt det går, givet de värden som ska representeras, och de garanterade minsta-intervallen. När problemet som ska lösas kräver att man har kontroll på representationen så använder jag stdint.h.
Re: C, varning datatyp
Bra förslag. Den kanske blir 32 bit på en ARM? (får kolla det vid tillfälle)int8_fast_t
Och 8 bit på en AVR?
-
lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: C, varning datatyp
extradrajven: Jo du var ganska otydlig. Men så blir det ju ibland. Tror tillochmed det har hänt mig.
Re: C, varning datatyp
Så här skriver K&R 2nd Ed om datatyper:
8-bitars processor vara 8 bitar.
16-bitars, 16 bitar.
32 bitars, 32 bitar
64 bitars, 64 bitar.
Osv....
Trevlig soppa egentligen
Dock hänvisar man till limits.h där arkitetkurens typlängder skall finnas.
Så, C är egentligen en jäkla soppa, men skojjig sådan.
Kontentan är ju naturligtvis, man måste hålla ögonen på typerna och dess längder, annars kan man få roliga överaskningar, speciellt om man porterar någonnting, eller skall skriva porterbar kod.
Sedan som Sodjan nämnde alignment stökar också till det, ordentligt, framför allt bitfält mm i strukturer osv samt i vissa fall om typerna är kortare än den nativa ordlängden, då kan det få lite konstiga effekter på vissa arkitekturer.
Egentligen så skall alltså en int på en:Object declared as char are large enough to store any member of the execution character set.
Besides the char type, up to three sizes of integer declared as short int, int and long int are available, plain int objects have the natural size suggested by the host machine architecture, the other sizes are provided to meet special needs.
Longer integers provide at least as much storage as shorter ones, but the implementation may make plain integers equivalent to either shorter integers or longer integers
8-bitars processor vara 8 bitar.
16-bitars, 16 bitar.
32 bitars, 32 bitar
64 bitars, 64 bitar.
Osv....
Trevlig soppa egentligen
Dock hänvisar man till limits.h där arkitetkurens typlängder skall finnas.
Så, C är egentligen en jäkla soppa, men skojjig sådan.
Kontentan är ju naturligtvis, man måste hålla ögonen på typerna och dess längder, annars kan man få roliga överaskningar, speciellt om man porterar någonnting, eller skall skriva porterbar kod.
Sedan som Sodjan nämnde alignment stökar också till det, ordentligt, framför allt bitfält mm i strukturer osv samt i vissa fall om typerna är kortare än den nativa ordlängden, då kan det få lite konstiga effekter på vissa arkitekturer.
-
lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: C, varning datatyp
Jo, structar ska man försöka sortera upp så att breda typer ligger i början. Om inte kompilatorn och arkitekturen har några andra egenheter. Hallå hallå, var det någon som pratade om arkitekturoberoende program? Tillåt mig småle.
-
lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
-
extradrajven
- Inlägg: 18
- Blev medlem: 1 juni 2013, 18:07:48
Re: C, varning datatyp
TomasL:
Njä. The C Programming Language har vi här:
https://hassanolity.files.wordpress.com ... uage_2.pdf
Boken innehåller en referensdel för "ANSI C" i Appendix A och framåt:
Sidan 257 (Appendix B11) specificerar limits.h och därmed heltalstyperna. SCHAR_MIN, SCHAR_MAX, INT_MIN, INT_MAX och så vidare är väldefinierade som jag beskrivit tidigare. Det är en strikt _nedre_ begränsning av intervallen som ges.
Sidan 260 (Appendix C) beskriver vad som är nytt i och med standardiseringen av språket ANSI C (antagligen i relation till K&R). Exempelvis "The standard places explicit minima on the ranges of the arithmetic types, and mandates headers (<limits.h> and <float.h>) giving the characteristics of each particular implementation.
En kompilator som medger int på 8 bitar uppfyller inte ANSI C eller senare standard.
C har inte ambition att standardisera bitfält och alignment. Det är snarare upp till ABI att avgöra.
Njä. The C Programming Language har vi här:
https://hassanolity.files.wordpress.com ... uage_2.pdf
Boken innehåller en referensdel för "ANSI C" i Appendix A och framåt:
Sidan 257 (Appendix B11) specificerar limits.h och därmed heltalstyperna. SCHAR_MIN, SCHAR_MAX, INT_MIN, INT_MAX och så vidare är väldefinierade som jag beskrivit tidigare. Det är en strikt _nedre_ begränsning av intervallen som ges.
Sidan 260 (Appendix C) beskriver vad som är nytt i och med standardiseringen av språket ANSI C (antagligen i relation till K&R). Exempelvis "The standard places explicit minima on the ranges of the arithmetic types, and mandates headers (<limits.h> and <float.h>) giving the characteristics of each particular implementation.
En kompilator som medger int på 8 bitar uppfyller inte ANSI C eller senare standard.
C har inte ambition att standardisera bitfält och alignment. Det är snarare upp till ABI att avgöra.
Re: C, varning datatyp
Jo men samtidigt (A4.2) som jag citerad ovan så sår det:
Kan ju vara att mi K&R är lite gammal då, för det står inte ett ord om detta i appC<limits.h> described in App B defines the largest and smallest values of each type in the local implementation
-
lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: C, varning datatyp
Självklart har jag kunder som läser min kod. Det är de bra kunderna. Kunder som inte ids läsa koden är de dåliga kunderna.
Ett av de största traumana var när jag hade en kund som lusläste allt jag gjorde och inte nog med det blev väldigt irriterad över att det var lite blandad mix av versaler och gemener i filnamn som jag inte var medveten om eftersom jag körde W2000. Som ju skiter fullständigt i gemener/versaler. Sedan jag har konverterat till "Church of Tux" har jag fullständig förståelse för det. Jag är numera mycket tacksam för deras CTOs irritation.
Ett av de största traumana var när jag hade en kund som lusläste allt jag gjorde och inte nog med det blev väldigt irriterad över att det var lite blandad mix av versaler och gemener i filnamn som jag inte var medveten om eftersom jag körde W2000. Som ju skiter fullständigt i gemener/versaler. Sedan jag har konverterat till "Church of Tux" har jag fullständig förståelse för det. Jag är numera mycket tacksam för deras CTOs irritation.
Re: C, varning datatyp
> Jo, structar ska man försöka sortera upp så att breda typer ligger i början.
Ja, det finns ju olika metoder för att lösa alignment problem. Många kompilatorer
har direktiv för att "fylla ut" structar för att få alla variabler på effektiva adresser.
Det beror ju lite på vad structen ska användas till. Sen så är olika arkitakturer
olika "känsliga"...
Ja, det finns ju olika metoder för att lösa alignment problem. Många kompilatorer
har direktiv för att "fylla ut" structar för att få alla variabler på effektiva adresser.
Det beror ju lite på vad structen ska användas till. Sen så är olika arkitakturer
olika "känsliga"...
