striiiiiiiiiiiiiiing - Page 55

Tu ne peux pas tester la réaction suite à un débordement ? (si 255+1 = 0, par exemple, tu as la taille de ton char, non ?)

Si ce comportement est normalisé, sûrement.
Qqchose genre
unsigned int n = 255;
(unsigned char) n ++;
if (n == 0)
...

(avec sizeof (int) >= 2* sizeof (char)), et si t'es en signé ça marchera pas)

Bon, d'après mon bouquin, le comportement n'est pas défini par la norme en cas d'overflow, même si la majorité des implémentations perdent tout simplement les bits les plus forts, comme on s'y attend (genre 255 + 2 = 1).
Donc ça marchera la plupart du temps, mais ça n'a l'air jamais garanti.

^^Évidemment, un cast sur un opérateur unaire, ça me paraît bizarre.
^Pour la plupart des implémentations, c'est sûrement défini dans leur documentation.

@Kevin: On ne peut pas toujours mettre à jour les programmes.

Arf (j'étais pourtant content de mon idée )

Il y a toujours la macro CHAR_BIT sinon, mais je ne sais plus exactement ce qu'elle garantit à propos de la taille (c'est peut-être seulement un "au moins cette valeur").

Link (./1624) :
^^Évidemment, un cast sur un opérateur unaire, ça me paraît bizarre.

Et pourquoi ?

GoldenCrystal (./1602) :
contrairement à UTF-8 qui peut aller jusqu'à 8 octets4 octets.

six, pour stocker jusqu'a 0xFFFFFFFF

Brunni (./1611) :
Alors peu de compilos le respectent, vu que c'est pareil pour les µC ^^

sdcc a des int de 16 bits sur toutes ses plate formes, et le compilo ST du boulot aussi, au moins

Link (./1624) :
^^Évidemment, un cast sur un opérateur unaire, ça me paraît bizarre.

Et pourquoi ?

À la réflexion, c'est parce que pour moi le résultat d'un cast est une rvalue.
En ajoutant des parenthèses pour clarifier, on a alors deux cas:
* (unsigned char)(n++) qui n'a aucun effet sur l'opérateur lui-même, seulement la valeur retournée (normal)
* ((unsigned char)n)++ qui selon moi ne devrait pas compiler.

Note: Par contre, "opérateur unaire" n'était pas forcément le bon terme, vu que je parlais ici uniquement des pre/post inc/decrémentation. Naturellement, un '-' unaire ou une '*' n'ont pas ce problème.

Link (./1629) :
* ((unsigned char)n)++ qui selon moi ne devrait pas compiler.

tu as raison.

squalyl (./1628) :
sdcc a des int de 16 bits sur toutes ses plate formes, et le compilo ST du boulot aussi, au moins

SDCC il est bien. Après t'as des trucs un peu plus chelou où c'est juste pas le cas. Je pense au compilo de Sensory de mémoire, et encore ailleurs mais j'arrive plus à me souvenir exactement - en tous cas j'ai halluciné. Là le C n'est absolument pas fait pour faire des progs portables, mais juste pour réutiliser une partie des connaissances des codeurs.

ben alors le compilo de Sensory il sux (ça compile pour quoi ce truc que je connais pas?)

C'est pas parce que tu connais pas que ça sux Le fait est que ça existe, et c'est assez courant à ce que j'ai entendu. Mon boss qui est ingé dans l'embarqué m'avait tout de suite fusillé quand il a vu que j'osais essayer d'utiliser des 'long' qui évidemment produisaient des résultats erronés pour une simple addition suivant le contexte.
Ce truc compile pour leur µC, qui doit être un bête 8502 de mémoire (j'ai plus sous les yeux, j'y travaille plus).

enfin un compilo qui sait pas additionner deux longs, même sur un 8 bits, il sux

que ça soit interdit car lanterne, ok, mais si ça marche pas, on accuse le compilo, pas le dev

squalyl (./1628) :

GoldenCrystal (./1602) :
contrairement à UTF-8 qui peut aller jusqu'à 8 octets4 octets.

six, pour stocker jusqu'a 0xFFFFFFFF

Mais l'Unicode ne va que jusqu'à 0x10FFFF ... C'est d'ailleurs pour ça que je soutiens que l'UTF-32 est un gâchis de place énorme. Même un hypothétique UTF-24 laisserait 3 bits en plan, ça serait déjà beaucoup mieux niveau espace, mais pas performances... Bref, vive l'UTF-16

Kevin Kofler (./1618) :

To say a bit more on the topic, yes he is right -- it would make some operations much easier.

Bah oui, c'est bien pour ça que le reste du monde est passé à l'UTF-8.

