Torvalds e C++

[PGI-Bis]

La teoria del fare programmazione orientata agli oggetti in Assembly ha un che di strano. Io mi domando, ad esempio, come sia possibile esprimere una relazione tra oggetti avendo a disposizione una manciata di registri prenominati.

[mindwings]

Originariamente inviato da PGI-Bis

Io non dubito di questo e sono sinceramente estasiato di fronte a tanta abbondanza. Ma con me non lo fa. Sarà che gli sto sui finferli.

Anche io all'inizio ho avuto problemi , ma si possono superare
i pregiudizi proprio non li mando giu della serie : " chi usa linux ha tempo da perdere "

Uso con molta soddisfazione sia Xp che Debian Linux

[variabilepippo]

La teoria del fare programmazione orientata agli oggetti in Assembly ha un che di strano. Io mi domando, ad esempio, come sia possibile esprimere una relazione tra oggetti avendo a disposizione una manciata di registri prenominati.

Ho citato la possibilità di sviluppare con il paradigma ad oggetti in Assembly solo a titolo di nota folcloristica.

D'altra parte se un compilatore C++ genera codice Assembly partendo da una rappresentazione ad alto livello di gerarchie ad oggetti non vedo perché un programmatore masochista, in vena di martoriamento di zebedei, non possa scrivere a manina ciò che il compilatore genera in automatico.

[PGI-Bis]

La possibilità di fare programmazione orientata agli oggetti si fonda sulla capacità dei compilatori di operare non solo come traduttori simbolici ma anche come trasformatori di prospettiva (da OO a procedurale nel caso di linguaggio OO).

Scrivere a mano ciò che produrrebbe un compilatore a fronte di un codice sorgente OO non è orientamento agli oggetti. Perchè il prodotto finale della compilazione è sempre ed immancabilmente procedurale. Lo è perchè la macchina che dovrà interpretare quel prodotto è meccanicamente vincolata ad un interpretazione procedurale dei fenomeni.

[k0nt3]

Originariamente inviato da fek

No. In C non puoi esprimere algoritmi che sono eseguiti a compile time (metaprogrammazione) come parte integrante del linguaggio. Non ha i template.

a parte che questo non diminuisce il potere espressivo del linguaggio perchè qualsiasi cosa volevi fare usando i template la puoi fare in un altro modo... comunque la metaprogrammazione in C esiste e si basa sul preprocessore (anche se minimale)

#define SWAP(a, b, type) { type __tmp_c; c = b; b = a; a = c; }

int main()
{
    int a = 3;
    int b = 5;

    printf("a is %d and b is %d\n", a, b);
    SWAP(a, b, int);
    printf("a is now %d and b is now %d\n", a, b);

    return 0;
}

inoltre se parliamo di C++ i template non sono sempre una soluzione elegante e/o efficiente
http://people.cs.uchicago.edu/~jacob...templates.html
soprattutto quando dice

C++ templates hide your intentions from the compiler: did you mean type abstraction? Did you mean a syntax extension? Did you mean constant-folding or compile-time code generation? The compiler doesn't know, so it has to just blindly apply the copy-and-paste strategy and then see what happens

[variabilepippo]

La possibilità di fare programmazione orientata agli oggetti si fonda sulla capacità dei compilatori di operare non solo come traduttori simbolici ma anche come trasformatori di prospettiva (da OO a procedurale nel caso di linguaggio OO).

La possibilità di mappare entità reali in oggetti ti è data dalla presenza di opportuni costrutti sintattici, nulla ti vieta di scrivere macro e strutture adatte a rappresentare oggetti in Assembly. Sono convinto che non ne valga assolutamente la pena (per una lunghissima serie di ragioni), ma tecnicamente si può fare, come è d'altronde dimostrato dai numerosi esempi reperibili on-line.

Considera poi che il C++ è nato come un "C con le classi":

To build that, I first used C to write a "C with Classes"-to-C preprocessor. "C with Classes" was a C dialect that became the immediate ancestor to C++. That preprocessor translated "C with Classes" constructs (such as classes and constructors) into C. It was a traditional preprocessor that didn't understand all of the language, left most of the type checking for the C compiler to do, and translated individual constructs without complete knowledge. I then wrote the first version of Cfront in "C with Classes".

