Vad använda istället för globala variabler - C++ ?

haha vafan kom de där ifrån?
Men mycket riktigt. Globala variabler och goto's är ett nono i mitt tycke. Du hade inte fått igenom en code-review om du hade börjat skriva globala variabler här och där som någon annan efter ett tag hade fått gissa sig fram till och hoppa med ctags...

Även om detta inte är skrivet i c++ så är drupal är perfekt exempel på varför globala variabler och funktioner suger balle. DÄR fick du din fatwa

Haha - tack tack,

Men varför är streamobjekten cin. cout, och cerr, (stdin, stdout, stderr i C) globaler då ?
Dvs de finns ju i det globala scopet kan man säga.

Det är nog ett arv från K&R där Unix av tradition haft globala filhandtag. Och för att minimera koden som behövs för att skriva ut "Hello world!".

Det hade varit bättre att man fått filhandtagen som argument till main()-funktionen och varit tvungen att passa dem vidare till kod som skall kunna skriva ut. Då hade man sluppit bli spammad av oönskade diagnostiska meddelanden från okynniga tredjepartsbibliotek.

Ja precis, designfilososfiskt så ansågs detta ju inte vara något dåligt på den tiden. På den tiden var globaler inget "fult", Globaler blev fulkod först senare i och med att man upptäckte deras nackdelar. Även printern har ett filhandtag, stdprn - Men man skulle kunna säga att alla IO-enheter egentligen är globaler, grafiken i Windows är en sådan, musen likaså.

Nu processas ju mus-eventsen av kerneln och bara en del skickas vidare till applikationen.

Att filhandtagen finns kvar är ju bara kravet på bakåtkompabilitet vilket var ett av de viktigaste designkriterierna för C++ i början.

Egentligen tror jag inte att det skulle vara någon vits med att passa dem som parametrar till main(), det förändrar ju inget. I så fall skulle man behöva skicka en hel struct med en massa environments, och IO-objekt, etc

Här är ett exempel på en global variabel som gör sitt jobb (gcc Linux) :


Koden är hämtad ifrån
http://stackoverflow.com/questions/1...dling-in-linux
Det finns gott om exempel av olika svårighetsgrad osv, det här var väl kanske inte det allra bästa.
Ursäkta för att jag tar ett exempel i C, och ursäkta för while (1) -statementet (BPP = Bad Programming Practice)
Jag ser det som svårt att undvika globaler i sådana här fall, man kanske vill avbryta/pausa en pågående körning på ett någorlunda ordnat sätt, signaler är i såfall ett enkelt och oftast alltid funktionellt sätt att göra det på. Istället för att använda "kill -9 <pid>"

Funktionen signal(int signum, sighandler_t handler), sätter alltså en ny egendefinierad signalhanterare istället för den gamla Man kan inte sätta den att peka på en medlemsfunktion i en klass , åtminstone inte som C++ är designat.

Det var länge sedan jag var intresserad av detta problem provade lite olika möjliga castnings men fick inte något att fungera acceptabelt,

Likadant är det med andra interrupthanterare att de kan inte fås att hakas på en medlemsfunktion i en klass.
Dvs de kan behöva globaler för att göra det de ska

Den som dock är intresserad kan ju bygga en mutexliknande konstruktion som bygger på signal handling ifall man behöver synka två processer emot typ ett shared memory eller pipe access.

Nu är ju sådant här med signal hantering och interrupt en teknik som vanligtvis är gömt inuti OS-et och man skriver ju sällan program med sådan hantering numera, de behövs vanligen inte.


Håller ju inte riktigt med här, det är lika viktigt att se till att datakorruption inte uppstår med lokaler likväl som globaler, det är lika svårt eller lika lätt beroende på hur man ser på det. Mutexar eller semaforer behövs för att säkerställa att bara en tråd/process i taget ändrar på variablerna.

Dock så måste jag lägga in en brasklapp om detta påståendet - det finns ju klasser som redan har inbyggd multitrådning, med fungerande synkning mm, och då ska man isåfall ha lokaler i dennas medlemsfunktioner.

Äh diskussionen om globaler visavi lokaler är ju delvis uppkommen av de tidigare programskrivningstekniken att bygga dinosaurie-program, eller monoliter som man också kallade det.
Den monolitiska traditionen finns ju delvis kvar i Linux kernels, men i tex Windows är OSet uppdelat istället.

Monoliterna gjorde det ju svårare att ha många grupper av programmerare uppdaterade och projekten försenades ofta för att man fick link errors eller variabel NN not declared bara för att ngn skrivit fel. Och rättningen tog sanslöst lång tid.

Så lokaler underlättade för olika grupper att samarbeta.

Jag vet inte vad som blir nästa stora fråga inom programmeringstekniken - Språket Swift gör tex lite delvis tvärtom, en del språk har designats med avsiktligt hård typning, medans Swift vill att medlemsfunktionerna själva ska deducera fram typningen i runtime, ett potentiellt svart hål för buggar - skulle jag tro