C chat

[Fenomeno85]

gente sto cercando un modo per creare una chat ... il problema è che in vb so gestire il tutto ma la voglio fare in c.

Allora per connessione client -> server non c'è problema ... li ho già fatti e, come prova ho mandato un mex al client ... e qui tutto bene. Ma come si gestisce il tutto della chat??

~§~ Sempre E Solo Lei ~§~

[tglman]

le chat possono essere in diversi modi..

1)un server dove si collegano tutti e dove ognuno può scrivere ciò che vuole...
2)server irc, cioè una chat con diversi canali ed in caso anche la comunicazione diretta tra gli utenti.
3) stile massanger dove un utente può comunicare solo con chi conosce.

Ciao!!!

[Fenomeno85]

per adesso voglio solo realizzare una cosa spuzzissima tipo messenger

~§~ Sempre E Solo Lei ~§~

[tglman]

Cioè due utenti che sapendo il loro indirizzo si collegano l'uno a l'altro e possono inviarsi testo,

be questo è semplice il programma deve mettere una porta in listen poi deve aprire una connessione con un'altro a quel punto ogni cosa che è scritta in un riquadro di testo viene spedita sulle connessioni aperte e tutto quello che viene ricevuto dalle connessioni viene scritto in un riquadro di testo (edit)

Ariciao..

[Fenomeno85]

si questo lo so ... il problema è gestire gli eventi ... cioè in vb si sa quando arrivano in un determinato istante dati anche se si sta facendo altro ... qui come si fa?

~§~ Sempre E Solo Lei ~§~

[tglman]

In c puoi usare due metodi uno utilizzare i socket non bloccanti e eseguire ripetutamente recv e l'altro è usare ioctlsocket.

pregi difetti:
i socket bloccanti anno il pregio di ritornare(recv lascia il controllo al programma) solo quando ricevono i dati quindi non devi stare continuamente a ciclare ma se non ci sono i dati ti può bloccare
e per risolvere questro problema usi ioctlsocket.

i socket non bloccanti appunto non ti bloccano il programma ma ti ritonano un errore che tu poi devi andar controllare se è un errore perche non ci sono i dati o perche si è disconnesso il socket

[VICIUS]

Programmazione client/server di rete, proprio quello che sto studiando ora in uni :D

Secondo me la soluzione migliore è creare un server concorrente (processo principale in ascolto che accetta connesioni e i figli che gestiscono la comunicazione con i client). per sapere quando c'è qualcosa su uno o piu socket puoi usare la select che pero non so se esiste su windows.

ciao ;)

[tglman]

Si questo il metodo che si usa con i grandi server( io sto costruendo un web server ed uso questo metodo). ma se devi fare un piccolo messangerino tra due computer non ti conviene usare questo metodo, troppo grande per un messangerino,

per la select su windows dorebbe esistere ma comunque sulle cose grandi ogni connessione la fai gestire ad un figlio che la chiude anche, e per le cose piccole te la puoi benissimo cavare con in'interrogazione a ciclo (cosa molto simile alla select)

Ciao!!!

[71104]

su Windows la select esiste, ma non conviene usarla perché non si integra bene; guardati in MSDN l'uso della WSAAsyncSelect ;)
ciao

[71104]

ah, oppure usa MFC che semplifica tutto ;)
ariciao

[tglman]

Attento pero se vuoi rendere il codice portabile su diverse tecnologie non ti conviene utilizare funzioni onlywindows come WSAAsyncSelect...

Ciao...

[71104]

se la fa in C la portabilità è un'utopia; se la vuole fare portabile la deve fare in Java ;)

[Fenomeno85]

abbandono per adesso dato che non ho + tempo per realizzarla :)

~§~ Sempre E Solo Lei ~§~

[h1jack3r]

Fenomeno sai per caso dove posso trovare un codice per una chat da implementare in un programma Visual studio.NET in visual basic.NET?

[Fenomeno85]

no non ho mai cercato cmq penso che se fai una ricerca qualcosa trovi ;)

~§~ Sempre E Solo Lei ~§~

[RaouL_BennetH]

Originariamente inviato da 71104
se la fa in C la portabilità è un'utopia; se la vuole fare portabile la deve fare in Java ;)

Posso chiederti perchè?

Credevo che il C, come il C++ (e mi riferisco agli standard, non i Visual, Borland etcetera) fossero tra i codici più portabili (a patto di pensarli in maniera portabile e includere le direttive necessarie).

Scusa se la domanda ti sembrerà scema, ma ho iniziato da poco e ho le idee ancora assai confuse.

Thx.

RaouL.

[Futuregames]

Originariamente inviato da RaouL_BennetH
Posso chiederti perchè?

Credevo che il C, come il C++ (e mi riferisco agli standard, non i Visual, Borland etcetera) fossero tra i codici più portabili (a patto di pensarli in maniera portabile e includere le direttive necessarie).

Scusa se la domanda ti sembrerà scema, ma ho iniziato da poco e ho le idee ancora assai confuse.

Thx.

RaouL.


