---

Hej...

Jeg hører ofte, at globale variabler er meget "fyfy", og at de for
enhver pris skal undgås.

Men behøver det være sådan?
Jeg sidder og roder med et mindre program, hvor der i main oprettes en
struct, som skal bruges i mange af funktionerne i programmet.
Den bliver sendt med som pointer til mange af funktionerne. Selv en tråd
skal have mulighed for at ændre på min struct, så den sendes også med
som en void-pointer til tråden.
Så det simple program bliver hurtigt mere eller mindre uoverskueligt, da
struct-variablen bliver sendt med til højre og venstre.

Det er i sådanne situationer, at jeg fristes til at gå mod min
indoktrinering om at gloable variabler er "fyfy".

Hvad hvis en tråd skal bruge en mutex? Skal en reference til mutexen
sendes med til alle tråde og funktioner?

</Leif>

---

"Leif Romme Thomsen" <lrt_news@hotmail.com> wrote

[8<8<8<]
> Det er i sådanne situationer, at jeg fristes til at gå mod min
> indoktrinering om at gloable variabler er "fyfy".

Hvis dit program er skrevet i C++, så lyder det som om det muligvis kunne
være nyttigt at lade din struct blive til en klasse og lade de mange
funktioner som tager en pointer til strukturen blive til member-funktioner.
Så slipper du for hele tiden at sende en pointer med (compileren gør det for
dig) og du slipper for fristelsen til at lave globale variable af
bekvemmelighedsgrunde.

> Hvad hvis en tråd skal bruge en mutex? Skal en reference til mutexen
> sendes med til alle tråde og funktioner?

ja.
Men hvis du pakker data der skal beskyttes ind i en klasse, der ejer
mutexen, kan låsningen ofte foretages intern i klassen i starten af
member-funktionerne.
Hvis låsningen skal spænde over flere funktionskald, kan man lave en låse
klasse. Objekter af denne låseklasse kan så sendes med som argument til
member-funktionerne.
Der findes også andre teknikker til at indkapsle synkronisering, således at
det enten ikke er synligt udefra eller brugeren stort set ikke kan undgå at
foretage den nødvendige låsning.

Venlig hilsen

Mogens Hansen

---

Hej Mogens

Mogens Hansen wrote:
> Hvis dit program er skrevet i C++

....det er det desværre ikke - det er skrevet i C.
Ellers er det nogle rigtig gode forslag og ideer du kommer med til
indkapsling af data.

Jeg arbejder mest med C++, og det er derfor vanskeligt sådan lige
pludselig ikke at må tænke i klasser og objekter mere!

</Leif>

---

On Mon, 19 May 2003 22:37:46 +0200, Leif Romme Thomsen
<lrt_news@hotmail.com> wrote:
>Jeg arbejder mest med C++, og det er derfor vanskeligt sådan lige
>pludselig ikke at må tænke i klasser og objekter mere!

Ækvivalensen til klasser og namespaces i c++, er filer i c.
Den indkapsling af data og tilhørende funktionalitet, som er blevet
understøttet i sproget c++, har altid eksisteret i C.
Alle OO paradigmerne har dog gjort det meget elegantere.

Mvh
Benny

---

Den Mon, 19 May 2003 22:11:36 +0200 skrev Mogens Hansen:
>
>"Leif Romme Thomsen" <lrt_news@hotmail.com> wrote
>
>[8<8<8<]
>> Det er i sådanne situationer, at jeg fristes til at gå mod min
>> indoktrinering om at gloable variabler er "fyfy".
>
>Hvis dit program er skrevet i C++, så lyder det som om det muligvis kunne
>være nyttigt at lade din struct blive til en klasse og lade de mange
>funktioner som tager en pointer til strukturen blive til member-funktioner.
>Så slipper du for hele tiden at sende en pointer med (compileren gør det for
>dig) og du slipper for fristelsen til at lave globale variable af
>bekvemmelighedsgrunde.

Og dernest begynder han så at overveje hvad forskellen er på globale
variable og variable i den klasse som hele programmet består af...

Mvh
Kent
--
Avoid the Gates of Hell. Use Linux
(Unknown source)

---

