Discussion :

[d.draper]

Bonjour à tous !
Malgré mes recherches, je suis toujours bloqué.

En fait, je ne sais pas comment mettre les octets d'un fichier quelconque dans une variable string.
Oublions la méthode d'un tableau de char, car traduire des caractères en octets selon la langue utilisée ne me parait
pas judicieux (portabilité, endianess, etc).


Bref, existe-t-il une classe, une fonction ou quoi que ce soit en c++ qui permet de mettre le contenu binaire ("0 et 1")
d'un fichier dans une variable string (sans passer par du texte)? Et dans les autres langages de programmation?Est-ce
possible en java?


Si vous avez un bout de code expliqué,
une fonction ou quoi que ce soit, je prends!!!!




Merci d'avance pour vos réponses pédagogiques !

[coyotte507]

Les tableaux de char ne sont jamais que des tableaux d'entier à 8 bits, sous 256 valeurs, c'est à dire des octets. C'est quand on affiche un char sous forme texte qu'un quelconque problème d'affichage apparait, mais si tu l'affiches sous forme d'entier tu auras bien le bon résultat.

Si tu as un fichiers, tu as une série d'octets dedans, et que tu les mettes dans un tableau de char ou un string, c'est la même chose.

Que cherche-tu exactement à faire au final avec les octets récupérés, peut-être que ça nous aidera à voir comment on peut t'aider?

[koala01]

Bonjour à tous !
Malgrès mes recherches, je suis toujours bloqué.

En fait, je ne sais pas comment mettre les octets d'un fichier quelconque dans une variable string.
Oublions la méthode d'un tableau de char, car traduire des caractères en octets selon la langue utilsée ne me parait
pas judicieux (portabilité, endianess, etc).

normalement, tu n'as pas de problème d'endianess avec les char, pour la simple et bonne raison qu'ils correspondent à ... un byte, (sauf si tu pars sur des caractères unicode !).

L'endianess n'intervient en effet que lorsqu'il faut utiliser plusieurs bytes pour représenter une valeur donnée, et ce n'est absolument pas tous les bits qui sont inversé, mais simplement l'ordre dans lequel les différents bytes sont écrits

Ceci dit, le meilleur moyen de transmettre des chaines de manière tout à fait portable est encore... d'abandonner les fichiers dits "binaires" au profit de fichiers "texte", pourquoi pas, en les formatant en XML

Car, dés le moment où tu envisage d'utiliser un fichier dit "binaire", si tu veux assurer la compatibilité, il faut impérativement prendre soin de préciser l'endianess utilisée pour l'écriture, vérifier celle-ci au début du traitement et, si besoin est, veiller à convertir les valeurs à coup de hton* ou de ntoh*

(du moins, pour tout type de taille supérieure à un byte )

[Emmanuel Deloget]

normalement, tu n'as pas de problème d'endianess avec les char, pour la simple et bonne raison qu'ils correspondent à ... un byte, (sauf si tu pars sur des caractères unicode !).

Ca pourrait être vrai si le byte dont du parles faisait un octet Ce n'est pas à toi que je vais l'apprendre, mais la norme ne spécifie pas la taille d'un byte - celle-ci est laissée à l'appréciation du vendeur de compilateur. Vu le codage ascii courant, je pense qu'une implémentation pourrait fixer que cette taille est au minimum de 7 bits (c'est suffisant, il me semble, pour stocker l'intégralité du source code character set ; mais ça devrait être vérifié).Par contre, rien n'interdit que le byte fasse 32 bits (avec toujours sizeof(char) == 1) pour des raisons d'optimisation sur une architecture ne supportant pas les lectures non-alignées. Du coup, le probleme de l'endianness se poserait.