si vero ma dopo quando si inizia a parlare di interfaccia grafica la cosa si complica...:(

[end.is.forever]

In C la portabilità è un'utopia se cominci a scrivere le cose nei dettagli implementativi.
Se progetti il software in maniera ragionata e tutt'altro che difficile isolare le parti platform-dependent e fare qualche direttiva per la compilazione su diversi ambienti.

Comunque il meglio della portabilità la ottieni con delle librerie come wxWindows (http://www.wxwindows.org/)

[71104]

Originariamente inviato da RaouL_BennetH
Posso chiederti perchè?

Credevo che il C, come il C++ (e mi riferisco agli standard, non i Visual, Borland etcetera) fossero tra i codici più portabili (a patto di pensarli in maniera portabile e includere le direttive necessarie).

Scusa se la domanda ti sembrerà scema, ma ho iniziato da poco e ho le idee ancora assai confuse.

Thx.

RaouL.
come ripeto spesso, attualmente le soluzioni più portabili e contemporaneamente potenti sono Java e .NET; il C/C++ non è portabile, perché le STL non includono numerosi aspetti della programmazione; ad esempio non includono di default librerie per il networking, una gestione un attimino più avanzata di processi/threads e come ti è stato già detto non includono nemmeno delle librerie per ottenere una GUI. la scelta di non includere tutte queste cose è voluta: un generico SO non è obbligato ad implementare di default tutte queste cose, pensa ad esempio al DOS: il DOS non ha la GUI e non essendo multitasking ne' multithreading non può gestire nemmeno processi e thread; eppure un programma totalmente ANSI C che usa solo librerie predefinite deve pur girare sul DOS, no?

[VICIUS]

Originariamente inviato da 71104
come ripeto spesso, attualmente le soluzioni più portabili e contemporaneamente potenti sono Java e .NET; il C/C++ non è portabile, perché le STL non includono numerosi aspetti della programmazione; ad esempio non includono di default librerie per il networking, una gestione un attimino più avanzata di processi/threads e come ti è stato già detto non includono nemmeno delle librerie per ottenere una GUI. la scelta di non includere tutte queste cose è voluta: un generico SO non è obbligato ad implementare di default tutte queste cose, pensa ad esempio al DOS: il DOS non ha la GUI e non essendo multitasking ne' multithreading non può gestire nemmeno processi e thread; eppure un programma totalmente ANSI C che usa solo librerie predefinite deve pur girare sul DOS, no?

Non vedo come java e .net siano piu portabili di C/C++. :confused:
Nessuno obbliga il programmatore C++ ad usare STL e se questa libreria è incompleta basta semplicemente appoggiarsi su altro.

ciao ;)

[71104]

Originariamente inviato da VICIUS
Non vedo come java e .net siano piu portabili di C/C++. :confused:
Nessuno obbliga il programmatore C++ ad usare STL e se questa libreria è incompleta basta semplicemente appoggiarsi su altro.

ciao ;)
ehm... forse dovremmo prima intenderci sul concetto di portabilità...

[VICIUS]

Originariamente inviato da 71104
ehm... forse dovremmo prima intenderci sul concetto di portabilità...
Per portabile _io_ intendo codice che è possibile trasportare da una architettura hardware/sistema opertivo ad un'altro con una discreta facilità e poche modifiche. E con poche modifiche intendo qualche if qua e la.

ciao ;)

[anx721]

Originariamente inviato da VICIUS
Non vedo come java e .net siano piu portabili di C/C++. :confused:
Nessuno obbliga il programmatore C++ ad usare STL e se questa libreria è incompleta basta semplicemente appoggiarsi su altro.

ciao ;)


e proprio quell'"altro" che spesso rompe la protabilità, perche una libreria esterna spesso la trovi per un sistema e non per un altro.

per java la portabilità deriva dal fatto che ad eseguire i programmi non è il sistema stesso ma una macchina virtuale che rende così i programmi indipendenti dalla piattaforma sottostante. Sono le diverse implementazioni della macchina virtuale a realizzare la portabilità.

[71104]

Originariamente inviato da VICIUS
Per portabile _io_ intendo codice che è possibile trasportare da una architettura hardware/sistema opertivo ad un'altro con una discreta facilità e poche modifiche. E con poche modifiche intendo qualche if qua e la.
ecco appunto: io invece intendo codice che è possibile trasportare da una architettura hardware/sistema opertivo ad un'altro senza NESSUNA modifica, come nel caso del Java e del .NET, che non devono nemmeno essere ricompilati. ;)

[VICIUS]

Originariamente inviato da anx721
e proprio quell'"altro" che spesso rompe la protabilità, perche una libreria esterna spesso la trovi per un sistema e non per un altro.
Se tra i requisiti del progetto c'è la portabilità tra piu sistemi e si scelgono librerie non portabili, allora è solo colpa di chi ha fatto certe scelte non di certo del linguaggio di programmazione.

Originariamente inviato da anx721
per java la portabilità deriva dal fatto che ad eseguire i programmi non è il sistema stesso ma una macchina virtuale che rende così i programmi indipendenti dalla piattaforma sottostante. Sono le diverse implementazioni della macchina virtuale a realizzare la portabilità.
Allo stesso modo la portabilità del C/C++ esiste vunque esiste una versione della libreria. Secondo la mia esperienza è molto piu facile riscriversi una piccola libreria per portarla su una nuova piattaforma che implementare una intera java virtual machine.

ciao ;)

[VICIUS]

Originariamente inviato da 71104
ecco appunto: io invece intendo codice che è possibile trasportare da una architettura hardware/sistema opertivo ad un'altro senza NESSUNA modifica, come nel caso del Java e del .NET, che non devono nemmeno essere ricompilati. ;)
compile once, run everywher ? :D

E' carina come idea ma il codice compialto va comunque testato su tutte le varie piattaforme come con programmi c. Sperare che tutto funzioni perfettamente e nella stessa maniera su sistemi operativi diversi che magari hanno implementazioni della jvm diverse è un utopia.

ciao ;)

[anx721]

Vicius java nasce con l'obiettivo primario della portabilità, e in questo non è paragonabile al c++, è ovvio che prendendo tutti gli accorgimenti anche del codice c++ può essere portabile, ma non è sempre cosi semplice; già igli stessi compilatori c++ si differenziano tra quelli che supportano questo e quelli che non lo supportano, tra quelli che offrono questo e quelli che non lo offrono e non sempre la tal libreria multipaittaforma è quella meglio si adatta alla tua applicazione.

