Torvalds e C++

[marco.r]

Originariamente inviato da PGI-Bis

La superiorità putativa dell'orientamento agli oggetti rispetto ad altre prospettive sta nel suo perchè. L'orientamento agli oggetti è il tentativo di far eseguire ad un calcolatore la rappresentazione umana della soluzione ad un problema. Compito di enorme difficoltà perchè qui andiamo a seminare un orto, quello della cognizione umana dei fenomeni, che è pieno di buche. Che sia questo il suo perchè è un fatto storico, desumibile dagli scritti di Alan Kay, Nygaard e Dahal: cioè coloro che hanno fondato l'orientamento agli oggetti.

Questo nell' ipotesi che l'orientamento agli oggetti sia sempr la "rappresentazione umana della soluzione ad (di?) un problema". Ma e' sempre cosi' ? Non mi sembra, anzi in matematica l'approccio "ad oggetti" e' tutto fuorche' la norma. Posso in ogni caso ricondurre tutto a quell'orientamento, ma il risultato non e' sempre intuitivo.
Ad esempio un intero e' un reale, per cui in una gerarchia mi aspetterei di vedere i reali come base degli interi, ma d'altra parte i reali supportano delle operazioni aggiuntive (divisione ad esempio) per cui sembrerebbe il contrario...
Cade quindi quello che dovrebbe essere il vantaggio di usare una rappresentazione piu' "umana" (ovvero di essere piu' diretta e comprensibile).
Senza contare che quello della OOP e' un modelo particolare, e come tutti i modelli comporta delle semplificazioni/assunzioni/etc. che possono far si' che in alcune circostanze il modello stesso sia sbagliato.

[atragon]

Originariamente inviato da k0nt3

eh no il preprocessore FA parte del linguaggio ed è specificato nello standard. altrimenti ogni compilatore avrebbe direttive discordanti con le altre e a quel punto sarebbero tanti dialetti del linguaggio. e invece no, tutti usano #include #define #ifdef perchè sono definiti nello standard (6.10 Preprocessing directives )

Sicuro sia questa l'interpretazione? Il preprocessore per come me lo ricordo in C è un programma che si occupa di compiere delle operazioni preliminari sul sorgente e applica le direttive impartite. Chiaramente va standardizzato (e ci mancherebbe) visto che il risultato dei mastruzi che compie è ciò che di fatto il compilatore elebora ma, proprio per la sua natura, non direi che è parte del linguaggio in senso stretto.

[PGI-Bis]

Non ti so dire quale sia la prospettiva degli studi matematici. O ingegneristici o filosofici.

Io parlo della ricerca di una prospettiva applicabile alla programmazione. La programmazione è l'attivita di rappresentazione della soluzione di (è vero ) un problema. Rappresentare significa descrivere in certi termini. Ecco, noi cerchiamo quei certi termini. Se nella programmazione procedurale quei certi termini sono registro di memoria, operazione elementare, ordine parziale tra operazioni, nella programmazione orientata agli oggetti quei termini potrebbero essere oggetto e relazione.

In linea di principio poter descrivere la soluzione nella sua forma umana è vantaggioso perchè non comporta una trasformazione dei termini in cui la soluzione è espressa. E' per questo che dico "è superiore alle altre prospettive".

Dico che questa superiorità è putativa, cioè non dimostrabile nei fatti, non tanto perchè la prospettiva orientata agli oggetti, in quanto modello, è un'approssimazione ma in quanto la realtà che vorremmo approssimare non è chiara.

La prospettiva procedurale è l'approssimazione di una realtà nota: il funzionamento di un calcolatore.

La prospettiva orientata agli oggetti è l'approssimazione di un ipotesi: il funzionamento di un essere umano.

E' questa natura ipotetica che causa la grande varietà di idee e soluzioni che si percepisce nelle discussioni sull'orientamento agli oggetti. Ed è la stessa ragione per cui vent'anni fa per fare orientamento agli oggetti si dovevano scrivere gerarchie di classi mentre oggi non parliamo neppure più di classe.

