"Frédéri MIAILLE" wrote in message news:<bls03h$2mqb$...
"James Kanze" a écrit dans le message de news:
"Frédéri MIAILLE" writes:
|> Et bien seekg()/seekp() peuvent placer le pointeur à la fin du |> fichier et on peut utiliser tellg()/tellp() par la suite. Ce n'est |> pas fiable ?
Non. Régarde le type de retour de tellg()/tellp(). Ce n'est pas un type entier.
type streampos et streampos est défini comme long.
J'aurais dû être plus précis. Si tu utilises <iostream> et al., il n'est pas de type entier. Il est effectivement un long dans les iostream classique de <iostream.h>
En <iostream>, c'est un traits::pos_type, qui doit être un streampos, qui est un type qui doit remplir les démandes de §27.4.3.2 ; dans la pratique, c'est prèsque toujours un typedef à fpos< mbstate_t >.
Et en fait, c'est mathématiquement impossible à remplir les démandes de §27.4.3.2. Une des exigeances, c'est que fpos peut se convertir en streamsize et vice-versa sans perte de valeur ; c'est impossible, parce que la norme exige que streamsize soit un type entier, et elle exige également que fpos contient plus d'information que ce qui ne tient sur un type entier.
Il n'y a aussi rien qui impose une sémantique quelconque sur l'entier de streamsize. Mais là n'est pas le problème. Le problème, c'est que dans la pratique, le type entier standard sur beaucoup d'implémentations, c'est un type à 32 bits. Alors, comment est-ce que tu fais pour qu'il contient la taille d'un fichier, qui lui peut être bien supérieur en général à 2^32 ?
(En fait, historiquement, il n'a jamais été possible de convertir entre un fpos_t et un type entier. Je ne sais pas pourquoi la norme C++ a essayé l'impossible ici.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Frédéri MIAILLE" <bobranger@wanadoo.fr> wrote in message
news:<bls03h$2mqb$1@biggoron.nerim.net>...
"James Kanze" <kanze@alex.gabi-soft.fr> a écrit dans le message de
news:86brsv3evk.fsf@alex.gabi-soft.fr...
"Frédéri MIAILLE" <bobranger@wanadoo.fr> writes:
|> Et bien seekg()/seekp() peuvent placer le pointeur à la fin du
|> fichier et on peut utiliser tellg()/tellp() par la suite. Ce n'est
|> pas fiable ?
Non. Régarde le type de retour de tellg()/tellp(). Ce n'est pas un
type entier.
type streampos
et streampos est défini comme long.
J'aurais dû être plus précis. Si tu utilises <iostream> et al., il n'est
pas de type entier. Il est effectivement un long dans les iostream
classique de <iostream.h>
En <iostream>, c'est un traits::pos_type, qui doit être un streampos,
qui est un type qui doit remplir les démandes de §27.4.3.2 ; dans la
pratique, c'est prèsque toujours un typedef à fpos< mbstate_t >.
Et en fait, c'est mathématiquement impossible à remplir les démandes de
§27.4.3.2. Une des exigeances, c'est que fpos peut se convertir en
streamsize et vice-versa sans perte de valeur ; c'est impossible, parce
que la norme exige que streamsize soit un type entier, et elle exige
également que fpos contient plus d'information que ce qui ne tient sur
un type entier.
Il n'y a aussi rien qui impose une sémantique quelconque sur l'entier de
streamsize. Mais là n'est pas le problème. Le problème, c'est que dans
la pratique, le type entier standard sur beaucoup d'implémentations,
c'est un type à 32 bits. Alors, comment est-ce que tu fais pour qu'il
contient la taille d'un fichier, qui lui peut être bien supérieur en
général à 2^32 ?
(En fait, historiquement, il n'a jamais été possible de convertir entre
un fpos_t et un type entier. Je ne sais pas pourquoi la norme C++ a
essayé l'impossible ici.)
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Frédéri MIAILLE" wrote in message news:<bls03h$2mqb$...
"James Kanze" a écrit dans le message de news:
"Frédéri MIAILLE" writes:
|> Et bien seekg()/seekp() peuvent placer le pointeur à la fin du |> fichier et on peut utiliser tellg()/tellp() par la suite. Ce n'est |> pas fiable ?
Non. Régarde le type de retour de tellg()/tellp(). Ce n'est pas un type entier.
type streampos et streampos est défini comme long.
J'aurais dû être plus précis. Si tu utilises <iostream> et al., il n'est pas de type entier. Il est effectivement un long dans les iostream classique de <iostream.h>
En <iostream>, c'est un traits::pos_type, qui doit être un streampos, qui est un type qui doit remplir les démandes de §27.4.3.2 ; dans la pratique, c'est prèsque toujours un typedef à fpos< mbstate_t >.
Et en fait, c'est mathématiquement impossible à remplir les démandes de §27.4.3.2. Une des exigeances, c'est que fpos peut se convertir en streamsize et vice-versa sans perte de valeur ; c'est impossible, parce que la norme exige que streamsize soit un type entier, et elle exige également que fpos contient plus d'information que ce qui ne tient sur un type entier.
Il n'y a aussi rien qui impose une sémantique quelconque sur l'entier de streamsize. Mais là n'est pas le problème. Le problème, c'est que dans la pratique, le type entier standard sur beaucoup d'implémentations, c'est un type à 32 bits. Alors, comment est-ce que tu fais pour qu'il contient la taille d'un fichier, qui lui peut être bien supérieur en général à 2^32 ?
(En fait, historiquement, il n'a jamais été possible de convertir entre un fpos_t et un type entier. Je ne sais pas pourquoi la norme C++ a essayé l'impossible ici.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
kanze
Philippe Elie wrote in message news:...
Frédéri MIAILLE wrote:
"James Kanze" a écrit dans le message de news:
"Frédéri MIAILLE" writes:
|> Et bien seekg()/seekp() peuvent placer le pointeur à la fin du |> fichier et on peut utiliser tellg()/tellp() par la suite. Ce |> n'est pas fiable ?
Non. Régarde le type de retour de tellg()/tellp(). Ce n'est pas un type entier.
type streampos et streampos est défini comme long.
pas nécessairement, par exemple une implémentation utilise:
typedef fpos<mbstate_t> streampos;
Si la bibliothèque n'est pas complètement cassée, il doit y avoir deux implémentations des flux, une dans <iostream.h>, et une dans <iostream>, <ostream>, <istream>, etc. Dans le premier, streampos doit être un long, et dans le deuxième, il est forcement un type de classe, prèsque toujours fpos< mbstate_t >.
Le streampos doit contenir toutes les informations nécessaires pour pouvoir reprendre la lecture ou l'écriture à partir de l'endroit où on l'a lu (avec tellg/tellp). C-à-d donc la position dans le fichier (qui souvent ne tient pas sur un long), et l'état dans un caractère composé.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Philippe Elie <phil.el@wanadoo.fr> wrote in message
news:<3F81A81A.30203@wanadoo.fr>...
Frédéri MIAILLE wrote:
"James Kanze" <kanze@alex.gabi-soft.fr> a écrit dans le message de
news:86brsv3evk.fsf@alex.gabi-soft.fr...
"Frédéri MIAILLE" <bobranger@wanadoo.fr> writes:
|> Et bien seekg()/seekp() peuvent placer le pointeur à la fin du
|> fichier et on peut utiliser tellg()/tellp() par la suite. Ce
|> n'est pas fiable ?
Non. Régarde le type de retour de tellg()/tellp(). Ce n'est pas un
type entier.
type streampos
et streampos est défini comme long.
pas nécessairement, par exemple une
implémentation utilise:
typedef fpos<mbstate_t> streampos;
Si la bibliothèque n'est pas complètement cassée, il doit y avoir deux
implémentations des flux, une dans <iostream.h>, et une dans <iostream>,
<ostream>, <istream>, etc. Dans le premier, streampos doit être un long,
et dans le deuxième, il est forcement un type de classe, prèsque
toujours fpos< mbstate_t >.
Le streampos doit contenir toutes les informations nécessaires pour
pouvoir reprendre la lecture ou l'écriture à partir de l'endroit où on
l'a lu (avec tellg/tellp). C-à-d donc la position dans le fichier (qui
souvent ne tient pas sur un long), et l'état dans un caractère composé.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
|> Et bien seekg()/seekp() peuvent placer le pointeur à la fin du |> fichier et on peut utiliser tellg()/tellp() par la suite. Ce |> n'est pas fiable ?
Non. Régarde le type de retour de tellg()/tellp(). Ce n'est pas un type entier.
type streampos et streampos est défini comme long.
pas nécessairement, par exemple une implémentation utilise:
typedef fpos<mbstate_t> streampos;
Si la bibliothèque n'est pas complètement cassée, il doit y avoir deux implémentations des flux, une dans <iostream.h>, et une dans <iostream>, <ostream>, <istream>, etc. Dans le premier, streampos doit être un long, et dans le deuxième, il est forcement un type de classe, prèsque toujours fpos< mbstate_t >.
Le streampos doit contenir toutes les informations nécessaires pour pouvoir reprendre la lecture ou l'écriture à partir de l'endroit où on l'a lu (avec tellg/tellp). C-à-d donc la position dans le fichier (qui souvent ne tient pas sur un long), et l'état dans un caractère composé.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Alain Naigeon
"Gabriel Dos Reis" a écrit dans le message news:
writes:
[...]
| norme qu'on savait avoir un intérêt limité. Il y a beaucoup de domaines | qui n'ont pas besoin de complexe, par exemple ; il y a même probablement | plus de domaines qui ont besoin d'un type décimal.
C'est peu utile, en effet. Tellement peu utile que l'une des premières classes C++ développées par Stroustrup porte justement sur les complexes.
Peut-être, mais ce n'est pas la seule raison possible. Mettons que c'est aussi utile que la drosophile ou l'oscillateur harmonique (qui *sont* utiles, soit dit en passant).
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> a écrit dans le message
news: flr81pxvab.fsf@sel.cmla.ens-cachan.fr...
kanze@gabi-soft.fr writes:
[...]
| norme qu'on savait avoir un intérêt limité. Il y a beaucoup de domaines
| qui n'ont pas besoin de complexe, par exemple ; il y a même probablement
| plus de domaines qui ont besoin d'un type décimal.
C'est peu utile, en effet. Tellement peu utile que l'une des
premières classes C++ développées par Stroustrup porte justement sur
les complexes.
Peut-être, mais ce n'est pas la seule raison possible.
Mettons que c'est aussi utile que la drosophile ou
l'oscillateur harmonique (qui *sont* utiles, soit dit
en passant).
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
| norme qu'on savait avoir un intérêt limité. Il y a beaucoup de domaines | qui n'ont pas besoin de complexe, par exemple ; il y a même probablement | plus de domaines qui ont besoin d'un type décimal.
C'est peu utile, en effet. Tellement peu utile que l'une des premières classes C++ développées par Stroustrup porte justement sur les complexes.
Peut-être, mais ce n'est pas la seule raison possible. Mettons que c'est aussi utile que la drosophile ou l'oscillateur harmonique (qui *sont* utiles, soit dit en passant).
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Fabien LE LEZ
On 07 Oct 2003 11:16:12 +0200, Gabriel Dos Reis wrote:
C'est peu utile, en effet. Tellement peu utile que l'une des premières classes C++ développées par Stroustrup porte justement sur les complexes.
Peut-être parce que c'est relativement facile à écrire ?
| On 07 Oct 2003 11:16:12 +0200, Gabriel Dos Reis | wrote: | | >C'est peu utile, en effet. Tellement peu utile que l'une des | >premières classes C++ développées par Stroustrup porte justement sur | >les complexes. | | Peut-être parce que c'est relativement facile à écrire ?
comparé à quoi ? à vector<> ou pair<> ?
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| On 07 Oct 2003 11:16:12 +0200, Gabriel Dos Reis
| <dosreis@cmla.ens-cachan.fr> wrote:
|
| >C'est peu utile, en effet. Tellement peu utile que l'une des
| >premières classes C++ développées par Stroustrup porte justement sur
| >les complexes.
|
| Peut-être parce que c'est relativement facile à écrire ?
| On 07 Oct 2003 11:16:12 +0200, Gabriel Dos Reis | wrote: | | >C'est peu utile, en effet. Tellement peu utile que l'une des | >premières classes C++ développées par Stroustrup porte justement sur | >les complexes. | | Peut-être parce que c'est relativement facile à écrire ?
comparé à quoi ? à vector<> ou pair<> ?
-- Gaby
Gabriel Dos Reis
Fabien LE LEZ writes:
| On 07 Oct 2003 11:16:12 +0200, Gabriel Dos Reis | wrote: | | >C'est peu utile, en effet. Tellement peu utile que l'une des | >premières classes C++ développées par Stroustrup porte justement sur | >les complexes. | | Peut-être parce que c'est relativement facile à écrire ?
Mais alors que dire de sa bibliothèque task ?
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| On 07 Oct 2003 11:16:12 +0200, Gabriel Dos Reis
| <dosreis@cmla.ens-cachan.fr> wrote:
|
| >C'est peu utile, en effet. Tellement peu utile que l'une des
| >premières classes C++ développées par Stroustrup porte justement sur
| >les complexes.
|
| Peut-être parce que c'est relativement facile à écrire ?
| On 07 Oct 2003 11:16:12 +0200, Gabriel Dos Reis | wrote: | | >C'est peu utile, en effet. Tellement peu utile que l'une des | >premières classes C++ développées par Stroustrup porte justement sur | >les complexes. | | Peut-être parce que c'est relativement facile à écrire ?
Mais alors que dire de sa bibliothèque task ?
-- Gaby
kanze
Gabriel Dos Reis wrote in message news:...
writes:
[...]
| norme qu'on savait avoir un intérêt limité. Il y a beaucoup de | domaines qui n'ont pas besoin de complexe, par exemple ; il y a même | probablement plus de domaines qui ont besoin d'un type décimal.
C'est peu utile, en effet.
Si tu le dis. C'est toi l'expert dans ces domaines -- moi, je l'aurais cru très utile. Dans les domaines où c'est utiles -- je doute que celui qui fait les programmes de gestion en a beaucoup d'utilisation.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message
news:<flr81pxvab.fsf@sel.cmla.ens-cachan.fr>...
kanze@gabi-soft.fr writes:
[...]
| norme qu'on savait avoir un intérêt limité. Il y a beaucoup de
| domaines qui n'ont pas besoin de complexe, par exemple ; il y a même
| probablement plus de domaines qui ont besoin d'un type décimal.
C'est peu utile, en effet.
Si tu le dis. C'est toi l'expert dans ces domaines -- moi, je l'aurais
cru très utile. Dans les domaines où c'est utiles -- je doute que celui
qui fait les programmes de gestion en a beaucoup d'utilisation.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
| norme qu'on savait avoir un intérêt limité. Il y a beaucoup de | domaines qui n'ont pas besoin de complexe, par exemple ; il y a même | probablement plus de domaines qui ont besoin d'un type décimal.
C'est peu utile, en effet.
Si tu le dis. C'est toi l'expert dans ces domaines -- moi, je l'aurais cru très utile. Dans les domaines où c'est utiles -- je doute que celui qui fait les programmes de gestion en a beaucoup d'utilisation.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Gabriel Dos Reis
writes:
| Gabriel Dos Reis wrote in message | news:... | > writes: | | > [...] | | > | norme qu'on savait avoir un intérêt limité. Il y a beaucoup de | > | domaines qui n'ont pas besoin de complexe, par exemple ; il y a même | > | probablement plus de domaines qui ont besoin d'un type décimal. | | > C'est peu utile, en effet. | | Si tu le dis. C'est toi l'expert dans ces domaines -- moi, je l'aurais | cru très utile.
À l'évidence, c'était trop subtile.
| Dans les domaines où c'est utiles -- je doute que celui | qui fait les programmes de gestion en a beaucoup d'utilisation.
-- Gaby
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message
| news:<flr81pxvab.fsf@sel.cmla.ens-cachan.fr>...
| > kanze@gabi-soft.fr writes:
|
| > [...]
|
| > | norme qu'on savait avoir un intérêt limité. Il y a beaucoup de
| > | domaines qui n'ont pas besoin de complexe, par exemple ; il y a même
| > | probablement plus de domaines qui ont besoin d'un type décimal.
|
| > C'est peu utile, en effet.
|
| Si tu le dis. C'est toi l'expert dans ces domaines -- moi, je l'aurais
| cru très utile.
À l'évidence, c'était trop subtile.
| Dans les domaines où c'est utiles -- je doute que celui
| qui fait les programmes de gestion en a beaucoup d'utilisation.
| Gabriel Dos Reis wrote in message | news:... | > writes: | | > [...] | | > | norme qu'on savait avoir un intérêt limité. Il y a beaucoup de | > | domaines qui n'ont pas besoin de complexe, par exemple ; il y a même | > | probablement plus de domaines qui ont besoin d'un type décimal. | | > C'est peu utile, en effet. | | Si tu le dis. C'est toi l'expert dans ces domaines -- moi, je l'aurais | cru très utile.
À l'évidence, c'était trop subtile.
| Dans les domaines où c'est utiles -- je doute que celui | qui fait les programmes de gestion en a beaucoup d'utilisation.
-- Gaby
Christophe de Vienne
James Kanze wrote:
Pour gérer les fichiers en C++, il existe fstream, il me semble. Pour la reste (lire des répertoires, etc.), c'est tellement facile à faire une classe d'interface portable pour tout ça, que le marché ne l'a même pas trouvé la peine d'en faire une tout faite.
Ben il y a quand même boost::filesystem qui est pas mal non ?
(Dietmar Kühl y avait commencé, dans le cadre de Boost, mais je ne crois pas qu'il a eu le temps d'y aller au bout.)
Apparemment ça a été terminé : "The directory_iterator and filesystem_error classes were based on prior work from Dietmar Kühl, as modified by Jan Langer." (citation du lien ci-dessus).
A+
Christophe
James Kanze wrote:
Pour gérer les fichiers en C++, il existe fstream, il me semble. Pour
la reste (lire des répertoires, etc.), c'est tellement facile à
faire une classe d'interface portable pour tout ça, que le marché
ne l'a même pas trouvé la peine d'en faire une tout faite.
Ben il y a quand même boost::filesystem qui est pas mal non ?
(Dietmar Kühl y avait commencé, dans le cadre de Boost, mais je ne
crois pas qu'il a eu le temps d'y aller au bout.)
Apparemment ça a été terminé :
"The directory_iterator and filesystem_error classes were based on prior
work from Dietmar Kühl, as modified by Jan Langer." (citation du lien
ci-dessus).
Pour gérer les fichiers en C++, il existe fstream, il me semble. Pour la reste (lire des répertoires, etc.), c'est tellement facile à faire une classe d'interface portable pour tout ça, que le marché ne l'a même pas trouvé la peine d'en faire une tout faite.
Ben il y a quand même boost::filesystem qui est pas mal non ?
(Dietmar Kühl y avait commencé, dans le cadre de Boost, mais je ne crois pas qu'il a eu le temps d'y aller au bout.)
Apparemment ça a été terminé : "The directory_iterator and filesystem_error classes were based on prior work from Dietmar Kühl, as modified by Jan Langer." (citation du lien ci-dessus).
A+
Christophe
kanze
Christophe de Vienne wrote in message news:<newscache$mkpwmh$tzo$...
James Kanze wrote:
Pour gérer les fichiers en C++, il existe fstream, il me semble. Pour la reste (lire des répertoires, etc.), c'est tellement facile à faire une classe d'interface portable pour tout ça, que le marché ne l'a même pas trouvé la peine d'en faire une tout faite.
Ben il y a quand même boost::filesystem qui est pas mal non ?
(Dietmar Kühl y avait commencé, dans le cadre de Boost, mais je ne crois pas qu'il a eu le temps d'y aller au bout.)
Apparemment ça a été terminé : "The directory_iterator and filesystem_error classes were based on prior work from Dietmar Kühl, as modified by Jan Langer." (citation du lien ci-dessus).
En effet.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Christophe de Vienne <cdevienne@alphacent.com> wrote in message
news:<newscache$mkpwmh$tzo$1@guronzan.alphacent.com>...
James Kanze wrote:
Pour gérer les fichiers en C++, il existe fstream, il me semble.
Pour la reste (lire des répertoires, etc.), c'est tellement facile à
faire une classe d'interface portable pour tout ça, que le marché ne
l'a même pas trouvé la peine d'en faire une tout faite.
Ben il y a quand même boost::filesystem qui est pas mal non ?
(Dietmar Kühl y avait commencé, dans le cadre de Boost, mais je ne
crois pas qu'il a eu le temps d'y aller au bout.)
Apparemment ça a été terminé :
"The directory_iterator and filesystem_error classes were based on
prior work from Dietmar Kühl, as modified by Jan Langer." (citation du
lien ci-dessus).
En effet.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Christophe de Vienne wrote in message news:<newscache$mkpwmh$tzo$...
James Kanze wrote:
Pour gérer les fichiers en C++, il existe fstream, il me semble. Pour la reste (lire des répertoires, etc.), c'est tellement facile à faire une classe d'interface portable pour tout ça, que le marché ne l'a même pas trouvé la peine d'en faire une tout faite.
Ben il y a quand même boost::filesystem qui est pas mal non ?
(Dietmar Kühl y avait commencé, dans le cadre de Boost, mais je ne crois pas qu'il a eu le temps d'y aller au bout.)
Apparemment ça a été terminé : "The directory_iterator and filesystem_error classes were based on prior work from Dietmar Kühl, as modified by Jan Langer." (citation du lien ci-dessus).
En effet.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