[71104]

Originariamente inviato da VICIUS
compile once, run everywher ? :D

sei rimasto indietro vecchio mio, quella cretinata è vecchia quanto il cucco, aggiornati ;)
se visiti una pagina web contenente un applet con windows o se la visiti con linux non cambia nulla, l'applet lo vedi uguale; questo è quello che intendo io con "portabilità". ;)

[RaouL_BennetH]

grazie a tutti per le risposte ma leggendole, mi è venuto un altro dubbio. Un codice portabile quindi, seguendo il "senso" che deve funzionare ovunque senza nessuna modifica, funzionerà alla stessa maniera ovunque oppure potrà essere migliore su una piattaforma piuttosto che su un'altra?

[VICIUS]

Originariamente inviato da 71104
sei rimasto indietro vecchio mio, quella cretinata è vecchia quanto il cucco, aggiornati ;)
se visiti una pagina web contenente un applet con windows o se la visiti con linux non cambia nulla, l'applet lo vedi uguale; questo è quello che intendo io con "portabilità". ;)
Quale sarebbe la cretinata il "compile once, run everywhere" o quello dopo ? :confused:

In ogni caso prendere come esempio una applet come programma portabile non mi sembra molto serio. Personalmente non li considero neanche programmi. Io stavo pensando a qualcosa di piu complesso di un giochino del triss o una simulazione di biliardo.

ciao ;)

[VICIUS]

Originariamente inviato da anx721
Vicius java nasce con l'obiettivo primario della portabilità, e in questo non è paragonabile al c++, è ovvio che prendendo tutti gli accorgimenti anche del codice c++ può essere portabile, ma non è sempre cosi semplice; già igli stessi compilatori c++ si differenziano tra quelli che supportano questo e quelli che non lo supportano, tra quelli che offrono questo e quelli che non lo offrono e non sempre la tal libreria multipaittaforma è quella meglio si adatta alla tua applicazione.
E' vero java nasce con quello scopo ed infatti ha una libreria inmensa che copre praticamente tutto. Ma questo non fa di certo java la soluzione a tutti i mali. Prova a scrivere qualcosa che debba interagire con il sistema operativo o tipo un server sonoro e vedrai che i problemi incominciano a comparire anche in java.

Ho avuto delle esperienze limitate con entrambi i linguaggi e per quello che ho visto un programma scritto da un buon programmatore di c++ è portabile quanto un scritto da un buon programmatore in java.

ciao ;)

[Futuregames]

scusa ma dove vedi che il .net è portabile!!! winzozz e basta... allora nn è portabilita:rolleyes:

java concordo ma .net no

[anx721]

Originariamente inviato da VICIUS
E' vero java nasce con quello scopo ed infatti ha una libreria inmensa che copre praticamente tutto. Ma questo non fa di certo java la soluzione a tutti i mali. Prova a scrivere qualcosa che debba interagire con il sistema operativo o tipo un server sonoro e vedrai che i problemi incominciano a comparire anche in java.
;)

ma infatti non ho detto che java è il linguaggio perfetto, ognuno ha le sue peculiarità, la portabilità è sicuramente più dallaa parte di java che non di c++

[VICIUS]

Originariamente inviato da Futuregames
scusa ma dove vedi che il .net è portabile!!! winzozz e basta... allora nn è portabilita:rolleyes:

java concordo ma .net no
.NET funziona anche su sistemi unix dove gira mono. Non ancora al 100% della compatibilità pero funziona.

ciao ;)

[mpattera]

io l'ho fatta in vb con mswinsock, tipologia client/server con anche p2p tra utenti per inviare e ricevere flussi video catturati da webcam.

in c penso sarebbe stato un massacro :cry:

[Futuregames]

Originariamente inviato da VICIUS
.NET funziona anche su sistemi unix dove gira mono. Non ancora al 100% della compatibilità pero funziona.

ciao ;)


si ma ora come ora un po poco... allora il discorso si può fare pure con tutti i linguaggi in questo modo

[Poix81]

ma java non e' un linguaggio interpretato?
questo vorrebbe dire che c/c++ e java non posso essere paragonati a livello prestazionale.

ciao ciao

[tglman]

Il java è un po strano come sistema quando tu scrivi il codice lo compili e estrai una specie di eseguibile (il .class) che puoi viene interpretato dalla virtual machine
quindi io non so come definirlo, perchè come linguaggio è compilato, ma la sua esecuzione avviene interpretando l'eseguibile e non proprio eseguendolo.

Infatti se fate caso a come si esegue un programma java, si dice alla virtual machine qual'è il file da eseguire e lei lo legge byte a byte e esegue le operazioni descritte dal programma.

In quanto alla costruzione di una chat in c l'unico problema risale alla costruzione delle interfacce di comunicazione con i dispositivi tipo web cam (se si vule uno stram video) altrimenti la gestione della comunicazione e più potente (a mio parere),di altri linguaggi tipo vb, e anche la gestione dell'applicazione in generale e più completa e performante.