Leif Romme Thomsen wrote:
> Hej...
>
> Jeg hører ofte, at globale variabler er meget "fyfy", og at de for
> enhver pris skal undgås.
>
> Men behøver det være sådan?
> Jeg sidder og roder med et mindre program, hvor der i main oprettes en
> struct, som skal bruges i mange af funktionerne i programmet.
> Den bliver sendt med som pointer til mange af funktionerne. Selv en tråd
> skal have mulighed for at ændre på min struct, så den sendes også med
> som en void-pointer til tråden.
> Så det simple program bliver hurtigt mere eller mindre uoverskueligt, da
> struct-variablen bliver sendt med til højre og venstre.
>
> Det er i sådanne situationer, at jeg fristes til at gå mod min
> indoktrinering om at gloable variabler er "fyfy".
>
Man skal IKKE undgå globale variable "for enhver pris".
Man skal forsøge at begrænse scope't for variabler (og typer, funktioner
etc.) mest muligt. Dvs lade så få som muligt have kendskab til hvordan
andre dele af koden er indrettet.
Hvis man forestillede sig at dit program voksede kunne man (hvis man
overholdt reglen) være fristet til at overføre pointeren til strukturen
til alle funktioner og tilføje alle nye variabler til denne struktur.
Dermed ville man have et program uden globale variabler, men hvor alle
havde adgang til alt.

/b

--
Bertel Brander, author of Wain, a free text editor for programmers:
http://home20.inet.tele.dk/midgaard/program.htm

---

"Leif Romme Thomsen" <lrt_news@hotmail.com> skrev i en meddelelse
news:baan87$q8rnl$1@ID-194690.news.dfncis.de...

> Jeg sidder og roder med et mindre program, hvor der i main oprettes en
> struct, som skal bruges i mange af funktionerne i programmet.
> Den bliver sendt med som pointer til mange af funktionerne. Selv en tråd
> skal have mulighed for at ændre på min struct, så den sendes også med
> som en void-pointer til tråden.
> Så det simple program bliver hurtigt mere eller mindre uoverskueligt, da
> struct-variablen bliver sendt med til højre og venstre.
>

At bruge en global variabel i denne situation er en løsning, men virker
umiddelbart grimt og fortæller alle disse mange funktioner for meget om,
hvordan strukturen er implementeret - hvilket er for dyrt, hvis du senere
ændrer denne implementation. Lad os antage, at din struct indeholder
nyttig information, så du f.ex. har

typedef struct UsefulStuff {
/* .... */
} UsefulStuff;

Hvis du brugte C++, ville det bedste være at have et interface, hvor
du kunne skrive i de forskellige properties, og så have en metode
SetA(), SetB(), osv. i den klasse, der huser strukturen.

Som det er, ville jeg faktisk foreslå at lægge din struct som en
static-variabel
i en selvstændig c-fil, men lave et interface til manipulationen af den med
Get og Set-metoder - du skal så blot initialisere struct'en med
Set-metoderne
i begyndelsen af programmet og inkludere den tilhørende h-fil alle de
steder,
hvor du har brug for at modificere struct'en. På denne måde kan du bibeholde
din struct, men helt skjule implementationen af den som static eller global
eller overhovedet som struct bag de metoder, din h-fil tilbyder.

--
FAKLENS NYHEDSTJENESTE:
http://www.faklen.dk/nyheder

---

"Carsten Agger" <agger@post8.tele.dk> skrev i en meddelelse
news:bans5h$2e2p$1@jarjarbinks.mobilixnet.dk...
>

Jeg skrev:

> Som det er, ville jeg faktisk foreslå at lægge din struct som en
> static-variabel
> i en selvstændig c-fil, men lave et interface til manipulationen af den
med
> Get og Set-metoder - du skal så blot initialisere struct'en med
> Set-metoderne
> i begyndelsen af programmet og inkludere den tilhørende h-fil alle de
> steder,
> hvor du har brug for at modificere struct'en. På denne måde kan du
bibeholde
> din struct, men helt skjule implementationen af den som static eller
global
> eller overhovedet som struct bag de metoder, din h-fil tilbyder.
>

En anden fordel ved at lave et sådant API i stedet for at sende din struct
med som parameter og i stedet for at gøre den til en global variabel er
i øvrigt, at det vil gøre det meget lettere at debugge, hvis der af en eller
anden grund skulle komme til at stå noget forkert/uventet i din struct - så
kan du finde ud af, hvor det kom fra, uden at skulle have et breakpoint alle
de steder, hvor dataene bliver opdateret.

--
FAKLENS NYHEDSTJENESTE:
http://www.faklen.dk/nyheder

---

> At bruge en global variabel i denne situation er en løsning, men virker
> umiddelbart grimt og fortæller alle disse mange funktioner for meget om,
> hvordan strukturen er implementeret - hvilket er for dyrt, hvis du senere
> ændrer denne implementation. Lad os antage, at din struct indeholder
> nyttig information, så du f.ex. har
>
> typedef struct UsefulStuff {
> /* .... */
> } UsefulStuff;
>
> Hvis du brugte C++, ville det bedste være at have et interface, hvor
> du kunne skrive i de forskellige properties, og så have en metode
> SetA(), SetB(), osv. i den klasse, der huser strukturen.

Jeg vil nu mene at et fint namespace burde være nok indpakning til at huse
sådanne globale variable.

namespace nGlobalVars {
unsigned long volatile g_CurrentTime;
};