View Full Version : Il linguaggio di oggi e del futuro?
LupettoOne
31-10-2006, 00:24
Salve! Sono nuovo su questo sito e complimenti per tutto! Da anni ormai che vivo sull'informatica ma la cosa che mi manca è la programmazione! Sò i linguaggi che esistono e ho provato anche a studiarne qualcuno ma come si dice... l'informatica è ampia e la cosa migliore da fare è buttarsi su una strada e proseguire su quella! Quindi vorrei un vostro aiuto... un'aiuto da voi esperti! Ho deciso di studiare la programmazione però vorrei studiare una ma che mi servirà anche in futuro! Sento che il linguaggio più ricercato e che nn morirà è il java sia per sistemi linux e windows! Ma ho sentito ke anche il VB .net 2005 è anche richiesto solo che ovviamente è solo per sistemi windows! Vorrei un consiglio da voi quale linguaggio mi consigliate di studiare oggi come oggi? Vi ringrazio in anticipo!
giannola
31-10-2006, 07:04
Dipende da tante cose.
Innanzitutto da cosa intendi fare, se vuoi programmare delle applicazioni che girino su qualunque computer devi programmare in C o C++.
Diversamente se vuoi orientarti su una piattaforma oppure su un'altra puoi scegliere o il java (microsoft predilige il J# che è una variante di java) o il VB.
Ripeto dipende da cosa vuoi fare, programmi che partono da dos, giochi, applicativi standalone, applicativi web e web based, ecc.
A seconda del ramo che scegli poi fai la tua selezione.
Ziosilvio
31-10-2006, 08:10
Sò
http://forum.nipogames.com/images/smilies/zingarelli%20in%20testa.gif
Io so, tu sai, egli sa.
i linguaggi che esistono e ho provato anche a studiarne qualcuno
[CUT]
Ho deciso di studiare la programmazione però vorrei studiare una ma che mi servirà anche in futuro!
Una cosa?
Vorrei un consiglio da voi quale linguaggio mi consigliate di studiare oggi come oggi?
Python. (http://www.python.org/)
Soprattutto se parti da zero.
Anche giannola ti ha dato dei buoni consigli e soprattutto una buona panoramica.
Diciamo che:
- con Python fai quasi tutto con poca fatica, ma non puoi pretendere grandissime velocità di esecuzione;
- Java è molto diffuso, ma ha una sintassi un po' prolissa;
- C e C++ sono ottimi per programmi che devono eseguire molte istruzioni in poco tempo, ma richiedono attenzione e un minimo di esperienza "pregressa".
Sconsiglio invece VB, troppo legato alle piattaforme Microsoft: semmai, dovendo scegliere io, userei C#.
La situazione attuale sembra essere questa:
http://www.hwupgrade.it/forum/showthread.php?t=1311007
http://forum.nipogames.com/images/smilies/zingarelli%20in%20testa.gif
Io so, tu sai, egli sa. tu sei un maleducato, tu è un maleducato, tu siamo dei maleducati, tu siete dei maleducati, tu sono dei maleducati :O
voce del verbo tu essere maleducato :read:
non è buona netiquette correggere gli errori grammaticali/ortografici dell'interlocutore :read:
- con Python fai quasi tutto con poca fatica, ma non puoi pretendere grandissime velocità di esecuzione;
- Java è molto diffuso, ma ha una sintassi un po' prolissa;
- C e C++ sono ottimi per programmi che devono eseguire molte istruzioni in c'è una diffusa (quanto falsa e basata sul nulla) credenza che i programmi in C e C++ siano più performanti di quelli scritti in linguaggi cross-platform; ti credevo superiore a queste bassezze, ma mi sbagliavo :Prrr:
il vero vantaggio del C e del C++ sui linguaggi cross-platform non l'hai detto: è la potenza.
Sconsiglio invece VB, troppo legato alle piattaforme Microsoft: semmai, dovendo scegliere io, userei C#. fa lo stesso
Ziosilvio
31-10-2006, 11:38
c'è una diffusa (quanto falsa e basata sul nulla) credenza che i programmi in C e C++ siano più performanti di quelli scritti in linguaggi cross-platform; ti credevo superiore a queste bassezze, ma mi sbagliavo :Prrr:
il vero vantaggio del C e del C++ sui linguaggi cross-platform non l'hai detto: è la potenza
E che cosa dovrebbe voler dire "potenza", in questo contesto?
Diamoci una calmata ragazzi, non mi sembra il caso di metterla sul personale.
mad_hhatter
31-10-2006, 14:15
beh, il bytecode java viene eseguito da una macchina virtuale e quindi si introduce uno strato in più rispetto a un programma C++... inoltre java esegue molti piu controlli di coerenza (si vedano i puntatori a un vettore, per esempio)... immagino che queste cose rendano il codice java (compilatore jit a parte) almeno un pelo più lento di un programma scritto in c++
o mi sbaglio?
E che cosa dovrebbe voler dire "potenza", in questo contesto? che ci puoi* fare mediamente più cose.
* dal verbo potere, da cui viene anche potenza http://forum.nipogames.com/images/smilies/zingarelli%20in%20testa.gif :Prrr:
(compilatore jit a parte) e vabbè grazie :D
mad_hhatter
31-10-2006, 14:38
beh, il compilatore jit non è che ti salva sempre...
c'è una diffusa (quanto falsa e basata sul nulla) credenza che i programmi in C e C++ siano più performanti di quelli scritti in linguaggi cross-platform
C e C++ sono cross-platform... :confused: o forse indendevi dire che i programmi generati non lo sono ?
In ogni caso il fatto che si possano scrivere programmi piu' efficienti in Java non vuol dire che sia piu' facile farlo, anzi mi sembra che favorito uno stile di programmazione che agevola piu' la correttezza che non le performance (non che sia sbagliato, anzi !)
il vero vantaggio del C e del C++ sui linguaggi cross-platform non l'hai detto: è la potenza.
Dipende dalla definizione... quando un linguaggio e' potente, quando permette di generare programmi veloci ? quando riduce il tempo perso dal programmatore ? quando permette l'uso di diverse e maggiori tecniche di programmazione ?
Secondo molte definizioni, C e C++ sono tutt'altro che potenti (il C in particolare).
che ci puoi* fare mediamente più cose.
* dal verbo potere, da cui viene anche potenza http://forum.nipogames.com/images/smilies/zingarelli%20in%20testa.gif :Prrr:
E' una definizione ancora abbastanza vaga... preso alla lettera qualsiasi linguaggio turing-completo va bene.
Ziosilvio
31-10-2006, 14:48
che ci puoi* fare mediamente più cose.
E perché? C, C++, Java e Python sono tutti linguaggi Turing-completi...
Dipende dalla definizione... quando un linguaggio e' potente, quando permette di generare programmi veloci ? quando riduce il tempo perso dal programmatore ? quando permette l'uso di diverse e maggiori tecniche di programmazione ?
Ecco, più o meno quello che intendevo dire.
CoreDump
31-10-2006, 15:19
Salve! Sono nuovo su questo sito e complimenti per tutto! Da anni ormai che vivo sull'informatica ma la cosa che mi manca è la programmazione! Sò i linguaggi che esistono e ho provato anche a studiarne qualcuno ma come si dice... l'informatica è ampia e la cosa migliore da fare è buttarsi su una strada e proseguire su quella! Quindi vorrei un vostro aiuto... un'aiuto da voi esperti! Ho deciso di studiare la programmazione però vorrei studiare una ma che mi servirà anche in futuro! Sento che il linguaggio più ricercato e che nn morirà è il java sia per sistemi linux e windows! Ma ho sentito ke anche il VB .net 2005 è anche richiesto solo che ovviamente è solo per sistemi windows! Vorrei un consiglio da voi quale linguaggio mi consigliate di studiare oggi come oggi? Vi ringrazio in anticipo!
Mah, secondo me non esiste un linguaggio meglio di un'altro in generale ma
esiste un linguaggio che è meglio di un altro in un determinato scopo :),
semplificando se devo scrivere un driver a basso livello magari lo faccio in C,
se devo fare un gioco di una certa complessità magari uso il C++, se volgio
fare un programma portatile su più piattaforme con interfaccia grafica magari
uso il java, se voglio fare un gestionale solo per ambiente windows magari uso
il VB o .NET che sia e via dicendo :D, io cosi a pelle ti consiglio di imparare
il java e l'approccio alla filosofia ad Oggetti, da li il passo a .NET e breve
e anche ( magari con un po più di sbattimento ) a C++, ovviamente imho ;)
C e C++ sono cross-platform... :confused: o forse indendevi dire che i programmi generati non lo sono ?
fino ad un certo punto lo sono...
quando incominci a usare primitive di sistema(posix, win32, etc) il codice non diventa piu cross plattaform, mentre in java (compilato o source) gira tranquillamente(non proprio tranquillamente se si fanno cose molto particolari...)su jvm dei diversi sistemi e SO.
E' una definizione ancora abbastanza vaga... preso alla lettera qualsiasi linguaggio turing-completo va bene. no perché la "Turing-completezza" non coinvolge la potenza in termini di interazione con la piattaforma (in Java non puoi chiamare le API Win32).
giannola
31-10-2006, 15:24
E' una definizione ancora abbastanza vaga... preso alla lettera qualsiasi linguaggio turing-completo va bene.
credo intendesse dire che il C è considerato il linguaggio di più basso livello tra i linguaggi di alto livello.
Nel senso che si può usare appena sopra l'assembly per creare sistemi operativi ecc.
In questo senso viene spiegata la maggiore potenza rispetto agli altri linguaggi concorrenti.
E perché? C, C++, Java e Python sono tutti linguaggi Turing-completi... ma il sistema operativo sottostante non è scritto ne' in Java ne' in Python; e neanche in C++ finora.
credo intendesse dire che il C è considerato il linguaggio di più basso livello tra i linguaggi di alto livello.
Nel senso che si può usare appena sopra l'assembly per creare sistemi operativi ecc.
In questo senso viene spiegata la maggiore potenza rispetto agli altri linguaggi concorrenti. ma non solo: Java per esempio non da' la possibilità di ereditare da basi multiple. che il signor Turing la mettesse come gli pare, è una cosa che in C++ posso fare e in Java no.
fdfdfdddd
31-10-2006, 15:30
E' da un po' di tempo che ritengo il l'ANSI C il linguaggio didattico di base. Lo step successivo è sicuramente un linguaggio ad oggetti. A questo punto bisogna però tenere conto di quello che vuoi fare ... t'interessi esclusivamente o quasi della piattaforma Windows? Meglio C# e .Net. Sei più orientato al web? Meglio Java. Hobbista? VB va bene così come altri linguaggi più "tranquilli".
Chiaro poi che ci stanno altre "intersezioni".
mad_hhatter
31-10-2006, 15:41
ma il sistema operativo sottostante non è scritto ne' in Java ne' in Python; e neanche in C++ finora.
ovvio, la gestione degli oggetti non serve a niente a livello di kernel e anzi appesantirebbe il tutto in modo inutile
mad_hhatter
31-10-2006, 15:45
no perché la "Turing-completezza" non coinvolge la potenza in termini di interazione con la piattaforma (in Java non puoi chiamare le API Win32).
beh, intanto dovremmo chiederci se tale interazione sia fondamentale e introduca limiti insormontabili... e qui andremmo a vedere quale scopo ciprefiggiamo, quindi nn possiamo dare valutazioni assolute... java gestisce in modo nativo meccanismi di sincronizzazione, mentre c, per esempio, si appoggia a librerie del s.o. ospite.
java è nato per essere indipendente dalla piattaforma, è ovvio che non dia la possibilità di chiamare le API di win... se ti servono le API di win vuol dire che non ti serve java e che sbaglieresti a usarlo. Ma questo non significa che java sia piu o meno potente... potente è un aggettivo tanto vago quanto relativo...
ma non solo: Java per esempio non da' la possibilità di ereditare da basi multiple. che il signor Turing la mettesse come gli pare, è una cosa che in C++ posso fare e in Java no.
in c++ non puoi dichiarare un blocco threadsafe(aka syncronized) o dire che una variabile sia leggibile e scrivibile dai + thread in maniera sicura(aka volatile)
ps.in c++ si puo fare multithreading, come in java si puo aggirare la mancanza dell'ereditarieta multipla(ereditarieta multipla di interfaccie, delegation, etc)
solo che i linguaggi ti mettono a disposizione dei meccanismi per scrivere + o - meglio queste cose(un po come i generics/template, o un for each)
ovvio, la gestione degli oggetti non serve a niente a livello di kernel tant'è vero che il kernel NT è scritto in un'ottica OOP, coi relativi vantaggi.
e anzi appesantirebbe il tutto in modo inutile perché?
repne scasb
01-11-2006, 10:20
Il linguaggio di oggi e del futuro?
Non conosco il linguaggio del presente ma essendomi nota la fantasia di un creatore medio di linguaggi di programmazione, direi che per il futuro mi aspetto un linguaggio di programmazione del tipo:
D**
E$
Kava
Anaconda
PPHHPP
mad_hhatter
01-11-2006, 10:27
tant'è vero che il kernel NT è scritto in un'ottica OOP, coi relativi vantaggi.
perché?
beh, che sia scritto in ottica OOP non significa che sia scritto con un linguaggio a oggetti... e' scritto in C o in C++?
anche il C puo' emulare con le struct il concetto di oggetto, ma non e' la stessa cosa!
per il discorso che si appesantisce... mah guarda, francamente non ho test sotto mano ma cosi' mi era stato detto. Probabilmente la gestione degli oggetti implica un overhead superiore e poi sicuramente hai un costo in termini di occupazione di memoria maggiore... ma potrei sbagliarmi, se hai info in merito mi piacerebbe discuterne.
LupettoOne
01-11-2006, 12:04
Ragazzi vi ringrazio per avermi dato tantissime risposte! Ovviamente come hanno detto tanti... dipende da quello ke vorrei fare! Bhè io vorrei creare programmi che devono avere una veste grafica! Sia installer che standalone mi va bene entrambi ma la cosa che non ho mai capito l'installer è sempre megliore dello standalone come esecuzione o viceversa?
Vorrei imparare un linguaggio che oggi si usa e che è ricercato nel mondo del lavoro! Da come ho capito ogni linguaggio ha un suo modo di programmazione che a seconda del programmatore cosa vuole fare! Sicuramente mi mettere la scelta tra il java e il .net! Vi ringrazio di nuovo!
jappilas
01-11-2006, 12:47
ovvio, la gestione degli oggetti non serve a niente a livello di kernel e anzi appesantirebbe il tutto in modo inutile
che io sappia, non è "la gestione degli oggetti" in senso lato che appesantirebbe il kernel , sarebbero eventualmente costrutti complessi di certo linguaggio con supporto OO ( vedi: templates, RTTI, eredità multipla...), ma questo si applicherebbe a programmi di qualunque tipo, e per il kernel nella fattispecie si tratta di costrutti di cui non si ha bisogno
comunque a livello di kernel gli oggetti servono eccome, pensa solo alla gerarchia delle risorse (file system locali e remoti), la gestione dei device
beh, che sia scritto in ottica OOP non significa che sia scritto con un linguaggio a oggetti... e' scritto in C o in C++?
anche il C puo' emulare con le struct il concetto di oggetto, ma non e' la stessa cosa!
per il discorso che si appesantisce... mah guarda, francamente non ho test sotto mano ma cosi' mi era stato detto. Probabilmente la gestione degli oggetti implica un overhead superiore e poi sicuramente hai un costo in termini di occupazione di memoria maggiore... ma potrei sbagliarmi, se hai info in merito mi piacerebbe discuterne.
http://www.caravan.net/ec2plus/rationale.html
Il System Expert (che gestisce la topologia dei device nel sistema e la loro mappatura a inode) di Mac Os X è scritto in questo linguaggio ;)
anonimizzato
01-11-2006, 12:49
Non conosco il linguaggio del presente ma essendomi nota la fantasia di un creatore medio di linguaggi di programmazione, direi che per il futuro mi aspetto un linguaggio di programmazione del tipo:
D**
E$
Kava
Anaconda
PPHHPP
LOL :D
Non conosco il linguaggio del presente ma essendomi nota la fantasia di un creatore medio di linguaggi di programmazione, direi che per il futuro mi aspetto un linguaggio di programmazione del tipo: guarda che i nomi vanno si a fantasia ma mica sono scelti a casaccio :Prrr:
e poi secondo me ormai l'era delle note musicali è finita :D
mad_hhatter
01-11-2006, 15:18
comunque a livello di kernel gli oggetti servono eccome, pensa solo alla gerarchia delle risorse (file system locali e remoti), la gestione dei device
ok, ma che io sappia il kernel linux è scritto in C, non in c++... o sbaglio?
purtroppo oggi non ho tempo, ma mi piacerebbe documentarmi su questi aspetti...
c'è anche da dire che come linguaggio OO ho in mente java, mentre non posso dire di conoscere C++... forse questo mi crea dei preconcetti errati... se hai altro materiale mi piacerebbe avere maggiori info, grazie
beh, che sia scritto in ottica OOP non significa che sia scritto con un linguaggio a oggetti... e' scritto in C o in C++? in C, ma solo per retrocompatibilità: la mancanza degli oggetti si sente (penso che se fosse stato scritto veramente in C++ sarebbe stato più veloce).
anche il C puo' emulare con le struct il concetto di oggetto, ma non e' la stessa cosa! infatti vedi sopra: in C++ sarebbe probabilmente ancora meglio.
per il discorso che si appesantisce... mah guarda, francamente non ho test sotto mano ma cosi' mi era stato detto. infatti anche questa è una credenza tanto diffusa quanto falsa. il buon vecchio fek su Diamond Crush ci ha messo poco a smontarla col suo classico esempio della GetType.
Probabilmente la gestione degli oggetti implica un overhead superiore e poi sicuramente hai un costo in termini di occupazione di memoria maggiore... ma non mi risulta proprio... secondo te perché un programma a oggetti dovrebbe occupare più memoria ed essere più lento di un programma scritto in paradigma procedurale?
mad_hhatter
01-11-2006, 15:41
infatti anche questa è una credenza tanto diffusa quanto falsa. il buon vecchio fek su Diamond Crush ci ha messo poco a smontarla col suo classico esempio della GetType.
ma non mi risulta proprio... secondo te perché un programma a oggetti dovrebbe occupare più memoria ed essere più lento di un programma scritto in paradigma procedurale?
hai qualche link sul "buon vecchio fek"? purtroppo non so di cosa parli :help:
mah guarda, come ho scritto in un altro post, probabilmente ho troppo in mente java con RTTI e RTTR... secondo me questi meccanismi portano più occupazione di memoria e più overhead... ma ti ripeto, forse sono solo miei preconcetti. se hai documentazione in merito fammi la cortesia di segnalarmela perchè vorrei levarmi di dosso questi falsi miti, se tali sono
hai qualche link sul "buon vecchio fek"? purtroppo non so di cosa parli :help: 1) mi pesa il mouse ad andare a ritrovare i post nei meandri del forum :Prrr:
2) non voglio suggerire :Prrr:
3) :Prrr:
comunque fek è (era) un utente di questo forum che ultimamente però è un po' sparito ^^
mah guarda, come ho scritto in un altro post, probabilmente ho troppo in mente java con RTTI e RTTR... secondo me questi meccanismi portano più occupazione di memoria e più overhead... ma come fai a farti questa opinione se manco sai come sono implementati... :asd:
oppure lo sai? :rolleyes:
ma ti ripeto, forse sono solo miei preconcetti. se hai documentazione in merito fammi la cortesia di segnalarmela perchè vorrei levarmi di dosso questi falsi miti, se tali sono non ci vuole niente a levarteli di dosso: devi semplicemente metterti in testa che non devi dare per buono quello che ti dicono finché non te lo dimostrano. nel caso specifico probabilmente avrebbero avuto difficoltà a dimostrarti che la programmazione a oggetti di per se' è "pesante", e in tal modo tu stesso (da ignorante sull'argomento) avresti anche ottenuto di aver fatto qualcosa di utile alla causa comune smontando i loro falsi miti. il tutto senza praticamente muovere un dito e senza argomentare nulla: gli hai solo fatto notare che non sono in grado di dimostrarli. fico no? :)
ah, comunque ad onor del vero per quanto riguarda l'RTTI aggiungo che neanche a fek è mai piaciuta: ricordo che ci ha espressamente vietato di usarla su DC e concordo pienamente perché la necessità di dover ritrovare il tipo di oggetto in un momento diverso dalla sua creazione è indice di un probabile cattivo design.
giannola
01-11-2006, 16:01
Ragazzi vi ringrazio per avermi dato tantissime risposte! Ovviamente come hanno detto tanti... dipende da quello ke vorrei fare! Bhè io vorrei creare programmi che devono avere una veste grafica! Sia installer che standalone mi va bene entrambi ma la cosa che non ho mai capito l'installer è sempre megliore dello standalone come esecuzione o viceversa?
Vorrei imparare un linguaggio che oggi si usa e che è ricercato nel mondo del lavoro! Da come ho capito ogni linguaggio ha un suo modo di programmazione che a seconda del programmatore cosa vuole fare! Sicuramente mi mettere la scelta tra il java e il .net! Vi ringrazio di nuovo!
precisando che .net non è un linguaggio ma un'architettura di programmazione.
Nel .net si può progammare in tre diversi linguaggi VB (che è l'erede del visual basic), C#(che è un linguaggio c con sintassi specifica di Microsoft), C++ e J# (java specifico microsoft).
Quindi non hai che l'imbarazzo della scelta per lavorare in .net, addirittura ti puoi divertire a fare pezzi di programma usando linguaggi diversi.
Visto che sei principiante ti consiglio il VB, perchè molto semplice ed intuitivo, anche per capire "come funziona" la programmazione.
Dopo, se lo desideri, potrai passare al c++ o a qualunque altro linguaggio più complesso nelle logiche di programmazione. ;)
P.S. ciò non significa che con il VB.net tu non possa possa fare le stesse cose degli altri linguaggi.
Visto che sei principiante ti consiglio il VB, perchè molto semplice ed intuitivo, anche per capire "come funziona" la programmazione. qui però è meglio specificare che stai consigliando la versione 2005 di Visual Basic, non la 6! ;)
giannola
01-11-2006, 16:04
qui però è meglio specificare che stai consigliando la versione 2005 di Visual Basic, non la 6! ;)
ovvio. :D
esistono le versioni express che sono gratuite oppure al limite chi vuole una edizione completa si può comprare a pochi euro quella education. ;)
mad_hhatter
01-11-2006, 16:10
1) mi pesa il mouse ad andare a ritrovare i post nei meandri del forum :Prrr:
2) non voglio suggerire :Prrr:
3) :Prrr:
comunque fek è (era) un utente di questo forum che ultimamente però è un po' sparito ^^
ma come fai a farti questa opinione se manco sai come sono implementati... :asd:
oppure lo sai? :rolleyes:
non ci vuole niente a levarteli di dosso: devi semplicemente metterti in testa che non devi dare per buono quello che ti dicono finché non te lo dimostrano. nel caso specifico probabilmente avrebbero avuto difficoltà a dimostrarti che la programmazione a oggetti di per se' è "pesante", e in tal modo tu stesso (da ignorante sull'argomento) avresti anche ottenuto di aver fatto qualcosa di utile alla causa comune smontando i loro falsi miti. il tutto senza praticamente muovere un dito e senza argomentare nulla: gli hai solo fatto notare che non sono in grado di dimostrarli. fico no? :)
posto che non ho capito dove vuoi essere ironico e dove (eventualmente) scortese, vorrei mettere in pratica subito il tuo consiglio facendoti notare (senza alcuna intenzione di essere sgarbato) che neanche dalle tue parole posso estrapolare una qualche dimostrazione del fatto che i miei falsi miti siano tali... ripeto, non prendere le mie parole come una sfida o come uno sgarbo. la mia è solo voglia di sapere
beppegrillo
01-11-2006, 16:50
ok, ma che io sappia il kernel linux è scritto in C, non in c++... o sbaglio?
purtroppo oggi non ho tempo, ma mi piacerebbe documentarmi su questi aspetti...
c'è anche da dire che come linguaggio OO ho in mente java, mentre non posso dire di conoscere C++... forse questo mi crea dei preconcetti errati... se hai altro materiale mi piacerebbe avere maggiori info, grazie
è stato scritto in c - asm, con ottica orientata agli oggetti.
jappilas
01-11-2006, 17:34
non ci vuole niente a levarteli di dosso: devi semplicemente metterti in testa che non devi dare per buono quello che ti dicono finché non te lo dimostrano. nel caso specifico probabilmente avrebbero avuto difficoltà a dimostrarti che la programmazione a oggetti di per se' è "pesante", e in tal modo tu stesso (da ignorante sull'argomento) avresti anche ottenuto di aver fatto qualcosa di utile alla causa comune smontando i loro falsi miti. il tutto senza praticamente muovere un dito e senza argomentare nulla: gli hai solo fatto notare che non sono in grado di dimostrarli. fico no? :)quello che sospetto è che gli abbiano fatto apparire immane l' overhead della tabella delle funzioni virtualizzate, o gli abbiano detto che le sezioni di codice contenute in una classe vengano replicate in memoria ad ogni istanziazione di un oggetto di quella classe :rolleyes:
siccome stava venendo anche a me il dubbio sulla portata reale dell' overhead eventuale, ho fatto un po' di ricerche... e quello che emerge è che il C++ sia "semplicemente" C con delle estensioni che,
se non usate non comportano nulla a meno che il compilatore non sia davvero scadente
se usate aggiungono in termini di costo computazionale, praticamente quello che uno dovrebbe (per risolvere lo stesso tipo di problema) aggiungere ugualmente, solo con strumenti meno espressivi (quindi maggiore sofferenza e minore leggibilità del codice finale)
alcune pagine uscite da google cercando "c++ overhead"
http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance.htm
http://unthought.net/c++/c_vs_c++.html
http://www.tantalon.com/pete/cppopt/final.htm
http://www.cantrip.org/emptyopt.html
http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance.htm
ok, ma che io sappia il kernel linux è scritto in C, non in c++... o sbaglio?Linux no, è stato scritto in C per le parti platform independent, con porzioni direttamente in linguaggio macchina (x86 quando nacque) per le parti critiche come scheduling e gestione della memoria
ma non fare lo ( IMHO) sbaglio di ritenere che se Linux non fa qualcosa, allora quel qualcosa non serva o sia errato farla...
Tieni conto che (a parte il fatto che vari fattori abbiano affibbiato a Linux l' etichetta di "nato vecchio" fin dall' inizio, e ciononostante tutti possono vedere che ha seppellito altri sistemi che apparivano più promettenti) quando il finnico lo scrisse, lo scopo era avere a disposizione un OS gratuito su cui far girare il codice che circolava in ambito accademico
Quindi gli serviva un clone Unix, e unix è sempre andato a braccetto con C...
Inoltre in questo modo ( vale per Linux, ma anche per i vari altri sistemi operativi open source di larga diffusione, che non è un caso siano tutti discendenti UNIX) ci si è potuto avvalere di una base di utenti - "hacker" ( quindi "koders" :D e patch contributors ) potenzialmente la più ampia possibile: questo dal momento che, soprattutto una volta, era facile il C fosse il linguaggio su cui la gente si fosse formata, a maggior ragione tra chi al college, su unix si era fatto le ossa
LupettoOne
01-11-2006, 17:35
Allora da come ho capito mi consigliate il pacchetto Visual Studio 2005! Ma il sql server 2005 è incluso nel pacchetto? Perchè facendo delle ricerche ho letto che il sql è il database per il VB 2005! E poi un'altra cosa ho letto anche che c'è bisogno del MSDN Library!
posto che non ho capito dove vuoi essere ironico e dove (eventualmente) scortese, vorrei mettere in pratica subito il tuo consiglio facendoti notare (senza alcuna intenzione di essere sgarbato) che neanche dalle tue parole posso estrapolare una qualche dimostrazione del fatto che i miei falsi miti siano tali... finché qualcuno non dimostra qualcosa qui non si afferma nulla. nessuno ha mai affermato che la programmazione a oggetti è pesante di per se'. qualcuno lo afferma: che lo dimostri.
tu mi metti in bocca che questa affermazione non dimostrata (e probabilmente non dimostrabile) sia falsa; io non dico che è falsa (altrimenti a dimostrarne la falsità dovrei essere io, e vorrei proprio vedere come dovrei fare a smontare qualcosa di non dimostrato), io dico che è difficilmente dimostrabile. vogliamo vedere? :asd:
su forza, chiama qui quelli che ti hanno detto ste cose e vediamo di cosa sono capaci :asd:
quello che sospetto è che gli abbiano fatto apparire immane l' overhead della tabella delle funzioni virtualizzate, overhead che spesso e volentieri nel paradigma procedurale si traduce nelle catene di if, quindi comunque non lo perdi; però se usi le funzioni virtuali al posto delle catene di if (ricorda sempre l'esempio della GetType) hai due notevolissimi vantaggi:
1) design pulito e semplice, codice "leggero" nel senso di facile lettura
2) non sputtani la branch prediction della CPU, perché un JMP è diverso da un Jcc ;)
o gli abbiano detto che le sezioni di codice contenute in una classe vengano replicate in memoria ad ogni istanziazione di un oggetto di quella classe HUWHAUWAHUWHAUWAHU MA LOL :rotfl: :D
ma non fare lo ( IMHO) sbaglio di ritenere che se Linux non fa qualcosa, allora quel qualcosa non serva o sia errato farla... quoto: Linux poi, ben lungi dall'essere un vangelo di programmazione... :asd:
jappilas
01-11-2006, 18:05
(ricorda sempre l'esempio della GetType) Quello andrebbe quasi messo come sticky post :D
2) non sputtani la branch prediction della CPU, perché un JMP è diverso da un Jcc ;)questo non me lo ricordavo :)
:rotfl: :Din realtà è ciò che ci disse la docente (7 anni fa) quando iniziò con le classi , non so che linguaggio o compilatore avesse in mente però... :mc: :rolleyes:
giannola
01-11-2006, 18:40
Allora da come ho capito mi consigliate il pacchetto Visual Studio 2005! Ma il sql server 2005 è incluso nel pacchetto? Perchè facendo delle ricerche ho letto che il sql è il database per il VB 2005! E poi un'altra cosa ho letto anche che c'è bisogno del MSDN Library!
dunque è altrettanto disponibile gratuitamente la versione di sql servo 2005 in versione express.
con vb puoi usare qualunque db, allo stesso modo puoi usare sql server con qualunque linguaggio è sufficiente avere dei drivers di collegamento al db prescelto.
Se vuoi avere le funzionalità msdn, senza avere msdn :
http://msdn2.microsoft.com
secondo te perché un programma a oggetti dovrebbe occupare più memoria ed essere più lento di un programma scritto in paradigma procedurale?
Non so se sia più lento o richieda più memoria ma certamente il compilatore deve produrre più istruzioni perchè l'invocazione di un metodo ne richiede più o meno cinque:
un branch per controllare che il puntatore sia valido
un load per caricare il puntatore alla tabella dei metodi
un load per caricare il metodo
uno store per l'indirizzo di ritorno
un salto per invocare il metodo
mentre per l'invocazione di una funzione bastano lo store e il jump.
LupettoOne
01-11-2006, 19:58
dunque è altrettanto disponibile gratuitamente la versione di sql servo 2005 in versione express.
con vb puoi usare qualunque db, allo stesso modo puoi usare sql server con qualunque linguaggio è sufficiente avere dei drivers di collegamento al db prescelto.
Se vuoi avere le funzionalità msdn, senza avere msdn :
http://msdn2.microsoft.com
Grazie mille giannola! Quindi potrei utilizzare anche l'access come db! Io pensavo che si doveva usare per forza il SQL server 2005! Grazie di nuovo!
questo non me lo ricordavo :) e diamine, era proprio quello il punto dell'esempio della GetType!!! :D
perché è meglio sostituire gli if con le funzioni virtuali? perché gli if, al contrario delle funzioni virtuali, non sfruttano la branch prediction! ;)
la CPU fa il prefetch delle prossime N istruzioni; ora mettiamo che vede un JMP incondizionato: che fa? è logico, continua il prefetch a partire dal target di quel JMP, piuttosto che dall'istruzione successiva al JMP. ora mettiamo invece che vede un Jcc: che fa? boh, la CPU non può mica sapere come andrà a finire la valutazione della condizione che determina o meno il salto. un sofisticato branch predictor potrebbe continuare il prefetch sia da una parte che dall'altra (sia da subito dopo il Jcc che dall'eventuale target del salto), ma chiaramente basta poco per superare anche questo meccanismo: un po' di salti condizionati a raffica (catena di if) e là che la CPU non può più prefetchare un bel nulla. :p
in realtà è ciò che disse la docente LA docente? :D
tutto chiaro :asd:
un branch per controllare che il puntatore sia valido no, in C++ è anche possibile che un metodo si ritrovi chiamato con this == NULL (MFC asserisce spesso su ciò).
un load per caricare il puntatore alla tabella dei metodi no, qualsiasi CISC decente può branchare tanto ad un indirizzo contenuto in un registro, quanto ad un indirizzo contenuto in una cella di memoria.
un load per caricare il metodo chee...? :huh:
che stai a di', il metodo è già caricato nella sezione .text dell'eseguibile... :huh:
mad_hhatter
01-11-2006, 20:09
ma no, non è che penso che ci sia un abisso prestazionale... è solo che avendo in mente più java che c++ (ripeto che c++ non lo conosco, ecco quindi forse la ragione dei miei errori), penso a tutti i controlli di sicurezza che fa java (tipo il controllo sull'array index out of bound, per capirci) e magari tend erroneamente a estendere questo fatto in modo irragionevole... cmq so benissimo che il codice di una di una classe non viene replicato, non è questo!
e poi ho solo chiesto info, non pensavo che chiedere e confessare le proprie lacune fosse visto come indice di pazzia...
ho visto ora il post di PGI-bis... beh, quindi non sono poi tanto pazzo quando parlo di overhead... sarà anche piccolo, ma un po' c'è... e io volevo solo chiedere se c'era o meno. grazie per l'info PGI-bis
tengo poi a precisare che parlo di linux perchè certe cose le so in ambito linux e non in ambito win. tutto lì... ripeto, stavo solo chiedendo e portando esempi
@71104
continuo a non capire la ragione della tua ironia... non so se ti piace sbeffeggiare chi ne sa meno di te o se sono io che fraintendo il tuo tono...
inoltre, se per tua stessa ammissione stiamo parlando di qualcosa di probabilmente indimostrabile, significa che è indimostrabile sia la pretesa che cio' che dicevo sia vero, sia la pretesa che sia falso e quindi non riesco davvero a capire perchè il tuo tono sottintende che affermare che sia più lento sia una idiozia... il fatto che tu non possa dimostrarmi nè che sia falso nè che sia vero mi porta a chiederti di essere meno ironico. prima affermi che la OOP non sia più pesante della prog. strutturata, poi affermi che ciò è difficilmente dimostrabile... io rilevo una contraddizione... tu no? con tutto il rispetto, ovviamente: non voglio polemizzare, spero sia chiaro
jappilas
01-11-2006, 20:31
e diamine, era proprio quello il punto dell'esempio della GetType!!! :D
perché è meglio sostituire gli if con le funzioni virtuali? perché gli if, al contrario delle funzioni virtuali, non sfruttano la branch prediction! ;)
eh, ti avevo detto come funziona il mio cervello.. :D
molto probabilmente ci sarei arrivato per ragionamento, ma nn ricordavo le esatte parole del discorso di fek, grazie del refresh :)
LA docente? :D tutto chiaro :asd:vorrei puntualizzare che non lo prendevo per vero a mia volta :O
tra l'altro, prima di quello aveva già detto altre cose che non mi tornavano, quindi mi ero già assuefatto a verificare sistematicamente (e quasi altrettanto sistematicamente, scremare) il contenuto originale delle sue lezioni :O
no, in C++ è anche possibile che un metodo si ritrovi chiamato con this == NULL (MFC asserisce spesso su ciò).
In Java, Smalltalk, Ruby e Python no.
no, qualsiasi CISC decente può branchare tanto ad un indirizzo contenuto in un registro, quanto ad un indirizzo contenuto in una cella di memoria.
E costa uguale? Un memory-indirect jump "pesa" quanto un register-indirect jump? Non è una domanda retorica, lo chiedo davvero. Lo chiedo perchè io ho letto che i register-indirect jump sono sempre più convenienti ma è un'affermazione che mi lascia perplesso.
chee...? :huh:
che stai a di', il metodo è già caricato nella sezione .text dell'eseguibile... :huh:
Se invoco il metodo m() su un riferimento di tipo A il compilatore non può determinare quale sia il metodo effettivamente invocato. Il riferimento potrebbe assumere un valore di tipo B, compatibile in assegnamento con A, e definire un proprio metodo m(). A me pare inevitabile che debba determinare al volo l'indirizzo in cui si trova il metodo e che non possa farlo se non passando per la tabella che contiene gli indirizzi dei metodi, tabella che a sua volta si trova ad un indirizzo determinabile solo a partire dal valore a cui si riferisce questo puntatore.
Si fa con un'istruzione sola? Se sì son felicissimo: io penso che nessun essere umano dovrebbe mettere mano a C (e che nessuno sano di mente dovrebbe avvicinarsi a C++).
Ad ogni modo, quanto ho detto non è che me lo sia inventato per sfizio. Si può trovare in Computer Organization And Design, Hennessy-Patterson (è uno dei capitoli nel CD, che non legge mai nessuno).
Alla fine credo che Java sia attualmente il linguaggio piu usato per quanto riguarda gli applicativi "terrestri"/desktop come volete chiamarli (e non certo perchè è cross-platform.. voglio dire dati alla mano purtroppo almeno il 90 % e forse piu usa sistemi operativi di zio bill e quindi il successo di java non è dovuto soltanto al fatto che puoi fare girare i programmi che scrivi ovunque).
Per il web Php è di gran lunga il più usato per le soluzioni piccole-medie e un pò meno per quelle grandi (anche se poi la programmazione diventa molto object oriented e molto java-like) dove ci sono ottime alternative come JSP e Python (di cui tutti parlano parlano ma poi dati alla mano si vede come nel sondaggio su questo forum che pochi effettivamente lo usano)
Poi c'è il C che un linguaggio che difficilmente morirà ed in fondo se hai le basi di C hai le basi fondamentali per poter affrontare qualsiasi linguaggio.
Il futuro ? chissà. L'importante per i linguaggi è la base di programmatori. Php, Java e C hanno una fortissima ed attivissima base di programmatori entusiasti che farebbero qualsiasi cosa nel proprio linguaggio preferito (anche le cose per cui non è adatto). Python, Ruby, Perl e via dicendo sono tutti linguaggi che hanno pro e contro ma hanno una community piu piccola (anche se mediamente piu preparata). Un fattore determinante per il futuro a mio parere sarà il peso della community.
Non sempre vince il prodotto migliore, vince il prodotto che ha piu successo... è il successo in questo campo è il numero di utenti che vi lavorano, che lo testano, che apportano modifiche e miglioramenti e che sono pronti a darti una mano
(e non certo perchè è cross-platform.. voglio dire dati alla mano purtroppo almeno il 90 % e forse piu usa sistemi operativi di zio bill e quindi il successo di java non è dovuto soltanto al fatto che puoi fare girare i programmi che scrivi ovunque).
in molte realta invece è comodo.
pensa a un applicazione web java, io programmo su windows con wsad(eclipse), ma poi l'applicazione in produzione gira....BOH, non sono manco sicuro su che OS giri in produzione :asd: (l'unica cosa di cui sono sicuro e che non sono win )
giannola
02-11-2006, 08:17
Alla fine credo che Java sia attualmente il linguaggio piu usato per quanto riguarda gli applicativi "terrestri"/desktop come volete chiamarli (e non certo perchè è cross-platform.. voglio dire dati alla mano purtroppo almeno il 90 % e forse piu usa sistemi operativi di zio bill e quindi il successo di java non è dovuto soltanto al fatto che puoi fare girare i programmi che scrivi ovunque).
semplicemente perchè fin'ora è stato quello gratuito
Per il web Php è di gran lunga il più usato per le soluzioni piccole-medie e un pò meno per quelle grandi (anche se poi la programmazione diventa molto object oriented e molto java-like) dove ci sono ottime alternative come JSP e Python (di cui tutti parlano parlano ma poi dati alla mano si vede come nel sondaggio su questo forum che pochi effettivamente lo usano)
idem come sopra con l'aggiunta del mysql altrettanto gratuito.
Ma adesso anche la microsoft sta fornendo programmi gratuiti (ver.express)
Poi c'è il C che un linguaggio che difficilmente morirà ed in fondo se hai le basi di C hai le basi fondamentali per poter affrontare qualsiasi linguaggio.
C e C++ moriranno e verranno sostituiti da un C indirizzato alla programmazione ad aspetti, questione di tempo.
Il futuro ? chissà. L'importante per i linguaggi è la base di programmatori. Php, Java e C hanno una fortissima ed attivissima base di programmatori entusiasti che farebbero qualsiasi cosa nel proprio linguaggio preferito (anche le cose per cui non è adatto). Python, Ruby, Perl e via dicendo sono tutti linguaggi che hanno pro e contro ma hanno una community piu piccola (anche se mediamente piu preparata). Un fattore determinante per il futuro a mio parere sarà il peso della community.
Il futuro secondo me almeno per quanto riguarda le applicazioni standalone e internet è la piattaforma .net, non a caso hanno cercato di elaborare dei framework che rendano possibile programmare .net anche su linux.
Le potenzialità sono enormi come anche creare videogiochi o applicativi interlinguaggi.
Non sempre vince il prodotto migliore, vince il prodotto che ha piu successo... è il successo in questo campo è il numero di utenti che vi lavorano, che lo testano, che apportano modifiche e miglioramenti e che sono pronti a darti una mano
Vince il prodotto più eclettico, java era più eclettico del visual basic, ma la piattaforma .net (adottando quattro linguaggi diversi e una miriade di oggetti) è ancora più eclettica di java, oltretutto ha una spiccata tendenza all'uso di proprietà e attributi degli oggetti.
Vedremo come risponderà sun.
in molte realta invece è comodo.
pensa a un applicazione web java, io programmo su windows con wsad(eclipse), ma poi l'applicazione in produzione gira....BOH, non sono manco sicuro su che OS giri in produzione :asd: (l'unica cosa di cui sono sicuro e che non sono win )
beh certo che è comodo... infatti io dicevo per gli applicativi terrestri/desktop non per quelli web :p
Ovviamente ci mancherebbe altro questo è uno dei motivi ma secondo me non è il motivo principale del successo di Java.
In effetti Giannola diceva che sono programmi che hanno avuto ampia diffusione e successo grazie alla loro gratuità. Ha perfettamente ragione.
C e C++ diventeranno un C+++ o quello che si inventeranno ma di fatto non moriranno si evolveranno.
.NET è una buona piattaforma ma tu stesso hai detto che il successo dei linguaggi piu utilizzati è dovuto al fatto che siano Free... .NET non è free e questo ne può limitare lo sviluppo e il successo... probabilmente se fosse stato free già ora..
Inoltre non credo che attualmente .NET sia conveniente in termini economici per i progetti medio piccoli (che sono l'80 % del mercato) e stiamo discutendo dell'eventualità di un porting su linux (attualmente i server web sono quasi tutti linux) che ancora non c'è e che probabilmente non sarà performante come il prodotto su win e questo può essere una grossa limitazione imho.
BountyKiller
02-11-2006, 14:48
il linguaggio del momento? difficile dirlo, forse C++;
il linguaggio del futuro? nella sfera di cristallo vedo C++ :)
In Java, Smalltalk, Ruby e Python no. non è colpa della OOP di per se', visto che come vedi esistono implementazioni più efficienti (C++).
E costa uguale? Un memory-indirect jump "pesa" quanto un register-indirect jump? Non è una domanda retorica, lo chiedo davvero. Lo chiedo perchè io ho letto che i register-indirect jump sono sempre più convenienti ma è un'affermazione che mi lascia perplesso. è chiaro che l'accesso a un registro è necessariamente più veloce di un accesso in memoria (anche solo perché un accesso in memoria, cache miss o hit che sia, deve comunque passare a sua volta per un paio di registri interni non accessibili da assembly, ovvero il MAR e quell'altro che non ricordo il nome).
ma in realtà non è che le cose migliorino traducendo in paradigma procedurale; mettiamola così: la OOP (perlomeno per come è implementata in C++) non introduce nessun overhead se non qualche ciclo di clock dovuto ad un sistema di puntatori a funzioni, le funzioni virtuali. ora se tu questo sistema lo vuoi usare e ne hai bisogno lo usi, sennò evita di fare metodi virtuali e non avrai nessun overhead.
quand'è che è conveniente usare le funzioni virtuali? tutte le volte che hai la possibilità di sostituire un branch condizionato con uno incondizionato. canonico l'esempio della GetType, che adesso ti espongo per intero. prendi queste righe di C:
typedef unsigned int OBJECT_TYPE, *POBJECT_TYPE;
#define OBJTYPE1 ((OBJECT_TYPE)0x00)
#define OBJTYPE2 ((OBJECT_TYPE)0x01)
#define ...
typedef struct _CLASS {
OBJECT_TYPE Type;
int Field1;
int Field2;
.
.
.
} CLASS, *PCLASS;
void IfChainedFunction(PCLASS Object) {
if (OBJTYPE1 == Object->Type) {
Do1();
}
else if (OBJTYPE2 == Object->Type) {
Do2();
}
.
.
.
else {
/* invalid object type error management */
}
}
ora prendi la corrispondente versione C++:
class Class
{
public:
int Field1;
int Field2;
.
.
.
virtual void Do() = 0;
};
class Class1 : public Class
{
public:
virtual void Do(); /* this is the old Do1 */
};
class Class2 : public Class
{
public:
virtual void Do(); /* this is the old Do2 */
};
void IfChainedNotAnymoreFunction(Class *Object) {
Object->Do(); /* and... "look mummy, no if!" [cit. :D] */
}
ora li vedi i vantaggi in termini sia di design che di performance?
Se invoco il metodo m() su un riferimento di tipo A il compilatore non può determinare quale sia il metodo effettivamente invocato. Il riferimento potrebbe assumere un valore di tipo B, compatibile in assegnamento con A, e definire un proprio metodo m(). A me pare inevitabile che debba determinare al volo l'indirizzo in cui si trova il metodo quando hai detto "un load per caricare il metodo" avevo capito caricare il codice del metodo... :p
e che non possa farlo se non passando per la tabella che contiene gli indirizzi dei metodi, tabella che a sua volta si trova ad un indirizzo determinabile solo a partire dal valore a cui si riferisce questo puntatore. l'indirizzo della tabella delle funzioni virtuali comunque lo sai già: è quello dell'oggetto più una costante nota in compile-time. ok ok, devi spendere un ciclo in più per addizionare la costante a this... :asd:
ma alla conclusione di tutto ricorda che se anche dovessi trovare qualche ciclo di clock in più rispetto al modello procedurale, sostituire le catene di if con un sistema di puntatori a funzioni (come quello delle funzioni virtuali, implementato dal compilatore) ti da' l'inestimabile vantaggio di poter sfruttare al massimo il branch predictor.
(e che nessuno sano di mente dovrebbe avvicinarsi a C++). eppure lo fanno in molti, e si dice che quando ti ritrovi a dire che tutto il resto del mondo è pazzo sia giunta l'ora di chiedersi se non sei pazzo tu. ;)
tomminno
02-11-2006, 22:25
finché qualcuno non dimostra qualcosa qui non si afferma nulla. nessuno ha mai affermato che la programmazione a oggetti è pesante di per se'. qualcuno lo afferma: che lo dimostri.
Dimostrazioni tipo teorema non saprei dartele, ma lavoro in una ditta dove si lavora molto con microcontrollori e DSP, in quel settore esiste uno e un solo linguaggio: il C (con l'assembly per le parti critiche).
Dove lavoro collaboriamo con una ditta dove ci sono persone che contribuiscono allo sviluppo di gcc (quindi immagino che ci capiscano ben più di qualcosa) e anche loro non si pongono nemmeno il problema se scegliere C o C++ per quel tipo di progetti.
tu mi metti in bocca che questa affermazione non dimostrata (e probabilmente non dimostrabile) sia falsa; io non dico che è falsa (altrimenti a dimostrarne la falsità dovrei essere io, e vorrei proprio vedere come dovrei fare a smontare qualcosa di non dimostrato), io dico che è difficilmente dimostrabile. vogliamo vedere? :asd:
su forza, chiama qui quelli che ti hanno detto ste cose e vediamo di cosa sono capaci :asd:
Forse pensi di avere sempre a disposizione una CPU superscalare, ma al mondo non esistono solo CPU che si misurano in GigaHertz e Giga di Ram. Esiste una gran parte dei sistemi dove hai 32KB non hai un OS che ti fa le cose e ti devi gestire a mano gli interrupt della CPU e non sono sistemi così rari. Praticamente qualunque oggetto elettronico ha al suo interno oggetti simili e se ci pensi sono forse più numerosi dei PC.
tomminno
02-11-2006, 22:44
quand'è che è conveniente usare le funzioni virtuali? tutte le volte che hai la possibilità di sostituire un branch condizionato con uno incondizionato. canonico l'esempio della GetType, che adesso ti espongo per intero. prendi queste righe di C:
typedef unsigned int OBJECT_TYPE, *POBJECT_TYPE;
#define OBJTYPE1 ((OBJECT_TYPE)0x00)
#define OBJTYPE2 ((OBJECT_TYPE)0x01)
#define ...
typedef struct _CLASS {
OBJECT_TYPE Type;
int Field1;
int Field2;
.
.
.
} CLASS, *PCLASS;
void IfChainedFunction(PCLASS Object) {
if (OBJTYPE1 == Object->Type) {
Do1();
}
else if (OBJTYPE2 == Object->Type) {
Do2();
}
.
.
.
else {
/* invalid object type error management */
}
}
ora prendi la corrispondente versione C++:
class Class
{
public:
int Field1;
int Field2;
.
.
.
virtual void Do() = 0;
};
class Class1 : public Class
{
public:
virtual void Do(); /* this is the old Do1 */
};
class Class2 : public Class
{
public:
virtual void Do(); /* this is the old Do2 */
};
void IfChainedNotAnymoreFunction(Class *Object) {
Object->Do(); /* and... "look mummy, no if!" [cit. :D] */
}
ora li vedi i vantaggi in termini sia di design che di performance?
Se ne era già discusso, ma questa soluzione mi sembra porti a poco: nel 99% dei casi non conosco il contenuto di PCLASS Object devo quindi farlo passare attraverso una sequenza di if o switch che sia, non posso chiamare il metodo Do() della classe appropriata perchè non so a quale tipo di sottoclasse appartenga Object. Prendi tutti i messaggi di Windows, non trovo soluzione allo switch, quando progetti un protocollo di comunicazione come distingui tra i vari comandi che spedisci?
ma alla conclusione di tutto ricorda che se anche dovessi trovare qualche ciclo di clock in più rispetto al modello procedurale, sostituire le catene di if con un sistema di puntatori a funzioni (come quello delle funzioni virtuali, implementato dal compilatore) ti da' l'inestimabile vantaggio di poter sfruttare al massimo il branch predictor.
Quando qualche anno fa, prima ancora di conoscere C#, lessi l'articolo su codeproject sui FastDelegate. A quanto pare l'implementazione dei puntatori a metodi virtuali dei compilatori C++ è un pò fallace.
non posso chiamare il metodo Do() della classe appropriata perchè non so a quale tipo di sottoclasse appartenga Object. cioè stai dicendo che la versione C++ non compila?
Prendi tutti i messaggi di Windows, non trovo soluzione allo switch, se riesci a trovare un algoritmo di hashing che possa disporre ordinatamente tutti i messaggi in maniera sequenziale puoi facilmente usare un array di puntatori a funzioni. può anche darsi che tale algoritmo di hashing sia banale se le costanti sono definite sequenzialmente (io non lo so, non c'ho mai guardato). ovvio comunque che alla fine non si fa: perché sarebbe casomai da farsi solo per scopi molto specifici (es. scrittura di un framework), e perché fa affidamento sui valori numerici delle costanti, e perché non ne vale la pena. ma era un esempio, che si appresta molto bene a rispondere al punto successivo.
quando progetti un protocollo di comunicazione come distingui tra i vari comandi che spedisci? progetti il protocollo in modo che gli opcode siano definiti sequenzialmente, così da poter usare un array di puntatori a funzioni. l'unico if che rimane è il bound checking.
Quando qualche anno fa, prima ancora di conoscere C#, lessi l'articolo su codeproject sui FastDelegate. A quanto pare l'implementazione dei puntatori a metodi virtuali dei compilatori C++ è un pò fallace. esempio di codice che nessun compilatore C++ (o perlomeno la maggior parte) è in grado di compilare correttamente? grazie.
jappilas
02-11-2006, 23:25
Se ne era già discusso, ma questa soluzione mi sembra porti a poco: nel 99% dei casi non conosco il contenuto di PCLASS Object devo quindi farlo passare attraverso una sequenza di if o switch che sia, non posso chiamare il metodo Do() della classe appropriata perchè non so a quale tipo di sottoclasse appartenga Object.
mi sfugge il motivo per cui ti serva, dell' oggetto, avere l' identificatore del tipo o sottoclasse a cui appartiene Object, in forma di valore...
(in questo ambito non ci interessa loggare in forma testuale "Oggetto 1 è di tipo A, Oggetto 2 è di tipo B, eccetera", per cui meccanismi come la reflection di Java vanno al di là dello scope di questa discussione)
Piuttosto, trasparenza e differenziazione a livello comportamentale dei metodi di una classe base, è una delle basi della OOP e uno dei motivi per cui esiste l' override
In realtà, il discorso ha finora omesso un piccolo dettaglio: in tutti i modi, ci sarà una sezione di codice in cui si istanzieranno entità di un tipo o dell' altro (in pratica, una factory); e, cosa più importante, a seconda delle circostanze e necessità algoritmiche avrò comunque delle valutazioni di condizioni (quindi if o switch) che stabiliscano quale tipo di oggetto debba essere creato.
Apparentemente sembra che il problema del controllo di condizioni a runtime, non venga elimiinato ma solo spostato...
Se stai programmando in C la factory, che sarà una routine di inizializzazione, avrà da riempire il campo OBJECT_TYPE con un valore controllato poi nello switch della routine di esecuzione unificata, se stai programmando a classi chiamerai il costruttore di una *classe concreta* piuttosto che l' altra: nel primo caso dovrai fare controlli due volte, in inizializzazione e in esecuzione, nel secondo solo in fase di istanziazione, perchè dopo basterà chiamare il metodo Do() di Object...
Se ne era già discusso, ma questa soluzione mi sembra porti a poco: nel 99% dei casi non conosco il contenuto di PCLASS Object devo quindi farlo passare attraverso una sequenza di if o switch che sia, non posso chiamare il metodo Do() della classe appropriata perchè non so a quale tipo di sottoclasse appartenga Object. Prendi tutti i messaggi di Windows, non trovo soluzione allo switch, quando progetti un protocollo di comunicazione come distingui tra i vari comandi che spedisci?
Così:
Command commands[] = {new Command1(), new Command2(), new Command3(), ......, new LastCommand()};
....
commands[frame.getCommandID()].doAction(frame.getPayload())];
Una cosa del genere l'ho fatta in una net application Java e funziona veramente alla grande... In tutta la catena di gestione del protocollo non ho inserito un if !!! :sofico: Ne segue una complessità ciclomatica bassissima...
Senza contare che la cosa si può utilizzare anche così che è ancora più bello (generalizzando):
OutgoingFrame processProtocol(IncomingFrame &frame)
{
Command commands[] = {new Command1(), new Command2(), new Command3(), ......, new LastCommand()};
Replay replay = commands[frame.getCommandID()].doAction(frame.getPayload())];
return replay.getOutgoingFrame();
}
Se avete paura di istanziare troppi oggetti ad ogni richiesta potete sempre dichiarare commands static ;)
jappilas
02-11-2006, 23:33
Così:
Command commands[] = {new Command1(), new Command2(), new Command3(), ......, new LastCommand()};
....
commands[frame.getCommandID()].doAction(frame.getPayload())];
Una cosa del genere l'ho fatta in una net application Java e funziona veramente alla grande... In tutta la catena di gestione del protocollo non ho inserito un if !!! :sofico: Ne segue una complessità ciclomatica bassissima...bellissimo, stavo giusto pensando di rispondere io con l' esempio di un array di puntatori a oggetti ... :D
Senza contare che la cosa si può utilizzare anche così che è ancora più bello (generalizzando):
OutgoingFrame processProtocol(IncomingFrame &frame)
{
Command commands[] = {new Command1(), new Command2(), new Command3(), ......, new LastCommand()};
Replay replay = commands[frame.getCommandID()].doAction(frame.getPayload())];
return replay.getOutgoingFrame();
}
:cool:
tomminno
02-11-2006, 23:55
cioè stai dicendo che la versione C++ non compila?
No, sto dicendo che IfChainedNotAnymoreFunction è perfettamente inutile, visto che generalmente questi casi si presentano quando hai a che fare con dati di cui non hai il controllo dell'origine: leggi un file, acquisisci un ingresso, ascolti su un socket, tutti casi in cui non ti arriva direttamente una classe, ma qualcosa che, prima di conoscerne il contenuto, devi almeno spacchettarla.
se riesci a trovare un algoritmo di hashing che possa disporre ordinatamente tutti i messaggi in maniera sequenziale puoi facilmente usare un array di puntatori a funzioni. può anche darsi che tale algoritmo di hashing sia banale se le costanti sono definite sequenzialmente (io non lo so, non c'ho mai guardato). ovvio comunque che alla fine non si fa: perché sarebbe casomai da farsi solo per scopi molto specifici (es. scrittura di un framework), e perché fa affidamento sui valori numerici delle costanti, e perché non ne vale la pena. ma era un esempio, che si appresta molto bene a rispondere al punto successivo.
Azz un hashing ordinato per evitare un pò di if? Non so quale delle 2 soluzioni sia più inefficiente.
progetti il protocollo in modo che gli opcode siano definiti sequenzialmente, così da poter usare un array di puntatori a funzioni. l'unico if che rimane è il bound checking.
La fai troppo semplice, non sempre puoi/devi stabilire una numerazione progressiva ai comandi, potresti lasciare dei vuoti per consentire al protocollo di estendersi a seconda degli utilizzi futuri, inoltre pensa un pò se ricevi un XML dove hai un tag <Command> in base al cui valore devi interpretare il contenuto di quello che viene dopo, non puoi fare altro che usare uno switch sul contenuto del tag.
esempio di codice che nessun compilatore C++ (o perlomeno la maggior parte) è in grado di compilare correttamente? grazie.
Non ho detto che non riescano a compilarlo (anche se castare un puntatore a metodo potrebbe portare ad errori su compilatori differenti, visto che non hanno tutti la stessa dimensione, non so però che utilità possa avere questa operazione) ho solo detto che non riescono a generare codice efficiente (certo sempre più efficiente dei delegati del C# :D ), tant'è che ogni compilatore aggiunge una propria parola chiave allo standard per trattare al meglio casi di puntatori a metodi, visto che ogni compilatore li implementa a modo suo e il sizeof restituisce dimensioni diverse a seconda del compilatore e del tipo di metodo puntato. Spero vivamente che con il TR1 risolvano definitivamente questa cosa.
tomminno
03-11-2006, 00:06
In realtà, il discorso ha finora omesso un piccolo dettaglio: in tutti i modi, ci sarà una sezione di codice in cui si istanzieranno entità di un tipo o dell' altro (in pratica, una factory); e, cosa più importante, a seconda delle circostanze e necessità algoritmiche avrò comunque delle valutazioni di condizioni (quindi if o switch) che stabiliscano quale tipo di oggetto debba essere creato.
Proprio questo che volevo dire, non puoi togliere gli switch.
Apparentemente sembra che il problema del controllo di condizioni a runtime, non venga elimiinato ma solo spostato...
Se stai programmando in C la factory, che sarà una routine di inizializzazione, avrà da riempire il campo OBJECT_TYPE con un valore controllato poi nello switch della routine di esecuzione unificata, se stai programmando a classi chiamerai il costruttore di una *classe concreta* piuttosto che l' altra: nel primo caso dovrai fare controlli due volte, in inizializzazione e in esecuzione, nel secondo solo in fase di istanziazione, perchè dopo basterà chiamare il metodo Do() di Object...
Non se i dati che devi interpretare sono continuamente variabili per cui hai bisogno dello switch per la generazione dell'oggetto a "run time". Cioè tutte le volte che devo andare a pescare dati da qualche parte devo chiedermi che dati sono?->switch->Creo l'oggetto->Ci faccio quello che mi pare. Chiaro che se questo lo posso fare staticamente una volta sola nel costruttore mi risparmio la fatica ma non sempre è possibile.
Chiaro che se questo lo posso fare staticamente una volta sola nel costruttore mi risparmio la fatica ma non sempre è possibile.
E' chiaro che non tutto si può riportare al caso sopra, ma si può coprire gran parte delle problematiche...
tomminno
03-11-2006, 00:28
Così:
Command commands[] = {new Command1(), new Command2(), new Command3(), ......, new LastCommand()};
....
commands[frame.getCommandID()].doAction(frame.getPayload())];
Una cosa del genere l'ho fatta in una net application Java e funziona veramente alla grande... In tutta la catena di gestione del protocollo non ho inserito un if !!! :sofico: Ne segue una complessità ciclomatica bassissima...
Hai però anche allocato un numero impressionante di classi, se hai 32KB di ram non è il massimo. Inoltre il commandID deve essere numerico e perfettamente sequenziale, sai che palle inizializzare anche 256 classi! E se qualche pazzo mette l'ID su un intero? :help:
E se ti scambi un messaggio XML con comandi testuali? Si ok un hash tra stringa e id (che è quello che uso anch'io), ma possibile che l'hash costi meno di uno switch?
(Perdonatemi la risposta tardiva)
fino ad un certo punto lo sono...
quando incominci a usare primitive di sistema(posix, win32, etc) il codice non diventa piu cross plattaform, mentre in java (compilato o source) gira tranquillamente(non proprio tranquillamente se si fanno cose molto particolari...)su jvm dei diversi sistemi e SO.
Sono le librerie a non esserlo, non il linguaggio. La cosa puo' capitare anche in Java se chi le crea utilizza strumenti specifici di una piattaforma (vedi le SWT).
no perché la "Turing-completezza" non coinvolge la potenza in termini di interazione con la piattaforma (in Java non puoi chiamare le API Win32).
D'altra parte da C fai fatica a chiamare le API del framework Java. In questo caso piu' che potenza la definirei supporto da parte della piattaforma. E' un vantaggio notevole ma non mi sembra sia merito del linguaggio in se'.
ma non solo: Java per esempio non da' la possibilità di ereditare da basi multiple. che il signor Turing la mettesse come gli pare, è una cosa che in C++ posso fare e in Java no.
E' un discorso molto piu' ragionevole, ma in questo caso non e' che C++ e ancor piu' C se la cavino molto bene. Mancano molte delle cosette carine che si possono trovare in altri linguaggi moderni, come closures, first order functions (e compagnia), serie possibilita' di introspezione, altro ancora. C++ si proclama multi-paradigma, ma la cosa gli riesce solo a costo di una notevole complessita' e perdita di chiarezza del codice. Il povero programmatore che volesse convertire l'equivalente di [ x.do() for x in container if x.needsDo() ] da Python a C++ dovrebbe cimentarsi con oggetti funzione e back inserters (intraducibile in Italiano se non si vuole andare sul volgare :D), tanto che il piu' delle volte si ritorna al classico ciclo for, con tanti saluti agli iteratori.
Penso che un linguaggio, per essere potente (secondo la mia definizione ovviamente) dovrebbe trovare un buon compromesso tra i tre seguenti aspetti
1 - espressivita', ovvero la capacita' di descrivere un determinato algoritmo/programma nel modo piu' consono; questo e' ancora piu' vero quando il linguaggio e' anche estendibile, e quindi adattabile a nuove idee/paradigmi.
2 - semplicita', nelle varie accezioni (sintassi, semplicita' della vita del programmatore, semplicita' del codice che il programmatore viene portato a scrivere)
3 - efficienza (anche se in effetti il linguaggio non e' efficiente di per se', ma puo' rendere piu' o meno semplice la vita al compilatore/interprete).
Purtroppo spesso una caratteristica fa a pugni con un'altra (se ho dieci modi di scrivere la stessa cosa, avro' un' espressivita' (fin troppo) elevata, ma va a quel paese la semplicita'), se non altro in molti contesti si puo' fare a meno di una delle tre. Idealmente un buon linguaggio ha un set relativamente ristretto di caratteristiche tra di loro ortogonali che permettano di preservare la semplicita' e di estendere il linguaggio per renderlo espressivo.
Per tornare al C++, se la cava bene col punto 3, ma l'espressivita' si ottiene a discapito della semplicita'.
Ripeto...è chiaro che non è sempre applicabile...
Lo spreco di memoria è trascurabile (sempre che siano di un'ordine di grandezza accettabile)... Sono method object...solitamente la parte dati è molto leggera, al massimo qualche puntatore...
Per comandi non sequenziali ?
I comandi "vuoti" si risolvono in maniera elegante con i NullObject...
Command commands[] = {new Command1(), new Command2(), new NullCommand(), ......, new LastCommand()};
Non importa coprire tutta l'estensione dei valori del commandID, ma per controllare che non si vada oltre l'ultimo elemento in C++ basta un if...in Java si aspetta un'eventuale eccezione di IndexOutOfBound.
Riguardo al costo dell'hash rispetto a quello dello switch, non ci metterei la mano sul fuoco...
Direi che con un basso numero di elementi prevale la componente di calcolo dell'hash, mentre per un elevato numero di elementi prevale la componente di confronto con gli hash esistenti che sicuramente saranno ordinati con qualche criterio...e quindi l'accesso è meidamente molto più veloce dello switch...ad occhio...
Poi anche con l'hash ne guadagna la leggibilità...senza ombra di dubbio...
tomminno
03-11-2006, 00:53
D'altra parte da C fai fatica a chiamare le API del framework Java. In questo caso piu' che potenza la definirei supporto da parte della piattaforma. E' un vantaggio notevole ma non mi sembra sia merito del linguaggio in se'.
Tra le 2 meglio chiamare le API dell'OS che non quelle di un framework non ti pare? Visto che alla fine il framework non può fare altro, a sua volta, che riferirsi all'OS.
E' un discorso molto piu' ragionevole, ma in questo caso non e' che C++ e ancor piu' C se la cavino molto bene. Mancano molte delle cosette carine che si possono trovare in altri linguaggi moderni, come closures,
Per closures intendi i delegati?
Il povero programmatore che volesse convertire l'equivalente di [ x.do() for x in container if x.needsDo() ] da Python a C++ dovrebbe cimentarsi con oggetti funzione e back inserters (intraducibile in Italiano se non si vuole andare sul volgare :D), tanto che il piu' delle volte si ritorna al classico ciclo for, con tanti saluti agli iteratori.
Che cavolo vorrebbe dire quella riga di codice? Parlando di chiarezza e avendo da sempre a che fare con linguaggi con sintassi C-like per me è arabo. Comunque così ad occhio un for te lo ritrovi anche lì o sbaglio?
Per tornare al C++, se la cava bene col punto 3, ma l'espressivita' si ottiene a discapito della semplicita'.
Programmando ormai da qualche tempo anche in C#, non vedo tutta questa complessità in più nel C++. Il fatto è che in C# hai il framework che ti dà già la pappa pronta quindi fai prima perchè c'è già qualcuno che ha fatto le cose per te, ma non appena cerchi di fare qualcosa che non è previsto dal framework di tempo ce ne perdi parecchio ugualmente.
x.do() for x in container if x.needsDo()
Ad occhio quel comando significa fai quella operazione su ogni elemento di x se x.needDo() ritorna vero...
In C++ si traduce in questo modo:
class X
{
int data;
public:
X(int d = 0):data(d){};
bool needToDoSomething()
{
return data <= 3;
};
static void doSomething(X &elem)
{
if(elem.needToDoSomething())
{
elem.data *= 2;
}
};
};
for_each(v.begin(), v.end(), X::doSomething);
L'unica differenza è l'applicazione della modifica che deve avvenire indirettamente dal metodo statico...
Mi sembra che come espressività non siamo molto lontani ;)
Tra le 2 meglio chiamare le API dell'OS che non quelle di un framework non ti pare? Visto che alla fine il framework non può fare altro, a sua volta, che riferirsi all'OS.
Dipende cosa ci devi fare. Potrei trarre poca utilita' dalle API dell'OS, ma avere bisogno di qualche interfaccia di piu' alto livello o di una funzionalita' scritta in puro Java (che ne so, manipolazione di oggetti XML).
Per closures intendi i delegati?
Uhm, direi di no. I delegates di C# sono fondamentalmente dei function pointer type-safe, e vengono utilizzati per le callback, le closures sono delle funzioni che fanno riferimento alle variabili libere del proprio contesto lessicale. Mi sa che mi spiego meglio con un esempio :p (in python, porta pazienza, ma dovrebbe essere chiaro):
def make_adder(n):
def adder(x):
x+=n
return adder
f = make_adder(10)
x = 10
f(x)
# ora x vale 20
Quello scritto sopra e' una funzione che prende un numero e "crea" e ritorna una funzione che aggiunge quella quantita' al proprio argomento. Il loro uso tipico e' piu' o meno quello degli oggetti funzione (rimandare l'esecuzione, nascondere lo stato...), con codice pero' piu' leggero e piu' "locale".
Che cavolo vorrebbe dire quella riga di codice? Parlando di chiarezza e avendo da sempre a che fare con linguaggi con sintassi C-like per me è arabo. Comunque così ad occhio un for te lo ritrovi anche lì o sbaglio?
Sorry, davo per scontato troppe cose ovviamente :P. Se te lo riscrivo come formula matematica forse lo capisci meglio :
{ x.do() | x ϵ container , x.needsDo() == True }
Ovvero l'insieme dei risultati di x.do() al variare di x tra gli elementi di container e qualora x.needsDo() sia vero. Nella versione python e' la lista dei risultati dell'applicazione di x.do() tra gli elementi di container che soddisfano la condizione.
Il modo piu' breve per scriverlo in C++ sarebbe all'incirca il seguente (supponendo di usare vettori):
vector<int> v;
for ( int i=0 ; i<u.size() ; ++i )
{
if ( u[i]->needsDo() )
v.push_back( u[i]->do() );
}
Che non e' poi cosi' tragico. Il problema si complica se pero' vuoi generalizzare, ad esempio perche' vorresti poter usare lo spezzone di codice anche con altri tipi di container, o sparare direttamente il risultato ad un altro pezzo di codice senza dover usare delle strutture dati intermedie.
In python e' semplice, cambio le [] in ():
y = ( x.do() for x in container if x.needsDo() )
...
for x in y:
print x
Ottengo come risultato un generatore, ovvero un oggetto che mi ritorna un risultato alla volta man mano che lo chiamo.
In C++ bisogna prima di tutto cominciare ad utilizzare i template con almeno due parametri (i tipi di iteratori di ingresso e quelli di uscita), cambiare il ciclo for in un while, ed assicurarti prima della chiamata che l'iteratore di uscita supporti l'accodamento.
// occhio, codice non testato !
template<typename In,typename Out>
Out doSomething( In begin, In end, Out out )
{
while ( begin != end )
{
if ( begin->needsDo())
{
*out= begin->do();
++out;
++begin;
}
}
return out;
}
/* ... */
set<Foo*> foos = ...
vector<int> result;
doSomething( foos.begin(), foos.end(), back_inserter(result))
// o anche
doSomething( foos.begin(), foos.end(), ostream_iterator<int>(cout));
Il codice comincia a diventare tutt'altro che semplice (non mi stupirei se avessi inserito un bug da qualche parte nelle righe qui sopra), soprattutto da parte del chiamante, e anche usando altri metodi o funzioni apposite per iteratori (for_each, transform...) non mi sembra che le alternative siano piu' chiare. Molti programmatori probabilmente rinunceranno ad una soluzione simile, e si riscriveranno la funzione volta per volta adattandola al contenitore sottomano, o magari preferiranno usare un contenitore sottomano per il risultato dell'elaborazione, a discapito dell'efficienza.
Non sembra, ma cosette come queste rendono molto piu' semplice la vita al programmatore. Se vuoi posso farti un esempio un po' piu' corposo, in cui si puo' separare il flusso logico del programma da quello effettivo dell'elaborazione (ma non adesso, vista l'ora :p ).
Programmando ormai da qualche tempo anche in C#, non vedo tutta questa complessità in più nel C++. Il fatto è che in C# hai il framework che ti dà già la pappa pronta quindi fai prima perchè c'è già qualcuno che ha fatto le cose per te, ma non appena cerchi di fare qualcosa che non è previsto dal framework di tempo ce ne perdi parecchio ugualmente.
Concordo, ma per il fatto che C# non e' molto piu' semplice di C++, (soprattutto con le continue aggiunte alla sintassi), non perche' il C++ non sia difficile.
giannola
03-11-2006, 07:04
il linguaggio del futuro? nella sfera di cristallo vedo C++ :)
il c++ sta per diventare concettualmente obsoleto in ottica di programmazione ad aspetti: non è il linguaggio del futuro. ;)
Così:
Command commands[] = {new Command1(), new Command2(), new Command3(), ......, new LastCommand()};
....
commands[frame.getCommandID()].doAction(frame.getPayload())];
Versione del "pythonico accidioso":
import commands_module
v = vars(commands_module)
commands = dict( (int(x[7:]), v[x]()) for x in v.keys() if x.startswith("Command") )
...
commands[frame.commandID].doAction( ... )
:mbe: :stordita: :ops2:
tomminno
03-11-2006, 11:53
Dipende cosa ci devi fare. Potrei trarre poca utilita' dalle API dell'OS, ma avere bisogno di qualche interfaccia di piu' alto livello o di una funzionalita' scritta in puro Java (che ne so, manipolazione di oggetti XML).
Per queste cose di alto livello puoi usare delle librerie come le Xerces o il framework .NET, mentre per certe altre non puoi fare a meno di riferirti direttamente all'OS.
Uhm, direi di no. I delegates di C# sono fondamentalmente dei function pointer type-safe, e vengono utilizzati per le callback, le closures sono delle funzioni che fanno riferimento alle variabili libere del proprio contesto lessicale.
La confusione mia era dovuta al fatto che il nome C++ dei delegati è closures.
Mi sa che mi spiego meglio con un esempio :p (in python, porta pazienza, ma dovrebbe essere chiaro):
def make_adder(n):
def adder(x):
x+=n
return adder
f = make_adder(10)
x = 10
f(x)
# ora x vale 20
Quello scritto sopra e' una funzione che prende un numero e "crea" e ritorna una funzione che aggiunge quella quantita' al proprio argomento. Il loro uso tipico e' piu' o meno quello degli oggetti funzione (rimandare l'esecuzione, nascondere lo stato...), con codice pero' piu' leggero e piu' "locale".
non è più o meno lo stesso di:
class Adder
{
public:
Adder(int y) : n(y){}
int Add(int x) {return n + x;}
private:
int n;
}
non conosco Python ma la variabile x deve essere nello scope di tutto il codice oppure il nome della variabile è ininfluente?
Sorry, davo per scontato troppe cose ovviamente :P. Se te lo riscrivo come formula matematica forse lo capisci meglio :
{ x.do() | x ϵ container , x.needsDo() == True }
Ovvero l'insieme dei risultati di x.do() al variare di x tra gli elementi di container e qualora x.needsDo() sia vero. Nella versione python e' la lista dei risultati dell'applicazione di x.do() tra gli elementi di container che soddisfano la condizione.
Ma container cos'è?
Il modo piu' breve per scriverlo in C++ sarebbe all'incirca il seguente (supponendo di usare vettori):
vector<int> v;
for ( int i=0 ; i<u.size() ; ++i )
{
if ( u[i]->needsDo() )
v.push_back( u[i]->do() );
}
Questo direi che vale anche per Java o C#.
Che non e' poi cosi' tragico. Il problema si complica se pero' vuoi generalizzare, ad esempio perche' vorresti poter usare lo spezzone di codice anche con altri tipi di container, o sparare direttamente il risultato ad un altro pezzo di codice senza dover usare delle strutture dati intermedie.
In python e' semplice, cambio le [] in ():
y = ( x.do() for x in container if x.needsDo() )
...
for x in y:
print x
Ottengo come risultato un generatore, ovvero un oggetto che mi ritorna un risultato alla volta man mano che lo chiamo.
Ma Python sa a quale container ti riferisci? Oppure non fa distinzione?
In C++ bisogna prima di tutto cominciare ad utilizzare i template con almeno due parametri (i tipi di iteratori di ingresso e quelli di uscita), cambiare il ciclo for in un while, ed assicurarti prima della chiamata che l'iteratore di uscita supporti l'accodamento.
// occhio, codice non testato !
template<typename In,typename Out>
Out doSomething( In begin, In end, Out out )
{
while ( begin != end )
{
if ( begin->needsDo())
{
*out= begin->do();
++out;
++begin;
}
}
return out;
}
/* ... */
set<Foo*> foos = ...
vector<int> result;
doSomething( foos.begin(), foos.end(), back_inserter(result))
// o anche
doSomething( foos.begin(), foos.end(), ostream_iterator<int>(cout));
Il codice comincia a diventare tutt'altro che semplice (non mi stupirei se avessi inserito un bug da qualche parte nelle righe qui sopra), soprattutto da parte del chiamante, e anche usando altri metodi o funzioni apposite per iteratori (for_each, transform...) non mi sembra che le alternative siano piu' chiare. Molti programmatori probabilmente rinunceranno ad una soluzione simile, e si riscriveranno la funzione volta per volta adattandola al contenitore sottomano, o magari preferiranno usare un contenitore sottomano per il risultato dell'elaborazione, a discapito dell'efficienza.
I template ci sono apposta per fare queste cose.
Parli di efficienza, ma non sai cosa fa Python per implementare quella riga di codice, visto che il motore è scritto in C.
A proposito chissà come mai Python, PHP, Lua hanno motori scritti in C invece che in C++.
non conosco Python ma la variabile x deve essere nello scope di tutto il codice oppure il nome della variabile è ininfluente?
Il nome e' ininfluente, x e' solo una variabile locale alla funzione adder. In effetti l'esempio che ho portato e' poco felice perche' poi riutilizzo lo stesso nome in un altro contesto
def make_adder(n):
def adder(x):
x+=n
return adder
f = make_adder(10)
z = 10
f(z)
# ora z vale 20
Questo fa la stessa cosa
non è più o meno lo stesso di:
class Adder
{
public:
Adder(int y) : n(y){}
int Add(int x) {return n + x;}
private:
int n;
}
Il risultato e' quello, diciamo che l'approccio con le closures e' piu' "leggero" e a me il codice risultante risulta piu' chiaro. Usando oggetti funzione appena mi serve qualcosa di piu' complicato, ad esempio creare una coppia di funzioni che condividono la stessa variabile, il codice comincia a diventare piu' complesso, soprattutto se i dati condivisi sono mutabili.
Ma container cos'è?
Un contenitore qualsiasi di oggetti, una lista, un vettore, un array...
Ma Python sa a quale container ti riferisci? Oppure non fa distinzione?
Fa lo stesso, basta che possa ritornarmi un iteratore, in modo non molto diverso da quel che che accade in Java e, penso in C#. Inoltre posso usare dei generatori per generare una sequenza potenzialmente infinita di elementi o per non dover usare grosse strutture dati intermedie.
Mah, secondo me non esiste un linguaggio meglio di un'altro in generale ma
esiste un linguaggio che è meglio di un altro in un determinato scopo :),
semplificando se devo scrivere un driver a basso livello magari lo faccio in C,
se devo fare un gioco di una certa complessità magari uso il C++, se volgio
fare un programma portatile su più piattaforme con interfaccia grafica magari
uso il java, se voglio fare un gestionale solo per ambiente windows magari uso
il VB o .NET che sia e via dicendo :D, io cosi a pelle ti consiglio di imparare
il java e l'approccio alla filosofia ad Oggetti, da li il passo a .NET e breve
e anche ( magari con un po più di sbattimento ) a C++, ovviamente imho ;)
quoto al 100%
la chiave per essere concorrenziali al giorno d'oggi è conoscere più linguaggi io dopo anni di C/C++ mi sono dovuto imparare la piattaforma .net , poi studiare jave/actionscript per flash ... ora scelgo il linguaggio che più si addice al lavoro che devo eseguire.
p.s.sarebbe bello conoscere anche assembler ma....... :muro:
No, sto dicendo che IfChainedNotAnymoreFunction è perfettamente inutile, be' è chiaro che in quel caso potevi chiamare direttamente Object->Do() anziché farla chiamare da IfChainedBlaBlaBla, ma può anche darsi che IfChainedBlaBlaBla debba fare anche altro lavoro oltre a chiamare Object->Do().
visto che generalmente questi casi si presentano quando hai a che fare con dati di cui non hai il controllo dell'origine: leggi un file, acquisisci un ingresso, ascolti su un socket, tutti casi in cui non ti arriva direttamente una classe, ma qualcosa che, prima di conoscerne il contenuto, devi almeno spacchettarla. hash table di puntatori a funzioni; e algoritmo di hashing senza collisioni, così la tabella è un array.
Azz un hashing ordinato per evitare un pò di if? Non so quale delle 2 soluzioni sia più inefficiente. sicuramente gli if.
La fai troppo semplice, non sempre puoi/devi stabilire una numerazione progressiva ai comandi, potresti lasciare dei vuoti per consentire al protocollo di estendersi a seconda degli utilizzi futuri, puntatore NULL nella tabella, oppure metodo che non fa nulla, oppure ancora algoritmo di hashing che elimina i vuoti.
inoltre pensa un pò se ricevi un XML dove hai un tag <Command> in base al cui valore devi interpretare il contenuto di quello che viene dopo, non puoi fare altro che usare uno switch sul contenuto del tag. non uno switch, ma una catena di if (gli switch non comparano blocchi di memoria, quindi neanche stringhe). infatti in questo caso non si può far nulla a meno che per altri motivi non sia comunque necessario effettuare prima una traduzione a opcodes; in quel caso sfrutti la cosa utilizzando gli opcodes come inidici all'array di handlers.
(anche se castare un puntatore a metodo potrebbe portare ad errori su compilatori differenti, visto che non hanno tutti la stessa dimensione, non so che esempi di codice non portabile tu abbia in mente, ma ci vuole poco a crearne di portabile.
non so però che utilità possa avere questa operazione) ah boh, chi l'ha introdotta nel discorso?
ho solo detto che non riescono a generare codice efficiente nessuno...? eeeeeh bè, se tu hai inventato un geniale sistema per compilare codice più efficiente di quello che riescano a generare la media dei compilatori C++ allora entra nel team del g++ (e complimenti da parte mia).
tant'è che ogni compilatore aggiunge una propria parola chiave allo standard per trattare al meglio casi di puntatori a metodi, quale sarebbe ad es. quella del compilatore Microsoft? (qui (http://msdn2.microsoft.com/en-us/library/2e6a4at9.aspx) se vuoi hai l'elenco completo).
il sizeof restituisce dimensioni diverse a seconda del compilatore e del tipo di metodo puntato. non ti seguo, sizeof di che? che vuol dire "tipo di metodo puntato"? tipo del valore di ritorno? prototipo? calling convention?
D'altra parte da C fai fatica a chiamare le API del framework Java. non tutte le macchine Windows hanno una macchina virtuale Java; però tutte le macchine Windows hanno il subsystem Win32. se poi consideriamo più in generale che le primitive di un sistema operativo sono molto più potenti delle classi che hai a disposizione con Java...
tomminno
03-11-2006, 19:41
non so che esempi di codice non portabile tu abbia in mente, ma ci vuole poco a crearne di portabile.
ah boh, chi l'ha introdotta nel discorso?
Io non ho mai parlato di codice non portabile, ho sempre fatto riferimento a codice generato dal compilatore non efficiente quanto in teoria potrebbe essere. E questo è colpa dello standard.
nessuno...? eeeeeh bè, se tu hai inventato un geniale sistema per compilare codice più efficiente di quello che riescano a generare la media dei compilatori C++ allora entra nel team del g++ (e complimenti da parte mia).
Io non ho inventato proprio niente, constato solamente che la parte del C++ relativa ai puntatori a metodo è un pò poco standardizzata, tanto che pare sia una delle sezioni principali del TR1.
quale sarebbe ad es. quella del compilatore Microsoft? (qui (http://msdn2.microsoft.com/en-us/library/2e6a4at9.aspx) se vuoi hai l'elenco completo).
__single_inheritance, __multiple_inheritance, __virtual_inheritance con queste parole chiave il compilatore riesce a generare codice quasi ottimale per i puntatori a metodo, nonostante la dimensione non sia mai pari a 4byte (eccetto che con __single_inheritance). Poi c'è l'opzione di compilazione /vmg che dichiara implicitamente tutte le classi come __virtual_inheritance, perciò tutti i puntatori a metodo occupano la dimensione massima. E c'era un bug fino a VC6 per cui se abiliti solo /vmg e non /vmm potresti ottenere il puntatore ad un altro metodo rispetto a quello richiesto.
Poi c'è il caso pessimo della forward declaration, dove il compilatore non sapendo che pesci prendere utilizza 16 byte.
Altra via di fuga con i compilatori Microsoft è la direttiva del precompilatore pointers_to_members.
non ti seguo, sizeof di che? che vuol dire "tipo di metodo puntato"? tipo del valore di ritorno? prototipo? calling convention?
Il sizeof di un puntatore a metodo, restituisce dimensioni differenti a seconda del tipo di eredità che si porta dietro la classe.
non è colpa della OOP di per se', visto che come vedi esistono implementazioni più efficienti (C++).
è chiaro che l'accesso a un registro è necessariamente più veloce di un accesso in memoria (anche solo perché un accesso in memoria, cache miss o hit che sia, deve comunque passare a sua volta per un paio di registri interni non accessibili da assembly, ovvero il MAR e quell'altro che non ricordo il nome).
ma in realtà non è che le cose migliorino traducendo in paradigma procedurale; mettiamola così: la OOP (perlomeno per come è implementata in C++) non introduce nessun overhead se non qualche ciclo di clock dovuto ad un sistema di puntatori a funzioni, le funzioni virtuali. ora se tu questo sistema lo vuoi usare e ne hai bisogno lo usi, sennò evita di fare metodi virtuali e non avrai nessun overhead.
quand'è che è conveniente usare le funzioni virtuali? tutte le volte che hai la possibilità di sostituire un branch condizionato con uno incondizionato. canonico l'esempio della GetType, che adesso ti espongo per intero. prendi queste righe di C:
omissis
ora prendi la corrispondente versione C++:
omissis...
ora li vedi i vantaggi in termini sia di design che di performance?
Per le performance dovremmo essere sicuri che la IfChainedFunction comporti branch prediction. Lo siamo? Siamo sicuri sicuri? Be', non dovremmo esserlo. Ad esempio l'ISA AMD64 ci dice che quella roba lì è meglio farla un CMP - CMOVE e alla fine un bel CALL, proprio perchè così facendo non si incorre nell'eventuale penalità della branch prediction.
Per me fare dell'orientamento agli oggetti una questione di performance è come dire "andiamo a vedere il Mosè di Michelangelo perchè ci piace il marmo". Se ti piace il marmo, vai in un cava: lì ne trovi quanto ne vuoi.
Perchè se parliamo di orientamento agli oggetti allora parliamo di capacità di rappresentare l'interpretazione di un fenomeno. Tema inesistente nelle altre prospettive, inclusa la prospettiva orientata agli aspetti. In C non esiste un'interpretazione possibile di un fenomeno all'infuori di quella che produrrebbe un calcolatore.
Quanto segue lo dico in base a come appare a me, che leggo: non è detto che queste fossero le tue intezioni.
Il codice C che proponi è la rappresentazione che un calcolatore fornirebbe del fenomeno "scegli cosa fare in base ad un parametro".
Il codice C++ che è la rappresentazione del fenomeno "qualcuno fa qualcosa".
Manca la scelta. Tabella, lista, quello che vuoi. Ma usi una tabella o una lista perchè così eviti la branch prediction?
Perchè cionci ha usato un array di command e non una catena di if-else su tanti oggetti command? Avrebbe potuto usare una catena di if-else, con un'invocazione del metodo "esegui" di un certo Command per ogni anello della catena?
Il command pattern separa il cosa (command) dal quando (stabilito da chi gestisca i command). Tutto ciò che consente al "quando" di scegliere senza sapere quale azione sarà eseguita e anche solo se una qualche azione sarà eseguita rispetta la separazione che colora il pattern usato. Tutto ciò che non offra questa piena separazione rende inutile il pattern.
Non puoi usare una catena di if-else così:
commandUno = new CommandUno();
commandDue = new CommandDue();
commandTre = new CommandTre();
esegui(tipo) {
if(tipo == tipoa)
commandUno.esegui();
else if(tipo == tipob)
commandDue.esegui();
else if(tipo == tipoc)
commandTre.esegui();
}
Che questo rompa il principio di separazione che fonda il command pattern è evidente se si rimuova dal sistema la classe CommandUno: chi sceglie non può più farlo, ergo quando e cosa non sono affatto separati.
La mappa "va" perchè separa i comandi dalla stanza dei bottoni usando come intermedio le chiavi di inserimento.
Non credo di doverlo ricordare ma affinchè due oggetti siano indipendenti è necessario e sufficiente che la definizione dell'uno non implichi la definizione dell'altro. La mappa di Command è ciò che unisce comando e scelta conservando la reciproca indipendenza.
scegli(tipo) {
Command c = mappa.get(tipo);
if(c != null)
c.esegui();
}
La catena di if potrebbe (forse) anche andare se si preservasse la sperazione tra chi sceglie e i singoli command "evocati":
Command a, b, c;
scegli(tipo) {
if(tipo == tipoa && a != null)
a.esegui();
else if(tipo == tipob && b != null)
b.esegui();
else if(tipo == tipoc && c != null)
c.esegui();
}
C'è una dipendenza tra il codice della scelta e l'esistenza di certi riferimenti di tipo Command (a, b, c) ma non so se sia interpretabile come violazione del command pattern.
Una cosa è certa: la branch prediction non c'entra. E non è questione di miglior design ma di design e basta: se scegli il command pattern, scrivi un command pattern, non qualcosa che lo contraddica.
Per le performance dovremmo essere sicuri che la IfChainedFunction comporti branch prediction. Lo siamo? Siamo sicuri sicuri? :wtf: no che non lo siamo, anzi siamo sicuri del contrario, è questo che stavo dicendo... un if nella maggior parte dei casi causa un Jcc, ovvero un jump condizionato che in linea di principio non è "predictable" perché non si sa che valori assumeranno i flags subito prima del Jcc.
Be', non dovremmo esserlo. Ad esempio l'ISA AMD64 ci dice che quella roba lì è meglio farla un CMP - CMOVE e alla fine un bel CALL, CALL? e cosa chiami?
proprio perchè così facendo non si incorre nell'eventuale penalità della branch prediction. se il branch predictor funziona per te è una penalità...? :huh:
io mica ti seguo eh...
Per me fare dell'orientamento agli oggetti una questione di performance è come dire "andiamo a vedere il Mosè di Michelangelo perchè ci piace il marmo". Se ti piace il marmo, vai in un cava: lì ne trovi quanto ne vuoi. e dove la trovo la cava delle ottimizzazioni?
Il codice C che proponi è la rappresentazione che un calcolatore fornirebbe del fenomeno "scegli cosa fare in base ad un parametro". no, veramente io intendevo "scegli cosa fare in base al tipo di entità che ti è arrivata in input", che vale "fai una scelta che è stata già fatta al momento della creazione di quell'entità".
Il codice C++ che è la rappresentazione del fenomeno "qualcuno fa qualcosa". io invece intendevo esattamente la stessa cosa di prima; solo che stavolta diventa "fai direttamente senza scegliere, perché sfrutti il risultato della scelta che è stata fatta prima".
Una cosa è certa: la branch prediction non c'entra. ripeto che in linea teorica un meccanismo di branch prediction non può prevedere l'esito di un branch condizionato, mentre di uno incondizionato si.
Il sizeof di un puntatore a metodo, restituisce dimensioni differenti a seconda del tipo di eredità che si porta dietro la classe. ok, ora ho capito... ma che c'entrano i puntatori a metodi...? :wtf:
:wtf:
Chiamo la funzione il cui indirizzo è immagazzinato in un GPR con il CMOVE invocato a seguito dell'esito positivo del CMP. Se guardi a pag. 43 del primo volume di "AMD 64 Architecture Programming Manual" a me pare che il codice C che hai proposto sia fattibile in questo modo. Uei, magari sbaglio, in caso correggetemi, non casca il pianeta :D.
Non sapevo che esistesse un branch incondizionato. Forse parliamo di cose diverse. Per branch intento il Conditional Branch di pag. 112 del Patterson-Hennessy (Computer Architecture , A quantitative Approach, 3a edizione) e per Branch Prediction quello di cui si parla a partire da pag. 196, stesso libro.
Cito il libro non per dire che l'ho letto (che spero proprio non gliene freghi niente a nessuno) ma perchè è più che possibile che altri parlino di branch in un senso diverso. Ecco, non parlo di un branch che mi sono inventato stamattina :D. Non mi riesce difficile immaginare che "branch", nel senso di ramificazione, sia anche un'invocazione di procedura. Mi chiedo però se abbia un senso parlare di predizione per un "branch incondizionato": che c'è da predire? Il flusso di esecuzione passerà sempre di lì: se no sarebbe condizionato.
Sempre tenendo conto di ciò di cui parlo, se il branch predictor funziona non è una penalità. Ma se il branch predictor non funziona, cioè fa una previsione errata, allora è una penalità, perchè le istruzioni eseguite nella validità supposta della condizione di ramificazione sono andate a vuoto e deve essere computato l'altro ramo.
So che intendevi "scegli cosa fare in base al tipo di entità che ti è arrivata in input" e che il codice C++ avrebbe dovuto essere la versione OO dello stesso fenomeno ma non è così. Diamine, lo vedi anche tu! In C scegli in base ad un parametro, in C++ invochi una funzione su un oggetto. L'analogo C di quello che hai scritto in C++ è:
#include <stdio.h>
#include <stdlib.h>
typedef void(*fun)(void);
void invoke(fun);
void function1(void);
void function2(void);
int main(int argc, char *argv[])
{
fun function = &function1;
invoke(function);
function = &function2;
invoke(function);
system("PAUSE");
return 0;
}
void invoke(fun f) {
f();
}
void function1() {
printf("I AM THE ONE!!!\n");
}
void function2() {
printf("I AM THE TWO!!!\n");
}
Cioè la scelta dell'invocazione è a monte dell'invocazione (è tardi, non m'è venuto di meglio :D).
giannola
04-11-2006, 05:55
capisco che siamo in programmazione e che "tecnicamente" quello che dite è pertinente, ma non potreste evitare queste dissertazioni tecnicistiche ?
Credo non si faccia altro che generare confusione in un neofita, che non ha altri parametri di riferimento oltre a quello che gli diciamo noi.
Cmq tornando ad un topic più di conserva ribadisco che se uno non ha mai fatto progarammazione ad alcun livello, dovrebbe scegliere un linguaggio che, lungi dall'essere debole, ben si adatta come linguaggio di primo approccio: il Visual Basic, soprattutto per capire in maniera intuitiva la programmazione ad oggetti.
Poi, solo poi, puntare a linguaggi con una sintassi prevalentemente matematica come il C, C++.
Personalmente in genere mi sento di sconsigliare il Java poichè è interpretato, meglio in termini di risorse e di tempo linguaggi compilati. ;)
il Visual Basic, soprattutto per capire in maniera intuitiva la programmazione ad oggetti.
Dai via...il VB6 ha un supporto agli oggetti penoso :eek: Lo definirei più un linguaggio procedurale con un framework ad oggetti e nemmeno molto elegante...
Personalmente in genere mi sento di sconsigliare il Java poichè è interpretato
Per uno che inizia questo non può che essere un vantaggio...
sottovento
04-11-2006, 10:01
... omissis...
Sento che il linguaggio più ricercato e che nn morirà è il java sia per sistemi linux e windows!
... omissis...
Ciao,
di suggerimenti e di criticismi ne sono piovuti a sufficienza, soprattutto da persone piu' preparate del sottoscritto. Quindi mi astengo.
Volevo solo raccontare una piccola storiella sui linguaggi che non moriranno mai...
Immagino non ti ricordi del PL/1. Quando IBM presento' questo linguaggio, gli assegno' appunto il numero 1 perche' secondo le intenzioni degli inventori non ci sarebbe stata piu' la necessita' di inventare od utilizzare un altro linguaggio. Questo era il numero 1!
Era il linguaggio ritenuto perfetto. Ho cercato (pochino, per la verita') le parole esatte pronunciate a suo tempo, ma non le ho trovate.
Ovviamente dovrei suggerirti di imparare il PL/1, ma come avrai capito non e' andata proprio cosi'. Era probabilmente buono per quei tempi...
High Flying
Sottovento
giannola
04-11-2006, 11:57
Dai via...il VB6 ha un supporto agli oggetti penoso :eek: Lo definirei più un linguaggio procedurale con un framework ad oggetti e nemmeno molto elegante...
Per uno che inizia questo non può che essere un vantaggio...
vabbè io intendo il visual basic.net ;)
Il vb6 lo usano i cavernicoli. :D
tomminno
04-11-2006, 14:43
vabbè io intendo il visual basic.net ;)
Il vb6 lo usano i cavernicoli. :D
I cavernicoli e buona parte delle aziende italiane (purtroppo) grazie alla diffusissima conoscenza informatica che impera in Italia.
Secondo me se uno deve cominciare a studiare un linguaggio nell'ambiente .NET quello è il C#, per lo meno è un linguaggio sano e con ambizioni multipiattaforma.
Cito il libro non per dire che l'ho letto (che spero proprio non gliene freghi niente a nessuno) ma perchè è più che possibile che altri parlino di branch in un senso diverso. Ecco, non parlo di un branch che mi sono inventato stamattina :D. Non mi riesce difficile immaginare che "branch", nel senso di ramificazione, sia anche un'invocazione di procedura. Mi chiedo però se abbia un senso parlare di predizione per un "branch incondizionato": che c'è da predire? Il flusso di esecuzione passerà sempre di lì: se no sarebbe condizionato. allora, ripeto facendo aderire le nostre terminologie: lasciamo perdere i branch e parliamo di salti. in linea teorica non è possibile prevedere l'esito di un salto condizionato perché non si possono conoscere i valori dei flag subito prima di esso, mentre al contrario è possibile conoscere l'esito di un salto incondizionato (ovviamente :p). perciò la CPU, nel fare il prefetch delle istruzioni al fine di non lasciare mai vuoti stadi della pipeline, se incontra un'istruzione CALL o JMP sa dove continuare il prefetch (oddio, magari nel caso di CALL ci vorrà parecchio lavoro per capirlo con esattezza, e così diversi stadi andranno comunque "sprecati", ma alla fine ci arriva), ma se incontra un Jcc no. questo in linea teorica.
di fatto però sappiamo anche che esistono meccanismi di branch prediction che possono prevedere l'esito di un Jcc; ma basta poco per "sputtanarli" (catena di if abbastanza grande).
I cavernicoli e buona parte delle aziende italiane (purtroppo) che è dire lo stesso
grazie alla diffusissima conoscenza informatica che impera in Italia. eh ma che ci vuoi fare, all'Università preferiscono insistere molto su Calcolo e Fisica -.-'
Personalmente in genere mi sento di sconsigliare il Java poichè è interpretato, non sempre
L'analogo C di quello che hai scritto in C++ è: [cut...] no, non è quello perché il tuo codice C chiama entrambe le funzioni, il mio ne chiama una sola.
tomminno
04-11-2006, 15:10
eh ma che ci vuoi fare, all'Università preferiscono insistere molto su Calcolo e Fisica -.-'
L'università non deve sfornare programmatori.
A me ad ogni esame lo ripetevano che il compito di un ingegnere non è fare il programmatore, salvo poi dover scrivere un programma per passare parte dell'esame e trovarmi di fronte a gente che di programmazione ne sapeva meno di me. Se si è fortunati non si diventa programmatori.
In ogni caso solo ai primi anni si insiste su matematica e fisica.
no, non è quello perché il tuo codice C chiama entrambe le funzioni, il mio ne chiama una sola.
Ma porca miseria, ma sarai tremendo!!!? :D
Ho evidenziato "invoke(fun f)" apposta per dire che il succo sta lì e tu mi vai a pigliare il main. Togli il main, che differenza c'è tra "invoke(fun f)" e "IfChainedNotAnymoreFunction(Class *Object)"?
Nessuna, a mio certo modesto giudizio. E possiamo dire, allora, che questo sia un esempio d'uso della programmazione orientata agli oggetti? Certamente no. E' un caso di eliminazione di una catena di if che va benissimo, è meravigliosa, ma non è una caratteristica della prospettiva orientata agli oggetti.
Credo che sia una specie di "scarto di produzione". Come dire: "hey, in un linguaggio orientato agli oggetti si può fare questo, quello e quell'altro e...toh, si può fare anche questo, come in C".
Per rispondere ad altri, non credo che queste siano discussioni off-topic: se si parla dei linguaggi del futuro è necessario parlare di quello che abbiamo in mano oggi.
giannola
04-11-2006, 17:21
Per rispondere ad altri, non credo che queste siano discussioni off-topic: se si parla dei linguaggi del futuro è necessario parlare di quello che abbiamo in mano oggi.
allora cominciamo a parlare anche di programmazione ad aspetti. ;)
Personalmente affrontai la questione degli aspetti un cinque o sei anni fa con AspectJ. Ricordo che allora la cosa sembrava grandiosa ma nessuno riusciva a capire se ci si potesse fare qualcos'altro oltre al monitoraggio esterno dei comportamenti di un sistema.
Poi, complice un rinnovato interesse per l'orientamento agli oggetti, non ho più approfondito la questione. Non so a che punto siamo oggi per cui se dicessi qualcosa sugli aspetti direi sicuramente una cialtronata. Prudentemente, evito :D.
Oh, ma voi quando programmate pensate alla branch prediction?? :eek:
A questo punto programmate direttamente in assembler.
Io personalmente penso a risolvere i problemi del dominio, non quelli del processore...
Comunque voi fate un po' come vi pare :D
jappilas
04-11-2006, 19:05
Oh, ma voi quando programmate pensate alla branch prediction?? :eek:
A questo punto programmate direttamente in assembler.
Io personalmente penso a risolvere i problemi del dominio, non quelli del processore...
si può programmare a oggetti e al tempo stesso usare tecniche che riducano il numero di indirezioni e quello delle diramazioni condizionate in successione
una volta risolti i problemi del dominio, ma anche nel mentre, ci si può dedicare a rendere il codice più efficiente (o più leggibile)
;)
Oh, ma voi quando programmate pensate alla branch prediction?? :eek:
A questo punto programmate direttamente in assembler.
Io personalmente penso a risolvere i problemi del dominio, non quelli del processore...
Averlo il tempo per pensare a certe cose... :D
mad_hhatter
04-11-2006, 22:41
beh un problema da risolvere può prevedere non solo requisiti funzionali ma anche vincoli temporali da rispettare oppure le alaborazioni che il nostro programma deve svolgere possono essere cpu-intensive e richiedere molto tempo. In entrambi i casi, tutto il tempo risparmiabile va risparmiato...
risolvere il problema è solo una parte della soluzione :sborone: (cavolo che frase! :D )
Lo dico all'inizio e facciamo finta che sia scritto prima di ogni affermazione: PER ME.
Io non credo che si possa "programmare ad oggetti" usando qualsivoglia tecnica volta a un fine diverso dall'esatta rappresentazione del fenomeno osservato o immaginato. Non c'è ottimizzazione o architettura nella prospettiva orientata agli oggetti: c'è il fenomeno e c'è la sua rappresentazione che deve essere "leggibile" se con ciò intendiamo "intelligibile".
Non significa certo che non si possa sapere come funziona un calcolatore, anzi. Sono anche questioni affascinanti. Ma come funziona un calcolatore è, per un programma orientato agli oggetti, assolutamente irrilevante e tenerne conto durante la descrizione del fenomeno è probabilmente dannoso, al pari di un vetro deforme che, posto tra l'osservatore e ciò che è osservato, genera una percezione distorta dell'obiettivo.
Ma tanto io sono matto :D.
mad_hhatter
04-11-2006, 23:09
non sei matto, solo che personalmente non sono del tutto d'accordo con quanto hai detto, anche se in parte è condivisibile.
il fatto che la programmazione a oggetti esista per permettere di descrivere un fenomeno dal punto di vista concettuale piuttosto che operativo è innegabile e porta moltissimi vantaggi in termini di espressività. C'è però da dire che la progettazione e implementazione di un software non sono processi mononolitici ma avvengono su piu livelli e in varie fasi. nulla impedisce di concepire un software pensando agli oggetti o ai concetti che descrivono il fenomeno in sè in modo del tutto astratto e svincolato dalla piattaforma. Ma il fatto che poi tali concetti andranno implementati implica già il dover effettuare delle decisioni sul come implementare le cose. E solitamente le soluzioni a disposizione sono molteplici. E' normale che la scelta venga fatta in base a determinati criteri e metriche qualitative, alcune delle quali possono essere, a seconda dei requisiti, di tipo prestazionale (in termini di tempo e/o di spazio). Non c'è contraddizione tra la OOP e un certo grado di analisi e previsione dei meccanismi di basso livello implicati da una certa porzione di codice
jappilas
04-11-2006, 23:23
Lo dico all'inizio e facciamo finta che sia scritto prima di ogni affermazione: PER ME.
Io non credo che si possa "programmare ad oggetti" usando qualsivoglia tecnica volta a un fine diverso dall'esatta rappresentazione del fenomeno osservato o immaginato. Non c'è ottimizzazione o architettura nella prospettiva orientata agli oggetti: c'è il fenomeno e c'è la sua rappresentazione che deve essere "leggibile" se con ciò intendiamo "intelligibile".
Non significa certo che non si possa sapere come funziona un calcolatore, anzi. Sono anche questioni affascinanti. Ma come funziona un calcolatore è, per un programma orientato agli oggetti, assolutamente irrilevante e tenerne conto durante la descrizione del fenomeno è probabilmente dannoso, al pari di un vetro deforme che, posto tra l'osservatore e ciò che è osservato, genera una percezione distorta dell'obiettivo.
Ma tanto io sono matto :D.
non sei matto, semplicemente concepisci gli oggetti come uno strumento di modellizzazione della soluzione informatica sul problema concreto
personalmente, facevo lo stesso fino a poco tempo fa... poi ho iniziato a fare pratica con Java, e quando ancora "il" fek era con noi (in questo forum), a studiare design pattern con cui avevo poca dimestichezza
Probabilmente questo mi ha definitivamente corrotto, nel senso di farmi cambiare prospettiva sul modo di pensare una soluzione informatica, rendere il mio modo di pensare un tantino più "disaccoppiato" di prima, e a convincermi che gli oggetti siano entità al solo servizio della visione del sw designer, che le plasmerà a seconda del grado di astrazione di cui è capace... :stordita:
Ho evidenziato "invoke(fun f)" apposta per dire che il succo sta lì e tu mi vai a pigliare il main. Togli il main, che differenza c'è tra "invoke(fun f)" e "IfChainedNotAnymoreFunction(Class *Object)"? bene, adesso hai capito i vantaggi delle funzioni virtuali: realizzano implicitamente un sistema di puntatori a funzioni che puoi sfruttare creando design molto carini. però voglio anche assicurarmi che tu abbia capito cosa sottintendevo nei miei due esempi di codice nei main che ho omesso.
nell'esempio C il main "istanziava" due struct di tipo CLASS e su ciascuna di esse faceva una scelta per settare un campo Type. successivamente su ciascuna di esse richiamava la IfChainedFunction, la quale faceva per ogni chiamata un'altra scelta, quindi in totale 4 scelte; il numero di if eseguiti però non era neanche uguale a 4, ma aumentava in funzione del numero di OBJTYPE_XXX dichiarati. ed infine considera che c'era anche la gestione del caso dell'invalid object type.
il codice C++ invece nel main istanzia due diverse classi effettuando così una prima scelta (sceglie quando istanziare Class1 e quando Class2). dopodiché chiama IfChainedNotAnymoreFunction, la quale ora non effettua più nessuna scelta.
morale della favola - numero di if della versione C: 2 + N + 1. numero di if della versione C++: 2. a parità di scelte nel main, la IfChainedXxxFunction del codice C++ vince. capito?
Nessuna, a mio certo modesto giudizio. E possiamo dire, allora, che questo sia un esempio d'uso della programmazione orientata agli oggetti? Certamente no. E' un caso di eliminazione di una catena di if che va benissimo, è meravigliosa, ma non è una caratteristica della prospettiva orientata agli oggetti. no, infatti chi l'ha mai detto: voleva molto modestamente essere un esempio di buona pratica di programmazione che fa uso di OOP.
La lettura di Design Pattern della banda bassotti (aka Gang Of Four) è stata la bottiglia che ha varato la nave della follia su cui veleggio. Un'ottima idea, uno che non l'ha capita ed un best-seller: sono gli ingredienti del disastro a cui è approdato l'orientamento agli oggetti.
Chi ha fondato l'orientamento agli oggetti non aveva le capacità per comunicarlo. E chi ha avuto le capacità di diffonderlo non l'aveva capito. A volte la storia ti prende semplicemente per il :ciapet:
La lettura di Design Pattern della banda bassotti (aka Gang Of Four) è stata la bottiglia che ha varato la nave della follia su cui veleggio. Un'ottima idea, uno che non l'ha capita ed un best-seller: sono gli ingredienti del disastro a cui è approdato l'orientamento agli oggetti.
Chi ha fondato l'orientamento agli oggetti non aveva le capacità per comunicarlo. E chi ha avuto le capacità di diffonderlo non l'aveva capito. A volte la storia ti prende semplicemente per il :ciapet:
Ma tanto io sono matto :D. :read:
EDIT: quest'ultima me la metto in signa :rotfl:
omissis..voleva molto modestamente essere un esempio di buona pratica di programmazione che fa uso di OOP
Niente, non c'è verso. Io parlo cinese, tu arabo e siamo entrambi sordi. Abbiamo evidenti e insormontabili difficoltà di comunicazione.
Niente, non c'è verso. Io parlo cinese, tu arabo e siamo entrambi sordi. Abbiamo evidenti e insormontabili difficoltà di comunicazione. kidaskdn ou ahdewj, :read: asjdja aPS AID jfuhed? defjew. :O
asjkdhansa, andildnsda. :doh: :mc:
adsjand sn. caksij?
jappilas
05-11-2006, 12:35
La lettura di Design Pattern della banda bassotti (aka Gang Of Four) è stata la bottiglia che ha varato la nave della follia su cui veleggio. Un'ottima idea, uno che non l'ha capita ed un best-seller: sono gli ingredienti del disastro a cui è approdato l'orientamento agli oggetti.
uhm, non mi sembrava che la OOP facesse Titanic come secondo nome... :p :D
tomminno
05-11-2006, 13:13
Non significa certo che non si possa sapere come funziona un calcolatore, anzi. Sono anche questioni affascinanti. Ma come funziona un calcolatore è, per un programma orientato agli oggetti, assolutamente irrilevante e tenerne conto durante la descrizione del fenomeno è probabilmente dannoso, al pari di un vetro deforme che, posto tra l'osservatore e ciò che è osservato, genera una percezione distorta dell'obiettivo.
Ma tanto io sono matto :D.
Però nella programmazione ad oggetti si parla sempre di cosa fa una determinata classe non come la fa, anche nell'UML mica specifichi come deve essere realizzato un metodo.
Se vuoi ottimizzare il codice devi scendere al livello di come viene implementata una determinata operazione e questo è ad un livello più basso della programmazione ad oggetti, che è una strutturazione di più alto livello.
Nessuno ti vieta di strutturare ad oggetti e implementare all'interno tutto in assembly
Avete mai letto "The Early History of Smalltalk", di Alan Kay? Parla delle radici dell'orientamento agli oggetti. Diamine, Alan Kay è quelle radici. Parla dell'idea di prendere un calcolatore e renderlo uno strumento per l'acquisizione di conoscenza. Non conoscenza del calcolatore ma conoscenza tramite il calcolatore.
Ciò che oggi si dice dell'orientamento agli oggetti altro non è che un tipo di programmazione procedurale unicamente "differente" in ciò, che anzichè parlare di sequenze parzialmente ordinate di operazioni su registri di memoria trattiamo di sequenze parzialmente ordinate di meta-operazioni su meta-registri, dove ciò che dichiara l'operazione è il metodo e ciò che dichiara il registro è un oggetto.
Io non dico che sia sbagliato: francamente è più quello di cui non ho una spiegazione che non ciò che riesco a motivare. Ma so che è capitato qualcosa all'idea originale di orientamento agli oggetti che ne ha fatto qualcosa di diverso. A un certo punto deve essere cessata la discussione intorno alla conoscenza e ne è iniziata una riguardo all'interpretazione. L'effetto, curioso, è che i termini dell'orientamento agli oggetti sono stati costretti nell'alveo delle prospettive precedenti.
Come se l'idea nuova, applicata alle cose vecchie, anzichè rinnovare l'idea delle cose sia stata fatta invecchiare da esse.
LupettoOne
06-11-2006, 13:35
Raga dopo l'installazione del Visual Studio 2005 mi dice se voglio installare il MSDN Library e del Verifica Della Service Release!
Il MSDN Library sarebbero le librerie giusto? Quindi mi conviene installarle? Grazie in anticipo!
MSDN Library è la documentazione, la trovi anche online al sito http://msdn.microsoft.com/library/default.asp quindi secondo me non ti conviene installarla in locale (a meno che non hai il 56k e quindi il sito di MSDN potrebbe risultarti pesante, o a meno che non hai una tariffa a tempo). piuttosto ciò che probabilmente vorrai installare (visto che molti se ne scordano) è il Platform SDK, cioè il kit necessario a programmare in Win32.
TorpedoBlu
04-05-2007, 09:45
ragazzi, vi vedo esperti ed attenti.
ho un quesito per voi :D
devo fare una tesi di laurea su la programmazione ad aspetti ed in particolare alla sua applicazione nel WEB.
la traccia è questa:
Aspects on Web
obiettivo: stato dell'arte della AOP sul Web
parte teorica:
o panoramica sulla AOP in OO e dettagli su ASPECTJ (con esempi)
o panoramica su AOP e Web (letteratura e software) in particolare per PHP
parte pratica:
o applicazione dei software esistenti (verifica delle varie implementazioni)
o confronto tra implementazioni
o (se si trova una implementazione funzionante) provarla su una applicazione specifica
- es. il calcolo di metriche software (tipo: codice eseguito, classi, funzioni, parametri, files, etc.-dipende da implementazione-)
o (se vale la precedente) si possono implementare le metriche in due sistemi: tradizionale e AOP e confrontarli
Ora sono abbastanza estraneo a Eclipse e non so dove partire per i vari Framework Java. C'è qualcuno che può mostrarmi la via da percorrere e ha qualche consiglio?? sono volenteroso, ho cercato su web, ma ci sono o articoli di poche righe o mattoni di centinaia di pagine. Prima di leggere le migliaia di pagine se qualcuno ha dei saggi consigli, io umile universitario senza esperienza vorrei ascoltare... grazie!
Professionalmente non l'ho mai usata nè l'ho mai vista usare. Ma questo non significa che l'AOP sia un esercizio di astratta utilità. E' ancora molto giovane. Basti pensare al fatto che la diffusione della programmazione OO ha richiesto 40 anni e quella funzionale... be' non so se si sia mai diffusa :D. Comunque sia, la natura ha i suoi tempi.
TorpedoBlu
04-05-2007, 10:00
ragazzi, vi vedo esperti ed attenti.
ho un quesito per voi :D
devo fare una tesi di laurea su la programmazione ad aspetti ed in particolare alla sua applicazione nel WEB.
la traccia è questa:
Aspects on Web
obiettivo: stato dell'arte della AOP sul Web
parte teorica:
o panoramica sulla AOP in OO e dettagli su ASPECTJ (con esempi)
o panoramica su AOP e Web (letteratura e software) in particolare per PHP
parte pratica:
o applicazione dei software esistenti (verifica delle varie implementazioni)
o confronto tra implementazioni
o (se si trova una implementazione funzionante) provarla su una applicazione specifica
- es. il calcolo di metriche software (tipo: codice eseguito, classi, funzioni, parametri, files, etc.-dipende da implementazione-)
o (se vale la precedente) si possono implementare le metriche in due sistemi: tradizionale e AOP e confrontarli
Ora sono abbastanza estraneo a Eclipse e non so dove partire per i vari Framework Java. C'è qualcuno che può mostrarmi la via da percorrere e ha qualche consiglio?? sono volenteroso, ho cercato su web, ma ci sono o articoli di poche righe o mattoni di centinaia di pagine. Prima di leggere le migliaia di pagine se qualcuno ha dei saggi consigli, io umile universitario senza esperienza vorrei ascoltare... grazie!
ma tu cosa mi consigli di vedere per iniziare le mie ricerche?? non sapete se ci sono delle applicazioni concrete da analizzare? dove posso sbattere la testa? di libri sulla teoria dell'AOP ne ho recuperati parecchi, ma nessuno mi fa vedere il succo (anche se poco) di qualcosa di applicato.
Prova Spring. Da una rapida ricerca in rete mi pare che usi l'AOP, almeno per una parte. E' un insieme di librerie per la produzione di applicazioni Java EE. Forse qualcuno che programma in ambiente Java EE potrà dirti di più.
http://www.infoq.com/articles/spring-2-intro
TorpedoBlu
04-05-2007, 10:28
si ho visto praticamente che devo guardare
-spring
-jboss
-structs
-ejb
ed in generale AspectJ
il problema è che non posso certo impararli (è una tesi non un martirio) ma capire chi è più avanti ed in particolare chi ha sviluppato qualcosa per il Web e magari un esempio concreto di una situazione dove AOP è efficace (o come risultato, o in fase di sviluppo per la cortezza del linguaggio, o in fase di manutenzione)
il tutto condito da esempi sia di codice che di disegno (UML)
^TiGeRShArK^
04-05-2007, 10:36
se non sbaglio le piattaforme EE da te citate usano AOP per fare del code injection quando vengono scatenati determinati eventi sul ciclo di vita dei Beans.
Per AspectJ c'è un plugin per eclipse e tra l'altro qualche tempo fa l'avevo anche installato..
solo che non l'ho mai usato :p
TorpedoBlu
04-05-2007, 10:38
se non sbaglio le piattaforme EE da te citate usano AOP per fare del code injection quando vengono scatenati determinati eventi sul ciclo di vita dei Beans.
Per AspectJ c'è un plugin per eclipse e tra l'altro qualche tempo fa l'avevo anche installato..
solo che non l'ho mai usato :p
si esatto, il problema è trovare qualcosa di concreto da portare, perchè a me esempi di come sfruttare AOP nel web mica mi vengono (sarei gia un professionista)..... nessuno ha esperienze??
^TiGeRShArK^
04-05-2007, 14:31
c'è un esempio di come sfruttare AOP x il logging:
http://www.devx.com/Java/Article/30799
qui c'è una comparazione dell'AOP puro e degli interceptor usati in EJB 3.
http://blogs.codehaus.org/people/avasseur/archives/001002_ejb_3_and_aop_the_ejb_interceptor_dilemna.html
da notare la "cattiva" implementazione odierna che sfrutta pesantemente la reflection ed ha un forte impatto prestazionale.
TorpedoBlu
04-05-2007, 14:49
da notare la "cattiva" implementazione odierna che sfrutta pesantemente la reflection ed ha un forte impatto prestazionale.
puoi spiegare questa cosa in maniera più semplice? non ho idea cosa sia la reflection. grazie
e grazie per i 2 link ora li guardo!
Professionalmente non l'ho mai usata nè l'ho mai vista usare. Ma questo non significa che l'AOP sia un esercizio di astratta utilità.
L'AOP me la sono studiata poco, per cui non ho molta competenza in materia, ma francamente non mi sembra niente di innovativo, soprattutto per chi e' gia' abituato a linguaggi dinamici e a un po' di metaprogrammazione. Certo che se poi voglio farlo in C++ o Java (condito pure con annotazioni in XML ) :mbe:.
E' ancora molto giovane. Basti pensare al fatto che la diffusione della programmazione OO ha richiesto 40 anni e quella funzionale... be' non so se si sia mai diffusa :D. Comunque sia, la natura ha i suoi tempi.
Piu' facile che faccia la fine di quella funzionale, nel senso che di per se' non si e' diffusa molto ma ha influenzato gli altri tipi di programmazione. Anzi, diverse delle features che si stanno inserendo ultimamente in linguaggi di ampia diffusione (C# ad esempio) sono tipicamente funzionali.
TorpedoBlu
06-05-2007, 13:59
L'AOP me la sono studiata poco, per cui non ho molta competenza in materia, ma francamente non mi sembra niente di innovativo, soprattutto per chi e' gia' abituato a linguaggi dinamici e a un po' di metaprogrammazione. Certo che se poi voglio farlo in C++ o Java (condito pure con annotazioni in XML ) :mbe:.
Piu' facile che faccia la fine di quella funzionale, nel senso che di per se' non si e' diffusa molto ma ha influenzato gli altri tipi di programmazione. Anzi, diverse delle features che si stanno inserendo ultimamente in linguaggi di ampia diffusione (C# ad esempio) sono tipicamente funzionali.
va bbo, allora cmq per cercare di capire come e cosa guardare per il Web l'unica cosa è capire cosa sono i framework (che ancora non ho capito nel concreto) e come usano AOP.
Sto provando a capire come installare AspectJ su Eclipse e capire come si usa...ma è dura
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.