e NON dimentichiamoci che il vb ha delle strutture non necessarie per la comunicazione che aiutano soltanto il programmatore e che quindi sono inutili (ha mio parere la macchina si deve piegare all'utente, e il programmatore si deve piegare alla macchina).

Ciao

[71104]

Originariamente inviato da VICIUS
Quale sarebbe la cretinata il "compile once, run everywhere" o quello dopo ? :confused:

In ogni caso prendere come esempio una applet come programma portabile non mi sembra molto serio. Personalmente non li considero neanche programmi. Io stavo pensando a qualcosa di piu complesso di un giochino del triss o una simulazione di biliardo.

ciao ;)
la cretinata era "compile once, run everywhere", e gli applet non devono necessariamente essere giochini del tris, possono anche essere di una certa complessità: sono veri e propri programmi Java integrati nel web; esistono ad esempio molti siti di banche che usano degli applet nelle loro pagine per numerosi scopi, e si tratta di applet piuttosto complessi. (e tra parentesi anche la simulazione del biliardo se la fai 3D è abbastanza complessa, sa'!)

[71104]

Originariamente inviato da RaouL_BennetH
grazie a tutti per le risposte ma leggendole, mi è venuto un altro dubbio. Un codice portabile quindi, seguendo il "senso" che deve funzionare ovunque senza nessuna modifica, funzionerà alla stessa maniera ovunque oppure potrà essere migliore su una piattaforma piuttosto che su un'altra?
se il codice è portabile vuol dire sicuramente che non è codice macchina, ma è qualcosa di concettualmente analogo al CLR di .NET, e quindi deve prima essere compilato "just in time" e poi eseguito da una qualche virtual machine, come la JVM o il framework .NET, o Mono; se il codice funziona meglio su una piattaforma che su un'altra, questo dipende solo dal modo in cui è implementata la virtual machine, ma in genere le prestazioni sono praticamente identiche su tutte le piattaforme.

[71104]

E' vero java nasce con quello scopo ed infatti ha una libreria inmensa che copre praticamente tutto. Ma questo non fa di certo java la soluzione a tutti i mali. Prova a scrivere qualcosa che debba interagire con il sistema operativo o tipo un server sonoro e vedrai che i problemi incominciano a comparire anche in java.

un programma che deve fare cose simile non potrà mai essere portabile, è chiaro che se deve interagire col SO deve avere un comportamento diverso per ogni piattaforma.


Ho avuto delle esperienze limitate con entrambi i linguaggi e per quello che ho visto un programma scritto da un buon programmatore di c++ è portabile quanto un scritto da un buon programmatore in java.

scusa, ma non credo proprio... il programma C lo devi quantomeno ricompilare, no?

[71104]

Originariamente inviato da Futuregames
scusa ma dove vedi che il .net è portabile!!! winzozz e basta... allora nn è portabilita:rolleyes:

java concordo ma .net no
mai sentito parlare di Mono? :rolleyes:
non è ancora completamente pronto che io sappia, ma è già molto.

[VICIUS]

Originariamente inviato da 71104
un programma che deve fare cose simile non potrà mai essere portabile, è chiaro che se deve interagire col SO deve avere un comportamento diverso per ogni piattaforma.
Tutti i programmi di questa terra devono interagire con il sistema operativo altrimenti non fanno assolutamente niente. Anche la sola apertura di un file o la creazione di thread o di socket passa comunque dal sistema operativo. Semplicemente nel caso di un server sonoro i progettisti java non hanno pensato di creare una librerira che gestisse l'accesso ai diversi sistemi in modo uniforme. Quindi in questo caso Java è portabile quanto un C++ senza librerie.

Originariamente inviato da 71104
scusa, ma non credo proprio... il programma C lo devi quantomeno ricompilare, no?
E' davvero cosi importante non dover ricompilare ? Fa veramente risparmiare dei soldi ?
Io quando scrivo un programma impiego il 20% del tempo a scrivere il codice vero e proprio sulla tastiera e il restante a trovare e corregger bug. Il tempo che usato per compialre anche 300 o 400 file .c non è neanche paragonabile al resto.

ciao ;)

[Futuregames]

Originariamente inviato da 71104
mai sentito parlare di Mono? :rolleyes:
non è ancora completamente pronto che io sappia, ma è già molto.


già molto... si vedra con mono 2.0 ad aprile/maggio cmq per ora .net nn è portabile più di tanto

[tglman]

Sono d'accordo con VICUS e molto semplice ricompilare un programma e questo si può fare anche con procedure di installazione (stile windows) che invece di copiare solo file eseguibili li compila anche, questo porterebbe ad una maggiore velocità del programma durante l'uso che è molto più utile anche se il tempo di installazione è maggiore,
cioè si preferisce avere un programma magari gia pronto eseguibile ma molto lento o un programma da installare ma dopo installato molto più veloce.... (io preferisco la seconda )

Ciao..

[71104]

Tutti i programmi di questa terra devono interagire con il sistema operativo altrimenti non fanno assolutamente niente.

quindi per te un programma Java non fa assolutamente niente!


Anche la sola apertura di un file o la creazione di thread o di socket passa comunque dal sistema operativo. Semplicemente nel caso di un server sonoro i progettisti java non hanno pensato di creare una librerira che gestisse l'accesso ai diversi sistemi in modo uniforme. Quindi in questo caso Java è portabile quanto un C++ senza librerie.

guarda che che io sappia in Java esistono anche delle librerie per sintetizzare suoni o mandarli in playback! non so cosa intendi per "server" sonoro... se col termine "server" ti riferisci alla terminologia caratteristica dei microkernel, be'... vorresti farmi un esempio di server sonoro portabile? e ne esiste anche una versione in C++??? Il java è portabile dove può esserlo! un server sonoro (se ho capito cosa intendi) funziona in kernel mode, come fa ad essere portabile, in Java o in C++ che sia?


E' davvero cosi importante non dover ricompilare ? Fa veramente risparmiare dei soldi ?

