Discussion :

[pseudocode]

1 caractère = 1 byte = 1 char (si vous préférez qu'on dise les choses ainsi ^^)

Non. il y a un glissement sémantique ici entre caractère (entité) et byte/char (représentation).

Un caractère ASCII-7 bits est stockable sur 1 byte, ou sur 1 char (bref sur un type de 8 bits). Un caractère ASCII-8 bits également. Et un caractère UTF8 8 bits aussi. Et aussi un entier entre 0 et 255. Ou une entier entre -128 et +127.

Pourtant tous ces types ne sont pas égaux entre eux, et donc pas interchangeables.

Assimiler chaine de caractère et tableau de byte/char est un raccourci technique valable en C (seulement dans certaines conditions) parce qu'il n'existe pas de frontière sémantique entre l'entité et sa représentation interne.

Mais c'est nettement moins le cas dans des langages objets qui existent précisément pour "capturer" la sémantique de l'entité et la séparer de sa représentation.

En objet (et donc en C++ objet), un itérateur sur une instance de chaine de caractère renvoie une instance de caractère. Alors qu'un itérateur sur une instance de tableau d'octet renvoie une instance d'octet. Gommer la différence sémantique en sachant (ou supposant) qu'ils utilisent la même représentation interne est un gros risque.

[alexis b]

Justement, memcpy ne travaille qu'au niveau de la mémoire, sur des... bytes.

C'est, justement, ce que gl essaye de mettre en évidence: si memcpy et str(n)cpy existent tous les deux, ce n'est pas pour faire joli, ni pour avoir le plaisir de se compliquer la vie en devant choisir l'une des deux

Je pense que vous devriez relire la discussion, j'ai clairement indiqué la fonction memcpy comme étant la fonction adéquate pour les tableaux de bytes...

un byte dont la valeur est 0, qui peut être une valeur tout à fait valide et non différente de 1 ou de 251.

0 = 1 = 251 ?

[koala01]

0 = 1 = 251 ?

Au temps pour moi... j'aurais du dire "à l'instar de 1 ou de 251"...

Bref, une valeur numérique tout à fait "classique"

[Luc Hermitte]

1 char = 1 byte . Donc utiliser le type char pour les tableau de bytes est tout à fait normal...

Mais pas un octet que je m'attends à aller de 0 à 255. A cause du signe.
Quand on veut stocker nos octets dans des chars, il faut rapidement jongler avec des reinterpret_cast pour afficher des valeurs hexa entre 0x00 et 0xff, ou simplement manipuler des octets variant entre 0 et 255.
Soit le code que Pierre Dolez nous avait initialement montré.

Si je ne m'abuse, j'avais signalé que je voyais une maladresse dans la mesure où l'on cherchait à afficher des chaines (stockant des séquences de char) en version hexa, alors qu'au fond dans notre tête on manipule des séquences d'unsigned char. Maladresse sémantique qui introduit ensuite une complexité dans le code

Code qui est déjà suffisamment verbeux comme ça grâce aux streams (pour passer en 2 caractères hexa). C'est sûr que la version printf du C est plus légère, mais au prix de code non DRY (on répète le type) et non sécurisé (on a vite fait de balancer une variable de type incompatible, voire non-POD (comme une string)). J'ai là une préférence pour des choses comme boost::format.

[alexis b]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
unsigned char Chaine[128];
strcpy(Chaine,MBR.c_str());
for (unsigned char *c=Chaine; c; c++) printf("%2x ",c);
printf("\n");

strcpy ne peut pas prendre une variable de type unsigned char [] (il faudrait la déclarer comme étant de type char []). De toute façon, il est inutile de faire une copie. A noter aussi que 'c' est un pointeur .

En tant que grand professionnel, je vous donne le corrigé .

for (const char *c = MBR.c_str();*c; c++) printf("%2x ",(unsigned char) *c);
printf("\n");

Alors, c'est qui le maitre du C++ ? Enfin c'est presque du C en l'occurence .

[pseudocode]

Alors, c'est qui le maitre du C++ ? Enfin c'est presque du C en l'occurence .

C'est même complètement du C, pour preuve l'utilisation de c_str().

[Invité]

Bonjour Alexis_b
Je pense que si on veut compresser le code, ce serait plutôt cela,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for (unsigned char *c = (void*)MBR.c_str(); c; c++) printf("%2x ", c);

Mais, j'avoue n'avoir essayé ni l'un ni l'autre.

Ceci dit, je suis réellement en admiration. Si je résume bien ce que j'ai compris " un byte et un char, pour la machine c'est la même chose, mais puisque ça peut ne pas représenter la même chose on va les traiter différemment, tant pis si ça rend les programmes complètement indigestes et illisibles."
A plusieurs reprises le terme "comprendre" a été employé. Habituellement, je comprends assez facilement, mais j'avoue que j'ai vu beaucoup plus d'affirmations que d'explications, et en tout cas jamais d'exemple.
Bonne journée.

[pseudocode]

Ceci dit, je suis réellement en admiration. Si je résume bien ce que j'ai compris " un byte et un char, pour la machine c'est la même chose, mais puisque ça peut ne pas représenter la même chose on va les traiter différemment, tant pis si ça rend les programmes complètement indigestes et illisibles."
A plusieurs reprises le terme "comprendre" a été employé. Habituellement, je comprend assez facilement, mais j'avoue que j'ai vu beaucoup plus d'affirmations que d'explications, et en tout cas jamais d'exemple.
Bonne journée.

Le raisonnement est inverse : "Vu que ca ne représente pas la même chose, on ne va pas utiliser le même type (byte, char ou objet)"

Les caractères d'une chaine de texte :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
String s;
foreach ( Character c : s ) printf("%2x ", c.getAsciiCode() );

(je sais, il n'y a pas encore de foreach en C++. C'est pour l'exemple )

Les octets d'un tableau d'octets

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
byte[] array;
int length;
for(int i=0; i<length; i++) printf("%2x ", array[i] );

Les éléments d'une chaine de char à zéro terminal

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
char[] str
char *ptr;
for(char *ptr = &str[0]; (*ptr)!=0; ptr++) printf("%2x ", *ptr );

[alexis b]

C'est même complètement du C, pour preuve l'utilisation de c_str().

Non justement, c_str() est une fonction du C++ (elle fait même partie de la classe string), donc elle prouve l'inverse .

Bonjour Alexis_b
Je pense que si on veut compresser le code, ce serait plutôt cela,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for (unsigned char *c = (void*)MBR.c_str(); c; c++) printf("%2x ", c);

Il y a encore quelques erreurs (et je crois que mon code est incompressable ). Aller je te mets quand même 8 / 10 ^^

A plusieurs reprises le terme "comprendre" a été employé. Habituellement, je comprend assez facilement, mais j'avoue que j'ai vu beaucoup plus d'affirmations que d'explications, et en tout cas jamais d'exemple.
Bonne journée.

A toi aussi .

[atttchoum]

Non justement, c_str() est une fonction du C++ (elle fait même partie de la classe string), donc elle prouve l'inverse .

c_str() te permet d'utiliser une chaine de caractères "à la sauce C".
Ça montre généralement que tu vas faire du C.

[alexis b]

c_str() te permet d'utiliser une chaine de caractères "à la sauce C".
Ça montre généralement que tu vas faire du C.

Essaye de compiler le code avec un compilateur C, ça pourra pas fonctionner . CQFD

[Davidbrcz]

Essaye de compiler le code avec un compilateur C, ça pourra pas fonctionner . CQFD

On est d'accord, c'est du C++ SAUF qu'elle existe pour fournir un acces en lecture vers l'implementation interne de la chaine (un char*) souvent dans le but de pouvoir utiliser des fonctions qui attendent des char* qui sont (a moins de tomber sur un fou qui utilise ca en C++) tirees du C.

[alexis b]

On est d'accord, c'est du C++

Très bien .

SAUF qu'elle existe pour fournir un acces en lecture vers l'implementation interne de la chaine (un char*) souvent dans le but de pouvoir utiliser des fonctions qui attendent des char* qui sont (a moins de tomber sur un fou qui utilise ca en C++) tirees du C.

Je n'ai jamais dit le contraire ^^

PS : bien que rien n'empêche d'utiliser le type char (même en C++) dans des algorithmes qui nécessiterait d'être très optimisés.

[pseudocode]

Je n'ai jamais dit le contraire ^^

PS : bien que rien n'empêche d'utiliser le type char (même en C++) dans des algorithmes qui nécessiterait d'être très optimisés.

Bah c'est possible, mais ca participe au mélange des genres que je trouve critiquable. Je préfèrerai que le code "pur C" soit clairement dissocié du reste, par exemple avec des marques de bloc, comme pour l'assembleur.

[alexis b]

Bah c'est possible, mais ca participe au mélange des genres que je trouve critiquable. Je préfèrerai que le code "pur C" soit clairement dissocié du reste, par exemple avec des marques de bloc, comme pour l'assembleur.

Il est possible de faire des algorithmes très optimisés en utilisant les char, sans passer par la moindre fonction lorsque l'on utilise ces valeurs (donc on n'a pas besoin d'utiliser les fonctions propres au langage c).

Dans ces conditions, le type char faisant partie intégrante du C++, cela me semble tout à fait normal .

[pseudocode]

Il est possible de faire des algorithmes très optimisés en utilisant les char, sans passer par la moindre fonction lorsque l'on utilise ces valeurs (donc on n'a pas besoin d'utiliser les fonctions propres au langage c).

Dans ces conditions, le type char faisant partie intégrante du C++, cela me semble tout à fait normal .

Le type "char" je dis pas. Mais la post-incrémentation du pointeur (et son possible dépassement de la zone mémoire) c'est pas très C++ Objet.

[Luc Hermitte]

Un pointeur est un itérateur trivial. C'est très C++ aussi.

[pseudocode]

Un pointeur est un itérateur trivial. C'est très C++ aussi.

Bah, c'est un type natif, comme 'int' ou 'char' et donc pas une instance d'objet.

Pourtant ils sert (ou peut servir) à accéder à un objet, ce que ne peuvent pas faire les autres types natifs. C'est donc assez hybride je trouve.

[Luc Hermitte]

Et ? Toute la bibliothèque standard du C++ repose sur le principe que OO n'est pas une finalité.

[pseudocode]

Et ? Toute la bibliothèque standard du C++ repose sur le principe que OO n'est pas une finalité.

hum...

Pour moi la STL est surtout basée des concepts de modélisation et, pour le cas qui nous intéresse ici, le Input Iterator.

Toujours dans ma vision des choses, en C++/STL le type "char*" est un itérateur sur le type natif 'char'. Alors qu'en C c'est un pointeur sur une zone mémoire contenant un 'char'.

Si, au final, l'implémentation est la meme, pour moi ce n'est pas la meme sémantique. En C, la valeur du pointeur à une signification (= c'est une adresse mémoire), alors qu'en C++ il n'a pas besoin d'en avoir : tout ce qui compte c'est que ce type permette de faire une itération.

D'ailleurs, bien que dans l'exemple ces deux types sont utilisés pour faire une itération, plusieurs personnes ici semblent voir une différence conceptuelle entre un "char*" et un "vecteur de char".