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

[mjordan]

Originariamente inviato da DioBrando

Se tra le fonti che hai guardato in rete ti è capitata quella di Wikipedia puoi leggere come in realtà l'avesse smentita già prima.
In ogni caso permettimi ma il fatto che appaia su di una intervista nel 96 non significa che prima non l'abbia mai smentita.
Non tutte le dichiarazioni vengono riportate, catalogate e soprattutto per intero.

Probabilmente alla ennesima volta in cui gli hanno stracciato i maroni ha voluto una volta per tutte precisarla.

In ogni caso qui si può leggere un estratto, da cui cito:

When IBM introduced its PC in 1981, many people attacked Microsoft for its
role. These critics said that 8-bit computers, which had 64K of address space,
would last forever. They said we were wastefully throwing out great 8-bit
programming by moving the world toward 16-bit computers.

We at Microsoft disagreed. We knew that even 16-bit computers, which had 640K
of available address space, would be adequate for only four or five years.

Sapevano già da allora che avrebbero creato Windows...

[gugoXX]

Originariamente inviato da DioBrando

Probabilmente alla ennesima volta in cui gli hanno stracciato i maroni ha voluto una volta per tutte precisarla.

Mi sa che e' proprio cosi'.
Comunque chiunque ne capisce qualcosa di architetture e Sistemi Operativi capisce che quella frase lascia il tempo che trova.
Come ho detto prima, qualunque cosa avesse o non avesse detto Bill Gates al tempo e' ininfluente.
Avrebbe potuto pensare che 640k andavano bene, come anche che andassero bene 64k o non bastassero 4GB.
Tanto la decisione su quanta RAM poter montare e quindi indirizzare con il suo DOS non stava a lui ma alla Intel e alla IBM.

La quale non ha limitato l'indirizzamento a 1MB perche' gli piaceva cosi'.
Semplicemente se oggi portare 1 segnale e poi anche un pin in piu' di Address Bus costa qualcosa, allora costava molto ma molto di piu'.
Non per niente il databus dell 8086 era addirittura in comune con l'address bus (con somma gioia dei memory controller)

[cdimauro]

Originariamente inviato da gugoXX

Mi sa che e' proprio cosi'.
Comunque chiunque ne capisce qualcosa di architetture e Sistemi Operativi capisce che quella frase lascia il tempo che trova.
Come ho detto prima, qualunque cosa avesse o non avesse detto Bill Gates al tempo e' ininfluente.
Avrebbe potuto pensare che 640k andavano bene, come anche che andassero bene 64k o non bastassero 4GB.
Tanto la decisione su quanta RAM poter montare e quindi indirizzare con il suo DOS non stava a lui ma alla Intel e alla IBM.

In primis a Intel, che ha messo il limite di 1MB per il processore. La frittata l'ha completata IBM, organizzando la memory map in maniera decisamente stupida, arrivando a occupare la memoria alt dal segmento B0000 in poi; non contenta della cazzata, con la scheda grafica EGA ha pensato bene di scendere fino al segmento A0000.

La quale non ha limitato l'indirizzamento a 1MB perche' gli piaceva cosi'.
Semplicemente se oggi portare 1 segnale e poi anche un pin in piu' di Address Bus costa qualcosa, allora costava molto ma molto di piu'.
Non per niente il databus dell 8086 era addirittura in comune con l'address bus (con somma gioia dei memory controller)

Esattamente, ma quella gestione astrusa dei segmenti se la poteva anche risparmiare: è una cazzata immane.

Internamente poteva benissimo usare i registri di segmento come facevano tante altre architetture a 16 bit dell'epoca: come BANCHI di memoria e non come aree sovrapponibili. Quindi indirizzando "linearmente" la memoria (potenzialmente fino a 4GB internamente).

Tra l'altro non avrebbe avuto neppure la necessità di aggiungere un sommatore in ogni parte del chip in cui doveva esserci la logica di generazione dell'indirizzo della memoria fisica, risparmiando ulteriori transistor.

Esternamente poi poteva tranquillamente continuare limitare il numero di bit di indirizzamento a 20, e continuare a indirizzare soltanto 1MB di memoria, come facevano già altre architetture (esempio la Motorola, che col 68000 "troncava" gli indirizzi a 24 bit e col 68008 a 20 bit, e col 68010 a 30 bit, ma internamente rimanevano sempre a 32 bit).