ad un utente normale si: se il programma è only-for-Windows ed è a pagamento (situazione tutt'altro che rara) e l'utente compra solo la versione per Windows (sempre che ne esistano versioni per altre piattaforme) poi non ha la possibilità di usarlo su un'altra piattaforma; invece un programma Java un utente lo può usare dove gli pare senza ricompilare e soprattutto senza sapere minimamente programmare; ancora una volta ribadisco che questo è quello che io chiamo portabilità.
poi può anche darsi che l'autore del programma abbia fornito anche delle versioni per altre piattaforme, Linux, Mac, ecc. ma questa non è portabilità: questo è un tipo di supporto che l'autore fornisce (sempre che lo fornisca) in aiuto ai poveri utenti finali che non hanno la minima idea di cosa sia la compilazione di un codice, utenti che non hanno il codice sorgente, e che spesso anche avendolo, anche sapendo cosa vuol dire compilare, e anche avendo un compilatore, NON POSSONO RICOMPILARLO, perché il codice stesso non è portabile (hai idea di quanti siano i programmi che usano windows.h? pensi che windows.h esista anche su Linux?)
spero che con questo tu ti sia convinto, perché è totalmente assurdo affermare che il C++ è più portabile del Java, e unanimemente accettato che il Java nasce con l'obiettivo primario della portabilità! (dove l'avevo già sentita questa? :p)


Io quando scrivo un programma impiego il 20% del tempo a scrivere il codice vero e proprio sulla tastiera e il restante a trovare e corregger bug. Il tempo che usato per compialre anche 300 o 400 file .c non è neanche paragonabile al resto.

il "resto" di cui sopra non è neanche paragonabile al tempo che impiegherebbe un utente finale ad imparare a programmare in C++, ad imparare cos'è un compilatore, ed infine ANCHE a ricompilare... ;)

[71104]

Originariamente inviato da tglman
Sono d'accordo con VICUS e molto semplice ricompilare un programma e questo si può fare anche con procedure di installazione (stile windows) che invece di copiare solo file eseguibili li compila anche, questo porterebbe ad una maggiore velocità del programma durante l'uso che è molto più utile anche se il tempo di installazione è maggiore,
cioè si preferisce avere un programma magari gia pronto eseguibile ma molto lento o un programma da installare ma dopo installato molto più veloce.... (io preferisco la seconda )

potete pensare e preferire quello che vi pare, ma non potete confutare ciò che è unanimemente accettato: o potete anche farlo, ma non ci crede nessuno! se tu preferisci un programma veloce ad uno lento (sempre che si possa parlare di "lentezza" coi processori d'oggi, che sfondano facilmente i 3 gigahertz) allora ok, avrai un programma veloce, ma non c'entra nulla con la portabilità, perché se tu sei un utente finale il "programma" per te non è il sorgente da cui è stato generato l'eseguibile finale, per il "programma" per te è solo l'eseguibile, e se ti si chiede di farlo girare su un'altra piattaforma tu non hai la minima idea di come fare, anzi probabilmente rispondi: "non si può, su Mac non gira, su Linux neanche, evidentemente NON E' PORTABILE!!!"
e se invece tu, utente finale che non hai la minima idea di come si possa creare un programma, hai a disposizione un programma Java e ti si chiede di farlo girare su altre piattaforme, tu rispondi: "ma funzionerà? io non sono tanto sicuro, proviamo... lo copio su floppy, ecco qua, lo ricopio su Linux, ok, che faccio lo avvio? vabbuo', ma secondo me non funzionerà, dovremo cercarne una versione per Linux... ODDIO... NON CI POSSO CREDERE! FUNZIONA!!! YUHUUU! ma allora ERA PORTABILE!"
capittt???

[71104]

dimenticavo, tglman: la portabilità esiste perché a volte (anche abbastanza spesso a dir la verità) ci sono situazioni in cui la portabilità dev'essere un obiettivo primario, ed è preferibile alla velocità (è esattamente il caso degli applet, che non servono solo a scopi ludici, ma anche per cose molto importanti); inoltre secondo me il Java non è così lento come dici, perché da quanto ne so non è interpretato: il codice dei files .class viene letto all'avvio dalla VM e compilato just-in-time (infatti un programma Java ce mette na vita ad avviarsi, ma una volta avviato procede normalmente).

[VICIUS]

Originariamente inviato da 71104
quindi per te un programma Java non fa assolutamente niente!

Un programma java fa esattamente quello che c'è scritto nel suo codice sorgente. Se faccio un System.out.println ("Hello World"); quello che alla fine viene eseguito dalla cpu è piu o meno questo pezzo di codice che non fa altro che invocare una system call (la write su stdout nel mio caso).

[SECTION .DATA]
x db "Hello World",10,0
[SECTION .TEXT]
global _start
_start:
mov eax,4
mov ebx,1
mov ecx,x
mov edx,12
int 80h
mov eax,1
mov ebx,0
int 80h

Originariamente inviato da 71104
guarda che che io sappia in Java esistono anche delle librerie per sintetizzare suoni o mandarli in playback! non so cosa intendi per "server" sonoro... se col termine "server" ti riferisci alla terminologia caratteristica dei microkernel, be'... vorresti farmi un esempio di server sonoro portabile? e ne esiste anche una versione in C++??? Il java è portabile dove può esserlo! un server sonoro (se ho capito cosa intendi) funziona in kernel mode, come fa ad essere portabile, in Java o in C++ che sia?

Non ci siamo capiti ed in effetti avrei dovuto elaborare un po di piu. Volevo semplicemente prendere come esempio un applicazione come winamp, itunes o xmms che ha la necessità di "suonare" qualcosa. Senza una libreria che disaccoppi il funzionamento del programma dal sistema sonoro sottostante l'applicazione non sara mai portabile. Ma questo avviene per tutti i linguaggi che conosco. L'ultima volta che guardai Java non aveva niente di simile quindi in questo caso Java risultava anche meno portabile del C visto che per questo linguaggio avevo trovato una libreria.

Tutto questo per evidenziare che l'estrema portabilità di Java è nella maggior parte dovuta alla immensa libreria fornita a corredo. Se il supporto di questa libreria viene a mancare semplicemente il livello di portabilità di Java è quanto quella di C++. E' che quindi secondo me non si puo affermare che il linguaggio java è piu portabile del C++.

Originariamente inviato da 71104
ad un utente normale si: se il programma è only-for-Windows ed è a pagamento (situazione tutt'altro che rara) e l'utente compra solo la versione per Windows (sempre che ne esistano versioni per altre piattaforme) poi non ha la possibilità di usarlo su un'altra piattaforma; invece un programma Java un utente lo può usare dove gli pare senza ricompilare e soprattutto senza sapere minimamente programmare; ancora una volta ribadisco che questo è quello che io chiamo portabilità.
poi può anche darsi che l'autore del programma abbia fornito anche delle versioni per altre piattaforme, Linux, Mac, ecc. ma questa non è portabilità: questo è un tipo di supporto che l'autore fornisce (sempre che lo fornisca) in aiuto ai poveri utenti finali che non hanno la minima idea di cosa sia la compilazione di un codice, utenti che non hanno il codice sorgente, e che spesso anche avendolo, anche sapendo cosa vuol dire compilare, e anche avendo un compilatore, NON POSSONO RICOMPILARLO, perché il codice stesso non è portabile (hai idea di quanti siano i programmi che usano windows.h? pensi che windows.h esista anche su Linux?)
spero che con questo tu ti sia convinto, perché è totalmente assurdo affermare che il C++ è più portabile del Java, e unanimemente accettato che il Java nasce con l'obiettivo primario della portabilità! (dove l'avevo già sentita questa? :p)


il "resto" di cui sopra non è neanche paragonabile al tempo che impiegherebbe un utente finale ad imparare a programmare in C++, ad imparare cos'è un compilatore, ed infine ANCHE a ricompilare... ;)

Anche qui avrei dovuto porre la domanda in maniera piu chiara. Mi stavo chiedendo se il non dover ricompilare facesse risparmiare concretamente dei soldi durante lo sviluppo del software alla casa produttrice. Anche non dovendo ricompilare la fase di testing sui vari sistemi va comunque effettuata e su questo spero non ci siano dubbi. L'unico vantaggio che vedo nel non dover ricompilare un programma è nella fase di distribuzione dello stesso dove si possono abbattere veramente i costi visto che non si hanno varie versioni.

Programmi che dipendono massicciamente da windows.h sono semplicemente pensati male. Se avessero usato toolkit grafici e non dipendenti dal sistema operativo il programma risulterebbe portabile quindi in questo caso la colpa è del programmatore incapace o semplicemente la portabilità non era nei requisiti del programma.

Non o ben capito perchè hai coinvolto gli utenti finali e per quale assurdo motivo dovrebbero prendere in mano un editor modificare un programma e compilarselo. Ma probabilmente è dovuto al fatto che avevo posto male la domanda. :confused:

ciao ;)

