Varför måste man hela tiden snåla i C ?

Man ska ALLTID hushålla med resurser. Sen går det ju att diskutera var gränsen till (dum)snålhet går.

C är ju ofta ett rätt hårdvarunära språk och kan göra det extra kritiskt att exekveringen är så optimal som möjligt. Det gäller att avväga vad som är nödvändigt och för att kunna göra det är det bra träning att snåla i början så att man vet var man kan "russla" när man kan sakerna lite bättre.

Börjar du programmera mikroprocessorer så är du däremot mer tvingad att hålla resursanvändningen nere eftersom de är betydligt mer begränsade i hos den hårdvaran.

Det är i högsta grad nödvändigt. Både då, nu och i framtiden.
Konstanter är deklarerade konstanter för att de INTE ska KUNNA ändras även om man så FELAKTIGEN ber om det. Ponera att du eller någon annan som jobbar med kodbasen finner det en bra ide att definiera om PI till 3.

Och att deklarera rätt utrymme till rätt data gör ofta att man behöver tänka ett steg till. Programmering är inte enbart att skriva kod utan det handlar även om planering.
Om jag skulle välja största möjliga datatypen i mina databaser skulle de ta mångdubbelt mer plats i minnet samt på värdefulla platsen på SSDn vilket direkt översätts till att det blir dyrare och långsammare.

Men aspirerar du inte till något mer än att kunna skriva "hello world" så gäller detta inte dig. Förstår inte i så fall inte varför du inte använder BASIC istället, på en c64 och på en monokrom skärm.

Unsigned vad? Signed definierar att du kan använda även negativa tal (genom att använda en bit till det) vilket då halverar "omfånget" på talet du kan spara.
Long använder du när du vill kunna spara ett tal med det omfånget long är definierat till på den plattformen du använder.

Edit : Rättade "Unsigned" till "Signed" ovan.

Arduino : Ja.
Webbläsare : Beror på vad du ska göra, men ja.
USB-drivrutiner : Ja.

Fast jag är osäker på vad du menar med "snålhet". För mig känns det som du vill hoppa över nödvändig baskunskap och då kan du utesluta i princip allt.

Ja det rimmar ju fint med det du skrev några inlägg tidigare med att du inte ville lägga ner speciellt mycket energi på det.
Varken Wolfenstein, Doom, eller Quake hade kunnat gjorts utan djupare kunskap och utnyttjande/trick av den hårdvaran som fanns då.

Och ska du göra 3D-spel(motorer) så är det inte enbart programmeringsspråk du behöver kunna utan även en hel del matematik.

Beror på vad du gör. Om du tänker implementera protokoll som används på nätet och/eller mellan I/O-enheter i din dator så är dessa protokoll nästan alltid definierade så att man dra maximal nytta av tillgängligt utrymme. Så om ett tal bara kan vara mellan 0-1000 finns det ju absolut ingen anledning att använda mer än 10 bitar för att representera ett sådant tal.

Ta IPv4, det protokoll vi alla använder (ihop med TCP) för att posta och läsa inlägg på SweC. Headern för IPv4 paket ser ut på följande sätt

Visa innehåll

Dold text

I C kan jag på ett enkelt sätt definiera en struktur som exakt representerar detta så här på en "big-endian" CPU (man måste ha en lite annan definition på en little-endian maskin)

struct ipv4hdr {
    uint8_t ver:4;
    uint8_t ihl:4;
    uint8_t tos;
    uint8_t tot_len;
    uint16_t id;
    uint16_t reserved:1;
    uint16_t df:1;
    uint16_t mf:1;
    uint16_t offset:13;
    uint8_t ttl;
    uint8_t proto;
    uint16_t chksum;
    uint32_t src;
    uint32_t dst;
    uint32_t options[0];
};

foo(struct ipv4hdr *iphdr) {
   if (iphdr->ver != 4)
     /* Tydligen inte IPv4... */
   if (iphdr->mf)
     /* detta är inte sista fragmentet */
    iphdr->offset = /* nya värdet på 'offset' fältet, kan innehålla talet 0..8192 (0..2^13) */
}

I praktiken ska man nog inte använda annat än char, int och unsigned int då storleken på char, short, int & long inte är specificerade. char använder man för enklare text (idag bör man köra med UTF-8 i stället för char) och int/unsigned int använder man när man behöver en heltalstyp som CPUn är som mest effektiv med. Vill man ha specifika storlekar så har ANSI-C typerna jag använde ovan (definierade i stdint.h) där man explicit anger bitstorlek och därmed kapaciteten.

signed/unsigned är något som i praktiken är långt mer komplicerat att få rätt än vad många först inser. Javas beslut att inte ha "unsigned" förenklar rejält jämfört med C/C++/C# då man kan åka på rejält luriga buggar om signed och unsigned heltal kombineras i ett och samma uttryck. I praktiken är det sällan man egentligen behöver unsigned, de tillfällen det är användbart är ofta samma där man även vill kunna specificera bitfält.

Nu vet jag inte om jag läste inlägget bakåfram eller om jag är trött, men jag tolkade ditt inlägg som att unsigned tillåter negativa vilket är motsatsen. Unsigned betyder i princip utan tecken så alla tal blir positiva.

En sak som är långt viktigare idag är att ta hänsyn till hur CPU-cachen mellan CPU-kärnor påverkas av ett program. Och här ser man den stora fördelen C/C++ har över alla andra språk; kontroll!

Om du har en struktur som samtidigt används av flera CPU-kärnor, vissa delar läser man bara och vissa andra både skriver man och läser (t.ex. statistikräknare, då vill du säkerställa en rad saker: din struktur ska alltid ligga i så få cache-lines som möjligt, men du vill ändå säkerställa att den del som är read-only ligger på en annan cache-line än delen som även skrivs. Du vill också att den del som skrivs, om möjligt, ligger så att CPU-kärna 1 skriver på en cache-line medan CPU-kärna 2 skriver på en annan (så slår man ihop resultatet när man vill läsa).

Är bara C/C++ (och assembler) som ger programmeraren den kontroll som behövs för att kunna säkerställa sådana saker, i Java/C# har jag ju ingen direkt konstroll över vart en struktur allokeras och heller ingen direkt kontroll över hur en struktur läggs ut i minnet. Någon kanske tycker: men nu pratar du om riktiga micro-optimeringar som man knappast behöver. Men det är inte sant, effekten av att ha olika CPU-kärnor skriva på separata cache-lines mot att de råkar dela en cache-line är typiskt 10-50% högre prestanda om det görs rätt vid 2 CPU-kärnor och effekten ökar exponentiellt med antalet CPU-kärnor (så vid 4-8 kärnor skiljer det många heltalsfaktorer).

I spel och andra interaktiva applikationer vill man också att programmet är helt förutsägbart, saker som automatiskt minneshantering blir då helt uteslutet. Alla lite mer avancerade spel använder sig inte ens direkt av malloc()/free() utan man skriver egna minneshanterar som ofta är specifika (lite olika) för olika typer av objekt i spelet. Moderna OS gör precis samma sak, det finns en generell minneshanterar i botten men sen har man specialdesignade minneshanterar för varje delsystem.