VC++ Implementation of Switch Statement

[cdimauro]

• 

Ed è il motivo per cui mi sono convertito a Python. Sebbene non sia affatto assente da critiche in tal senso (le metaclassi fanno venire il mal di testa), in generale è un linguaggio semplice e veloce da padroneggiare.

[cdimauro]

• 

Per questo è meglio che ci sia qualcuno che imprima una precisa direzione. E' il caso di Python, dove lo sviluppo del linguaggio, della VM, e della libreria, è ovviamente affidato a un folto gruppo di sviluppatori, ma Guido, il creatore del linguaggio, rimane il "benevolo dittatore" e si esprime sui cambiamenti, arrivando a "mettere il veto" quando lo ritiene opportuno (es: sulle tail call, i break "labelled", lo switch/case, il do/while, ecc.).

[cdimauro]

• 

Purtroppo quel libro è disponibile soltanto in versione cartacea. Dopo aver comprato il Kindle, non ho proprio voglia di prendere altra roba "scomoda", e per giunta costosa.

Comunque ho letto velocemente sulla paginetta wiki di Modula-3 che l'operator overloading fu scartato perché ritenuta una funzionalità complicata e pericolosa? Posso capire che tracciare l'esecuzione reale del codice possa diventare più difficile, ma pericolosa?
Sull'ereditarietà multipla nulla da dire, invece. In Python l'ho usata pochissime volte, e sostanzialmente come "mixin".

[cdimauro]

• 

Purtroppo quel libro è disponibile soltanto in versione cartacea. Dopo aver comprato il Kindle, non ho proprio voglia di prendere altra roba "scomoda", e per giunta costosa.

E' un libro fantastico (la libreria di I/O è la più performante che ci sia).

Per questo volevo prenderlo. Ho visto anche un po' di recensioni, e ne parlano benissimo. Poi io rimangono ancora di matrice pascal-wirthiana, per cui vado a nozze quando trovo materiale informatico che parla o fa uso di linguaggi come questi.

Comunque il capitolo più menzionato da libri di compilatori o di design è "How the language got its spots"

OK, grazie.

Comunque ho letto velocemente sulla paginetta wiki di Modula-3 che l'operator overloading fu scartato perché ritenuta una funzionalità complicata e pericolosa?

Credo che pericoloso sia riferito al multiple inheritance e che complicating sia riferito all'operator overloading

Ah, bene. Ha molto più senso.

[Z80Fan]

• 

Ma come, dov'è il mio messaggio!?
Avevo scritto una risposta relativamente lunga ieri, è andato perso...

Se mi ricordo bene, avevo dato come esempio di problema con la standardizzazione da parte di molte persone l'introduzione di memory_model_relaxed (qui e qui, quello che dico è nel secondo) nei std::atomic<> di C++11 perchè sulle architetture POWER e ARMv7 il modello SC-DRF con le barriere acquire/release avrebbe introdotto delle full memory barrier che avrebbe ucciso le prestazioni, perciò IBM e ARM hanno insistito per inserire questa modalità (che deve essere specificata esplicitamente cmq).
I due video son simpatici, tenuti da Herb Sutter; di C++ c'è ben poco, è praticamente un'introduzione sui modelli della memoria e come (non) usare le barriere di memoria.

Poi avevo scritto una mia interpretazione dell'"indovinello" (prima di leggere la soluzione) dopo aver appreso che "base" non era un altro aggettivo di "destructor" (/me fails at english...): avevo preso praticamente quasi tutto giusto, eccetto che "abstract virtual base" l'avevo tradotto in "una classe base che ha almeno un metodo virtuale puro (quindi è astratta e non si può istanziare; in questo caso già il distruttore è il metodo virtuale puro)", mentre lui intendeva la "virtual inheritance" che non conoscevo o che mi ero dimenticato visto che non la ho mai usata.

