View Full Version : [Vari]I linguaggi che più avete odiato.
Quali sono i linguaggi di programmazione più brutti con cui avete avuto a che fare?
La mia personale classifica dei "mostri" è la seguente:
1)Perl
2)Visual Basic 6.0
3)Bash Script
4)Php
my humble opinion: PHP andrebbe messo MOLTO PRIMA di Bash e soprattutto MOLTO PRIMA di VB6.
io sono dell'idea che VB6 non sia stato capito: per capire a fondo cos'era e qual'era il suo scopo di vita bisognava conoscere le varie tecnologie sottostanti, le famose tecnologie "attive" (ActiveX, ActiveScripting, ecc.), ed eventualmente anche quelle ancora piu sottostanti, cioé COM.
VB6 era veramente un bel software, e fino a poco tempo fa (quando ancora ero ignorante) sarei stato il primo a dire che era un obbrobbrio mal riuscito, una grossa svista dall'immeritato successo che la Microsoft continuava ottusamente a portare avanti, sarei stato il primo a tuonare contro i suoi stravolgimenti della programmazione a oggetti; poi per fortuna ho capito e ho amato.
my humble opinion: PHP andrebbe messo MOLTO PRIMA di Bash e soprattutto MOLTO PRIMA di VB6.
io sono dell'idea che VB6 non sia stato capito: per capire a fondo cos'era e qual'era il suo scopo di vita bisognava conoscere le varie tecnologie sottostanti, le famose tecnologie "attive" (ActiveX, ActiveScripting, ecc.), ed eventualmente anche quelle ancora piu sottostanti, cioé COM.
VB6 era veramente un bel software, e fino a poco tempo fa (quando ancora ero ignorante) sarei stato il primo a dire che era un obbrobbrio mal riuscito, una grossa svista dall'immeritato successo che la Microsoft continuava ottusamente a portare avanti, sarei stato il primo a tuonare contro i suoi stravolgimenti della programmazione a oggetti; poi per fortuna ho capito e ho amato.
Io purtroppo ci ho dovuto mettere le mani sopra quando già esistevano tecnologie migliori come .net quindi è stato odio a prima vista. Fortunatamente
la mia esperienza con VB6 è durata poco. Non conosco abbastanza bene VB6 per poter controbattere le tue argomentazioni......In ogni caso l'intento del topic non era determinare i linguaggi di programmazione peggiori con criteri oggettivi ma solo riportare eventuali esperienze negative.
Php molto prima di bash? Detesto php ma Bash è oltre i limiti della perversione umana..
1) Powerscript
2) VBA
3) php
Poi ci sono i linguaggi che non mi piacciono più ma contro i quali non provo odio.... tipo perl o java...
C++ (dopo aver conosciuto Java): come andare in carrozza dopo essere salito su una Mercedes...
cdimauro
24-07-2009, 21:42
1) Perl
2) PHP
3) Bash
C++ (dopo aver conosciuto Java): come andare in carrozza dopo essere salito su una Mercedes...
Vero. Però la "bruttezza" del c++ è dovuta a ben due buone ragioni:
1) Permette di lavorare a basso livello
2) E (quasi) un super-insieme del C.
Partendo da questi presupposti non penso che sarebbe stato facile creare un linguaggio molto più semplice ed elegante.....Insomma c++ ha la sua ragione di esistere.
Nessuno ha mai avuto esperienza con cobol? Me ne hanno parlato decisamente malissimo....
||ElChE||88
24-07-2009, 21:59
1) Perl
2) Perl
3) Perl
1) Powerscript
2) VBA
3) php cos'é Powerscript?
che strana scelta poi VBA... cos'é che non ti piace di VBA? la sintassi é la stessa di Visual Basic 6, cambiano solo gli oggetti esposti (oggetti specifici di Office nel caso di VBA, tutti gli ActiveX installati sulla macchina nel caso di VB6).
interessante notare come PHP appaia in tutte le classifiche :asd:
C++ (dopo aver conosciuto Java): come andare in carrozza dopo essere salito su una Mercedes... ci sono cose che in Java non puoi fare, e non si tratta dei buffer overrun (parlo di cose utili). per esempio Java non ha l'ereditarietá multipla, non ha l'operator overloading, non ha i puntatori a funzioni (presenti anche in C# sotto forma dei delegates), non ha le lambda expressions (presenti nella nuova revisione del C++) e non permette di realizzare scoped objects togliendoti quindi quel controllo finissimo che hai in C++ sulla deallocazione delle risorse allocate dinamicamente; puoi scegliere uno tra alcuni algoritmi predefiniti di garbage collection ma non é la stessa cosa.
parlando invece delle API é tutt'altra questione: l'armamentario messo a disposizione da Java é infinitamente piu vasto e potente delle quattro cacchiate che ti da il C++ (classi di I/O, collection classes e poco altro), ma se il C++ (come spesso accade) viene abbinato a qualche framework é tutta un'altra musica.
Vero. Però la "bruttezza" del c++ è dovuta a ben due buone ragioni:
1) Permette di lavorare a basso livello non é del tutto vero: non é quasi mai possibile usare il C++ per scrivere drivers per Windows.
1) Perl
2) Perl
3) Perl 4) PHP :D
ti prego, non spezzare la continuitá che era venuta a crearsi :asd:
||ElChE||88
24-07-2009, 22:11
4) PHP :D
ti prego, non spezzare la continuitá che era venuta a crearsi :asd:
Ci ho lavorato solo per qualche giorno, posso metterlo in lista comunque?
Ricordo che rimasi parecchio impressionato da alcune """feature""" del linguaggio. :asd:
morskott
24-07-2009, 22:36
Bhe, direi che (personalmente) il maggior obbrobrio di cui mi sia (cercato con scarso successo di) sporcato le mani è quella lettera dell'alfabeto....si...il C!!
Sarà che son partito dal Pascal (ah che tempi alle superiori!!!) per poi approdare direttamente a Java (il mio preferito) interessandomi nel contempo al C# (per quanto visto molto bello) e dovendomi sorbire quell'obbrobrio per qualche tesina (forse son un po esagerato, ma provate a far una tesina in C che dopo un anno devi ancora riuscire a provarla (per una non spiegata impossibilità/incapacità di chiamare una syscall personale da usermode)!!).
Vabbeh, ho un po divagato!!
Vero. Però la "bruttezza" del c++ è dovuta a ben due buone ragioni:
1) Permette di lavorare a basso livello
2) E (quasi) un super-insieme del C.
Partendo da questi presupposti non penso che sarebbe stato facile creare un linguaggio molto più semplice ed elegante.....Insomma c++ ha la sua ragione di esistere.
Storicamente immagino che c++ sia stato un notevole passo in avanti rispetto al C (parlo rispetto all'OO) e quindi gli riconosco assolutamente la ragione di esistere. Ma Java, che è venuto dopo, ha migliorato il c++ nei sui aspetti scomodi e antiquati, in maniera notevole. La comodità, la sicurezza, la tranquillità (e mettiamoci pure l'ottima documentazione) di programmare in Java non è paragonabile a quella del c++.
interessante notare come PHP appaia in tutte le classifiche :asd:
Nella mia non l'ho messo solo per non sparare sulla croce rossa. :D
ci sono cose che in Java non puoi fare, e non si tratta dei buffer overrun (parlo di cose utili). per esempio Java non ha l'ereditarietá multipla, non ha l'operator overloading, non ha i puntatori a funzioni (presenti anche in C# sotto forma dei delegates), non ha le lambda expressions (presenti nella nuova revisione del C++) e non permette di realizzare scoped objects togliendoti quindi quel controllo finissimo che hai in C++ sulla deallocazione delle risorse allocate dinamicamente; puoi scegliere uno tra alcuni algoritmi predefiniti di garbage collection ma non é la stessa cosa.
parlando invece delle API é tutt'altra questione: l'armamentario messo a disposizione da Java é infinitamente piu vasto e potente delle quattro cacchiate che ti da il C++ (classi di I/O, collection classes e poco altro), ma se il C++ (come spesso accade) viene abbinato a qualche framework é tutta un'altra musica.
Per l'ereditarietà multipla si può ovviare con le interfacce. Da studente onestamente non ho mai sentito la mancanza di puntatori a funzioni e overloading degli operatori.
Sul controllo finissimo delle deallocazione delle risorse, per la mia piccolissima esperienza (che è stata sufficiente a farmi intervenire in questo thread :asd:) è stato più un :muro: che altro: stesso progetto, per un esame, da implementare in c++ e in Java. Per deallocare correttamente oggetti che non venivano più referenziati non bastava la solita free in quanto chi creava l'oggetto non era chi lo distruggeva. Google consigliava smart pointer, ma non erano sufficienti. Alla fine ho usato un garbage collector (mentre Java se la rideva...) ovviamente non standard.
In Java non mi sono neanche posto il problema. :D
Se devo sporcarmi le mani preferisco il C, che apprezzo nel suo ambito. Se voglio usare gli oggetti Java.
Ovviamente il tutto molto imho e molto "gusti personali".
Per l'ereditarietà multipla si può ovviare con le interfacce. non é la stessa cosa, é un workaround lungo ed operoso. tra l'altro (mi viene in mente solo ora) altra cosa molto antipatica, almeno per me, é che in Java le classi ereditano tutto pubblicamente; in C++ invece é possibile ereditare con specificatori di visibilitá (private, protected, public).
Da studente onestamente non ho mai sentito la mancanza di puntatori a funzioni e overloading degli operatori. gli operatori sono concettualmente analoghi ai metodi, quindi si tratta di una pura comoditá sintattica :D, peró sempre una comoditá é.
per quanto riguarda i puntatori a funzioni, io invece ne sento la mancanza eccome: in Java non posso neanche implementare uno stupidissimo metodo che calcoli la derivata di una funzione reale arbitraria, perché non posso passargli quella funzione; devo per forza sfruttare il puntatore a metodo implicito rappresentato dalla vtable di una classe. i puntatori a funzioni non sono affatto l'ennesima porcheria di derivazione C, anzi nella programmazione funzionale un concetto del tutto analogo, la chiusura, é di importanza fondamentale (ed é supportato anche da C# nella forma di delegati anonimi).
Sul controllo finissimo delle deallocazione delle risorse, per la mia piccolissima esperienza (che è stata sufficiente a farmi intervenire in questo thread :asd:) è stato più un :muro: che altro: stesso progetto, per un esame, da implementare in c++ e in Java. Per deallocare correttamente oggetti che non venivano più referenziati non bastava la solita free in quanto chi creava l'oggetto non era chi lo distruggeva. Google consigliava smart pointer, ma non erano sufficienti. Alla fine ho usato un garbage collector (mentre Java se la rideva...) ovviamente non standard.
In Java non mi sono neanche posto il problema. :D é chiaro che per programmi non critici (che sono la stragrande maggioranza) i garbage collectors di Java vanno benissimo, ma ci sono programmi in cui vorresti evitare che il GC entrasse in azione in determinati momenti. in C++ usando degli scoped objects (magari anche una sola classe, sotto forma di template) puoi scrivere un GC personalizzato in pochi minuti mantenendo il controllo totale sulla scelta dei momenti opportuni per la deallocazione delle risorse dinamiche (ivi inclusi blocchi allocati con new). se invece non ti serve questo controllo eccezionale puoi usare una dei fottiliardi di classi di smart pointers scritte fino ad oggi, incluse auto_ptr delle librerie standard oppure CHeapPtr di ATL; questo equivale a dire che neanche in C++ devi porti il problema della deallocazione della memoria dinamica, basta che dichiari il tuo puntatore come auto_ptr<int> anziché int*, per esempio.
infine, se la risorsa dinamica di cui devi gestire la deallocazione non é un blocco di memoria dell'heap (ma é, ad esempio, un HANDLE Win32) allora puoi scrivere in pochissimo tempo una tua smart class, ma prima controlla che qualche framework non ne abbia giá (MFC ed ATL ad esempio offrono classi per wrappare qualunque HANDLE ti venga in mente).
aggiungo che il fatto che tu abbia usato la free in C++ mi suggerisce una certa ignoranza in materia da parte tua; in C++ si usano new e delete.
Se devo sporcarmi le mani preferisco il C, che apprezzo nel suo ambito. Se voglio usare gli oggetti Java. mentre se vuoi usare un linguaggio potente usi C++. il C++ é un linguaggio di enorme complessitá che offre costrutti molto sofisticati; impararlo approfonditamente richiede tempi notevoli ma una volta che l'hai fatto tuo puoi diventare molto produttivo perché puoi scrivere codice semanticamente sofisticato e quindi puoi fare di piu con meno righe di codice.
DanieleC88
24-07-2009, 23:44
ci sono cose che in Java non puoi fare, e non si tratta dei buffer overrun (parlo di cose utili). per esempio Java non ha l'ereditarietá multipla, non ha l'operator overloading, non ha i puntatori a funzioni (presenti anche in C# sotto forma dei delegates), non ha le lambda expressions (presenti nella nuova revisione del C++) e non permette di realizzare scoped objects togliendoti quindi quel controllo finissimo che hai in C++ sulla deallocazione delle risorse allocate dinamicamente; puoi scegliere uno tra alcuni algoritmi predefiniti di garbage collection ma non é la stessa cosa.
Ricordo male o non ci sono nemmeno i parametri opzionali in Java? :D
Per rispondere al thread: PIACCAPPI'! :D
cos'é Powerscript?
E' il linguaggio di scripting di Powerbuilder. Una cosa per cui Guantanamo dovrebbe essere riaperta, secondo me.
che strana scelta poi VBA... cos'é che non ti piace di VBA? la sintassi é la stessa di Visual Basic 6, cambiano solo gli oggetti esposti (oggetti specifici di Office nel caso di VBA, tutti gli ActiveX installati sulla macchina nel caso di VB6).
Ah, credo sia una mia personale idiosincrasia. VB e derivati mi fanno sanguinare gli occhi.
JavaScript
Dai... javascript non è malvagio come linguaggio in sè. Secondo me ha delle buone idee.
Il problema è il browser, DOM, implementazioni buggate...
Ricordo male o non ci sono nemmeno i parametri opzionali in Java? :D no, quelli ci sono. ecco la dichiarazione del metodo PrintStream.printf:
public PrintStream printf(String format, Object ... args);
all'interno del codice del metodo args é visto come un array di Object.
cdimauro
25-07-2009, 10:41
non é del tutto vero: non é quasi mai possibile usare il C++ per scrivere drivers per Windows.
Perché?
Dai... javascript non è malvagio come linguaggio in sè. Secondo me ha delle buone idee.
Io mi sono limitato a elencarne tre, ma il quarto se lo aggiudicherebbe sicuramente JavaScript che è un abominio.
Creare classi con JS è una cosa immonda. :muro:
Il problema è il browser, DOM, implementazioni buggate...
Qui però si parla del linguaggio, non delle implementazioni. :D
no, quelli ci sono. ecco la dichiarazione del metodo PrintStream.printf:
public PrintStream printf(String format, Object ... args);
all'interno del codice del metodo args é visto come un array di Object.
Credo si riferisse agli argomenti di default:
def Pippo(Topolino, Pluto = 'Il cane del topo'):
pass
Come ho fatto a dimenticare javascript?
Ma sopratutto quanto odio questa moda di voler spostare tutto sul web!!!!!!
Io mi sono limitato a elencarne tre, ma il quarto se lo aggiudicherebbe sicuramente JavaScript che è un abominio.
Creare classi con JS è una cosa immonda. :muro:
Va beh, è semplicemente una filosofia diversa.
http://en.wikipedia.org/wiki/Prototype-based_programming
Definirlo immondo perchè diverso (oltre a farmi venire in mente The Elephant Man :p) mi sembra esagerato. Se poi mi dici che ci sono linguaggi che implementato il suddetto stile in maniera più elegante (tipo Self o Io), allora sono d'accordo.
Qui però si parla del linguaggio, non delle implementazioni. :D
Si appunto, intendevo dire che secondo me il linguaggio in sè ha delle buone cose, ma le "piattaforme" sulle quali bisogna farlo girare lasciano spesso a desiderare.
Perché? sostanzialmente perché non hai lo stesso controllo che hai in C su come e dove viene generato il codice; per esempio non puoi prevedere in quali sezioni dell'eseguibile andrá a finire tutto il codice necessario ad eseguire una certa chiamata al driver proveniente dal kernel, e di conseguenza non sai quali sezioni devono essere rese pageable e quali devono essere residenti (é una cosa molto importante quando la chiamata proviene da un IRQL > DISPATCH_LEVEL); inoltre é necessario tenere presente alcune limitazioni come il ridotto spazio che hai sullo stack in kernel mode (ed é piuttosto difficile tenerne conto quando allochi oggetti anonimi temporanei) e l'assenza di una libreria necessaria all'uso delle eccezioni C++ (senza contare che l'uso di eccezioni C++ farebbe scempio dello stack limitato). é possibile invece (anzi, indispensabile) utilizzare un altro meccanismo di eccezioni, il SEH, che é molto piú lightweight al costo di essere un meccanismo molto piú approssimativo: quando un'eccezione SEH attraversa un blocco di codice non vengono chiamati i distruttori delle variabili locali, impedendoti cosí di usare qualunque tipo di smart object pena grossi leak.
qui trovi maggiori dettagli su tutta la questione del C++ in kernel mode:
http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx#EDE
SQL
So che non è un linguaggio di programmazione ma mi fa talmente schifo che lo metterei anche se questo fosse un post sull'animale più velenoso.
DanieleC88
25-07-2009, 11:58
no, quelli ci sono. ecco la dichiarazione del metodo PrintStream.printf:
public PrintStream printf(String format, Object ... args);
all'interno del codice del metodo args é visto come un array di Object.
E i valori di default? :)
EDIT: sì, esatto, è come dice cdimauro. Non è indispensabile, ma è una cosa abbastanza fastidiosa fare millemila overloading della stessa funzione per fare la stessa cosa che potresti fare con una riga di codice. :)
anonimizzato
25-07-2009, 11:58
JavaScript
*
PHP non lo trovo così osceno, forse perchè non ho grande esperienza con altri linguaggi.
Certo la differenza con Ruby la sto sentendo parecchio. :asd:
anonimizzato
25-07-2009, 12:01
Dai... javascript non è malvagio come linguaggio in sè. Secondo me ha delle buone idee.
Il problema è il browser, DOM, implementazioni buggate...
Javascript "wrappato" in framework con Prototype e JQuery è fantastico secondo me.
Come linguaggio "puro" purtroppo ho un supporto decisamente scadente sui vari browser.
E i valori di default? :) per quelli sei costretto ad usare l'overloading, che per fortuna non é un workaround eccssivamente lungo (é sufficiente che tutti i metodi chiamino la versione con piu parametri).
cdimauro
25-07-2009, 12:03
Va beh, è semplicemente una filosofia diversa.
http://en.wikipedia.org/wiki/Prototype-based_programming
Definirlo immondo perchè diverso (oltre a farmi venire in mente The Elephant Man :p) mi sembra esagerato. Se poi mi dici che ci sono linguaggi che implementato il suddetto stile in maniera più elegante (tipo Self o Io), allora sono d'accordo.
Non è la diversità che mi spaventa, ma la sintassi che personalmente trovo veramente orribile.
Si appunto, intendevo dire che secondo me il linguaggio in sè ha delle buone cose, ma le "piattaforme" sulle quali bisogna farlo girare lasciano spesso a desiderare.
Onestamente non lo trovo tanto bello. Per quello che fa, al suo posto avrei preferito (A)REXX.
sostanzialmente perché non hai lo stesso controllo che hai in C su come e dove viene generato il codice; per esempio non puoi prevedere in quali sezioni dell'eseguibile andrá a finire tutto il codice necessario ad eseguire una certa chiamata al driver proveniente dal kernel, e di conseguenza non sai quali sezioni devono essere rese pageable e quali devono essere residenti (é una cosa molto importante quando la chiamata proviene da un IRQL > DISPATCH_LEVEL); inoltre é necessario tenere presente alcune limitazioni come il ridotto spazio che hai sullo stack in kernel mode (ed é piuttosto difficile tenerne conto quando allochi oggetti anonimi temporanei) e l'assenza di una libreria necessaria all'uso delle eccezioni C++ (senza contare che l'uso di eccezioni C++ farebbe scempio dello stack limitato). é possibile invece (anzi, indispensabile) utilizzare un altro meccanismo di eccezioni, il SEH, che é molto piú lightweight al costo di essere un meccanismo molto piú approssimativo: quando un'eccezione SEH attraversa un blocco di codice non vengono chiamati i distruttori delle variabili locali, impedendoti cosí di usare qualunque tipo di smart object pena grossi leak.
qui trovi maggiori dettagli su tutta la questione del C++ in kernel mode:
http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx#EDE
Il SEH mi sembra specifico di Windows.
Per il resto e rimanendo fermi al solo linguaggio, non vedo perché il C dovrebbe permettere di specificare in quale tipo memoria (pageable o no) deveono stare codice e/o dati, e il C++ no. Mi sembrano dettagli non legati al linguaggio di per sé, quanto alle implementazioni.
Idem per lo stack.
Poi dobbiamo fare il topic sui linguaggi con cui è più piacevole programmare...
Già questo finirà a cazzotti entro due pagine, che vuoi fare, partire col secondo round a metà del primo? :D
Giù questo finirà a cazzotti entro due pagine, che vuoi fare, partire col secondo round a metà del primo? :D
Ah ah ....Io vedo che su certi ""argomenti"" siamo $tutti d'accordo:D
rеpne scasb
25-07-2009, 13:27
■
Ah ah ....Io vedo che su certi ""argomenti"" siamo $tutti d'accordo:D
E' il trappolone del sorriso, con la destra si stringe la mano mentre con la sinistra si cerca il coltello infilato nella cintura dietro la schiena.
A differenza di alcuni io adoro il php :D
Quelli che odio di più sono:
-Assembler
-Perl
cosa avete contro il perl e il bash script?
il perl permette di fare molti esperimenti unito al c. Sfruttare bufferoverflow con script bash + perl è semplicissimo.
Ad ogni modo, quello che odio veramente è L'assembly Intel x86, anche se risulta molto utile nelle chiamate di sistema.
DanieleC88
25-07-2009, 16:09
cosa avete contro il perl e il bash script?
il perl permette di fare molti esperimenti unito al c. Sfruttare bufferoverflow con script bash + perl è semplicissimo.
Be', IMHO se la "utilità" del Perl si limita a questo, se ne può benissimo fare a meno, è solo un insulto agli occhi. :D
Be', IMHO se la "utilità" del Perl si limita a questo, se ne può benissimo fare a meno, è solo un insulto agli occhi. :D
io ritengo che per l'utilizzo in ambito shell vada più che bene, altrimenti può benissimo essere rimpiazzato da altri linguaggi di scripting, Python in primis.
io ritengo che per l'utilizzo in ambito shell vada più che bene, altrimenti può benissimo essere rimpiazzato da altri linguaggi di scripting, Python in primis.
Bash è utile per fare script di una decina di righe e niente più. Passato quel limite il codice diventa veramente difficile da gestire se paragonato ad altri linguaggi. Ci sarebbe anche uno standard del linguaggio ma alla fine ogni shell ha il suo personale dialetto che può variare anche da una versione all'altra della stessa shell. Per non parlare delle prestazioni visto che praticamente ogni singolo comando di uno script è implementato da programmi esterni quindi la shell è costretta ad eseguire centinaia di fork anche per le cose più semplici.
Quelli che odio di più sono:
-Assembler di quale processore?
cosa avete contro il perl e il bash script?
il perl permette di fare molti esperimenti unito al c. Sfruttare bufferoverflow con script bash + perl è semplicissimo. sfruttare buffer overflow sulle macchine di oggi (dotate di NX bit) é impossibile; al massimo fai crashare il programma vulnerabile.
Ad ogni modo, quello che odio veramente è L'assembly Intel x86, anche se risulta molto utile nelle chiamate di sistema. nelle chiamate di sistema? :mbe:
Il SEH mi sembra specifico di Windows. io infatti stavo parlando di drivers per Windows.
Per il resto e rimanendo fermi al solo linguaggio, non vedo perché il C dovrebbe permettere di specificare in quale tipo memoria (pageable o no) deveono stare codice e/o dati, e il C++ no. letto il link?
per un linguaggio che offre costrutti semplici come il C, il modo in cui il codice viene generato é molto piu semplice da capire e controllare, per esempio non esistono costruttori e distruttori e quindi tutto il codice che verrá mai eseguito da una tua funzione si trova interamente all'interno di quella funzione e delle funzioni richiamate da essa; inoltre non esiste il discorso degli oggetti temporanei e quindi puoi valutare con precisione quanto spazio di stack stai usando solo contando i parametri e le variabili locali.
ti fa rabbrividire l'idea di dover fare simili assunzioni nella programmazione kernel-mode in Windows, oltre all'idea di dover usare il C e per giunta preferibilmente con uno specifico compilatore? pazienza, in Windows i driver si programmano cosi. per decidere in quale sezione (e quali memory flags deve avere quella sezione) mettere determinate funzioni devi circondarle con un paio di pragma specifiche del compilatore Microsoft.
Mi sembrano dettagli non legati al linguaggio di per sé, quanto alle implementazioni.
Idem per lo stack. pensala come ti pare, sta di fatto che non riuscirai mai con nessun compilatore a scrivere un driver per Windows in C++, per esempio uno storage filter (ne prendo apposta uno dello storage stack in modo tale che sia coinvolto nel paging path). a meno che ovviamente non ne usi un sottoinsieme talmente ridicolo da ridurti al C.
All'università ci hanno fatto un accenno di java in attesa di esami specifici in cui lo tratteremo. Forse ultimamente sarò abituato troppo bene con python, ma francamente è stato odio a prima vista.
sfruttare buffer overflow sulle macchine di oggi (dotate di NX bit) é impossibile; al massimo fai crashare il programma vulnerabile.
Beh via, fosse veramente così :asd:
Beh via, fosse veramente così :asd: se hai qualcosa da obiettare obietta, saró felice di apprendere :)
^TiGeRShArK^
25-07-2009, 20:46
per esempio Java non ha l'ereditarietá multipla,
è considerata dannosa per una buona progettazione, generalmente vengono preferite le interfacce che Java supporta perfettamente.
non ha l'operator overloading,
Questo in effetti sarebbe comodo...
come sarebbe anche comodo se in C# fosse permesso tramite extension methods. :mad:
non ha i puntatori a funzioni (presenti anche in C# sotto forma dei delegates), non ha le lambda expressions (presenti nella nuova revisione del C++)
Da JDK 7 in poi dovrebbero esserci.
e non permette di realizzare scoped objects togliendoti quindi quel controllo finissimo che hai in C++ sulla deallocazione delle risorse allocate dinamicamente; puoi scegliere uno tra alcuni algoritmi predefiniti di garbage collection ma non é la stessa cosa.
Nel 99% dei casi è inutile, nei casi in cui serve fare ciò java non è il linguaggio da usare.
Comunque volendo ci sarebbe la versione real time di java che da il controllo completo su tutto, ma imho è una snaturazione di java.
^TiGeRShArK^
25-07-2009, 20:50
Ricordo male o non ci sono nemmeno i parametri opzionali in Java? :D
Per rispondere al thread: PIACCAPPI'! :D
sono stati aggiunti a partire da java 6.
sfruttare buffer overflow sulle macchine di oggi (dotate di NX bit) é impossibile; al massimo fai crashare il programma vulnerabile.
Uh??!
http://milw0rm.com/
Qua è pieno di exploit che sfruttano (tra le altre vulnerabilità), anche buffer overflow.
Da JDK 7 in poi dovrebbero esserci.
No, non ci saranno.
Nel 99% dei casi è inutile, nei casi in cui serve fare ciò java non è il linguaggio da usare.
Se ti riferisci alla scelta del GC, son d'accordo. Trovo invece che sia una mancanza grave in un linguaggio moderno l'impossibilita' di associare la vita di una risorsa allo scope statico; tra l'altro Java non e' proprio il linguaggio piu' flessibile e non si puo' sopperire con metodi fatti in casa.
Uno potrebbe dire quanto è bello Java semplicemente citando quello che non ha.
1. Non supporta l'estensione multipla
2. Non consente alcun intervento sulla gestione della memoria
3. Non ha una sintassi speciale per le funzioni
4. Non supporta la sovrascrittura degli operatori
5. Non ha l'aritmetica dei puntatori
Sfortunatamente:
1. Ha gli array
2. Ha i generici
3. Ha i primitivi
Nessuno è perfetto.
E c'è poi il tocco da Sun Microsystem (riposi in pace): 15 anni fa pensarono che un linguaggio moderno dovesse essere concorrente. Proprio il linguaggio, non le API. Non ce ne sono tanti, anzi, di mainstream direi che c'è solo lui.
^TiGeRShArK^
26-07-2009, 01:40
No, non ci saranno.
ah ok..
ero rimasto ancora al punto in cui erano previste le closures in java 7, mi ero perso l'abbandono.
Imho hanno fatto un'ENORME cazzata dato che la cosa che mi piace di + di C# rispetto a java è proprio la propgrammazione funzionale tramite LINQ.
(e purtroppo l'F# che alla fin fine mi pareva carino dopo la perplessità iniziale l'ho abbandonato completamente perchè non ho tempo manco per bestemmiare.. :cry: )
^TiGeRShArK^
26-07-2009, 01:42
Se ti riferisci alla scelta del GC, son d'accordo. Trovo invece che sia una mancanza grave in un linguaggio moderno l'impossibilita' di associare la vita di una risorsa allo scope statico; tra l'altro Java non e' proprio il linguaggio piu' flessibile e non si puo' sopperire con metodi fatti in casa.
mmmm....
esempi in cui potrebbe essere indispensabile che ora come ora mi sfuggono? :stordita:
nelle chiamate di sistema? :mbe:
forse usi Windows e non hai presente, comunque Linux offre delle funzioni (syscall) richiamabili tramite interrupt ed eseguibili dall'assembly.
#ifndef _ASM_X86_UNISTD_32_H
#define _ASM_X86_UNISTD_32_H
/*
* This file contains the system call numbers.
*/
#define __NR_restart_syscall 0
#define __NR_exit 1
#define __NR_fork 2
#define __NR_read 3
#define __NR_write 4
#define __NR_open 5
#define __NR_close 6
#define __NR_waitpid 7
#define __NR_creat 8
#define __NR_link 9
#define __NR_unlink 10
#define __NR_execve 11
#define __NR_chdir 12
#define __NR_time 13
#define __NR_mknod 14
#define __NR_chmod 15
#define __NR_lchown 16
#define __NR_break 17
#define __NR_oldstat 18
#define __NR_lseek 19
#define __NR_getpid 20
#define __NR_mount 21
#define __NR_umount 22
#define __NR_setuid 23
#define __NR_getuid 24
#define __NR_stime 25
#define __NR_ptrace 26
#define __NR_alarm 27
#define __NR_oldfstat 28
#define __NR_pause 29
#define __NR_utime 30
#define __NR_stty 31
#define __NR_gtty 32
#define __NR_access 33
#define __NR_nice 34
#define __NR_ftime 35
#define __NR_sync 36
#define __NR_kill 37
#define __NR_rename 38
#define __NR_mkdir 39
#define __NR_rmdir 40
#define __NR_dup 41
#define __NR_pipe 42
#define __NR_times 43
#define __NR_prof 44
#define __NR_brk 45
#define __NR_setgid 46
#define __NR_getgid 47
#define __NR_signal 48
#define __NR_geteuid 49
#define __NR_getegid 50
#define __NR_acct 51
#define __NR_umount2 52
#define __NR_lock 53
#define __NR_ioctl 54
#define __NR_fcntl 55
#define __NR_mpx 56
#define __NR_setpgid 57
#define __NR_ulimit 58
#define __NR_oldolduname 59
#define __NR_umask 60
#define __NR_chroot 61
#define __NR_ustat 62
#define __NR_dup2 63
#define __NR_getppid 64
#define __NR_getpgrp 65
#define __NR_setsid 66
#define __NR_sigaction 67
#define __NR_sgetmask 68
#define __NR_ssetmask 69
#define __NR_setreuid 70
#define __NR_setregid 71
#define __NR_sigsuspend 72
#define __NR_sigpending 73
#define __NR_sethostname 74
#define __NR_setrlimit 75
#define __NR_getrlimit 76 /* Back compatible 2Gig limited rlimit */
#define __NR_getrusage 77
#define __NR_gettimeofday 78
#define __NR_settimeofday 79
#define __NR_getgroups 80
#define __NR_setgroups 81
#define __NR_select 82
#define __NR_symlink 83
#define __NR_oldlstat 84
#define __NR_readlink 85
#define __NR_uselib 86
#define __NR_swapon 87
#define __NR_reboot 88
#define __NR_readdir 89
#define __NR_mmap 90
#define __NR_munmap 91
#define __NR_truncate 92
#define __NR_ftruncate 93
#define __NR_fchmod 94
#define __NR_fchown 95
#define __NR_getpriority 96
#define __NR_setpriority 97
#define __NR_profil 98
#define __NR_statfs 99
#define __NR_fstatfs 100
#define __NR_ioperm 101
#define __NR_socketcall 102
#define __NR_syslog 103
#define __NR_setitimer 104
#define __NR_getitimer 105
#define __NR_stat 106
#define __NR_lstat 107
#define __NR_fstat 108
#define __NR_olduname 109
#define __NR_iopl 110
#define __NR_vhangup 111
#define __NR_idle 112
#define __NR_vm86old 113
#define __NR_wait4 114
#define __NR_swapoff 115
#define __NR_sysinfo 116
#define __NR_ipc 117
#define __NR_fsync 118
#define __NR_sigreturn 119
#define __NR_clone 120
#define __NR_setdomainname 121
#define __NR_uname 122
#define __NR_modify_ldt 123
#define __NR_adjtimex 124
#define __NR_mprotect 125
#define __NR_sigprocmask 126
#define __NR_create_module 127
#define __NR_init_module 128
#define __NR_delete_module 129
#define __NR_get_kernel_syms 130
#define __NR_quotactl 131
#define __NR_getpgid 132
#define __NR_fchdir 133
#define __NR_bdflush 134
#define __NR_sysfs 135
#define __NR_personality 136
#define __NR_afs_syscall 137 /* Syscall for Andrew File System */
#define __NR_setfsuid 138
#define __NR_setfsgid 139
#define __NR__llseek 140
#define __NR_getdents 141
#define __NR__newselect 142
#define __NR_flock 143
#define __NR_msync 144
#define __NR_readv 145
#define __NR_writev 146
#define __NR_getsid 147
#define __NR_fdatasync 148
#define __NR__sysctl 149
#define __NR_mlock 150
#define __NR_munlock 151
#define __NR_mlockall 152
#define __NR_munlockall 153
#define __NR_sched_setparam 154
#define __NR_sched_getparam 155
#define __NR_sched_setscheduler 156
#define __NR_sched_getscheduler 157
#define __NR_sched_yield 158
#define __NR_sched_get_priority_max 159
#define __NR_sched_get_priority_min 160
#define __NR_sched_rr_get_interval 161
#define __NR_nanosleep 162
#define __NR_mremap 163
#define __NR_setresuid 164
#define __NR_getresuid 165
#define __NR_vm86 166
#define __NR_query_module 167
#define __NR_poll 168
#define __NR_nfsservctl 169
#define __NR_setresgid 170
#define __NR_getresgid 171
#define __NR_prctl 172
#define __NR_rt_sigreturn 173
#define __NR_rt_sigaction 174
#define __NR_rt_sigprocmask 175
#define __NR_rt_sigpending 176
#define __NR_rt_sigtimedwait 177
#define __NR_rt_sigqueueinfo 178
#define __NR_rt_sigsuspend 179
#define __NR_pread64 180
#define __NR_pwrite64 181
#define __NR_chown 182
#define __NR_getcwd 183
#define __NR_capget 184
#define __NR_capset 185
#define __NR_sigaltstack 186
#define __NR_sendfile 187
#define __NR_getpmsg 188 /* some people actually want streams */
#define __NR_putpmsg 189 /* some people actually want streams */
#define __NR_vfork 190
#define __NR_ugetrlimit 191 /* SuS compliant getrlimit */
#define __NR_mmap2 192
#define __NR_truncate64 193
#define __NR_ftruncate64 194
#define __NR_stat64 195
#define __NR_lstat64 196
#define __NR_fstat64 197
#define __NR_lchown32 198
#define __NR_getuid32 199
#define __NR_getgid32 200
#define __NR_geteuid32 201
#define __NR_getegid32 202
#define __NR_setreuid32 203
#define __NR_setregid32 204
#define __NR_getgroups32 205
#define __NR_setgroups32 206
#define __NR_fchown32 207
#define __NR_setresuid32 208
#define __NR_getresuid32 209
#define __NR_setresgid32 210
#define __NR_getresgid32 211
#define __NR_chown32 212
#define __NR_setuid32 213
#define __NR_setgid32 214
#define __NR_setfsuid32 215
#define __NR_setfsgid32 216
#define __NR_pivot_root 217
#define __NR_mincore 218
#define __NR_madvise 219
#define __NR_madvise1 219 /* delete when C lib stub is removed */
#define __NR_getdents64 220
#define __NR_fcntl64 221
/* 223 is unused */
#define __NR_gettid 224
#define __NR_readahead 225
#define __NR_setxattr 226
#define __NR_lsetxattr 227
#define __NR_fsetxattr 228
#define __NR_getxattr 229
#define __NR_lgetxattr 230
#define __NR_fgetxattr 231
#define __NR_listxattr 232
#define __NR_llistxattr 233
#define __NR_flistxattr 234
#define __NR_removexattr 235
#define __NR_lremovexattr 236
#define __NR_fremovexattr 237
#define __NR_tkill 238
#define __NR_sendfile64 239
#define __NR_futex 240
#define __NR_sched_setaffinity 241
#define __NR_sched_getaffinity 242
#define __NR_set_thread_area 243
#define __NR_get_thread_area 244
#define __NR_io_setup 245
#define __NR_io_destroy 246
#define __NR_io_getevents 247
#define __NR_io_submit 248
#define __NR_io_cancel 249
#define __NR_fadvise64 250
/* 251 is available for reuse (was briefly sys_set_zone_reclaim) */
#define __NR_exit_group 252
#define __NR_lookup_dcookie 253
#define __NR_epoll_create 254
#define __NR_epoll_ctl 255
#define __NR_epoll_wait 256
#define __NR_remap_file_pages 257
#define __NR_set_tid_address 258
#define __NR_timer_create 259
#define __NR_timer_settime (__NR_timer_create+1)
#define __NR_timer_gettime (__NR_timer_create+2)
#define __NR_timer_getoverrun (__NR_timer_create+3)
#define __NR_timer_delete (__NR_timer_create+4)
#define __NR_clock_settime (__NR_timer_create+5)
#define __NR_clock_gettime (__NR_timer_create+6)
#define __NR_clock_getres (__NR_timer_create+7)
#define __NR_clock_nanosleep (__NR_timer_create+8)
#define __NR_statfs64 268
#define __NR_fstatfs64 269
#define __NR_tgkill 270
#define __NR_utimes 271
#define __NR_fadvise64_64 272
#define __NR_vserver 273
#define __NR_mbind 274
#define __NR_get_mempolicy 275
#define __NR_set_mempolicy 276
#define __NR_mq_open 277
#define __NR_mq_unlink (__NR_mq_open+1)
#define __NR_mq_timedsend (__NR_mq_open+2)
#define __NR_mq_timedreceive (__NR_mq_open+3)
#define __NR_mq_notify (__NR_mq_open+4)
#define __NR_mq_getsetattr (__NR_mq_open+5)
#define __NR_kexec_load 283
#define __NR_waitid 284
/* #define __NR_sys_setaltroot 285 */
#define __NR_add_key 286
#define __NR_request_key 287
#define __NR_keyctl 288
#define __NR_ioprio_set 289
#define __NR_ioprio_get 290
#define __NR_inotify_init 291
#define __NR_inotify_add_watch 292
#define __NR_inotify_rm_watch 293
#define __NR_migrate_pages 294
#define __NR_openat 295
#define __NR_mkdirat 296
#define __NR_mknodat 297
#define __NR_fchownat 298
#define __NR_futimesat 299
#define __NR_fstatat64 300
#define __NR_unlinkat 301
#define __NR_renameat 302
#define __NR_linkat 303
#define __NR_symlinkat 304
#define __NR_readlinkat 305
#define __NR_fchmodat 306
#define __NR_faccessat 307
#define __NR_pselect6 308
#define __NR_ppoll 309
#define __NR_unshare 310
#define __NR_set_robust_list 311
#define __NR_get_robust_list 312
#define __NR_splice 313
#define __NR_sync_file_range 314
#define __NR_tee 315
#define __NR_vmsplice 316
#define __NR_move_pages 317
#define __NR_getcpu 318
#define __NR_epoll_pwait 319
#define __NR_utimensat 320
#define __NR_signalfd 321
#define __NR_timerfd_create 322
#define __NR_eventfd 323
#define __NR_fallocate 324
#define __NR_timerfd_settime 325
#define __NR_timerfd_gettime 326
#define __NR_signalfd4 327
#define __NR_eventfd2 328
#define __NR_epoll_create1 329
#define __NR_dup3 330
#define __NR_pipe2 331
#define __NR_inotify_init1 332
#endif /* _ASM_X86_UNISTD_32_H */
questo è il file che si trova in /usr/include/asm/unistd_32.
e ce n'è un altro per le architetture a 64 bit
senza l'assembly non saprei come richiamarle, per questo ho scritto che l'assembly è utile per richiamare le syscall
forse usi Windows e non hai presente, comunque Linux offre delle funzioni (syscall) richiamabili tramite interrupt ed eseguibili dall'assembly.
#ifndef _ASM_X86_UNISTD_32_H
#define _ASM_X86_UNISTD_32_H
/*
* This file contains the system call numbers.
*/
#define __NR_restart_syscall 0
#define __NR_exit 1
#define __NR_fork 2
#define __NR_read 3
#define __NR_write 4
#define __NR_open 5
#define __NR_close 6
#define __NR_waitpid 7
#define __NR_creat 8
#define __NR_link 9
#define __NR_unlink 10
#define __NR_execve 11
#define __NR_chdir 12
#define __NR_time 13
#define __NR_mknod 14
#define __NR_chmod 15
#define __NR_lchown 16
#define __NR_break 17
#define __NR_oldstat 18
#define __NR_lseek 19
#define __NR_getpid 20
#define __NR_mount 21
#define __NR_umount 22
#define __NR_setuid 23
#define __NR_getuid 24
#define __NR_stime 25
#define __NR_ptrace 26
#define __NR_alarm 27
#define __NR_oldfstat 28
#define __NR_pause 29
#define __NR_utime 30
#define __NR_stty 31
#define __NR_gtty 32
#define __NR_access 33
#define __NR_nice 34
#define __NR_ftime 35
#define __NR_sync 36
#define __NR_kill 37
#define __NR_rename 38
#define __NR_mkdir 39
#define __NR_rmdir 40
#define __NR_dup 41
#define __NR_pipe 42
#define __NR_times 43
#define __NR_prof 44
#define __NR_brk 45
#define __NR_setgid 46
#define __NR_getgid 47
#define __NR_signal 48
#define __NR_geteuid 49
#define __NR_getegid 50
#define __NR_acct 51
#define __NR_umount2 52
#define __NR_lock 53
#define __NR_ioctl 54
#define __NR_fcntl 55
#define __NR_mpx 56
#define __NR_setpgid 57
#define __NR_ulimit 58
#define __NR_oldolduname 59
#define __NR_umask 60
#define __NR_chroot 61
#define __NR_ustat 62
#define __NR_dup2 63
#define __NR_getppid 64
#define __NR_getpgrp 65
#define __NR_setsid 66
#define __NR_sigaction 67
#define __NR_sgetmask 68
#define __NR_ssetmask 69
#define __NR_setreuid 70
#define __NR_setregid 71
#define __NR_sigsuspend 72
#define __NR_sigpending 73
#define __NR_sethostname 74
#define __NR_setrlimit 75
#define __NR_getrlimit 76 /* Back compatible 2Gig limited rlimit */
#define __NR_getrusage 77
#define __NR_gettimeofday 78
#define __NR_settimeofday 79
#define __NR_getgroups 80
#define __NR_setgroups 81
#define __NR_select 82
#define __NR_symlink 83
#define __NR_oldlstat 84
#define __NR_readlink 85
#define __NR_uselib 86
#define __NR_swapon 87
#define __NR_reboot 88
#define __NR_readdir 89
#define __NR_mmap 90
#define __NR_munmap 91
#define __NR_truncate 92
#define __NR_ftruncate 93
#define __NR_fchmod 94
#define __NR_fchown 95
#define __NR_getpriority 96
#define __NR_setpriority 97
#define __NR_profil 98
#define __NR_statfs 99
#define __NR_fstatfs 100
#define __NR_ioperm 101
#define __NR_socketcall 102
#define __NR_syslog 103
#define __NR_setitimer 104
#define __NR_getitimer 105
#define __NR_stat 106
#define __NR_lstat 107
#define __NR_fstat 108
#define __NR_olduname 109
#define __NR_iopl 110
#define __NR_vhangup 111
#define __NR_idle 112
#define __NR_vm86old 113
#define __NR_wait4 114
#define __NR_swapoff 115
#define __NR_sysinfo 116
#define __NR_ipc 117
#define __NR_fsync 118
#define __NR_sigreturn 119
#define __NR_clone 120
#define __NR_setdomainname 121
#define __NR_uname 122
#define __NR_modify_ldt 123
#define __NR_adjtimex 124
#define __NR_mprotect 125
#define __NR_sigprocmask 126
#define __NR_create_module 127
#define __NR_init_module 128
#define __NR_delete_module 129
#define __NR_get_kernel_syms 130
#define __NR_quotactl 131
#define __NR_getpgid 132
#define __NR_fchdir 133
#define __NR_bdflush 134
#define __NR_sysfs 135
#define __NR_personality 136
#define __NR_afs_syscall 137 /* Syscall for Andrew File System */
#define __NR_setfsuid 138
#define __NR_setfsgid 139
#define __NR__llseek 140
#define __NR_getdents 141
#define __NR__newselect 142
#define __NR_flock 143
#define __NR_msync 144
#define __NR_readv 145
#define __NR_writev 146
#define __NR_getsid 147
#define __NR_fdatasync 148
#define __NR__sysctl 149
#define __NR_mlock 150
#define __NR_munlock 151
#define __NR_mlockall 152
#define __NR_munlockall 153
#define __NR_sched_setparam 154
#define __NR_sched_getparam 155
#define __NR_sched_setscheduler 156
#define __NR_sched_getscheduler 157
#define __NR_sched_yield 158
#define __NR_sched_get_priority_max 159
#define __NR_sched_get_priority_min 160
#define __NR_sched_rr_get_interval 161
#define __NR_nanosleep 162
#define __NR_mremap 163
#define __NR_setresuid 164
#define __NR_getresuid 165
#define __NR_vm86 166
#define __NR_query_module 167
#define __NR_poll 168
#define __NR_nfsservctl 169
#define __NR_setresgid 170
#define __NR_getresgid 171
#define __NR_prctl 172
#define __NR_rt_sigreturn 173
#define __NR_rt_sigaction 174
#define __NR_rt_sigprocmask 175
#define __NR_rt_sigpending 176
#define __NR_rt_sigtimedwait 177
#define __NR_rt_sigqueueinfo 178
#define __NR_rt_sigsuspend 179
#define __NR_pread64 180
#define __NR_pwrite64 181
#define __NR_chown 182
#define __NR_getcwd 183
#define __NR_capget 184
#define __NR_capset 185
#define __NR_sigaltstack 186
#define __NR_sendfile 187
#define __NR_getpmsg 188 /* some people actually want streams */
#define __NR_putpmsg 189 /* some people actually want streams */
#define __NR_vfork 190
#define __NR_ugetrlimit 191 /* SuS compliant getrlimit */
#define __NR_mmap2 192
#define __NR_truncate64 193
#define __NR_ftruncate64 194
#define __NR_stat64 195
#define __NR_lstat64 196
#define __NR_fstat64 197
#define __NR_lchown32 198
#define __NR_getuid32 199
#define __NR_getgid32 200
#define __NR_geteuid32 201
#define __NR_getegid32 202
#define __NR_setreuid32 203
#define __NR_setregid32 204
#define __NR_getgroups32 205
#define __NR_setgroups32 206
#define __NR_fchown32 207
#define __NR_setresuid32 208
#define __NR_getresuid32 209
#define __NR_setresgid32 210
#define __NR_getresgid32 211
#define __NR_chown32 212
#define __NR_setuid32 213
#define __NR_setgid32 214
#define __NR_setfsuid32 215
#define __NR_setfsgid32 216
#define __NR_pivot_root 217
#define __NR_mincore 218
#define __NR_madvise 219
#define __NR_madvise1 219 /* delete when C lib stub is removed */
#define __NR_getdents64 220
#define __NR_fcntl64 221
/* 223 is unused */
#define __NR_gettid 224
#define __NR_readahead 225
#define __NR_setxattr 226
#define __NR_lsetxattr 227
#define __NR_fsetxattr 228
#define __NR_getxattr 229
#define __NR_lgetxattr 230
#define __NR_fgetxattr 231
#define __NR_listxattr 232
#define __NR_llistxattr 233
#define __NR_flistxattr 234
#define __NR_removexattr 235
#define __NR_lremovexattr 236
#define __NR_fremovexattr 237
#define __NR_tkill 238
#define __NR_sendfile64 239
#define __NR_futex 240
#define __NR_sched_setaffinity 241
#define __NR_sched_getaffinity 242
#define __NR_set_thread_area 243
#define __NR_get_thread_area 244
#define __NR_io_setup 245
#define __NR_io_destroy 246
#define __NR_io_getevents 247
#define __NR_io_submit 248
#define __NR_io_cancel 249
#define __NR_fadvise64 250
/* 251 is available for reuse (was briefly sys_set_zone_reclaim) */
#define __NR_exit_group 252
#define __NR_lookup_dcookie 253
#define __NR_epoll_create 254
#define __NR_epoll_ctl 255
#define __NR_epoll_wait 256
#define __NR_remap_file_pages 257
#define __NR_set_tid_address 258
#define __NR_timer_create 259
#define __NR_timer_settime (__NR_timer_create+1)
#define __NR_timer_gettime (__NR_timer_create+2)
#define __NR_timer_getoverrun (__NR_timer_create+3)
#define __NR_timer_delete (__NR_timer_create+4)
#define __NR_clock_settime (__NR_timer_create+5)
#define __NR_clock_gettime (__NR_timer_create+6)
#define __NR_clock_getres (__NR_timer_create+7)
#define __NR_clock_nanosleep (__NR_timer_create+8)
#define __NR_statfs64 268
#define __NR_fstatfs64 269
#define __NR_tgkill 270
#define __NR_utimes 271
#define __NR_fadvise64_64 272
#define __NR_vserver 273
#define __NR_mbind 274
#define __NR_get_mempolicy 275
#define __NR_set_mempolicy 276
#define __NR_mq_open 277
#define __NR_mq_unlink (__NR_mq_open+1)
#define __NR_mq_timedsend (__NR_mq_open+2)
#define __NR_mq_timedreceive (__NR_mq_open+3)
#define __NR_mq_notify (__NR_mq_open+4)
#define __NR_mq_getsetattr (__NR_mq_open+5)
#define __NR_kexec_load 283
#define __NR_waitid 284
/* #define __NR_sys_setaltroot 285 */
#define __NR_add_key 286
#define __NR_request_key 287
#define __NR_keyctl 288
#define __NR_ioprio_set 289
#define __NR_ioprio_get 290
#define __NR_inotify_init 291
#define __NR_inotify_add_watch 292
#define __NR_inotify_rm_watch 293
#define __NR_migrate_pages 294
#define __NR_openat 295
#define __NR_mkdirat 296
#define __NR_mknodat 297
#define __NR_fchownat 298
#define __NR_futimesat 299
#define __NR_fstatat64 300
#define __NR_unlinkat 301
#define __NR_renameat 302
#define __NR_linkat 303
#define __NR_symlinkat 304
#define __NR_readlinkat 305
#define __NR_fchmodat 306
#define __NR_faccessat 307
#define __NR_pselect6 308
#define __NR_ppoll 309
#define __NR_unshare 310
#define __NR_set_robust_list 311
#define __NR_get_robust_list 312
#define __NR_splice 313
#define __NR_sync_file_range 314
#define __NR_tee 315
#define __NR_vmsplice 316
#define __NR_move_pages 317
#define __NR_getcpu 318
#define __NR_epoll_pwait 319
#define __NR_utimensat 320
#define __NR_signalfd 321
#define __NR_timerfd_create 322
#define __NR_eventfd 323
#define __NR_fallocate 324
#define __NR_timerfd_settime 325
#define __NR_timerfd_gettime 326
#define __NR_signalfd4 327
#define __NR_eventfd2 328
#define __NR_epoll_create1 329
#define __NR_dup3 330
#define __NR_pipe2 331
#define __NR_inotify_init1 332
#endif /* _ASM_X86_UNISTD_32_H */
questo è il file che si trova in /usr/include/asm/unistd_32.
e ce n'è un altro per le architetture a 64 bit
senza l'assembly non saprei come richiamarle, per questo ho scritto che l'assembly è utile per richiamare le syscall
Mi sa che hai le idee un po' confuse. Per tutte le chiamate di sistema c'è una funzione apposita c che le astrae dal livello macchina. Quindi l'utilizzo diretto delle syscall mediante interrupt è praticamente inutile
Ad esempio se fai una fork lui te la traduce nell'interrupt 2 una volta compilato il programma
io ho sempre usato l'assembly e non ho mai avuto problemi
se hai qualcosa da obiettare obietta, saró felice di apprendere :)
Se fosse veramente così vedresti sistemi attuali (processori che supportano l'NX Bit) dove gli exploit non esisterebbero - cosa piu sbagliata non esiste, basta che ti guardi attorno. In realtà l'NX Bit riesce a coprire solo uno dei possibili modi di sfruttare un attacco causato da buffer overflow (e se configurato bene). Ci sono almeno altre due tipologie di attacchi dove l'NX Bit è totalmente inoffensivo e inutile.
Se mi parli di NX Bit, ASLR, Safe SEH combinati insieme allora ne possiamo anche riparlare. Se affermi che grazie all'NX Bit non esistono piu attacchi da buffer overflow sei fortemente sulla strada sbagliata
morskott
26-07-2009, 11:52
Mi sa che hai le idee un po' confuse. Per tutte le chiamate di sistema c'è una funzione apposita c che le astrae dal livello macchina. Quindi l'utilizzo diretto delle syscall mediante interrupt è praticamente inutile
Ad esempio se fai una fork lui te la traduce nell'interrupt 2 una volta compilato il programma
Bhe, che io sappia l'UNICO modo per accedere alle system call linux è una "int 0x80", cioè tramite un interrupt alla "porta" 80, ci stanno delle macro user-mode che lo fanno al posto nostro, ma quella è l'unica via di accesso
Bhe, che io sappia l'UNICO modo per accedere alle system call linux è una "int 0x80", cioè tramite un interrupt alla "porta" 80, ci stanno delle macro user-mode che lo fanno al posto nostro, ma quella è l'unica via di accesso
La funzione c viene poi ovviamente tradotta nella corrispondente istruzione macchina(nella fattispecie int) dal compilatore, ma francamente non vedo il motivo di utilizzare codice macchina direttamente per effettuare chiamate di sistema tipo fork/clone ecc complicandosi la vita in modo atroce come fa mark91 quando si hanno a disposizioni delle api c per farlo
morskott
26-07-2009, 16:00
La funzione c viene poi ovviamente tradotta nella corrispondente istruzione macchina(nella fattispecie int) dal compilatore, ma francamente non vedo il motivo di utilizzare codice macchina direttamente per effettuare chiamate di sistema tipo fork/clone ecc complicandosi la vita in modo atroce come fa mark91 quando si hanno a disposizioni delle api c per farlo
Per quello che ci hanno fatto studiare le "fork" etc sono solo macro (delle define) in C che espandendosi il codice che viene passato effettivamente al compilatore è un "asm volatile("int 0x80" ...)", ma anch'io vorrei sapere come fare a chiamare sys call visto che per una tesina non riesco a chiamare delle sys call fatte da me!!!!
fatmatto
26-07-2009, 16:31
Scusate se faccio lo S?&%o ma come fate a dire che perl e php sono brutti?
Io ci ho lavorato e mi hano semplificato un sacco la vita!
Se per esempio dovessi scrivere un semplice blog, scriverlo in php piuttosto che in java mi risparmierebbe tempo e soprattutto denaro. E poi php è ancora il motore di scripting dominante del web! (anche questo sito è in php)
Perl mi ha aiutato tantissimo nell'amministrazione di sistema: è molto comodo per editare files di configurazione di diverse applicazioni e per fare parsing estensivo di files.
Ora confesso di aver abbandonato perl a favore del python, ma quest'ultimo non mi permette di scrivere i miei programmi "one line" dove in una riga di codice illeggibile ottieni grandi risultati XD
quindi i linguaggi che ho odiato di + sono
1)Pascal
2)C (non è OOP brrr)
3)C#
Il primo perchè me lhanno imposto alle superiori, il secondo all'università ed il terzo per un semplice motivo: Conosco il C++ conosco il Java perchè devo confondermi con una sintassi leggermente diversa e con nuove classi e librerie da imparare? Perchè Microsoft ha una enorme
Per quello che ci hanno fatto studiare le "fork" etc sono solo macro (delle define) in C che espandendosi il codice che viene passato effettivamente al compilatore è un "asm volatile("int 0x80" ...)", ma anch'io vorrei sapere come fare a chiamare sys call visto che per una tesina non riesco a chiamare delle sys call fatte da me!!!!
Quello che volevo far capire a mark91 è che non c'è alcun motivo per scendere a basso livello con il codice macchina ogni volta che deve fare delle chiamate di sistema, perchè sono disponibili delle api c che rendono possibile la cosa ad alto livello. Quindi è inutile sporcarsi le mani :)
DanieleC88
26-07-2009, 17:17
Scusate se faccio lo S?&%o ma come fate a dire che perl e php sono brutti?
Perl è illeggibile, PHP è un po' più leggibile ma neanche tanto in fondo (non mi soffermerò più di tanto, ma se vuoi approfondire c'è un thread con decine di buone motivazioni). E poi PHP deve la sua potenza solo al fatto di essere onnipresente e con una serie di estensioni comunitarie che ti permettono di fare un bel po' di cose. Ma a parte la virtual machine che è pesante, lo stesso software scritto in PHP e in Java sarebbe ben più perfomante in Java, ad esempio.
DanieleC88
26-07-2009, 17:23
sono stati aggiunti a partire da java 6.
Veramente? Buono a sapersi. :)
fatmatto
26-07-2009, 18:25
Perl è illeggibile, PHP è un po' più leggibile ma neanche tanto in fondo (non mi soffermerò più di tanto, ma se vuoi approfondire c'è un thread con decine di buone motivazioni). E poi PHP deve la sua potenza solo al fatto di essere onnipresente e con una serie di estensioni comunitarie che ti permettono di fare un bel po' di cose. Ma a parte la virtual machine che è pesante, lo stesso software scritto in PHP e in Java sarebbe ben più perfomante in Java, ad esempio.
illeggibile solo perchè hai un $ davanti le variabili? :rotfl:
(ammetto che mi da fastidio premere shift-4)
un esempio di sintassi php-java_
//gli oggetti si istanziano quasi come in java:
$var = new Class();
//in java:
Class var = new Class();
Non notate qualche somiglianza ? :rotfl:
Parli di performance?imho è come fare un confronto tra un aereoplano ed un treno... php è un linguaggio di scripting Java no, è ovvio che php ha performance diverse dal punto di vista dell'esecuzione , ma dal punto di vista della stesura del codice fai molto prima con php per quel che riguarda applicazioni semplici. Fammi un Semplice un blog in jsp e dimmi quante linee di codice ti servono :fagiano:
Perl non è destinato a grandi progetti quindi non alla leggibilità sai che ha salvato il progetto sulla mappatura del genoma umano? http://www.bioperl.org/wiki/How_Perl_saved_human_genome
cmq alla fine dipende sempre da cosa devi fare, un sito di banking lo faccio in java anche se la zend vorrebbe che lo facessi in php.
un blog lo scrivo in php
uno spider web o un robottino per msn lo scrivo in python XD
come diceva un saggio: i gusti son gusti :oink:
Per quello che ci hanno fatto studiare le "fork" etc sono solo macro (delle define) in C che espandendosi il codice che viene passato effettivamente al compilatore è un "asm volatile("int 0x80" ...)", ma anch'io vorrei sapere come fare a chiamare sys call visto che per una tesina non riesco a chiamare delle sys call fatte da me!!!!
se intendi in assembly, è molto seplice
innazitutto vedi il numero della chiamata di sistema che ti serve, poi sposti dentro il registro EAX il valore intero corrispondente alla chiamata di sistema. Se la funzione ha degli argomenti devi inserili nei registri EBX, ECX, EDX, in seguito richiami l'interrupt 0x80. per uscire in modo ortodosso, devi richiamare la funzione exit (chiamata di sistema numero 1), in questo modo
;uscita
mov eax,1
mov ebx,0 ;il primo argomento deve essere 0
int 0x80
se intendi in C non ne ho idea :D
cdimauro
26-07-2009, 18:59
io infatti stavo parlando di drivers per Windows.
letto il link?
Lo conoscevo già.
per un linguaggio che offre costrutti semplici come il C, il modo in cui il codice viene generato é molto piu semplice da capire e controllare, per esempio non esistono costruttori e distruttori e quindi tutto il codice che verrá mai eseguito da una tua funzione si trova interamente all'interno di quella funzione e delle funzioni richiamate da essa; inoltre non esiste il discorso degli oggetti temporanei e quindi puoi valutare con precisione quanto spazio di stack stai usando solo contando i parametri e le variabili locali.
ti fa rabbrividire l'idea di dover fare simili assunzioni nella programmazione kernel-mode in Windows, oltre all'idea di dover usare il C e per giunta preferibilmente con uno specifico compilatore? pazienza, in Windows i driver si programmano cosi. per decidere in quale sezione (e quali memory flags deve avere quella sezione) mettere determinate funzioni devi circondarle con un paio di pragma specifiche del compilatore Microsoft.
pensala come ti pare, sta di fatto che non riuscirai mai con nessun compilatore a scrivere un driver per Windows in C++, per esempio uno storage filter (ne prendo apposta uno dello storage stack in modo tale che sia coinvolto nel paging path). a meno che ovviamente non ne usi un sottoinsieme talmente ridicolo da ridurti al C.
Io penso che un linguaggio è costituito da sintassi e semantica, e che dal "comportamento" di un'implementazione nulla si possa attribuire al linguaggio di per sé.
Ciò che hai riportato riguarda, appunto, implementazioni attuali.
Tanto per fare un esempio, nessuno m'impedisce di scrivere un compilatore C che genera il codice delle funzioni in posizioni pseudocasuali all'interno del codice oggetto finale.
Come posso scrivere un compilatore C++ che riesce a controllare in maniera assolutamente precisa la posizione di qualunque risorsa dovrà generare.
Un esempio "real world" è AmigaOS, dove coi compilatori a disposizione potevo specificare quali tipi di memoria utilizzare per specifiche porzioni di codice/dati/BSS. Ciò si rendeva indispensabile a causa della presenza di due tipi di memoria molto diversi: la chip ram (l'unica accessibile dal chipset) e la fast ram (accessibile esclusivamente dalla CPU e da periferiche che non fossero il chipset).
Uno potrebbe dire quanto è bello Java semplicemente citando quello che non ha.
1. Non supporta l'estensione multipla
2. Non consente alcun intervento sulla gestione della memoria
3. Non ha una sintassi speciale per le funzioni
4. Non supporta la sovrascrittura degli operatori
5. Non ha l'aritmetica dei puntatori
Sfortunatamente:
1. Ha gli array
2. Ha i generici
3. Ha i primitivi
Nessuno è perfetto.
E c'è poi il tocco da Sun Microsystem (riposi in pace): 15 anni fa pensarono che un linguaggio moderno dovesse essere concorrente. Proprio il linguaggio, non le API. Non ce ne sono tanti, anzi, di mainstream direi che c'è solo lui.
Fra gli "sfortunatamente" ti sei dimenticato di aggiungere le stringhe. :fiufiu: :D
Scusate se faccio lo S?&%o ma come fate a dire che perl e php sono brutti?
Io ci ho lavorato e mi hano semplificato un sacco la vita!
E chi lo nega. Per te possono essere bellissimi, ma qui ognuno sta esprimendo i PROPRI giudizi: abbiamo il diritto farlo anche se tu la pensi in maniera diversa?
Comunque c'è quasi unanimità sulla bruttezza di Perl e PHP, e magari un fondo di verità c'è. :fagiano:
Se per esempio dovessi scrivere un semplice blog, scriverlo in php piuttosto che in java mi risparmierebbe tempo e soprattutto denaro. E poi php è ancora il motore di scripting dominante del web! (anche questo sito è in php)
Perl mi ha aiutato tantissimo nell'amministrazione di sistema: è molto comodo per editare files di configurazione di diverse applicazioni e per fare parsing estensivo di files.
Ora confesso di aver abbandonato perl a favore del python, ma quest'ultimo non mi permette di scrivere i miei programmi "one line" dove in una riga di codice illeggibile ottieni grandi risultati XD
Ecco perché un Pythonista non potrà mai lavorare con Perl. :D
quindi i linguaggi che ho odiato di + sono
1)Pascal
2)C (non è OOP brrr)
3)C#
Il primo perchè me lhanno imposto alle superiori,
E questo per te è motivo sufficiente per "odiarlo"? Mah. :rolleyes:
il secondo all'università ed il terzo per un semplice motivo: Conosco il C++ conosco il Java perchè devo confondermi con una sintassi leggermente diversa e con nuove classi e librerie da imparare? Perchè Microsoft ha una enorme
Sete di potere, sì, l'avevamo capito. E magari, "casualmente", sei un Linuxiano e/o fanatico dell'open source... :D
Fra gli "sfortunatamente" ti sei dimenticato di aggiungere le stringhe. :fiufiu: :D
Eh eh, la stringa. La stringa è delicata ma in tutte le lingue. Va bene il tipo di dato - come un qualsiasi altro tipo di dato - mentre il letterale è pericoloso. Basta un niente per tagliarsi le gambe. Ricordo la mitica transazione SAP per le verifiche inventariali con la sua bella etichetta "Differenzienlist Berbeiten", anche nella versione italiana.
fatmatto
26-07-2009, 19:34
Lo conoscevo già.
Io penso che un linguaggio è costituito da sintassi e semantica, e che dal "comportamento" di un'implementazione nulla si possa attribuire al linguaggio di per sé.
Ciò che hai riportato riguarda, appunto, implementazioni attuali.
Tanto per fare un esempio, nessuno m'impedisce di scrivere un compilatore C che genera il codice delle funzioni in posizioni pseudocasuali all'interno del codice oggetto finale.
Come posso scrivere un compilatore C++ che riesce a controllare in maniera assolutamente precisa la posizione di qualunque risorsa dovrà generare.
Un esempio "real world" è AmigaOS, dove coi compilatori a disposizione potevo specificare quali tipi di memoria utilizzare per specifiche porzioni di codice/dati/BSS. Ciò si rendeva indispensabile a causa della presenza di due tipi di memoria molto diversi: la chip ram (l'unica accessibile dal chipset) e la fast ram (accessibile esclusivamente dalla CPU e da periferiche che non fossero il chipset).
Fra gli "sfortunatamente" ti sei dimenticato di aggiungere le stringhe. :fiufiu: :D
E chi lo nega. Per te possono essere bellissimi, ma qui ognuno sta esprimendo i PROPRI giudizi: abbiamo il diritto farlo anche se tu la pensi in maniera diversa?
Comunque c'è quasi unanimità sulla bruttezza di Perl e PHP, e magari un fondo di verità c'è. :fagiano:
Ecco perché un Pythonista non potrà mai lavorare con Perl. :D
E questo per te è motivo sufficiente per "odiarlo"? Mah. :rolleyes:
Sete di potere, sì, l'avevamo capito. E magari, "casualmente", sei un Linuxiano e/o fanatico dell'open source... :D
SMi dispiace smontare la tua splendida intuizione , ma non sono un fanatico dell'open source.Nonostante ne sia un sostenitore al momento scrivo da windows e nella mia zona il 90% delle aziende usa .NET ecco perchè parlo di microsoft.
Ho forse detto che qualcuno NON può esprimere i propri giudizi? no! Lo sto facendo anche io, mi segui? è un problema se difendo ciò che mi piace? lo fai anche tu con python tanto da averlo nell'avatar :wtf:
E ti sembra un buon motivo odiare un linguaggio perchè è brutto? Secondo me la bellezza è seconda alla curva di apprendimento e a tante altre cose, ma magari mi sbaglio! Un giorno incontrerò un cliente che vorrà incorniciare il codice sorgente del proprio sito e nel farlo mi dirà EH MA PHP è proprio brutto eh! Cosa direbbero quei poveri uomini che usavano assembly? Erano veramente persone senza un minimo di stile....
^TiGeRShArK^
26-07-2009, 19:42
Scusate se faccio lo S?&%o ma come fate a dire che perl e php sono brutti?
Non sono brutti sono degli aborti.
Basta solo il fatto che il PHP non è nemmeno nato come linguaggio ad oggetti e l'hanno aggiunto solo dopo. :Puke:
Quanto alla sintassi di perl lasciamo stare che è meglio va. :asd:
Io ci ho lavorato e mi hano semplificato un sacco la vita!
Evidentemente non hai mai usato ASP.NET e ruby on rails....
Se per esempio dovessi scrivere un semplice blog, scriverlo in php piuttosto che in java mi risparmierebbe tempo e soprattutto denaro. E poi php è ancora il motore di scripting dominante del web! (anche questo sito è in php)
Con Ror lo scrivi in 10 minuti ad essere lunghi una volta che lo impari....
Perl mi ha aiutato tantissimo nell'amministrazione di sistema: è molto comodo per editare files di configurazione di diverse applicazioni e per fare parsing estensivo di files.
Ora confesso di aver abbandonato perl a favore del python, ma quest'ultimo non mi permette di scrivere i miei programmi "one line" dove in una riga di codice illeggibile ottieni grandi risultati XD
Appunto.
Proprio per quello perl fa veramente CAGARE.
Un linguaggio di programmazione DEVE essere comprensibile.
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” :O
quindi i linguaggi che ho odiato di + sono
1)Pascal
2)C (non è OOP brrr)
3)C#
Il primo perchè me lhanno imposto alle superiori, il secondo all'università ed il terzo per un semplice motivo: Conosco il C++ conosco il Java perchè devo confondermi con una sintassi leggermente diversa e con nuove classi e librerie da imparare? Perchè Microsoft ha una enorme
C# è un gradino superiore rispetto a Java grazie a LINQ.
^TiGeRShArK^
26-07-2009, 19:43
Veramente? Buono a sapersi. :)
si ma poi ho visto che ti riferivi agli argomenti di default. :asd:
Quelli non ci sono, con java 6 sono stati aggiunti gli argomenti opzionali, che erano quelli che avevi nominato nel primo post. :p
C# è un gradino superiore rispetto a Java grazie a LINQ.
C# è un linguaggio di programmazione nello stesso senso in cui la bestemmia è un modo di esprimersi: tecnicamente è vero.
^TiGeRShArK^
26-07-2009, 19:48
C# è un linguaggio di programmazione nello stesso senso in cui la bestemmia è un modo di esprimersi: tecnicamente è vero.
beh...
magari tu sarai contento perchè ti hanno levato le closures da java 7, per me hanno fatto un'enorme cazzata invece, dopo essere diventato lambda-function dipendente col C#. :p
illeggibile solo perchè hai un $ davanti le variabili? :rotfl:
(ammetto che mi da fastidio premere shift-4)
un esempio di sintassi php-java_
//gli oggetti si istanziano quasi come in java:
$var = new Class();
//in java:
Class var = new Class();
Non notate qualche somiglianza ? :rotfl:
È normale che ci siano similitudini tra i due linguaggi visto che hanno dei parenti in comune. PHP però, a differenza di Java, è pieno di piccole incongruenze e difetti che a molti danno veramente fastidio.
Parli di performance?imho è come fare un confronto tra un aereoplano ed un treno... php è un linguaggio di scripting Java no, è ovvio che php ha performance diverse dal punto di vista dell'esecuzione , ma dal punto di vista della stesura del codice fai molto prima con php per quel che riguarda applicazioni semplici. Fammi un Semplice un blog in jsp e dimmi quante linee di codice ti servono :fagiano:
Non vedo perché tirare in ballo la velocità con cui vengono scritti i programmi quando si stava parlando di prestazioni del linguaggio. Tra l'altro php non è che sia così facile da scrivere se paragonato a soluzioni come ruby+rails.
Perl non è destinato a grandi progetti quindi non alla leggibilità sai che ha salvato il progetto sulla mappatura del genoma umano? http://www.bioperl.org/wiki/How_Perl_saved_human_genome
Per quale motivo un linguaggio pensato per piccoli lavoretti non dovrebbe essere leggibile? Piuttosto si può dire che Perl non è usato in grandi progetti perché non leggibile.
fatmatto
26-07-2009, 20:09
non uso ror ma lo conosco per fama e non posso che darti ragione sul discorso del tempo risparmiato, però vorrei farti riflettere sulla percentuale di diffusione del linguaggio, maggiore diffusione porta maggiore documentazione e supporto. inoltre per php ci sono moltissimi hosting anche gratuiti!
Il fatto che php non è nato con il supporto OOP ma lo hanno aggiunto in seguito NON rappresenta uno svantaggio, a meno che non inventiamo la macchina del tempo.
.NET è un ottimo ambiente non lo nego, ho soltanto detto che dopo aver studiato Java e C++ e compagnia bella imparare un linguaggio al mese con le sue librerie non è il massimo.
Linq è stata un ottima innovazione , pare che ci sia un progetto analogo per java ma non ho mai approfondito
PS ignoranza mia: quali sono le piccole incongruenze che danno fastidio? SOno un amante dell'oop e mi hai incuriosito
||ElChE||88
26-07-2009, 20:16
C# è un linguaggio di programmazione nello stesso senso in cui la bestemmia è un modo di esprimersi: tecnicamente è vero.
Ecco a voi l'intervento perfetto per iniziare un flame: critica costruttiva 0. Non si riesce proprio ad evitarlo, eh? :rolleyes:
PS ignoranza mia: quali sono le piccole incongruenze che danno fastidio? SOno un amante dell'oop e mi hai incuriosito
Prova a dare un occhiata qui: http://wiki.theory.org/YourLanguageSucks#PHP_sucks_because: (non sono sicuro se siano le incongruenze nominate in precedenza, ma qualcosa c'è :fagiano:)
beh...
magari tu sarai contento perchè ti hanno levato le closures da java 7, per me hanno fatto un'enorme cazzata invece, dopo essere diventato lambda-function dipendente col C#. :p
Mi limiterò a dire:
[K super Comparable => ? extends K, J => K extends J, T]
non uso ror ma lo conosco per fama e non posso che darti ragione sul discorso del tempo risparmiato, però vorrei farti riflettere sulla percentuale di diffusione del linguaggio, maggiore diffusione porta maggiore documentazione e supporto. inoltre per php ci sono moltissimi hosting anche gratuiti!
Ed è per questo che continuo ad usarlo per alcuni lavori ma il fatto che sia un pessimo linguaggio non cambia.
Il fatto che php non è nato con il supporto OOP ma lo hanno aggiunto in seguito NON rappresenta uno svantaggio, a meno che non inventiamo la macchina del tempo.
Ci sono però in giro milioni di righe di codice scritte coi piedi perché con la 4 non si poteva fare oop decentemente. Il non aver introdotto fin da subito una programmazione ad oggetti è stato un immenso errore degli autori di php.
PS ignoranza mia: quali sono le piccole incongruenze che danno fastidio? SOno un amante dell'oop e mi hai incuriosito
Vedi il link postato da ||ElChE||88
astorcas
26-07-2009, 20:23
...
1. Ha gli array
2. Ha i generici
3. Ha i primitivi
...
Posso chiederti perché sfortunatamente? Cosa non ti piace ad esempio dei generics?
cdimauro
26-07-2009, 20:39
Eh eh, la stringa. La stringa è delicata ma in tutte le lingue. Va bene il tipo di dato - come un qualsiasi altro tipo di dato - mentre il letterale è pericoloso. Basta un niente per tagliarsi le gambe. Ricordo la mitica transazione SAP per le verifiche inventariali con la sua bella etichetta "Differenzienlist Berbeiten", anche nella versione italiana.
Per fortuna non ho mai lavorato a SAP. :D
Comunque le stringhe le ho citate soltanto per rinvangare una delle nostre vecchie discussioni sulla "purezza" delle prospettive & relativi linguaggi. :)
SMi dispiace smontare la tua splendida intuizione , ma non sono un fanatico dell'open source.Nonostante ne sia un sostenitore al momento scrivo da windows e nella mia zona il 90% delle aziende usa .NET ecco perchè parlo di microsoft.
:fagiano:
Ho forse detto che qualcuno NON può esprimere i propri giudizi? no!
Veramente ognuno l'aveva fatto tranquillamente, finché sei arrivato tu a lamentarti.
Lo sto facendo anche io, mi segui?
Fallo coi linguaggi che non ti stanno simpatici allora.
è un problema se difendo ciò che mi piace? lo fai anche tu con python tanto da averlo nell'avatar :wtf:
Python non ha bisogno d'esser difeso, ma diffuso. :cool:
E ti sembra un buon motivo odiare un linguaggio perchè è brutto?
Sì.
Secondo me la bellezza è seconda alla curva di apprendimento e a tante altre cose, ma magari mi sbaglio!
In tal caso sarebbe interessante conoscere la curva d'apprendimento di Perl. Ho la NON vaga impressione che sia piuttosto tortuosa. :D
Un giorno incontrerò un cliente che vorrà incorniciare il codice sorgente del proprio sito e nel farlo mi dirà EH MA PHP è proprio brutto eh! Cosa direbbero quei poveri uomini che usavano assembly? Erano veramente persone senza un minimo di stile....
Anche nello scrivere codice assembly c'era stile. E che stile. :cool:
Non sono brutti sono degli aborti.
Basta solo il fatto che il PHP non è nemmeno nato come linguaggio ad oggetti e l'hanno aggiunto solo dopo. :Puke:
Quanto alla sintassi di perl lasciamo stare che è meglio va. :asd:
Ecco, appunto, perché non hai idea di come abbiano aggiunto gli "oggetti" a Perl. Ed è meglio per la tua sanità mentale che tu non lo sappia. :asd:
In tal caso sarebbe interessante conoscere la curva d'apprendimento di Perl. Ho la NON vaga impressione che sia piuttosto tortuosa. :D
Così? :asd:
http://img140.imageshack.us/img140/1552/perlo.jpg
Posso chiederti perché sfortunatamente? Cosa non ti piace ad esempio dei generics?
A un certo punto qualcuno è saltato fuori ed ha detto che i ClassCastException e gli ArrayStoreException erano "il problema" di chi sviluppava in Java.
Non si è mai capito perchè. C'erano miliardoni di messaggi nella bugparade ma quelli contavano meno.
Fatto sta che uno che usa Java oggi deve sapere quello che c'è scritto qua:
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
Sono 513 pagine di casi limite, sottigliezze, errori, differenze e chissà che altro.
513 pagine che hanno risolto il terribile problema che attanagliava milioni di programmatori Java di fronte ai monitor:
String s = (String)lista.get(10);
Ogni volta che ci penso mi sale un'incazzatura che non avete idea... :muro:
^TiGeRShArK^
26-07-2009, 21:05
Ecco, appunto, perché non hai idea di come abbiano aggiunto gli "oggetti" a Perl. Ed è meglio per la tua sanità mentale che tu non lo sappia. :asd:
Preferisco evitare. :O
Mi vengono i conati di vomito solo a pensare di dover leggere un programma scritto in perl. :asd:
Non che in java e in C# non si possa scrivere codice altrettanto orrendo, ma è MOOOLTO + difficile, ti ci devi proprio impegnare. :asd:
In perl invece ti esce praticamente naturale seguendo la filosofia del linguaggio. :asd:
morskott
26-07-2009, 21:37
A un certo punto qualcuno è saltato fuori ed ha detto che i ClassCastException e gli ArrayStoreException erano "il problema" di chi sviluppava in Java.
Non si è mai capito perchè. C'erano miliardoni di messaggi nella bugparade ma quelli contavano meno.
Fatto sta che uno che usa Java oggi deve sapere quello che c'è scritto qua:
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
Sono 513 pagine di casi limite, sottigliezze, errori, differenze e chissà che altro.
513 pagine che hanno risolto il terribile problema che attanagliava milioni di programmatori Java di fronte ai monitor:
String s = (String)lista.get(10);
Ogni volta che ci penso mi sale un'incazzatura che non avete idea... :muro:
Per evitare qualcosa di questo genere
public void a(){
List b=new List();
b.add(new Cat());
b.add(new Dog());
b.add(new Whale());
c(b);
}
public void c(List iWantOnlyHouses){
//code that needs a list of houses
}e far capire l'errore solo a runtime.
Come esempio può essere leggermente estremizzato, ma fa capire il perchè dei generics che trovo invece utilissimi e fondamentali per la correttezza non solo sintattica ma anche semantica del codice!!!
Nell'orientamento agli oggetti si risolve dichiarando una lista di case con la composizione e rinvio.
morskott
26-07-2009, 21:52
Nell'orientamento agli oggetti si risolve dichiarando una lista di case con la composizione e rinvio.
??? cosa sarebbero?
Comunque il codice sarebbe legalissimo per il compilatore (ovviamente genererà ClassCastException a runtime), quindi la scoperta dell'errore avverrebbe solo dopo che il codice venga runnato/testato. Altro caso: da una javadoc fatta alla cavolo (senza spiegazioni sui parametri) di un programmatore che manco conosco vedo la segnatura del metodo "c" e basta, bene, che List ci dovrei passare?
non é la stessa cosa, é un workaround lungo ed operoso. tra l'altro (mi viene in mente solo ora) altra cosa molto antipatica, almeno per me, é che in Java le classi ereditano tutto pubblicamente; in C++ invece é possibile ereditare con specificatori di visibilitá (private, protected, public).
E' un workaround se vuoi convertire una ereditarietà multipla in Java. Ma se si progettano le classi in modo da non averla, il problema non si pone neanche.
é chiaro che per programmi non critici (che sono la stragrande maggioranza) i garbage collectors di Java vanno benissimo, ma ci sono programmi in cui vorresti evitare che il GC entrasse in azione in determinati momenti. in C++ usando degli scoped objects (magari anche una sola classe, sotto forma di template) puoi scrivere un GC personalizzato in pochi minuti mantenendo il controllo totale sulla scelta dei momenti opportuni per la deallocazione delle risorse dinamiche (ivi inclusi blocchi allocati con new). se invece non ti serve questo controllo eccezionale puoi usare una dei fottiliardi di classi di smart pointers scritte fino ad oggi, incluse auto_ptr delle librerie standard oppure CHeapPtr di ATL; questo equivale a dire che neanche in C++ devi porti il problema della deallocazione della memoria dinamica, basta che dichiari il tuo puntatore come auto_ptr<int> anziché int*, per esempio.
infine, se la risorsa dinamica di cui devi gestire la deallocazione non é un blocco di memoria dell'heap (ma é, ad esempio, un HANDLE Win32) allora puoi scrivere in pochissimo tempo una tua smart class, ma prima controlla che qualche framework non ne abbia giá (MFC ed ATL ad esempio offrono classi per wrappare qualunque HANDLE ti venga in mente).
aggiungo che il fatto che tu abbia usato la free in C++ mi suggerisce una certa ignoranza in materia da parte tua; in C++ si usano new e delete.
Quando ho scritto quel post non ero del tutto in me :D (pensavo di aver scitto più stupidaggini :asd:). Conosco new e delete. La mia ignoranza è comunque vasta, in quanto come detto, la mia conoscenza del c++ deriva dall'implementazione di un piccolo progetto universitario. E proprio per questo mi ha colpito negativamente la non immediatezza della deallocazione.
(Solo per la cronaca sulla deallocazione avevo aperto un thread qui: http://www.hwupgrade.it/forum/showthread.php?t=1782985)
e cosa sarebbero....Se hai una lista "generica" - nel senso che piglia tutto - e vuoi una lista specifica crei una diversa classe di liste dotandola di comportamenti omonimi operanti su oggetti diversi.
Esempio:
class Lista {
void add(Oggetto o) {}
}
A un certo punto uno dice: ok, io voglio lavorare su una lista ma non di qualsiasi cosa: di case.
class ListaDiCase {
private Lista lista = new Lista();
void add(Casa c) { lista.add(c); }
}
E avrai il tuo metodo:
public void faiQualcosa(ListaDiCase c) {}
Nota l'effetto: è identico alla parametrizzazione di un generico. Così come Lista non è compatibile con ListaDiCase pur avendo metodi con lo stesso nome allo stesso modo Lista<Object> non è compatibile con Lista<Case>.
Il fatto è che ciò che è evidente attraverso la sintassi diciamo "esplicita" o "verbosa" diventa rocket science coi generici. Lista<Object> non è compatibile con Lista<Case> a prescindere dalla relazione di Case con Object perchè Lista<T> non è un tipo ma è un operatore sui tipi.
Discorsi analoghi valgono per gli X extends Y o i mitici ? super/extends XYZ.
In teoria è molto bello avere un compilatore che controlla qualsiasi precondizione. In pratica uno deve valutare se il gioco valga la candela.
Perchè se posso fare:
T extends Comparable
allora posso ancha fare:
class Pippo<J extends Comparable<J>,K extends Comparable<? super Serializable>>
Solo che a questo punto devo anche sapere come mai Pippo<String, String> non è accettabile.
Facciamo il quizzone? Perchè String non è accettabile?
Suggerimento: type erasure e Classe<X> non è compatibile con Class<Y> a meno che X non sia strettamente di tipo Y.
morskott
26-07-2009, 23:05
Se hai una lista "generica" - nel senso che piglia tutto - e vuoi una lista specifica crei una diversa classe di liste dotandola di comportamenti omonimi operanti su oggetti diversi.
Esempio:
class Lista {
void add(Oggetto o) {}
}
A un certo punto uno dice: ok, io voglio lavorare su una lista ma non di qualsiasi cosa: di case.
class ListaDiCase {
private Lista lista = new Lista();
void add(Casa c) { lista.add(c); }
}
E avrai il tuo metodo:
public void faiQualcosa(ListaDiCase c) {}
Nota l'effetto: è identico alla parametrizzazione di un generico. Così come Lista non è compatibile con ListaDiCase pur avendo metodi con lo stesso nome allo stesso modo Lista<Object> non è compatibile con Lista<Case>.
Il fatto è che ciò che è evidente attraverso la sintassi diciamo "esplicita" o "verbosa" diventa rocket science coi generici. Lista<Object> non è compatibile con Lista<Case> a prescindere dalla relazione di Case con Object perchè Lista<T> non è un tipo ma è un operatore sui tipi.
Discorsi analoghi valgono per gli X extends Y o i mitici ? super/extends XYZ.
In teoria è molto bello avere un compilatore che controlla qualsiasi precondizione. In pratica uno deve valutare se il gioco valga la candela.
Perchè se posso fare:
T extends Comparable
allora posso ancha fare:
class Pippo<J extends Comparable<J>,K extends Comparable<? super Serializable>>
Solo che a questo punto devo anche sapere come mai Pippo<String, String> non è accettabile.
Facciamo il quizzone? Perchè String non è accettabile?
Suggerimento: type erasure e Classe<X> non è compatibile con Class<Y> a meno che X non sia strettamente di tipo Y.
Si, delle volte i generics danno dei mal di testa, ma per fare tramite composizione devi comunque scriverti una tua classe ex-novo, List<Houses> è tutto già scritto, il che è un bel vantaggio!!! Poi se la tua lista la devi passare ad un metodo non tuo che usa una List (generizzata o meno) devi comunaue fare metodi di conversione che non ti servirebbero in caso di generics (e qua mi potresti ribattere che stavamo parlando della "correttezza formale", non dei casi di merging di piu codici).
cdimauro
27-07-2009, 07:30
È normale che ci siano similitudini tra i due linguaggi visto che hanno dei parenti in comune. PHP però, a differenza di Java, è pieno di piccole incongruenze e difetti che a molti danno veramente fastidio.
A me sembra che i "progettisti" (lo metto tra virgolette per non offendere la categoria :D) del PHP abbiano preso a piene mani da Java per il modello a oggetti.
Così? :asd:
http://img140.imageshack.us/img140/1552/perlo.jpg
Ecco perché Debian continua a non piacermi. :p
A un certo punto qualcuno è saltato fuori ed ha detto che i ClassCastException e gli ArrayStoreException erano "il problema" di chi sviluppava in Java.
Non si è mai capito perchè. C'erano miliardoni di messaggi nella bugparade ma quelli contavano meno.
Fatto sta che uno che usa Java oggi deve sapere quello che c'è scritto qua:
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
Sono 513 pagine di casi limite, sottigliezze, errori, differenze e chissà che altro.
513 pagine che hanno risolto il terribile problema che attanagliava milioni di programmatori Java di fronte ai monitor:
String s = (String)lista.get(10);
Ogni volta che ci penso mi sale un'incazzatura che non avete idea... :muro:
La colpa è tua, che sei troppo sempliciotto. In realtà ci sono vagonate di persone che adorano complicarsi la vita, e quella FAQ soddisfa il loro desiderio di profondo autolesionismo. :O
Preferisco evitare. :O
Mi vengono i conati di vomito solo a pensare di dover leggere un programma scritto in perl. :asd:
Non che in java e in C# non si possa scrivere codice altrettanto orrendo, ma è MOOOLTO + difficile, ti ci devi proprio impegnare. :asd:
In perl invece ti esce praticamente naturale seguendo la filosofia del linguaggio. :asd:
Concordo. E rilancio mostrandoti una foto di quando studiavo Perl:
http://files.splinder.com/abe0664ee7502ae39fe06db708edd12c.jpeg
Se hai una lista "generica" - nel senso che piglia tutto - e vuoi una lista specifica crei una diversa classe di liste dotandola di comportamenti omonimi operanti su oggetti diversi.
Esempio:
class Lista {
void add(Oggetto o) {}
}
A un certo punto uno dice: ok, io voglio lavorare su una lista ma non di qualsiasi cosa: di case.
class ListaDiCase {
private Lista lista = new Lista();
void add(Casa c) { lista.add(c); }
}
E avrai il tuo metodo:
public void faiQualcosa(ListaDiCase c) {}
Nota l'effetto: è identico alla parametrizzazione di un generico. Così come Lista non è compatibile con ListaDiCase pur avendo metodi con lo stesso nome allo stesso modo Lista<Object> non è compatibile con Lista<Case>.
Il fatto è che ciò che è evidente attraverso la sintassi diciamo "esplicita" o "verbosa" diventa rocket science coi generici. Lista<Object> non è compatibile con Lista<Case> a prescindere dalla relazione di Case con Object perchè Lista<T> non è un tipo ma è un operatore sui tipi.
A me pare un'inutile complicazione. Ci sono i generic, perché non usarli? Solo perché Sun s'è "dimenticata" di aggiornare la JVM per supportare correttamente questo strumento (conservando anche il tipo degli oggetti)?
Discorsi analoghi valgono per gli X extends Y o i mitici ? super/extends XYZ.
In teoria è molto bello avere un compilatore che controlla qualsiasi precondizione. In pratica uno deve valutare se il gioco valga la candela.
Perchè se posso fare:
T extends Comparable
allora posso ancha fare:
class Pippo<J extends Comparable<J>,K extends Comparable<? super Serializable>>
Solo che a questo punto devo anche sapere come mai Pippo<String, String> non è accettabile.
Facciamo il quizzone? Perchè String non è accettabile?
Suggerimento: type erasure e Classe<X> non è compatibile con Class<Y> a meno che X non sia strettamente di tipo Y.
Ti spiace se ti dico che mi sono fermato al <J della definizione di Pippo? Per me quello è codice altamente illegibile, e non riesco proprio a farmelo digerire. :stordita:
fdfdfdddd
27-07-2009, 08:17
I linguaggi che più amo (ho amato) sono:
1) Pascal
2) C#
3) C
Quelli che ho più odiato:
1) PHP
2) Il basic di HP AssetCenter
3) Visual Basic 6
Il Pascal sta li in cima per un fattore "sentimentale" ... il primo amore non si scorda mai :-p
@PGI-Bis: non vorrei sbagliarmi ma i Generics sono stati introdotti per motivi prestazionali, in particolare per evitare boxing e unboxing.
Se ci sono eccezioni particolari nell'uso dei Generics in Java il problema è della implementazione che ne ha fatto Java non dei Generics di per se.
Un piccolo OT per cdimauro: sto studiando python, ma si possono aggiungere variabili di instanza agli oggetti anche dall'esterno della classe? Mi sembra un po' una pazzia questa cosa :D. Tra l'altro non ci sono accessors per le variabili di istanza?
class Persona: pass
p = Persona()
p.nome = "Giulio"
fatmatto
27-07-2009, 09:34
Fallo coi linguaggi che non ti stanno simpatici allora.
questa risposta non ha senso :mbe:
Sì.
Come vuoi ma la mia reazione è BAH XD
In tal caso sarebbe interessante conoscere la curva d'apprendimento di Perl. Ho la NON vaga impressione che sia piuttosto tortuosa. :D
è un linguaggio di scripting cosa c'è di tortuoso? ah si le regexp e basta. E comunque mi riferivo a php
cdimauro
27-07-2009, 09:47
Un piccolo OT per cdimauro: sto studiando python, ma si possono aggiungere variabili di instanza agli oggetti anche dall'esterno della classe? Mi sembra un po' una pazzia questa cosa :D. Tra l'altro non ci sono accessors per le variabili di istanza?
class Persona: pass
p = Persona()
p.nome = "Giulio"
Sì, è possibilissimo. Python è un linguaggio dinamico, e permettere di aggiungere variabili / membri a runtime sia alle classi che alle singole istanze (tranne per le classi built-in).
Questo è possibile farlo direttamente (come nel tuo codice; questo perché gli attributi sono pur sempre contenuti in un apposito dizionario, e in Python questi sono oggetti modificabili) oppure tramite appositi metodi speciali.
Inoltre puoi creare delle proprietà che regolano l'accesso a particolari risorse.
questa risposta non ha senso :mbe:
Non ha senso nemmeno questo thread, visto che la simpatia / antipatia per un linguaggio è una questione soggettiva e pure irrazionale. :D
Come vuoi ma la mia reazione è BAH XD
Sopravviverò lo stesso.
è un linguaggio di scripting cosa c'è di tortuoso?
La sintassi, come abbiamo già detto in molti.
ah si le regexp e basta.
Quelle sono poco leggibili a prescindere dal linguaggio.
E comunque mi riferivo a php
Che c'entrano le regexpr, allora? Perl incorpora appositi elementi sintattici per manipolare le espressioni regolari, mentre con PHP devi far uso di apposite funzioni, similmente agli altri linguaggi di programmazione (Ruby escluso, che da questo punto di vista è Perl-ish).
Comunque anche PHP ha le sue idiosincrasie. Leggiti il link su YourLanguageSucks, che è stato segnalato prima (anche se ammetto di esser di parte, visto che la maggior parte di quelle cose le ho scritte io :asd:).
yorkeiser
27-07-2009, 09:54
1) Cobol
2) JavaScript
3) Prolog
E tralascio XML solo perchè non è un linguaggio di programmazione.
Ma sopratutto quanto odio questa moda di voler spostare tutto sul web!!!!!!
*
astorcas
27-07-2009, 10:04
Io direi....
1)PHP
2)JAVASCRIPT
3)CSS <--- posso vero?
4)BASH
cdimauro
27-07-2009, 10:23
No, CSS non mi pare sia un linguaggio di programmazione. :D
Uhm...
1) Cobol
2) Pascal
3) Java
astorcas
27-07-2009, 10:26
No, CSS non mi pare sia un linguaggio di programmazione. :D
:( ok :mc:
banryu79
27-07-2009, 12:01
Fatto sta che uno che usa Java oggi deve sapere quello che c'è scritto qua:
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
Sono 513 pagine di casi limite, sottigliezze, errori, differenze e chissà che altro.
Sì però guardiamo anche l'aspetto positivo della faccenda: quella Angelika oltre a spiegare il casino dei Generics con dovizia di particolari è proprio una bella donna (vedere home page) :D
Io penso che un linguaggio è costituito da sintassi e semantica, e che dal "comportamento" di un'implementazione nulla si possa attribuire al linguaggio di per sé.
Ciò che hai riportato riguarda, appunto, implementazioni attuali.
Tanto per fare un esempio, nessuno m'impedisce di scrivere un compilatore C che genera il codice delle funzioni in posizioni pseudocasuali all'interno del codice oggetto finale. a parte il fatto che non si stava parlando di posizione ma di sezione (poi all'interno di una certa sezione il codice puó stare nella posizione che gli pare, l'importante sono i flag associati alla sezione), COMUNQUE: il fatto é che il C, con i suoi costrutti relativamente semplici*, si presta infinitamente meglio del C++ al controllo del codice generato, e tale controllo é indispensabile a causa di certe limitazioni presenti nell'ambiente del kernel, come il fatto di non poter eseguire codice paginabile al di sopra del DISPATCH_LEVEL o il non poter usare oltre un certo tot limitato di stack.
*come complessitá del linguaggio stiamo parlando praticamente di un BASIC con un sistema di tipi.
Come posso scrivere un compilatore C++ che riesce a controllare in maniera assolutamente precisa la posizione di qualunque risorsa dovrà generare. sono fantasie, potrebbe anche esistere ma non esiste. la situazione attuale é quella determinata dalla mia affermazione iniziale: non é quasi mai possibile scrivere drivers per Windows in C++. tutt'al piu ti concedo una piccola rettifica: "possibile/assennato" al posto di "possibile" (perché magari pur essendo possibile non é assennato, nel senso che a conti fatti serve meno fatica col C).
inoltre non é il collocamento di ogni singolo pezzo di codice eseguito l'unico problema dell'usare il C++ in kernel-mode, in un post precedente ti ho citato anche l'usura dello stack data da oggetti temporanei e grossi record necessari ad implementare le eccezioni C++ (con il corretto stack unwinding); se quei record sono necessari vuol dire che meglio di cosi non si puó fare: non credo che il compilatore Microsoft si metta a scrivere roba inutile sullo stack, quindi non esisterá mai un mondo in cui potrai felicemente usare le eccezioni C++ in un kernel driver per Windows.
Un esempio "real world" è AmigaOS, dove coi compilatori a disposizione potevo specificare quali tipi di memoria utilizzare per specifiche porzioni di codice/dati/BSS. Ciò si rendeva indispensabile a causa della presenza di due tipi di memoria molto diversi: la chip ram (l'unica accessibile dal chipset) e la fast ram (accessibile esclusivamente dalla CPU e da periferiche che non fossero il chipset). non conosco assolutamente, ma sicuramente il formato dell'eseguibile finale era diverso e quindi era tutta un'altra questione.
Così? :asd:
http://img140.imageshack.us/img140/1552/perlo.jpg ROTFL!!! :rotfl:
forse usi Windows e non hai presente, comunque Linux offre delle funzioni (syscall) richiamabili tramite interrupt ed eseguibili dall'assembly.
...
questo è il file che si trova in /usr/include/asm/unistd_32.
e ce n'è un altro per le architetture a 64 bit
senza l'assembly non saprei come richiamarle, per questo ho scritto che l'assembly è utile per richiamare le syscall non rispondo per pietá :asd: specialmente leggendo quello che é venuto fuori piu avanti :rotfl:
Se fosse veramente così vedresti sistemi attuali (processori che supportano l'NX Bit) dove gli exploit non esisterebbero - cosa piu sbagliata non esiste, basta che ti guardi attorno. lo so perfettamente che é una cosa sbagliata, infatti gli exploit esisteranno sempre: sará anche possibile eliminare totalmente le vulnerabilitá legate alla gestione della memoria, come accade (sperabilmente) nei programmi managed, ma non sará mai possibile eliminare del tutto i potenziali errori logici nel programma, errori tipo la SQL Injection per fare un esempio comune.
In realtà l'NX Bit riesce a coprire solo uno dei possibili modi di sfruttare un attacco causato da buffer overflow (e se configurato bene). Ci sono almeno altre due tipologie di attacchi dove l'NX Bit è totalmente inoffensivo e inutile. e cioé?
C# è un gradino superiore rispetto a Java grazie a LINQ. C# é un gradino superiore rispetto a Java grazie a tutta la piattaforma .NET, non solo LINQ. WCF pwna di brutto RMI e WPF si pulisce il didietro usando Swing come carta igienica. si dia inizio alle danze :asd:
PS: anzi, per pwnare RMI non era necessario WCF, bastava giá DCOM da solo (tecnologia degli anni 90, non so se mi spiego).
e cioé?
return-to-libc (http://en.wikipedia.org/wiki/Return-to-libc_attack)
SEH exploitation (http://www.secuobs.com/revue/news/117233.shtml)
cdimauro
27-07-2009, 13:23
a parte il fatto che non si stava parlando di posizione ma di sezione (poi all'interno di una certa sezione il codice puó stare nella posizione che gli pare, l'importante sono i flag associati alla sezione),
La posizione è un termine a granularità più fine rispetto al concetto di sezione, e permette di ottimizzare meglio il codice. Se, ad esempio, disponessi il codice in maniera pseudocasuale all'interno di una precisa sezione, potrei generare parecchi page miss e degradare le prestazioni.
COMUNQUE: il fatto é che il C, con i suoi costrutti relativamente semplici*, si presta infinitamente meglio del C++ al controllo del codice generato, e tale controllo é indispensabile a causa di certe limitazioni presenti nell'ambiente del kernel, come il fatto di non poter eseguire codice paginabile al di sopra del DISPATCH_LEVEL o il non poter usare oltre un certo tot limitato di stack.
*come complessitá del linguaggio stiamo parlando praticamente di un BASIC con un sistema di tipi.
Che il C si presti meglio non l'ho mai negato, ma continuiamo a parlare di implementazioni e non del linguaggio di per sé.
sono fantasie, potrebbe anche esistere ma non esiste.
Quindi per te l'unica cosa degna di nota è quella che esiste? Bene, buttiamo a mare anche la macchina di Turing, visto che ci siamo...
la situazione attuale é quella determinata dalla mia affermazione iniziale: non é quasi mai possibile scrivere drivers per Windows in C++. tutt'al piu ti concedo una piccola rettifica: "possibile/assennato" al posto di "possibile" (perché magari pur essendo possibile non é assennato, nel senso che a conti fatti serve meno fatica col C).
Io aggiungerei: "allo stato attuale (dei compilatori)".
inoltre non é il collocamento di ogni singolo pezzo di codice eseguito l'unico problema dell'usare il C++ in kernel-mode, in un post precedente ti ho citato anche l'usura dello stack data da oggetti temporanei e grossi record necessari ad implementare le eccezioni C++ (con il corretto stack unwinding); se quei record sono necessari vuol dire che meglio di cosi non si puó fare: non credo che il compilatore Microsoft si metta a scrivere roba inutile sullo stack, quindi non esisterá mai un mondo in cui potrai felicemente usare le eccezioni C++ in un kernel driver per Windows.
Non sei obbligato a utilizzare le eccezioni, di cui comunque hai un completo controllo.
C++ != C + eccezioni
non conosco assolutamente, ma sicuramente il formato dell'eseguibile finale era diverso e quindi era tutta un'altra questione.
Infatti non lo era: http://en.wikipedia.org/wiki/Amiga_Hunk
E l'Amiga era una macchina reale, non teorica.
Fermo restando che a me interessano tanto le implicazioni pratiche che quelle teoriche. Lo stato dell'arte attuale nulla toglie alle potenzialità dello strumento, né tanto meno si può utilizzare per restringere il suo potere espressivo.
anonimizzato
27-07-2009, 13:32
Io direi....
3)CSS <--- posso vero?
:nonsifa:
Più che altro il problema dei CSS è il supporto tra browser, come per JS.
La posizione è un termine a granularità più fine rispetto al concetto di sezione, e permette di ottimizzare meglio il codice. Se, ad esempio, disponessi il codice in maniera pseudocasuale all'interno di una precisa sezione, potrei generare parecchi page miss e degradare le prestazioni. e quindi, tornando al discorso?
Che il C si presti meglio non l'ho mai negato, ma continuiamo a parlare di implementazioni e non del linguaggio di per sé. possiamo anche fantasticare di implementazioni ipotetiche se vuoi (al Nord la chiamano fuffa). tu comincia pure che io ti raggiungo.
Quindi per te l'unica cosa degna di nota è quella che esiste? anche si... :fagiano:
Bene, buttiamo a mare anche la macchina di Turing, visto che ci siamo... mi spiace ma caschi malissimo :asd:
http://www.youtube.com/watch?v=cYw2ewoO6c4
Non sei obbligato a utilizzare le eccezioni, di cui comunque hai un completo controllo.
C++ != C + eccezioni cosi come non sono obbligato a usare gli scoped objects, a usare new e delete, a creare oggetti temporanei e a fare un sacco di altre cose, siamo d'accordissimo. quello che resta mi ricorda molto il C.
Infatti non lo era: http://en.wikipedia.org/wiki/Amiga_Hunk non so il tuo Windows ma il mio non usa neanche lontanamente quella roba.
quasi dimenticavo:
C++ != C + eccezioni risulta false solo se preceduto da:
int C = ... ; //valore qualunque
int eccezioni = 1;
ok, scusatemi :asd:
cdimauro
27-07-2009, 13:58
e quindi, tornando al discorso?
Posizione è un termine che abbraccia anche quello di sezione. Più generale, quindi.
possiamo anche fantasticare di implementazioni ipotetiche se vuoi (al Nord la chiamano fuffa). tu comincia pure che io ti raggiungo.
L'ho già fatto e mi sembra sufficientemente chiaro il discorso. Per chi lo vuol capire, ovviamente.
anche si... :fagiano:
OK, allora quando parli di C riporta s.o, architettura e compilatore.
Perché il C, come linguaggio, non ha nulla a che spartire coi dettagli specifici di una sua implementazione.
mi spiace ma caschi malissimo :asd:
http://www.youtube.com/watch?v=cYw2ewoO6c4
http://it.wikipedia.org/wiki/Macchina_di_Turing
"Caratteristica delle MdT è quella di disporre di un nastro potenzialmente infinito, cioè estendibile quanto si vuole qualora questo si renda necessario."
cosi come non sono obbligato a usare gli scoped objects, a usare new e delete, a creare oggetti temporanei e a fare un sacco di altre cose, siamo d'accordissimo. quello che resta mi ricorda molto il C.
Non lo metto in dubbio, se non sai come ridefinire opportunamente gli handler di de/allocazione della memoria del C++.
Mi sembra di sentir parlare Torvalds...
non so il tuo Windows ma il mio non usa neanche lontanamente quella roba.
Qui l'unico che continua a parlare di precise implementazioni sei tu.
Io fin dall'inizio ho parlato di C/C++ come LINGUAGGIO, per il quale sono definite esclusivamente SINTASSI e SEMANTICA.
Sulle IMPLEMENTAZIONI dei compilatori per Amiga era possibile definire opportunatamente le sezioni in cui far confluire il codice.
Il che dimostra che gli esempi che ho fatto sono REALI, per gli informatici che sanno ragiorare soltanto in questi termini...
Posizione è un termine che abbraccia anche quello di sezione. Più generale, quindi. ancora non riesco a collegare col discorso della performance, comunque... ok... é una generalitá inutile visto che per non dare BSOD nella circostanza che stavamo discutendo era sufficiente che il codice eseguito stesse in una sezione marcata IMAGE_SCN_MEM_NOT_PAGED, ma vabbé.
OK, allora quando parli di C riporta s.o, architettura e compilatore. il sistema operativo l'ho specificato molto chiaramente; il compilatore l'ho specificato imlicitamente (se tenti di programmare drivers con un kit diverso dal WDK originale sei solo masochista); l'architettura non c'é bisogno di specificarla perché i drivers ben scritti hanno sorgente portabile, infatti possono funzionare anche sulle architetture a 64 bit.
http://it.wikipedia.org/wiki/Macchina_di_Turing
"Caratteristica delle MdT è quella di disporre di un nastro potenzialmente infinito, cioè estendibile quanto si vuole qualora questo si renda necessario." 1:45 :asd:
l'apparecchio che vedi non sará una vera macchina di Turing ma é un'ottima approssimazione, anche considerando che per allungare il nastro puoi ordinare alla LEGO tutti i pezzi che vuoi :D
Non lo metto in dubbio, se non sai come ridefinire opportunamente gli handler di de/allocazione della memoria del C++. dopodiché ti ci voglio a debuggare senza i tag. il link che ti ho dato non devi solo conoscerlo, devi anche leggerlo, altrimenti mi continui a fare fuffa.
Qui l'unico che continua a parlare di precise implementazioni sei tu. sei tu che continui a non parlare di precise implementazioni, io ho cominciato parlando di Windows: non é del tutto vero: non é quasi mai possibile usare il C++ per scrivere drivers per Windows.
Io fin dall'inizio ho parlato di C/C++ come LINGUAGGIO, il tuo inizio non esiste, ho iniziato io e ho parlato di Windows. il contesto del WDK era palese per chi abbia una vaga idea di cosa si stava parlando; chi invece non ce l'ha cerca di fare riferimento alla sua cultura generale, che equivale a dire che rimedia un sacco di fuffa.
Sulle IMPLEMENTAZIONI dei compilatori per Amiga era possibile definire opportunatamente le sezioni in cui far confluire il codice. e a me? io stavo parlando di tutt'altro...
Il che dimostra che gli esempi che ho fatto sono REALI, per gli informatici che sanno ragiorare soltanto in questi termini... se per parlare dei drivers in Windows tu mi citi l'Amiga (:rotfl: ) mi dimostri solamente che non ne sai niente, perdonami. i tuoi esempi saranno anche molto interessanti ma stai sicuro che non riuscirai a programmare in C++ un driver per Windows completo e funzionante.
cdimauro
27-07-2009, 15:57
ancora non riesco a collegare col discorso della performance, comunque...
Scrivendo due funzioni vicine, generalmente ci si aspetta che lo sia anche il loro codice nel codice oggetto generato. Quindi si può organizzare il codice facendo sì che funzioni richiamate più o meno nello stesso "periodo" si trovino nelle stesse pagine di memoria.
Se invece il loro codice fosse distribuito in maniera più o meno casuale, i page miss aumenterebbero (come pure i TLB miss).
ok... é una generalitá inutile visto che per non dare BSOD nella circostanza che stavamo discutendo era sufficiente che il codice eseguito stesse in una sezione marcata IMAGE_SCN_MEM_NOT_PAGED, ma vabbé.
Per questo avevo parlato di posizione (del codice). In linea con quanto stavamo discutendo, quindi.
il sistema operativo l'ho specificato molto chiaramente; il compilatore l'ho specificato imlicitamente (se tenti di programmare drivers con un kit diverso dal WDK originale sei solo masochista);
Di questo ne parlo dopo.
l'architettura non c'é bisogno di specificarla perché i drivers ben scritti hanno sorgente portabile, infatti possono funzionare anche sulle architetture a 64 bit.
Quindi anche su Itanium e ARM. Esistono versioni di Windows anche per questi microprocessori (e, prima ancora, anche per l'Alpha della Digital).
1:45 :asd:
l'apparecchio che vedi non sará una vera macchina di Turing ma é un'ottima approssimazione, anche considerando che per allungare il nastro puoi ordinare alla LEGO tutti i pezzi che vuoi :D
Che sono... illimitati suppongo.
dopodiché ti ci voglio a debuggare senza i tag. il link che ti ho dato non devi solo conoscerlo, devi anche leggerlo, altrimenti mi continui a fare fuffa.
Gli handler ridefiniti si possono usare? Si o no.
sei tu che continui a non parlare di precise implementazioni, io ho cominciato parlando di Windows:
il tuo inizio non esiste, ho iniziato io e ho parlato di Windows. il contesto del WDK era palese per chi abbia una vaga idea di cosa si stava parlando; chi invece non ce l'ha cerca di fare riferimento alla sua cultura generale, che equivale a dire che rimedia un sacco di fuffa.
e a me? io stavo parlando di tutt'altro...
se per parlare dei drivers in Windows tu mi citi l'Amiga (:rotfl: ) mi dimostri solamente che non ne sai niente, perdonami. i tuoi esempi saranno anche molto interessanti ma stai sicuro che non riuscirai a programmare in C++ un driver per Windows completo e funzionante.
Ti ricordo il post da cui è partito tutto: http://www.hwupgrade.it/forum/showpost.php?p=28338971&postcount=7
"Vero. Però la "bruttezza" del c++ è dovuta a ben due buone ragioni:
1) Permette di lavorare a basso livello"
a cui tu hai risposto con quella frase e dai cui è scaturito il mio "perché?".
Si parlava del LINGUAGGIO C++, non di particolari implementazioni. Come del resto s'è fatto per tutto il thread (io non ho parlato di CPython, Stackless, PyPy, IronPython, ecc., ma soltanto di Python; né tanto meno ho fatto distinzioni fra le particolari architetture o s.o., che hanno pure loro delle differenze).
Sei TU che hai riportato il caso di UNA particolare implementazione del C++ (su una piattaforma), che nulla dice sul linguaggio DI PER SE'.
E messaggi che ho scritto, esempi inclusi, avevano tutti un solo scopo: farti notare che la fuffa sul C++ l'hai scritta tu, pretendendo di prendere un caso particolare e assurgerlo alla generalità, cioé al linguaggio (era di questo si stava parlando).
Il contesto di una discussione non puoi prenderlo da dove ti pare, cioé da dove ti fa più comodo.
quasi dimenticavo:
risulta false solo se preceduto da:
int C = ... ; //valore qualunque
int eccezioni = 1;
ok, scusatemi :asd:
Uh? :confused: Sicuro?
Scrivendo due funzioni vicine, generalmente ci si aspetta che lo sia anche il loro codice nel codice oggetto generato. Quindi si può organizzare il codice facendo sì che funzioni richiamate più o meno nello stesso "periodo" si trovino nelle stesse pagine di memoria.
Se invece il loro codice fosse distribuito in maniera più o meno casuale, i page miss aumenterebbero (come pure i TLB miss).
Per questo avevo parlato di posizione (del codice). In linea con quanto stavamo discutendo, quindi. su questo ramo della discussione do' forfait: ho il fumo negli occhi, é mezz'ora che cerco di capire cosa risponderti, non capisco come ci siamo arrivati ma pazienza visto che sono d'accordo su quanto dici :asd:
Quindi anche su Itanium e ARM. su Itanium assolutamente si, su ARM invece no perché il WDK (che tu evidentemente non conosci, altrimenti non cercheresti di sincerarti di queste cose, e te lo faccio notare per farti capire che stai cercando di discutere di cose che non conosci) non permette di programmare drivers per Windows Mobile. non conosco l'architettura di questo sistema ma so che si tratta di un kernel completamente a parte, semplicemente utilizza lo stesso formato PE per gli eseguibili e ha dei layer di compatibilitá Win32 e .NET (incompleti per ovvi motivi).
Che sono... illimitati suppongo. virtualmente illimitati :Prrr:
diciamo che una macchina di Turing puó modellare perfettamente qualunque situazione reale che tu possa mai raggiungere usando l'apparecchio che vedi nel video, il quale a sua volta ne é un'ottima approssimazione.
Gli handler ridefiniti si possono usare? Si o no. supponendo che per "handler ridefiniti" tu intenda degli overload degli operatori new e delete scritti dal programmatore, si. ma difficilmente arriverai a completare il tuo software cosi (non credere di poter programmare un kernel driver senza mai debuggare).
Ti ricordo il post da cui è partito tutto: http://www.hwupgrade.it/forum/showpost.php?p=28338971&postcount=7
"Vero. Però la "bruttezza" del c++ è dovuta a ben due buone ragioni:
1) Permette di lavorare a basso livello"
a cui tu hai risposto con quella frase e dai cui è scaturito il mio "perché?".
Si parlava del LINGUAGGIO C++, non di particolari implementazioni. Come del resto s'è fatto per tutto il thread (io non ho parlato di CPython, Stackless, PyPy, IronPython, ecc., ma soltanto di Python; né tanto meno ho fatto distinzioni fra le particolari architetture o s.o., che hanno pure loro delle differenze). e quindi? questo toglie validitá alla mia affermazione? (mi riferisco a quella a cui hai risposto col perché).
Sei TU che hai riportato il caso di UNA particolare implementazione del C++ (su una piattaforma), che nulla dice sul linguaggio DI PER SE'. indipendentemente da cosa dica costituiva una risposta valida all'affermazione originale secondo cui il C++ permette di lavorare a basso livello. no, non é vero: non sempre il C++ permette di lavorare a basso livello. il kernel di Windows é un livello bassissimo, eppure in C++ non ci puoi lavorare.
E messaggi che ho scritto, esempi inclusi, avevano tutti un solo scopo: farti notare che la fuffa sul C++ l'hai scritta tu, pretendendo di prendere un caso particolare e assurgerlo alla generalità, cioé al linguaggio (era di questo si stava parlando).
Il contesto di una discussione non puoi prenderlo da dove ti pare, cioé da dove ti fa più comodo. perfetto, grazie mille. ma la prossima volta non discutere di cose che non conosci e arriva dritto al dunque, perché altrimenti mi fai solo perdere tempo. addio.
Uh? :confused: Sicuro? ops, hai ragione, era un post-incremento :fagiano:
inoltre non é il collocamento di ogni singolo pezzo di codice eseguito l'unico problema dell'usare il C++ in kernel-mode, in un post precedente ti ho citato anche l'usura dello stack data da oggetti temporanei e grossi record necessari ad implementare le eccezioni C++ (con il corretto stack unwinding); se quei record sono necessari vuol dire che meglio di cosi non si puó fare: non credo che il compilatore Microsoft si metta a scrivere roba inutile sullo stack, quindi non esisterá mai un mondo in cui potrai felicemente usare le eccezioni C++ in un kernel driver per Windows.
Usare il C++ non vuol necessariamente dover utilizzarne tutte le features. Anzi, una delle caratteristiche del C++ e' proprio la possibilita' di scegliere solo il subset che serve e non dover "pagare" per le features che si ignorano. Se il framework in cui gira il driver e' scritto in C ad esempio, e' decisamente poco utile usare le eccezioni, visto che comunque dovra' gestirsele tutte il driver; piu' utile puo' essere usare con giudizio template per una migliore gestione dei tipi. L'usura dello stack e' un problema risibile; le strutture dati occupano spazio dello stack anche in C, e se non uso le eccezioni non vado a consumare spazio in piu'.
Se la Microsoft facesse le cose bene anche il maggior costo dovuto all'uso di certe features sarebbe inferiore.
indipendentemente da cosa dica costituiva una risposta valida all'affermazione originale secondo cui il C++ permette di lavorare a basso livello. no, non é vero: non sempre il C++ permette di lavorare a basso livello. il kernel di Windows é un livello bassissimo, eppure in C++ non ci puoi lavorare.
Il ragionamento non e' corretto. Il fatto che in un sistema operativo scrivere i driver in un certo linguaggio sia difficile, non vuol dire che in generale il linguaggio non sia adatto a fare programmazione di basso livello. Se non sei d'accordo, prova a scrivere in C un driver per una lisp machine, e poi ne riparliamo :D
Usare il C++ non vuol necessariamente dover utilizzarne tutte le features. Anzi, una delle caratteristiche del C++ e' proprio la possibilita' di scegliere solo il subset che serve e non dover "pagare" per le features che si ignorano. da un mio post precedente: cosi come non sono obbligato a usare gli scoped objects, a usare new e delete, a creare oggetti temporanei e a fare un sacco di altre cose, siamo d'accordissimo. quello che resta mi ricorda molto il C.
piu' utile puo' essere usare con giudizio template per una migliore gestione dei tipi. a parte che abbiamo praticamente eliminato le classi visto che abbiamo escluso l'uso di new, l'allocazione di oggetti sullo stack (e non solo per motivi di spazio) e non possiamo allocare oggetti con ExAllocatePoolWithTag o altre funzioni del kernel perché non avremmo supporto per costruttori e distruttori; comunque ok, credo che nei drivers per Windows sia possibile usare function templates.
L'usura dello stack e' un problema risibile; le strutture dati occupano spazio dello stack anche in C, e se non uso le eccezioni non vado a consumare spazio in piu'. infatti non é banalmente dichiarare una variabile di tipo struct o class che usura lo stack.
Se la Microsoft facesse le cose bene anche il maggior costo dovuto all'uso di certe features sarebbe inferiore. oh sciagura, ma perché non ci sei finito tu nel team del kernel di Windows anziché quegli incompetenti! :rolleyes:
Il fatto che in un sistema operativo scrivere i driver in un certo linguaggio sia difficile, non vuol dire che in generale il linguaggio non sia adatto a fare programmazione di basso livello. ma io non ho scritto questo...
da un mio post precedente:
Ed io ti ripeto che non usare una feature non vuol dire non usarne nemmeno una.
a parte che abbiamo praticamente eliminato le classi visto che abbiamo escluso l'uso di new, l'allocazione di oggetti sullo stack (e non solo per motivi di spazio) e non possiamo allocare oggetti con ExAllocatePoolWithTag o altre funzioni del kernel perché non avremmo supporto per costruttori e distruttori;
Classe factory templatizzata che astrae sia il tipo che l'allocatore. O in alternativa in strutture dati template aventi come argomento anche l'allocatore (in stile STL tanto per capirsi). Come risultato non e' molto diverso dalla controparte C ma ne guadagni in type safety. Non ho esperienza in merito sotto windows, ma si fa in altri sistemi operativi scritti in C e non vedo controindicazioni particolari.
infatti non é banalmente dichiarare una variabile di tipo struct o class che usura lo stack.
quali altri dati ingombranti ti trovi sullo stack, una volta che hai escluso le eccezioni ?
oh sciagura, ma perché non ci sei finito tu nel team del kernel di Windows anziché quegli incompetenti! :rolleyes:
Il fatto che alcune cose non vengano fatte bene non e' necessariamente una questione di competenza, puo' anche solo mancanza di interesse (anzi, probabilmente e' la ragione vera) da parte di MS. Questo non toglie che se volesse farlo e lo facesse, alcuni problemi evidenziati nell'articolo che avevi inizialmente linkato non si presenterebbero.
cdimauro
28-07-2009, 08:13
su questo ramo della discussione do' forfait: ho il fumo negli occhi, é mezz'ora che cerco di capire cosa risponderti, non capisco come ci siamo arrivati ma pazienza visto che sono d'accordo su quanto dici :asd:
Lo capirai quando avrai un'adeguata conoscenza di come funzionano le architetture degli elaboratori.
su Itanium assolutamente si, su ARM invece no perché il WDK (che tu evidentemente non conosci, altrimenti non cercheresti di sincerarti di queste cose, e te lo faccio notare per farti capire che stai cercando di discutere di cose che non conosci) non permette di programmare drivers per Windows Mobile. non conosco l'architettura di questo sistema ma so che si tratta di un kernel completamente a parte, semplicemente utilizza lo stesso formato PE per gli eseguibili e ha dei layer di compatibilitá Win32 e .NET (incompleti per ovvi motivi).
Ecco, se non lo conosci lascia perdere, che è meglio. Fino alla scorsa settimana lavoravo a un progetto per Windows Mobile, e "casualmente", guarda cosa si trova in
c:\Program Files\Microsoft SDKs\Windows\v6.1\Samples\WinBase\PNPX\SimpleThermostat\
Dal readme.htm:
PnP-X Simple Thermostat Sample
January 2007
Demonstrates
This sample demonstrates an end-to-end scenario using PnP-X. It includes device samples using UPnP and WSD, a driver to install the devices in PnP, proxies to talk with the devices, and a client application that uses the devices through the proxies. Developers will find this sample when implementing end-to-end scenarios using PnP-X or just implementing a small portions of a scenario, like a PnP-X compliant device.
Ma la cosa più interessante è questa:
Languages
C++
Ed è inutile che ti dica su quale CPU gira il codice, perché dovresti averlo già capito da solo.
virtualmente illimitati :Prrr:
diciamo che una macchina di Turing puó modellare perfettamente qualunque situazione reale che tu possa mai raggiungere usando l'apparecchio che vedi nel video, il quale a sua volta ne é un'ottima approssimazione.
Diciamo che una macchina di Turing NON è reale, ma un concetto astratto, e che non avrebbe diritto di esistere, a tuo dire.
Anzi, visto che ci siamo possiamo anche buttare l'intera teoria della computabilità (sulla quale è stata fondata l'informatica, ma questo è un dettaglio trascurabile), visto che si tratta di masturbazioni mentali di matematici che mal si conciliano con la finitezza del mondo reale col quale siamo costretti a lavorare tutti i giorni.
supponendo che per "handler ridefiniti" tu intenda degli overload degli operatori new e delete scritti dal programmatore, si.
E' già qualcosa. Bene.
Quanto agli "handler", non è una mia definizione. La trovi nel manuale di riferimento del C++: "The C++ Programming Language" di Bjarne Stroustrup, alle pagine 420-421 e 660 della terza edizione italiana.
ma difficilmente arriverai a completare il tuo software cosi (non credere di poter programmare un kernel driver senza mai debuggare).
Nella mia vita ho usato poco i debugger ("Il debugger è il male" - fek).
In ogni caso a me interessa se è possibile o meno fare una cosa. Ed è possibile, in linea teorica e pratica. Tanto basta.
e quindi? questo toglie validitá alla mia affermazione? (mi riferisco a quella a cui hai risposto col perché).
Sì, perché il contesto in cui l'hai espresso non si può bellamente ignorare.
Poi se prendiamo la tua sola frase estrapolandola dal suddetto contesto, ha una sua validità, benché sia viziata dall'implementazione, come ho già ripetuto in ogni messaggio che ho scritto in questa discussione sull'argomento.
indipendentemente da cosa dica costituiva una risposta valida all'affermazione originale secondo cui il C++ permette di lavorare a basso livello. no, non é vero: non sempre il C++ permette di lavorare a basso livello. il kernel di Windows é un livello bassissimo, eppure in C++ non ci puoi lavorare.
Su questo avevo già risposto, e sono perfettamente in linea con quanto riportato anche da marco.r.
perfetto, grazie mille. ma la prossima volta non discutere di cose che non conosci e arriva dritto al dunque, perché altrimenti mi fai solo perdere tempo. addio.
Ecco, allora tu comincia a farti una cultura su cos'è un linguaggio di programmazione e la differenza che passa con le sue implementazioni, cercando di non confondere i due termini e di non prendere il caso particolare di un'implementazione pretendendo di pontificare sull'intero linguaggio.
Magari una ripassata al manuale di riferimento del linguaggio male non ti farebbe.
devbeginner
28-07-2009, 10:10
E' il trappolone del sorriso, con la destra si stringe la mano mentre con la sinistra si cerca il coltello infilato nella cintura dietro la schiena.
http://img378.imageshack.us/img378/4360/cipollinoagguatowl5.gif
lol
io scriverei Java che è anche l'unico...ma in realtà sono io che non ci capisco una mazza...o almeno faccio fatica, trovo i testi che ho provato tutti difficili :cry:
Ho odiato le trasformazioni
XML + XSLT
Centra di sfuggita, ma mi faceva ridere
http://img.photobucket.com/albums/v314/gugogugo/fail-owned-cake-print-fail.jpg
Tanti auguri a te... tanti auguri a te.
non riesco a fermarmi dal ridere... pieta'.
Ed io ti ripeto che non usare una feature non vuol dire non usarne nemmeno una. quelle che ho elencato non mi sembravano "una", perció io ti ripeto che quello che resta mi ricorda molto il C: praticamente abbiamo un C coi tipi reference e i function templates. to', tutt'al piu restano ancora i namespaces: non so quanto possano risultare utili, il codice di un driver dovrebbe sempre avere una struttura ben precisa specifica del tipo di driver, tanto che sono stati standardizzati non solo i nomi delle routines esportate ma in alcuni casi addirittura quelli delle routines ad uso interno del driver (naturalmente é solo un consiglio dettato da motivi di leggibilitá).
Classe factory templatizzata che astrae sia il tipo che l'allocatore. O in alternativa in strutture dati template aventi come argomento anche l'allocatore (in stile STL tanto per capirsi). Come risultato non e' molto diverso dalla controparte C ma ne guadagni in type safety. in codice?
se puó aiutarti qui c'é la documentazione di una routine generica di allocazione e della corrispettiva di deallocazione:
http://msdn.microsoft.com/en-us/library/ms796989.aspx
http://msdn.microsoft.com/en-us/library/ms796854.aspx
quali altri dati ingombranti ti trovi sullo stack, una volta che hai escluso le eccezioni ? domando scusa, avevo letto male :p
naturalmente i dati ingombranti sono le variabili locali di tipo class o struct, gli oggetti temporanei di tipo class o struct e i record delle eccezioni non SEH; da quanto ho appreso leggendo a suo tempo quel famoso articolo che ho linkato non ce ne sono altri, si vedrá con le versioni future del compilatore.
Il fatto che alcune cose non vengano fatte bene non e' necessariamente una questione di competenza, puo' anche solo mancanza di interesse (anzi, probabilmente e' la ragione vera) da parte di MS. Questo non toglie che se volesse farlo e lo facesse, alcuni problemi evidenziati nell'articolo che avevi inizialmente linkato non si presenterebbero. non ti balena l'idea che i vantaggi del poter usare a cuor leggero i piú sofisticati costrutti di C++ in kernel-mode non valgano la complessitá da affrontare per ottenere un simile risultato?
in altre parole, provaci tu e poi ne riparliamo. non mi venire a citare altri kernels scritti in C++ perché ne sono perfettamente a conoscenza, e quei kernels non sono Windows e non hanno le stesse capacitá.
Lo capirai quando avrai un'adeguata conoscenza di come funzionano le architetture degli elaboratori. spiacente ma non "nutro" i troll.
Ecco, se non lo conosci lascia perdere, che è meglio. Fino alla scorsa settimana lavoravo a un progetto per Windows Mobile, e "casualmente", guarda cosa si trova in
[...] e dove sarebbe il codice del driver? non so da te ma da me la cartella che dovrebbe contenerne i sorgenti contiene solo un file INF per installare un certo file CAT che non sono riuscito ad ottenere a seguito di una compilazione "successful" (tant'é vero che seguendo alla lettera gli steps descritti nel file readme.htm non riesco ad installare i drivers per le nuove periferiche).
Ed è inutile che ti dica su quale CPU gira il codice, perché dovresti averlo già capito da solo. lo si legge chiaramente nel file INF infatti, di conseguenza non capisco cosa c'entri questo esempio dell'SDK con la tua fantastica esperienza lavorativa in Windows Mobile. o hanno fatto un cellulare dotato di processore x86, x64 o Itanium?
Diciamo che una macchina di Turing NON è reale, ma un concetto astratto, e che non avrebbe diritto di esistere, a tuo dire. nella mia mente esiste eccome: nessuno vieta ad un'idea di esiste. sono le sue implementazioni che non esistono.
Anzi, visto che ci siamo possiamo anche buttare l'intera teoria della computabilità (sulla quale è stata fondata l'informatica, ma questo è un dettaglio trascurabile), visto che si tratta di masturbazioni mentali di matematici che mal si conciliano con la finitezza del mondo reale col quale siamo costretti a lavorare tutti i giorni.
E' già qualcosa. Bene. che simpaticone... :asd:
In ogni caso a me interessa se è possibile o meno fare una cosa. Ed è possibile, in linea teorica e pratica. Tanto basta. avrei da ridire sulla linea pratica: tu non sai se é possibile scrivere un kernel driver per Windows in C++ in linea pratica perché non l'hai mai fatto in tutta la tua vita, anzi non l'hai mai fatto neanche usando il C, dico bene?
Nella mia vita ho usato poco i debugger ("Il debugger è il male" - fek). altro motivo per cui difficilmente riusciresti a scrivere un driver: hai poca esperienza coi debuggers (specialmente con quelli per il kernel e quelli remoti immagino).
Sì, perché il contesto in cui l'hai espresso non si può bellamente ignorare. a no? prendimi la targa.
Poi se prendiamo la tua sola frase estrapolandola dal suddetto contesto, ha una sua validità, benché sia viziata dall'implementazione, come ho già ripetuto in ogni messaggio che ho scritto in questa discussione sull'argomento. e in che modo invece il suddetto contesto invalidava la mia affermazione?
Ecco, allora tu comincia a farti una cultura su cos'è un linguaggio di programmazione e la differenza che passa con le sue implementazioni, cercando di non confondere i due termini e di non prendere il caso particolare di un'implementazione pretendendo di pontificare sull'intero linguaggio.
Magari una ripassata al manuale di riferimento del linguaggio male non ti farebbe. stesso discorso del troll di cui sopra: se ti sollazzi a fare assunzioni sulla mia cultura continua pure finché non scoppi, a me frega meno che zero (anzi se non ti spiace, onde evitare di ripetere lo stesso concetto nei prossimi post, parti simili le taglio direttamente).
cdimauro
28-07-2009, 21:07
spiacente ma non "nutro" i troll.
Troll è chi ha preferito buttare sul personale una discussione che viaggiava sul piano puramente tecnico, cominciando con sfottò e parlando di "fuffa".
Per il resto, puoi anche evitare di scrivere se è questa la tua posizione.
e dove sarebbe il codice del driver? non so da te ma da me la cartella che dovrebbe contenerne i sorgenti contiene solo un file INF per installare un certo file CAT che non sono riuscito ad ottenere a seguito di una compilazione "successful" (tant'é vero che seguendo alla lettera gli steps descritti nel file readme.htm non riesco ad installare i drivers per le nuove periferiche).
Quando torno a lavoro lo provo. A casa ho soltanto Visual Studio Express Edition.
lo si legge chiaramente nel file INF infatti, di conseguenza non capisco cosa c'entri questo esempio dell'SDK con la tua fantastica esperienza lavorativa in Windows Mobile.
Avevi scritto che su WM non era possibile creare driver.
o hanno fatto un cellulare dotato di processore x86, x64 o Itanium?
Se non sono ancora arrivati, sono previsti a breve basati su x86.
avrei da ridire sulla linea pratica: tu non sai se é possibile scrivere un kernel driver per Windows in C++ in linea pratica perché non l'hai mai fatto in tutta la tua vita, anzi non l'hai mai fatto neanche usando il C, dico bene?
Non l'ho mai fatto e non è necessario che lo faccia per sapere se è possibile oppure no.
Lo stesso link che hai postato (e che conoscevo già) non dice che è impossibile, ma sconsiglia di usarlo ed espone i casi in cui è meglio non usare certe caratteristiche di questo linguaggio.
Ciò non toglie che, appunto, sia possibile farlo.
altro motivo per cui difficilmente riusciresti a scrivere un driver: hai poca esperienza coi debuggers (specialmente con quelli per il kernel e quelli remoti immagino).
Ne ho poca perché poche volte ho scritto codice con bug così rognosi da non saltare fuori leggendo soltanto il codice.
D'altra parte quando lavoravo a basso livello con Amiga era impossibile utilizzare un debugger, per cui dovevo arrangiarmi e il codice dei giochi lo scrivevo ugualmente.
e in che modo invece il suddetto contesto invalidava la mia affermazione?
Linguaggio != implementazione.
Javaboy (nello specifico) e tutti gli altri qui hanno sempre parlato di LINGUAGGIO di programmazione (vedi anche il titolo del thread).
Tu hai risposto a un'affermazione di javaboy sul linguaggio tirando in ballo UNA IMPLEMENTAZIONE.
Il che, ripeto, nulla dice sul linguaggio di per sé.
stesso discorso del troll di cui sopra: se ti sollazzi a fare assunzioni sulla mia cultura continua pure finché non scoppi, a me frega meno che zero (anzi se non ti spiace, onde evitare di ripetere lo stesso concetto nei prossimi post, parti simili le taglio direttamente).
Non c'è problema.
Poi prendi il K&R e lo Stroustrup, e fammi vedere quale caratteristica del C non si trova nel C++, e ne preclude pertanto l'uso nella scrittura di codice a basso livello (che era il tema originale di questa parte della discussione).
Così vediamo chi dei due è un troll e prendiamo atto della tua cultura in materia.
Quando torno a lavoro lo provo. A casa ho soltanto Visual Studio Express Edition. si ma non hai risposto alla mia domanda: dove sarebbe il codice C++ del driver? io li' vedo solo programmi user-mode e DLL, nessuno dei sorgenti contiene una DriverEntry (che é l'entry point dei kernel drivers).
Avevi scritto che su WM non era possibile creare driver. ????
Se non sono ancora arrivati, sono previsti a breve basati su x86. secondo te io come potrei evitare di parlare di fuffa in risposta a quello che scrivi? questa come me la chiami? serve a qualcosa questa precisazione?
Non l'ho mai fatto e non è necessario che lo faccia per sapere se è possibile oppure no. :rotfl:
Lo stesso link che hai postato (e che conoscevo già) non dice che è impossibile, ma sconsiglia di usarlo ed espone i casi in cui è meglio non usare certe caratteristiche di questo linguaggio.
Ciò non toglie che, appunto, sia possibile farlo. in linea teorica.
Ne ho poca perché poche volte ho scritto codice con bug così rognosi da non saltare fuori leggendo soltanto il codice. si vede che raramente hai avuto a che fare con certi livelli di complessitá tecnica: l'uomo per definizione sbaglia, e se sto interloquendo con un essere sovrumano mi scuso con umiltá :rolleyes:
fatto sta che hai poca esperienza con uno strumento che é indispensabile nello sviluppo di un kernel driver per Windows.
Linguaggio != implementazione.
Javaboy (nello specifico) e tutti gli altri qui hanno sempre parlato di LINGUAGGIO di programmazione (vedi anche il titolo del thread).
Tu hai risposto a un'affermazione di javaboy sul linguaggio tirando in ballo UNA IMPLEMENTAZIONE. e allora?
non farti troppe seghe, per invalidare la mia affermazione devi trovare un controesempio.
Poi prendi il K&R e lo Stroustrup, e fammi vedere quale caratteristica del C non si trova nel C++, e ne preclude pertanto l'uso nella scrittura di codice a basso livello (che era il tema originale di questa parte della discussione). quando dico che non é possibile scrivere drivers in C++ non intendo dire che non é possibile utilizzandone un ridotto sottoinsieme prossimo al C, e tu lo sai perfettamente. di conseguenza il punto a cui volevi arrivare con questo squisito sarcasmo era?
morskott
28-07-2009, 23:12
Ma a qualcuno importa scrivere driver per windows in C++ (importa=ha interesse a farlo) o è una disputa sull'"ho ragione io, ho ragione io, ho ragione io!!!"???
Chi dice che è possibile non c'è miglior prova che implementarlo (o mostrarne un'implementazione) (negare la non esistenza è la parte più "facile" (notare le virgolette), basta trovare una soluzione), mentre chi dice che non è possibile ha una bella rogna (deve dimostrare che sotto TUTTE le condizioni la condizione non è verificata)
Intervenendo sulla parte "filosofica": perchè si avrebbe vantaggi a scrivere driver in C++? Per utilizzare gli oggetti? Non aggiunge maggiore complessità e non è piu soggetto a errori di (de-)allocazione di memoria (per altro limitata)? (chiedo perchè non conosco molto bene questo tipo di cose a così basso livello)
Già questo finirà a cazzotti entro due pagine...
:yeah: !!!Nostradamus mi fa un baffo mi fa!!! :yeah:
Ahhh, ormai è come sparare sulla croce rossa...
morskott
28-07-2009, 23:19
:yeah: !!!Nostradamus mi fa un baffo mi fa!!! :yeah:
Ahhh, ormai è come sparare sulla croce rossa...
6 numeri presto!!!
6 numeri presto!!!
:D Allora,
38, 'E mazzate
48, 'O muorto che pparla
17, 'A disgrazzia
60, 'O lamiento
39, 'A funa 'n ganna
19, 'O sanghe
Si accettano benemerenze in caso di vittoria! :D
Chi dice che è possibile non c'è miglior prova che implementarlo (o mostrarne un'implementazione) (negare la non esistenza è la parte più "facile" (notare le virgolette), basta trovare una soluzione), sacrosanto.
mentre chi dice che non è possibile ha una bella rogna (deve dimostrare che sotto TUTTE le condizioni la condizione non è verificata) credimi, la rogna piu grossa ce l'hanno i primi :asd:
a supporto delle mie parole é sufficiente l'articolo che ho linkato: la dimostrazione generale sotto tutte le condizioni é descritta li.
Intervenendo sulla parte "filosofica": perchè si avrebbe vantaggi a scrivere driver in C++? Per utilizzare gli oggetti? Non aggiunge maggiore complessità e non è piu soggetto a errori di (de-)allocazione di memoria (per altro limitata)? (chiedo perchè non conosco molto bene questo tipo di cose a così basso livello) la memoria che hai a disposizione in kernel space in genere non é piu limitata di quella che avresti in user space: in entrambi i casi ammonta a 2 GB virtuali se escludiamo che sulle edizioni server di Windows a volte si usa un'opzione di boot che riduce a 1 GB virtuale il kernel space al fine di espandere a 3 GB virtuali lo user space. comunque sia di memoria solitamente ce n'é tanta, é solo lo stack ad essere limitato.
il vantaggio dell'usare il C++ é che potresti usare costrutti piu sofisticati che ti permetterebbero di ridurre le dimensioni del codice, esempio classico quello degli scoped objects, senza contare i templates che ti permettono di scrivere una volta sola un codice che in C dovresti replicare per ogni combinazione di template parameters a cui lo applicheresti in C++ (spiegazione schifosa :D).
l'uso delle classi non comporta necessariamente il problema della gestione della memoria dinamica: non é detto che un oggetto debba essere allocato con new, anzi.
:yeah: !!!Nostradamus mi fa un baffo mi fa!!! :yeah:
Ahhh, ormai è come sparare sulla croce rossa... scusa se ti deludo ma non é che tu abbia previsto chissá cosa, lo sapevamo tutti :asd:
:D Allora,
38, 'E mazzate
48, 'O muorto che pparla
17, 'A disgrazzia
60, 'O lamiento
39, 'A funa 'n ganna
19, 'O sanghe
Si accettano benemerenze in caso di vittoria! :D LOL, cos'é, la smorfia napoletana? :D
scusa se ti deludo ma non é che tu abbia previsto chissá cosa, lo sapevamo tutti :asd: anzi, tanto che ci siamo perché qualcuno non risponde al post #104? :Prrr:
prima magari peró attendete che io finisca con cdimauro :stordita:
il vantaggio dell'usare il C++ é che potresti usare costrutti piu sofisticati che ti permetterebbero di ridurre le dimensioni del codice, esempio classico quello degli scoped objects, senza contare i templates che ti permettono di scrivere una volta sola un codice che in C dovresti replicare per ogni combinazione di template parameters a cui lo applicheresti in C++ (spiegazione schifosa :D).
l'uso delle classi non comporta necessariamente il problema della gestione della memoria dinamica: non é detto che un oggetto debba essere allocato con new, anzi.
C'è un problema... chi scrive driver è generalmente gente "rodata", che conosce l'hardware come le sue tasche e che reputa di alto livello l'assembly.
E' evidente che questo "tipo umano" se ne frega altamente delle comodità che proponi, ed anzi è terrorizzato dal fatto che queste facciano perdere un bel pò di prestazioni rispetto al C o meno.
E, aggiungo io utente, fa bene :D
Perdere 10 fps in qualcosa perchè gli faceva comodo usare gli scoped objects non è il primo dei miei desideri :asd:
In poche parole, C++ non è richiesto nei driver perchè è un ambito dove ogni singola goccia di performance conta.
Conta come qualità, e conta anche come $oldi, dato che un driver più prestante si traduce in più hardware venduto.
E questo vale dalle GPU ai joypads fino agli scanner...
anzi, tanto che ci siamo perché qualcuno non risponde al post #104? :Prrr:
Pronti:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Pussa via, te e il tuo C#! :D
morskott
29-07-2009, 00:12
anzi, tanto che ci siamo perché qualcuno non risponde al post #104? :Prrr:
prima magari peró attendete che io finisca con cdimauro :stordita:
Perchè oltre che ho poche se non nulle esperienze su .net (mentre su java ci ho fatto qualcosuccia anche su RMI (due progetti), JGroups, accenni di EJB, due progetti su JSP/Servlet, JDBC, e qualche progettino solo per conto mio con swing), non ho visto nessuna argomentazione a supporto della superiorità di .net. (evitare link di dipendenti microsoft E dipendenti sun (anzi, oracle ormai))
Anche se devo dire che LINQ è una gran bell'invenzione, anche se JPA (Java Persistence API (forse ho sbagliato acronimo)) ne ha pure lui di cose da dire!!
Per quanto ho visto con JPA puoi embeddare su codice come annotazioni query sql, un po come LINQ, appena ho un attimo di tempo/voglia me lo studio bene, come in .net persistence framework c'è un oggetto che rappresenta il DB su cui invocare metodi per tirar fuori tramite query embeddate oggetti java, tutto fortemente tipizzato.
morskott
29-07-2009, 00:14
Pronti:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Pussa via, te e il tuo C#! :D
Purtroppo per la causa Java (se mai ce ne è una) popolarità!=superiorità !!!
(anche se ne è buon indizio!!)
Carta canta e villan dorme. Quando quel tafano di C# ronzerà intorno al 20% ne riparleremo :Prrr:
||ElChE||88
29-07-2009, 00:19
Pronti:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Pussa via, te e il tuo C#! :D
Affidabile quel sito. :asd:
RPG che sale mostruosamente perché nella ricerca vengono inclusi pure i giochi di ruolo (RPG - Role Playing Game).
Certo che è affidabile. Come definisci qualcuno che scopre di aver fatto una stronzata e ne espone pubblicamente ragioni e soluzioni? C# al momento se la gioca con Python (se mai è stato possibile tifare per un linguaggio, FORZA PYTHON, FACCI SOGNARE!!!).
Magari un giorno sarà popolare quanto C o C++, forse addirittura quanto Java. Al momento è nel trogolo dei mosconi.
Sarebbe bello avere un indice regionale. Scommetterei che in Italia C# spopola.
||ElChE||88
29-07-2009, 00:41
Certo che è affidabile. Come definisci qualcuno che scopre di aver fatto una stronzata e ne espone pubblicamente ragioni e soluzioni? C# al momento se la gioca con Python (se mai è stato possibile tifare per un linguaggio, FORZA PYTHON, FACCI SOGNARE!!!).
Magari un giorno sarà popolare quanto C o C++, forse addirittura quanto Java. Al momento è nel trogolo dei mosconi.
Sarebbe bello avere un indice regionale. Scommetterei che in Italia C# spopola.
Sbaglio o noto un certo astio nei confronti di C#? :fagiano:
Almeno dimmi che hai buone ragioni per odiarlo e che non sei l'ennesimo anti-MS per principio; quei poveracci fanno veramente pena. :(
PS: L'importante è che Perl scenda. :asd:
No, io sono un sacro adoratore dello zio bill e di fronte al solo sospetto che mi animi un sentimento anti-windows mi costringi a farmi tre volte il segno della finestra.
Ciò detto esprimerei il mio sentimento nei confronti di C# con queste parole:
tutti i linguaggi sono contenitori di caratteristiche e quando è giunto il momento di scegliere che tipo di contenitore dovesse essere C# i progettisti di MS hanno scelto la pattumiera.
E se mai dovessero decidere di infilarci dentro pure la tipazione dinamica avranno fatto il passo al livello successivo: la discarica.
Han tirato su tutta la rantumaglia stantia accumulatasi negli anni, l'han rabberciata su Java e han vomitato C#.
Come disse armstrong: un piccolo passo per un uomo, un'enorme stronzata per l'umanità.
No, io sono un sacro adoratore dello zio bill e di fronte al solo sospetto che mi animi un sentimento anti-windows mi costringi a farmi tre volte il segno della finestra.
Ciò detto esprimerei il mio sentimento nei confronti di C# con queste parole:
tutti i linguaggi sono contenitori di caratteristiche e quando è giunto il momento di scegliere che tipo di contenitore dovesse essere C# i progettisti di MS hanno scelto la pattumiera.
E se mai dovessero decidere di infilarci dentro pure la tipazione dinamica avranno fatto il passo al livello successivo: la discarica.
Han tirato su tutta la rantumaglia stantia accumulatasi negli anni, l'han rabberciata su Java e han vomitato C#.
Come disse armstrong: un piccolo passo per un uomo, un'enorme stronzata per l'umanità.
ma va la'.
^TiGeRShArK^
29-07-2009, 07:42
Perchè oltre che ho poche se non nulle esperienze su .net (mentre su java ci ho fatto qualcosuccia anche su RMI (due progetti), JGroups, accenni di EJB, due progetti su JSP/Servlet, JDBC, e qualche progettino solo per conto mio con swing), non ho visto nessuna argomentazione a supporto della superiorità di .net. (evitare link di dipendenti microsoft E dipendenti sun (anzi, oracle ormai))
Anche se devo dire che LINQ è una gran bell'invenzione, anche se JPA (Java Persistence API (forse ho sbagliato acronimo)) ne ha pure lui di cose da dire!!
Per quanto ho visto con JPA puoi embeddare su codice come annotazioni query sql, un po come LINQ, appena ho un attimo di tempo/voglia me lo studio bene, come in .net persistence framework c'è un oggetto che rappresenta il DB su cui invocare metodi per tirar fuori tramite query embeddate oggetti java, tutto fortemente tipizzato.
JPA è diverso da LINQ.
Dovrebbe essere + o - l'equivalente dell'Entity Framework.
Linq invece contiene Linq to objects, che permette di operare su *qualsiasi* oggetto in memoria, anche quelli che non c'entrano nulla col DB, Linq to Xml che è il modo + semplice che io abbia mai visto per operare con l'XML e Linq to Sql che è una specie di versione ridotta dell'Entity Framework.
^TiGeRShArK^
29-07-2009, 07:47
Certo che è affidabile. Come definisci qualcuno che scopre di aver fatto una stronzata e ne espone pubblicamente ragioni e soluzioni? C# al momento se la gioca con Python (se mai è stato possibile tifare per un linguaggio, FORZA PYTHON, FACCI SOGNARE!!!).
Magari un giorno sarà popolare quanto C o C++, forse addirittura quanto Java. Al momento è nel trogolo dei mosconi.
Sarebbe bello avere un indice regionale. Scommetterei che in Italia C# spopola.
Se la popolarità indicasse le potenzialità allora C# dovrebbe essere al di sopra di java visti gli strumenti che offre in + come linguaggio.
Castrare in java la programmazione funzionale, in un periodo in cui si sta diffondendo sempre di + vista l'enorme diffusione dei multi-core, è indubbiamente una boiata.
E sono convinto che java ne pagherà il prezzo se non sarà + competitiva con C#.
^TiGeRShArK^
29-07-2009, 07:50
No, io sono un sacro adoratore dello zio bill e di fronte al solo sospetto che mi animi un sentimento anti-windows mi costringi a farmi tre volte il segno della finestra.
Ciò detto esprimerei il mio sentimento nei confronti di C# con queste parole:
tutti i linguaggi sono contenitori di caratteristiche e quando è giunto il momento di scegliere che tipo di contenitore dovesse essere C# i progettisti di MS hanno scelto la pattumiera.
E se mai dovessero decidere di infilarci dentro pure la tipazione dinamica avranno fatto il passo al livello successivo: la discarica.
Han tirato su tutta la rantumaglia stantia accumulatasi negli anni, l'han rabberciata su Java e han vomitato C#.
Come disse armstrong: un piccolo passo per un uomo, un'enorme stronzata per l'umanità.
Diciamo che ti costa fatica non prendere atto che java non è + al passo con i tempi e la qualità media del codice java in confronto a C# si è abbassata notevolmente dall'inizio fino ad oggi. :)
Questo perchè C# si è evoluto, java è rimasto sostanzialmente uguale (generics a parte).
astorcas
29-07-2009, 08:08
No, io sono un sacro adoratore dello zio bill e di fronte al solo sospetto che mi animi un sentimento anti-windows mi costringi a farmi tre volte il segno della finestra.
Ciò detto esprimerei il mio sentimento nei confronti di C# con queste parole:
tutti i linguaggi sono contenitori di caratteristiche e quando è giunto il momento di scegliere che tipo di contenitore dovesse essere C# i progettisti di MS hanno scelto la pattumiera.
E se mai dovessero decidere di infilarci dentro pure la tipazione dinamica avranno fatto il passo al livello successivo: la discarica.
Han tirato su tutta la rantumaglia stantia accumulatasi negli anni, l'han rabberciata su Java e han vomitato C#.
Come disse armstrong: un piccolo passo per un uomo, un'enorme stronzata per l'umanità.
Un link a caso:
http://demiliani.com/blog/archive/2008/10/31/6524.aspx :asd:
e comunque non sono d'accordo con te.
I <3 C# (4.0)
^TiGeRShArK^
29-07-2009, 08:38
Un link a caso:
http://demiliani.com/blog/archive/2008/10/31/6524.aspx :asd:
e comunque non sono d'accordo con te.
I <3 C# (4.0)
E' ottimo per l'interoperabilità con linguaggi di scripting.
E cmq hanno aggiunto anche il COM interoperability che è una panacea per chi si è mai trovato a scrivere cose con COM, ad esempio accedendo a fogli Excel e cose simili.
C'è un problema... chi scrive driver è generalmente gente "rodata", che conosce l'hardware come le sue tasche e che reputa di alto livello l'assembly.
E' evidente che questo "tipo umano" se ne frega altamente delle comodità che proponi, ed anzi è terrorizzato dal fatto che queste facciano perdere un bel pò di prestazioni rispetto al C o meno.
E, aggiungo io utente, fa bene :D
Perdere 10 fps in qualcosa perchè gli faceva comodo usare gli scoped objects non è il primo dei miei desideri :asd:
In poche parole, C++ non è richiesto nei driver perchè è un ambito dove ogni singola goccia di performance conta.
Conta come qualità, e conta anche come $oldi, dato che un driver più prestante si traduce in più hardware venduto.
E questo vale dalle GPU ai joypads fino agli scanner...
Non e' scritto da nessuna parte che un driver in C++ debba essere piu' lento della controparte C. Semmai possiamo dire che per la maggior parte dei driver HW non c'e' grande utilita' nell'usare C++. Diverso per driver di tipo piu' "astratto" (filesystems ad esempio) dove la componente algoritmica ha un peso diverso, e dove le ottimizzazioni possibili grazie all'uso dei template possono farsi sentire.
Perdere 10 fps in qualcosa perchè gli faceva comodo usare gli scoped objects non è il primo dei miei desideri :asd:
Perche' uno scoped object dovrebbe causare perdita di performance ?
Diciamo che ti costa fatica non prendere atto che java non è + al passo con i tempi e la qualità media del codice java in confronto a C# si è abbassata notevolmente dall'inizio fino ad oggi. :)
Questo perchè C# si è evoluto, java è rimasto sostanzialmente uguale (generics a parte).
Sul fatto che Java abbia la sua bella età, non c'è che dire. E' nella seconda decina ormai.
Scala è al passo coi tempi. Newspeak è al al passo coi tempi. Ma C#... via, non scherziamo.
marko.fatto
29-07-2009, 10:02
Non pensavo che D fosse così in "alto" in quella classifica dei linguaggi :fagiano:
banryu79
29-07-2009, 10:10
Non pensavo che D fosse così in "alto" in quella classifica dei linguaggi :fagiano:
Sì, ma sta col paracadute aperto, a occhio :D
A scanso di equivoci prendete il TIOBE tanto seriamente quanto i miei commenti su C#. Il TIOBE è statistica quindi è di per sè una stronzata e C# mi sta sulle balle per partito preso.
C# mi sta sulle balle per partito preso.
Il che ti rende meno attendibile nell'esprimere pareri nei suoi confronti.
Forse non s'è capito l'appunto.
TIOBE = da non prendere seriamente
i miei commenti su C# = da prendere tanto seriamente quanto TIOBE
ergo nessuno dei due da prendere seriamente.
"tanto"..."quanto"
Che c'entra "Il che ti rende meno attendibile nell'esprimere pareri nei suoi confronti." :mbe:
Non si può essere meno attendibili di totalmente inattendibili. O no? :confused:
Forse non s'è capito l'appunto.
TIOBE = da non prendere seriamente
i miei commenti su C# = da prendere tanto seriamente quanto TIOBE
ergo nessuno dei due da prendere seriamente.
"tanto"..."quanto"
Che c'entra "Il che ti rende meno attendibile nell'esprimere pareri nei suoi confronti." :mbe:
Non si può essere meno attendibili di totalmente inattendibili. O no? :confused:
Certo che si puo'.
Potresti avere un'attendibilita' negativa in merito.
Ovvero tanto piu' ne parli male, tanto piu' la gente si convincera' che C# e' il migliore. :)
Ps: Sono d'accordo nel considerare anche Tiobe inattendibile. Anzi, l'ho sempre sostenuto.
C'è un problema... chi scrive driver è generalmente gente "rodata", che conosce l'hardware come le sue tasche e che reputa di alto livello l'assembly.
E' evidente che questo "tipo umano" se ne frega altamente delle comodità che proponi, ed anzi è terrorizzato dal fatto che queste facciano perdere un bel pò di prestazioni rispetto al C o meno.
Ma non ti credere, anzi, l'idea che chi scriva driver mangi pane e assembly è spesso fortemente sbagliata.
Bisogna poi vedere che tipo di driver si sta per andare a scrivere, ma solitamente si evita fortemente l'utilizzo dell'assembly -a meno di casi in cui non se ne può assolutamente fare a meno - per evitare di introdurre errori grossolani che potrebbero facilmente essere introdotti con un uso non attento dell'asm e per problemi di compatibilità.
Per quanto riguarda l'utilizzo del C++ come linguaggio di programmazione per driver, che dire..."potrebbe" essere utilizzato in linea del tutto teorica, ma verrebbe fuori un simil-C più che un C++.
Almeno io, e così tutti i miei colleghi e tutte le persone che ho visto fino ad ora (sorgenti compresi), utilizzo il C
banryu79
29-07-2009, 10:52
Dai ragazzi, non buttiamoci sul flame (no, non è una battuta).
Che PGI-Bis non sprizzi gioia di fronte al C# non è un mistero, e ha avuto l'onestà di dirlo, quindi uno prende i suoi commenti relativamente a questo linguaggio, specie quando gli "rifila mazzate" senza motivare in chiaro, cum grano salis.
Certo non è un atteggiamento che giova all'utilità della discussione, però ogni tanto capita di svaccare un po' sul forum, basta farlo senza scadere e arrivare a fare attacchi alle persone, che sono al di sopra di qualsiasi linguaggio e qualunque tecnologia.
P.S.: a me piacerebbe sentire le ragioni per cui tizio deplora C#, e magari la risposta di caio farcita di altrettante ragioni per cui C# è buono, almeno un ignorante come me che assiste dall'esterno può venire a conoscenza di questa o quella feature del linguaggio, questo o quell'utilizzo, questo o quel pitfall, e vedere se ne rimane incuriosito tanto da andare a provarselo per poi farsi una sua opinione.
Poi se volete mazziarvi, mazziatevi, ogni tanto è anche divertente vedere due programmatori azzuffarsi per le proprie idee :asd:
cdimauro
29-07-2009, 11:02
si ma non hai risposto alla mia domanda: dove sarebbe il codice C++ del driver? io li' vedo solo programmi user-mode e DLL, nessuno dei sorgenti contiene una DriverEntry (che é l'entry point dei kernel drivers).
Come faccio a rispondere se t'ho detto che a casa ho soltanto VS Express? E' a lavoro che ho VS + SDK per Windows Mobile e posso verificare.
????
su ARM invece no perché il WDK (che tu evidentemente non conosci, altrimenti non cercheresti di sincerarti di queste cose, e te lo faccio notare per farti capire che stai cercando di discutere di cose che non conosci) non permette di programmare drivers per Windows Mobile
secondo te io come potrei evitare di parlare di fuffa in risposta a quello che scrivi? questa come me la chiami? serve a qualcosa questa precisazione?
A rimarcare che Windows Mobile non è vincolato alla sola architettura ARM.
:rotfl:
Le risate se le fa chi sa cos'è un linguaggio di programmazione, e sa distinguerlo da una qualsiasi implementazione.
in linea teorica.
Anche pratica, ma di questo ne parlo alla fine.
si vede che raramente hai avuto a che fare con certi livelli di complessitá tecnica: l'uomo per definizione sbaglia, e se sto interloquendo con un essere sovrumano mi scuso con umiltá :rolleyes:
fatto sta che hai poca esperienza con uno strumento che é indispensabile nello sviluppo di un kernel driver per Windows.
Si vede che tu non hai la minima idea di cosa significhi sviluppare un videogioco su Amiga. Debugger? Avercelo! L'unica cosa su cui potevi contare erano i sorgenti, oppure (quindi l'uno o l'altro) lo schermo davanti col codice in esecuzione.
e allora?
non farti troppe seghe, per invalidare la mia affermazione devi trovare un controesempio.
La tua affermazione non è che si debba invalidare. Semplicemente non è pertinente / applicabile al contesto citato.
Si parlava di mele (linguaggio), e tu tiri fuori le pere (implementazione): come si fa a confrontarle?
quando dico che non é possibile scrivere drivers in C++ non intendo dire che non é possibile utilizzandone un ridotto sottoinsieme prossimo al C, e tu lo sai perfettamente.
Che sia quasi uguale al C è una tua speculazione. Anzi, finora mi sembra che l'unico punto su cui c'è convergenza è l'uso delle eccezioni, anche se rimangono utilizzabili su contesti / pezzi di codice limitati.
Ma non mi risulta che il C++ abbia aggiunto soltanto le eccezioni al C...
di conseguenza il punto a cui volevi arrivare con questo squisito sarcasmo era?
Nessun sarcasmo: era un precisa richiesta.
Prendi i manuali di riferimento dei rispettivi linguaggi e fammi vedere cos'è che il C avrebbe rispetto al C++, che impedisce o limita fortemente a quest'ultimo nell'essere usatilizzato per scrivere codice a basso livello.
Sei in grado di portare almeno un esempio, oppure no?
credimi, la rogna piu grossa ce l'hanno i primi :asd:
a supporto delle mie parole é sufficiente l'articolo che ho linkato: la dimostrazione generale sotto tutte le condizioni é descritta li.
Che dimostra soltanto che è consigliabile di no, e... solo per Windows.
Quando invece javaboy avevo parlato più genericamente del linguaggio C++, quindi senza legarsi a una particolare implementazione come hai fatto tu, e pretendendo poi di estendere il singolo caso all'intero linguaggio.
il vantaggio dell'usare il C++ é che potresti usare costrutti piu sofisticati che ti permetterebbero di ridurre le dimensioni del codice, esempio classico quello degli scoped objects, senza contare i templates che ti permettono di scrivere una volta sola un codice che in C dovresti replicare per ogni combinazione di template parameters a cui lo applicheresti in C++ (spiegazione schifosa :D).
l'uso delle classi non comporta necessariamente il problema della gestione della memoria dinamica: non é detto che un oggetto debba essere allocato con new, anzi.
Insomma, poca roba rispetto al C. E immagino che si tratti sempre di fuffa inutile, no?
^TiGeRShArK^
29-07-2009, 11:05
Sul fatto che Java abbia la sua bella età, non c'è che dire. E' nella seconda decina ormai.
Scala è al passo coi tempi. Newspeak è al al passo coi tempi. Ma C#... via, non scherziamo.
fai in java o in scala qualcosa di simile per parsare la cronologia di MSN:
class Program
{
static void Main(string[] args)
{
XDocument doc = XDocument.Load(@"Z:\Documents\File ricevuti\*******3638208852\Cronologia\***********.xml");
var messages = from m in doc.Descendants("Message")
select String.Format("[{0} {1}] <{2}> {3}",
(string)m.Attribute("Date"),
(string)m.Attribute("Time"),
(string)(m.Element("From").Element("User").Attribute("FriendlyName")),
(string)m.Element("Text"));
messages.ToList().ForEach(Console.WriteLine);
Console.ReadLine();
}
}
E vediamo quanto sono potenti visto che sono "al passo coi tempi". :)
Una cosa che stampa delle stringhe da un file XML è troppo per me. Quello che devo fare io è questo.
package it.tukano.moduleframework;
public interface Application extends Module {
public <T extends Module> T getModule(Class<T> type);
public void execute();
public void shutdown();
}
package it.tukano.moduleframework;
public interface Module {
void setApplication(Application application);
void initialize();
void postInitialize();
void start();
void stop();
void destroy();
}
package it.tukano.moduleframework.basic;
import it.tukano.moduleframework.*;
import java.util.concurrent.ConcurrentHashMap;
public class BasicApplication implements Application {
private Application application;
private final ConcurrentHashMap<Class<? extends Module>, Module> modules;
public BasicApplication(ModulePack pack) {
modules = new ConcurrentHashMap<Class<? extends Module>, Module>(pack.getData());
}
public void execute() {
initialize();
postInitialize();
start();
}
public void shutdown() {
stop();
destroy();
}
public void initialize() {
for (Module m : modules.values()) {
m.setApplication(this);
m.initialize();
}
}
public void postInitialize() {
for(Module m : modules.values()) {
m.postInitialize();
}
}
public void start() {
for (Module m : modules.values()) {
m.start();
}
}
public void stop() {
for (Module m : modules.values()) {
m.stop();
}
}
public void destroy() {
for (Module m : modules.values()) {
m.destroy();
}
}
public <T extends Module> T getModule(Class<T> type) {
if (type == null) {
return null;
}
Module m = modules.get(type);
if (m == null) {
return null;
}
if (!type.isAssignableFrom(m.getClass())) {
return null;
}
return type.cast(m);
}
public synchronized void setApplication(Application application) {
this.application = application;
}
public synchronized Application getApplication() {
return application;
}
}
package it.tukano.moduleframework.basic;
import it.tukano.moduleframework.Application;
import it.tukano.moduleframework.Module;
public class BasicModule implements Module {
private Application application;
public synchronized <T extends Module> T getModule(Class<T> type) {
return application.getModule(type);
}
public synchronized void setApplication(Application application) {
this.application = application;
}
public synchronized Application getApplication() {
return application;
}
public void initialize() {
}
public void postInitialize() {
}
public void start() {
}
public void stop() {
}
public void destroy() {
}
}
package it.tukano.moduleframework.basic;
import it.tukano.moduleframework.Module;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
public class ModulePack {
private final Map<Class<? extends Module>, Module> data =
new ConcurrentHashMap<Class<? extends Module>, Module>();
public <T extends Module, K extends T> void put(Class<T> type, K moduleInstance) {
getData().put(type, moduleInstance);
}
public Map<Class<? extends Module>, Module> getData() {
return data;
}
}
^TiGeRShArK^
29-07-2009, 11:52
Una cosa che stampa delle stringhe da un file XML è troppo per me. Quello che devo fare io è questo.
...devi eseguire delle applicazioni in maniera concorrente? :stordita:
Perchè tutto questo codice anzichè un Thread Pool in cui magari le classi vengono caricate al runtime partendo da una directory tramite reflection? :fagiano:
EDIT: e comunque mi sfugge l'attinenza dato che anche in C# a partire dal .net 2.0 lo puoi fare...
astorcas
29-07-2009, 12:04
una curiosità... (non centra all'incirca una mazza)
Java ha i nullable types?
EDIT: mi sa che non ne ha bisogno :fagiano:
...devi eseguire delle applicazioni in maniera concorrente? :stordita:
Perchè tutto questo codice anzichè un Thread Pool in cui magari le classi vengono caricate al runtime partendo da una directory tramite reflection? :fagiano:
EDIT: e comunque mi sfugge l'attinenza dato che anche in C# a partire dal .net 2.0 lo puoi fare...
Acqua circa lo scopo del codice. Non concentrarti sul dettaglio, "leggi" gli oggetti.
L'attinenza sta in ciò che ogni volta che propiniamo un esempio di ficheria del linguaggio X mostrando una funzione di fibonacci o il parsing di un file di testo perdiamo di vista il fatto che le sequenze di fibonacci e il parsing di file sono poco attendibili come misura di efficacia.
Posto che ogni programma in quanto tale ha una sua struttura di base per me conta di più il modo in cui un linguaggio permette di esprimere quella struttura. Non è una questione di sintesi o di efficienza ma di espressività. Se dovessi valutare C# lo valuterei in questo ambito perchè potrebbe non dover mai fare un complesso calcolo ma dovrà necessariamente esprimere una struttura.
fai in java o in scala qualcosa di simile per parsare la cronologia di MSN:
class Program
{
static void Main(string[] args)
{
XDocument doc = XDocument.Load(@"Z:\Documents\File ricevuti\*******3638208852\Cronologia\***********.xml");
var messages = from m in doc.Descendants("Message")
select String.Format("[{0} {1}] <{2}> {3}",
(string)m.Attribute("Date"),
(string)m.Attribute("Time"),
(string)(m.Element("From").Element("User").Attribute("FriendlyName")),
(string)m.Element("Text"));
messages.ToList().ForEach(Console.WriteLine);
Console.ReadLine();
}
}
E vediamo quanto sono potenti visto che sono "al passo coi tempi". :)
Factor è al passo coi tempi :D Anche senza LINQ! :p
"test.xml" file>xml "Message" tags-named [
{
[ "Date" attr ]
[ "Time" attr ]
[ "From" tag-named "User" tag-named "FriendlyName" attr ]
[ "Text" tag-named children>string ]
} cleave "[%s %s] <%s> %s\n" printf
] each
^TiGeRShArK^
29-07-2009, 13:58
Factor è al passo coi tempi :D Anche senza LINQ! :p
"test.xml" file>xml "Message" tags-named [
{
[ "Date" attr ]
[ "Time" attr ]
[ "From" tag-named "User" tag-named "FriendlyName" attr ]
[ "Text" tag-named children>string ]
} cleave "[%s %s] <%s> %s\n" printf
] each
Non ti offendere, ma per un essere umano è assolutamente illegibile un programma in factor...
Giuro che mi fa rimpiangere l'assembly x86.. :mbe:
^TiGeRShArK^
29-07-2009, 13:59
Acqua circa lo scopo del codice. Non concentrarti sul dettaglio, "leggi" gli oggetti.
L'attinenza sta in ciò che ogni volta che propiniamo un esempio di ficheria del linguaggio X mostrando una funzione di fibonacci o il parsing di un file di testo perdiamo di vista il fatto che le sequenze di fibonacci e il parsing di file sono poco attendibili come misura di efficacia.
Posto che ogni programma in quanto tale ha una sua struttura di base per me conta di più il modo in cui un linguaggio permette di esprimere quella struttura. Non è una questione di sintesi o di efficienza ma di espressività. Se dovessi valutare C# lo valuterei in questo ambito perchè potrebbe non dover mai fare un complesso calcolo ma dovrà necessariamente esprimere una struttura.
E cosa dovrebbe fare un insieme di applicazioni/moduli? :fagiano:
banryu79
29-07-2009, 14:01
Non ti offendere, ma per un essere umano è assolutamente illegibile un programma in factor...
Giuro che mi fa rimpiangere l'assembly x86.. :mbe:
Guarda, a me francamente non sembra così illegibile (dopo la spiegazione fornitami tempo fa da shinya sul codice della sua soluzione dell'ultimo contest, non so se ti ricordi...)
L'unica difficoltà di lettura che riscontro di quello che ha postato anche qui, per me, è data dal fatto che 1) non conosco Factor e 2) non sono abituato a leggere codice scritto in Factor.
In pratica dall'abitudine.
(P.S.: se poi ci aggiungi che pure il paradigma di programmazione è diverso da quello a cui sono abituato...)
^TiGeRShArK^
29-07-2009, 14:03
Guarda, a me francamente non sembra così illegibile (dopo la spiegazione fornitami tempo fa da shinya sul codice della sua soluzione dell'ultimo contest, non so se ti ricordi...)
L'unica difficoltà di lettura che riscontro di quello che ha postato anche qui, per me, è data dal fatto che 1) non conosco Factor e 2) non sono abituato a leggere codice scritto in Factor.
In pratica dall'abitudine.
(P.S.: se poi ci aggiungi che pure il paradigma di programmazione è diverso da quello a cui sono abituato...)
Per me le cose simil-RPN sono quanto di + illegibile possa esistere. :mbe:
banryu79
29-07-2009, 14:08
Per me le cose simil-RPN sono quanto di + illegibile possa esistere. :mbe:
Sì esatto: quello che volevo dire è che il giudizio sulla leggibilità è soggettivo!
Prendi me: leggo agevolmente Java.
Vedo il tuo codice in C# in stile funzionale: non sono abituato ma lo leggo.
Vedo il codice Factor equivalente: non so manco cos'è ma ricordo quello che shinya mi aveva spiegato e con un piccolo sforzo lo leggo.
L'unica differenza che mi rende più ardua la lettura nella versione Factor rispetto a C# è dovuta al cambio di paradigma a cui non sono abituato.
Poi però se mi chiedessero di rifare la stessa cosa scegliendo uno dei due linguaggi, potendo contare sulle conoscenze già acquisite e sulla familiarità (abitudine) mi butterei senza pensarci due volte su C#.
Non ti offendere, ma per un essere umano è assolutamente illegibile un programma in factor...
Giuro che mi fa rimpiangere l'assembly x86.. :mbe:
Ti capisco.
Ma vedo che hai Leonardo Da Vinci come avatar. Non era lui che scriveva da destra verso sinistra? :) E' più o meno la stessa cosa.
E' come quando guardi uno stereogramma per la prima volta, all'inizio non vedi niente.
Per il resto sono tutte funzioni... tags-named, tag-named, attr... non è una sintassi particolare o un'estensione al linguaggio.
banryu79
29-07-2009, 14:24
Per il resto sono tutte funzioni... tags-named, tag-named, attr... non è una sintassi particolare o un'estensione al linguaggio.
Ho una curiosità: sono funzioni definite da te, oppure fanno parte del "framework"?
^TiGeRShArK^
29-07-2009, 14:26
Ti capisco.
Ma vedo che hai Leonardo Da Vinci come avatar. Non era lui che scriveva da destra verso sinistra? :) E' più o meno la stessa cosa.
E' come quando guardi uno stereogramma per la prima volta, all'inizio non vedi niente.
Per il resto sono tutte funzioni... tags-named, tag-named, attr... non è una sintassi particolare o un'estensione al linguaggio.
si, ma è lo stesso motivo per cui ritengo le list comprehension di python illeggibili, perchè ti costringono a leggere in maniera "innaturale" il codice rispetto a come siamo stati abituati fin dalla nascita.
Perchè forzare qualcuno a leggere da destra verso sinistra se tutti noi occidentali siamo abituati a leggere in un certo modo? :fagiano:
cdimauro
29-07-2009, 14:27
E' come quando guardi uno stereogramma per la prima volta, all'inizio non vedi niente.
:what:
E' come quando guardi uno stereogramma, non vedi niente.
:D
si, ma è lo stesso motivo per cui ritengo le list comprehension di python illeggibili, perchè ti costringono a leggere in maniera "innaturale" il codice rispetto a come siamo stati abituati fin dalla nascita.
Perchè forzare qualcuno a leggere da destra verso sinistra se tutti noi occidentali siamo abituati a leggere in un certo modo? :fagiano:
:stordita: Allora Dragonball non l'hai mai letto? :fagiano:
Ho una curiosità: sono funzioni definite da te, oppure fanno parte del "framework"?
Fanno parte di questa libreria (e sotto-librerie)
http://docs.factorcode.org/content/vocab-xml.html
E si, fa parte del "framework" :)
Perchè forzare qualcuno a leggere da destra verso sinistra se tutti noi occidentali siamo abituati a leggere in un certo modo? :fagiano:
Era per fare un esempio di qualcosa a cui non sei abituato, ma che non per questo perde di senso.
E poi un programma in Factor si legge esattamente come leggi l'italiano o l'inglese, cioè da sinistra verso destra. E' molto più semplice di quello che sembra.
:what:
:D
Se ci si sforza un attimo, si possono vedere cose meravigliose :p
In python probabilmente si scriverebbe qualcosa del genere
from BeautifulSoup import BeautifulStoneSoup as soup
xml = soup( file( "..." ) )
messages = xml.findAll( "Message" )
for m in message:
print "[%s %s] <%s> %s" % (m['Date'], m['Time'], m.From.User['FriendlyName'], m.Text)
La notazione LINQ non e' male, ma mi sembra che a C# continuino ad aggiungere tante funzionalita' singole senza soffermarsi a cercare un set base di caratteristiche ortogonali che da cui derivare le altre.
Ad esempio in Lisp l' object system si puo' scrivere come libreria, e una sintassi come LINQ uno se la puo' fare usando le macro. In haskell funzionalita' come IO, ricerca con backtracking, parser combinators condividono uno stessa stessa struttura di base che permette di costruirsi dei DSL specifici... alla lunga paga perche' aumentando le funzionalita' la complessita' non cresce in ugual misura.
cdimauro
29-07-2009, 14:49
Se ci si sforza un attimo, si possono vedere cose meravigliose :p
Pensi che non c'abbia provato per n volte, con n tendente all'infinito? :sob:
In python probabilmente si scriverebbe qualcosa del genere
from BeautifulSoup import BeautifulStoneSoup as soup
xml = soup( file( "..." ) )
messages = xml.findAll( "Message" )
for m in message:
print "[%s %s] <%s> %s" % (m['Date'], m['Time'], m.From.User['FriendlyName'], m.Text)
Figa questa libreria! :)
La notazione LINQ non e' male, ma mi sembra che a C# continuino ad aggiungere tante funzionalita' singole senza soffermarsi a cercare un set base di caratteristiche ortogonali che da cui derivare le altre.
Ad esempio in Lisp l' object system si puo' scrivere come libreria, e una sintassi come LINQ uno se la puo' fare usando le macro. In haskell funzionalita' come IO, ricerca con backtracking, parser combinators condividono uno stessa stessa struttura di base che permette di costruirsi dei DSL specifici... alla lunga paga perche' aumentando le funzionalita' la complessita' non cresce in ugual misura.
Amen.
^TiGeRShArK^
29-07-2009, 14:59
:what:
:D
:stordita: Allora Dragonball non l'hai mai letto? :fagiano:
Si, insieme a Berserk (:ave: ), vagabond, slam dunk, city hunter, porompompin (:D) e un altro bel pò di manga, ma preferisco la modalità italiana. :p
^TiGeRShArK^
29-07-2009, 15:06
In python probabilmente si scriverebbe qualcosa del genere
from BeautifulSoup import BeautifulStoneSoup as soup
xml = soup( file( "..." ) )
messages = xml.findAll( "Message" )
for m in message:
print "[%s %s] <%s> %s" % (m['Date'], m['Time'], m.From.User['FriendlyName'], m.Text)
La notazione LINQ non e' male, ma mi sembra che a C# continuino ad aggiungere tante funzionalita' singole senza soffermarsi a cercare un set base di caratteristiche ortogonali che da cui derivare le altre.
Ad esempio in Lisp l' object system si puo' scrivere come libreria, e una sintassi come LINQ uno se la puo' fare usando le macro. In haskell funzionalita' come IO, ricerca con backtracking, parser combinators condividono uno stessa stessa struttura di base che permette di costruirsi dei DSL specifici... alla lunga paga perche' aumentando le funzionalita' la complessita' non cresce in ugual misura.
C'era anche in java qualcosa del genere che si ricreava in memoria degli oggetti partendo dall'xml tramite reflection, ma non fa parte del framework di default. :p
Comunque in effetti non dovrebbe essere difficile implementare qualcosa di simile anche in C# partendo da linq to xml, ma x ora non ho proprio tempo...:sob:
banryu79
29-07-2009, 15:08
Si, insieme a Berserk (:ave: ), vagabond, slam dunk, city hunter, porompompin (:D) e un altro bel pò di manga...
[SUPER OT]
Alita (Gunnm) :)
[/SUPER OT]
^TiGeRShArK^
29-07-2009, 15:11
[SUPER OT]
Alita (Gunnm) :)
[/SUPER OT]
[SUPER OT]
letto anche quello ovviamente. :p
[/SUPER OT]
malocchio
29-07-2009, 16:40
La mia classifica:
1) C
2) PHP
3) VB.net
Bene, buttiamo a mare anche la macchina di Turing, visto che ci siamo...:eek:
:yeah: !!!Nostradamus mi fa un baffo mi fa!!! :yeah::asd:
PS: L'importante è che Perl scenda. :asd:Php invece sale! :eek:
E sono convinto che java ne pagherà il prezzo se non sarà + competitiva con C#.LA Java :confused: ?
Non si può essere meno attendibili di totalmente inattendibili. O no? :confused:Sembra quasi di stare in piazzetta :O :asd:
E cosa dovrebbe fare un insieme di applicazioni/moduli? :fagiano:
Si compone. Lassamo perdere... :D.
zulutown
29-07-2009, 17:27
php, python e in genere qualunque linguaggio di scripting
cdimauro
29-07-2009, 17:56
Python non è più un linguaggio di scripting da eoni. :O
Come faccio a rispondere se t'ho detto che a casa ho soltanto VS Express? E' a lavoro che ho VS + SDK per Windows Mobile e posso verificare. non devi verificare nulla, devi solo dirmi dove stanno i sorgenti del driver. ti do un aiuto: non ci stanno.
su ARM invece no perché il WDK (che tu evidentemente non conosci, altrimenti non cercheresti di sincerarti di queste cose, e te lo faccio notare per farti capire che stai cercando di discutere di cose che non conosci) non permette di programmare drivers per Windows Mobile mi sembra ben diverso da quanto mi hai messo in bocca...
A rimarcare che Windows Mobile non è vincolato alla sola architettura ARM. d'accordo, e allora quando si parlava della tua travolgente esperienza lavorativa in Windows Mobile perché hai tirato fuori un driver che palesemente per Windows Mobile non é?
Le risate se le fa chi sa cos'è un linguaggio di programmazione, e sa distinguerlo da una qualsiasi implementazione. le risate se le sono giá fatte quelli che leggendo il flame di sfuggita hanno avuto la fortuna di capitare su quella perla :asd:
Si vede che tu non hai la minima idea di cosa significhi sviluppare un videogioco su Amiga. ma al contrario di te non ho difficoltá ad ammettere di non aver mai avuto a che fare con certe cose: non si puó vivere in tutte le epoche, io sono capitato in questa e un Amiga non l'ho mai toccato in vita mia.
La tua affermazione non è che si debba invalidare. bravo, finalmente un ragionevole cambio di rotta:
io - "e come mai il contesto invaliderebbe la mia affermazione?"
tu - "<pippe mentali>"
io - "e allora?"
tu - "ah ma no, non é che si deve invalidare, che hai capito!"
Semplicemente non è pertinente / applicabile al contesto citato. é corretta e supportata da fonti ufficiali e tanto mi basta per esprimerla. che poi non sia pertinente é una tua opinione: stiamo parlando di un linguaggio di cui esiste una sola implementazione che possa essere ragionevolmente usata per un certo scopo, e della relativitá di quel "ragionevolmente"; in altre parole quel linguaggio praticamente non ha implementazioni che permettano di raggiungere quello scopo.
Che sia quasi uguale al C è una tua speculazione. ho giá fatto l'elenco delle principali features inutilizzabili e il resoconto delle principali features "extra-C" che restano utilizzabili, se hai da aggiungere aggiungi ma non mi chiamare C++ quello che resta perché é evidente che C++ non é, é un sottoinsieme molto ridotto. se non sei d'accordo fattelo andare bene lo stesso perché la mia frase iniziale non voleva dire che quando programmi in kernel mode non puoi usare i tipi reference.
Anzi, finora mi sembra che l'unico punto su cui c'è convergenza è l'uso delle eccezioni, anche se rimangono utilizzabili su contesti / pezzi di codice limitati. prego? eccezioni C++ usabili in kernel-mode in contesti particolari, ho capito bene? quali contesti, di grazia?
Nessun sarcasmo: era un precisa richiesta.
Prendi i manuali di riferimento dei rispettivi linguaggi e fammi vedere cos'è che il C avrebbe rispetto al C++, che impedisce o limita fortemente a quest'ultimo nell'essere usatilizzato per scrivere codice a basso livello. evidentemente sono andato troppo avanti con la discussione e tu non ci sei ancora arrivato, quindi andiamo un passettino alla volta (vedi sotto).
Sei in grado di portare almeno un esempio, oppure no? no, non sono in grado, non ne trovo: non trovo features del C che, mancando nel C++, impediscano per definizione la scrittura di codice a basso livello. allora?
Che dimostra soltanto che è consigliabile di no, naturalmente, ma ti assicuro che non é il caso di introdurre fattori complicanti in un simile contesto di sviluppo: il "non consigliabile" puó fin troppo facilmente trasformarsi in "semplicemente impossibile", solo una robusta esperienza puó evitarlo e comunque non ne vale la pena.
e... solo per Windows. non sto parlando d'altro.
Quando invece javaboy avevo parlato più genericamente del linguaggio C++, quindi senza legarsi a una particolare implementazione come hai fatto tu, e il problema sarebbe?
e pretendendo poi di estendere il singolo caso all'intero linguaggio. si estende molto facilmente se il suddetto singolo caso é l'unica implementazione di quel linguaggio che permetta di discutere di una certa questione.
Insomma, poca roba rispetto al C. E immagino che si tratti sempre di fuffa inutile, no? vedo che non hai capito niente.
non so cosa tu abbia fantasticato ma io non ho alcuna idiosincrasia nei confronti del C++ e sarei il primo ad essere felice di poterlo usare per programmare drivers per Windows.
cdimauro
29-07-2009, 21:44
non devi verificare nulla, devi solo dirmi dove stanno i sorgenti del driver. ti do un aiuto: non ci stanno.
Allora non vuoi proprio capire:
Come faccio a rispondere se t'ho detto che a casa ho soltanto VS Express?
mi sembra ben diverso da quanto mi hai messo in bocca...
TU: su ARM invece no perché il WDK ... non permette di programmare drivers per Windows Mobile
IO: Avevi scritto che su WM non era possibile creare driver.
Conosci un altro modo per scrivere driver su WM?
d'accordo, e allora quando si parlava della tua travolgente esperienza lavorativa in Windows Mobile perché hai tirato fuori un driver che palesemente per Windows Mobile non é?
Questo lo potrò appurare quando potrò metterci le mani.
le risate se le sono giá fatte quelli che leggendo il flame di sfuggita hanno avuto la fortuna di capitare su quella perla :asd:
Infatti si vede chi hanno quotato su certe affermazioni sul C++: te e non me.
ma al contrario di te non ho difficoltá ad ammettere di non aver mai avuto a che fare con certe cose:
Si vede che non hai seguito bene la discussione, perché questo:
Non l'ho mai fatto e non è necessario che lo faccia per sapere se è possibile oppure no.
l'ho già scritto immediatamente dopo la tua domanda in merito.
non si puó vivere in tutte le epoche, io sono capitato in questa e un Amiga non l'ho mai toccato in vita mia.
E allora non partire avanti con giudizi su chi ha usato poco i debugger. Io le ossa me le sono fatte quando era impossibile usarne uno.
bravo, finalmente un ragionevole cambio di rotta:
io - "e come mai il contesto invaliderebbe la mia affermazione?"
tu - "<pippe mentali>"
io - "e allora?"
tu - "ah ma no, non é che si deve invalidare, che hai capito!"
Le mie "pippe mentali" si chiamano definizioni di linguaggio di programmazione e di implementazione. Due concetti diversi, sebbene legati.
é corretta e supportata da fonti ufficiali e tanto mi basta per esprimerla. che poi non sia pertinente é una tua opinione: stiamo parlando di un linguaggio di cui esiste una sola implementazione che possa essere ragionevolmente usata per un certo scopo, e della relativitá di quel "ragionevolmente"; in altre parole quel linguaggio praticamente non ha implementazioni che permettano di raggiungere quello scopo.
Quindi le tue valutazioni riguardano esclusivamente quella particolare implementazione, e lì devono rimanere confinate.
Non hanno NULLA a che vedere col linguaggio di per sé, come sto cercando di farti capire da un bel pezzo.
ho giá fatto l'elenco delle principali features inutilizzabili e il resoconto delle principali features "extra-C" che restano utilizzabili, se hai da aggiungere aggiungi ma non mi chiamare C++ quello che resta perché é evidente che C++ non é, é un sottoinsieme molto ridotto. se non sei d'accordo fattelo andare bene lo stesso perché la mia frase iniziale non voleva dire che quando programmi in kernel mode non puoi usare i tipi reference.
Lo chiamo C++ come lo chiamerebbe Stroustrop che l'ha creato, e come qualche altro utente ha cercato invano di farti capire.
In soldoni: del C++ utilizzi gli strumenti che ritieni più opportuno utilizzare a seconda del problema che devi risolvere.
Per maggiori informazioni, c'è il manuale di riferimento del linguaggio scritto dallo stesso autore, che sull'uso del suo linguaggio si è espresso fin troppo chiaramente.
prego? eccezioni C++ usabili in kernel-mode in contesti particolari, ho capito bene? quali contesti, di grazia?
E' sufficiente essere sicuri di usarle in codice che rimane sotto il completo controllo dell'applicazione. Quindi senza che vengano invocate API esterne al codice.
evidentemente sono andato troppo avanti con la discussione e tu non ci sei ancora arrivato, quindi andiamo un passettino alla volta (vedi sotto).
no, non sono in grado, non ne trovo: non trovo features del C che, mancando nel C++, impediscano per definizione la scrittura di codice a basso livello. allora?
Allora vale quanto detto da javaboy: il C++ si può usare per scrivere codice a basso livello.
Con buona pace di quello che gli hai risposto.
naturalmente, ma ti assicuro che non é il caso di introdurre fattori complicanti in un simile contesto di sviluppo: il "non consigliabile" puó fin troppo facilmente trasformarsi in "semplicemente impossibile", solo una robusta esperienza puó evitarlo e comunque non ne vale la pena.
Non credo che a scrivere driver si metta gente senza o con poca esperienza. Sia per la scrittura dei driver, che per la conoscenza del C++.
non sto parlando d'altro.
E javaboy parlava d'altro.
e il problema sarebbe?
Che la tua risposta era fuori luogo, visto che il contesto era il linguaggio.
si estende molto facilmente se il suddetto singolo caso é l'unica implementazione di quel linguaggio che permetta di discutere di una certa questione.
Le tue valutazioni non si possono "estendere": rimangono confinate strettamente al contesto di riferimento, cioé soltanto all'implementazione che hai citato.
vedo che non hai capito niente.
non so cosa tu abbia fantasticato ma io non ho alcuna idiosincrasia nei confronti del C++ e sarei il primo ad essere felice di poterlo usare per programmare drivers per Windows.
javaboy: Però la "bruttezza" del c++ è dovuta a ben due buone ragioni:
1) Permette di lavorare a basso livello
TU: non é del tutto vero: non é quasi mai possibile usare il C++ per scrivere drivers per Windows.
Lui parla del linguaggio, e tu di una sua particolare implementazione.
Se questa implementazione limita l'uso del C++, nulla si può dire sulle capacità del C++ di permettere di scrivere codice a basso livello.
Giusto per fare un altro esempio, non è che se prendo un interprete C o C++, mi posso arrogare il diritto di affermare che questi linguaggi sono interpretati: lo sono soltanto quelle particolari implementazioni, ma i linguaggi di per sé NON pongono limiti al fatto di essere interpretati, compilati, compilati in bytecode, ecc. ecc.
Un linguaggio serve soltanto a una cosa: a definire sintassi e semantica. Il resto sono rogne che competono esclusivamente alle particolari implementazioni.
Allora non vuoi proprio capire:
Come faccio a rispondere se t'ho detto che a casa ho soltanto VS Express? mi prendi per il culo? i files con estensione .c o .cpp li puoi aprire anche con Blocco Note! non ti serve Visual Studio per trovare i sorgenti che ti sto chiedendo, ti serve un miracolo.
TU: su ARM invece no perché il WDK ... non permette di programmare drivers per Windows Mobile
IO: Avevi scritto che su WM non era possibile creare driver.
Conosci un altro modo per scrivere driver su WM? no, ma non significa che non esista; ci sará un kit apposito.
Infatti si vede chi hanno quotato su certe affermazioni sul C++: te e non me. "gné gné gné, guarda che ce l'hanno tutti con te!! :Prrr:"
praticamente adesso per difenderti ricorri alle parole degli altri: incommentabile :rolleyes:
Si vede che non hai seguito bene la discussione, perché questo:
Non l'ho mai fatto e non è necessario che lo faccia per sapere se è possibile oppure no.
l'ho già scritto immediatamente dopo la tua domanda in merito. ah, hai ragione: dovevo scrivere che io a differenza di te non ho difficoltá ad ammettere di essere totalmente incapace in cose che non ho mai fatto.
E allora non partire avanti con giudizi su chi ha usato poco i debugger. Io le ossa me le sono fatte quando era impossibile usarne uno. tutto rispetto per le ossa che ti sei fatto ma visto quanto scrivi non ti servirebbero a molto se oggi improvvisamente dovessi avere a che fare con WinDbg, e questa é una cosa che hai proprio difficoltá a scrivere: io ho fatto qui, io ho fatto lá, all'epoca si faceva cosi, io sono un grande pioniere dell'informatica... ma "io non ne so un cazzo" non ti esce proprio.
Le mie "pippe mentali" si chiamano definizioni di linguaggio di programmazione e di implementazione. Due concetti diversi, sebbene legati. whatever.
Quindi le tue valutazioni riguardano esclusivamente quella particolare implementazione, e lì devono rimanere confinate.
Non hanno NULLA a che vedere col linguaggio di per sé, come sto cercando di farti capire da un bel pezzo. tutte queste interessanti considerazioni quale difetto comportano nella mia affermazione originale?
Lo chiamo C++ come lo chiamerebbe Stroustrop che l'ha creato, e come qualche altro utente ha cercato invano di farti capire. chiamalo come ti pare, basta capirsi: la spiegazione della mia idea sui nomi l'hai avuta. perché ho quest'idea cosi bislacca? perché non ho mai letto alcuno su Internet che abbia affermato di aver scritto un kernel driver per Windows in C++, cosi come non ho mai ne' letto ne' sentito alcuno definire codice C++ un sorgente scritto in C.
In soldoni: del C++ utilizzi gli strumenti che ritieni più opportuno utilizzare a seconda del problema che devi risolvere. e come la mettiamo quando invece sei impossibilitato ad usare un certo strumento?
E' sufficiente essere sicuri di usarle in codice che rimane sotto il completo controllo dell'applicazione. Quindi senza che vengano invocate API esterne al codice. quale applicazione? cosa stai farneticando? stiamo ancora parlando di kernel drivers?
Allora vale quanto detto da javaboy: il C++ si può usare per scrivere codice a basso livello. non sempre.
non c'é nulla nel C++ che per definizione impedisca la scrittura di codice C++ che funzioni quando il processore é in kernel mode (almeno per quanto riguarda l'architettura x86 a 32 bit e il ring 0, non so le altre architetture), ma non c'é neanche nulla che garantisca che questo si possa fare sempre.
Non credo che a scrivere driver si metta gente senza o con poca esperienza. Sia per la scrittura dei driver, che per la conoscenza del C++. esiste una prima volta in tutto, anche per la scrittura di un driver. scrivere un driver WDM é un'esperienza di sviluppo che non assomiglia a nessun'altra, garantisco. come complessitá tecnica si fa battere solo dalla scrittura di un FSD.
E javaboy parlava d'altro. no, javaboy parlava di un caso piu generale che raccoglieva anche quello: se dici "programmazione a basso livello" in assoluto non puoi escludere la programmazione a basso livello su Windows.
essendo un caso piu generale probabilmente capirai tutto "quando avrai un'adeguata conoscenza di come funzionano le architetture degli elaboratori" :asd:
Che la tua risposta era fuori luogo, visto che il contesto era il linguaggio. non mi sembrava tanto fuor di luogo, sempre di C++ si stava parlando. come avresti definito se invece che in quel modo io avessi risposto dicendo che vado matto per i bucatini alla carbonara?
Le tue valutazioni non si possono "estendere": rimangono confinate strettamente al contesto di riferimento, cioé soltanto all'implementazione che hai citato. mi ricordo di quando PGI-Bis descrisse dialoghi ottusi come questi con un'analogia molto divertente che recitava qualcosa del tipo: "che giorno é oggi?" - "le 12 e un quarto". :D
in effetti é stancante fare questo botta e risposta cosi idiota per tre giorni di seguito.
javaboy: Però la "bruttezza" del c++ è dovuta a ben due buone ragioni:
1) Permette di lavorare a basso livello
TU: non é del tutto vero: non é quasi mai possibile usare il C++ per scrivere drivers per Windows.
Lui parla del linguaggio, e tu di una sua particolare implementazione. si, ma non c'é alcun problema in ció perché io parlando di una specifica implementazione ho smentito una sua affermazione errata nel caso generale: il C++ in generale non permette di lavorare (agevolmente) a basso livello, infatti esiste almeno un caso in cui usare il C++ a basso livello sarebbe un incubo come pochi.
a questo punto non si tratta piu di una questione tecnica ma dialettica, e a me francamente interessa poco: se vuoi capire il mio italiano fantastico, altrimenti anche 'sti cazzi.
Se questa implementazione limita l'uso del C++, nulla si può dire sulle capacità del C++ di permettere di scrivere codice a basso livello. io infatti non ho detto nulla sulle capacitá del linguaggio C++ (di per se') di permettere di scrivere codice a basso livello: in teoria il linguaggio C++ puó permettere di scrivere anche un bootloader che fa la transizione da modalitá reale a 16 bit a modalitá protetta a 32 bit per quanto mi riguarda.
anche qui, questione di dialettica, di espressione linguistica.
Giusto per fare un altro esempio, non è che se prendo un interprete C o C++, mi posso arrogare il diritto di affermare che questi linguaggi sono interpretati: lo sono soltanto quelle particolari implementazioni, ma i linguaggi di per sé NON pongono limiti al fatto di essere interpretati, compilati, compilati in bytecode, ecc. ecc. mi dispiace ma l'esempio non calza :stordita:
Frank1962
30-07-2009, 02:12
dato che per me sono tutti orrendi (da scheme,ocaml in giù) ribalto la domanda/risposta:
The BEST is:
1) Java
2) Java
3) Java
static{int x=3;} while(true) { System.out.println(++x + ") Java") }
Java forever ....semplice, efficente, chiaro e conciso nella sintassi, è in licenza open GPL e, sopratutto, è GRATIS ---> a differenza di quella monnezza di C#!
all'infinitesimo posto metterei C,C++ e tutto l'accozzaglia di assembly solo per la retrocompatibilità con stè caffettiere di macchine hardware che ci ritroviamo a dover programmare (cellulari,palmari,tv,netbook,notebook,pc,ecc...) e che si ostinano a produrre ancora con delle isa antiquate e, ovviamente, proprietarie .....se un giorno si decidessero, per produrre l'hardware, di prendere il bytecode di Java come punti di riferimento e non la loro minchia non sarà mai troppo tardi!
^TiGeRShArK^
30-07-2009, 07:32
dato che per me sono tutti orrendi (da scheme,ocaml in giù) ribalto la domanda/risposta:
The BEST is:
1) Java
2) Java
3) Java
static{int x=3;} while(true) { System.out.println(++x + ") Java") }
Java forever ....semplice, efficente, chiaro e conciso nella sintassi, è in licenza open GPL e, sopratutto, è GRATIS ---> a differenza di quella monnezza di C#!
all'infinitesimo posto metterei C,C++ e tutto l'accozzaglia di assembly solo per la retrocompatibilità con stè caffettiere di macchine hardware che ci ritroviamo a dover programmare (cellulari,palmari,tv,netbook,notebook,pc,ecc...) e che si ostinano a produrre ancora con delle isa antiquate e, ovviamente, proprietarie .....se un giorno si decidessero, per produrre l'hardware, di prendere il bytecode di Java come punti di riferimento e non la loro minchia non sarà mai troppo tardi!
1) C# è gratis.
2) Con la versione normale di java non puoi assolutamente scrivere software realtime per via delle latenze non deterministiche causate dal GC.
STOP al flame, ma quando di STOP vuol dire STOP davvero :D
Comunque il linguaggio che più ho odiato è il Prolog :Puke:
cdimauro
30-07-2009, 08:20
mi prendi per il culo? i files con estensione .c o .cpp li puoi aprire anche con Blocco Note! non ti serve Visual Studio per trovare i sorgenti che ti sto chiedendo, ti serve un miracolo.
Non ti prendo per il culo, ma onestamente non so proprio come prenderti, visto che continui a non capire che l'SDK per Windows Mobile l'ho installato soltanto in ufficio e, quindi, da casa non mi era possibile andare a controllare i file.
Comunque il progetto (soluzione) in questione non è completo: mancano pezzi di codice. Infatti non compila:
Errore 10 general error c10100b1: Failed to load file "..\Win32\Debug\SimpleThermostatDriver.exe". Impossibile trovare il file specificato. mt.exe SimpleThermostatDriver
Ma ciò non significa che non sia possibile realizzare driver con Windows Mobile. Semplicemente alla MS si sono dimenticati di fornire il codice completo per l'esempio nell'SDK. Infatti nella stessa cartella il file scenario.jpg mostra in che modo si relazionano i vari componenti del sistema, e Simple Thermostat Driver vi fa parte.
no, ma non significa che non esista; ci sará un kit apposito.
Se lo trovi fammi un fischio.
"gné gné gné, guarda che ce l'hanno tutti con te!! :Prrr:"
praticamente adesso per difenderti ricorri alle parole degli altri: incommentabile :rolleyes:
Sei stato TU che hai tirato in ballo gli altri utenti cercando di deridermi.
Io ti ho semplicemente fatto notare che chi ha ricevuto più volte messaggi sulle proprie affermazioni riguardo il C++ non sono stato certo io, ma tu. E non sono stati scritti né per farti i complimenti né per dirti che erano d'accordo con te... :mc:
ah, hai ragione: dovevo scrivere che io a differenza di te non ho difficoltá ad ammettere di essere totalmente incapace in cose che non ho mai fatto.
Guarda, che tu sia incapace o no, è un problema tuo. Io le capacità le ho, e al più mi toccherebbe cimentarmi nell'opera. Come sempre.
tutto rispetto per le ossa che ti sei fatto ma visto quanto scrivi non ti servirebbero a molto se oggi improvvisamente dovessi avere a che fare con WinDbg, e questa é una cosa che hai proprio difficoltá a scrivere: io ho fatto qui, io ho fatto lá, all'epoca si faceva cosi, io sono un grande pioniere dell'informatica... ma "io non ne so un cazzo" non ti esce proprio.
Direi proprio di no, perché non mi mancano certo le capacità né tanto meno è obbligatorio lavorare col WinDbg quando si sviluppano driver.
tutte queste interessanti considerazioni quale difetto comportano nella mia affermazione originale?
Che le mele non si possono confrontare con le pere, come ho già detto.
chiamalo come ti pare, basta capirsi: la spiegazione della mia idea sui nomi l'hai avuta. perché ho quest'idea cosi bislacca? perché non ho mai letto alcuno su Internet che abbia affermato di aver scritto un kernel driver per Windows in C++,
http://www.perisoft.net/engineer/cpp.htm
http://blogs.msdn.com/bobkjelgaard/archive/2009/03/12/using-c-in-a-kmdf-driver-part-1-a-pattern-for-using-contexts-as-objects.aspx
Con tanto di codice annesso.
Da notare poi che il secondo link è di MSDN...
cosi come non ho mai ne' letto ne' sentito alcuno definire codice C++ un sorgente scritto in C.
Se fosse scritto in C si potrebbe prendere il sorgente e compilarlo con un compilatore C, ma ho la NON vaga impressione che l'operazione non andrebbe in porto...
e come la mettiamo quando invece sei impossibilitato ad usare un certo strumento?
Premesso che finora di impossibilità non si è mai parlato, non vedo quale sia il problema: semplicemente non si usa lo strumento.
Come dicevo prima, gli strumenti si usano se risultano adeguati alla risoluzione di particolari problemi.
quale applicazione? cosa stai farneticando? stiamo ancora parlando di kernel drivers?
Piccolo lapsus. Mi riferivo al codice del driver, ovviamente (il contesto era quello).
non sempre.
non c'é nulla nel C++ che per definizione impedisca la scrittura di codice C++ che funzioni quando il processore é in kernel mode (almeno per quanto riguarda l'architettura x86 a 32 bit e il ring 0, non so le altre architetture), ma non c'é neanche nulla che garantisca che questo si possa fare sempre.
Dipende sempre dall'implementazione, perché il linguaggio, come tu stesso hai ammesso, non ne preclude l'uso.
esiste una prima volta in tutto, anche per la scrittura di un driver. scrivere un driver WDM é un'esperienza di sviluppo che non assomiglia a nessun'altra, garantisco. come complessitá tecnica si fa battere solo dalla scrittura di un FSD.
Non lo metto in dubbio, ma non parti da zero. Ci sono esempi e documentazione a cui attingi. E il linguaggio di programmazione quanto meno lo devi padroneggiare molto bene.
no, javaboy parlava di un caso piu generale che raccoglieva anche quello: se dici "programmazione a basso livello" in assoluto non puoi escludere la programmazione a basso livello su Windows.
essendo un caso piu generale probabilmente capirai tutto "quando avrai un'adeguata conoscenza di come funzionano le architetture degli elaboratori" :asd:
javaboy non parla di un caso generale, ma del linguaggio, cosa ben diversa da una sua implementazione che può anche essere viziata da problemi che non permettono di sfruttare tutte le potenzialità del linguaggio.
Ripeto: stai cercando di confrontare due cose completamente diverse. Linguaggio = sintassi + semantica. Null'altro.
A parte questo e limitandoci alla sola implementazione per Windows, non mi sembra che ne venga escluso l'uso per la scrittura di codice a basso livello. Tutt'altro.
non mi sembrava tanto fuor di luogo, sempre di C++ si stava parlando. come avresti definito se invece che in quel modo io avessi risposto dicendo che vado matto per i bucatini alla carbonara?
typeof(Linguaggio) != typeof(Implementazione)
Sono due diverse.
mi ricordo di quando PGI-Bis descrisse dialoghi ottusi come questi con un'analogia molto divertente che recitava qualcosa del tipo: "che giorno é oggi?" - "le 12 e un quarto". :D
in effetti é stancante fare questo botta e risposta cosi idiota per tre giorni di seguito.
Non lo metto in dubbio. Eppure i concetti di linguaggio e di implementazione dovrebbero essere a prova di idiota, per cui non mi spiego questo continuare a confrontare due cose diverse fra di loro.
si, ma non c'é alcun problema in ció perché io parlando di una specifica implementazione ho smentito una sua affermazione errata nel caso generale: il C++ in generale non permette di lavorare (agevolmente) a basso livello, infatti esiste almeno un caso in cui usare il C++ a basso livello sarebbe un incubo come pochi.
a questo punto non si tratta piu di una questione tecnica ma dialettica, e a me francamente interessa poco: se vuoi capire il mio italiano fantastico, altrimenti anche 'sti cazzi.
Ripeto, non è un problema del linguaggio, e se con l'italiano non ci capiamo, possiamo anche prendere l'inglese:
With its object features, C++ appears to be a natural match for the semantics of Microsoft Windows Driver Model (WDM) and Windows Driver Foundation (WDF) drivers, and it is appealing for the added convenience and expressive power it provides to developers. However, technical issues associated with writing kernel-mode code in C++ using the currently available Microsoft compilers can cause problems in driver code.
Many developers use the C++ compiler as a “super-C” without using the full C++ language, because the C++ compiler enforces certain rules more strictly than standard C compilers and provides some additional features that happen to be safe for use in the context of drivers. Using the C++ compiler in this way is typically expected to work for kernel-mode code. It is “advanced” C++ features such as non-POD (“plain ol’ data”, as defined by the C++ standard) classes and inheritance, templates, and exceptions that present problems for kernel-mode code. These problems are due more to the C++ implementation and the kernel environment than to the inherent properties of the C++ language.
Da notare in particolare l'ultima frase, che distingue fra implementazione e linguaggio (ma tu guarda: non l'avrei mai detto!).
E questo lo dice MS nel link che tu stesso hai passato.
io infatti non ho detto nulla sulle capacitá del linguaggio C++ (di per se') di permettere di scrivere codice a basso livello: in teoria il linguaggio C++ puó permettere di scrivere anche un bootloader che fa la transizione da modalitá reale a 16 bit a modalitá protetta a 32 bit per quanto mi riguarda.
anche qui, questione di dialettica, di espressione linguistica.
Appunto. Linguaggio = sintassi + semantica = potenzialità. Poi se le implementazioni presentano problemi, non è certo colpa del linguaggio di per sé.
mi dispiace ma l'esempio non calza :stordita:
Calza alla perfezione invece. Tu su una particolare implementazione del C++ pretendi di trarre conclusioni sul linguaggio. E io ho fatto esattamente la stessa cosa.
dato che per me sono tutti orrendi (da scheme,ocaml in giù) ribalto la domanda/risposta:
The BEST is:
1) Java
2) Java
3) Java
static{int x=3;} while(true) { System.out.println(++x + ") Java") }
Java forever ....semplice, efficente, chiaro e conciso nella sintassi,
Per il linguaggio preferito c'è un apposito thread.
è in licenza open GPL
Di questo c'è poco da vantarsi. :asd:
e, sopratutto, è GRATIS ---> a differenza di quella monnezza di C#!
... che è pure gratis. :asd:
all'infinitesimo posto metterei C,C++ e tutto l'accozzaglia di assembly solo per la retrocompatibilità con stè caffettiere di macchine hardware che ci ritroviamo a dover programmare
Certo. E poi vorrei ben vedere in che modo potresti ottenere gli eseguibili del tuo linguaggio preferito. :asd:
(cellulari,palmari,tv,netbook,notebook,pc,ecc...) e che si ostinano a produrre ancora con delle isa antiquate e, ovviamente, proprietarie .....
Ma anche no.
se un giorno si decidessero, per produrre l'hardware, di prendere il bytecode di Java come punti di riferimento e non la loro minchia non sarà mai troppo tardi!
Speriamo di no. Di ISA fatte alla cazzo di cane ne esistono già troppe. Cerchiamo di non peggiorare la situazione. :asd:
EDIT:
STOP al flame, ma quando di STOP vuol dire STOP davvero :D
Mi sono accorto di questo soltanto dopo aver scritto già il messaggio.
Se ritieni opportuno cancellarlo o modificarlo, per me non c'è problema. Quel che avevo da dire l'ho ripetuto decine di volte.
Comunque faccio notare soltanto una cosa: la discussione stava filando bene, finché "qualcuno" non ha deciso di spostarla sul piano personale, ricorrendo a battutine fuori luogo e prendendo in giro.
Comunque il linguaggio che più ho odiato è il Prolog :Puke:
A me invece è piaciuto. :fagiano:
malocchio
30-07-2009, 09:05
Personalmente penso che il modo migliore per evitare una discussione del tipo "Che giorno è oggi" - "Le 12 e un quarto"
non è rispondere facendo notare all'altro che di questo si tratta, ma piantarla per primo :cry:.
banryu79
30-07-2009, 09:10
Personalmente penso che il modo migliore per evitare una discussione del tipo "Che giorno è oggi" - "Le 12 e un quarto"
non è rispondere facendo notare all'altro che di questo si tratta, ma piantarla per primo :cry:.
Esite un'alternativa che fa contenti tutti: portare avanti il diverbio in pvt :D
malocchio
30-07-2009, 09:28
Esite un'alternativa che fa contenti tutti: portare avanti il diverbio in pvt :D
Hai PM :eek:
Mi sono accorto di questo soltanto dopo aver scritto già il messaggio.
Non faccio niente, però devo concedere anche a fero86 un'ultima risposta ;)
Per gli altri: quando vedete queste cose, usate il tasto segnala. Visto sopratutto che mi sembra vi diano fastidio.
cdimauro
30-07-2009, 10:18
Non c'è problema. Mi sembra corretto.
Frank1962
30-07-2009, 10:27
1) C# è gratis.
per un Console.print anche forse ...se vuoi poter utilizzare le librerie, per esempio, per collegarti ad excel allora mi sà che c'è da pagare (Visual Studio or similari a meno di non ricorrere a soluzioni non standard/non microsoft)
2) Con la versione normale di java non puoi assolutamente scrivere software realtime per via delle latenze non deterministiche causate dal GC.
mi sa che neanche con la verisione "normale" di C# .....cioè, anche su Vista nel Task Manager dei processi c'è l'opzione "Tempo Reale" ma avrei qualche dubbio sulla sua reale affidabilità conoscendo di fama la Microsozzz :D
....poi quà mi sà che si stà facendo un pò di confusione tra linguaggio, librerie e implementazione!
astorcas
30-07-2009, 10:32
per un Console.print anche forse ...se vuoi poter utilizzare le librerie, per esempio, per collegarti ad excel allora mi sà che c'è da pagare (Visual Studio or similari a meno di non ricorrere a soluzioni non standard/non microsoft)
mi sa che neanche con la verisione "normale" di C# .....cioè, anche su Vista nel Task Manager dei processi c'è l'opzione "Tempo Reale" ma avrei qualche dubbio sulla sua reale affidabilità conoscendo di fama la Microsozzz :D
....poi quà mi sà che si stà facendo un pò di confusione tra linguaggio, librerie e implementazione!
ehm lì se vuoi "collegarti" con excel basta che sia installato excel, nient'altro.
il secondo commento non capisco dove voglia arrivare perciò lo ignoro :fagiano:
cdimauro
30-07-2009, 10:53
Non ti preoccupare: è il classico flame da fanatico Linaro-quindi-anti-MS...
Non ti preoccupare: è il classico flame da fanatico Linaro-quindi-anti-MS...
Non mi sembra il caso di attaccare così.
Senza sistema operativo realtime è impossibile scrivere applicazioni realtime ;)
Windows non è realtime, quindi niente applicazioni VERAMENTE realtime.
astorcas
30-07-2009, 11:10
Non mi sembra il caso di attaccare così.
Senza sistema operativo realtime è impossibile scrivere applicazioni realtime ;)
Windows non è realtime, quindi niente applicazioni VERAMENTE realtime.
Non so se voleva sottolineare questa finezza.. ma bisogna ammettere che
ma avrei qualche dubbio sulla sua reale affidabilità conoscendo di fama la Microsozzz
non mi sembra così simpatizzante per zio Bill....
Ah....
mi sa che neanche con la verisione "normale" di C#
forse voleva scrivere
mi sa che neanche con la verisione "normale" di Windows....
banryu79
30-07-2009, 11:10
il secondo commento non capisco dove voglia arrivare perciò lo ignoro :fagiano:
Lasciando perdere la battuta sul task manager l'ultima frase che da è in risposta a questa osservazione, per altro corretta, di ^TiGeRShArK^:
2) Con la versione normale di java non puoi assolutamente scrivere software realtime per via delle latenze non deterministiche causate dal GC.
Frank1962 fa notare che se si parla di linguaggio Java si parla di una cosa; se poi si parla della sua "impletazione standard" (quella sella Sun) o della sua "implementazione real time" (una implementazione commerciale della Sun delle specifiche JSR-001 aggiornate dalle specifiche JSR-282) oppure di un'altra qualsiasi implementazione, si sta parlando di altro.
Non so se voleva sottolineare questa finezza.. ma bisogna ammettere che
non mi sembra così simpatizzante per zio Bill....
Certo, ma in ogni caso è un'affermazione che ha solo lo scopo di creare flame.
Frank1962
30-07-2009, 11:32
ehm lì se vuoi "collegarti" con excel basta che sia installato excel, nient'altro.
& il Visual Studio 'ndo lo metti? :D
il secondo commento non capisco dove voglia arrivare perciò lo ignoro :fagiano:
vabbò lassamo perdere che è meglio
Non ti preoccupare: è il classico flame da fanatico Linaro-quindi-anti-MS...
interessante come argomentazione ....per il "fanatico" lascio cortesemente la palla al moderatore di turno che pare sia già intervenuto in merito ....per il "Linaro Anti MS" ti dico semplicemente che se ci sono aziende e/o realtà che producono software Open-Source che mi permette di vedere che cosa fa un processo sulla mia macchina e che sono valide alternative a sistemi proprietari Closed-Source allora, bè sì, qualche astio verso Microsoft c'è l'ho sopratutto dopo anni e anni che per comprare un portatile sono COSTRETTO AD ACQUISTARE UNA LICENZA WINDOWS nelle sue molteplici forme e versioni!
Frank1962: però se io intervengo tu non devi rispondere...
astorcas
30-07-2009, 11:37
& il Visual Studio 'ndo lo metti? :D
1)http://www.microsoft.com/express/vcsharp/
oppure per uscire fuori dal mondo MS
2) http://www.icsharpcode.net/OpenSource/SD/
oppure
3)http://notepad-plus.sourceforge.net/it/site.htm
passando da 1 a 3 le cose si complicano un po' ma niente di che... la cosa rimane FATTIBILE
banryu79
30-07-2009, 11:40
Eddai, basta fiammate, fa già caldo di suo :flower:
Frank1962
30-07-2009, 11:46
1)http://www.microsoft.com/express/vcsharp/
....da quì a essere un sito per i giochini dell'XBOX il passo e breve :D ....cmq è una Express Edition, limitata ....un pò come l'Oracle Express edition per i DBMS che quando vai a lavorarci scopri dei limiti veramente tediosi :muro:
astorcas
30-07-2009, 11:51
....da quì a essere un sito per i giochini dell'XBOX il passo e breve :D ....cmq è una Express Edition, limitata ....un pò come l'Oracle Express edition per i DBMS che quando vai a lavorarci scopri dei limiti veramente tediosi :muro:
E allora? Intanto con c# "normale" (scusa quelli speciali dove sono?) e con un software gratuito puoi andare di com interop e generare fogli excel.
Chiudo qua perché effettivamente fa caldo... :)
^TiGeRShArK^
30-07-2009, 12:01
per un Console.print anche forse ...se vuoi poter utilizzare le librerie, per esempio, per collegarti ad excel allora mi sà che c'è da pagare (Visual Studio or similari a meno di non ricorrere a soluzioni non standard/non microsoft)
Visual studio express edition è gratis dal 2005.
mi sa che neanche con la verisione "normale" di C# .....cioè, anche su Vista nel Task Manager dei processi c'è l'opzione "Tempo Reale" ma avrei qualche dubbio sulla sua reale affidabilità conoscendo di fama la Microsozzz :D
....poi quà mi sà che si stà facendo un pò di confusione tra linguaggio, librerie e implementazione!
Mai detto che il C# sia adatto per software real time.
Ma sei tu che hai detto:
all'infinitesimo posto metterei C,C++ e tutto l'accozzaglia di assembly solo per la retrocompatibilità con stè caffettiere di macchine hardware che ci ritroviamo a dover programmare (cellulari,palmari,tv,netbook,notebook,pc,ecc...) e che si ostinano a produrre ancora con delle isa antiquate e, ovviamente, proprietarie .....se un giorno si decidessero, per produrre l'hardware, di prendere il bytecode di Java come punti di riferimento e non la loro minchia non sarà mai troppo tardi!
E per operazioni real time non è assolutamente possibile con la versione normale di java.
Frank1962
30-07-2009, 12:03
Comunque quà stiamo andando un pò Off-Topic ...il fatto è che molti linguaggi sono stati creati per esigenza del tempo e del contesto in cui sono nati e, quindi, inevitabilmente risentono del contesto applicativo di cui fanno o facevano parte ....C per scrivere Sistemi Operativi, Fortran per i calcoli, Cobol per l'elaborazione dati, Php per fare siti + o - dinamici nell'era di internet, Scheme/OCaml e similari per RIportare in auge i linguaggi funzionali sepolti da una storia di frustrazioni accademiche di non poco conto ecc.. ecc.. pure Java alla fine era nato all'inizio, principalmente, con l'obbiettivo di essere portabile ...questa caratteristica è rimasta grossomodo inalterata ma con l'evoluzione dei tempi si è aggiunto a questo linguaggio anche la caratteristica di voler soddisfare le esigenze reali e concrete dei programmatori di mezzo mondo aprendosi alla comunità Open-Source che sicuramente darà una nuova prospettiva all'evoluzione di questo linguaggio verso qualcosa che serva a DESCRIVERE e non semplicemente a TRASCIVERE qualche cosa che già c'era prima ;)
Frank1962
30-07-2009, 12:12
E per operazioni real time non è assolutamente possibile con la versione normale di java.
per tutti i dispostivi che ho elencato il Real-Time è superfluo se non addirittura uno svantaggio ($$$$)
^TiGeRShArK^
30-07-2009, 12:26
per tutti i dispostivi che ho elencato il Real-Time è superfluo se non addirittura uno svantaggio ($$$$)
un pc con un GC sempre in azione non lo userei, soprattutto se consideriamo che può essere un server.
Frank1962
30-07-2009, 12:35
un pc con un GC sempre in azione non lo userei, soprattutto se consideriamo che può essere un server.
se ti vai a cercare su internet c'è qualche test prestazionale Java vs C e a quanto sembra le prestazioni, anche a livello server, tendono a essere le stesse con o senza GC
http://www.stefankrause.net/wp/?p=4
DanieleC88
30-07-2009, 12:37
Io direi che a nessuno importa (http://nonciclopedia.wikia.com/wiki/A_nessuno_importa).
se ti vai a cercare su internet c'è qualche test prestazionale Java vs C e a quanto sembra le prestazioni, anche a livello server, tendono a essere le stesse con o senza GC
http://www.stefankrause.net/wp/?p=4
Già, a nessuno importa.
Java come linguaggio in sè sarà anche veloce (un pò) ma il problema sono le sue librerie che tutti si sentono in dovere di usare ad ogni piè sospinto.
Cioè d'accordo, C è solo il 30% più veloce di java. Poi però per risolvere un problema uso un array in memoria, e qualche chiamata a funzione scritta da me.
Invece con Java per la stessa cosa creo una Lista dinamica su cui chiamo metodi virtuali, la duplico, ecc ecc.
Questo per dire che, Java è lento e poco reattivo perchè si tira dietro tonnellate di inutility/utility di alto livello che chiunque sente il bisogno di usare, e risolvere lo stesso problema complesso (non i soliti benchmark inutili) su Java spesso invoglia ad usare algoritmi più semplici e astratti ma anche dannatamente più pesanti.
cdimauro
30-07-2009, 13:15
Senza sistema operativo realtime è impossibile scrivere applicazioni realtime ;)
Windows non è realtime, quindi niente applicazioni VERAMENTE realtime.
http://msdn.microsoft.com/en-us/library/ms838340(WinEmbedded.5).aspx :cool:
Comunque se cerchi "Windows real time" trovi un sacco di roba. ;)
per il "Linaro Anti MS" ti dico semplicemente che se ci sono aziende e/o realtà che producono software Open-Source che mi permette di vedere che cosa fa un processo sulla mia macchina e che sono valide alternative a sistemi proprietari Closed-Source allora, bè sì, qualche astio verso Microsoft c'è l'ho
Non mi sembra che MS sia l'unica azienda ad avere puntato principalmente al progetti closed source. Il tuo astio è, quindi, egualmente riservato a qualunque azienda che opera in questo settore?
sopratutto dopo anni e anni che per comprare un portatile sono COSTRETTO AD ACQUISTARE UNA LICENZA WINDOWS nelle sue molteplici forme e versioni!
Questa è una leggenda metropolitana: puoi benissimo comprare portatili senza s.o. installato già da un po' di anni.
Eddai, basta fiammate, fa già caldo di suo :flower:
Parli tu che sei a Padova. :D
cmq è una Express Edition, limitata ....un pò come l'Oracle Express edition per i DBMS che quando vai a lavorarci scopri dei limiti veramente tediosi :muro:
Tipo? Quale limite avrei con VSEE? Io per questo http://code.google.com/p/wpython/ progetto mi sono trovato benissimo, e non ho sentito la mancanza di alcunché.
pure Java alla fine era nato all'inizio, principalmente, con l'obbiettivo di essere portabile ...questa caratteristica è rimasta grossomodo inalterata ma con l'evoluzione dei tempi si è aggiunto a questo linguaggio anche la caratteristica di voler soddisfare le esigenze reali e concrete dei programmatori di mezzo mondo aprendosi alla comunità Open-Source che sicuramente darà una nuova prospettiva all'evoluzione di questo linguaggio verso qualcosa che serva a DESCRIVERE e non semplicemente a TRASCIVERE qualche cosa che già c'era prima ;)
Questa non l'ho capita (e sono serio: non è una battuta né c'è del sarcasmo). Mi riferisco all'ultima parte ovviamente.
E poi vorrei capire quale sarebbe il valore aggiunto dell'open source in questo caso, a parte l'ovvia disponibilità di braccia a costo zero che possono lavorarci.
se ti vai a cercare su internet c'è qualche test prestazionale Java vs C e a quanto sembra le prestazioni, anche a livello server, tendono a essere le stesse con o senza GC
http://www.stefankrause.net/wp/?p=4
Sono test molto vecchi.
Qui http://shootout.alioth.debian.org/ trovi qualcosa di più aggiornato.
insane74
30-07-2009, 13:46
Qui http://shootout.alioth.debian.org/ trovi qualcosa di più aggiornato.
scusa l'ignoranza, ma questo (per esempio) http://shootout.alioth.debian.org/u32q/csharp.php come andrebbe interpretato?
se la barra è "sopra" è meglio o peggio? cioè il linguaggio in questione (c# su mono) è più veloce o meno del linguaggio di riferimento (java 6 server)?
mi fa "strano" perché da questo http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=csharp&lang2=python3&box=1 sembrerebbe che c# è molto + veloce di python??? o lo sto leggendo al contrario?
:fagiano: :stordita:
http://msdn.microsoft.com/en-us/library/ms838340(WinEmbedded.5).aspx :cool:
Comunque se cerchi "Windows real time" trovi un sacco di roba. ;)
Soluzione rabberciata ;)
Fin quando non si può mettere mano al kernel, il sistema non potrà mai essere veramente realtime, ma al massimo potrà simulare il funzionamento di un sistema realtime con uno scheduler esterno (come infatti avviene lì).
In sostanza quello è un thread con priorità realitme che si occupa di fare il dispatching dei thread allo scheduler del sistema operativo e di revocarli alla fine della deadline se non terminano da soli.
Infatti non ci mettono certo questa tecnologia nei sistemi real-time seri.
Ma davvero vorresti mettere il kernel di Windows XP nel sistema di controllo di una centrale nucleare ? :stordita: Seriamente...
Gli shuttle, i satelliti, le sonde etc etc sono basati per la maggior parte su un sistema operativo real-time chiamato QNX.
Spesso tra l'altro le potenze di elaborazione in gioco nei sistem real-time sono veramente esigue.
Poi ci sono vincoli di testabilità nei sistemi real-time mission critical. Di fatto è impossibile infilare software closed in questo genere di progetti.
^TiGeRShArK^
30-07-2009, 13:52
se ti vai a cercare su internet c'è qualche test prestazionale Java vs C e a quanto sembra le prestazioni, anche a livello server, tendono a essere le stesse con o senza GC
http://www.stefankrause.net/wp/?p=4
Non sto parlando di prestazioni, sto parlando di determinismo delle latenze che è essenziale in un kernel imho.
malocchio
30-07-2009, 15:09
http://msdn.microsoft.com/en-us/library/ms838340(WinEmbedded.5).aspx :cool:
Mi suona male leggere HARD real-time :read:, su kernel Windows... Addirittura Linux ha al massimo una patch per tentare di fare qualcosa, ma resta sempre SOFT real-time
Questa è una leggenda metropolitana: puoi benissimo comprare portatili senza s.o. installato già da un po' di anni.:mbe:
E poi vorrei capire quale sarebbe il valore aggiunto dell'open source in questo caso, a parte l'ovvia disponibilità di braccia a costo zero che possono lavorarci.Che si possono leggere comodamente i sorgenti delle librerie? :stordita:
Soluzione rabberciata ;)
Fin quando non si può mettere mano al kernel, il sistema non potrà mai essere veramente realtime, ma al massimo potrà simulare il funzionamento di un sistema realtime con uno scheduler esterno (come infatti avviene lì).
In sostanza quello è un thread con priorità realitme che si occupa di fare il dispatching dei thread allo scheduler del sistema operativo e di revocarli alla fine della deadline se non terminano da soli.
Infatti non ci mettono certo questa tecnologia nei sistemi real-time seri.
Ma davvero vorresti mettere il kernel di Windows XP nel sistema di controllo di una centrale nucleare ? :stordita: Seriamente...
Gli shuttle, i satelliti, le sonde etc etc sono basati per la maggior parte su un sistema operativo real-time chiamato QNX.
Spesso tra l'altro le potenze di elaborazione in gioco nei sistem real-time sono veramente esigue.
Poi ci sono vincoli di testabilità nei sistemi real-time mission critical. Di fatto è impossibile infilare software closed in questo genere di progetti.
Premesso che Windows non è nato per quello, QNX è basato su micro-kernel per cui ha come tutte le cose dei vantaggi e degli svantaggi.
Windows è un ibrido, mentre il kernel di Linux è monolitico.
I kernel monolitici in genere sono più veloci, e cmq neanche il kernel di Linux così com'è è real-time, tant'è che ci sono delle varianti.
IMHO cmq stiamo portando la dicussione verso altri lidi e non ha senso dare seguito a certi commenti privi di significato.
Premesso che Windows non è nato per quello, QNX è basato su micro-kernel per cui ha come tutte le cose dei vantaggi e degli svantaggi.
Windows è un ibrido, mentre il kernel di Linux è monolitico.
I kernel monolitici in genere sono più veloci, e cmq neanche il kernel di Linux così com'è è real-time, tant'è che ci sono delle varianti.
Chi ha nominato Linux ? :D
Kralizek
30-07-2009, 15:36
Che si possono leggere comodamente i sorgenti delle librerie? :stordita:
se fosse necessario leggere i sorgenti di una libreria per usarla, non la userei.
malocchio
30-07-2009, 15:39
se fosse necessario leggere i sorgenti di una libreria per usarla, non la userei.
Non è necessario, ma è una comodità.
Qualche volta mi è capitato di riuscire a carpire di più dal sorgente che dalla documentazione.
Vabbè nella pratica non è che mi cambi molto, ma la vedo più come una cosa positiva piuttosto che negativa.
se fosse necessario leggere i sorgenti di una libreria per usarla, non la userei.
Sei abituato bene! :D
banryu79
30-07-2009, 15:47
se fosse necessario leggere i sorgenti di una libreria per usarla, non la userei.
L'OpenSource portato alle estreme conseguenze: ti rilascio la libreria in versione beta, se scovi un bug... fixatelo, tanto sei un developer no? :D
Comunque da quando il esiste OpenJDK la possibilità di leggere alcuni sorgenti giusto solo per spirito di conoscenza/curiosità a me non dispiace (poi per carità arrivo sempre fino a un certo punto: quando ho risalito la catena di chiamate all'inseguimento di quello che penso sia interessantissimo leggere perchè voglio vedere come diavolo hanno fatto e arrivo alla chiamata a metodo native, alzo le mani e resto a bocca asciutta).
Per esempio ho trovato interessante la possibilità di leggere direttamente da sorgente (con i limiti di cui sopra) cosa succede quando invoco un Collections.sort() passando una collezione.
malocchio
30-07-2009, 15:48
Comunque da quando il esiste OpenJDK la possibilità di leggere alcuni sorgenti giusto solo per spirito di conoscenza/curiosità a me non dispiace (poi per carità arrivo sempre fino a un certo punto: quando ho risalito la catena di chiamate all'inseguimento di quello che penso sia interessantissimo leggere perchè voglio vedere come diavolo hanno fatto e arrivo alla chiamata a metodo native, alzo le mani e resto a bocca asciutta).
E' successo lo stesso a me un paio di volte. Una piccola delusione :D
Frank1962
30-07-2009, 15:53
Non sto parlando di prestazioni, sto parlando di determinismo delle latenze che è essenziale in un kernel imho.
rispondevo alla tua perplessità sull'uso di un applicativo server con il Thread GC in esecuzione ....pensavo fosse una problematica rivolta al problema prestazioni in generale e non al Real Time che, come si sa, è un caso molto particolare e di nicchia che necessità più che di un linguaggio specifico anche e sopratutto un hardware particolare e costoso ai più.
Frank1962
30-07-2009, 15:55
L'OpenSource portato alle estreme conseguenze: ti rilascio la libreria in versione beta, se scovi un bug... fixatelo, tanto sei un developer no? :D
Comunque da quando il esiste OpenJDK la possibilità di leggere alcuni sorgenti giusto solo per spirito di conoscenza/curiosità a me non dispiace (poi per carità arrivo sempre fino a un certo punto: quando ho risalito la catena di chiamate all'inseguimento di quello che penso sia interessantissimo leggere perchè voglio vedere come diavolo hanno fatto e arrivo alla chiamata a metodo native, alzo le mani e resto a bocca asciutta).
Per esempio ho trovato interessante la possibilità di leggere direttamente da sorgente (con i limiti di cui sopra) cosa succede quando invoco un Collections.sort() passando una collezione.
Nello specifico? che cosà ti ha lasciato a bocca asciutta?
malocchio
30-07-2009, 15:57
Ora io non ho esperienze con Java Server, ma non penso che il GC possa portare ad avere differenze sostanziali in termini di velocità... anche considerando che stiamo parlando di macchine dotate di parecchi core/cpu :mc:
L'OpenSource portato alle estreme conseguenze: ti rilascio la libreria in versione beta, se scovi un bug... fixatelo, tanto sei un developer no? :D
E se fosse closed la libreria buggata ? :D
malocchio
30-07-2009, 16:01
E se fosse closed la libreria buggata ? :D
Segnali e aspetti...
for (;;) System.out.println("Aspetti...");
:banned:
banryu79
30-07-2009, 16:20
Nello specifico? che cosà ti ha lasciato a bocca asciutta?
In che senso scusa?
Rimango a bocca asciutta quando nel sorgente java arrivo alla chiamata di un metodo native.
Il metodo native sta in una bella dll, se proprio ho voglia di andare a vedere.
Di solito non ho così tanta voglia; se ne avessi la neccessità ovviamente sarebbe tutto un altro paio di maniche.
E se fosse closed la libreria buggata ?
Cosa cambia?
Pensi che se scovo un bug nel JDK mi sfiora l'idea di mettermi lì di buzzo buono (come se ne avessi capacità e tempo) per trovare la soluzione all'inghippo? Ehi, io sono solo un povero user...
Al massimo faccio un salto nella bugparade per vedere se sono in buona compagnia: mal comune mezzo gaudio.
E poi mi metto a scovare un workaround per risolvere il mio problema.
Frank1962
30-07-2009, 16:28
In che senso scusa?
Rimango a bocca asciutta quando nel sorgente java arrivo alla chiamata di un metodo native.
Il metodo native sta in una bella dll, se proprio ho voglia di andare a vedere.
Di solito non ho così tanta voglia; se ne avessi la neccessità ovviamente sarebbe tutto un altro paio di maniche.
ah ok capito .....bè è normale, alla fine le JNI sono così...se invece di una dll avessi una lib allora lì si che potresti appoggiarti al source del kernel linux o della libreria specifica per vedere poi come funziona! ....la cosa interessante è che se anche tu andassi fino al punto dove il kernel utilizza l'assembly per soddisfare quella chiamata alla fine per andare ancor + a fondo dovresti studiarti la ISA del processore e, ancora andando più in giù, anche un pò di fisica della materia per capire i meccanismi che "muovono" l'elettronica che soddisfa la tua chiamata e, dopo tutta questa strada, arriveresti alla fatidica domanda: "ma tutto ciò, alla fine, che senso ha?" :D
cdimauro
30-07-2009, 16:55
Soluzione rabberciata ;)
Fin quando non si può mettere mano al kernel, il sistema non potrà mai essere veramente realtime, ma al massimo potrà simulare il funzionamento di un sistema realtime con uno scheduler esterno (come infatti avviene lì).
In sostanza quello è un thread con priorità realitme che si occupa di fare il dispatching dei thread allo scheduler del sistema operativo e di revocarli alla fine della deadline se non terminano da soli.
Infatti non ci mettono certo questa tecnologia nei sistemi real-time seri.
Ma davvero vorresti mettere il kernel di Windows XP nel sistema di controllo di una centrale nucleare ? :stordita: Seriamente...
Gli shuttle, i satelliti, le sonde etc etc sono basati per la maggior parte su un sistema operativo real-time chiamato QNX.
Spesso tra l'altro le potenze di elaborazione in gioco nei sistem real-time sono veramente esigue.
Poi ci sono vincoli di testabilità nei sistemi real-time mission critical. Di fatto è impossibile infilare software closed in questo genere di progetti.
Di Windows Embedded alcuni partner hanno a disposizione i sorgenti per creare delle proprie, particolari, customizzazioni. ;)
Mi suona male leggere HARD real-time :read:, su kernel Windows... Addirittura Linux ha al massimo una patch per tentare di fare qualcosa, ma resta sempre SOFT real-time
Si può fare di meglio. Vedi sopra.
:mbe:
E' più difficile, ma si trovano. :read:
Che si possono leggere comodamente i sorgenti delle librerie? :stordita:
Non è necessario, ma è una comodità.
Qualche volta mi è capitato di riuscire a carpire di più dal sorgente che dalla documentazione.
Vabbè nella pratica non è che mi cambi molto, ma la vedo più come una cosa positiva piuttosto che negativa.
Bisogna vedere come sono scritti i sorgenti e/o la documentazione (e qui c'è da ridere, visto che nei progetti open source scarseggia).
E se fosse closed la libreria buggata ? :D
La disassembli e vedi perché non funziona. :fagiano:
Closed != impossibile vedere cosa fa il codice. :cool:
cdimauro
30-07-2009, 17:02
scusa l'ignoranza, ma questo (per esempio) http://shootout.alioth.debian.org/u32q/csharp.php come andrebbe interpretato?
se la barra è "sopra" è meglio o peggio? cioè il linguaggio in questione (c# su mono) è più veloce o meno del linguaggio di riferimento (java 6 server)?
mi fa "strano" perché da questo http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=csharp&lang2=python3&box=1 sembrerebbe che c# è molto + veloce di python??? o lo sto leggendo al contrario?
:fagiano: :stordita:
Scusami, non m'ero accorto di questo tuo messaggio.
I dati rappresentano il rapporto fra i valore del primo linguaggio e quello del secondo.
Quindi se trovi scritto 1/3, vuol dire che il primo linguaggio ha impiegato 1/3 del tempo, oppure 1/3 della memoria, o ancora che il sorgente è 1/3 più piccolo rispetto al secondo.
In soldoni e per semplificare:
- frazione -> vantaggio del primo linguaggio;
- intero -> vantaggio del secondo linguaggio.
insane74
30-07-2009, 18:10
Scusami, non m'ero accorto di questo tuo messaggio.
I dati rappresentano il rapporto fra i valore del primo linguaggio e quello del secondo.
Quindi se trovi scritto 1/3, vuol dire che il primo linguaggio ha impiegato 1/3 del tempo, oppure 1/3 della memoria, o ancora che il sorgente è 1/3 più piccolo rispetto al secondo.
In soldoni e per semplificare:
- frazione -> vantaggio del primo linguaggio;
- intero -> vantaggio del secondo linguaggio.
ok, allora ho interpretato correttamente.
risulta quindi (con quei test) che c# su mono è in media 5 volte + lento del c++ e (sempre in media) 45,8 volte + veloce di python?
urca!
devo subito dirlo a tutto l'ufficio....
qua vendiamo un app sviluppata (da noi) principalmente in python a 40K€...
mi sa che dobbiamo migrare! :ciapet: :ciapet: :ciapet: :ciapet:
qua vendiamo un app sviluppata (da noi) principalmente in python a 40K€...
40K euro??! E che cazzo fa? Simula la Guerra Termonucleare Globale (cit.) e il Tic-Tac-Toe (cit., sempre la stessa) quando è in idle?
Mi suona male leggere HARD real-time :read:, su kernel Windows... Addirittura Linux ha al massimo una patch per tentare di fare qualcosa, ma resta sempre SOFT real-time
No, si puo' ottenere hard real-time anche in linux, ci sono tre implementazioni differenti (RTLinux, RTAI e Xenomai).
Tra l'altro l'approccio e' abbastanza simile a quello del link (architettura co-kernel).
insane74
30-07-2009, 18:28
40K euro??! E che cazzo fa? Simula la Guerra Termonucleare Globale (cit.) e il Tic-Tac-Toe (cit., sempre la stessa) quando è in idle?
beh... un'applicazione di cui siamo rivenditori costa 300.000€, fai un pò tu... :D
PS: non me la sto tirando, io sono l'ultima ruota del carro... :cry:
Soluzione rabberciata ;)
Fin quando non si può mettere mano al kernel, il sistema non potrà mai essere veramente realtime, ma al massimo potrà simulare il funzionamento di un sistema realtime con uno scheduler esterno (come infatti avviene lì).
Il poter mettere mano al kernel non e' necessario per il realtime, tanto che i piu' rilevanti sistemi operativi real-time (VxWorks, QNX) sono closed source.
Poi volendo si puo' richiedere anche il sorgente, ma quello si puo' fare anche con MS, e comunque si comincia ad andare su cifre a 4-5 zeri.
In sostanza quello è un thread con priorità realitme che si occupa di fare il dispatching dei thread allo scheduler del sistema operativo e di revocarli alla fine della deadline se non terminano da soli.
No piano, se anche nel caso di Windows l'approccio e' co-kernel, semplicemente il kernel di linux diventa un processo di bassa priorita' rispetto ai processi real-time, che riescono quindi a venire schedulati con la precisione richiesta. Il problema e' che ovviamente il processo real-time non puo' fare chiamate di sistema, e tutti i driver che usa devono essere scritti per funzionare in real-time.
Gli shuttle, i satelliti, le sonde etc etc sono basati per la maggior parte su un sistema operativo real-time chiamato QNX.
Mi risulta che QNX sia diffuso soprattutto nell'automotive, e che VxWorks sia piu' diffuso nell'aerospaziale, ma potrei sbagliarmi...
cdimauro
30-07-2009, 20:01
ok, allora ho interpretato correttamente.
risulta quindi (con quei test) che c# su mono è in media 5 volte + lento del c++ e (sempre in media) 45,8 volte + veloce di python?
urca!
devo subito dirlo a tutto l'ufficio....
qua vendiamo un app sviluppata (da noi) principalmente in python a 40K€...
mi sa che dobbiamo migrare! :ciapet: :ciapet: :ciapet: :ciapet:
Non vedo il perché: Python permette di sviluppare codice molto velocemente ed è facilmente manutenibile.
Se hai problemi di prestazioni puoi provare un moduletto, Psyco, che attiva un compilatore JIT x86, aumentando di molto le prestazioni.
Ecco qui (http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=python&lang2=psyco&box=1) il confronto con Python, e qui (http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=csharp&lang2=psyco&box=1) con C# (Mono).
Che ne dici? Notevole, eh? :cool:
insane74
30-07-2009, 20:10
Non vedo il perché: Python permette di sviluppare codice molto velocemente ed è facilmente manutenibile.
Se hai problemi di prestazioni puoi provare un moduletto, Psyco, che attiva un compilatore JIT x86, aumentando di molto le prestazioni.
Ecco qui (http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=python&lang2=psyco&box=1) il confronto con Python, e qui (http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=csharp&lang2=psyco&box=1) con C# (Mono).
Che ne dici? Notevole, eh? :cool:
alt, qui non volevo iniziare discorsi su facilità di sviluppo o meno, ma sui meri numeri che saltano fuori da quei bench, parlando di pure prestazioni di quei particolari esempi.
anche con psyco cmq salta fuori che nella maggior parte dei casi mono risulta più performante.
volevo solo "puntare il dito" sui meri numeri (un pò come nei bench delle schede video), non certo su "tutto il contorno". ;)
PS: io poi personalmente non mi trovo con python, ma certo non faccio il tifo per mono! semplicemente ultimamente mi sto divertendo con monodevelop, e fondamentalmente solo perché trovo eccezionale gnome-do! :fagiano:
cdimauro
30-07-2009, 20:30
Le prestazioni non sono tutto. Anzi, sono l'ultima cosa a cui pensare (soltanto nel caso in cui non risultano oggettivamente adeguate alla risoluzione del problema). ;)
insane74
30-07-2009, 20:36
Le prestazioni non sono tutto. Anzi, sono l'ultima cosa a cui pensare (soltanto nel caso in cui non risultano oggettivamente adeguate alla risoluzione del problema). ;)
sicuramente non sono tutto, però contano.
vai da un cliente, gli fai vedere un applicativo scritto in X, lo stesso in Y, dove X è più veloce fino a 45 volte di Y... secondo te al cliente frega qualcosa del linguaggio? della facilità di sviluppo? della mantenibilità del codice?
a noi programmatori si, a loro clienti no.
e visto che s'ha da guadagnare la pagnotta... :oink:
poi ovviamente se si trova il giusto compromesso, tanto di guadagnato! :sofico:
PS: ovviamente non ce l'ho con python/java/php/altro né sono un fan di c#/altro.
ribadisco, erano solo commenti su quei bench. :cincin:
PPS: e tra l'altro, molti risultati sono per me inattesi! :O
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.