Tu veux dire les 0.15% restant une fois qu'on a décompté Windows, Mac OS X (Cocoa), .NET, Java, Qt & co. ? Bon j'ai balancé le %age au pif, mais sachant que Linux = environ 1% de pdm...)
Le seul endroit où l'UTF-8 est vraiment exploité, c'est le Web (bien que l'UTF-16 soit un choix valide et autorisé). L'UTF-8 est bien pour l'échange de données, pas comme représentation interne.

(bah, il suffit de stocker d'autres choses dans les msb )

Zerosquare (./1610) :
Auquel cas, ton compilateur ne respecte pas le standard (un int doit avoir au moins 16 bits).

Non INT c'est la taille "native" du mot mémoire (celon le K&R, et le C90 si j'ai bonne mémoire) donc un CPU 8bit, int = 8 bits, etc...

Oui, mais ça n'empêche qu'il est censé faire 16 bits au minimum (j'ai vérifié dans le K&R).

Ok c'est encore pire que prévu. De toute maniere je banni "int" a vue ^^

Pareil, inttypes.h FTW !

S'il est là
Perso je définis dans mes projets perso des trucs du genre:

typedef unsigned char u8;
typedef signed char s8;
typedef unsigned short u16;
typedef signed short s16;
typedef unsigned long u32;
typedef signed long s32;

Et j'adapte suivant la plate-forme (je mets ça dans le même section que le code endian-critique). Ca permet d'avoir les ambiguïtés au niveau du signe aussi.

^^Quelle est exactement la différence entre inttypes.h et stdint.h?

Zerosquare (./1640) :
Pareil, inttypes.h FTW !

Idem pour les trucs un peu critiques ou tutoyant les limites d'un type, mais pour un compteur de boucle de 1 à 10, int est plus rapide à taper

Question d'habitude

D'où mes noms de type à 2~3 caractères ^^ u32 i; est bien plus agréable à taper que unsigned i;

\o/ GCC vient de me laisser faire:

const u32 colors[] = {
    colors[0], colors[1], colors[2], colors[3]
};

Je voulais évidemment accéder à ma propriété colors, mais il trouve rien de mieux que prendre les éléments du tableau que je suis en train d'initialiser... je pouvais bien chercher pourquoi c'était tout noir

Je me suis déjà fait avoir de la même façon... Kevin m'avait répondu que c'était pas un bug, mais je ne me rappelle plus de la justification...

Bah à ce niveau rien n'est un bug normalement, mais c'est quand même... discutable niveau conceptuel
Sinon un truc que je tombe totalement des nues c'est ça:

class Colored {
	void set(int c) {
		color = c;
	}
public:
	int color;
};

Ca compile, et ça marche. Je ne comprends ab-so-lu-ment pas pourquoi. Il fait une deuxième passe pour déjà connaître 'color' dans le corps de 'set'? Je croyais que c'était pas le cas.

Dans son bouquin, Stroustrup conseille de déclarer les attributs (et tout ce qui est privé) à la fin de la classe. Perso j'ai toujours fait comme ça.

Link (./1624) :
@Kevin: On ne peut pas toujours mettre à jour les programmes.

C'est bien pour ça que les logiciels propriétaires, ça sux! Sous GNU/Linux, on refuse par principe d'introduire des workarounds pour les applications boguées, et ça ne dérange pas tant que ça, sauf pour les quelques applications propriétaires qui n'arrêtent pas de casser. Quand il y a un problème avec un logiciel libre, quelqu'un le corrige et pouf, il n'y a plus de problème!

GoldenCrystal (./1635) :
Tu veux dire les 0.15% restant une fois qu'on a décompté Windows, Mac OS X (Cocoa), .NET, Java, Qt & co. ?

OS X utilise des locales UTF-8 par défaut, tout comme GNU/Linux etc. Maintenant, il y a des toolkits qui utilisent l'UTF-16 par dessus, mais le codage système, et le codage utilisé partout où on a besoin d'un codage "8 bits" (c'est-à-dire compatible ASCII), c'est l'UTF-8. Il n'y a vraiment qu'un seul système qui persiste à utiliser des codepages 8 bits obsolètes et à essayer de forcer tout le monde de passer à l'UTF-16 pour gérer le Unicode, même quand ça implique d'être incompatible avec les APIs existantes et portables parce qu'elles travaillent avec des chaînes de caractères 8 bits (pratiquement toutes les APIs C, par exemple).

Zerosquare (./1638) :
Oui, mais ça n'empêche qu'il est censé faire 16 bits au minimum (j'ai vérifié dans le K&R).

Le K&R n'est pas un document normatif. Mais ton affirmation est correcte d'après 6.2.5 §5 et 5.2.4.2.1 §1 (11^ème et 12^ème énumérés) du standard ISO C99 (cf. le document n1256.pdf WG14/N1256 ISO/IEC 9899:TC3 téléchargeable gratuitement) qui garantissent que int doit pouvoir représenter au moins l'ensemble [-32767,32767] ∩ ℤ. (Je signale cependant que -32768 n'est pas garanti être représentable dans un int, parce que la représentation "complément de 2" n'est pas obligatoire.)

Link (./1642) :
^^Quelle est exactement la différence entre inttypes.h et stdint.h?

inttypes.h inclut stdint.h et rajoute des trucs en plus.

Brunni (./1646) :
\o/ GCC vient de me laisser faire:

const u32 colors[] = {
    colors[0], colors[1], colors[2], colors[3]
};

Je voulais évidemment accéder à ma propriété colors, mais il trouve rien de mieux que prendre les éléments du tableau que je suis en train d'initialiser... je pouvais bien chercher pourquoi c'était tout noir

Zerosquare (./1647) :
Je me suis déjà fait avoir de la même façon... Kevin m'avait répondu que c'était pas un bug, mais je ne me rappelle plus de la justification...

C'est parce que int x=x; est la manière proposée par GCC pour supprimer les warnings au sujet des variables non initialisées (quand il y a un faux positif).

Brunni (./1648) :
Il fait une deuxième passe pour déjà connaître 'color' dans le corps de 'set'? Je croyais que c'était pas le cas.

Contrairement au C, le C++ n'est pas un langage parsable en une seule passe linéaire.