Un bémol toutefois : les développeurs ne programment que rarement avec le standard à l'esprit, et du coup, nombreux sont ceux qui considèrent que sizeof(char) = 1 byte = 1 octet. Même si cette relation est fausse, elles est supposée dans tant de programme qu'il y a peu de chance de voir un jour une architecture répandue (ARM, MIPS, x86 ou ia64, pour n'en citer que quelques unes) passer autre chose.

[koala01]

Ca pourrait être vrai si le byte dont du parles faisait un octet Ce n'est pas à toi que je vais l'apprendre, mais la norme ne spécifie pas la taille d'un byte - celle-ci est laissée à l'appréciation du vendeur de compilateur. Vu le codage ascii courant, je pense qu'une implémentation pourrait fixer que cette taille est au minimum de 7 bits (c'est suffisant, il me semble, pour stocker l'intégralité du source code character set ; mais ça devrait être vérifié).Par contre, rien n'interdit que le byte fasse 32 bits (avec toujours sizeof(char) == 1) pour des raisons d'optimisation sur une architecture ne supportant pas les lectures non-alignées. Du coup, le probleme de l'endianness se poserait.

Un bémol toutefois : les développeurs ne programment que rarement avec le standard à l'esprit, et du coup, nombreux sont ceux qui considèrent que sizeof(char) = 1 byte = 1 octet. Même si cette relation est fausse, elles est supposée dans tant de programme qu'il y a peu de chance de voir un jour une architecture répandue (ARM, MIPS, x86 ou ia64, pour n'en citer que quelques unes) passer autre chose.

tu ergotes, mais tu as raison... J'aurais du préciser "pour une architecture donnée

Par contre, sizeof(char) est clairement défini dans la norme comme valant 1

Maintenant, il est vrai qu'avant l’avènement des "PC", il était tout à fait possible de trouver des architecture basées sur 6bits == 1 byte

[oodini]

Par contre, sizeof(char) est clairement défini dans la norme comme valant 1

Oui, mais 1 byte ou 1 octet ? :-)

Wikipedia nous éclaire un peu plus.

[koala01]

Oui, mais 1 byte ou 1 octet ? :-)

1 byte, qui, dans les architetures actuelles "classiques" est, justement composé de 8 bits (et qui est donc dans les faits égal à un octet dans les architectures classiques actuelles )

[Emmanuel Deloget]

[quote=koala01;6253310]tu ergotes/QUOTE]

Point je n'oserais !

Oui, mais 1 byte ou 1 octet ? :-)

Wikipedia nous éclaire un peu plus.

L'unité de taille définie par le standard C++ est le byte. Mais le nombre de bits dans un byte n'est pas précisé dans le standard C++, de sorte qu'il est tout à fait possible d'avoir des bytes de 32 bits pour des questions d'optimisation.

Ce qui me rappelle un problème marrant : comment convertir une valeur d'un type scalaire connu (char, int, short, ...) en une chaîne binaire en restant dans les clous du standard ? (tous les bits doivent être représentés).

Exemple, ou sizeof(short) == 2 et le nombre de bits d'un byte == 8 :

Code :

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

1
2
3
4
5
 
short v = 0x6666;
std::string b = to_bits(v);
std::cout << b << std::endl;
// écrit 0101010101010101

En gros, écrivez template <class ScalarType> to_bits(ScalarType scalar)

Il y a un piège

[Médinoc]

La norme n'exige-t-elle pas qu'un byte fasse au moins 8 bits en C++?

PS: Pour moi, données brutes ou texte, il faut choisir: Soit tu formates tes données binaires sous une forme de texte (Hexadécimal, base64 etc.), soit tu utilises des std::vector< char > plutôt que des std::string. Même si tes char font plus de 8 bits, ça ne changera pas grand-chose en fin de compte puisque tu ne pourras pas lire plus petit.

[Emmanuel Deloget]

La norme n'exige-t-elle pas qu'un byte fasse au moins 8 bits en C++?

Non, un byte doit être de taille suffisante pour permettre l'encodage du basic execution character set (BECS, 1.7$1). Le BECS est composé du basic source character set (BSCS) (96 caractères) + NUL + ALERT + BACKSPACE (2.2§1 + 2.2$3). Du coup, seuls 99 caractères sont nécessaires, ce qui peut se coder sur 7 bits.

Note que le BSCS peut être implémenté d'une manière quelconque, à condition qu'elle soit documentée par le vendeur de compilateur. La correlation avec ASCII n'est pas éxigée, car le BSCS n'est pas le set de caractère avec lequel le code source est encodé, mais bien l'ensemble des caractères qui sont nécessaire à l'écriture de ce code source.

Je sais, c'est tordu.

[Médinoc]

Alors c'est seulement la norme C qui dit que CHAR_BIT >= 8?
(Livre de l'Environnement, Chapitre 5.2.4, verset 5.2.4.2.1)

Edit: Apparemment. Je viens de parcourir n3290.pdf, j'ai vu le nom des constantes mais pas de valeurs minimales listées.
Je crois que cela fait un point de plus à ajouter à la liste des preuves que C++ n'est pas un "superset du C".