Salut,
Selon vous, quelle est la manière la plus simple de convertir un code gcc, en un code Visual C++ ?
Version imprimable
Salut,
Selon vous, quelle est la manière la plus simple de convertir un code gcc, en un code Visual C++ ?
Ta question est un peu vague :aie:
Tu pourrais préciser si tu utilises des makefiles, des libs propres à gcc, ta version de visual studio ...
;)
et même parmi les libs standard de gcc... il y a pas mal de changement pour vc++ notamment dans la libc si tu y a recours parfois, où des méthodes disponibles sous environnement linux n'existent pas sous windows, car ces méthode existent dans l'API Windows.
de même si tu utilise les sockets nativement, sans passer par une lib tierce, le passage à VC++ risque de nécessiter pas mal de modifications.
Si tu a réécrit des classes à la sauce STL en mettant des templates partout, également il n'est pas sure que l'écriture que tu ai choisi fonctionne également sous VC++... trouver une écriture avec les templates qui compile et fonctionne à la fois sur les 2 compilateurs n'est pas toujours évident.
précise un peu plus avant qu'on puisse t'aider car comme tu vois...
Non, je n'utilise pas de makesfiles dans ce projet.
J'ignore si les librairies que j'utilise sont propres à gcc ;
#include<stdio.h>
#include<unistd.h>
#include<stdlib.h>
#include<sys/wait.h>
#include<string.h>
J'utilise Visual C++ 2010 Express
Je ne pense pas avoir recours à la libc (vu les includes)
J'ignore aussi si j'utilise les sockets nativement, sans passer par une lib tierce
Je ne pense pas avoir réécrit des classes à la sauce STL en mettant des templates partout, car j'ignore ce qu'est STL. Et les templates, ce sont des patrons ?
Enfin, comme vous le voyez, je débute pas mal :oops:.
J'avais entendu dire que le C et le C++ était des langages portables, alors du coup, ça m'étonne de rencontrer tant de difficultés...
C'est vrai que C et C++ sont des langages portables ?
Salut en théorie le plus simple c'est de
-créer un nouveau projet
-rajouter aux projets tous les fichiers .c,.cpp.h
Maintenant ce qui est le plus important c'est de savoir quel type de projet tu utilises si c'est un projet ligne de commande genre dos ou un projet avec une fenêtre genre Windows et des boutons.
Tu risques d'avoir des problèmes à la compilation notamment pour certaines classes ou structures.
Il faut regarder et trouver dans le MSDN les équivalents
sous Windows on peut utiliser les sockets nativement il faut passer par Winsock mais les appels de fonctions sont strictement identiques ( recv(),connect() etc..Citation:
Envoyé par réciproxy
http://msdn.microsoft.com/en-us/libr...16(VS.85).aspx
la STL fonctionne parfaitement avec VC++.Citation:
Envoyé par cinemania
On peut même l'utiliser avec les MFC
Et pareil pour boost...
les MFC... hum... vu le bordel je lui souhaite du courage :)
Alors pour information ton projet utilise la libc... et c'est bien ca le problème.
en dehors des mots clés qui varient entre g++ et vc++, la libc... change pas mal aussi...
en effet, il n'y a quasiment aucune méthode "réentrante" dans la libc de windows/vc++, alors que yen a plein la libc de linux, résultat... les développeurs qui ont eu vent que c'était mieux d'utiliser les méthodes réentrantes, les utilisent et comme il est très dur dans ce pays de trouver des développeurs multiplateforme...
Le problème, c'est que C++ c'est de loin le langage le plus complexe qui soit, et le plus subtile... si tu n'a aucune connaissance dans le domaine, porter un projet C++ linux vers Windows ca ressemble vaguement à mission impossible :)
enfin bon je dit ca je dit rien... hein...
mais moi je te conseillerais quand même déjà d'apprendre le langage avant, c'est la moindre des choses.
Mat.M les appels sont les mêmes pour les winsocks à ceci prêt qu'il est souvent nécessaires de faire des réglages particuliers nécessitant un API non exposé par linux, si tu veux que certaines de ces méthodes "identiques" aient un fonctionnement identique...
Si t'avais fait du développement avec les sockets entre les 3 versions de BSD, quelques distrib linux, et windows... tu saurais que si y a bien un domaine où tout ce qui est sensé être standard ne l'est pas... c'est bien ca.
et oui BSD expose les memes fonctions de libc, et surprise... elles fonctionnent pas du tout pareil, ou carrément mieux, elles sont juste là pour faire beau... windows fait pareil dans son coin...
alors le fin du fin pour son projet c'est si y a un include du genre #include <pthread.h> dans le projet... le portage de son projet est particulièrement compromis... cette lib n'existe pas dans windows, vu que c'est inclue nativement dans l'api windows, et que ca ne ressemble pas du tout et que la gestion est totalement différente...
La STL c'est très bien si tu sais l'utiliser, et son projet ne l'utilise pas, il n'y a aucun include spécifique.
Et bien merci. J'y vois déjà beaucoup plus clair dans mon projet de conversion utilisant le langage C (cette fois ci, pas en C++).
Alors si je comprends bien, au jour d'aujourd'hui, on ne peu pas vraiment dire que la langage C soit portable, c'est ça ?
qu'il soit C ou C++ non.
il faut savoir que même au sein d'un même environnement similaire Linux et donc UNIX se n'est déjà pas portable, ou de façon plus générale d'un unix à l'autre, d'un bsd à l'autre, ou d'un linux vers un mac... d'un bsd vers un mac est plus simple car, macosx est basé sur bsd... mais bon... là encore ce n'est guère aisé.
On attend énormément de la nouvelle C++ 2.0 qui devrait déjà permettre d'uniformiser pas mal de choses, mais tant qu'il restera des différences structurelles, et surtout des différences d'architecture entre les OS
porter un logiciel écrit pour l'un, ne sera toujours pas plus évident pour l'autre.
Note toutefois, qu'il est plus facile de porter un projet écrit pour linux, avec usage de la lib GTK pour le GUI, vers Windows que l'inverse, qui lui est un travail pharaonique.
<unistd.h> et <sys/wait.h> sont propres à POSIX et ne marcheront pas sous Windows.
D'après moi, ils ne devraient même pas être présents sous MinGW (gcc pour Windows)...
Pour les fonctions de socket: Attention aux différences. Les read(), write() et close() POSIX ne marcheront pas sur des sockets sous Windows (où il faut utiliser les recv() et send() Berkeley ainsi que closesocket()), select() ne marche que sur les sockets (alors que sous POSIX, ça marche sur n'importe quel descripteur), etc.
Bonjour,
Je tombe un peu des nues, gcc existant sous Linux et Windows pourquoi vouloir utiliser le compilateur et l'IDE de microsoft ?
code::block reste un excellent IDE même si pas aussi complet que VC, mais quand on debute ca a peu d'importance.
code::block a l'avantage de pouvoir fonctionner avec le compilateur de microsoft comme avec mingw :ccool:
Je dispose d'un code que j'ai créer avec gcc sous Linux, et je voulais faire tourner ce code sous Windows. Il sagit d'un petit soft dans une interface en ligne de commande.
J'avais penser à Visual C++, mais effectivement, peu importe le compilateur que j'utilise, la fin ne justifiera pas les moyens.
J'ai beaucoup entendu parler de code::block, mais j'ignorai qu'on pouvait compiler avec.
Est-il vraiment possible de compiler avec code::block?
Bonjour,
Code::block est un IDE (au meme titre que visual studio).
Tu peux telecharger code::block avec mingw, tu l'installes et tu as un IDE + un compilateur tout frais tout chaud.
A partir de la, il ne devrait y avoir aucun soucis pour compiler ton projet linux (pour peux qu'il ne touche pas au système)
si le projet touche au système, utilise des fonctionnalités un peu exotiques, genre les threads, et pour l'affichage aussi...
tout devient complexe. en plus la différence entre POSIX/Berkeley c'est aussi une chianlie pas possible, comme déjà précisé :)
moi j'ai arrêté de vouloir porter les trucs fait pour l'un sur l'autre et vice versa :)
C'est clair. Je vais essayer voir avec code::block.
Je sais pas encore si je vais adapter le code jusqu'au bout.
J'ai dû confondre avec Java, c'est Java qui doit être portable.
Enfin, je vais vous tenir informé.
Nice.
Bonjour,
Effectivement tu as du confondre.
Le Java est un langage interprété (en comparaison au C qui est un langage compilé).
Cela signifie que le java a besoin d'un interpréteur pour s'exécuter, ainsi ce n'est plus au développeur applicatif a ce soucier de la portabilité mais au développeur de l'interpréteur.
Ainsi sur l'ensemble des systèmes qui dispose d'une machine virtuelle java ton code peut être exécuté.
Alors qu'en C il te faudra faire des retouches a droite a gauche (ou utiliser des bibliothèques portables qui s'occupe de tout ca pour toi).