[VICIUS]

Originariamente inviato da 71104
potete pensare e preferire quello che vi pare, ma non potete confutare ciò che è unanimemente accettato: o potete anche farlo, ma non ci crede nessuno!
In genere non accetto le cose solo perchè qualcuno mi dice che è cosi. Preferisco vedere le cose come stanno con i miei occhi e pensare con la mia testa. Quello che è unanimaente accettato non è sempre vero, vedi galileo/copernico e colombo ma qui sto andando OT :D

Originariamente inviato da 71104
se tu preferisci un programma veloce ad uno lento (sempre che si possa parlare di "lentezza" coi processori d'oggi, che sfondano facilmente i 3 gigahertz) allora ok, avrai un programma veloce,
La ricerca di buone prestazioni non mi sembra tanto strana. Assumere che tutti abbiano a disposizione precessori sopra i 3 Ghz è un po azzardato. Ed anche supponendo che tutti siano in possesso di una grande potenza di calcolo perchè sprecarla?

Originariamente inviato da 71104
ma non c'entra nulla con la portabilità, perché se tu sei un utente finale il "programma" per te non è il sorgente da cui è stato generato l'eseguibile finale, per il "programma" per te è solo l'eseguibile, e se ti si chiede di farlo girare su un'altra piattaforma tu non hai la minima idea di come fare, anzi probabilmente rispondi: "non si può, su Mac non gira, su Linux neanche, evidentemente NON E' PORTABILE!!!"
e se invece tu, utente finale che non hai la minima idea di come si possa creare un programma, hai a disposizione un programma Java e ti si chiede di farlo girare su altre piattaforme, tu rispondi: "ma funzionerà? io non sono tanto sicuro, proviamo... lo copio su floppy, ecco qua, lo ricopio su Linux, ok, che faccio lo avvio? vabbuo', ma secondo me non funzionerà, dovremo cercarne una versione per Linux... ODDIO... NON CI POSSO CREDERE! FUNZIONA!!! YUHUUU! ma allora ERA PORTABILE!"
capittt???
floppy ? nell'era dei masterizzatori e di internet :D ?

Come hai gia detto per l'utente finale il programma è solo codice sorgente è qualcosa che va eseguito, deve fare quello per cui è scritto e poi terminare. Perchè l'utente dovrebbe interessarsi anche minimamente di come viene realizzato.

Se vuole il programma su X prende la versione per X se lo vuole su windows prende la versione per i sistemi microsoft e cosi via. Giusto per fare un esempio di programma scritto con criterio in C++ basta citare Opera. Funziona indifferentemente su una grande varietà di sistemi operativi e persino su vari dispositivi portatili come cellulari di ultime generazione. Non si tratta forse di un programma portabile ?

ciao ;)