Alla Intel gli ingegneri dovevano essere masochisti autolesionisti, visto che hanno continuato a fare cazzate anche con gli altri processori (vedi 286, a che indirizzava virtualmente 24 bit: gran passaggio quello da 20 a 24 bit, non c'è che dire).

[gugoXX]

Originariamente inviato da cdimauro

...

Quoto tutto. L'ho sempre pensato anche io.
Anche se forse adesso avremmo ancora i 16bit e neppure i 32, altro che i 64.
E magari saremmo tutti piu' contenti e piu' veloci. Ma forse no. Boh.

[cdimauro]

Il passaggio ai 32 bit sarebbe arrivato ugualmente, e probabilmente negli stessi tempi: è il codice che spinge verso certe soluzioni architetturali, man mano che le esigenze cambiano (e si "complicano" le cose da fare).

Per il resto, sarei stato MOLTO più felice sicuramente da un'architettura "più lineare", e penso che anche la velocità ne avrebbe giovato (un'architettura meno complicata è più facile da "spingere" in termini di velocità di esecuzione).

[marco.r]

Originariamente inviato da DioBrando

3) Effects Model
§ Purely Functional is the right default
§ Imperative constructs are vital features
that must be exposed through explicit
effects-typing constructs:
questo invece è il punto che mi intriga di più e che si ricollega a quel che ha scritto mindwings.

Quelle sopra non sono affermazioni di poco conto.
La prima dice ad esempio che non si deve adeguare solo il programmatore, ma anche il framework che usa (e, in conclusione, la libreria standard del linguaggio), perche' altrimenti farlo diventa una perdita di tempo che non porta vantaggi. E' se non altro fattibile, in generale, senza portare tanti cambiamenti al linguaggio. Un buon esempio e' il lisp, che viene geralmente considerato funzionale, ma in realta' e' multiparadigma (il goto esiste anche in lisp ), solo che ha come "right default" l'approccio funzionale. In generale ci cascano dentro un po' tutti i linguaggi funzionali, compresi quelli non puri, visto che, quando non si tratta di side-effects, tendono verso questo approccio.
La seconda e' ben ancora peggiore, in quanto dice ci deve essere una distinzione netta tra funzioni(/metodi) con side effects e quelle che non ce l'hanno, che una funzione che prende una stringa e la converte in numero e' sostanzialmente diversa da una che quel numero te lo ritorna da un file, perche' quest'ultima interagisce con il mondo esterno e non puoi usarla quando vuoi in vece della prima.
Questa distinzione la fanno pochissimi linguaggi mainstream (Haskell e mi sembra Clean) e, oltre a cambiare radicalmente il modo in cui ci programma, e' difficile da aggiungere in modo ragionevole ad un linguaggio senza cambiarlo profondamente

[cdimauro]

