Je vais aussi vous faire part de mon opinion, ayant programmé sous les deux systèmes.
Il y a effectivement des trucs assez chiants sous linux, du style ouvrir une socket ou récupérer la taille d'un fichier avec les appels C standards (bien qu'on puisse toujours utiliser une surcouche de bibliothèques) et c'est énervant de se dire qu'en 2004 on se tape encore une api préhistorique... malheuresement il n'y a aucun nouveau standard en vue pour améliorer cet état des choses bien que certaines bibliothèques comme la glib soient assez courantes pour pouvoir les utiliser.
Sous windows (plus précisement avec les MFC) même si le code est plus concis et faire une application simple prend moins de temps, je trouve l'api particulièrement crad. Le code généré par le wizard est absolument incompréhensible, les fichiers sources regorgent de macros qu'on est censé modifier que par l'interface graphique, les appels peuvent être contraire à la philo du c++ (par ex: pour transformer le curseur souris en sablier, on instancie juste en local une variable d'un type particulier. Le constructeur change le curseur, et le destructeur exécuté automatiquement à la fin de la fonction le restaure : c'est peut être rapide, mais c'est surtout affreusement crad). Le résultat est que pour une application conséquente, le code devient un véritable bordel et il est particulièrement difficile de comprendre ce qui s'y passe pour pouvoir le debug'er...
En gros je dirais que sous windows c'est plutôt pratique, et sous unix/linux c'est plus carré
Par contre concernant le support, y a pas photo... entre les forums sur le net basés sur l'entraide entre dév et une hotline où il faut filer son num de CB, le choix est vite fait...
[^] # Re: API de programmation système et Linux : et si ?
Posté par calandoa . En réponse au journal API de programmation système et Linux : et si . Évalué à 3.
Il y a effectivement des trucs assez chiants sous linux, du style ouvrir une socket ou récupérer la taille d'un fichier avec les appels C standards (bien qu'on puisse toujours utiliser une surcouche de bibliothèques) et c'est énervant de se dire qu'en 2004 on se tape encore une api préhistorique... malheuresement il n'y a aucun nouveau standard en vue pour améliorer cet état des choses bien que certaines bibliothèques comme la glib soient assez courantes pour pouvoir les utiliser.
Sous windows (plus précisement avec les MFC) même si le code est plus concis et faire une application simple prend moins de temps, je trouve l'api particulièrement crad. Le code généré par le wizard est absolument incompréhensible, les fichiers sources regorgent de macros qu'on est censé modifier que par l'interface graphique, les appels peuvent être contraire à la philo du c++ (par ex: pour transformer le curseur souris en sablier, on instancie juste en local une variable d'un type particulier. Le constructeur change le curseur, et le destructeur exécuté automatiquement à la fin de la fonction le restaure : c'est peut être rapide, mais c'est surtout affreusement crad). Le résultat est que pour une application conséquente, le code devient un véritable bordel et il est particulièrement difficile de comprendre ce qui s'y passe pour pouvoir le debug'er...
En gros je dirais que sous windows c'est plutôt pratique, et sous unix/linux c'est plus carré
Par contre concernant le support, y a pas photo... entre les forums sur le net basés sur l'entraide entre dév et une hotline où il faut filer son num de CB, le choix est vite fait...