[VICIUS]

Originariamente inviato da 71104
inoltre secondo me il Java non è così lento come dici, perché da quanto ne so non è interpretato: il codice dei files .class viene letto all'avvio dalla VM e compilato just-in-time (infatti un programma Java ce mette na vita ad avviarsi, ma una volta avviato procede normalmente).
Saro sfortunato io ma fino ad ora sono incappato solo in programmi Java di due tipi. Delle semplici applet, carine veloci, leggere ma con poca utilità. E veri e propri mastodonti che riescono a risucchiare ram come dei buchi neri e un interfaccia grafica poco reattiva che dopo un poco incomincia a dare sui nervi.

ciao ;)

[71104]

Un programma java fa esattamente quello che c'è scritto nel suo codice sorgente.

quindi qualcosa fa...


Non ci siamo capiti ed in effetti avrei dovuto elaborare un po di piu. Volevo semplicemente prendere come esempio un applicazione come winamp, itunes o xmms che ha la necessità di "suonare" qualcosa. Senza una libreria che disaccoppi il funzionamento del programma dal sistema sonoro sottostante l'applicazione non sara mai portabile. Ma questo avviene per tutti i linguaggi che conosco. L'ultima volta che guardai Java non aveva niente di simile quindi in questo caso Java risultava anche meno portabile del C visto che per questo linguaggio avevo trovato una libreria.

l'ultima volta che l'ho visto io il Java delle librerie per il suono ce le aveva, e cmq considera che (sempre stando a quanto ne so io) l'sdk di Microsoft per il Java include le DirectX, quindi di conseguenza anche le DirectSound, solo che non credo ci siano molti utenti che installano la JVM di Ms su Linux :D quindi questa parentesi è ininfluente :p
IMHO E' POSSIBILE creare un media player in Java, e con tanto di skin!!! (e un media player io non lo chiamo "server sonoro"...)


Tutto questo per evidenziare che l'estrema portabilità di Java è nella maggior parte dovuta alla immensa libreria fornita a corredo. Se il supporto di questa libreria viene a mancare semplicemente il livello di portabilità di Java è quanto quella di C++. E' che quindi secondo me non si puo affermare che il linguaggio java è piu portabile del C++.

il Java senza le sue librerie NON E' Java, perché sono librerie native (cercane l'implementazione: non la troverai! sono tutte classi dichiarate come native); allo stesso modo in genere il C++ viene considerato assieme alle sue librerie, senza le quali non è C++, ma una cosa molto simile ma pur sempre differente.
puoi anche dirmi che il Java è molto semplice come linguaggio, meno evoluto, meno potente, ma fermo rimane che:
1) è portabile nativamente, quindi molto di più del C++
2) è relativamente potente, nel senso che come potenza il C e C++ non si battono, ma il Java è il più potente (IMHO) tra le soluzioni portabili ("portabili" come intendo io, non come lo intendi tu...)


Anche qui avrei dovuto porre la domanda in maniera piu chiara. Mi stavo chiedendo se il non dover ricompilare facesse risparmiare concretamente dei soldi durante lo sviluppo del software alla casa produttrice. Anche non dovendo ricompilare la fase di testing sui vari sistemi va comunque effettuata e su questo spero non ci siano dubbi. L'unico vantaggio che vedo nel non dover ricompilare un programma è nella fase di distribuzione dello stesso dove si possono abbattere veramente i costi visto che non si hanno varie versioni.

ma infatti è ovvio che dev'essere l'azienda casomai a ricompilare, non l'utente che non sa manco che vuol dire ricompilare; le mie erano ipotesi per assurdo.
la fase di testing va effettuata su tutte le piattaforme supportate, certo, ma il testing che fai col programma C++ è estremamente diverso da quello Java: il programma C++ lo devi ricompilare per tutte le piattaforme ad ogni magagna che trovi, mentre quello Java nel 99.999% dei casi lo esegui e funziona subito dappertutto... (ti prego di non contraddirmi, magari non sarà il 99.999, ma è cmq sicuramente una percentuale di casi estremamente elevata, quasi massima)
però dall'ultima affermazione di questa quotatura vedo che finalmente inizi ad intendere il concetto di portabilità... ;)
pensa sempre all'esempio che ti ho fatto prima, quello dell'utente che ha un programma C++ e dell'utente che ha un programma Java...


Programmi che dipendono massicciamente da windows.h sono semplicemente pensati male. Se avessero usato toolkit grafici e non dipendenti dal sistema operativo il programma risulterebbe portabile quindi in questo caso la colpa è del programmatore incapace o semplicemente la portabilità non era nei requisiti del programma.

se un programma dipende massicciamente da windows.h non vuol dire che sia pensato male; evidentemente vuol dire che al programmatore non interessa la portabilità, no?


Non o ben capito perchè hai coinvolto gli utenti finali e per quale assurdo motivo dovrebbero prendere in mano un editor modificare un programma e compilarselo. Ma probabilmente è dovuto al fatto che avevo posto male la domanda. :confused:

