 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Philip K Dick
Guest
|
 Posted: Mon Apr 30, 2007 9:12 am Post subject: Encodage C++/Java/Big-little Endian |
 |
|
Hello
Je cherche des solutions pour encoder/décoder
des structures de données que je puisse échanger
entre des programmes Java et C++.
Qui plus est, je souhaiterais :
- que les programmes puissent tourner indifféremment
sur des machines à représentation big ou little endian
- que l'encodage soit le plus compact possible car
destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de
type CORBA ou DCOM).
Merci d'avance pour toute piste !
PKD |
|
| Back to top |
|
 |
Mathias Gaunard
Guest
|
| Posted: Mon Apr 30, 2007 4:59 pm Post subject: Re: Encodage C++/Java/Big-little Endian |
|
|
Philip K Dick a écrit :
| Quote: | Je cherche des solutions pour encoder/décoder
des structures de données que je puisse échanger
entre des programmes Java et C++.
|
1) Choisis un format bien défini pour tes données d'échange
2) Tiens-toi à ce format quand tu les écris et les relis
Et voilà. |
|
| Back to top |
|
|
Bruno Causse
Guest
|
| Posted: Mon Apr 30, 2007 5:36 pm Post subject: Re: Encodage C++/Java/Big-little Endian |
|
|
| Quote: | Philip K Dick a écrit :
Je cherche des solutions pour encoder/décoder
des structures de données que je puisse échanger
entre des programmes Java et C++.
|
portable entre java/c++/big and little-Endian == du texte (comme toujours) |
|
| Back to top |
|
|
Mathias Gaunard
Guest
|
| Posted: Mon Apr 30, 2007 6:22 pm Post subject: Re: Encodage C++/Java/Big-little Endian |
|
|
Bruno Causse a écrit :
| Quote: | portable entre java/c++/big and little-Endian == du texte (comme toujours)
|
Pas forcément.
On peut tout à fait avoir des données binaires portables.
La seule chose pour que ce soit portable c'est que le format doit être
bien défini et ne pas dépendre de la machine utilisée pour lire et écrire.
L'intérêt du texte, c'est qu'il peut représenter certaines choses non
représentables autrement, et qu'il est plus facilement modifiable à la main. |
|
| Back to top |
|
|
Stan
Guest
|
| Posted: Mon Apr 30, 2007 8:01 pm Post subject: Re: Encodage C++/Java/Big-little Endian |
|
|
"Mathias Gaunard" <loufoque (AT) gmail (DOT) com> a écrit dans le message de
news:4635ed91$0$25806$426a34cc (AT) news (DOT) free.fr...
| Quote: | L'intérêt du texte, c'est qu'il peut représenter certaines choses non
représentables autrement, et qu'il est plus facilement modifiable à la
main. |
Un exemple de ce qui est représentable en texte et pas autrement ?
--
-Stan |
|
| Back to top |
|
|
Sylvain Togni
Guest
|
| Posted: Mon Apr 30, 2007 8:18 pm Post subject: Re: Encodage C++/Java/Big-little Endian |
|
|
Stan wrote:
| Quote: | Un exemple de ce qui est représentable en texte et pas autrement ?
|
Du texte !
--
Sylvain Togni |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Tue May 01, 2007 9:11 am Post subject: Re: Encodage C++/Java/Big-little Endian |
|
|
On Apr 30, 9:40 am, Philip K Dick <philip.k.d...@tele2.fr> wrote:
| Quote: | Je cherche des solutions pour encoder/décoder
des structures de données que je puisse échanger
entre des programmes Java et C++.
Qui plus est, je souhaiterais :
- que les programmes puissent tourner indifféremment
sur des machines à représentation big ou little endian
- que l'encodage soit le plus compact possible car
destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de
type CORBA ou DCOM).
|
Pourquoi pas utiliser le format de sérialisation Java tout
court ? Il semble bien spécifié, et tu en as accès directement
en Java.
Sinon, je régarderais dans la direction de XDR ; c'est le
format binaire le plus compact que je connais, et c'est assez
facile à implémenter SI tu te réstreins à des machines ayant des
multiplets de huit bits, représentation signée complément à deux
pour les entiers, et format IEEE pour les flottants. (Prèsque
toutes les machines courantes remplissent les deux premières
conditions, et les PC et les systèmes Unix courants utilisent le
plus souvent IEEE aussi.)
--
--
James Kanze (Gabi Software) email: james.kanze (AT) gmail (DOT) com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Tue May 01, 2007 9:12 am Post subject: Re: Encodage C++/Java/Big-little Endian |
|
|
On Apr 30, 3:22 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
| Quote: | Bruno Causse a écrit :
portable entre java/c++/big and little-Endian == du texte
(comme toujours)
Pas forcément.
On peut tout à fait avoir des données binaires portables.
La seule chose pour que ce soit portable c'est que le format doit être
bien défini et ne pas dépendre de la machine utilisée pour lire et écrire.
|
Tout à fait. XDR ou BER, par exemple. On peut toujours définir
son propre format, mais AMHA, ce n'est pas la peine.
| Quote: | L'intérêt du texte, c'est qu'il peut représenter certaines
choses non représentables autrement, et qu'il est plus
facilement modifiable à la main.
|
Ce qu'on peut représenter est, en fin de compte, pûrement une
fonction du nombre de bits d'information disponible. Un format
texte a typiquement beaucoup de rédondance, c-à-d qu'il faut
plus de bits physiques pour représenter la même quantité de bits
d'information réele (mais ce n'est pas toujours le cas, et les
formats binaires ont souvent de la rédondance aussi). L'avantage
du format texte, c'est que tu peux le lire directement, ce qui
facilite la mise au point énormement. Et selon les types de
données, il ne faut pas toujours beaucoup plus de bits.
--
James Kanze (Gabi Software) email: james.kanze (AT) gmail (DOT) com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 |
|
| Back to top |
|
|
Mathias Gaunard
Guest
|
| Posted: Tue May 01, 2007 4:19 pm Post subject: Re: Encodage C++/Java/Big-little Endian |
|
|
Stan a écrit :
| Quote: | Un exemple de ce qui est représentable en texte et pas autrement ?
|
Un nombre décimal par exemple, sera plus précis en texte que sous forme
de flottant. |
|
| Back to top |
|
|
Fabien LE LEZ
Guest
|
| Posted: Tue May 01, 2007 4:54 pm Post subject: Re: Encodage C++/Java/Big-little Endian |
|
|
On Tue, 01 May 2007 13:19:34 +0200, Mathias Gaunard
<loufoque (AT) gmail (DOT) com>:
| Quote: | Un exemple de ce qui est représentable en texte et pas autrement ?
Un nombre décimal par exemple, sera plus précis en texte que sous forme
de flottant.
|
Si tu veux représenter un flottant machine (float ou double), le
format binaire (i.e. copie directe depuis la RAM) gardera toutes les
informations, sans aucune perte. Une conversion en décimal, au
contraire, perdra des informations la plupart du temps, même s'il y a
cent chiffres décimaux.
Et on peut dire la même chose d'un flottant codé en RAM sur
1000 bits : une copie des octets de la RAM vers le disque garantit
l'absence de perte, donc une précision aussi parfaite que possible.
Certes, on peut représenter un nombre décimal sous forme de texte,
mais on ne pourra pas le charger dans un flottant.
Par ailleurs, on peut représenter le même nombre en base 100, ce qui
permet de le stocker avec deux fois moins d'octets, mais dans un
format non lisible par un humain. |
|
| Back to top |
|
|
Jean-Marc Bourguet
Guest
|
|
| Back to top |
|
|
Dominique Vaufreydaz
Guest
|
| Posted: Tue May 01, 2007 8:46 pm Post subject: Re: Encodage C++/Java/Big-little Endian |
|
|
Bonjour,
| Quote: | Un exemple de ce qui est représentable en texte et pas autrement ?
Du texte !
|
Le texte est une suite de caractere ascii, et c'est du binaire ! C'est
dans un ordinateur donc c'est binaire ou on m'aurait menti ;-P
Doms. |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Wed May 02, 2007 9:12 am Post subject: Re: Encodage C++/Java/Big-little Endian |
|
|
On May 1, 1:54 pm, Fabien LE LEZ <grams...@gramster.com> wrote:
| Quote: | On Tue, 01 May 2007 13:19:34 +0200, Mathias Gaunard
loufo...@gmail.com>:
Un exemple de ce qui est représentable en texte et pas autrement ?
Un nombre décimal par exemple, sera plus précis en texte que sous forme
de flottant.
Si tu veux représenter un flottant machine (float ou double), le
format binaire (i.e. copie directe depuis la RAM) gardera toutes les
informations, sans aucune perte. Une conversion en décimal, au
contraire, perdra des informations la plupart du temps, même s'il y a
cent chiffres décimaux.
|
Pas forcément, mais d'abord, il faudrait définir ce qu'on entend
par « perdre des informations ». Toute valeur représentable
dans un double IEEE peut se représenter exactement comme
fraction décimale, avec au maximum 52 chiffres. Si dans le
contexte, en revanche, on s'ait qu'il s'agit d'un double IEEE,
et non simplement d'un réel quelconque, 17 chiffres décimaux
suffissent pour savoir sans ambiguité lequel (et donc, de les
transmettre sans perte d'information).
Enfin, d'autres formats, sont possible. On pourrait, par
exemple, transmettre la mantisse multiplié par 2^52 (ce qui en
fait un entier, représentable exactment), avec la signe et
l'exposant. Voire simplement un dump des 8 octets, en
hexadécimal (16 caractères totaux) ou base-64 (12 caractères).
| Quote: | Et on peut dire la même chose d'un flottant codé en RAM sur
1000 bits : une copie des octets de la RAM vers le disque garantit
l'absence de perte, donc une précision aussi parfaite que possible.
Certes, on peut représenter un nombre décimal sous forme de texte,
mais on ne pourra pas le charger dans un flottant.
Par ailleurs, on peut représenter le même nombre en base 100, ce qui
permet de le stocker avec deux fois moins d'octets, mais dans un
format non lisible par un humain.
|
Base 100 est la solution adoptée souvent quand la spécification
exige BCD packé, et que le hardware ne le supporte pas. Ce n'est
pas trop difficile d'écrire une classe qui se comporte comme si
c'était du BCD, mais qui internalement travaille en base 100.
(Si mes souvenirs sont exacts -- ma ça date -- le format
« portable » des flottants en CISAM était base 100.)
--
James Kanze (GABI Software) email:james.kanze (AT) gmail (DOT) com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 |
|
| Back to top |
|
|
Fabien LE LEZ
Guest
|
| Posted: Wed May 02, 2007 9:12 am Post subject: Re: Encodage C++/Java/Big-little Endian |
|
|
On 1 May 2007 23:54:43 -0700, James Kanze <james.kanze (AT) gmail (DOT) com>:
| Quote: | Toute valeur représentable
dans un double IEEE peut se représenter exactement comme
fraction décimale, avec au maximum 52 chiffres.
|
Oups, oui, effectivement... J'avais oublié que 2 divise 10 :-/ |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Wed May 02, 2007 9:12 am Post subject: Re: Encodage C++/Java/Big-little Endian |
|
|
On May 2, 6:23 am, Loïc Joly <loic.actarus.j...@numericable.fr> wrote:
| Quote: | James Kanze a écrit :
Un format
texte a typiquement beaucoup de rédondance, c-à-d qu'il faut
plus de bits physiques pour représenter la même quantité de bits
d'information réele (mais ce n'est pas toujours le cas, et les
formats binaires ont souvent de la rédondance aussi).
On a effectivement eu le cas d'un fichier qui contenait des doubles,
dont la majorité valait 0. Et bien la sauvegarde en format texte prenait
beaucoup moins de place qu'en format binaire.
|
Et un format binaire sur mesure aurait peut-être pris encore
moins de place. (Disons, un bool « isZero », suivi du flottant
en binaire seulement dans le cas de faux.) De même, si tu avais
systèmatiquement formatté chacun des doubles en format
scientifique, avec 16 chiffres derrière le décimal, le format
texte n'aurait pas été plus court.
En général, si les valeurs ne sont pas réparties d'une façon un
peu aléatoire, on a souvent intérêt à adopter un format à
longueur variable. Un format texte qui ne sort pas les '0' sans
signification, par exemple. Ou le format des entiers à longueur
variable de BER : 7 bits par octets, avec le bit de poids forts
comme drappeau de fin. (On n'a donc besoin que d'un octet pour
des valeurs de 0 a 127, mais on peut également représenter
toutes les valeurs possibles. C'est une bonne solution, par
exemple, pour la longueur d'une chaîne de texte, où on a très
souvent des valeurs inférieur à 127, mais où on pourrait, à
l'occasion, avoir des valeurs très élevées.)
--
James Kanze (GABI Software) email:james.kanze (AT) gmail (DOT) com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 |
|
| Back to top |
|
|
Powered by phpBB © 2001, 2006 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