Ma poi un linguaggio puramente funzionale è ben difficile da programmare: ti costringe a tanti "contorsionismi" che con linguaggi già non puramente funzionali (è sufficiente l'operazione di assegnazione per rendere la vita più facile ) si risolvono senza troppi sbattimenti di testa.

[marco.r]

Originariamente inviato da cdimauro

Ma poi un linguaggio puramente funzionale è ben difficile da programmare: ti costringe a tanti "contorsionismi" che con linguaggi già non puramente funzionali (è sufficiente l'operazione di assegnazione per rendere la vita più facile ) si risolvono senza troppi sbattimenti di testa.

Non e' difficile, e' diverso.
Alcune cose sono piu' complesse, altre piu' semplici.
In un linguaggio puramente funzionale alcune cose come iteratori, revisioning (tenere vecchie versioni di un oggetto) vengono praticamente gratis. La memoria viene allocata e condivisa tra oggetti diversi automaticamente. Altre cose sono proprio impossibili da ottenere o richiedono algoritmi differenti (le code ad esempio)
Ovvio che per chi e' abituato in modo diverso sono contorsionismi.
In ogni caso trovo che una volta presa mano i vantaggi siano notevoli, soprattutto quando ci si rende conto di quanto sforzo mentali porti via il dover considerare i side effects.

Attenzione comunque che sopra non si parlava di linguaggi puramente funzionali, ma di preferire la programmare in modo puramente funzionale quando possibile.
Quel che volevo dire quanto questo sia possibile dipende molto dal supporto che viene dal linguaggio e dalla sua libreria.
In python ad esempio possiamo considerare la list comprehension come qualcosa di puramente funzionale, ma d'altra parte il metodo sort delle liste non lo e', per cui uno dovrebbe farsi sempre una copia della lista prima di ordinarla.

[cdimauro]

Esattamente, ma spesso si opera in locale, cioé non è necessario mantenere anche la vecchia lista.

Per un approccio puramente funzionale basta usare la funzione built-in sorted().

Comunque all'università non mi sono trovato male con la programmazione funzionale, e il mio prof. di linguaggi di programmazione (il mitico Giovanni Gallo ) s'è prodigato molto per farci apprezzare le meraviglie di questo paradigma con Scheme.

Debbo dire che ho apprezzato e mi affascina molto, tanto che spesso tendo a esagerare (e Fran per questo mi prende a mazzate un giorno sì, e l'altro pure ).

Soprattutto mi affascina il fatto che con la programmazione funzionale pura è più facile testare la correttezza del codice.

[tomminno]

Per ritornare in topic ho trovato goto anche nel codice per creazione dei processi e in quasi tutti i metodi dei Socket.

Ah e chi sostiene che con la programmazione ad oggetti eviti gli if?
Vedo sempre controlli del tipo

if (nonRispettaIRequisiti) 
throw EccezioneDiQualcheTipo()

E non potrebbe essere altrimenti.

[cdimauro]

Ne avevemo già parlato del perché serva almeno un if: http://www.hwupgrade.it/forum/showpo...4&postcount=48

[tomminno]

Originariamente inviato da cdimauro

Ne avevemo già parlato del perché serva almeno un if: http://www.hwupgrade.it/forum/showpo...4&postcount=48

Lo so benissimo, solo che ho letto tante volte discorsi del tipo "con la programmazione OOP eviti gli if", oppure "io non uso gli if ma mi affido alle eccezioni".

E quotando il tuo post:

La prassi con C & affini è quella della catena di if, dal primo che l'ha rilevata fino all'ultimo che la deve poi gestire. Tutti if condizionali, che, come sai, sono i peggiori da trattare per un processore.

Anche la prassi del C# è quella di una catena di if per vedere quale possibile eccezione sollevare.

[cdimauro]

Non è certo la stessa cosa che ripetere gli n controlli necessari per tutti i "livelli"...

Comunque quelli che riporti sono ovviamente slogan: la programmazione OOP non può eliminare gli if, ma certamente contribuisce, se ben usata, a ridurli anche di molto.

[fek]

Originariamente inviato da tomminno

Anche la prassi del C# è quella di una catena di if per vedere quale possibile eccezione sollevare.

Assolutamente no. Dipende dal design del codice.

[tomminno]

Originariamente inviato da fek

Assolutamente no. Dipende dal design del codice.

E questo design come lo definiresti?

    if (this.disposed)
    {
        throw new ObjectDisposedException(base.GetType().Name);
    }
    if (!string.IsNullOrEmpty(startInfo.UserName) || (startInfo.Password != null))
    {
        throw new InvalidOperationException(SR.GetString("CantStartAsUser"));
    }
    if ((startInfo.RedirectStandardInput || startInfo.RedirectStandardOutput) || startInfo.RedirectStandardError)
    {
        throw new InvalidOperationException(SR.GetString("CantRedirectStreams"));
    }
    if (startInfo.StandardErrorEncoding != null)
    {
        throw new InvalidOperationException(SR.GetString("StandardErrorEncodingNotAllowed"));
    }
    if (startInfo.StandardOutputEncoding != null)
    {
        throw new InvalidOperationException(SR.GetString("StandardOutputEncodingNotAllowed"));
    }
    if (startInfo.environmentVariables != null)
    {
        throw new InvalidOperationException(SR.GetString("CantUseEnvVars"));
    }

Per non parlare poi di questo

ShellExecuteHelper helper = new ShellExecuteHelper(executeInfo);
        if (helper.ShellExecuteOnSTAThread())
        {
            goto Label_0304;
        }
        int errorCode = helper.ErrorCode;
        if (errorCode != 0)
        {
            goto Label_0282;
        }
        long hInstApp = (long) executeInfo.hInstApp;
        if (hInstApp <= 8L)
        {
            if (hInstApp < 2L)
            {
                goto Label_0276;
            }
            switch (((int) (hInstApp - 2L)))
            {
                case 0:
                    errorCode = 2;
                    goto Label_0282;

                case 1:
                    errorCode = 3;
                    goto Label_0282;

                case 2:
                case 4:
                case 5:
                    goto Label_0276;

                case 3:
                    errorCode = 5;
                    goto Label_0282;

                case 6:
                    errorCode = 8;
                    goto Label_0282;
            }
        }
        if ((hInstApp <= 0x20L) && (hInstApp >= 0x1aL))
        {
            switch (((int) (hInstApp - 0x1aL)))
            {
                case 0:
                    errorCode = 0x20;
                    goto Label_0282;

                case 1:
                    goto Label_0276;

                case 2:
                case 3:
                case 4:
                    errorCode = 0x484;
                    goto Label_0282;

                case 5:
                    errorCode = 0x483;
                    goto Label_0282;

                case 6:
                    errorCode = 0x485;
                    goto Label_0282;
            }
        }
    Label_0276:
        errorCode = (int) executeInfo.hInstApp;
    Label_0282:
        throw new Win32Exception(errorCode);

[fek]

Originariamente inviato da tomminno

E questo design come lo definiresti?

    if (this.disposed)
    {
        throw new ObjectDisposedException(base.GetType().Name);
    }
    if (!string.IsNullOrEmpty(startInfo.UserName) || (startInfo.Password != null))
    {
        throw new InvalidOperationException(SR.GetString("CantStartAsUser"));
    }
    if ((startInfo.RedirectStandardInput || startInfo.RedirectStandardOutput) || startInfo.RedirectStandardError)
    {
        throw new InvalidOperationException(SR.GetString("CantRedirectStreams"));
    }
    if (startInfo.StandardErrorEncoding != null)
    {
        throw new InvalidOperationException(SR.GetString("StandardErrorEncodingNotAllowed"));
    }
    if (startInfo.StandardOutputEncoding != null)
    {
        throw new InvalidOperationException(SR.GetString("StandardOutputEncodingNotAllowed"));
    }
    if (startInfo.environmentVariables != null)
    {
        throw new InvalidOperationException(SR.GetString("CantUseEnvVars"));
    }

Cosi':

[tomminno]

Originariamente inviato da fek

Cosi':

Immaginavo
Peccato che quello è il modo in cui il .NET solleva le eccezioni.
E sinceramente non so come altro potrebbe fare.

[fek]

Originariamente inviato da tomminno

Immaginavo
Peccato che quello è il modo in cui il .NET solleva le eccezioni.
E sinceramente non so come altro potrebbe fare.

NullObject pattern e passa la paura. Il problema di quel codice non e' l'uso dei goto, ma chi lo ha scritto.
Se mi passa sotto gli occhi una catena di if cosi' ad una review, io non faccio fare il commit. E puo' piangere in tutte le lingue che vuole.

[tomminno]

Originariamente inviato da fek

NullObject pattern e passa la paura. Il problema di quel codice non e' l'uso dei goto, ma chi lo ha scritto.
Se mi passa sotto gli occhi una catena di if cosi' ad una review, io non faccio fare il commit. E puo' piangere in tutte le lingue che vuole.

Evidentemente chi sovrintende alla scrittura del .NET non è pignolo come te

Però scusa il null object pattern non solleva eccezioni, semplicemente crea un oggetto che non fa niente, ma come farebbe il framework a sollevarti una eccezione?
E' chiaro che deve controllare se un oggetto è nullo, se il valore è fuori range ecc...
E questo lo può fare solo con una catena di if che controlli che ogni parametro passato non sia nullo, ecc...

[fek]

Originariamente inviato da tomminno

Evidentemente chi sovrintende alla scrittura del .NET non è pignolo come te

Dipende dal team di sviluppo. Molti team di sviluppo in MS hanno degli ingegneri che si occupano solo del testing ed hanno potere di vita o di morte sul codice: se non rispetta gli standard qualitativi si riscrive. Purtroppo non tutti i team lavorano cosi'.

Però scusa il null object pattern non solleva eccezioni, semplicemente crea un oggetto che non fa niente, ma come farebbe il framework a sollevarti una eccezione?

Easy.

Redirector redirector = object.GetRedirector();
redirector.WriteSomething("bla bla bla");

class NullRedirector: public Redirector
{
 ...
  void WriteSomething(String string)
  {
     throw NOOOOWAYException("WriteSomething called on a NullRedirector, you twat");
  }
}

Inizializzi object nel costruttore per usare un NullRedirector di default e se nessuno sovrascrive quella proprieta' ti viene sparata un'eccezione al momento dell'uso. Nessun if di mezzo.

Good design is simple and communicate intensions well and clearly.