Skriva ut array, varför inte bara på ett sätt?

[TomasL]

Det handlar inte om att lita på kompilatorn, det handlar om att ha kontroll på allt, för att få så buggfria program som möjligt.

[snigelen]

Ja nu orkar jag inte klydda mer idag. Vill du ha kontroll på allt bör du inte använda en kompilator överhuvud taget. Men vi har nog olika sätt att uppnå "så buggfria program som möjligt". Själv tycker jag nog att tiotusentals kritiska granskare av kompilator och standardbibliotek borgar för kvalitativ avlusning. Men vi tycker ju inte lika i allt...

Men du får gärna tro att du har "kontroll på allt" . Det har inte jag.

[TomasL]

Nä, men man ha kontroll på det man skriver själv, och dessutom, 10k granskare, betyder inte att det blr bättre, eftersom 9999 av dem inte har en aning om vad de pysslar med, ett antal buggar det senaste åren bevisar ju det.

[Nerre]

Jag får föreslå snigelen att läsa lite standarder om utveckling av mjukvara.

Där handlar det ofta om att göra saker "för säkerhets skull", just eftersom det inte kostar så mycket i kodväg.

Det är enklare att sätta ett känt värde på en variabel än att behöva ha en massa kod som kollar att variabeln är rätt.

[TomasL]

Exakt.

[bearing]

Jag verkar ha hamnat mitt i något personligt här. Det verkar som att två personer hyser agg mot varandra. Hur som helst har jag själv använt argumentet att open source-kompilatorer ger bra avlusning.

Jag jobbar just nu inom bilindustrin, och det är otroligt vilka summor som läggs ned på att försöka följa standarder för säker mjukvara (och hårdvara). Man använder processorer med dubbla kärnor som kör exakt samma program i identiska kärnor för att friskriva sig från sporadiska fel i processorn. Lägger ned stora pengar på kompilatorer. Men i slutändan är det ju programmerarna som orsakar buggar. Man använder folk som är outsourcade och konsultade från hela världen med alla möjliga tidszoner, där ingen kan ha koll på vad för utbildning, erfarenhet, och relevant kunskap personen som knappat ner koden har. Men man följer alla standarder, och tror att man ska kunna nå ett bra resultat.

Att kosmisk strålning ändrar ett tillstånd i logiken inuti en mikrokontroller, eller att kompilatorn plötsligt en dag visar sig ha haft en bug under hela utvecklingstiden, verkar ju enormt mer osannolikt än att någon helt enkelt har skrivit en bugg en trött måndagsmorgon, eller ja, såklart valfri tidpunkt, för folk skriver buggar hela tiden. Kanske var det ett misstag, ogenomtänkt, eller så förstod personen inte bättre. Och det här senaste är väldigt vanligt. Folk förstod inte bättre, för de förstod inte hur systemet fungerade. Eller så var de helt enkelt ovana som programmerare. Det är ju här buggarna uppstår. Om man byter ut all kod till sin/företagets egen, kanske man därmed ökar risken för buggar. Fördelen är väl att man kan rätta till dem enklare. I alla fall i mindre projekt. I större projekt blir allt så komplext till slut, att ingen har en aning om var felet finns, oavsett om koden är egen eller följde med kompilatorn.

[Mr Andersson]

En lokal/automatic variabel som är delvis initierad borde också fyllas med nollor. Standarden(erna) är inte jättetydlig(a) på den punkten, men gcc fyller i alla fall på med nollor i det fallet också.

Det är garanterat att alla* delvis initierade variabler fylls ut med nollor oavsett storage class. Det är många hopp fram och tillbaka för att hitta det i standarden, men det finns där.

*) Med ett undantag; Om de skippade fälten är referenstyper blir det kompileringsfel.

Och visst, det kostar inte mycket att manuellt nolla allt en extra gång. Men börjar man få ont om plats är det lite onödigt att skriva kod för att göra något som kompilatorn redan har gjort. Vissa skulle kanske säga att i det läget ska man byta till större mcu, men det är inte alltid det går.

[Henry]

Henry: Jag antar att du inte har något emot att tråden spårade ur till något helt annat?

Något annat hade varit förvånande.

Men nej då det är intressant läsning, än så länge.

[mounte]

För just C så finns det ju faktiskt lite att falla tillbaka på i form av dokumentation
C89 - kapitel 6.5.7 Initialization
C99 - kapitel 6.7.8 Initialization

If an object that has automatic storage duration is not initialized explicitely, its value is indeterminate. If an object that has static storage duration is not initialized explicitely, it is initialized implicitely as if every member that has arithmetic type were assigned 0 and every member that has pointer type were assigned a null pointer constant.


If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, then:
— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned) zero;
— if it is an aggregate, every member is initialized (recursively) according to these rules;
— if it is a union, the first named member is initialized (recursively) according to these rules.

