c++ pour vista (bis)
J'ai rencontré un problème en essayant d'installer celui-là sous Vista :Envoyé par Memnon
Ce message s'affiche à la fin de l'installation, juste au moment où on a l'impression que ça a bien marché. :s
Je suis allé sur Win Update, mais je n'ai rien trouvé comme parade.
Quelqu'un aurait une solution à ça ?
Dernière modification par yoda1234 ; 30/08/2007 à 16h35.
Bonjour,
plusieurs choses:
- Merci de respecter la charte de notre forum qui dit:
La courtoisie est de rigueur sur ce forum : pour une demande de renseignements bonjour et merci devraient être des automatismes.- De plus, tu aurais dû créer ton propre sujet: J'ai donc séparé ton message pour en faire un fil à part entière.
- Et enfin nous ne sommes pas favorable à l'utilisation de serveurs extérieurs pour les images; Merci donc d'utiliser la fonction "Gérer les pièces jointes".
Là où l'ignorance est un bienfait, c'est de la folie d'être sage (Thomas Gray).
Salut,
J'aurais effectivement fait mon topic si j'avais cru devoir le faire... Là, j'avais l'impression que mon problème collait bien au topic en cours, donc autant pour moi...
Ensuite, j'avais déjà lu la Charte et je n'avais rien vu sur votre hébergeur propre. J'ai donc uploadé mon image comme on le fait partout ailleurs. Là encore, autant pour moi...
A part ça, merci d'avance à qui aurait une solution. :s
Une explication concernant les images sur des serveurs extérieurs : il n'y a aucune garantie de permanence de l'image, ce qui fait que le sujet peut devenir inexploitable si quelqu'un le consulte dans quelque temps.
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
Je ne peux pas t'aider pour ton installation... mais est-il nécessaire pour toi d'utiliser visual C++ ??? Ne pourrais tu essayer Code::blocks ?
Comme le message l'indique, il faut que tu ailles chercher le sp1 de visual express sur le lien qui est donné.
Cela dit, visual express est un excellent EDI. Le principal reproche (outre le fait qu'il ne tourne que sous windows) que je lui fait est que l'on ne peut pas choisir le compilateur, contrairement à code blocks qui, lui aussi est un excellent EDI.
Personnellement, j'ai une grosse préférence pour visual, pour les outils de trés bonne qualité qu'il fourni, notamment le débugger.
Pour moi c'est un immense défaut car tu es pogné avec le magnifique (sentir l'apport ironique au terme) compilateur de MS. Il ne respecte pas l'ANSI C++, et tu perds donc une belle partie de compatibilité que tu pourrais obtenir avec un GNU.
Je ne suis pas d'accord. C'était vrai avec Visual6 (à bannir définitivement). Mais dés VS7.1, le respect de la norme ANSI/ISO est devenu un argument de vente, et avec le compilo MS Toolkit 2003 (utilisé par visual8 et visual express edition), on peut dire que dorénavant, MS respecte la norme autant que GNU.
Aprés, gcc a un peu d'avance, notamment sur la STL, puisqu'ils ont commencé à intégrer la TR1 (et je crois même qu'il existe une branche qui a commencé à intégrer la TR2), mais là on sort du stantard.
Ben ce n'est pas nécessaire, mais j'ai déjà essayé Code::Blocks et Dev-C++. Le premier posait problème à chaque enregistrement de fichier (il ne "trouvait pas le répertoire" alors que son existence était évidente...), le second n'est plus mis à jour depuis un certain temps et était donc truffé de bugs sous Vista (y compris le même que Code::Blocks, ainsi qu'un mauvais affichage des caractères "spéciaux", etc).
Je me suis vaguement demandé si ce problème d'enregistrement ne venait donc pas de mon ordi, mais je ne vois vraiment pas pourquoi ma machine poserait problème... J'ai donc décidé d'essayer Visual C++, et voilà où j'en suis maintenant. En tout cas, merci pour ta suggestion. ^^
Justement, j'étais allé sur le lien vers Win Update et ça n'avait rien donné.
Mais bon, j'ai trouvé et téléchargé ce SP1... Sauf que l'installation n'a pas marché non plus. Logique, puisque l'exécutable ne trouve aucun programme concerné sur l'ordi (l'installation de Visual ayant elle-même foiré) ! :s
Sinon, pardon pour le retard de ma réponse, j'ai eu une petite semaine d'absence.
Non non il ne respecte pas complètement.
C'est pourquoi j'ai des étudiants qui me donne du code qui compile sous VS et pas sous une plateforme UNIX avec GNU GCC alors qu'ils croient faire de l'ANSI. Cependant, je pense effectivement que tout code ANSI est accepté par VS7.1 mais je n'en ai pas confirmation. D'ailleurs MS n'a jamais voulu se plier à cette norme pour des raisons commerciales.
Certes ce sont des détails souvent et c'est un peu anodin, mais c'est le cas.
Exemple, tiré du site de Microsoft
The compiler supports the following two non-ANSI casts:C'est Microsoft qui le dit -_- et tu vois qu'il est facile de produire donc du code non ANSI avec VS C++
- Use of non-ANSI casts to produce l-values:
The preceding example could be rewritten to conform with the ANSI C standard as follows:Code:char *p; (( int * ) p )++;Code:p = ( char * )(( int * )p + 1 );- Non-ANSI casting of a function pointer to a data pointer:
To perform the same cast while maintaining ANSI compatibility, you must cast the function pointer to an int before casting it to a data pointer:Code:int ( * pfunc ) (); int *pdata; pdata = ( int * ) pfunc;
Code:pdata = ( int * ) (int) pfunc;
Le compilo de visual ne respecte pas le standard à 100%, je ne le nie pas (et je ne l'ai jamais affirmé). Mais gcc non plus. Le seul compilo qui le fait, c'est le Comeau.
Mais l'erreur que je te pointe fais que beaucoup de code VS n'est pas utilisable autre part -_-
Et ça c'est un problème ne trouves tu pas ?
C'est pas rare de voir des développeurs utilisant VS utiliser l'approche autorisée par VS en utilisant les pointeurs car ils ne savent pas que ce n'est pas ANSI. Tu vas me dire qu'ils devraient le savoir... certes certes... mais avec le GCC c'est bien plus difficile de trouver un exemple aussi flagrant.
Et pourtant, il y en a beaucoup.
Voir, par exemple: http://gcc.gnu.org/gcc-3.4/changes.html
C'est la liste des changements entre gcc 3.x et gcc 4.x sur les points qui ne respectaient pas la norme.
En vérité, j'ai dit une erreur: même le Comeau ne respecte pas la norme à 100%.
Euh... justement... ce sont les points qui maintenant respectent encore plus la norme... il y en a de moins en moins donc.... ton raisonnement est spécial (à défaut d'être spécieux) car tu me donnes une liste des points qui vérifient la norme pour me montrer qu'il y a beaucoup de points qui ne la vérifient pas
« G++ is now much closer to full conformance to the ISO/ANSI C++ standard. This means, among other things, that a lot of invalid constructs which used to be accepted in previous versions will now be rejected. »
MS est connu pour vouloir faire SON standard... ils ne respectent ANSI autant qu'ils peuvent que parce que sinon de nombreuses personnes ne voudraient pas utiliser leurs compilateurs sinon, mais il est clair qu'ils veulent que ce soit leurs choix qui soit le standard. Encore une fois, les erreurs que je t'ai montré son des erreurs qui sont souvent faîtes sous VS et qui ne sont donc plus ANSI. Aurais tu un exemple aussi courant pour G++ ? Je n'ai pas particulièrement cherché car je n'ai jamais eu de problème avec des gens qui avait développé avec G++ même quand j'utilisais un autre compilateur.
C'est là la nature du problème. Pas parce que leurs choix seraient plus mauvais, mais parce qu'ils veulent contrôler leurs C++. Quand je discute avec des gens de MS, ils me disent souvent « our C++ »... je crois que c'est explicite non ?
Donc je vois effectivement un problème à VS sur ce point, et je préfère un outil qui vise à suivre un standard qui permet qu'on s'entende sur le langage.
Par curiosité, je viens de compile ce code (sous visual 8):
résultat:Code:char *p; (( int * ) p )++;
Je ne sais pas où tu as trouvé tes infos, mais visiblement, cela ne concernait pas la dernière version de Visual.error C2105: '++' needs l-value
Concernant gcc, c'était juste pour montrer que les versions 3 n'étaient pas non plus respectueuses du standard, contrairement à des mythes que l'on voit encore ressurgir par moment. Et cependant, il est préférable d'utiliser, en production, les versions 3 que les versions 4.
M'enfin bon, je veux bien accepter que le compilateur de visual respecte moins le stantard que gcc, mais ils en sont tous deux tellement proche que les différences sont négligeables. En tout cas, depuis visual 8, je n'ai pas eu de sérieux problème à cause de non respect du standard, et pourtant j'effectue fréquemment des compilations de mes applis avec différents compilateurs pour différentes raison (portabilité, tests, etc.).
Enfin, tout ça pour dire que là, nous pinaillons (et moi le premier, j'en conviens, j'aime beaucoup ça), mais que ça n'a pas vraiment d'importance.
Sur le site MSDN de Microsoft ^_^
Désolé s'ils ne sont pas à jour sur leurs propres documentations... ça donne pas envie d'utiliser leurs outils
C'est ton avis.Et cependant, il est préférable d'utiliser, en production, les versions 3 que les versions 4.
Je connais de très nombreux projets qui ne s'accordent pas à celui ci.
Tu as certes mis des arguments valables pour certains cas, mais pas pour tous. Il y a des sociétés de services qui préfèrent passer tout de suite à la version 4 pour ne pas être en retard plus tard et que cela leurs coûte trop.
http://msdn2.microsoft.com/en-us/lib...f8(VS.80).aspx
C'est normal que ça marche. C'est ce que j'avais dit.
C'est justement NON ANSI !
Donc je réitère, c'est une forme très utilisée par les développeurs de VS qui n'est pas ANSI et ne marche pas sur la plupart (tous?) des autres compilateurs -_-