Poi avevo espresso il mio dissenso verso l'ereditarietà multipla, che sarebbe una delle cose che andrebbero "deprecate" e incluse in quel famoso switch del compilatore di cui parlavo prima; avevo anche detto di togliere l'ereditarietà public/protected/private e fare solo la public, visto che le altre son usate estremamente di rado e spesso si può raggirare scegliendo in modo più preciso il livello di protezione direttamente nella classe base. Le interface a mo di Java sarebbero carine da inserire (forse necessarie togliendo l'ereditarietà multipla), e lato compilatore non sono per niente difficili da implementare, perchè si possono considerare come classi con solo metodi virtuali puri (e distruttore virtuale implicito), e poi si possono usare le stesse tecniche dell'ereditarietà multipla.

Concludevo che, alla fine, il C++ usato e utile è cmq un subset del totale (anche solo per il famoso export); se "deprecassero" le funzionalità più arcane o che son state inserite in fretta e furia, il codice vecchio continuerebbe a compilare, ma il codice nuovo lo si può creare direttamente nel modo "nuovo" e più appropriato.
Stroustrup dovrebbe anche difendere la sua creatura; magari lo standard "ristretto" non sarà nell'ISO, ma son sicuro che la comunità (specialmente open source) sarebbe disposta ad ascoltarlo, è pur sempre un nome conosciuto...

Praticamente il Type System non è a conoscenza del genericity, i moduli generici vengono istanziati da quake (il make tool di Modula-3) e il compilatore si ritrova solo i moduli specializzati. Questo elimina un sacco di problemi tipo un type system complesso e il code bloating/memory hogging dei template C++.

Non ho ben capito, riesci a farmi un esempio?

[Z80Fan]

• 

Intendo un esempio di tipo di dato generico, che viene specializzato in vari tipi, e di come appare nel codice macchina generato; ovviamente non intendo istruzione per istruzione, ma di come il codice distingue tra le specializzazioni senza ripetere il codice (modello C++) o Java (con codice generico che lavora tramite puntatori e va di boxing/unboxing).

[Z80Fan]

• 

Non so cosa tu intenda che per il modello del C++ non ci sia codice duplicato, tutto l'opposto. Sarò breve, perché ho il tempo contato con il contagocce.

Non hai letto bene: la frase (probabilmente scritta male) è da leggere come "distingue tra le specializzazioni senza o ripetere il codice (modello C++), o fare come Java[...]".
Il modello C++ è "ripetere codice", non "senza ripetere codice".

Limitare il genericity solo ai reference object è la soluzione adottata da ISO-Modula-2, Modula-3, Oberon-2ext, Java.

Ottimo, questo risponde al dubbio che avevo prima.

Shared object:

Il codice generato è unico per tutti i casi possibili. Vengono utilizzate le classi estese più grosse (T2 e P2) e le classi base vengono allocate con un padding tutte della stessa dimensione.
Per il parametro basic type viene usato il basic type più grande rappresentabile.

Numero totale di codice oggetto per classe: 2, numero funzioni: 2.

Vantaggi: Velocità di compilazione, easy debugging, no code bloating.

Svantaggi: Il codice delle classi occupa leggermente di più, overhead sui basic type, aritmetica lenta (gli interi vengono usati all'intero più grosso di 128 bit, i float sono tutti a precisione doppia, etc..).

Capito, quindi lascia un pochino l'efficienza di esecuzione per facilitare la programmazione e la compilazione. Ottimo.
(il numero di codice oggetto dovrebbe essere 1, non 2)

Quanti sono i primitive type in C++? 14? 9*2*14 = 252 funzioni in totale. Il C++ linker ovviamente eliminerà gran parte (se non quasi tutte) le istanze non utilizzate, ma sta di fatto che il compilatore per motivi di type checking andrà a generare tutto questo garbage.

Si beh, ovviamente questo assumendo che in un programma vengano richieste le specializzazioni per tutti i tipi: se vengono richieste due specializzazioni vengono compilate solo quelle, non è che il compilatore compila ad oltranza.

Vantaggi: Storage economy nell'allocazione delle classi, no overhead sui basic type, nessuna influenza sull'aritmetica.

Un altro vantaggio è che, poichè ogni specializzazione del template è come se fosse stata scritta a mano, il compilatore può ottimizzare il codice per ogni singola specializzazione; spesso questo (poichè quando il compilatore crea la specializzazione usata da un qualche altro codice ha a disposizione l'intera implementazione delle funzioni) si traduce nell'inline delle funzioni templatizzate nel codice della funzione chiamante, e permette ulteriori ottimizzazioni.

Questo ad esempio è molto utile con template di strutture dati che sono semplici nel loro codice, ad esempio una lista concatenata dove l'inserimento/eliminazione è solo un'assegnazione di qualche puntatore: in questo caso il codice finisce direttamente nel codice della funzione chiamante, a efficienza di esecuzione (si risparmia la chiamata a funzione etc).


Cmq grazie della spiegazione.

[Z80Fan]

• 

Se consideri l'istanziamento del generic/template sì, ma forse mi sono espresso male, mi riferisco qui all'object code delle classi, essendo 2 (indipendentemente dalle estensioni, dato che viene fatto il padding prendendo la classe con dimensione più grande) ci sono 2 object code per due classi. Invece se si vanno a considerare le estensioni sono 3+3 (6) object code, in tal modo si risparmia quando si alloca su stack.

Non mi riferivo al codice che va ad istanziare il generic/template (che sarebbe in questo caso il numero di funzioni). Forse tu consideri un template class (in questo caso sì, solo una istanza, anche se sarebbe da considerare a parte), in Ada il genericity è a livello modulare quindi ho considerato solo l'istanziamento delle due funzioni (che sarebbe 1 istanziamento del generic).

Ok, penso di aver capito un po' meglio; mi servirebbe conoscere un po' meglio Ada, ma per il momento la risposta mi soddisfa.

No, se sono typechecked vengono istanziate tutte, poi quelle inutilizzate vengono rimosse dal linker.

(Tu dirai, che ne può sapere se non conosce il C++?) Da Programming Language Pragmatics:

In the usual case, the compiler creates a separate copy of the code for every instance. (C++ goes farther, and arranges to type-check each of these instances independently.)
[...]
C++ will create specialized implementations of a generic for different built-in or value types.
[...]
C++ is by far the most ambitious. Its templates are intended for almost any programming task that requires substantially similar but not identical copies of an abstraction.

Mmmmmh... però da quella frase non è detto che debba per forza girare la passata di machine code generation, mi spiego: il compilatore C++, quando trova un template, lo parsa e si segna tutti i dati importanti nell'AST & co., e poi usa questa rappresentazione per fare i chek sui tipi, e passa alla generazione del codice solo quando ha deciso che effettivamente la specializzazione si ha da compilare.

(Ovviamente se c'è scritto per inciso sul libro che genera pure tutto il codice, ignora quel che dico )

Se ti interessa il language design ed il language implementation, è un must (1000 pagine circa).

Me lo segno tra i libri da leggere; è un argomento che mi interessa molto, anche se il tempo è poco.

[Z80Fan]

• 

Ehm, non credo sia possibile fare type checking su un template non istanziato a meno che non ci sia qualche metodo che non conosco. Il type checking richiede che tutti i tipi di un determinato blocco facciano parte della symbol table, in modo tale che dopo il lookup si hanno informazioni sugli operatori implementati da quel tipo (=, <, o >=, etc).

Quello che intendo dire è che, metti di avere una funzione a caso:

Codice: [Seleziona]

template<typename T>
T modulo(T a, T b) {
    return a % b;
}
...
int res = modulo(10, 5);
Prima di tutto un compilatore fatto bene ha abbastanza informazioni per sapere di dover elaborare solo "int modulo(int, int)", ma anche se si mettesse a istanziare il template per tutti i tipi base T = {char, short, int, float, double, unsigned,...}, non è detto che debba anche generare il codice macchina per tutti quelli, quindi ad esempio nel codice oggetto per il file che contiene quel codice non ci sarà il codice oggetto per "char modulo(char,char)", "short modulo(short,short)" etc, ma solo "int modulo(int, int)".

In questo senso "il compilatore non compila a oltranza".

In realtà c'è una soluzione a questo problema, ovvero il constrained genericity di Eiffel, nella definizione del template puoi passare determinate interfacce di tipi, prendendo l'esempio di wikipedia in quel caso puoi passare solo tipi che implementano l'interfaccia comparable (=, !=, <,>, <=, >=).
Qui puoi fare un po' di type checking senza istanziare il template prima, perché conosci un minimo di informazioni sugli operatori che implementa

Assomiglia ai concepts (o meglio, i concepts assomigliano a quello) che si stanno progettando per il prossimo standard di C++.

[Z80Fan]

• 

Io mi chiedo perché concetti semplici e lineari devono renderli immensamente complicati in C++, i concepts sono estremamente perversi rispetto al constrained genericity. Basterebbe solo che implementassero le interfacce

Per questo hanno addirittura dovuto lasciare l'idea originale e creare i Concepts Lite!

[fulvio]

• 

Limitare il genericity solo ai reference object è la soluzione adottata da ISO-Modula-2, Modula-3, Oberon-2ext, Java.

Ci sono due code pattern generation: lo shared object (di Ada) e specific object instantiation (di C++).

Immaginiamo di avere un generic package o template che accetta due classi con tre livelli di extension ed un tipo basic type come parametro, vengono usate per due funzioni all'interno del package/template. Classi T, T2 (estende T), T3 (estende T2), P, P1 (estende P), P2 (estende P1).


Shared object:

Il codice generato è unico per tutti i casi possibili. Vengono utilizzate le classi estese più grosse (T2 e P2) e le classi base vengono allocate con un padding tutte della stessa dimensione.
Per il parametro basic type viene usato il basic type più grande rappresentabile.

Numero totale di codice oggetto per classe: 2, numero funzioni: 2.

Vantaggi: Velocità di compilazione, easy debugging, no code bloating.

Svantaggi: Il codice delle classi occupa leggermente di più, overhead sui basic type, aritmetica lenta (gli interi vengono usati all'intero più grosso di 128 bit, i float sono tutti a precisione doppia, etc..).


Specific object instantiation:

Viene istanziato codice per ogni classe in ogni sua estensione e per ogni basic type.
Trattiamo prima il caso delle classi:
Le classi vengono istanziate in ogni loro estensione, T, T1, T2, P, P1, P2. Il codice del template (le due funzioni) viene allocato per ogni coppia: T, P;  T, P1;  T, P2; ... T3, P3;

Numero totale di codice oggetto per classe: (3+3) 6, numero funzioni: 18 (3*3 * 2).

Quanti sono i primitive type in C++? 14? 9*2*14 = 252 funzioni in totale. Il C++ linker ovviamente eliminerà gran parte (se non quasi tutte) le istanze non utilizzate, ma sta di fatto che il compilatore per motivi di type checking andrà a generare tutto questo garbage.

Vantaggi: Storage economy nell'allocazione delle classi, no overhead sui basic type, nessuna influenza sull'aritmetica.

Svantaggi: Super code bloat, ultra slow compilation time, nightmare debugging.

I template del C++ sono comunque (inutilmente) molto avanzati e complicano di tantissimo questo code pattern generation. Non sono un esperto di C++ per poter dire di più.

Mi dilungherei sulle alternative/varianti ma per ora non posso, non ho nemmeno riletto per vedere se ho scritto inesattezze

Questo thread è davvero interessante, mi dispiace solo di non avere molto tempo. Se pur sono d'accordo su praticamente tutto quello che dice dsar, vorrei mettere solo un secondo le cose in prospettiva: molte delle cose cattive del C++ vengono dalla sua necessità di includere il C (quasi del tutto) e rimanere per lo più compatibile con esso. Certo ci sono scelte che potevano essere fatte diversamente, ma se il tuo primo vincolo è "devo rimanere compatibile con il C" allora diventa più difficile fare le cose diversamente da come sono state fatte (è una intuizione perchè non ho pensato seriamente ha come poteva evolvere il C++ senza quel vincolo).

Il libro di Stroustrup comunque non è di language design, è più una introduzione al linguaggio. So che scrisse un altro libro, "The Design and Evolution of C++", dove spiegava il perchè di molte scelte, ma non l'ho mai letto.

Sui template anche io sono d'accordo che è un meccanismo inutilmente complicato (tant'è che è turing complete) ma se ne sono accorti e hanno introdotto constexpr anche per questo, avere computazioni a compile-time senza l'uso della metaprogrammazione. Se ti limiti ai concetti base, quando i concept lite saranno implementati scrivere una funzione che calcola la media di una sequenza sarà una cosa come:

Codice: [Seleziona]

auto mean( Sequence seq )
{
  return std::accumulate( begin(seq), end(seq), 0.0 ) / seq.size(); 
}

Questo sarà effettivamente un template, anche se non c'è bisogno della parola template, su qualsiasi modello di sequenza

Scrivere la parte di infrastruttura sarà difficile (uno stack exception safe è già una sfida abbastanza difficile), ma se le astrazioni e le librerie le scrivono gli esperti, l'utilizzo poi diviene abbastanza semplice. Almeno è questo l'intento. C'è sempre un livello di complessità esposto al programmatore, ma se vuoi poter decidere l'allineamento e il layout dei dati in memoria e dettagli del genere è difficile nascondere del tutto certe cose.

Principalmete che linguaggio usi?

[cdimauro]

• 

Premetto che mi sono goduto quest'interessantissima discussione , c'è qualcosa che non è mi chiara.

Limitare il genericity solo ai reference object è la soluzione adottata da ISO-Modula-2, Modula-3, Oberon-2ext, Java.

E da Python, che ha soltanto reference object alla fine. D'altra parte è la soluzione più semplice.

Ci sono due code pattern generation: lo shared object (di Ada) e specific object instantiation (di C++).

Immaginiamo di avere un generic package o template che accetta due classi con tre livelli di extension ed un tipo basic type come parametro, vengono usate per due funzioni all'interno del package/template. Classi T, T2 (estende T), T3 (estende T2), P, P1 (estende P), P2 (estende P1).


Shared object:

Il codice generato è unico per tutti i casi possibili. Vengono utilizzate le classi estese più grosse (T2 e P2) e le classi base vengono allocate con un padding tutte della stessa dimensione.
Per il parametro basic type viene usato il basic type più grande rappresentabile.

Numero totale di codice oggetto per classe: 2, numero funzioni: 2.

Vantaggi: Velocità di compilazione, easy debugging, no code bloating.

Svantaggi: Il codice delle classi occupa leggermente di più, overhead sui basic type, aritmetica lenta (gli interi vengono usati all'intero più grosso di 128 bit, i float sono tutti a precisione doppia, etc..).

Gli interi dovrebbero arrivare a 64 bit al massimo.

A parte questo dettaglio, non capisco per quale motivo per il basic type si debba utilizzare il più grande rappresentabile. Se utilizzi un basic type come parametro per il generic package, che viene usato poi in tutte le classi di cui sopra, e mettiamo che tale template venga "istanziato" usando soltanto interi a 8 e 16 bit, a conti fatti il compilatore dovrebbe utilizzare l'intero più grande utilizzato, quindi quello a 16 bit, anziché la massima rappresentazione (32 o 64 bit) per l'unica copia di dati (definiti nelle classi, come parametri dei metodi, e come variabili locali) e codice che ne fa uso.

[cdimauro]

• 

Principalmete che linguaggio usi?

Questa me la chiedo anche io 

Azzardo: PHP e/o Javascript.

[cdimauro]

• 

E da Python, che ha soltanto reference object alla fine. D'altra parte è la soluzione più semplice.

E va bene in tutti i casi. Ho visto povere argomentazioni contro questo tipo di genericity, come per esempio quando fanno vedere che le operazioni su intero/float wrappate in un object reference sono lente per via di quello che chiamano boxing/unboxing.
I container sono fatti per conservare oggetti, non per farci dei calcoli di sopra. Un buon programmatore si copia il tipo di dato in una struttura locale (o direttamente in delle variabili) se c'è una lunga computazione da fare

Assolutamente d'accordo. Con Python, comunque, non si può fare, perché non esistono tipi primitivi, ma soltanto reference a oggetti; d'altra parte non è nato pensando alle prestazioni.

Gli interi dovrebbero arrivare a 64 bit al massimo.

Sì, hai ragione, non so per quale motivo ricordassi che GNAT supportasse 128 bit (con l'uso di due registri e 16 byte di allocazione nelle strutture). Invece l'implementazione supporta fino a 64 bit, boh.. starò tirando le cuoia

Ho visto che GNAT è un'implementazione di ADA. E' chiaro ed è ragionevole che se il linguaggio supporti interi a 128 o più bit il massimo intero rappresentabile non potrebbe non tenerne conto. Solo che a livello prestazionale le ricadute sarebbero tutt'altro che trascurabili.

A parte questo dettaglio, non capisco per quale motivo per il basic type si debba utilizzare il più grande rappresentabile. Se utilizzi un basic type come parametro per il generic package, che viene usato poi in tutte le classi di cui sopra, e mettiamo che tale template venga "istanziato" usando soltanto interi a 8 e 16 bit, a conti fatti il compilatore dovrebbe utilizzare l'intero più grande utilizzato, quindi quello a 16 bit, anziché la massima rappresentazione (32 o 64 bit) per l'unica copia di dati (definiti nelle classi, come parametri dei metodi, e come variabili locali) e codice che ne fa uso.

In C++ una cosa del genere si potrebbe accettare (se solo non supportasse l'uso implicito dei template) ma in Ada no. In C++ un vero separate compilation non esiste.

I generics in Ada vengono compilati una sola volta e viene generato un unico (shared) object code per sempre. Se prima l'object code è stato generato per il basic type (più grande istanziato) a 16 bit e poi vari mesi dopo in un modulo X è stato istanziato per 32 bit, allora l'object code del generic andrebbe rigenerato e tutti i package che fanno uso del generic package andrebbero ricompilati perché cambiano tutti gli offset. Questo va contro il principio del modularity, solo la modifica dell'interfaccia del modulo implica la ricompilazione del modulo e di tutti moduli che lo utilizzano

Il modularity è un big topic, però stringendo in Ada una cosa del genere non sarebbe accettabile :-)

Ho capito, e in quest'ottica sicuramente è molto comodo l'approccio utilizzato.
Però in ottica di generazione di un binario partendo da tutti i sorgenti, preferirei un approccio più ottimizzato, che funzioni come ho descritto sopra.

Diciamo che l'approccio modularity di Ada lo posso accettare quando sto lavorando a un progetto (in modalità debug), per cui è senz'altro comodo non dover ricompilare continuamente tutto (in C e C++ la ricompilazione è overkill; beati i tempi di Turbo Pascal e Delphi), ma quando devo generare la build finale (modalità release) mi aspetto che debba essere fatto tutto il possibile per tirare fuori il meglio; SE ci sono le condizioni, ovviamente.

Principalmete che linguaggio usi?

Questa me la chiedo anche io 

Azzardo: PHP e/o Javascript.

Credo non potesse finirmi peggio

L'avevo intuito dai discorsi che avevi fatto. Purtroppo è capitato pure a me in passato. Adesso in generale programmo poco, e ho a che fare più che altro con C/C++ e Python (le rare volte che  sviluppo roba; da solo), con qualcosa di Fortran (niente sviluppo, fortunatamente).

Ti auguro di trovare di meglio, perché francamente mi sembri sprecato. Anzi, se hai voglia di cambiare aria (in tutti i sensi) e di lavorare in un ambiente di gran lunga più stimolante, fammi sapere.

[cdimauro]

• 

Quindi con l'embedded C hanno finalmente reso onore al mito del C, che lo dipinge come un linguaggio di basso livello? Perché personalmente cosa NON apprezzo del C è il fatto che venga usato per system programming, ma non mi dà la possibilità di andare realmente a toccare certi dettagli della macchina, come ad esempio definire dei tipi interi di dimensione precisa in termini di bit, endianess, e altro che farebbe comodo nell'ottimizzazione delle istruzioni e dell'uso dei registri.

Se hanno risolto con questo embedded C, allora magari un'occhiata gliela butto (anche se la sintassi del C mi rimane comunque sullo stomaco).