Suite à mon passage en version 64 bit, j'ai tenté de remettre à jour ma base de donnée de code.
En testant tous mes codes, sous mon nouvel environnement, je suis heurté à un problème.
Certaines de fonctions de code qui fonctionnaient sous 32 bits, ne fonctionnent plus, puisqu'elle ont été soit effacées soit remplacées par d'autres pour l'environnement 64 bits. Ok, pas de soucis.
Par contre, j'ai des codes qui sont censées encore fonctionner en 64 bits, qui me donnent des warning, certains même, ne fonctionnent plus du tout.
Actuellement j'ai un problème avec la fonction size pour le retournement de valeur ou pour afficher la taille d'un VECTOR<INT>...
#include <iostream>
#include <vector>
#include <string>
using std::cout;
using std::endl;
using std::vector;
using std::size_t;
using std::string;
using std::to_string;
static int Split(vector<string>& tableau, string basededonnee, char separateur)
{
tableau.clear();
string::size_type section=basededonnee.find(separateur);
while(section!=string::npos)
{
tableau.push_back(basededonnee.substr(0, section));
basededonnee=basededonnee.substr(section + 1);
section=basededonnee.find(separateur);
}
tableau.push_back(basededonnee);
return tableau.size();
}
int main()
{
int taille_liste{};
vector<int>liste{};
for(int i=0; i<10; ++i)
{
liste.push_back(i);
}
taille_liste=liste.size();
cout<<taille_liste<<endl;
}
Le code d'erreur est :
H:\Code\c++\Vector\Vectorisation_decoupage.cpp(22): warning C4267: 'return': conversion from 'size_t' to 'int', possible loss of data H:\Code\c++\Vector\Vectorisation_decoupage.cpp(22): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data H:\Code\c++\Vector\Vectorisation_decoupage.cpp(34): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
Je code ne fonctionne même plus.
Je suis allé sur le site microsoft pour voir le code d'erreur. C4267;
J'ai tenté avec la fonction size_t, size, auto size(), faire des boucles avec .begin(),.end(), avec des auto ...etc. Rien ne fonctionne.
Donc, si j'ai bien compris on ne peut plus faire un size() sur un int en version 64 bits, car le int est trop petit par rapport à un _int64. Sur d'autres sites, on parle d'erreurs internes qui sont générées par la fonction size() avec int.
Mais on fait comment alors, on abandonne les int ???
Vu toutes les explications que j'ai lu, je suis perdu, et je n'y comprends plus rien !!!
Car sur certain site, ils disent que size() est censé encore fonctionner.
Enfin, si je comprends. Cela ne fonctionne plus.
Quelqu'un peut-il m'expliquer et me corriger mon code d'exemple ci-dessous, s'il vous plait ?
Pour être claire, ce n'est pas un problème de passage au 64bits, c'est juste que vous avez un code vraiment pas terrible et que le passage en 64bits n'a fait que révéler.
Généralement, quand on fait un développement, on compile à la fois en 32bits et en 64bits pour voir rapidement qu'on est en train d'écrire comme un sagouin.
C4264 n'est qu'un warning, pas une erreur.
Mais il faut toujours corriger les warning.
Le problème majeur, c'est que votre fonction "Split" sent bon le C tout moisi.
Les classes de la STL ont été conçues pour être utilisé correctement en C++, pas en C.
Dans les réponses de la question du lien qui suit donne plusieurs approche bien plus C++ que cette horrible fonction "Split" qui a plein d'effet de bord.
Vous ne devriez donc plus avoir besoin du moindre "int" dans votre code et "auto" est ton ami.
>Donc, si j'ai bien compris on ne peut plus faire un size() sur un int en version 64 bits
Si mais "size" a toujours renvoyé un "size_t" et non un int.
Vous voulez rentrer des ronds dans des carrés. Que cela passe en 32bits est une chose, mais ce n'est pas correct d'un point de vue cohérence des types.
Par chance, dans votre environnement 32bits, int et size_t était synonyme mais ce n'était qu'un hasard (ou une mauvaise lecture des warning).
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Ce sont des warnings qui te disent qu'une mauvaise utilisation d'une conversion implicite de size_t en int peuvent potentiellement mener à une perte de donnée.
size_t == unsigned int || EDIT : size_t (PARFOIS) == unsigned int
Etant donnée que size() renvoie la taille d'un vecteur, devrait pas y avoir de problèmes à renvoyer un unsigned int.
En ce qui concerne, les découpes, c'est du vieux code que j'ai fait il y a deux ans, lorsque je débutais sur la programmation c++. Si tu avais vu ce que je fais, il y a deux ans en débutant, je serai fusilier. Mais, il fallait bien débuter. J'en ai d'autres plus rapide et mieux fait maintenant.
Mon problème reste demeure sur le size du VECTOR<INT>. C 'est la ou je suis paumer.
Quelque soit l'environnement, lorsque l'on utilise size() pour récupérer la taille d'un VECTOR, on ne doit pas avoir de warning, et cela doit fonctionner. J'ai tenté sur plusieurs compilateur Visual studio, Eclipse, Codeblock, Sierrachart. Cela ne fonctionne pas.
D'ou mon étonnement.
#include <iostream>
#include <vector>
#include <string>
using std::cout;
using std::endl;
using std::vector;
using std::size_t;
using std::string;
using std::to_string;
int main()
{
int taille_liste{};
vector<int>liste{};
for(int i=0; i<10; ++i)
{
liste.push_back(i);
}
taille_liste=liste.size();
cout<<taille_liste<<endl;
}
Normalement, ce code simple, doit fonctionner.
17h54, Après ce message, je vais redémarrer. En cas de bug, on ne sait jamais.
On t'a explique que std::vector::size() retourne un size_t. On t'a expliqué qu'un size_t est different d'un int.
Dit autrement, si cela n'a pas declenché des ces mêmes warnings, c'est uniquement par coup de bol. Donc si tu veux stocker une donnée de type size_t, la variable qui doit acceuillir la donnée doit etre de size_t aussi.
Depuis C++, il y' a un mot clé auto qui permet de deduire automatiquement les types en fonction de la situation. Si tu l'avais utilisée, tu n'aurais pas eu ce warning. Personnelement, je l'utilise systématiquement dès que la variable est suivi d'un =.
J'avais déjà tester ce code la, sur tous les compilateurs que j'ai. Mais, la aussi cela ne fonctionne pas. Je connais cette fonction.
C'est incompréhensible.
Je suis sans solution, à moins de tout reformater et de passer en 32/64 Bits pour windows et linux.
Rien, que le fait d'y penser, j'en ai mal au crâne.
Je viens de voir un message. J'ai déjà fait avec des auto. Je les utilises aussi.
Mais la je pense plus pour une mauvaise installation des bibliothèques pour windows, ou un bug lors de l'installation de celle-ci. Vu que j'avais formater mon seven 64 pour mettre le 10 en 64 et le debian 64 ainsi que le lutis linux, il y a deux jours de cela. Elle commence bien cette expérience avec windows 10.
19 h 00. Après, une réflexion après manger. Je vais tout formater repasser sur Seven 64.
Merci à tous pour tout vos messages.
Bon je vais mettre en vente cette merde windows 10 sur le bon coin ou ebay.
En tout cas c'est terminer, je verai le prochain, si tout le monde dit que c'est bien
J'ai pas vu ton message j'étais en train de modifier le mien quand tu as posté. On ne peut pas écrire deux messages à la suite sur ce forum.
Non, c'est un problème d'installation, j'ai eu des problèmes avec il y a deux jours. Installer windows 10 64Bits sur mon nouvel ordi, ce fut une galère, il y a deux jours.
Ne te fâche pas, s'il te plait tu peux me l'a donner la documentation en lien. Peut être que je vais éviter de faire ce que j'ai dit plus haut.
En tout cas, sincèrement merci pour tous vos messages.
Votre problème n'a strictement rien à voir avec votre OS.
Votre bidouille était peut-être tombée en marche sur les anciens environnements, mais n'est que contingence.
Pour la doc: c'est juste sous le "RTFM" dans l'un de mes précédents posts.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Probleme de fonction sous environnement 64 bits
× 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.
Eug