[.NET] Perchè il goto è così usato?

[71104]

Originariamente inviato da cionci

Ah ok...ho capito il problema...sentiamo fek cosa suggerirebbe di fare per una soluzione del genere...

ti riferisci al mio post o a quello di tomminno?

[cionci]

Originariamente inviato da 71104

ti riferisci al mio post o a quello di tomminno?

Al tuo sorry...conoscendo un po' le API Win32 capisco benissimo la situazione a cui ti riferisci

[71104]

Originariamente inviato da cionci

conoscendo un po' le API Win32 capisco benissimo la situazione a cui ti riferisci

ah ma guarda che non è solo questione di Win32 eh: gli stessi scenari mi si presentano puntualmente tali e quali anche con malloc/free, realloc/free, fopen/fclose, costruttore di ifstream e metodo fail, costruttore di ofstream e metodo fail anche lì... addirittura con new e delete

edit - e poi la sai la cosa divertente? certe volte ho anche provato a ridurre il codice di cleanup affidandomi al fatto che quando il processo termina la sua memoria virtuale scompare e tutti i suoi HANDLE vengono chiusi (e di conseguenza non ha realmente senso liberarsi di molte risorse che in realtà vanno tenute fino alla fine dell'esecuzione). i problemi di questo approccio sono:
1) se il codice cambia e alcune risorse non devi più tenerle fino alla fine ma puoi liberarle prima, devi rintracciare tutte le loro allocazioni e scrivere le corrispondenti deallocazioni; per esperienza personale posso dirti che troppi dettagli potresti tralasciare quando effettui sul codice operazioni del genere in un secondo momento anziché in fase di prima scrittura... almeno per me è così.
2) in Win32 certe risorse (quelle di User32 e GDI32) non se ne vanno da sole quando il processo termina; tempo fa ho letto su MSDN che è questa la causa di certi errori di visualizzazione delle icone del desktop che capitano ogni tanto (a dire il vero in Windows 2000 avevo l'impressione di vederli più spesso che in XP, chissà perché; forse è solo questione di hash tables più grosse).
3) il punto 2 si può estendere ai files temporanei: quelli se non li cancelli non se ne vanno in qualunque piattaforma.

[cionci]

Un conto sono 12 istruzioni API ognuna con una sequenza di istruzioni di pulizia diversa, un altro sono poche istruzioni con diversa gestione degli errori, lì ci stanno bene le eccezioni. Se in quel caso non riesci a farlo in maniera semplice senza il goto significa che devi riprogettare la struttura ad oggetti...

[cdimauro]

Originariamente inviato da 71104

ah ma guarda che non è solo questione di Win32 eh: gli stessi scenari mi si presentano puntualmente tali e quali anche con malloc/free, realloc/free, fopen/fclose, costruttore di ifstream e metodo fail, costruttore di ofstream e metodo fail anche lì... addirittura con new e delete

Tutto qui? E' ora di passare a Python allora:

with open('Pippo.txt', 'wb') as f:
  f.write('Fai i tuoi porci comodi, a chiudere il file ci penso io.')

with MyMutex:
  print "Sto accedendo all'area critica. Tranquillo: al release ci penso io!"

[71104]

Originariamente inviato da cdimauro

Tutto qui? E' ora di passare a Python allora:

come ho già detto non uso mai i goto negli ambienti managed. inoltre ci sono cose che non so se riuscirei a fare in Python, e anche se fosse possibile a occhio direi che mi farei solo del male. ad esempio in questo periodo mi sto dilettando a creare un desktop manager (ne ho visti a decine in giro ma nemmeno uno decente) che mostri N pulsanti in una desk band, ciascuno corrispondente ad un desktop; per fare ciò devo anzitutto implementare la desk band (cosa che in Windows si fa scrivendo un oggetto COM, e tanti cari saluti a Python ), e poi devo gestire i desktop virtuali con le apposite API Win32.

[cdimauro]

Uomo di poca fede: http://sourceforge.net/projects/pywin32/

http://aspn.activestate.com/ASPN/doc...2/PyWin32.html

[kernel::panic]

Come diceva prima cionci, anche secondo me basterebbe usare le eccezioni... io perlomeno le uso perchè odio il goto

Per fare un esempio (PS: è anche più comodo da loggare perchè si mette una unica volta nel catch la chiamata al logger):

FILE *pFile=NULL;
HANDLE hMutex=NULL;
int *piBuffer=NULL;