[k0nt3]

Originariamente inviato da atragon

Sicuro sia questa l'interpretazione? Il preprocessore per come me lo ricordo in C è un programma che si occupa di compiere delle operazioni preliminari sul sorgente e applica le direttive impartite. Chiaramente va standardizzato (e ci mancherebbe) visto che il risultato dei mastruzi che compie è ciò che di fatto il compilatore elebora ma, proprio per la sua natura, non direi che è parte del linguaggio in senso stretto.

lo stesso succede per i template d'altra parte (danno indicazioni al compilatore su come compilare il programma)... se io scrivo #include o #define in C sto dicendo qualcosa in un linguaggio e questo linguaggio è il C

[Hall999]

Originariamente inviato da k0nt3

lo stesso succede per i template d'altra parte (danno indicazioni al compilatore su come compilare il programma)... se io scrivo #include o #define in C sto dicendo qualcosa in un linguaggio e questo linguaggio è il C

nel libro c how to program dice che le direttive del preprocessore non fanno parte del linguaggio c

[cdimauro]

Originariamente inviato da k0nt3

eh no il preprocessore FA parte del linguaggio ed è specificato nello standard. altrimenti ogni compilatore avrebbe direttive discordanti con le altre e a quel punto sarebbero tanti dialetti del linguaggio. e invece no, tutti usano #include #define #ifdef perchè sono definiti nello standard (6.10 Preprocessing directives )

Mettersi d'accordo mi pare il minimo, ma ripeto: un preprocessore non fa parte del linguaggio vero e proprio. Tant'è che lo si può benissimo aggiungere in un secondo momento senza toccare di una virgola né il linguaggio né i compilatori esistenti.

Pre-processore, appunto.

questo è solo ed esclusivamente perchè il C++ è dotato di una libreria standard più completa. infatti se si usasse questa libreria http://moonflare.com/code/ctl/list.php sarebbe semplice, efficiente (forse più efficiente dei templates) e chiaramente procedurale

Usa le macro (quindi il preprocessore). Ma tu guarda: non l'avrei mai detto.

ps. mi pare che per ora il sort non è implementato, ma chiaramente ci vuole pochissimo a implementare l'algoritmo che si desidera (anche qui è una mancanza della libreria e non del linguaggio)

Non credo sia così facile. Se prendi l'esempio di cui sopra, cioé la definizione di una lista che conserva dei punti, servirà definire un algoritmo di ordinamento per questo tipo di dati.
Anche qui "a naso" servirà qualche macro per gestire l'operazione di ordinamento in maniera "astratta".

sono daccordo sul fatto che il C++ si può usare come il C, ma non sono daccordo sul fatto che questo sia un modo "sano" di programmare.
per intenderci... o usi gli oggetti o non li usi e se non li usi il C è la scelta migliore. se fai un minestrone delle due cose viene fuori una schifezza, quindi non ha senso dire uso il C++ come se fosse il C e poi se mai mi servirà un'oggetto lo userò.

Te l'avevo già scritto tempo fa e te lo ripeto ancora una volta: il C++ non ha soltanto gli oggetti in più rispetto al C!

Originariamente inviato da k0nt3

lo stesso succede per i template d'altra parte (danno indicazioni al compilatore su come compilare il programma)...

I template NON SONO MACRO! Fanno parte del linguaggio e già a livello di parsing vengono fatti tutti i controlli che è possibile fare (leggi: sui tipi di dato che NON sono opachi).

se io scrivo #include o #define in C sto dicendo qualcosa in un linguaggio e questo linguaggio è il C

Quindi se io scrivo

#define STAMPA(CITTA) print "Com'è bello far l'amore da " + CITTA + ' in giù...'

dici che un compilatore C riuscirebbe a digerirlo? Tanto sto usando #define in C, no?

P.S. In Python funzionebbe, ma... non farebbe niente. Il # marca l'inizio di un commento.

[k0nt3]

Originariamente inviato da cdimauro