Cfront was a traditional compiler that did complete syntax and semantic checking of the C++ source. For that, it had a complete parser, built symbol tables, and built a complete internal tree representation of each class, function, etc. It also did some source level optimization on its internal tree representation of C++ constructs before outputting C. The version that generated C, did not rely on C for any type checking. It simply used C as an assembler. The resulting code was uncompromisingly fast.

Ed il C non è altro che un Assembly "on steroids":

Naturalmente è possibile programmare "ad oggetti" e "per template" in Assembly puro (alla fine dei conti questo è ciò che producono i vari compilatori), e per estensione anche in ANSI/ISO C'89/99. Tuttavia si tratta di un passatempo assai poco salutare, sebbene non manchino esempi notevoli in merito.

[PGI-Bis]

Entità reale ed oggetto sono sinonimi. Non c'è un'associazione da fare. Credo che la definizione di forme sintattiche idonee a rappresentare gli oggetti corrisponda all'estensione del linguaggio.

Credo che il rapporto originario tra C e C++ da te citato sia un buon esempio. Come disse Alan Kay, C++ nasce come preprocessore di C, cioè introduce una serie di forme riconducibili a definizione C attraverso trasformazioni sintattiche automattizate.

Estende il linguaggio perchè l'atto di predisporre queste forme, l'atto di introdurre nel linguaggio questi opportuni costrutti, deve essere ripetuto ogni volta che si scriva un programma in una prospettiva diversa da quella che è naturale per il linguaggio. E', ancora una volta, la famigerata trappola di turing: un linguaggio non supporta una caratteristica se tale caratteristica deve essere definita ogni volta che la si voglia usare.

Poichè un linguaggio è identificato dall'insieme di caratteristiche che supporta, l'introduzione in pianta stabile di una forma sintattica non presente nell'originale produce necessariamente un nuovo linguaggio.

Insomma, fare programmazione orientata agli oggetti in assembly significa creare un linguaggio diverso da assembly. Ergo la programmazione orientata agli oggetti in assembly non è possibile.

[k0nt3]

Originariamente inviato da cdimauro

Rileggendomi non avevo messo un NON, per cui la frase assumeva il significato opposto. :|

Adesso va bene.

per lo meno lui ha dimostrato di saper programmare che ti piaccia o no. per fare un paragone quando un tale di nome zio Bill ha consegnato DOS a IBM, quest'ultima l'ha testato scoprendo oltre 300 bugs in circa 4000 linee di codice una media di tutto rispetto
FONTE: http://www.ordineingegneri.bergamo.i...e02/storia.htm

per quanto riguarda GIT vi consiglio di conoscerlo prima di giudicarlo.. perchè non è vero che software di quel tipo ce n'è a bizzeffe

[PGI-Bis]

E DOS l'avrebbe scritto Bill Gates?

[marco.r]

Originariamente inviato da k0nt3

a parte che questo non diminuisce il potere espressivo del linguaggio perchè qualsiasi cosa volevi fare usando i template la puoi fare in un altro modo...

Tutto si puo' fare in assembler se e' per quello... ma capirai che se devo andare a Berlino ci vado in aereo, anche se potrei andarci a piedi .

comunque la metaprogrammazione in C esiste e si basa sul preprocessore (anche se minimale)

#define SWAP(a, b, type) { type __tmp_c; c = b; b = a; a = c; }

int main()
{
    int a = 3;
    int b = 5;

    printf("a is %d and b is %d\n", a, b);
    SWAP(a, b, int);
    printf("a is now %d and b is now %d\n", a, b);

    return 0;
}

A proposito della metaprogrammazione in C++ si puo' dire tutto il male di questo mondo, ma non facendo esempi col preprocessore... , quando si va su cose un attimo piu' complesse tutti i problemi saltano fuori (ad esempio non hai mai la garanzia di scegliere nomi temporanei univoci).

[k0nt3]

Originariamente inviato da PGI-Bis

E DOS l'avrebbe scritto Bill Gates?

no ma zio Bill e cugino Allen ebbero il compito di ripulirlo dalle funzionalità e riempirlo di bug
scherzi a parte la storia è scritta nel link

[k0nt3]

Originariamente inviato da marco.r

Tutto si puo' fare in assembler se e' per quello... ma capirai che se devo andare a Berlino ci vado in aereo, anche se potrei andarci a piedi .

non si può nemmeno pretendere di usare l'aereo per andare al cesso

Originariamente inviato da marco.r

A proposito della metaprogrammazione in C++ si puo' dire tutto il male di questo mondo, ma non facendo esempi col preprocessore... , quando si va su cose un attimo piu' complesse tutti i problemi saltano fuori (ad esempio non hai mai la garanzia di scegliere nomi temporanei univoci).