Vidare kan vara intressant att indeterminate betyder (enl, C99 kapitel 3.17.2)

indeterminate value
either an unspecified value or a trap representation

Ursäkta om jag bland posterna missade referenser till denna dokumentation, försöker undvika dubbelpostningar.

[bearing]

Så vad händer om man som i mitt exempel delvis initierar en array? att t.ex. initiera "123456789" i en lokal array på 20 chars? Gäller då "If an object that has automatic storage duration is not initialized explicitely, its value is indeterminate", d.v.s de 10 sista charsen är "indeterminate"? Eller fylls de med nollor? Det verkar olika bud i tråden vad som gäller. I gcc fylls de 10 sista med nollor, påstås det.

[adent]

Nej det stämmer inte. Initierar man inte hela arrayen så fylls resten ut med nollor, såvida det inte är en lokal, icke static oinitierad variabel.

Det är helt sant att globala/static-variabler initieras till 0 automatiskt. Givetvis kan man utnyttja det, men jag skulle säga att det är ett riktigt dåligt sätt i detta specifika fall.

[Mr Andersson]

Så vad händer om man som i mitt exempel delvis initierar en array? att t.ex. initiera "123456789" i en lokal array på 20 chars? Gäller då "If an object that has automatic storage duration is not initialized explicitely, its value is indeterminate", d.v.s de 10 sista charsen är "indeterminate"? Eller fylls de med nollor? Det verkar olika bud i tråden vad som gäller. I gcc fylls de 10 sista med nollor, påstås det.

Glöm diskussionen om storage class, det har inget med saken att göra. Det gäller endast helt oinitialiserade variabler.
Alla kompilatorer som följer standarderna fyller i utelämnade fält med noll.

Från c++11 8.5.1 paragraf 7 om aggregate initialization

If there are fewer initializer-clauses in the list than there are members in the aggregate, then each member not explicitly initialized shall be initialized from its brace-or-equal-initializer or, if there is no brace-or-equalinitializer, from an empty initializer list (8.5.4)

Från 8.5.4 paragraf 3 om tomma initializer lists

Otherwise, if the initializer list has no elements, the object is value-initialized.

Och sist från 8.5 paragraf 8 om value initialization

To value-initialize an object of type T means:
...
if T is an array type, then each element is value-initialized;
otherwise, the object is zero-initialized.

C har samma sak fast med enklare språk då det inte finns templates, klasser eller referenser.

If there are fewer initializers in a brace-enclosed list than there are elements or members
of an aggregate, or fewer characters in a string literal used to initialize an array of known
size than there are elements in the array, the remainder of the aggregate shall be
initialized implicitly the same as objects that have static storage duration.

Det är jättevanligt att skriva t.ex. int x[10] = {0};. Däremot är det ovanligt att se formen int x[10] = {0,0,0,0,0,0,0,0,0,0}; förutom från de som inte har full koll på hur språket fungerar.

Edit/lite uppföljning:
Jag har sett en del programmerare som lär ut att int x[10] = {0}; sätter alla element till noll, utan att förklara varför. Då är det lätt att bli lurad att int x[10] = {1}; sätter alla element till 1, men det är fel. Bara första elementet blir 1, alla andra blir 0. Därför föredrar jag personligen formen int x[10] = {};

[Nerre]

Skriver man kod som man vill ha koll på är det ju grundläggande regel att skriva ut allting explicit.

Detta för att den människa som läser koden ska kunna vara säker på vad som händer.

Typisk grej för C är ju att man i ett villkor bör skriva if (x != 0) istället för if (x). Bägge sakerna kommer fungera likadant, men den första är mycket enklare att direkt se hur den fungerar när man läser koden.

För tydlighets skull bör man också använda defines för TRUE och FALSE och istället för if(x) skriva if (x == TRUE).

[Mr Andersson]

> För tydlighets skull bör man också använda defines för TRUE och FALSE och istället för if(x) skriva if (x == TRUE).

if(x) och if (x == TRUE) är inte ekvivalenta. Använd if (x != FALSE) istället. (Förutsatt att FALSE är lika med noll)

> Skriver man kod som man vill ha koll på är det ju grundläggande regel att skriva ut allting explicit.
Okej visst, för 10 element kan man skriva ut alla. Men säg att du har 10000 element, skriver du explicit ut alla 10000 nollor?
Följer man standarden så är man säker på vad som händer.

[Nerre]

Har jag 10 000 element och vill visa i koden att de är initierade till 0 så gör jag en loop som intierar dem. Även om loopen är helt onödig ur funktionssynpunkt, så är den nödvändig ur läsbarhetssynpunkt.

Samma sak t.ex. med casting, ska man skriva tydlig kod så ska all casting vara explicit.