je suis a la recherche d'aide sur l'utilisation de endian.h avec
config.h dans le but de convertir des fichier compilés sous unix
solaris en BIG-ENDIAN en fichier LITTLE-ENDIAN.
je suis a la recherche d'aide sur l'utilisation de endian.h avec
config.h dans le but de convertir des fichier compilés sous unix
solaris en BIG-ENDIAN en fichier LITTLE-ENDIAN.
je suis a la recherche d'aide sur l'utilisation de endian.h avec
config.h dans le but de convertir des fichier compilés sous unix
solaris en BIG-ENDIAN en fichier LITTLE-ENDIAN.
"hicham" wrote in message
news:<bdp1um$92s$...je suis a la recherche d'aide sur l'utilisation de endian.h avec
config.h dans le but de convertir des fichier compilés sous unix
solaris en BIG-ENDIAN en fichier LITTLE-ENDIAN.
Ce
qu'il faut, c'est définir complétement le format du fichier (comment
reconnaître si les octets qui suivent sont un entier binaire à quatre
octet ou une chaîne de caractères, par exemple), et puis écire du code
pour le lire et l'écrire de façon portable -- et on n'a pas besoin de
connaître l'architecture du hardware pour faire ça.
"hicham" <t.hicham@netcourrier.com> wrote in message
news:<bdp1um$92s$1@omega.u-picardie.fr>...
je suis a la recherche d'aide sur l'utilisation de endian.h avec
config.h dans le but de convertir des fichier compilés sous unix
solaris en BIG-ENDIAN en fichier LITTLE-ENDIAN.
Ce
qu'il faut, c'est définir complétement le format du fichier (comment
reconnaître si les octets qui suivent sont un entier binaire à quatre
octet ou une chaîne de caractères, par exemple), et puis écire du code
pour le lire et l'écrire de façon portable -- et on n'a pas besoin de
connaître l'architecture du hardware pour faire ça.
"hicham" wrote in message
news:<bdp1um$92s$...je suis a la recherche d'aide sur l'utilisation de endian.h avec
config.h dans le but de convertir des fichier compilés sous unix
solaris en BIG-ENDIAN en fichier LITTLE-ENDIAN.
Ce
qu'il faut, c'est définir complétement le format du fichier (comment
reconnaître si les octets qui suivent sont un entier binaire à quatre
octet ou une chaîne de caractères, par exemple), et puis écire du code
pour le lire et l'écrire de façon portable -- et on n'a pas besoin de
connaître l'architecture du hardware pour faire ça.
wrote:"hicham" wrote in message
news:<bdp1um$92s$...je suis a la recherche d'aide sur l'utilisation de endian.h avec
config.h dans le but de convertir des fichier compilés sous unix
solaris en BIG-ENDIAN en fichier LITTLE-ENDIAN.
Ce qu'il faut, c'est définir complétement le format du fichier
(comment reconnaître si les octets qui suivent sont un entier
binaire à quatre octet ou une chaîne de caractères, par exemple), et
puis écire du code pour le lire et l'écrire de façon portable -- et
on n'a pas besoin de connaître l'architecture du hardware pour faire
ça.
On peut aussi utiliser un format existant et déjà portable (je pense à
XML).
kanze@gabi-soft.fr wrote:
"hicham" <t.hicham@netcourrier.com> wrote in message
news:<bdp1um$92s$1@omega.u-picardie.fr>...
je suis a la recherche d'aide sur l'utilisation de endian.h avec
config.h dans le but de convertir des fichier compilés sous unix
solaris en BIG-ENDIAN en fichier LITTLE-ENDIAN.
Ce qu'il faut, c'est définir complétement le format du fichier
(comment reconnaître si les octets qui suivent sont un entier
binaire à quatre octet ou une chaîne de caractères, par exemple), et
puis écire du code pour le lire et l'écrire de façon portable -- et
on n'a pas besoin de connaître l'architecture du hardware pour faire
ça.
On peut aussi utiliser un format existant et déjà portable (je pense à
XML).
wrote:"hicham" wrote in message
news:<bdp1um$92s$...je suis a la recherche d'aide sur l'utilisation de endian.h avec
config.h dans le but de convertir des fichier compilés sous unix
solaris en BIG-ENDIAN en fichier LITTLE-ENDIAN.
Ce qu'il faut, c'est définir complétement le format du fichier
(comment reconnaître si les octets qui suivent sont un entier
binaire à quatre octet ou une chaîne de caractères, par exemple), et
puis écire du code pour le lire et l'écrire de façon portable -- et
on n'a pas besoin de connaître l'architecture du hardware pour faire
ça.
On peut aussi utiliser un format existant et déjà portable (je pense à
XML).
On peut aussi utiliser un format existant et déjà portable (je pense à
XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation de ce
qu'on a écrit n'est pas très rapide, et SI on accepte que les fichiers
auront une taille deux fois plus grande que nécessaire.
^^^^
On peut aussi utiliser un format existant et déjà portable (je pense à
XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation de ce
qu'on a écrit n'est pas très rapide, et SI on accepte que les fichiers
auront une taille deux fois plus grande que nécessaire.
^^^^
On peut aussi utiliser un format existant et déjà portable (je pense à
XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation de ce
qu'on a écrit n'est pas très rapide, et SI on accepte que les fichiers
auront une taille deux fois plus grande que nécessaire.
^^^^
On peut aussi utiliser un format existant et déjà portable (je pense à
XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation de ce
qu'on a écrit n'est pas très rapide, et SI on accepte que les fichiers
auront une taille deux fois plus grande que nécessaire.
On peut aussi utiliser un format existant et déjà portable (je pense à
XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation de ce
qu'on a écrit n'est pas très rapide, et SI on accepte que les fichiers
auront une taille deux fois plus grande que nécessaire.
On peut aussi utiliser un format existant et déjà portable (je pense à
XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation de ce
qu'on a écrit n'est pas très rapide, et SI on accepte que les fichiers
auront une taille deux fois plus grande que nécessaire.
writes:On peut aussi utiliser un format existant et déjà portable (je pense à
XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation de ce
qu'on a écrit n'est pas très rapide, et SI on accepte que les fichiers
auront une taille deux fois plus grande que nécessaire.
^^^^
Tu es optimiste ou bien tu consideres qu'on utilise la zlib d'office
quand on ecrit du XML?
kanze@gabi-soft.fr writes:
On peut aussi utiliser un format existant et déjà portable (je pense à
XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation de ce
qu'on a écrit n'est pas très rapide, et SI on accepte que les fichiers
auront une taille deux fois plus grande que nécessaire.
^^^^
Tu es optimiste ou bien tu consideres qu'on utilise la zlib d'office
quand on ecrit du XML?
writes:On peut aussi utiliser un format existant et déjà portable (je pense à
XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation de ce
qu'on a écrit n'est pas très rapide, et SI on accepte que les fichiers
auront une taille deux fois plus grande que nécessaire.
^^^^
Tu es optimiste ou bien tu consideres qu'on utilise la zlib d'office
quand on ecrit du XML?
Et
pour ça, il fallait plusieurs dizaines d'octets de message, ce qu'on
aurait pu faire en ASN.1 codé DER (ou autre) en quelques octets seulement.
Un exemple aussi minable et un tel gaspillage de ressources, ça m'a
dégouté du machin en question.
Et
pour ça, il fallait plusieurs dizaines d'octets de message, ce qu'on
aurait pu faire en ASN.1 codé DER (ou autre) en quelques octets seulement.
Un exemple aussi minable et un tel gaspillage de ressources, ça m'a
dégouté du machin en question.
Et
pour ça, il fallait plusieurs dizaines d'octets de message, ce qu'on
aurait pu faire en ASN.1 codé DER (ou autre) en quelques octets seulement.
Un exemple aussi minable et un tel gaspillage de ressources, ça m'a
dégouté du machin en question.
wrote:Christophe de Vienne wrote in message
news:<newscache$5s5chh$b0g$...wrote:On peut aussi utiliser un format existant et déjà portable (je
pense à XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Mais XML _est_ simple...
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation
de ce qu'on a écrit n'est pas très rapide, et SI on accepte que les
fichiers auront une taille deux fois plus grande que nécessaire.
Egalement SI on veut que le format soit très facilement lisible par un
programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI on veut pouvoir lire le fichier en question avec un simple éditeur
de texte,
SI on veut pouvoir valider le format du fichier facilement (et éviter
pas mal de debugging),
SI on veut utiliser des encodages ésotériques...
Donc, à moins que la vitesse de lecture et la taille du fichier ne
soit un réel problème, mon choix est en général vite fait.
Par ailleurs passer tout en format texte est-il si couteux ?
kanze@gabi-soft.fr wrote:
Christophe de Vienne <cdevienne@alphacent.com> wrote in message
news:<newscache$5s5chh$b0g$1@guronzan.alphacent.com>...
kanze@gabi-soft.fr wrote:
On peut aussi utiliser un format existant et déjà portable (je
pense à XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Mais XML _est_ simple...
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation
de ce qu'on a écrit n'est pas très rapide, et SI on accepte que les
fichiers auront une taille deux fois plus grande que nécessaire.
Egalement SI on veut que le format soit très facilement lisible par un
programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI on veut pouvoir lire le fichier en question avec un simple éditeur
de texte,
SI on veut pouvoir valider le format du fichier facilement (et éviter
pas mal de debugging),
SI on veut utiliser des encodages ésotériques...
Donc, à moins que la vitesse de lecture et la taille du fichier ne
soit un réel problème, mon choix est en général vite fait.
Par ailleurs passer tout en format texte est-il si couteux ?
wrote:Christophe de Vienne wrote in message
news:<newscache$5s5chh$b0g$...wrote:On peut aussi utiliser un format existant et déjà portable (je
pense à XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Mais XML _est_ simple...
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation
de ce qu'on a écrit n'est pas très rapide, et SI on accepte que les
fichiers auront une taille deux fois plus grande que nécessaire.
Egalement SI on veut que le format soit très facilement lisible par un
programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI on veut pouvoir lire le fichier en question avec un simple éditeur
de texte,
SI on veut pouvoir valider le format du fichier facilement (et éviter
pas mal de debugging),
SI on veut utiliser des encodages ésotériques...
Donc, à moins que la vitesse de lecture et la taille du fichier ne
soit un réel problème, mon choix est en général vite fait.
Par ailleurs passer tout en format texte est-il si couteux ?
On 1 Jul 2003 wrote:
[...]On peut aussi utiliser un format existant et déjà portable (je
pense à XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation
de ce qu'on a écrit n'est pas très rapide, et SI on accepte que les
fichiers auront une taille deux fois plus grande que nécessaire.
Comme disent les djeunz, ASN.1 rulez! (ah non, ils ne connaissent pas
l'ASN.1) ;)
Je me souviens avoir lu dans Linux Journal une description de ce qui
allait devenir Jabber... L'auteur de l'article était tout content à
l'idée des potentialités du machin, de la facilité d'échanger du XML,
etc. Son exemple qu'il trouvait génial, c'était qu'on pourrait dans un
futur pas trop lointain envoyer un message à une ampoule pour qu'elle
s'allume. Et pour ça, il fallait plusieurs dizaines d'octets de
message, ce qu'on aurait pu faire en ASN.1 codé DER (ou autre) en
quelques octets seulement.
Un exemple aussi minable et un tel gaspillage de ressources, ça m'a
dégouté du machin en question.
On 1 Jul 2003 kanze@gabi-soft.fr wrote:
[...]
On peut aussi utiliser un format existant et déjà portable (je
pense à XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation
de ce qu'on a écrit n'est pas très rapide, et SI on accepte que les
fichiers auront une taille deux fois plus grande que nécessaire.
Comme disent les djeunz, ASN.1 rulez! (ah non, ils ne connaissent pas
l'ASN.1) ;)
Je me souviens avoir lu dans Linux Journal une description de ce qui
allait devenir Jabber... L'auteur de l'article était tout content à
l'idée des potentialités du machin, de la facilité d'échanger du XML,
etc. Son exemple qu'il trouvait génial, c'était qu'on pourrait dans un
futur pas trop lointain envoyer un message à une ampoule pour qu'elle
s'allume. Et pour ça, il fallait plusieurs dizaines d'octets de
message, ce qu'on aurait pu faire en ASN.1 codé DER (ou autre) en
quelques octets seulement.
Un exemple aussi minable et un tel gaspillage de ressources, ça m'a
dégouté du machin en question.
On 1 Jul 2003 wrote:
[...]On peut aussi utiliser un format existant et déjà portable (je
pense à XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Sérieusement, ça peut être une bonne idée, SI on accepte le prix de
passer tout en format texte, et SI on accepte que l'interprétation
de ce qu'on a écrit n'est pas très rapide, et SI on accepte que les
fichiers auront une taille deux fois plus grande que nécessaire.
Comme disent les djeunz, ASN.1 rulez! (ah non, ils ne connaissent pas
l'ASN.1) ;)
Je me souviens avoir lu dans Linux Journal une description de ce qui
allait devenir Jabber... L'auteur de l'article était tout content à
l'idée des potentialités du machin, de la facilité d'échanger du XML,
etc. Son exemple qu'il trouvait génial, c'était qu'on pourrait dans un
futur pas trop lointain envoyer un message à une ampoule pour qu'elle
s'allume. Et pour ça, il fallait plusieurs dizaines d'octets de
message, ce qu'on aurait pu faire en ASN.1 codé DER (ou autre) en
quelques octets seulement.
Un exemple aussi minable et un tel gaspillage de ressources, ça m'a
dégouté du machin en question.
Christophe de Vienne wrote in message
news:<newscache$i3rchh$u7i$...wrote:Christophe de Vienne wrote in message
news:<newscache$5s5chh$b0g$...wrote:On peut aussi utiliser un format existant et déjà portable (je
pense à XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Mais XML _est_ simple...
On voit que tu ne l'as jamais vraiment utilisé:-).
L'avantage du XML, évidemment, c'est que tu peux te télécharger un
parseur qui a des chances de marcher. Si la structure des données est
complexe et variable, et que tu peux te permettre l'expansion de taille,
c'est à considérer pour cette raison. Si la structure n'est pas complex,
il est souvent plus simple d'écrire un parseur de rien que d'écrire des
spécifications XML (le schéma ou le DTD). Et si la structure est figée,
tu n'as pas besoin vraiment d'un parseur, ni de toutes les informations
supplémentaire dans le fichier XML.
Egalement SI on veut que le format soit très facilement lisible par un
programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI ton application peut utiliser un schéma pré-existant, c'est vrai.
Sinon, ce n'est pas l'utilisation du XML qui va changer quelque chose.
Du XML avec un schéma sur mésure, c'est comme n'importe quel autre
format que tu inventes toi-même.
SI on veut pouvoir lire le fichier en question avec un simple éditeur
de texte,
Un fichier texte est préférable. Toujours, quand on peut. Là, je suis
d'accord. Mais le XML n'est pas le seul format texte possible.
SI on veut utiliser des encodages ésotériques...
Et pourquoi est-ce qu'on voudrait faire une chose comme ça ? Si mon
programme ne sait pas écrire un encodage, quel est l'intérêt de
l'utiliser.
De toute façon, sans savoir ce qu'il veut faire avec ses données, on ne
peut pas dire quel serait le meilleur format. (Quelqu'un d'autre a
supposé qu'il veut les exécuter -- qu'il voulait un programme qui
convertirait un a.out Solaris (Sparc ?) en un a.out Linux (Intel ?). Ça
doit être possible, mais ce en serait pas un programme trivial.)
Christophe de Vienne <cdevienne@alphacent.com> wrote in message
news:<newscache$i3rchh$u7i$1@guronzan.alphacent.com>...
kanze@gabi-soft.fr wrote:
Christophe de Vienne <cdevienne@alphacent.com> wrote in message
news:<newscache$5s5chh$b0g$1@guronzan.alphacent.com>...
kanze@gabi-soft.fr wrote:
On peut aussi utiliser un format existant et déjà portable (je
pense à XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Mais XML _est_ simple...
On voit que tu ne l'as jamais vraiment utilisé:-).
L'avantage du XML, évidemment, c'est que tu peux te télécharger un
parseur qui a des chances de marcher. Si la structure des données est
complexe et variable, et que tu peux te permettre l'expansion de taille,
c'est à considérer pour cette raison. Si la structure n'est pas complex,
il est souvent plus simple d'écrire un parseur de rien que d'écrire des
spécifications XML (le schéma ou le DTD). Et si la structure est figée,
tu n'as pas besoin vraiment d'un parseur, ni de toutes les informations
supplémentaire dans le fichier XML.
Egalement SI on veut que le format soit très facilement lisible par un
programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI ton application peut utiliser un schéma pré-existant, c'est vrai.
Sinon, ce n'est pas l'utilisation du XML qui va changer quelque chose.
Du XML avec un schéma sur mésure, c'est comme n'importe quel autre
format que tu inventes toi-même.
SI on veut pouvoir lire le fichier en question avec un simple éditeur
de texte,
Un fichier texte est préférable. Toujours, quand on peut. Là, je suis
d'accord. Mais le XML n'est pas le seul format texte possible.
SI on veut utiliser des encodages ésotériques...
Et pourquoi est-ce qu'on voudrait faire une chose comme ça ? Si mon
programme ne sait pas écrire un encodage, quel est l'intérêt de
l'utiliser.
De toute façon, sans savoir ce qu'il veut faire avec ses données, on ne
peut pas dire quel serait le meilleur format. (Quelqu'un d'autre a
supposé qu'il veut les exécuter -- qu'il voulait un programme qui
convertirait un a.out Solaris (Sparc ?) en un a.out Linux (Intel ?). Ça
doit être possible, mais ce en serait pas un programme trivial.)
Christophe de Vienne wrote in message
news:<newscache$i3rchh$u7i$...wrote:Christophe de Vienne wrote in message
news:<newscache$5s5chh$b0g$...wrote:On peut aussi utiliser un format existant et déjà portable (je
pense à XML).
Pourquoi faire simple si on peut faire compliqué, n'est-ce pas ?
Mais XML _est_ simple...
On voit que tu ne l'as jamais vraiment utilisé:-).
L'avantage du XML, évidemment, c'est que tu peux te télécharger un
parseur qui a des chances de marcher. Si la structure des données est
complexe et variable, et que tu peux te permettre l'expansion de taille,
c'est à considérer pour cette raison. Si la structure n'est pas complex,
il est souvent plus simple d'écrire un parseur de rien que d'écrire des
spécifications XML (le schéma ou le DTD). Et si la structure est figée,
tu n'as pas besoin vraiment d'un parseur, ni de toutes les informations
supplémentaire dans le fichier XML.
Egalement SI on veut que le format soit très facilement lisible par un
programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI ton application peut utiliser un schéma pré-existant, c'est vrai.
Sinon, ce n'est pas l'utilisation du XML qui va changer quelque chose.
Du XML avec un schéma sur mésure, c'est comme n'importe quel autre
format que tu inventes toi-même.
SI on veut pouvoir lire le fichier en question avec un simple éditeur
de texte,
Un fichier texte est préférable. Toujours, quand on peut. Là, je suis
d'accord. Mais le XML n'est pas le seul format texte possible.
SI on veut utiliser des encodages ésotériques...
Et pourquoi est-ce qu'on voudrait faire une chose comme ça ? Si mon
programme ne sait pas écrire un encodage, quel est l'intérêt de
l'utiliser.
De toute façon, sans savoir ce qu'il veut faire avec ses données, on ne
peut pas dire quel serait le meilleur format. (Quelqu'un d'autre a
supposé qu'il veut les exécuter -- qu'il voulait un programme qui
convertirait un a.out Solaris (Sparc ?) en un a.out Linux (Intel ?). Ça
doit être possible, mais ce en serait pas un programme trivial.)