Discussion :

[deaven]

Bonjour,

J'étudie présentement pour une évaluation à venir; je voudrais connaître les avantages de chacun de ces languages : C VS PHP VS JAVA.
Je parle des avantages du point de vu réseau bien sûr (Interface avec connection aux bases de données).

Selon moi les avantages du PHP c'est son coût qui est nul et sa facilité de s'intégrer aux pages HTML.

En C l'avantage c'est la portabilité entre systèmes Linux et Windows.

Pour ce qui est du JAVA je ne vois pas vraiment d'avantage.

Merci pour votre aide à ma réflexion

[Médinoc]

Le java est beaucoup plus portable que le C, puisqu'il marche partout où il y a une JVM.
Après pour les performances, les gens sont divisés... Deux écoles s'affrontent, disant que l'un est plus performant que l'autre...

[millie]

Le java est beaucoup plus portable que le C, puisqu'il marche partout où il y a une JVM.
Après pour les performances, les gens sont divisés... Deux écoles s'affrontent, disant que l'un est plus performant que l'autre...

En fait, si on utilise les sockets en C comme un barbare (c'est à dire en utilisant uniquement des appels du type : send, recv qui font directement appel à des appels systèmes), ça va forcement être ralenti (surtout si c'est pour lire 2 caractères à chaque fois)

