Discussion :

[Franck.H]

Ha bon ? Le protocole TCP/IP c'est pas portable ? n'importe nawak

Je n'est nullement parlé des protocoles réseau mais des implémentations qui pour la plupart sont créées suivant le système d'exploitation !
La portabilité commence à venir tout doucement avec les sockets BSD mais ce n'est pas encore ca !

La Glib commence aussi à avoir des interfaces portables pour le réseau mais là encore une fois, c'est loin d'être fini ... d'ailleur si cela n'a pas bougé, ca ne fonctionne que sous Linux pour le moment

[Luc Hermitte]

En C++, on a des libs réseau portables comme ACE. C'est certes une usine à gaz, mais cela fait abstraction de quantités d'API système différentes de gestion des sockets.

Et cela fonctionne sur une grande quantité d'architectures différentes.
Il reste des petits détails toutes fois: p.ex. le pattern reactor (enveloppe autour de select()) est plus efficace sur *nix alors que sous windows c'est le pattern proactor, à cause du comment fonctionne ces systèmes.

[nyal]

ce qui est portable (ou non), ce sont les librairies et non le langage (syntaxe de base).

Ce point est intèresssant. Dommage que tu ne détailles pas ta pensée.
Ce qu'a dit Marc lussac est tout à fait juste. Que ce soit python, java, C/C++ c'est tout à fait portable MAIS toujours dans une certaine mesure.
En effet, les problèmes de portabilité surviennent sur ces points:
Intègration dans un OS (niveau système d'authentification, graphisme,...)
Développement de chose "pointu": Il suffit d'essayer d'utiliser une clé crypto, l'usb,...
La gestion des répertoires: Chose simple et pourtant y'a des soucis vu qu'il faut changer les chemins absolus
...

Bien sûr un langage est portable mais ce sont les bibliothèques autour qui le sont beaucoup moins. Si vous faites des choses "simples", ça sera portable. Après on n'a surement pas le même sens du mot portabilité. Est ce que la recompilation empêche un langage d'être considéré comme portable ? Ce serait bien d'identifier ce mot "portable" et expression "langage portable". (Où ? quoi ? Comment ?)

[aurelsty]

Sans conteste Python et wxPython!
Pour la bdd sqlite ou mysql, ou mieux postgres.

[Lunixinclar]

Le topic date d'il y a quoi, deux ans?... Mais question très intéressante!

Qu'est-ce que c'est comme logiciel exactement? Si c'est une application web, la question ne se pose même pas puisque chaque plateforme dispose d' au moins un navigateur web.
En revanche pour un applicatif local qui va puiser ses données dans une BDD, la question est entière.

Il existe une dizaine de bons systèmes de gestion de bases de données. Par bon, j'entend que les performances sont au rendez-vous, que c'est pas un cauchemard à administrer, et qu'une version existe sur au moins 3 plate-formes (win32/UN*X/MacOS).

Reste à savoir comment attaquer la base de données.


Java: comme indiqué plus haut, ce n'est pas la panacée. Trop de couches superposées, une certaine lourdeur à bien des égards.

.NET: c'est niet. Qui dit portabilité dit non M$FT.

C/C++ oui ils sont portables. C plus que C++ d' ailleurs. La majorité des grosses applications portables sont écrites en C, avec un exécutable qui cible la plateforme.
Exemples: Apache/Java/Perl/PHP, tous suivent ce paradigme (si si, PHP est écrit en C). Le C est universel, ce n'est pas une coincidence si les noyaux de windoze et linux sont écrits en C.
Mais ce n'est pas un langage de haut-niveau. En d' autres termes, il requiert une durée de développement plus longue, tout en garantissant la puissance.
C'est en tout cas mon choix personnel.

Perl: il peut à peu près tout faire, même des application graphiques. Pour peu qu'il utilise une Lib portée sur la plateforme cible.

PHPl: idem. Bon en Bases de données, mais pauvre en GUI.

TCL: idem, mais moins répandu. Difficile aussi d'appréhender un nouveau langage.

Python: la grande classe. Encore mieux que PHP ou Perl. En plus il est extensible avec des modules écrits en C/C++!

Gambas: super à tous égards. Vraiment. C'est un VB ultra-puissant en bytecode pré-compilé. Mais l'interpréteur ne tourne pas sous windows... Au fond c'est un langage d'avenir, très luicide.


La portabilité a toujours un prix.
Soit le programme est extrêmement bien intégré à sa plateforme, ce qui implique une multiplication du temps de développement, donc requiert un superman de la programmation -ou une équipe bien dirigée. Un code dédié autorise des langages que la portabilité rebute, tout en permettant la puissance du code natif.
...Soit il ne l'est pas, dans ce cas c'est son aspect même qui est discutable. Les fenêtres Java ont toutes l' air si... Java.

Mais, il n' y a pas que le langage ou l' OS à prendre en compte. Le type de processeur aussi...

[kedare]

Python : Langage de script de haut niveau de plus en plus connu , tres simple , et tres puissant
(Interpreté)
Ocaml : Langage Fonctionnel de haut niveau avec comme choix :
Utilisation comme script
Compilation Bytecode
Compilation Natif (Vitesse d'execution entre le C et le C++ , extremement rapide donc)
(fonctionne sur windows , linux , mac)

avec ces deux langages tu peut faire tout ce que tu veut
tu peut meme les combinner avec Pycaml si tu veut

[Luc Hermitte]

<pinaillage sur="de même ordre de grandeur">"entre"? Quelle drôle de formulation. Il n'y a pas de différence de perf entre le C et le C++. 99.99% des codes C compilent en C++ ce qui lui donne au moins les mêmes perfs. Après il y a des idiomes (/bibliothèques) du C++ plus rapides que ceux équivalents du C (-> les tris), d'autres plus lents si on désire les utiliser, c'est un choix. Et d'autres pas comparables (cf le soit disant coût des fonctions virtuelles).
NB: il y a un fil sur les perfs du C++ et un autre sur les différences entre C++ et C. Mon pinaillage, n'est qu'un extrait, un résumé.
</>

[elekis]

c'est marrant , j'ai toujours cru que le c++ etait plus lent que le c car en orienté objet, il y a le calcul des virtual (polymorphismes) qui se fait a l'execution, le this qui est aussi calculé a l'execution, etc...etc.. se sont de petite chose , certes, mais ce sont des choses quand meme.


a+++

[Lunixinclar]

On sort du topic.
Soit le programme simplissime suivant (le superlatif n'est pas outrancier) :

#include <iostream>
int main()
{
std::cout << "Hello world!" << std::endl;
return 0;
}

Compilé avec g++ -O4 -S 1.cpp ça donne un joli fichier 1.s.

Maintenant l' équivalent en C:
#include <stdio.h>

int main()
{
puts("Hello world!\n");
return 0;
}
Compilé avec gcc -O4 -S 1.c ça donne un autre fichier.

Juste quelques kilos de moins et quelques dizaines d'instructions assembleur en
moins. Que dire du moteur Half-Life de 30.000 lignes de code? Rapide, certes. Mais peut
mieux faire.

Tu m' étonnes que les applications critiques soient écrites en C.
Le C++ est génial, pour les programmeurs. Les classes sont puissantes pour
le développement. Quant aux temps de compilation, la portabilité, de taille des
exécutables, ce n'est pas ce qui se fait de mieux. Mais c'est plus rapide
du point de vue du temps de développement.

[Luc Hermitte]

<hs>
@Elekis. Plutôt que de refaire un copier-coller maladroit, je déterre une ancienne discussion sur le point précis du coût imaginaire de la virtualité.
http://www.developpez.net/forums/sho...9&page=1&pp=15
On pourra continuer les débats là bas vu que cela y est bien plus en thême.

Concernant le this, c'est exactement le même débat. Soit on a besoin d'un ensemble de données attachées à une aggréagation de données. Et donc on paye le coût équivalent au passage de cet argument supplémentaire. Qu'il soit implicite (C++, et autres langages supportant nativement le paradigme OO) ou explicite (comme en C). Si on n'a pas besoin de cet aggrégat, alors on ne le passe pas, même dans les langages qui supportent la POO. Il faut comparer ce qui est comparable. Ou plus précisément, il faut comparer les diverses solutions qui permettent de résoudre un même problème.
Autrement, cela n'a strictement aucun sens.


@Lunixinclar. Ton code C est également parfaitement valide en C++ -- on peut même le torturer avec des std:: pour qu'il ne compile plus en C, mais seulement en C++. C'est précisément ce que je disais à propos des choix possibles.
Si on utilise les flux C++, on paye en perfs pour les fonctionalités qu'ils nous apportent en plus par au rapport I/O C :
- typage fort (*)
- locales localisées à chaque flux
- filtrage à la volée des flux (pour p.ex ignorer, de façon transparente, les commentaires avant même d'extraire nos données utilisateur des flux)
- définitions "génériques" des sérializations pour n'importe quel type exact de flux (fichier, pipe, socket, buffer en mémoire, ...)
- résistance aux buffers overflow tout en permettant des extractions conviviales (En C, allez donc lire un ensemble de mots de longueurs inconnues)

(*) et encore, on aurait pu l'avoir en payant bien moins cher : http://msobczak.com/prog/fastreams/


Je n'ai fait que dire que le C++ offrait le choix et qu'il est au moins aussi rapide que le C. Si on veut payer pour des algos et des structures de données plus lentes, et bien on paye. Et c'est valable pour tous les langages.
</>

[FloMo]

C++ ( ou Python ) avec l'API QT4 : l'idéal pour du multi-plateformes.

Ca fonctionne sous Linux, Windows ( Vista compris ) et Mac avec le même code. C'est rapide à développer. C'est très performant. Il y a une bonne communauté derrière. C'est libre. ( dans la mesure où on développe du libre ) L'API est très complète.

En plus, il y a un designer pour réaliser les interfaces graphiques mais qui peut aussi utiliser Visual Studio ou bien Eclipse.

[viviboss]

Sans concession et aucun daute pour moi : Java...... Et c'est tout !!!

[Neuromancien2]

Delphi :
- portable grâce à Kylix sur linux, mais sur Mac, Mac OS X est un nux, comprend-il les progs compilés avec Kylix ?
- si l'exécutable fait 1 Mo ou 2 à tout casser c'est le grand maximum
- convivial (un utilisateur non habitués - le public ciblé par ce soft -) ne sera pas dépaysé, les applis ont bien le look windows.
- rapidité (au moins sous Windows), sous Kylix ?
- presque gratos (y'a toujours la pub pour la version 7 perso?), la 7 est compatible Kylix, pas le 6 je crois...

Il existe Lazarus, clone libre de Delphi, qui existe sous Windows, Linux et MacOS. Les programmes FreePascal/Lazarus sont totalement portables.

[Garulfo]

Sans concession et aucun daute pour moi : Java...... Et c'est tout !!!

Hélas, c'est loin d'être vrai -_-
Nous avons expérimenté plusieurs problème concernant des détails, mais parfois fortement dérangeante sur la gestion du clic-droit, ou le rafraichissement des fenêtres, ou la gestion des icônes etc. entre le même code sur Windows, Linux, SunOS et Mac... donc je ne suis pas convaincu.

[Garulfo]

[...]
Tu m' étonnes que les applications critiques soient écrites en C.[...]

Ça dépend ce que tu appelles critique. À ma connaissance, le critique est plutôt écrit en ADA vois-tu... que ce soit à Siemens, à la NASA, à Eurospace, au DOD etc. mais tu voulais peut-être dire les programmes devant être léger ?

[eclesia]

Hélas, c'est loin d'être vrai -_-
Nous avons expérimenté plusieurs problème concernant des détails, mais parfois fortement dérangeante sur la gestion du clic-droit, ou le rafraichissement des fenêtres, ou la gestion des icônes etc. entre le même code sur Windows, Linux, SunOS et Mac... donc je ne suis pas convaincu.

Se sont des soucis d'affichages, j'ai eu les memes. Ca se regle assez bien en utilisant l'EDT. pour les icones, chaque OS les gere a sa facon, ca depend du theme etc... je ne trouve pas ca bien genant. le clic droit je n'en sais rien,
je n'ai pas assez de retour des utilisateurs de mon logiciel sous mac.

Le code critique (entendez qui n'est pas l'affichage) marche sans soucis en tout cas.

[FloMo]

C++ avec Qt4, c'est l'idéal ! Code rapide à écrire, propre, hyper portable, performant. Pour ceux qui préfèrent Java ou Python, ces 2 langages sont aussi supportés.

[Garulfo]

Se sont des soucis d'affichages, j'ai eu les memes. Ca se regle assez bien en utilisant l'EDT. pour les icones, chaque OS les gere a sa facon, ca depend du theme etc... je ne trouve pas ca bien genant. le clic droit je n'en sais rien,
je n'ai pas assez de retour des utilisateurs de mon logiciel sous mac.

Le code critique (entendez qui n'est pas l'affichage) marche sans soucis en tout cas.

Amusant d'appeler ça critique ... le calcul, le modèle de donnée, etc. a rarement été le problème de la portabilité. Il est très aisé de faire du C++ portable si tu ne t'intéresses pas à l'aspect interaction avec l'humain. En général quasiment tous les langages interprétés ou semi-interprétés sont très portables si on ne considère que cet aspect. Et je dirais que ocaml ou python ont même dans ce cas un large plus face à Java. Je n'ai jamais vu de problème avec eux, j'ai vu des cas (exceptionnel certes) avec Java. Je pense cependant que ces cas auraient pû apparaître dans les autres langages puisque ce sont des features non spécifiées.

Pour notre cas particulier, c'est un cas particulier bien sûr Dans notre cas, tout le problème tourne principalement autour de l'affichage: le but étant d'automatiser les tâches du processus humain d'analyse/conception et d'y pluger un tuteur. Le tuteur procède par analyse de l'interface. Donc s'il y a des détails d'interfaces qui fonctionnent différemment le projet risque de se compliquer.