20/04/09 18:23
eddiewrc
Postato originariamente da gigisoft:
Per quanto riguarda il confronto C/C++ <--> Delphi:
1) Il delphi e' molto piu' ottimizzato in molte funzionalita' gestite nativamente mentre in C/C++ devono essere gestite manualmente ( stringhe, oggetti dinamici, ecc... );
Per quanto riguarda il confronto C/C++ <--> Delphi:
1) Il delphi e' molto piu' ottimizzato in molte funzionalita' gestite nativamente mentre in C/C++ devono essere gestite manualmente ( stringhe, oggetti dinamici, ecc... );
ehm.. il C è di sicuro + ottimizzato rispetto al dephi proprio PERCHè bisogna gestire manualmente praticamente tutto! delphi invece sarà più semplice, user-friendly .. ma non direi "ottimizzato". il NON dover gestire manualmente le cose è di sicuro molto comodo ma il 99% delle volte comporta una perdita di performance.
2) Se vuoi un interfaccia visuale in C++ devi usare dei tool apposta ( tipo il Dev ) ma la portabilita' inizia a venire meno;
non è questione di tool, è questione di librerie grafiche! come gtk
3) L'unico vantaggio ( forse ) del C rispetto al Delphi e' che permette di fare alcune cose a basso livello senza scomodare l'assembler, ma solo in una situazione cosi' particolare consiglierei il C rispetto al Delphi
un vantaggio che spesso fa la differenza!
aaa
21/04/09 8:57
gigisoft
Postato originariamente da eddiewrc:
Java per fare applicazioni distribuite PROPRIO NO!!!
programmi PORTABILI e DISTRIBUITI sono due cose completamente diverse... come la luna e lo yoghurt!
java è portabile...invece i programmi distribuiti sono quelli usati dai bridge per creare uno spanning tree o quelli dei router per gestire l'instradamento. NON gli applet
Java per fare applicazioni distribuite PROPRIO NO!!!
programmi PORTABILI e DISTRIBUITI sono due cose completamente diverse... come la luna e lo yoghurt!
java è portabile...invece i programmi distribuiti sono quelli usati dai bridge per creare uno spanning tree o quelli dei router per gestire l'instradamento. NON gli applet
E' ovvio che "portabili" e "distribuiti" sono due cose totalmente separate. Stavo solo indicando la tipologia di programmi per cui ( secondo me ) e' adatto il Java.
E comunque i programmi distribuiti sono quelli composti da componenti che lavorano su piu' macchine diverse connesse tra loro.
Ciao.
aaa
21/04/09 9:04
gigisoft
Postato originariamente da eddiewrc:
ehm.. il C è di sicuro + ottimizzato rispetto al dephi proprio PERCHè bisogna gestire manualmente praticamente tutto! delphi invece sarà più semplice, user-friendly .. ma non direi "ottimizzato". il NON dover gestire manualmente le cose è di sicuro molto comodo ma il 99% delle volte comporta una perdita di performance.
non è questione di tool, è questione di librerie grafiche! come gtk
un vantaggio che spesso fa la differenza!
Postato originariamente da gigisoft:
Per quanto riguarda il confronto C/C++ <--> Delphi:
1) Il delphi e' molto piu' ottimizzato in molte funzionalita' gestite nativamente mentre in C/C++ devono essere gestite manualmente ( stringhe, oggetti dinamici, ecc... );
Per quanto riguarda il confronto C/C++ <--> Delphi:
1) Il delphi e' molto piu' ottimizzato in molte funzionalita' gestite nativamente mentre in C/C++ devono essere gestite manualmente ( stringhe, oggetti dinamici, ecc... );
ehm.. il C è di sicuro + ottimizzato rispetto al dephi proprio PERCHè bisogna gestire manualmente praticamente tutto! delphi invece sarà più semplice, user-friendly .. ma non direi "ottimizzato". il NON dover gestire manualmente le cose è di sicuro molto comodo ma il 99% delle volte comporta una perdita di performance.
2) Se vuoi un interfaccia visuale in C++ devi usare dei tool apposta ( tipo il Dev ) ma la portabilita' inizia a venire meno;
non è questione di tool, è questione di librerie grafiche! come gtk
3) L'unico vantaggio ( forse ) del C rispetto al Delphi e' che permette di fare alcune cose a basso livello senza scomodare l'assembler, ma solo in una situazione cosi' particolare consiglierei il C rispetto al Delphi
un vantaggio che spesso fa la differenza!
Beh... ci sarebbe da discutere, non vorrei essere scortese ma:
1) Il fatto di dover gestire manualmente qualcosa, in genere, implica una maggior probabilita' di introdurre errori, che si eviterebbero con una gestione gia' esistente e testata
2) Tool o librerie grafiche il discorso non cambia, in genere e' preferibile concentrarsi sulla logica del programma senza dover perdere tempo a costruire un'interfaccia grafica da 0
3) E' vero e' un vantaggio, ma se non si deve scendere cosi' a basso livello non ne vale la pena ( ovviamente e' anche una questione di gusti ).
Ciao.
aaa
21/04/09 9:32
eddiewrc
che sia più difficile da gestire un approcio a basso livello e che quindi sia soggetto a bug è certamente vero... però un buon approcio a basso livello, SE fatto bene e SE funziona è decisamente più efficente della stessa cosa fatta tramite api.
un esempio è lo stack di rete.. spesso per fare applicazioni che devono rispettare parametri di affidabilità e realt time abbastanza rigidi, occorre riscriversi uno stack che sia più efficiente di quello fornito dal so.
poi per comodità è ovvio che ogni volta che è possibile non si sta a rifare quello che è già stato fatto!! non dimentichiamoci però che anche le librerie che ci forniscono delle utilissime api a volte sono buggate..
ciao!
un esempio è lo stack di rete.. spesso per fare applicazioni che devono rispettare parametri di affidabilità e realt time abbastanza rigidi, occorre riscriversi uno stack che sia più efficiente di quello fornito dal so.
poi per comodità è ovvio che ogni volta che è possibile non si sta a rifare quello che è già stato fatto!! non dimentichiamoci però che anche le librerie che ci forniscono delle utilissime api a volte sono buggate..
ciao!
aaa