Socket portables est OS [Résolu]
Helldream
- Messages postés
- 29
- Date d'inscription
- mercredi 14 juin 2006
- Statut
- Membre
- Dernière intervention
- 6 février 2009
- Messages postés
- 29
- Date d'inscription
- mercredi 14 juin 2006
- Statut
- Membre
- Dernière intervention
- 6 février 2009
A voir également:
- Socket portables est os
- C / C++ / C++.NET : Encapsulation d'une partie de l'api socket portable - CodeS SourceS - Guide
- Trouver l'os d'un serveur (socket) - Codes sources - PHP (Réseau & Internet)
- Client serveur socket c - Guide
- Vérifier un numéro de téléphone portable - Forum - PHP
- Visual basic portable - Forum - VB.NET
5 réponses
Meilleure réponse
- Messages postés
- 492
- Date d'inscription
- samedi 10 juillet 2004
- Statut
- Membre
- Dernière intervention
- 12 janvier 2012
Salut,
si tu veux tu peux t'inspirer de ma source, qui fait exactement ce que tu veux.
Sinon, pour les detection de compilo/OS, jette un oeil ici -> http://predef.sourceforge.net/
@++
<hr size="2" width="100%" />TuRn3r
si tu veux tu peux t'inspirer de ma source, qui fait exactement ce que tu veux.
Sinon, pour les detection de compilo/OS, jette un oeil ici -> http://predef.sourceforge.net/
@++
<hr size="2" width="100%" />TuRn3r
Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire
197 internautes nous ont dit merci ce mois-ci
- Messages postés
- 2023
- Date d'inscription
- mardi 24 septembre 2002
- Statut
- Membre
- Dernière intervention
- 28 juillet 2008
Sans vouloir te décourager, créer une librairie de ce genre n'est utile qu'à but pédagogique puisque les librairies portables (wx, qt, etc...) intégère déjà la gestion de socket. En parenthèse, j'ajouterais meme que gérer le réseau avec Qt, c'est un pur bonheur.
Donc en conclusion je dirais, pourquoi refaire ce qui existe deja ? :)
Concernant l'utilisation du préprocesseur, je suis d'accord avec BruNews. De toute facon, tu auras très peu de code commun, donc rien que pour la lisibilité, mieux vaut séparer en plusieurs fichiers. Qt fonctionne de cette façon pour certain fichier.
Et oui le portable, c'est boulot.
Donc en conclusion je dirais, pourquoi refaire ce qui existe deja ? :)
Concernant l'utilisation du préprocesseur, je suis d'accord avec BruNews. De toute facon, tu auras très peu de code commun, donc rien que pour la lisibilité, mieux vaut séparer en plusieurs fichiers. Qt fonctionne de cette façon pour certain fichier.
Et oui le portable, c'est boulot.
Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire
197 internautes nous ont dit merci ce mois-ci
- Messages postés
- 21042
- Date d'inscription
- jeudi 23 janvier 2003
- Statut
- Modérateur
- Dernière intervention
- 21 août 2019
Encore cette illusion du portable qui t'amènera à réduire au + petit dénominateur commun, résultat daube pour 4 OS. Mettre 4 codes dans un fichier n'apporte aucune valeur ajoutée comparé à 4 fichiers.
Fais propre et performant pour chacun, ensuite une config d'inclusion pour compilation vers chaque OS.
ciao...
BruNews, MVP VC++
Fais propre et performant pour chacun, ensuite une config d'inclusion pour compilation vers chaque OS.
ciao...
BruNews, MVP VC++
- Messages postés
- 29
- Date d'inscription
- mercredi 14 juin 2006
- Statut
- Membre
- Dernière intervention
- 6 février 2009
Je ne vois pas la chose de la même façon :
"Encore cette illusion du portable qui t'amènera à réduire au + petit
dénominateur commun, résultat daube pour 4 OS".
--> Peux tu me citer ennormément de Gros logiciels conçus pour plus que 3 OS (déjà 3, c'est pas donné, la plupart ne sont développés que pour la plateforme principale visée : Windows, Mac OU EXCLUSIF Linux) ? A part certains projets open source, j'en connais très peu... Même Open Office n'est accessible que pour ces 3 plateformes ! Alors désolé, mais je trouve ta remarque un peu exagéré. Si déjà tous les logiciels (jeux et autres) étaient compatibles pour ces 3 plateformes, je pense que pas mal de monde seraient très satisfaits
"Mettre 4 codes dans un fichier n'apporte aucune valeur ajoutée comparé à 4 fichiers."
--> En effet, je suis d'accord, mais je doute que ça en retire. Par contre, en temps de développement, avoir quelques classes d'abstraction, afin d'avoir quelques fonctions utilisables indépendamment de l'OS... C'est quand même bien pratique. Franchement, tu te vois modifier par exemple un code comme celui d'Open Office afin de le réécrire pour chaque OS? Et remodifier chaque fichier à chaque mise à jour? Même au niveau de la maintenance, avoir une grosse partie de code en commun (car d'après ce que j'ai compris, pour les socket il n'y a presque pas de différence) évite d'avoir à remodifier x fichiers à chaque mise à jour.
J'ai peut être mal compris ce que tu voulais dire, mais à première vue, je ne vois rien de très constructif (pas de piste précise pour m'y prendre autrement, ni de réponse à mes questions...)
"Encore cette illusion du portable qui t'amènera à réduire au + petit
dénominateur commun, résultat daube pour 4 OS".
--> Peux tu me citer ennormément de Gros logiciels conçus pour plus que 3 OS (déjà 3, c'est pas donné, la plupart ne sont développés que pour la plateforme principale visée : Windows, Mac OU EXCLUSIF Linux) ? A part certains projets open source, j'en connais très peu... Même Open Office n'est accessible que pour ces 3 plateformes ! Alors désolé, mais je trouve ta remarque un peu exagéré. Si déjà tous les logiciels (jeux et autres) étaient compatibles pour ces 3 plateformes, je pense que pas mal de monde seraient très satisfaits
"Mettre 4 codes dans un fichier n'apporte aucune valeur ajoutée comparé à 4 fichiers."
--> En effet, je suis d'accord, mais je doute que ça en retire. Par contre, en temps de développement, avoir quelques classes d'abstraction, afin d'avoir quelques fonctions utilisables indépendamment de l'OS... C'est quand même bien pratique. Franchement, tu te vois modifier par exemple un code comme celui d'Open Office afin de le réécrire pour chaque OS? Et remodifier chaque fichier à chaque mise à jour? Même au niveau de la maintenance, avoir une grosse partie de code en commun (car d'après ce que j'ai compris, pour les socket il n'y a presque pas de différence) évite d'avoir à remodifier x fichiers à chaque mise à jour.
J'ai peut être mal compris ce que tu voulais dire, mais à première vue, je ne vois rien de très constructif (pas de piste précise pour m'y prendre autrement, ni de réponse à mes questions...)
- Messages postés
- 29
- Date d'inscription
- mercredi 14 juin 2006
- Statut
- Membre
- Dernière intervention
- 6 février 2009
Merci pour vos réponses.
luhtor > Je peux comprendre en effet que lorsque le code diffère beaucoup (disons moins de 75% du code en commun, et encore), cela peut devenir clairement illisible et inmaintenable. Mais là, je parle d'une classe gérant uniquement les socket, et il me semble que les différences sont assez minimes. C'est cela que je reprochais à BruNews : lancer une généralité, qui ne s'applique pas forcément au sujet posé, et sans vraiment développer son argumentaire.
Pour ce qui est des librairies, en effet mes motivations sont :
- Avant tout apprendre à faire un code portable, propre, et à gérer les socket par moi même
- Ne dépendre que du minimum de librairies, afin de pouvoir avoir des fonctions adaptées au mieux à mon utilisation (ne pas utiliser une librairie comme QT si je n'utilise que ses socket)
- Maitriser au mieux mon code (pour la maintenance, par exemple)
- Avoir un minimum de limitation, concernant par exemple les licences.
Cela dit, il est vrai que cela fait plusieurs fois que j'entends du bien de QT, et que certaines de ses fonctionnalités me tenteraient bien. Mais si je ne l'utilise pas pour sa fonction première (gestion des fenêtres), ce serait dommage :)
turnerom > Merci pour le lien, je regarde ça de suite ;)
luhtor > Je peux comprendre en effet que lorsque le code diffère beaucoup (disons moins de 75% du code en commun, et encore), cela peut devenir clairement illisible et inmaintenable. Mais là, je parle d'une classe gérant uniquement les socket, et il me semble que les différences sont assez minimes. C'est cela que je reprochais à BruNews : lancer une généralité, qui ne s'applique pas forcément au sujet posé, et sans vraiment développer son argumentaire.
Pour ce qui est des librairies, en effet mes motivations sont :
- Avant tout apprendre à faire un code portable, propre, et à gérer les socket par moi même
- Ne dépendre que du minimum de librairies, afin de pouvoir avoir des fonctions adaptées au mieux à mon utilisation (ne pas utiliser une librairie comme QT si je n'utilise que ses socket)
- Maitriser au mieux mon code (pour la maintenance, par exemple)
- Avoir un minimum de limitation, concernant par exemple les licences.
Cela dit, il est vrai que cela fait plusieurs fois que j'entends du bien de QT, et que certaines de ses fonctionnalités me tenteraient bien. Mais si je ne l'utilise pas pour sa fonction première (gestion des fenêtres), ce serait dommage :)
turnerom > Merci pour le lien, je regarde ça de suite ;)