En Java, on couple les sockets avec des BufferedInput/OutputStream en général pour bufferiser les entrées (on lit par exemple 5000 caractères d'un coup et au prochain read on lit directement dans le buffer) et les sorties. Ceci de manière totalement transparente.

Pour le réseau en C classique (sous UNIX avec les sys/socket.h etc. et sous Windows avec les win2sock), il faut en général recoder une couche au dessus pour imiter ce type de fonctionnalités.


Après, le reste a déjà été dit.

[gorgonite]

Le java est beaucoup plus portable que le C, puisqu'il marche partout où il y a une JVM.

C/C++ sont beaucoup plus portables que le Java... puisqu'en codant proprement et en utilisant un compilateur respectueux des normes, on pourra compiler vers bien plus de plate-formes, et donc faire fonctionner son programme là où on attendrait encore une JVM

morale de l'histoire :
il aurait mieux valu utiliser "Java permet une portabilité sans recompilation", et non "Java est plus portable que le C (ou le C++)"

En fait, si on utilise les sockets en C comme un barbare (c'est à dire en utilisant uniquement des appels du type : send, recv qui font directement appel à des appels systèmes), ça va forcement être ralenti (surtout si c'est pour lire 2 caractères à chaque fois)

En Java, on couple les sockets avec des BufferedInput/OutputStream en général pour bufferiser les entrées (on lit par exemple 5000 caractères d'un coup et au prochain read on lit directement dans le buffer) et les sorties. Ceci de manière totalement transparente.

Pour le réseau en C classique (sous UNIX avec les sys/socket.h etc. et sous Windows avec les win2sock), il faut en général recoder une couche au dessus pour imiter ce type de fonctionnalités.

pas vraiment d'accord.
sans avoir à se reconstruire une bib, passer par des FILE* pour les accès aux sockets permet d'éviter ce problème... pourquoi toujours partir sur l'hypothèse que les langages bas niveau oblige systématiquement à tout reconstruire

[snake264]

C/C++ sont beaucoup plus portables que le Java... puisqu'en codant proprement et en utilisant un compilateur respectueux des normes, on pourra compiler vers bien plus de plate-formes, et donc faire fonctionner son programme là où on attendrait encore une JVM

Le problème est là, il existe trop de compilateur C et C++ et dont certains ne sont pas entièrement aux normes, alors que le Java lui peut importe le compilateur que tu utilise ça marchera et en plus tu le compile une fois et c'est tout ce qui est un énorme avantage Et puis cela demande plus de temps au développeur de faire un code entièrement portable en C que en Java. Voir les sockets par exemple comme l'a si bien dit millie.

morale de l'histoire :
il aurait mieux valu utiliser "Java permet une portabilité sans recompilation", et non "Java est plus portable que le C (ou le C++)"

Oui et non je suis un peu mitigé sur ce point de vue car pour moi Java est tout ce qu'il y a de portable, le C aussi mais il est soumis à trop de condition.

sans avoir à se reconstruire une bib, passer par des FILE* pour les accès aux sockets permet d'éviter ce problème... pourquoi toujours partir sur l'hypothèse que les langages bas niveau oblige systématiquement à tout reconstruire

Entièrement d'accord, même si il est vrai que le C a été inventé pour justement tout reconstruire car à la base c'étais pour faire un système d'exploitation.

[gege2061]

Le problème est là, il existe trop de compilateur C et C++ et dont certains ne sont pas entièrement aux normes,

Si tu prends les plus populaires il n'y a pas de soucis, en C++ il peut y avoir des différences mais si tu y es confronté c'est déjà que tu sais ce que tu fais.

alors que le Java lui peut importe le compilateur que tu utilise ça marchera

Mais bien sûr... T'as déjà essayé gcj ?

[snake264]

Si tu prends les plus populaires il n'y a pas de soucis, en C++ il peut y avoir des différences mais si tu y es confronté c'est déjà que tu sais ce que tu fais.

Je suis bien d'accord mais ce que je voulais dire c'est que surtout en C si tu veux utiliser la norme C99 avec gcc tu aura bien du mal car cette norme est encore très loin d'y être entièrement incorporée.

Mais bien sûr... T'as déjà essayé gcj ?

A non je n'est jamais essayé. En quoi pose t-il problème ?

[millie]

pas vraiment d'accord.
sans avoir à se reconstruire une bib, passer par des FILE* pour les accès aux sockets permet d'éviter ce problème... pourquoi toujours partir sur l'hypothèse que les langages bas niveau oblige systématiquement à tout reconstruire

Ca marche FILE* avec les SOCKET de windows ?

[gorgonite]

Ca marche FILE* avec les SOCKET de windows ?

sans doute... un HANDLE n'est pas si différent d'un descripteur de fichier completé

un exemple :
http://web.mit.edu/Source/third/perl/win32/win32sck.c

[millie]

sans doute... un HANDLE n'est pas si différent d'un descripteur de fichier completé

un exemple :
http://web.mit.edu/Source/third/perl/win32/win32sck.c

Effectivement, on dirait qu'on peut Donc même en utilisant un FILE*, il faut recoder un truc pour simplifier l'utilisation des sockets

[Nasky]

Pour le réseau, je dirais que le C n'est pas le meilleur choix. Java est (beaucoup) plus simple dans ce domaine.
Quant à la portabilité, elle n'est pas si significative en C concernant les sockets.
Bref, le Java est le meilleur choix à mon avis. Le PHP pourquoi pas... tout dépend du projet exact que tu souhaites réaliser.

Nas'

[deaven]

Le java est beaucoup plus portable que le C

Humm vraiment ?? Je comprend pas, le c peut s'éxecuter sans aucune machine virtuelle donc c'est beaucoup plus portable que JAVA non ?

[Pouic]

Le java est beaucoup plus portable que le C

Humm vraiment ?? Je comprend pas, le c peut s'éxecuter sans aucune machine virtuelle donc c'est beaucoup plus portable que JAVA non ?

Oui, si tu recompiles.... Mais du Java, ça ne se compile pas

[Médinoc]

De plus, seul le C standard peut être qualifié de portable... Et encore... (voir fonction system())...

[Nasky]

Le point de vue du forum C sera forcément biaisé..

Pourtant, on a prouvé le contraire dans ce post. Personne n'a défendu le C

Nas'

[reggae]

.Net c'est pas mal non plus il parraît... Par contre on a besoin d'une machine virtuelle

[Emmanuel Delahaye]

Le point de vue du forum C sera forcément biaisé..

Pourtant, on a prouvé le contraire dans ce post. Personne n'a défendu le C

A l'évidence, la question du réseau dépend du système, pas du langage. Aucun langage n'a de gestion de réseau integrée. Certains ont des sur-couches plus ou moins faciles à utiliser. Ca existe aussi en C. Simplement, c'est une bibliothèque tierce commme un des sous-ensembles de GTK+, par exemple...

Il y en a d'autres, et si ça manque, on peut le faire facilement...

[jowo]

Quand tu parles de réseau, de quelle couche (transport, réeseau, liasion physique) parles-tu?

Parce que java en standard n'a des facilités que pour que la couche transport. Si tu as besoin des couches plus profondes (réseau --> physique), je te conseillerais d'utiliser C.

[trattos]

D'un point de vue réseau je ferai intervenir Perl aussi!

[Jedai]

Tout à fait, mais tout dépend de ce que tu entends par "application réseau"... Parce que la présence de PHP me donne à penser que tu ne t'intéresse qu'aux applications qui utilisent HTTP, alors que C n'est absolument pas intéressant dans ce cas. Maintenant si on parle d'une architecture client-serveur classique, PHP est un choix moins intéressant (qui ne concerne qu'une partie de l'implémentation), C devient viable (bien que probablement pas des plus facile à prendre en main dans ce cas), Java devient le leader du marché malgré sa lourdeur et Perl est une alternative très crédible (que je favoriserais au moins pour tous les développements légers à moyens, le Java étant peut-être à privilégier au-delà).

--
Jedaï