Bonjour , dans le cadre de mon travail nous avons a supporte de vieille plateforme ou des plateforme un peu funky qui nous oblige a pas pouvoir utiliser c++11/14. Le probleme c'est qu'en local , mes codes c++11 passe bien , mais lorsque rendu sur le CI ca passe pas sur les vieilles plateformes. Nous aimerions faire en sorte que les codes c++11/14 ne build plus en local avec vs2015 , c'est possible ?
Non, MSVC ne permet pas de choisir la version du C++. Il faut que tu compiles avec la meme version de MSVC pour reproduire les erreurs de build.
Dommage
bacelar a écrit:
Pourquoi ne pas avoir les outils utilisés pas le CI aussi sur votre machine de dev ?
C'est ce qu'on fait parfois , mais desfoison va ajouter 3-4 lignes et envoyer sur le source control qui lance le CI. Des truc simple comme un membre initialise "in-class" qui passe facilement le radar si on y porte pas attention. Rien de grave mais ca fait perdre parfois 3-4 minutes pour changer la ligne fautive et reenvoyer sur le source control. On aurait aimer que c'est lignes soit detecter en local sur le coup.
La seule méthode fiable, c'est d'utiliser les mêmes outils (de bas niveau), rien n'empêche d'utiliser ces outils dans VS, via MSBUILD par exemple.
Rien ne garantit que vos outils "funky" suivent à la lettre un standard plutôt qu'un autre.
Vous avez de la CI, et vous avez un feedback en 3-4 minutes, c'est vraiment déjà très confortable.
Sinon, si c'est toujours les mêmes boulettes, vous pouvez mettre en place des règles à la FxCop ou via d'autres outils d'analyses customisables (ou peut-être que ces plateformes dispose de jeux de règles pluggable dans les outils d'analyses).
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Avec VS2017 (pas sûr que ce soit le cas sur VS2015, mais ça ne coûte rien de vérifier), il y a un paramètre de la ligne de commande /std qui, je pense est analogue à celui de gcc et qui permet de spécifier le niveau de norme à accepter. Par défaut, il est positionné sur /std:c++latest qui indique: utiliser tout ce qui est supporté par le compilateur. Je ne sais pas si ça peut aider pour ton problème, mais c'est peut être une piste peu coûteuse à explorer.
Après, je devine que ta plateforme "un peu funky" est en fait un truc à base ARM sur Windows CE 5/6. Je ne qualifierais pas ça de funky mais de cauchemardesque, le support est inexistant, les API sont bugées jusqu'à la moelle... bref ce sont des vraies merdes. Avec ces merdes, tu n'as pas d'autre choix que d'utiliser exactement le même compilateur avec les mêmes bibliothèques et les mêmes options de compilations (que bien sûr tu dois deviner) sinon c'est mort. Un petit exemple, les programmes de tests de boost::shared_ptr, les tests de capacité sont surdimensionnés, le nombre de shared_ptr prévu par le test est trop important, on pourrait s'attendre à ce que le test échoue sur un std::bad_alloc, mais non, le programme de test plante comme merde sur une violation d'accès, la SL est conçue pour une gestion d'erreur par exception, sauf qu'en cas d'échec d'allocation new retourne un pointeur nul (sauf si tu link avec MFC auquel cas, tu as bien une exception). Tu vas me dire ouais mais ça n'arrivera pas. Si ça arrive, ça arrive d'autant plus que la gestion de la mémoire est bugée, si j'alloue 20 Mo, ça passe, je libère, et je réalloue 20 Mo... Pan! dans ta gueule...
Tu utilises VS2008 avec des lib VS2005? ça va merder (dans le meilleur des cas ça ne linkera même pas). Tu valides ton code avec VS2005 Win32, la SL de clarm n'est pas la même (et c'est valable aussi avec VS2008), du coup, même si ton code x86 marche, rien ne garantit que ça marchera sur la cible, à chaque fois c'est un coup de poker!
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.