try
{
	pFile=fopen("c:\\pippo.txt","w+");
	if(!pFile) throw exception("cippa lippa");

	hMutex=CreateMutex(.....);
	if(!hMutex) throw exception("pippo & pluto");
	
	// La new lancia già una std::bad_alloc se non c'è std::nothrow
	piBuffer=new int[1234];
		
	........
}
catch(const exception &ex)
{
	CLog::Put() << "E' successo un bel casino: " << ex.what() << endl;
}

if(pFile) fclose(pFile);
if(hMutex) ReleaseMutex(hMutex);
delete piBuffer;

Se invece sono richieste performance ultra-super-turbo allora il goto è molto più performante del try...catch (e anche del try...finally, senza catch, del c#). Lo stesso kernel di linux ne fa uso (http://kerneltrap.org/node/553/2131); probabilmente anche quello di win ma, essendo closed, non ci è dato saperlo

Ciao

[cdimauro]

Onestamente mi sa troppo di codice C-style. Preferisco questo:

if(FILE *pFile=fopen("c:\\pippo.txt","w+")) {
  try
    if (HANDLE hMutex=CreateMutex(.....) {
      try

        // La new lancia già una std::bad_alloc se non c'è std::nothrow
        if (int *piBuffer = new int[1234]) {

          try {
            // Do something...
          }
          catch(const exception &ex)
            CLog::Put() << "E' successo un bel casino lavornado col buffer: " << ex.what() << endl;

          delete piBuffer;
        }
        else
          throw exception("Allocazione buffer fallita!");

      catch(const exception &ex)
        CLog::Put() << "E' successo un bel casino lavorando dentro il mutex: " << ex.what() << endl;

      ReleaseMutex(hMutex);
    }
    else
      throw exception("Creazione mutex fallita!");

  catch(const exception &ex)
    CLog::Put() << "E' successo un bel casino lavorando col file: " << ex.what() << endl;

  fclose(pFile);
}
else
  throw exception("Apertura file fallita!");

Ovviamente sto assumendo, come te, che dentro la sezione catch non venga sollevata un'eccezione, altrimenti anche quella andava "blindata" dentro un try/catch.

Se invece sono richieste performance ultra-super-turbo allora il goto è molto più performante del try...catch (e anche del try...finally, senza catch, del c#).

Questo sarebbe da vedere.

Lo stesso kernel di linux ne fa uso (http://kerneltrap.org/node/553/2131); probabilmente anche quello di win ma, essendo closed, non ci è dato saperlo

Ciao

Il kernel di Linux fa ampio uso del goto semplicemente perché il suo autore lo ritiene un utile costrutto (e te pareva).
Direttamente dal link che hai postato:

I think goto's are fine, and they are often more readable than large
amounts of indentation. That's _especially_ true if the code flow isn't
actually naturally indented (in this case it is, so I don't think using
goto is in any way _clearer_ than not, but in general goto's can be quite
good for readability).

Of course, in stupid languages like Pascal, where labels cannot be
descriptive, goto's can be bad. But that's not the fault of the goto,
that's the braindamage of the language designer.

Linus

Il Pascal viene criticato soltanto perché le etichette del goto non possono essere identificatori "tradizionali", non in quanto tali!

"Dimenticando", tra l'altro, che da una cinquantina d'anni a questa parte l'uso del goto nella letteratura informatica è severamente deprecato, tant'è che lo stesso Wirth (creatore del Pascal) l'ha COMPLETAMENTE RIMOSSO dai successivi linguaggi che ha progettato.

La madre degli pseudo-programmatori è sempre incinta...

[71104]

Originariamente inviato da cdimauro

Uomo di poca fede: http://sourceforge.net/projects/pywin32/

http://aspn.activestate.com/ASPN/doc...2/PyWin32.html

omg ma guarda te oh

ma sta roba di preciso mi permetterebbe di scrivere in Python una DLL da usare come in-process server? anche esportando le funzioni DllCanUnloadNow, DllRegisterServer, DllGetClassObject e DllUnregisterServer? e Python supporta l'ereditarietà di interfacce multiple? perché una desk band è un oggetto che deve implementare almeno tre interfacce diverse.

[71104]

Originariamente inviato da kernel::panic

Per fare un esempio (PS: è anche più comodo da loggare perchè si mette una unica volta nel catch la chiamata al logger):

[...]

if(pFile) fclose(pFile);
if(hMutex) ReleaseMutex(hMutex);
delete piBuffer;

questa soluzione contiene del codice ridondante: le condizioni di fallimento vengono controllate due volte (durante il proseguimento dell'algoritmo e durante il cleanup). io le duplicazioni di codice le odio sia quando programmo in maniera "bella" e pulita in un ambiente OO e managed sia quando faccio porcate con Win32

probabilmente anche quello di win ma, essendo closed, non ci è dato saperlo

di sicuro Windows non fa uso di try/catch nel kernel dato che è scritto in C.

[71104]

Originariamente inviato da cdimauro

Questo sarebbe da vedere.

vabbè Cesare, non esageriamo adesso... ok le piattaforme managed ma stai paragonando l'istanziazione nell'heap di una classe (l'eccezione) con un jump incondizionato

edit - senza contare poi l'algoritmo di ricerca dell'exception handler lungo il call stack; ora permettimi, anche se non ho fatto test approfonditi, che un catch deve pesare necessariamente molto di più di un jump (incondizionato poi, una delle istruzioni più semplici che ci siano).

Il kernel di Linux fa ampio uso del goto semplicemente perché il suo autore lo ritiene un utile costrutto (e te pareva).

si appunto ragazzi, abbiamo datto del puttanaro a Dijkstra quindi evitiamo di idolatrare quell'incivile incompetente di Torvalds

[gugoXX]

Originariamente inviato da 71104

si appunto ragazzi, abbiamo datto del puttanaro a Dijkstra quindi evitiamo di idolatrare quell'incivile incompetente di Torvalds

Non l'ho capita questa.
Dijkstra amava i goto oppure sarebbe difficile costruire l'algoritmo di Dijkstra senza goto? La seconda non e' vera...

[cdimauro]

Originariamente inviato da 71104

omg ma guarda te oh

Tzé! Python è onnipotente.

ma sta roba di preciso mi permetterebbe di scrivere in Python una DLL da usare come in-process server? anche esportando le funzioni DllCanUnloadNow, DllRegisterServer, DllGetClassObject e DllUnregisterServer?

Non mi sono mai cimentato con queste cose onestamente, ma penso che per creare una DLL "farlocca" in cui integrare l'interprete Python non ci voglia molto.

Python è un linguaggio fortemente propenso sia alla sua estensione che all'integrazione in altre applicazioni (DLL incluse, quindi): http://docs.python.org/ext/ext.html

e Python supporta l'ereditarietà di interfacce multiple? perché una desk band è un oggetto che deve implementare almeno tre interfacce diverse.

Python supporta l'ereditarietà multipla, "alla C++", per cui sulla carta non avrebbe difficoltà.

Sulla desk band in particolare non so niente, ma qui http://aspn.activestate.com/ASPN/doc...c_and_COM.html trovi un esempio di utilizzo di un oggetto COM, mentre qui http://aspn.activestate.com/ASPN/doc...ell_Links.html usa la shell.

Mi fermo qui perché, come ho detto, su quanto chiedi non so nulla e non amo sparare puttanate come Torvalds.

[marco.r]

Originariamente inviato da 71104

si, e interferiscono con lo Structured Exception Handling

Giustificare un errore (usare i goto) con un altro (programmare in windows) non e' una buona cosa
Battute a parte, non mi vengono in mente molti casi in un cui abbia un senso, a parte
che nell'implementazione di funzionalita' di piu' alto livello (ad esempio la gestione delle eccezioni stessa). In particolare non mi e' chiaro il tuo esempio... puoi essere piu' esplicito ?

Originariamente inviato da cdimauro

Uomo di poca fede: http://sourceforge.net/projects/pywin32/

http://aspn.activestate.com/ASPN/doc...2/PyWin32.html

ipse dixit :o.

Ho avuto modo di implementare oggetti com e anche servizi in python, ed e' una vera sciocchezza (e lo dice uno che la programmazione in Windows la conosce poco).

Originariamente inviato da 71104

edit - senza contare poi l'algoritmo di ricerca dell'exception handler lungo il call stack; ora permettimi, anche se non ho fatto test approfonditi, che un catch deve pesare necessariamente molto di più di un jump (incondizionato poi, una delle istruzioni più semplici che ci siano).

Beh, un jump non locale e' una bestia decisamente diversa. Se invece ti riferisci sempre al solo jump locale probabilmente il costo dello stack unwind dovuto alla gestione delle eccezioni puo' essere ottimizzata senza problemi, mentre con la jump devi stare piu' attento (vedi mio post successivo)

[cdimauro]

Originariamente inviato da 71104

vabbè Cesare, non esageriamo adesso... ok le piattaforme managed ma stai paragonando l'istanziazione nell'heap di una classe (l'eccezione) con un jump incondizionato

edit - senza contare poi l'algoritmo di ricerca dell'exception handler lungo il call stack; ora permettimi, anche se non ho fatto test approfonditi, che un catch deve pesare necessariamente molto di più di un jump (incondizionato poi, una delle istruzioni più semplici che ci siano).

Qui c'è un problema di fondo da chiarire.

Se dobbiamo usare le eccezioni, non possiamo farlo com'è stato (anche nell'esempio che ho portato io) utilizzando gli if per controllare la restituzione o meno di una risorsa: stiamo programmando ancora in maniera "tradizionale" (sebbene le try/catch aiutino a sistemare meglio il codice).

Con le eccezioni io NON dovrei mettere NESSUN if, visto che al primo utilizzo della risorsa dovrebbe esser generata l'apposita eccezione.

Il codice, quindi, sarebbe perfettamente lineare e privo del benché minimo controllo che comporta SEMPRE un relativo salto CONDIZIONALE (i peggiori della specie, lo sai) nella soluzione "classica".

In soldoni, mi aspetterei roba così (lo scrivo in Python per sbrigarmi prima ):

try:
  f = open('pippo')

  try:
    print 'La prima riga è:', f.readline()
  except IOError:
    print 'Errore di lettura ci fu!'
  finally:
    f.close()

except:
  print 'Errore di apertura file ci fu!'

ZERO if, insomma, al contrario del codice tradizionale che ha SEMPRE un if e relativo salto.

Il che, permettimi, è MOLTO differente in termini prestazionali, visto che la creazione dell'oggetto eccezione avviene esclusivamente nel momento in cui effettivamente bisogna generarla.

x marco.r: grazie della tua testimonianza.

Comunque... eretico!!! Windows è er mejo che ci possa essere.

[marco.r]

Originariamente inviato da 71104

questa soluzione contiene del codice ridondante: le condizioni di fallimento vengono controllate due volte (durante il proseguimento dell'algoritmo e durante il cleanup). io le duplicazioni di codice le odio sia quando programmo in maniera "bella" e pulita in un ambiente OO e managed sia quando faccio porcate con Win32

E' ridondante perche' e' scritto piu' alla C che alla C++.
In un mondo ideale sia i file che i mutex sono oggetti che liberano automaticamente le risorse quando distrutti e che quindi lavorano bene col meccanismo delle eccezioni. Un esempio abbastanza vicino si potrebbe fare con gli fstream della libreria standard e i mutex delle boost:

try
{
	std::ofstream out("c:\\pippo.txt","w+");
	boost::thread::scoped_lock( ... );
	piBuffer=new int[1234];
	//  ...
}
catch(const exception &ex)
{
	CLog::Put() << "E' successo un bel casino: " << ex.what() << endl;
}
// look ma, no code cleanup !

Per inciso in questo caso ho usato scoped_lock per cui se durante il blocco try{...} qualcun altro lancia una eccezione mentre teniamo il mutex, la risorsa viene liberata. L'alternativa e' controllare _tutte_ le chiamate a funzioni metodi (anche quelli dichiarati throw()!) con dey try...catch nested.
In altri casi potrei non volerlo fare, e allora usero' un mutex "standard"

[kernel::panic]

Originariamente inviato da marco.r

E' ridondante perche' e' scritto piu' alla C che alla C++.
In un mondo ideale sia i file che i mutex sono oggetti che liberano automaticamente le risorse quando distrutti e che quindi lavorano bene col meccanismo delle eccezioni.

Esattamente! Il problema è proprio questo: le API dei sistemi operativi sono scritte in C (per cui no eccezioni), e sono poche le librerie scritte in C++ che ne fanno uso. Le boost ad esempio le usano e permettono la scrittura di codice "pulito" come nel tuo esempio.
In ambiente MS mi è capitato di usare ALT/MFC, che non usano le eccezioni, però incapsulano gli handle di sistema nelle classi (CRegKey, CMutex, ecc). Quindi non c'è bisogno di fare il cleanup: viene già fatto dal distruttore quando termina lo scoop.

[ally]

...scusate l'ignoranza...programmo in java dove il goto è riservato ma non utilizzabile...come mai questo goto è tanto bistrattato?...se esiste come funzione perchè è ritenuto una porcata?...

...ciao...

[cdimauro]

http://en.wikipedia.org/wiki/Spaghetti_code