Bonjour à tous,
Pour mes besoins j'ai défini une fonction write ainsi :
template<typename T>
void write( std::ofstream & Stream, T Value )
{
Stream.write( reinterpret_cast<char*>( &Value ), sizeof T );
}
void main()
{
std::ofstream OutFileStream;
OutFileStream.open( "test" );
int c = 10;
write( OutFileStream, c );
}
Je m'étonne qu'elle n'existe pas déjà dans la STL, ou même carrement en tant
que fonction membre de ofstream. Je pense plutôt que j'ai mal cherché.
Y'a-t-il un équivalent et si non pourquoi ?
Merci.
Pour répondre à tout le monde, en fait ce qui me choque n'est pas tant l'absence de cette petite fonction template (j'ai maintenant bien compris pourquoi elle n'y est pas) que le fait que C++ impose l'utilisation de reinterpret_cast pour écrire une donnée en binaire.
Comme on te l'as dit, non seulement reinterpret_cast n'est pas nécessaire, mais en plus, c'est une erreur de l'utiliser dans ce contexte. Il faut définir mauellement le format binaire que l'on soihaite avoir, puis convertir nos données en tableau de char selon cette définition.
Cette fonction template avait juste pour but d'alléger l'écriture. fwrite accepte un void *, pourquoi ostream::write ne fait pas de même ?
Parce qu'elle accepte un char*, et que autant je sais ce qu'écrire un char veut dire, autant j'ignore ce que peut vouloir dire écrire un void.
-- Loïc
Aurélien REGAT-BARREL wrote:
Pour répondre à tout le monde, en fait ce qui me choque n'est pas tant
l'absence de cette petite fonction template (j'ai maintenant bien compris
pourquoi elle n'y est pas) que le fait que C++ impose l'utilisation de
reinterpret_cast pour écrire une donnée en binaire.
Comme on te l'as dit, non seulement reinterpret_cast n'est pas
nécessaire, mais en plus, c'est une erreur de l'utiliser dans ce
contexte. Il faut définir mauellement le format binaire que l'on
soihaite avoir, puis convertir nos données en tableau de char selon
cette définition.
Cette fonction template
avait juste pour but d'alléger l'écriture.
fwrite accepte un void *, pourquoi ostream::write ne fait pas de même ?
Parce qu'elle accepte un char*, et que autant je sais ce qu'écrire un
char veut dire, autant j'ignore ce que peut vouloir dire écrire un void.
Pour répondre à tout le monde, en fait ce qui me choque n'est pas tant l'absence de cette petite fonction template (j'ai maintenant bien compris pourquoi elle n'y est pas) que le fait que C++ impose l'utilisation de reinterpret_cast pour écrire une donnée en binaire.
Comme on te l'as dit, non seulement reinterpret_cast n'est pas nécessaire, mais en plus, c'est une erreur de l'utiliser dans ce contexte. Il faut définir mauellement le format binaire que l'on soihaite avoir, puis convertir nos données en tableau de char selon cette définition.
Cette fonction template avait juste pour but d'alléger l'écriture. fwrite accepte un void *, pourquoi ostream::write ne fait pas de même ?
Parce qu'elle accepte un char*, et que autant je sais ce qu'écrire un char veut dire, autant j'ignore ce que peut vouloir dire écrire un void.
-- Loïc
Aurélien REGAT-BARREL
Comme on te l'as dit, non seulement reinterpret_cast n'est pas nécessaire, mais en plus, c'est une erreur de l'utiliser dans ce contexte. Il faut définir mauellement le format binaire que l'on soihaite avoir, puis convertir nos données en tableau de char selon cette définition.
C'est une tâche assez laborieuse, surtout quand on ne vise pas la portabilité et qu'on est assuré que le format du fichier et le format interne sont les mêmes, ce qui est mon cas. Dans cette situation, est-ce acceptable d'utiliser reinterpret_cast ?
Cette fonction template avait juste pour but d'alléger l'écriture. fwrite accepte un void *, pourquoi ostream::write ne fait pas de même ?
Parce qu'elle accepte un char*, et que autant je sais ce qu'écrire un char veut dire, autant j'ignore ce que peut vouloir dire écrire un void.
Ben fwrite le sait bien elle... Mais bon je saisis un peu mieux le truc, ce que j'ai enfin compris c'est qu'il faut écrire sa routine qui sérialise ses données en un tableau de char. Ce que je trouve "aberrant" (vous aurez compris que ce mot était volontairement trop fort et avait pour but de susciter des réactions ;-) c'est qu'il n'y ait rien dans la SL qui guide le programmeur dans ce sens, genre une fonction write templatée qui accepte/appelle un serialiser, ou des fonctions d'aide à la sérialisation, ou autre chose. Je trouve que c'est pas évident du tout qu'il faille procéder ainsi, et j'ai peur de ne pas être le seul. Existe-t-il quelque chose ailleurs, dans boost par exemple, qui soit indiqué dans ce cas ? James a parlé de oberstream et d' oxdrstream, mais je n'ai rien trouvé :-( Excusez moi si j'ai été lourd. Merci pour votre aide.
-- Aurélien REGAT-BARREL
Comme on te l'as dit, non seulement reinterpret_cast n'est pas
nécessaire, mais en plus, c'est une erreur de l'utiliser dans ce
contexte. Il faut définir mauellement le format binaire que l'on
soihaite avoir, puis convertir nos données en tableau de char selon
cette définition.
C'est une tâche assez laborieuse, surtout quand on ne vise pas la
portabilité et qu'on est assuré que le format du fichier et le format
interne sont les mêmes, ce qui est mon cas. Dans cette situation, est-ce
acceptable d'utiliser reinterpret_cast ?
Cette fonction template
avait juste pour but d'alléger l'écriture.
fwrite accepte un void *, pourquoi ostream::write ne fait pas de même ?
Parce qu'elle accepte un char*, et que autant je sais ce qu'écrire un
char veut dire, autant j'ignore ce que peut vouloir dire écrire un void.
Ben fwrite le sait bien elle...
Mais bon je saisis un peu mieux le truc, ce que j'ai enfin compris c'est
qu'il faut écrire sa routine qui sérialise ses données en un tableau de
char. Ce que je trouve "aberrant" (vous aurez compris que ce mot était
volontairement trop fort et avait pour but de susciter des réactions ;-)
c'est qu'il n'y ait rien dans la SL qui guide le programmeur dans ce sens,
genre une fonction write templatée qui accepte/appelle un serialiser, ou des
fonctions d'aide à la sérialisation, ou autre chose. Je trouve que c'est pas
évident du tout qu'il faille procéder ainsi, et j'ai peur de ne pas être le
seul. Existe-t-il quelque chose ailleurs, dans boost par exemple, qui soit
indiqué dans ce cas ?
James a parlé de oberstream et d' oxdrstream, mais je n'ai rien trouvé :-(
Excusez moi si j'ai été lourd.
Merci pour votre aide.
Comme on te l'as dit, non seulement reinterpret_cast n'est pas nécessaire, mais en plus, c'est une erreur de l'utiliser dans ce contexte. Il faut définir mauellement le format binaire que l'on soihaite avoir, puis convertir nos données en tableau de char selon cette définition.
C'est une tâche assez laborieuse, surtout quand on ne vise pas la portabilité et qu'on est assuré que le format du fichier et le format interne sont les mêmes, ce qui est mon cas. Dans cette situation, est-ce acceptable d'utiliser reinterpret_cast ?
Cette fonction template avait juste pour but d'alléger l'écriture. fwrite accepte un void *, pourquoi ostream::write ne fait pas de même ?
Parce qu'elle accepte un char*, et que autant je sais ce qu'écrire un char veut dire, autant j'ignore ce que peut vouloir dire écrire un void.
Ben fwrite le sait bien elle... Mais bon je saisis un peu mieux le truc, ce que j'ai enfin compris c'est qu'il faut écrire sa routine qui sérialise ses données en un tableau de char. Ce que je trouve "aberrant" (vous aurez compris que ce mot était volontairement trop fort et avait pour but de susciter des réactions ;-) c'est qu'il n'y ait rien dans la SL qui guide le programmeur dans ce sens, genre une fonction write templatée qui accepte/appelle un serialiser, ou des fonctions d'aide à la sérialisation, ou autre chose. Je trouve que c'est pas évident du tout qu'il faille procéder ainsi, et j'ai peur de ne pas être le seul. Existe-t-il quelque chose ailleurs, dans boost par exemple, qui soit indiqué dans ce cas ? James a parlé de oberstream et d' oxdrstream, mais je n'ai rien trouvé :-( Excusez moi si j'ai été lourd. Merci pour votre aide.
-- Aurélien REGAT-BARREL
Falk Tannhäuser
Aurélien REGAT-BARREL wrote:
C'est une tâche assez laborieuse, surtout quand on ne vise pas la portabilité et qu'on est assuré que le format du fichier et le format interne sont les mêmes, ce qui est mon cas. Dans cette situation, est-ce acceptable d'utiliser reinterpret_cast ?
Si tu n'as pas besoin de portabilité, je ne vois pas ce qui s'opposerait à l'utilisation de 'reinterpret_cast' ; il a même l'avantage d'avertir le lecteur du code : "attention, ici on fait quelque chose de non-portable !"
En utilisant les fonctions C 'fwrite' et 'fread', on fait bien l'équivalent moral d'un 'reinterpret_cast' en cachette, puisque ces fonctions prennent un 'void [const]*' pour le traiter en interne - au moins d'un point de vue conceptuel - comme 'unsigned char [const]*' car elles écrivent / lisent des "bytes" ; or une conversion (même implicite) d'un pointeur vers 'void [const]*' suivi par une conversion (explicite en C++, explicite ou implicite en C) vers un pointeur sur un autre type que celui du pointeur d'origine revient à faire un 'reinterpret_cast'.
Falk
Aurélien REGAT-BARREL wrote:
C'est une tâche assez laborieuse, surtout quand on ne vise pas la
portabilité et qu'on est assuré que le format du fichier et le format
interne sont les mêmes, ce qui est mon cas. Dans cette situation, est-ce
acceptable d'utiliser reinterpret_cast ?
Si tu n'as pas besoin de portabilité, je ne vois pas ce qui
s'opposerait à l'utilisation de 'reinterpret_cast' ; il a
même l'avantage d'avertir le lecteur du code : "attention,
ici on fait quelque chose de non-portable !"
En utilisant les fonctions C 'fwrite' et 'fread', on fait
bien l'équivalent moral d'un 'reinterpret_cast' en cachette,
puisque ces fonctions prennent un 'void [const]*' pour le
traiter en interne - au moins d'un point de vue conceptuel -
comme 'unsigned char [const]*' car elles écrivent / lisent
des "bytes" ; or une conversion (même implicite) d'un
pointeur vers 'void [const]*' suivi par une conversion
(explicite en C++, explicite ou implicite en C) vers
un pointeur sur un autre type que celui du pointeur
d'origine revient à faire un 'reinterpret_cast'.
C'est une tâche assez laborieuse, surtout quand on ne vise pas la portabilité et qu'on est assuré que le format du fichier et le format interne sont les mêmes, ce qui est mon cas. Dans cette situation, est-ce acceptable d'utiliser reinterpret_cast ?
Si tu n'as pas besoin de portabilité, je ne vois pas ce qui s'opposerait à l'utilisation de 'reinterpret_cast' ; il a même l'avantage d'avertir le lecteur du code : "attention, ici on fait quelque chose de non-portable !"
En utilisant les fonctions C 'fwrite' et 'fread', on fait bien l'équivalent moral d'un 'reinterpret_cast' en cachette, puisque ces fonctions prennent un 'void [const]*' pour le traiter en interne - au moins d'un point de vue conceptuel - comme 'unsigned char [const]*' car elles écrivent / lisent des "bytes" ; or une conversion (même implicite) d'un pointeur vers 'void [const]*' suivi par une conversion (explicite en C++, explicite ou implicite en C) vers un pointeur sur un autre type que celui du pointeur d'origine revient à faire un 'reinterpret_cast'.
Falk
Fabien LE LEZ
On Thu, 19 Aug 2004 14:31:27 +0200, "Aurélien REGAT-BARREL" :
Ce que je trouve "aberrant" (vous aurez compris que ce mot était volontairement trop fort et avait pour but de susciter des réactions ;-) c'est qu'il n'y ait rien dans la SL qui guide le programmeur dans ce sens,
Il n'y a pas grand-chose dans la SL, juste des briques de base qui font le minimum. Le principe, c'est d'ajouter les bibliothèques externes dont tu as besoin.
-- ;-)
On Thu, 19 Aug 2004 14:31:27 +0200, "Aurélien REGAT-BARREL"
<nospam-aregatba@yahoo.fr.invalid>:
Ce que je trouve "aberrant" (vous aurez compris que ce mot était
volontairement trop fort et avait pour but de susciter des réactions ;-)
c'est qu'il n'y ait rien dans la SL qui guide le programmeur dans ce sens,
Il n'y a pas grand-chose dans la SL, juste des briques de base qui
font le minimum. Le principe, c'est d'ajouter les bibliothèques
externes dont tu as besoin.
On Thu, 19 Aug 2004 14:31:27 +0200, "Aurélien REGAT-BARREL" :
Ce que je trouve "aberrant" (vous aurez compris que ce mot était volontairement trop fort et avait pour but de susciter des réactions ;-) c'est qu'il n'y ait rien dans la SL qui guide le programmeur dans ce sens,
Il n'y a pas grand-chose dans la SL, juste des briques de base qui font le minimum. Le principe, c'est d'ajouter les bibliothèques externes dont tu as besoin.
-- ;-)
Loïc Joly
Aurélien REGAT-BARREL wrote:
Comme on te l'as dit, non seulement reinterpret_cast n'est pas nécessaire, mais en plus, c'est une erreur de l'utiliser dans ce contexte. Il faut définir mauellement le format binaire que l'on soihaite avoir, puis convertir nos données en tableau de char selon cette définition.
C'est une tâche assez laborieuse, surtout quand on ne vise pas la portabilité et qu'on est assuré que le format du fichier et le format interne sont les mêmes, ce qui est mon cas. Dans cette situation, est-ce acceptable d'utiliser reinterpret_cast ?
Si tu ne vise pas la compatibilité (même entre deux versions de ton programme), et si tu ne sauves que des types de données directs (pas de pointeurs...), alors oui, un reinterpret_cast doit fonctionner.
Cette fonction template avait juste pour but d'alléger l'écriture. fwrite accepte un void *, pourquoi ostream::write ne fait pas de même ?
Parce qu'elle accepte un char*, et que autant je sais ce qu'écrire un char veut dire, autant j'ignore ce que peut vouloir dire écrire un void.
Ben fwrite le sait bien elle... Mais bon je saisis un peu mieux le truc, ce que j'ai enfin compris c'est qu'il faut écrire sa routine qui sérialise ses données en un tableau de char. Ce que je trouve "aberrant" (vous aurez compris que ce mot était volontairement trop fort et avait pour but de susciter des réactions ;-) c'est qu'il n'y ait rien dans la SL qui guide le programmeur dans ce sens, genre une fonction write templatée qui accepte/appelle un serialiser, ou des fonctions d'aide à la sérialisation, ou autre chose. Je trouve que c'est pas évident du tout qu'il faille procéder ainsi, et j'ai peur de ne pas être le seul. Existe-t-il quelque chose ailleurs, dans boost par exemple, qui soit indiqué dans ce cas ?
Il y a boost::serialization qui permet de sauver des données complexes. Ce que j'aime bien dedans (mais je n'ai pas utilisé directement, j'ai juste spécifié ça à un prestataire chez nous), c'est : - La possibilité de n'écrire qu'une seule fonction qui fait à la fois lecture et écriture - Le fait qu'il soit aussi simple de sauver un int qu'un pointeur sur une classe de base qui pointe en fait sur une base dérivée - Le fait que le code pour sérialiser la STL est déjà fourni (ce qui implique entre autre qu'on peut sérialiser une classe de manière non intrusive) - La possibilité de choisir le format de sauvegarde (même si les format fournis à la base sont orientés texte (XML ou format de texte qui en fait pas des tonnes pour pas grand chose) ou flux binaire non portable)
James a parlé de oberstream et d' oxdrstream, mais je n'ai rien trouvé :-( Excusez moi si j'ai été lourd.
Bof, ya pire, mais je ne citerai pas de noms.
Par contre, je me pose une question : Pourquoi sauver en binaire ? Au boulot, on le fait pour envoyer des messages réseau (contraintes de charges et de temps assez importantes), mais plus le temps passe, plus je me demande si un format textuel, éventuellement compressé et crypté, ne serait pas aussi efficace et plus simpe à mettre en oeuvre.
Aujourd'hui, ne ne voit que les points suivants sur lesquels le binaire peut s'avérer intéressant : - La sérialisation de chaque type de base prend un nombre constant de bits - Il existe des logiciels prenant un format binaire avec lesquels s'interfacer (mais dans ce cas là, il ne faut pas faire *du* binaire, mais *le* binaire en question) - Il y a des types (flottants) pour lesquels une représentation textuelle classique fait perdre de l'information.
Dans l'autre sens, je vois les points suivants : - Un format plus simple à debugger, analyser... - Du code plus simple à écrire
Y a-t-il d'autres arguments dans un sens ou un autre ?
-- Loïc
Aurélien REGAT-BARREL wrote:
Comme on te l'as dit, non seulement reinterpret_cast n'est pas
nécessaire, mais en plus, c'est une erreur de l'utiliser dans ce
contexte. Il faut définir mauellement le format binaire que l'on
soihaite avoir, puis convertir nos données en tableau de char selon
cette définition.
C'est une tâche assez laborieuse, surtout quand on ne vise pas la
portabilité et qu'on est assuré que le format du fichier et le format
interne sont les mêmes, ce qui est mon cas. Dans cette situation, est-ce
acceptable d'utiliser reinterpret_cast ?
Si tu ne vise pas la compatibilité (même entre deux versions de ton
programme), et si tu ne sauves que des types de données directs (pas de
pointeurs...), alors oui, un reinterpret_cast doit fonctionner.
Cette fonction template
avait juste pour but d'alléger l'écriture.
fwrite accepte un void *, pourquoi ostream::write ne fait pas de même ?
Parce qu'elle accepte un char*, et que autant je sais ce qu'écrire un
char veut dire, autant j'ignore ce que peut vouloir dire écrire un void.
Ben fwrite le sait bien elle...
Mais bon je saisis un peu mieux le truc, ce que j'ai enfin compris c'est
qu'il faut écrire sa routine qui sérialise ses données en un tableau de
char. Ce que je trouve "aberrant" (vous aurez compris que ce mot était
volontairement trop fort et avait pour but de susciter des réactions ;-)
c'est qu'il n'y ait rien dans la SL qui guide le programmeur dans ce sens,
genre une fonction write templatée qui accepte/appelle un serialiser, ou des
fonctions d'aide à la sérialisation, ou autre chose. Je trouve que c'est pas
évident du tout qu'il faille procéder ainsi, et j'ai peur de ne pas être le
seul. Existe-t-il quelque chose ailleurs, dans boost par exemple, qui soit
indiqué dans ce cas ?
Il y a boost::serialization qui permet de sauver des données complexes.
Ce que j'aime bien dedans (mais je n'ai pas utilisé directement, j'ai
juste spécifié ça à un prestataire chez nous), c'est :
- La possibilité de n'écrire qu'une seule fonction qui fait à la fois
lecture et écriture
- Le fait qu'il soit aussi simple de sauver un int qu'un pointeur sur
une classe de base qui pointe en fait sur une base dérivée
- Le fait que le code pour sérialiser la STL est déjà fourni (ce qui
implique entre autre qu'on peut sérialiser une classe de manière non
intrusive)
- La possibilité de choisir le format de sauvegarde (même si les format
fournis à la base sont orientés texte (XML ou format de texte qui en
fait pas des tonnes pour pas grand chose) ou flux binaire non portable)
James a parlé de oberstream et d' oxdrstream, mais je n'ai rien trouvé :-(
Excusez moi si j'ai été lourd.
Bof, ya pire, mais je ne citerai pas de noms.
Par contre, je me pose une question : Pourquoi sauver en binaire ? Au
boulot, on le fait pour envoyer des messages réseau (contraintes de
charges et de temps assez importantes), mais plus le temps passe, plus
je me demande si un format textuel, éventuellement compressé et crypté,
ne serait pas aussi efficace et plus simpe à mettre en oeuvre.
Aujourd'hui, ne ne voit que les points suivants sur lesquels le binaire
peut s'avérer intéressant :
- La sérialisation de chaque type de base prend un nombre constant de bits
- Il existe des logiciels prenant un format binaire avec lesquels
s'interfacer (mais dans ce cas là, il ne faut pas faire *du* binaire,
mais *le* binaire en question)
- Il y a des types (flottants) pour lesquels une représentation
textuelle classique fait perdre de l'information.
Dans l'autre sens, je vois les points suivants :
- Un format plus simple à debugger, analyser...
- Du code plus simple à écrire
Y a-t-il d'autres arguments dans un sens ou un autre ?
Comme on te l'as dit, non seulement reinterpret_cast n'est pas nécessaire, mais en plus, c'est une erreur de l'utiliser dans ce contexte. Il faut définir mauellement le format binaire que l'on soihaite avoir, puis convertir nos données en tableau de char selon cette définition.
C'est une tâche assez laborieuse, surtout quand on ne vise pas la portabilité et qu'on est assuré que le format du fichier et le format interne sont les mêmes, ce qui est mon cas. Dans cette situation, est-ce acceptable d'utiliser reinterpret_cast ?
Si tu ne vise pas la compatibilité (même entre deux versions de ton programme), et si tu ne sauves que des types de données directs (pas de pointeurs...), alors oui, un reinterpret_cast doit fonctionner.
Cette fonction template avait juste pour but d'alléger l'écriture. fwrite accepte un void *, pourquoi ostream::write ne fait pas de même ?
Parce qu'elle accepte un char*, et que autant je sais ce qu'écrire un char veut dire, autant j'ignore ce que peut vouloir dire écrire un void.
Ben fwrite le sait bien elle... Mais bon je saisis un peu mieux le truc, ce que j'ai enfin compris c'est qu'il faut écrire sa routine qui sérialise ses données en un tableau de char. Ce que je trouve "aberrant" (vous aurez compris que ce mot était volontairement trop fort et avait pour but de susciter des réactions ;-) c'est qu'il n'y ait rien dans la SL qui guide le programmeur dans ce sens, genre une fonction write templatée qui accepte/appelle un serialiser, ou des fonctions d'aide à la sérialisation, ou autre chose. Je trouve que c'est pas évident du tout qu'il faille procéder ainsi, et j'ai peur de ne pas être le seul. Existe-t-il quelque chose ailleurs, dans boost par exemple, qui soit indiqué dans ce cas ?
Il y a boost::serialization qui permet de sauver des données complexes. Ce que j'aime bien dedans (mais je n'ai pas utilisé directement, j'ai juste spécifié ça à un prestataire chez nous), c'est : - La possibilité de n'écrire qu'une seule fonction qui fait à la fois lecture et écriture - Le fait qu'il soit aussi simple de sauver un int qu'un pointeur sur une classe de base qui pointe en fait sur une base dérivée - Le fait que le code pour sérialiser la STL est déjà fourni (ce qui implique entre autre qu'on peut sérialiser une classe de manière non intrusive) - La possibilité de choisir le format de sauvegarde (même si les format fournis à la base sont orientés texte (XML ou format de texte qui en fait pas des tonnes pour pas grand chose) ou flux binaire non portable)
James a parlé de oberstream et d' oxdrstream, mais je n'ai rien trouvé :-( Excusez moi si j'ai été lourd.
Bof, ya pire, mais je ne citerai pas de noms.
Par contre, je me pose une question : Pourquoi sauver en binaire ? Au boulot, on le fait pour envoyer des messages réseau (contraintes de charges et de temps assez importantes), mais plus le temps passe, plus je me demande si un format textuel, éventuellement compressé et crypté, ne serait pas aussi efficace et plus simpe à mettre en oeuvre.
Aujourd'hui, ne ne voit que les points suivants sur lesquels le binaire peut s'avérer intéressant : - La sérialisation de chaque type de base prend un nombre constant de bits - Il existe des logiciels prenant un format binaire avec lesquels s'interfacer (mais dans ce cas là, il ne faut pas faire *du* binaire, mais *le* binaire en question) - Il y a des types (flottants) pour lesquels une représentation textuelle classique fait perdre de l'information.
Dans l'autre sens, je vois les points suivants : - Un format plus simple à debugger, analyser... - Du code plus simple à écrire
Y a-t-il d'autres arguments dans un sens ou un autre ?
-- Loïc
Fabien LE LEZ
On Thu, 19 Aug 2004 16:56:49 +0200, Loïc Joly :
Aujourd'hui, ne ne voit que les points suivants sur lesquels le binaire peut s'avérer intéressant :
N'oublie pas le cas où on a vraiment beaucoup de données. Si tu as quelques centaines de millions d'entiers à sauvegarder, un format binaire est beaucoup plus efficace.
-- ;-)
On Thu, 19 Aug 2004 16:56:49 +0200, Loïc Joly
<loic.actarus.joly@wanadoo.fr>:
Aujourd'hui, ne ne voit que les points suivants sur lesquels le binaire
peut s'avérer intéressant :
N'oublie pas le cas où on a vraiment beaucoup de données. Si tu as
quelques centaines de millions d'entiers à sauvegarder, un format
binaire est beaucoup plus efficace.
Aujourd'hui, ne ne voit que les points suivants sur lesquels le binaire peut s'avérer intéressant :
N'oublie pas le cas où on a vraiment beaucoup de données. Si tu as quelques centaines de millions d'entiers à sauvegarder, un format binaire est beaucoup plus efficace.
-- ;-)
M. B.
"Loïc Joly" a écrit dans le message de news: cg2esa$q5a$
Aurélien REGAT-BARREL wrote:
Dans l'autre sens, je vois les points suivants : - Un format plus simple à debugger, analyser... - Du code plus simple à écrire
Y a-t-il d'autres arguments dans un sens ou un autre ?
Pour rester du cote textuel, les avantages d'XML sont innombrables.
MB
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message de news:
cg2esa$q5a$1@news-reader1.wanadoo.fr...
Aurélien REGAT-BARREL wrote:
Dans l'autre sens, je vois les points suivants :
- Un format plus simple à debugger, analyser...
- Du code plus simple à écrire
Y a-t-il d'autres arguments dans un sens ou un autre ?
Pour rester du cote textuel, les avantages d'XML sont
innombrables.
"Loïc Joly" a écrit dans le message de news: cg2esa$q5a$
Aurélien REGAT-BARREL wrote:
Dans l'autre sens, je vois les points suivants : - Un format plus simple à debugger, analyser... - Du code plus simple à écrire
Y a-t-il d'autres arguments dans un sens ou un autre ?
Pour rester du cote textuel, les avantages d'XML sont innombrables.
MB
drkm
"M. B." writes:
"Loïc Joly" a écrit dans le message de news: cg2esa$q5a$
Dans l'autre sens, je vois les points suivants : - Un format plus simple à debugger, analyser... - Du code plus simple à écrire
Y a-t-il d'autres arguments dans un sens ou un autre ?
Pour rester du cote textuel, les avantages d'XML sont innombrables.
Dont la plupart sont très surfaits, AMHA. Un des principaux avantages étant selon moi la quantité de logiciels le prenant en compte, surtout au niveau des bibliothèques.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
"M. B." <m_binder@magicnet.com> writes:
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message de news:
cg2esa$q5a$1@news-reader1.wanadoo.fr...
Dans l'autre sens, je vois les points suivants :
- Un format plus simple à debugger, analyser...
- Du code plus simple à écrire
Y a-t-il d'autres arguments dans un sens ou un autre ?
Pour rester du cote textuel, les avantages d'XML sont
innombrables.
Dont la plupart sont très surfaits, AMHA. Un des principaux
avantages étant selon moi la quantité de logiciels le prenant en
compte, surtout au niveau des bibliothèques.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
"Loïc Joly" a écrit dans le message de news: cg2esa$q5a$
Dans l'autre sens, je vois les points suivants : - Un format plus simple à debugger, analyser... - Du code plus simple à écrire
Y a-t-il d'autres arguments dans un sens ou un autre ?
Pour rester du cote textuel, les avantages d'XML sont innombrables.
Dont la plupart sont très surfaits, AMHA. Un des principaux avantages étant selon moi la quantité de logiciels le prenant en compte, surtout au niveau des bibliothèques.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
drkm
Loïc Joly writes:
- Il y a des types (flottants) pour lesquels une représentation textuelle classique fait perdre de l'information.
Je ne sais pas ce que tu entends par « classique », mais il est toujours possible de spécifier une représentation textuelle inspirée de la représentation binaire utilisée par ton implémentation.
Mais il me semble que si tu analyses bien tes besoins, il y a moyen de spécifier un format où tu représentes la mantisse, l'exposant, etc. sous forme d'entiers textuels, de manière à disposer de la précision dont tu as besoin. Le fait que certaines implémentations pourrait ne pas garantir une telle précision est ici hors propos.
Il me semble, du moins.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
- Il y a des types (flottants) pour lesquels une représentation
textuelle classique fait perdre de l'information.
Je ne sais pas ce que tu entends par « classique », mais il est
toujours possible de spécifier une représentation textuelle inspirée
de la représentation binaire utilisée par ton implémentation.
Mais il me semble que si tu analyses bien tes besoins, il y a moyen
de spécifier un format où tu représentes la mantisse, l'exposant,
etc. sous forme d'entiers textuels, de manière à disposer de la
précision dont tu as besoin. Le fait que certaines implémentations
pourrait ne pas garantir une telle précision est ici hors propos.
Il me semble, du moins.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
- Il y a des types (flottants) pour lesquels une représentation textuelle classique fait perdre de l'information.
Je ne sais pas ce que tu entends par « classique », mais il est toujours possible de spécifier une représentation textuelle inspirée de la représentation binaire utilisée par ton implémentation.
Mais il me semble que si tu analyses bien tes besoins, il y a moyen de spécifier un format où tu représentes la mantisse, l'exposant, etc. sous forme d'entiers textuels, de manière à disposer de la précision dont tu as besoin. Le fait que certaines implémentations pourrait ne pas garantir une telle précision est ici hors propos.
Il me semble, du moins.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Aurélien REGAT-BARREL
Il y a boost::serialization qui permet de sauver des données complexes. Ce que j'aime bien dedans (mais je n'ai pas utilisé directement, j'ai juste spécifié ça à un prestataire chez nous), c'est : - La possibilité de n'écrire qu'une seule fonction qui fait à la fois lecture et écriture - Le fait qu'il soit aussi simple de sauver un int qu'un pointeur sur une classe de base qui pointe en fait sur une base dérivée - Le fait que le code pour sérialiser la STL est déjà fourni (ce qui implique entre autre qu'on peut sérialiser une classe de manière non intrusive) - La possibilité de choisir le format de sauvegarde (même si les format fournis à la base sont orientés texte (XML ou format de texte qui en fait pas des tonnes pour pas grand chose) ou flux binaire non portable)
Très intéressant. J'y jetterai un oeil.
Par contre, je me pose une question : Pourquoi sauver en binaire ? Au boulot, on le fait pour envoyer des messages réseau (contraintes de charges et de temps assez importantes), mais plus le temps passe, plus je me demande si un format textuel, éventuellement compressé et crypté, ne serait pas aussi efficace et plus simpe à mettre en oeuvre.
Et le flux compressé, tu l'envoie en texte ? ;-)
Aujourd'hui, ne ne voit que les points suivants sur lesquels le binaire peut s'avérer intéressant : [..]
Comme l'a dit Fabien, quand les fichiers comment à dépasser le mega, le binaire devient très intéressant. Au boulot on manipule "à la main" des données ASCII (pratique pour les tests, etc...) mais une fois que c'est ok, on passe le tout à la moulinette -> binaire. Ca réduit la taille par ~10, et le temps de chargement par XXX (convertir des millions de nombres flottants, c'est long !) Dans un cas comme ça compresser fait gagner d'un côté (taille) mais perdre de l'autre (temps : en plus de la conversion très longue, y'a la compression/decompression).
-- Aurélien REGAT-BARREL
Il y a boost::serialization qui permet de sauver des données complexes.
Ce que j'aime bien dedans (mais je n'ai pas utilisé directement, j'ai
juste spécifié ça à un prestataire chez nous), c'est :
- La possibilité de n'écrire qu'une seule fonction qui fait à la fois
lecture et écriture
- Le fait qu'il soit aussi simple de sauver un int qu'un pointeur sur
une classe de base qui pointe en fait sur une base dérivée
- Le fait que le code pour sérialiser la STL est déjà fourni (ce qui
implique entre autre qu'on peut sérialiser une classe de manière non
intrusive)
- La possibilité de choisir le format de sauvegarde (même si les format
fournis à la base sont orientés texte (XML ou format de texte qui en
fait pas des tonnes pour pas grand chose) ou flux binaire non portable)
Très intéressant. J'y jetterai un oeil.
Par contre, je me pose une question : Pourquoi sauver en binaire ? Au
boulot, on le fait pour envoyer des messages réseau (contraintes de
charges et de temps assez importantes), mais plus le temps passe, plus
je me demande si un format textuel, éventuellement compressé et crypté,
ne serait pas aussi efficace et plus simpe à mettre en oeuvre.
Et le flux compressé, tu l'envoie en texte ? ;-)
Aujourd'hui, ne ne voit que les points suivants sur lesquels le binaire
peut s'avérer intéressant :
[..]
Comme l'a dit Fabien, quand les fichiers comment à dépasser le mega, le
binaire devient très intéressant. Au boulot on manipule "à la main" des
données ASCII (pratique pour les tests, etc...) mais une fois que c'est ok,
on passe le tout à la moulinette -> binaire. Ca réduit la taille par ~10, et
le temps de chargement par XXX (convertir des millions de nombres flottants,
c'est long !)
Dans un cas comme ça compresser fait gagner d'un côté (taille) mais perdre
de l'autre (temps : en plus de la conversion très longue, y'a la
compression/decompression).
Il y a boost::serialization qui permet de sauver des données complexes. Ce que j'aime bien dedans (mais je n'ai pas utilisé directement, j'ai juste spécifié ça à un prestataire chez nous), c'est : - La possibilité de n'écrire qu'une seule fonction qui fait à la fois lecture et écriture - Le fait qu'il soit aussi simple de sauver un int qu'un pointeur sur une classe de base qui pointe en fait sur une base dérivée - Le fait que le code pour sérialiser la STL est déjà fourni (ce qui implique entre autre qu'on peut sérialiser une classe de manière non intrusive) - La possibilité de choisir le format de sauvegarde (même si les format fournis à la base sont orientés texte (XML ou format de texte qui en fait pas des tonnes pour pas grand chose) ou flux binaire non portable)
Très intéressant. J'y jetterai un oeil.
Par contre, je me pose une question : Pourquoi sauver en binaire ? Au boulot, on le fait pour envoyer des messages réseau (contraintes de charges et de temps assez importantes), mais plus le temps passe, plus je me demande si un format textuel, éventuellement compressé et crypté, ne serait pas aussi efficace et plus simpe à mettre en oeuvre.
Et le flux compressé, tu l'envoie en texte ? ;-)
Aujourd'hui, ne ne voit que les points suivants sur lesquels le binaire peut s'avérer intéressant : [..]
Comme l'a dit Fabien, quand les fichiers comment à dépasser le mega, le binaire devient très intéressant. Au boulot on manipule "à la main" des données ASCII (pratique pour les tests, etc...) mais une fois que c'est ok, on passe le tout à la moulinette -> binaire. Ca réduit la taille par ~10, et le temps de chargement par XXX (convertir des millions de nombres flottants, c'est long !) Dans un cas comme ça compresser fait gagner d'un côté (taille) mais perdre de l'autre (temps : en plus de la conversion très longue, y'a la compression/decompression).