io ho solo detto che il C ha il supporto per la metaprogrammazione, non ho detto che è superiore a quello fornito dal C++ (anzi mi sembra di aver detto che è limitato).
vero è che il supporto alla metaprogrammazione offerto dal C++ non è quanto di meglio si poteva pensare e qui rimando al link di prima

[Mixmar]

Originariamente inviato da PGI-Bis

E DOS l'avrebbe scritto Bill Gates?

Effettivamente no, non l'ha scritto lui.

[variabilepippo]

Poichè un linguaggio è identificato dall'insieme di caratteristiche che supporta, l'introduzione in pianta stabile di una forma sintattica non presente nell'originale produce necessariamente un nuovo linguaggio.

Insomma, fare programmazione orientata agli oggetti in assembly significa creare un linguaggio diverso da assembly. Ergo la programmazione orientata agli oggetti in assembly non è possibile.

Se distinguiamo entrambi tra l'opportunità e la possibilità di sviluppare "ad oggetti" (nota le virgolette) in C, Assembly o in qualunque altro linguaggio tendenzialmente procedurale allora stiamo dicendo la medesima cosa con forme diverse.

Nel libro Object Oriented Programming with ANSI-C viene discusso un possibile approccio all'OOP in C, esistono inoltre librerie che consentono di impiegare il paradigma ad oggetti in codice ANSI-C (ripeto per l'ennesimo volta: viene fuori una gran porcheria però si può fare), non mi sembra che usare una libreria equivalga a "creare un linguaggio diverso". Con un po' più di fatica e qualche ulteriore forzatura il discorso è applicabile anche all'Assembly.

[k0nt3]

Originariamente inviato da variabilepippo

Nel libro Object Oriented Programming with ANSI-C viene discusso un possibile approccio all'OOP in C, esistono inoltre librerie che consentono di impiegare il paradigma ad oggetti in codice ANSI-C (ripeto per l'ennesimo volta: viene fuori una gran porcheria però si può fare), non mi sembra che usare una libreria equivalga a "creare un linguaggio diverso". Con un po' più di fatica e qualche ulteriore forzatura il discorso è applicabile anche all'Assembly.

ti dirò.. per cose banali non è nemmeno una porcheria. un paio di puntatori a funzione e la tua stuct diventa un "oggetto" che ha relazioni con altri "oggetti"
ovvio che se devi implementare l'ereditarietà e tutto il resto diventa una porcheria, ma per quello infatti ci sono linguaggi apposta

[PGI-Bis]

Io parlo proprio della "possibilità", non dell'opportunità. Se fosse possibile sarebbe sempre opportuno usare la prospettiva orientata agli oggetti.

Una libreria può definire un diverso linguaggio se essa introduca forme sintattiche (modi di esprire le cose) non presenti nel linguaggio senza quella libreria.

Il fatto che l'introduzione di una nuova forma sintattica corrisponda alla creazione di un diverso linguaggio deriva dalla definizione di linguaggio (insieme di regole sintattiche per l'espressione di significati).

[marco.r]

Originariamente inviato da cdimauro

Il C++ può essere di basso livello tanto quanto il C: bisogna "soltanto" imparare a usare lo strumento giusto a seconda del tipo di (sotto)problema da risolvere.

Per far ciò è necessaria parecchia esperienza: bisogna entrare nella mentalità del programmatore C++, perché il linguaggio è complesso e ogni strumento merita d'esser sviscerato e "maturato".

Non sono d'accordo sul fatto che la programmazione di sistema debba essere relegata all'uso di strumenti di basso livello: proprio la presenza di s.o. scritti con linguaggi di livello più alto ne è, appunto, una controprova.

Come già detto si tratta di usare gli strumenti che il C++ (o qualunque altro linguaggio di alto livello) mette a disposizione nel giusto modo e al momento giusto.
Tanto per dirne una: non mi aspetto che all'interno della funzione malloc del s.o. venga utilizzato l'operatore new per allocare memoria per un oggetto, se non eventualmente dopo aver ridefinito opportunamente le funzioni di dis/allocazione da new e delete.

