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).
Un exemple de ce qui est représentable en texte et pas autrement ?
Du texte !
-- Sylvain Togni
James Kanze
On Apr 30, 9:40 am, Philip K Dick wrote:
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: 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
On Apr 30, 9:40 am, Philip K Dick <philip.k.d...@tele2.fr> wrote:
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@gmail.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
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: 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
James Kanze
On Apr 30, 3:22 pm, Mathias Gaunard wrote:
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.
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: 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
On Apr 30, 3:22 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
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.
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@gmail.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
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.
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: 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
Mathias Gaunard
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.
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.
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.
Fabien LE LEZ
On Tue, 01 May 2007 13:19:34 +0200, Mathias Gaunard :
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.
On Tue, 01 May 2007 13:19:34 +0200, Mathias Gaunard
<loufoque@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.
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.
On Tue, 01 May 2007 13:19:34 +0200, Mathias Gaunard :
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.
Jean-Marc Bourguet
Mathias Gaunard writes:
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.
Et une représentation BCD, Densely Packed Decimal, Chen-Ho est tout aussi précise et plus dense.
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.
Et une représentation BCD, Densely Packed Decimal, Chen-Ho est tout aussi
précise et plus dense.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org