signed ou unsigned ? - C++ - Programmation
Marsh Posté le 17-12-2002 à 09:46:46
J'crois que c'est signé par défaut.
un char par contre, je dirais que c'est non-signé (à vérifier)
Marsh Posté le 17-12-2002 à 10:42:10
short et long sont signés par defaut
quand au char ca depend de l'implementation
Marsh Posté le 17-12-2002 à 10:50:34
à ... qq1 c si (déjà short eet long sont bien signés sous VC++6, on m'a dit qu'il était peu respectueux de la norme) et ensuite si char est signé ou pas, tjs sous vc++6 ?
Marsh Posté le 17-12-2002 à 11:43:36
Tu n'as qu'à faire le test :
Code :
|
Marsh Posté le 17-12-2002 à 12:13:58
d'apres l'article de Musaran, ca me mettra -1 et ca le déclarera en non signé. Musaran disait qu'il se met tout seul en signé ou non signé suivant son utilisation. (si g bien compris ce qu'il avait dit)
Marsh Posté le 17-12-2002 à 12:29:18
Citation : quand au char ca depend de l'implementation |
Quand j'y pense, ca ca veux dire qu'il ne faut pas en tenir compte. Donc si pour toi ca t'interresse de savoir si c'est signe ou non signe, c'est qu'il ne faut pas utiliser char mais "signed char" et "unsigned char".
Le comportement d'un compilateur particulier en s'en fout, ce qui compte c'est le standard
Marsh Posté le 17-12-2002 à 13:58:38
Kristoph a écrit :
|
Oui enfin ce qui compte c'est ce que tu liveras a ton client en utilisant le compilo mis a ta disposition...
Marsh Posté le 17-12-2002 à 15:06:32
Respecter les standards, c'est un gage de qualité et de vision à long terme. Et en plus ça fait gagné du temps car on ne se pose pas des questions inutiles comme dans ce cas :
Le standard dit, ça dépend. Moi je réponds : "OK, j'utilise alors autre chose pour lequel ça ne dépend pas au lieu de demander à mon compilo comment il fait". De plus, si demain tu applique le SPz de Microsoft et que tout à coup Visual se met à mieux respecter le standard, le code que tu avais écrit ne marcheras plus. Alors respect des standards avant tout.
Marsh Posté le 17-12-2002 à 15:23:16
J'essaie, c pour ca que je pose bcp de questions sur la norme (et j'essaie d'eviter sur mon compilo)
Marsh Posté le 17-12-2002 à 15:33:27
Kristoph a écrit : Respecter les standards, c'est un gage de qualité et de vision à long terme. Et en plus ça fait gagné du temps car on ne se pose pas des questions inutiles comme dans ce cas : |
OK, donc tu ne fais jamais d'interfaces graphiques, tu n'utilises pas de multi-threading sous Win (pas POSIX)...
C'est quand meme tres limitatif non ?
Tu trouves des amateurs pour tes production en mode console
Serieusement, je suis d'accord sur le principe que il vaut mieux respecter le standard, mais quelques fois ce n'est pas possible...
Marsh Posté le 17-12-2002 à 16:00:12
J'utilises le standard là où il existe ! Et quand il y a un problème entre les outils que j'utilises et le standard, autant que possible je choisis une solution qui reste définie par ce dernier plustot que de compter sur un comportement qui pourra être amené à changer dans une version ulterieure !
Et puis, utilises QT et tu auras de l'interface graphique portable, et tu auras du multithreading portable aussi
Marsh Posté le 17-12-2002 à 16:45:03
si, vu ke en général je dev sous win, j'utilise les API et le multithreading, les interfaces graphiques je fais en API et g encore enormement de mal ... d'ailleurs si qq1 pouvait me filer des liens d'interfaces graphiques en API (sans MFC beuuuurk ni rien de ce genre)
Marsh Posté le 17-12-2002 à 16:46:28
BlackGoddess a écrit : si, vu ke en général je dev sous win, j'utilise les API et le multithreading, les interfaces graphiques je fais en API et g encore enormement de mal ... d'ailleurs si qq1 pouvait me filer des liens d'interfaces graphiques en API (sans MFC beuuuurk ni rien de ce genre) |
Pourquoi MFC beuuuurk ?
Marsh Posté le 17-12-2002 à 16:48:38
Kristoph a écrit : J'utilises le standard là où il existe ! Et quand il y a un problème entre les outils que j'utilises et le standard, autant que possible je choisis une solution qui reste définie par ce dernier plustot que de compter sur un comportement qui pourra être amené à changer dans une version ulterieure ! |
QT Ce n'est pas standard ! Et il y a d'autres bibliotheques dans ce style (wxwindows par exemple)...
Logiquement pour le multi-threading tu devrais suivre pthread (norme POSIX)...
Quand au standard, je suis d'accord c'est une reference, mais aucun compilo ne le respecte totalement...
donc mes prioritées sont :
1- Arriver au resultat car c'est pour cela qu'on me paye en premier lieu
2- respecter le standard quand il existe et est appliqué/applicable...
Marsh Posté le 17-12-2002 à 17:00:24
j'm pas les MFC, c un avis personnel mais je supporte pas
Marsh Posté le 19-12-2002 à 01:32:57
BlackGoddess a écrit : d'apres l'article de Musaran, ca me mettra -1 et ca le déclarera en non signé. Musaran disait qu'il se met tout seul en signé ou non signé suivant son utilisation. (si g bien compris ce qu'il avait dit) |
T'as mal compris, ou mes explications sont mauvaises (où ça ?).
Les types numériques intégrés du C++:
Code :
|
Plusieurs choses à remarquer:
cout << typeid(short).name() << endl; //"signed short int" de son vrai nom
Donc, pour reprendre ton exemple:
Code :
|
Soit 'char' est signé et ça marche.
Soit 'char' est non-signé et la valeur obtenue n'est pas définie par le standard. Ce serait probablement modulo 256 donnant 255.
Le cast sert uniquement à fermer son clapet au compilateur dans ce dernier cas.
Marsh Posté le 17-12-2002 à 09:44:38
Bonjour,
qd on délcare un long, un short, est-ce un signé ou non-signé ?
et pour un char ? (g lu un topic de Musaran la dessus), mais si on lit 1 char ds un fichier par exemple, sera-t-il lu comme un signé ou non ?
---------------
-( BlackGoddess )-