Mettersi d'accordo mi pare il minimo, ma ripeto: un preprocessore non fa parte del linguaggio vero e proprio. Tant'è che lo si può benissimo aggiungere in un secondo momento senza toccare di una virgola né il linguaggio né i compilatori esistenti.

beh ma allo stesso tempo direi che il preprocessore è una parte indispensabile del linguaggio C, non sarebbe possibile nemmeno includere una libreria senza. e poi ripeto..

#includimi stringhe.h

int main(int argc, char *argv[])
{
    return 0;
}

non è codice C perchè non rispetta lo standard

Originariamente inviato da cdimauro

Pre-processore, appunto.

il termine ha a che fare con il compilatore, non con il linguaggio.
il linguaggio è composto da sintassi e semantica. la sintassi mi dice cosa posso scrivere, mentre la semantica mi dice cosa significa quello che ho scritto.
la semantica di #include è dire al compilatore di includere la libreria specificata, non vedo cosa gli manca per essere parte del linguaggio

Originariamente inviato da cdimauro

Usa le macro (quindi il preprocessore). Ma tu guarda: non l'avrei mai detto.

cambia la sintassi ma in fondo con i template succede la stessa cosa. cioè il compilatore li espande al momento della compilazione l'unica differenza è che non deve necessariamente farlo inline

Originariamente inviato da cdimauro

Non credo sia così facile. Se prendi l'esempio di cui sopra, cioé la definizione di una lista che conserva dei punti, servirà definire un algoritmo di ordinamento per questo tipo di dati.
Anche qui "a naso" servirà qualche macro per gestire l'operazione di ordinamento in maniera "astratta".

l'unica cosa che serve è una funzione per comparare due elementi... un puntatore a funzione in parole povere

Originariamente inviato da cdimauro

Te l'avevo già scritto tempo fa e te lo ripeto ancora una volta: il C++ non ha soltanto gli oggetti in più rispetto al C!

lo so visto che l'ho usato molte volte il C++, ma il discorso non cambia.. usare il C++ come se fosse il C è snaturarlo, come è snaturare il C quando si tenta di programmare a oggetti

Originariamente inviato da cdimauro

I template NON SONO MACRO! Fanno parte del linguaggio e già a livello di parsing vengono fatti tutti i controlli che è possibile fare (leggi: sui tipi di dato che NON sono opachi).

vorrà dire che template e macro non hanno la stessa semantica e nemmeno la stessa sintassi

Originariamente inviato da cdimauro

Quindi se io scrivo

#define STAMPA(CITTA) print "Com'è bello far l'amore da " + CITTA + ' in giù...'

dici che un compilatore C riuscirebbe a digerirlo? Tanto sto usando #define in C, no?

P.S. In Python funzionebbe, ma... non farebbe niente. Il # marca l'inizio di un commento.

la sintassi e la semantica del preprocessore sta scritta sullo standard.. se scrivi una roba del genere dovresti dargli una ripassata

[Ufo13]

Originariamente inviato da PGI-Bis

Ed è la stessa ragione per cui vent'anni fa per fare orientamento agli oggetti si dovevano scrivere gerarchie di classi mentre oggi non parliamo neppure più di classe.

