[programmazione] variabili globali o argomenti di una funzione

[ginetto79]

Buongiorno a tutti.

Sto utilizzando Matlab, ma la mia domanda dovrebbe essere di programmazione generale.
Nel programma ho definito una funzione che lavora su alcune variabili. Per poter lavorare su tali variabili, queste devono essere dichiarate come globali (se non erro, "public" in C) o passate come argomenti della funzione. Quali sono se differenze di questi due metodi? Qual'è il più conveniente?

Vi ringrazio

[franzauker2.0]

Accidenti, si apre un universo intero con questa domanda

La risposta è quindi lunghissima, ma almeno la formulo in versione "per bambini" (che sarebbero quelli che hanno fatto qualche corso, magari all'università, di superbase), per "ex-bambini" (come prima, ma con più esperienza) e per "ex-ex-bambini" (stato di illuminazione maggiore, magari a LED)

Per bambini la risposta è: niente variabili globali. Sono il male. Danno un sacco di problemi di aliasing blablabla sono da evitare come pattern malefico blablabla

Per ex-bambini: in alcuni casi le variabili globali fanno risparmiare così tante rotture di maroni che - sotto stretto controllo - fanno più bene (al portafoglio, nel senso riduzione tempo di sviluppo) che male (alla pulizia del codice).

Per ex-ex-bambini: fai come vuoi, nulla ti vieta di usare tutte le variabili globali del mondo, le quali in generale sono più efficienti di quelle locali. Se sei abituato a scrivere videogiochi in assembler non t'impressioni certo per questi motivi
In certi ambiti esistono SOLO variabili globali, altri SOLO locali, scegli quello più vantaggioso (per il portafoglio)

[Scara95]

In C public non esiste.
In ogni caso: in generale evita le variabili globali, usale solo se sono costanti di configurazione a cui non assegnerai mai un valore in esecuzione.

Aggiungere un parametro ad una funzione ti permette inoltre di generalizzarla e poterla riutilizzare in più ambiti. Un altro svantaggio delle variabili globali è appunto quello di non poter essere usate su strutture/variabili diverse.

Per i problemi di performance, l'aggiunta di un parametro passato come puntatore/referenza risulta in un lieve impatto sulle performance e in un grande guadagno di flessibilità/riutilizzo.

Pensa anche al futuro non solo ad ora, l'utilizzo di variabili globali introduce varie complicazioni anche nella lettura e comprensione del codice...

Le variabili globali non sono sempre più performanti, ciò varia da linguaggio a linguaggio e da implementazione a implementazione.

Esempio banale:
Lua (linguaggio di scripting) permette tranquillamente l'uso di più interpreti in parallelo in uno stesso programma in quanto tutto ciò che gli serve è contenuto in una struttura passata come argomento alle funzioni.
CPython sembra permettere l'uso di più interpreti in parallelo, che in realtà non funzionano in parallelo in quanto un solo pezzo di codice viene eseguito alla volta e i vari processi si contendono l'uso dell'interprete, questo per l'utilizzo di variabili globali...

[MItaly]

Se n'è parlato tante volte... http://forum.html.it/forum/showthrea...hreadid=887694

Originariamente inviato da Scara95
CPython sembra permettere l'uso di più interpreti in parallelo, che in realtà non funzionano in parallelo in quanto un solo pezzo di codice viene eseguito alla volta e i vari processi si contendono l'uso dell'interprete, questo per l'utilizzo di variabili globali...

Occhio che qui non stai più parlando di variabili globali in sé, ma da accesso da thread diversi ai medesimi dati (che possono essere globali o meno), una problematica correlata ma indipendente.
Inoltre, i vari processi Python sono completamente indipendenti e girano in parallelo; il problema di CPython è il GIL (Global Interpreter Lock), che (in parte) impedisce l'esecuzione parallela di più thread all'interno dello stesso interprete dato che c'è un unico lock per tutte le strutture dati condivise dell'interprete (e se scrivi un interprete per forza c'è un suo stato globale - sia che lo passi in giro come parametro, sia come global); è possibile rendere più granulare il lock (per Python 2.qualcosa ci fosse una patch del genere), ma pare che nel caso di CPython peggiorasse molto le prestazioni per via delle continue acquisizioni/rilasci dei vari lock.

[Scara95]

Smentiscimi se sbaglio, che non ne sono sicuro: se devo lavorare su dati indipendenti su thread indipendenti in Lua uso due stati diversi, uno per thread C, in CPython non c'é alcun modo...
(ora é più una domanda che un'affermazione, come sempre tu mi togli certezze MItaly )

[MItaly]

Originariamente inviato da Scara95
Smentiscimi se sbaglio, che non ne sono sicuro: se devo lavorare su dati indipendenti su thread indipendenti in Lua uso due stati diversi, uno per thread C, in CPython non c'é alcun modo...

Il problema non sono i dati, ma l'esecuzione: l'interprete Python quando sta "macinando" il codice intermedio tiene occupato il GIL, che impedisce di passare ad un altro thread.
Se però richiami funzioni esterne, queste possono rilasciare il GIL mentre vanno (a patto ovviamente che altri thread non gli cambino i dati di nascosto) e consentire così un certo grado di parallelismo. Ad esempio, nel codice che sto scrivendo il grosso del lavoro è fatto in un'estensione scritta in C++ (con binding SIP), e all'ingresso della chiamata C++ viene rilasciato il GIL; in questa maniera posso eseguire in thread diversi il mio codice C++ senza che nulla rimanga bloccato.