Quello che intendo dire e' che le funzionalita' in piu' del C++ vengono ad un costo notevole e, anche discorsi del tipo "il C e' meglio del C++" li trovo ridicoli, posso capire chi invece la mette sul "uso il C perche' secondo me il gioco non vale la candela", soprattutto in certi contesti.
Ad esempio gli iteratori, anche se molto comodi, richiedono una quantita' non banale di codice da scrivere, tanto che nei casi semplici uno non li usa, e ad esempio cicla direttamente sugli indici di un array. La cosa non e' bella perche' se certe forme, che dovrebbero esseer idiomatiche, non vengono usate nei casi semplici, i principianti tendono a non impararle e ad usarle col risultato che non lo faranno neanche nei casi in cui tornerebbe comodo, e rischiano di non capire quando lo fanno gli altri.

[variabilepippo]

Se fosse possibile sarebbe sempre opportuno usare la prospettiva orientata agli oggetti.

C'è anche chi dissente:

OOP criticism and OOP problems

Why I Prefer Procedural/Relational Over OOP

Core Philosophical Differences

OOP Versus Relational: Beyond the Hardware

Nota bene: per progetti sopra le 100K LOC preferirei ricevere una manganellata sui gioielli di famiglia piuttosto che adottare l'approccio procedurale. In alcuni contesti (embedded, realizzazione di device drivers o comunque di codice "vicino" all'hardware, etc) l'uso di linguaggi OOP non introduce vantaggi, anzi comporta una serie di problematiche.

Una libreria può definire un diverso linguaggio se essa introduca forme sintattiche (modi di esprire le cose) non presenti nel linguaggio senza quella libreria.

Non capisco come una libreria compilabile senza problemi da un compilatore pensato per un dato linguaggio possa costituire la definizione di un "diverso linguaggio". Loki, Boost (hai mai scritto un parser con la Spirit?) e la stessa STL introducono forme sintattiche non presenti nel C++ ma nessuno si sognerebbe di definirle "un altro linguaggio".

[atragon]

Originariamente inviato da marco.r

Quello che intendo dire e' che le funzionalita' in piu' del C++ vengono ad un costo notevole e, anche discorsi del tipo "il C e' meglio del C++" li trovo ridicoli, posso capire chi invece la mette sul "uso il C perche' secondo me il gioco non vale la candela", soprattutto in certi contesti.

Questo è molto più sensato delle farneticazioni villane di Linus.

[k0nt3]

Originariamente inviato da atragon

Questo è molto più sensato delle farneticazioni villane di Linus.

io non metto in dubbio la sua conoscenza dell'argomento, secondo me ha un modo di porsi sbagliato, ma questo fa parte del suo carattere

Originariamente inviato da marco.r

Quello che intendo dire e' che le funzionalita' in piu' del C++ vengono ad un costo notevole e, anche discorsi del tipo "il C e' meglio del C++" li trovo ridicoli, posso capire chi invece la mette sul "uso il C perche' secondo me il gioco non vale la candela", soprattutto in certi contesti.

*

Originariamente inviato da marco.r

Ad esempio gli iteratori, anche se molto comodi, richiedono una quantita' non banale di codice da scrivere, tanto che nei casi semplici uno non li usa, e ad esempio cicla direttamente sugli indici di un array. La cosa non e' bella perche' se certe forme, che dovrebbero esseer idiomatiche, non vengono usate nei casi semplici, i principianti tendono a non impararle e ad usarle col risultato che non lo faranno neanche nei casi in cui tornerebbe comodo, e rischiano di non capire quando lo fanno gli altri.

ecco pensate agli iteratori! il modo sbagliato per risolvere il problema giusto (ed è facile incappare in casi del genere trai programmatori che credono che Dio sia un oggetto) è vero che nel 99% dei casi quando itero su un array non me ne frega niente di sapere quanto è lungo, ma magari mi serve sapere qual'è l'elemento prima, o quello dopo, o quello modulo 2 per 6 chessò
ecco perchè il modo corretto per risolvere il problema è il seguente

foreach (j, char c; input)
{
       ...
       char a = c + (input[j%15]/input[j*(j-1)*(j-2)*(j-3)*(j-4)*(j^2)-1]);
       ...
}

con la possibilità di omettere il j nel caso sia superfluo

poi ci sono casi in cui serve definire un modo particolare di iterare su una collezione e lì si usa il buon vecchio pattern Iterator, ma sono casi particolari. l'importante è non sentirsi stupidi a ciclare su array per via del fatto che vanno specificati tutte le volte i limiti dell'array e/o bisogna creare una variabile apposta per tenere il conto dell'indice corrente