Eh si`, al giorno d'oggi nessuno parla di classi

[PGI-Bis]

Era una frase sintetica. Le classi ci sono ancora ma dal significato originario di elemento di una gerarchia si è passati all'altro (pur presente) di raggruppamento di esemplari. C'è una crisi dell'ereditarietà. Si vede chiaramente in Chapel, Scala, Newspeak, Fortress. Cioè nelle lingue che nascono adesso.

[cdimauro]

Originariamente inviato da k0nt3

beh ma allo stesso tempo direi che il preprocessore è una parte indispensabile del linguaggio C, non sarebbe possibile nemmeno includere una libreria senza. e poi ripeto..

Questo è UN ALTRO problema, e non riguarda soltanto il C.

Ad esempio anche il Pascal ne soffriva; problema risolto poi con delle direttive di preprocessore aggiunte a posteriori (quelle della Borland sono diventate poi lo standard di fatto per tutti i linguaggi di derivazione Pascal).

#includimi stringhe.h

int main(int argc, char *argv[])
{
    return 0;
}

non è codice C perchè non rispetta lo standard

Non rispetta la sintassi del preprocessore che è stato scelto dallo standard, ma potrei crearmi il mio preprocessore per cui avrebbe perfettamente senso.

il termine ha a che fare con il compilatore, non con il linguaggio.
il linguaggio è composto da sintassi e semantica. la sintassi mi dice cosa posso scrivere, mentre la semantica mi dice cosa significa quello che ho scritto.
la semantica di #include è dire al compilatore di includere la libreria specificata, non vedo cosa gli manca per essere parte del linguaggio

Quella sintassi specifica al PREPROCESSORE di compiere un'operazione, e non ha nulla a che vedere col linguaggio.

cambia la sintassi ma in fondo con i template succede la stessa cosa. cioè il compilatore li espande al momento della compilazione l'unica differenza è che non deve necessariamente farlo inline

No, ti ho spiegato prima che coi template non è così.

l'unica cosa che serve è una funzione per comparare due elementi... un puntatore a funzione in parole povere

Questo mi sembra ovvio.

lo so visto che l'ho usato molte volte il C++, ma il discorso non cambia.. usare il C++ come se fosse il C è snaturarlo, come è snaturare il C quando si tenta di programmare a oggetti

Su questo sono perfettamente d'accordo.

vorrà dire che template e macro non hanno la stessa semantica e nemmeno la stessa sintassi

Infatti sono due cose completamente diverse.

la sintassi e la semantica del preprocessore sta scritta sullo standard.. se scrivi una roba del genere dovresti dargli una ripassata

Lo standard ha specificato, oltre alla sintassi del linguaggio C, anche quella del preprocessore, ma sono due cose diverse appunto.

Eh, no, non ho bisogno di ripassarlo, perché il K&R lo conosco bene, come conosco bene anche tanta letteratura informatica in merito a linguaggi, interpreti e compilatori, e la differenza fra linguaggio e preprocessore.

Comunque basta farti una ricerca e troverai montagne di letteratura in merito: non sono certo io ad arrogarmi il diritto di definire cos'è un preprocessore e cos'è un linguaggio, visto che l'ha già fatto gente ben più illustre di me, e da parecchio tempo.

[cdimauro]

Originariamente inviato da PGI-Bis

Era una frase sintetica. Le classi ci sono ancora ma dal significato originario di elemento di una gerarchia si è passati all'altro (pur presente) di raggruppamento di esemplari. C'è una crisi dell'ereditarietà. Si vede chiaramente in Chapel, Scala, Newspeak, Fortress. Cioè nelle lingue che nascono adesso.

E Python (anche se è vecchiotto come linguaggio)?

[PGI-Bis]

Python è bello vecchio e, in tutta onestà, è una lingua a cui non ho mai prestato grande attenzione.

Comunqe se ha una sintassi specifica per la definizione di un oggetto (di solito è come quella della classe ma genera un singleton, genera Scala) e un tipo "interfaccia" la cui applicabilità è indipendente da una specifica dichiarazione (a la Ruby o Chapel) allora propone un'alternativa alla gerarchia classica.

Che non sia un barbatrucco: qualsiasi linguaggio che definisca un meccanismo introspettivo (la riflessione di Java, ad es.) permette anche di dire che un certo oggetto è un Pippo a prescindere dal fatto che dichiari di avere Pippo come parente e di usarlo come un Pippo. Altro è avere altro è simulare.

[k0nt3]

Originariamente inviato da cdimauro

Eh, no, non ho bisogno di ripassarlo, perché il K&R lo conosco bene, come conosco bene anche tanta letteratura informatica in merito a linguaggi, interpreti e compilatori, e la differenza fra linguaggio e preprocessore.

Comunque basta farti una ricerca e troverai montagne di letteratura in merito: non sono certo io ad arrogarmi il diritto di definire cos'è un preprocessore e cos'è un linguaggio, visto che l'ha già fatto gente ben più illustre di me, e da parecchio tempo.

forse davo per scontata una definizione troppo generale di linguaggio comunque vedrò di documentarmi

[cdimauro]

Originariamente inviato da PGI-Bis

Python è bello vecchio e, in tutta onestà, è una lingua a cui non ho mai prestato grande attenzione.

Comunqe se ha una sintassi specifica per la definizione di un oggetto (di solito è come quella della classe ma genera un singleton, genera Scala) e un tipo "interfaccia" la cui applicabilità è indipendente da una specifica dichiarazione (a la Ruby o Chapel) allora propone un'alternativa alla gerarchia classica.

Python ha una sintassi specifica per la definizione di un oggetto e supporta l'ereditarietà multipla.

Come linguaggio dinamico, poi, non ha nemmeno bisogno di specificare una classe (o interfaccia) da cui derivare specifiche funzionalità. Voglio dire che se nei miei progetti ho bisogno che gli oggetti che manipolo debbano rispondere a particolari funzionalità, è sufficiente che siano stati definiti degli appositi metodi.

Esempio:

class A:
  def Stampa(self):
    print 'Hai invocato il metodo "Stampa" della classe A'

class B:
  def Stampa(self):
    print 'Questa volta hai invocato il metodo "Stampa" della classe B'

def ProvaStampa(Istanza):
  Istanza.Stampa()


ProvaStampa(A())
ProvaStampa(B())

A e B derivano entrambe dalla classe fondamentale (object), ma sono capaci di rispondere allo stesso messaggio.

Che non sia un barbatrucco: qualsiasi linguaggio che definisca un meccanismo introspettivo (la riflessione di Java, ad es.) permette anche di dire che un certo oggetto è un Pippo a prescindere dal fatto che dichiari di avere Pippo come parente e di usarlo come un Pippo. Altro è avere altro è simulare.

Con Python puoi avere entrambe le cose.

[PGI-Bis]

Insomma no. .

[cdimauro]

Originariamente inviato da PGI-Bis

Insomma no. .

Come no? Puoi fare tutto! E' onnipotente.

[PGI-Bis]

Ma che ci fai, ma che fai! Ci giochi a tresette con python!

[cdimauro]

Originariamente inviato da PGI-Bis

Ma che ci fai, ma che fai! Ci giochi a tresette con python!

A parte gli scherzi, Python riesce a soddisfare entrambe le cose che hai riportato: perché non andrebbe bene?

Il tutto dipende soltanto dall'uso che se ne fai: puoi anche sviluppare classi e interfacce dimenticandoti della reflection e della possibilità di definire soltanto dei metodi come interfaccia.

Nota bene: potrei anche forzare che un'istanza derivi da una classe che implementa un certo metodo di una certa interfaccia, in modo da eliminare il secondo tipo di utilizzo.
In soldoni: prima di chiamare il metodo Stampa posso anche controllare che l'oggetto in questione sia istanza di una "interfaccia" (che in Python si traduce sempre in una classe, visto che supporta l'ereditarietà multipla) ben precisa.

[PGI-Bis]

Ho detto no perchè la partita si gioca non sulla possibilità di invocare dei metodi ma sull'appartenenza ad un tipo in base al fatto che abbia o non abbia certe caratteristiche.

Supponendo che una funzione accetti come argomento un Impiegato (perchè usa opera su metodi che sono propri dei soli impiegati), come discrimi in un insieme di Dipendenti chi siano gli impiegati e chi siano gli operai?

Attraverso relazioni statiche io passo a quella funzione tutti e soli quei riferimenti che dichiarino di essere Impiegati (o che abbiano il ruolo di, come è solitamente necessario).

Attraverso relazioni dinamiche io passo a quella funzione tutti e soli coloro i quali possiedano le caratteristiche di un impiegato, a prescindere dal fatto che dichiarino o meno di esserlo.

Tutto qua.

[cdimauro]

Devi scusare la mia ignoranza, ma io lo vedo perfettamente realizzabile in Python senza ricorrere a "barbatrucchi".