li ho coinvolti perché il discorso è questo: mettiamo che un programmatore deve creare un programma e vuole che sia portabile; se lo fa in C++ (che NON E' un linguaggio portabile) deve faticare almeno un minimo per renderlo portabile e fare in modo che l'utente ne abbia sia una versione per Windows, che una per Linux, ecc. (le quali versioni saranno PROGRAMMI DIFFERENTI GENERATI DALLO STESSO SORGENTE!!! quindi in realtà non possiamo nemmeno affermare che IL programma è portabile, perché non è uno solo, sono due NON PORTABILI...)
se invece il programmatore scrive direttamente in Java, che è un linguaggio portabile, non si deve lui stesso preoccupare della portabilità, dovrà semplicemente scrivere il suo codice e compilarlo una volta sola e senza condizionali per ottenere risultati tangibili su qualsiasi piattaforma che abbia una JVM, e così l'utente è felice: esiste UNA SOLA versione del programma, che possiamo definire come "portabile", ed è in grado di girare su qualsiasi piattaforma.

[Poix81]

li ho coinvolti perché il discorso è questo: mettiamo che un programmatore deve creare un programma e vuole che sia portabile; se lo fa in C++ (che NON E' un linguaggio portabile) deve faticare almeno un minimo per renderlo portabile e fare in modo che l'utente ne abbia sia una versione per Windows, che una per Linux, ecc. (le quali versioni saranno PROGRAMMI DIFFERENTI GENERATI DALLO STESSO SORGENTE!!! quindi in realtà non possiamo nemmeno affermare che IL programma è portabile, perché non è uno solo, sono due NON PORTABILI...)
se invece il programmatore scrive direttamente in Java, che è un linguaggio portabile, non si deve lui stesso preoccupare della portabilità, dovrà semplicemente scrivere il suo codice e compilarlo una volta sola e senza condizionali per ottenere risultati tangibili su qualsiasi piattaforma che abbia una JVM, e così l'utente è felice: esiste UNA SOLA versione del programma, che possiamo definire come "portabile", ed è in grado di girare su qualsiasi piattaforma.

non credo propio che per compatibilita' di intenda questo.

[71104]

In genere non accetto le cose solo perchè qualcuno mi dice che è cosi. Preferisco vedere le cose come stanno con i miei occhi e pensare con la mia testa. Quello che è unanimaente accettato non è sempre vero, vedi galileo/copernico e colombo ma qui sto andando OT :D

colombo cmq non aveva ragione... :D
e poi quello che dici vale quando non esistono prove tangibili dell'affermazione, ma in una scienza come l'informatica vuoi che non esistano prove tangibili? se vuoi vedere se un programma è portabile o no basta che lo fai girare su piattaforme diverse, però non mi venire a citare Opera, FireFox, ecc. perché non li possiamo esattamente definire "portabili", ma casomai "portati": sono programmi di cui esistono numerose versioni, una per ogni piattaforma.
un programma Java invece è uno solo per tutte.


La ricerca di buone prestazioni non mi sembra tanto strana. Assumere che tutti abbiano a disposizione precessori sopra i 3 Ghz è un po azzardato. Ed anche supponendo che tutti siano in possesso di una grande potenza di calcolo perchè sprecarla?

non si assume niente e non si spreca niente: "the right tool for the right job"; se per te è importante che il programma sia portabile più che veloce lo fai in Java (sempre che, ripeto, si possa dubitare della velocità del Java sui processori odierni...), e se invece è il viceversa lo fai in C++


floppy ? nell'era dei masterizzatori e di internet :D ?

se a casa tua hai due macchine, una windows e una linux, e devi passare un prog più piccolo di 1.44 mega da una all'altra, che fai, lo uppi su un server e lo riscarichi sull'altra macchina??? :D :rotfl:


Come hai gia detto per l'utente finale il programma è solo codice sorgente è qualcosa che va eseguito, deve fare quello per cui è scritto e poi terminare. Perchè l'utente dovrebbe interessarsi anche minimamente di come viene realizzato.

questa frase non l'ho capita bene, mi sa che ci mancava qualche "non"... :confused:


Se vuole il programma su X prende la versione per X se lo vuole su windows prende la versione per i sistemi microsoft e cosi via. Giusto per fare un esempio di programma scritto con criterio in C++ basta citare Opera. Funziona indifferentemente su una grande varietà di sistemi operativi e persino su vari dispositivi portatili come cellulari di ultime generazione. Non si tratta forse di un programma portabile ?

appunto: se vuole il programma per X prende quello per X, se lo vuole per Win32 prende quello per Win32... ma non sono mica lo stesso programma portabile, sono programmi diversi generati dallo stesso sorgente "portato a mano" sulle diverse piattaforme; Opera è "portabile" (anche se non è esatto definirlo così) perché ce l'hanno portato con una marea di compilazioni condizionali... o cmq con una sostanziosa parte di codice da compilare condizionalmente.

[VICIUS]

Originariamente inviato da 71104
[...] ("portabili" come intendo io, non come lo intendi tu...) [...]

Penso che questa frase risolva definitivamente la discussione. Da quello che ho capito fino ad ora quindi per te un programma si scrive una volta e si compila una volta e il risultato deve andare su ogni sistema e macchina nello stesso modo. È una concezzione di portabilità un po estremista che personalmente non condivido. Visto che abbiamo due concetti di portabilità diversi e nessuno dei due sembra cedere alle obbiezioni dell'altro è meglio fermarsi qui finche la discussione è ancora civile.

ciao :)

[71104]

Originariamente inviato da VICIUS
Penso che questa frase risolva definitivamente la discussione. Da quello che ho capito fino ad ora quindi per te un programma si scrive una volta e si compila una volta e il risultato deve andare su ogni sistema e macchina nello stesso modo. È una concezzione di portabilità un po estremista che personalmente non condivido. Visto che abbiamo due concetti di portabilità diversi e nessuno dei due sembra cedere alle obbiezioni dell'altro è meglio fermarsi qui finche la discussione è ancora civile.
hai ragione, me so stufato pure io :D
comunque io credo che tutto il resto del mondo intenda la portabilità come la intendo io, è una concezione che non ho certo inventato io, però... STOP! ;)
cya'