Je cherche à savoir quelle est l'API d'un lecteur de cassettes de type DAT
sous windows (2000). Peut-on voir une cassette comme un répertoire contenant
des fichiers ou est-on seulement capable d'écrire des fichiers les uns à la
suite des autres ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Frédéri MIAILLE
"Jean-Philippe Iafrate" a écrit dans le message de news:biginf$6qr$
Bonjour,
Je cherche à savoir quelle est l'API d'un lecteur de cassettes de type DAT sous windows (2000).
uh !!?? Pas d'API, juste des fonctions de l'API Windows qui permettent de gérer ça.
Peut-on voir une cassette comme un répertoire contenant des fichiers ou est-on seulement capable d'écrire des fichiers les uns à
la
suite des autres ?
Si ça marche sur un ordinateur ça veut dire que oui, tu ne crois pas ? Ton lecteur DAT est un lecteur. En C++ : ifstream SOURCE("J:/File", ios::nocreate); ouvre le fichier File sur le lecteur J qui est ton lecteur de cassette. voir doc <fstream.h>.
"Jean-Philippe Iafrate" <jeanTIRETphilippePOINTiafrate@wanadoo.fr> a écrit
dans le message de news:biginf$6qr$1@news-reader1.wanadoo.fr...
Bonjour,
Je cherche à savoir quelle est l'API d'un lecteur de cassettes de type DAT
sous windows (2000).
uh !!??
Pas d'API, juste des fonctions de l'API Windows qui permettent de gérer ça.
Peut-on voir une cassette comme un répertoire contenant
des fichiers ou est-on seulement capable d'écrire des fichiers les uns à
la
suite des autres ?
Si ça marche sur un ordinateur ça veut dire que oui, tu ne crois pas ?
Ton lecteur DAT est un lecteur.
En C++ :
ifstream SOURCE("J:/File", ios::nocreate);
ouvre le fichier File sur le lecteur J qui est ton lecteur de cassette.
voir doc <fstream.h>.
"Jean-Philippe Iafrate" a écrit dans le message de news:biginf$6qr$
Bonjour,
Je cherche à savoir quelle est l'API d'un lecteur de cassettes de type DAT sous windows (2000).
uh !!?? Pas d'API, juste des fonctions de l'API Windows qui permettent de gérer ça.
Peut-on voir une cassette comme un répertoire contenant des fichiers ou est-on seulement capable d'écrire des fichiers les uns à
la
suite des autres ?
Si ça marche sur un ordinateur ça veut dire que oui, tu ne crois pas ? Ton lecteur DAT est un lecteur. En C++ : ifstream SOURCE("J:/File", ios::nocreate); ouvre le fichier File sur le lecteur J qui est ton lecteur de cassette. voir doc <fstream.h>.
A merde ! je me suis planté de news-group. Bon, dans l'API windows, il existe une gestion de fichiers un peu plus "évoluée" que ifstream. Mais il est clair que un petit tour sur la msdn devrait être relativement fructueuse.
"Frédéri MIAILLE" a écrit dans le message de news:bihmdr$c3u$
"Jean-Philippe Iafrate" a écrit dans le message de news:biginf$6qr$ > Bonjour, > > Je cherche à savoir quelle est l'API d'un lecteur de cassettes de type
DAT
> sous windows (2000). uh !!?? Pas d'API, juste des fonctions de l'API Windows qui permettent de gérer
ça.
> Peut-on voir une cassette comme un répertoire contenant > des fichiers ou est-on seulement capable d'écrire des fichiers les uns à la > suite des autres ? Si ça marche sur un ordinateur ça veut dire que oui, tu ne crois pas ? Ton lecteur DAT est un lecteur. En C++ : ifstream SOURCE("J:/File", ios::nocreate); ouvre le fichier File sur le lecteur J qui est ton lecteur de cassette. voir doc <fstream.h>.
A merde ! je me suis planté de news-group.
Bon, dans l'API windows, il existe une gestion de fichiers un peu plus
"évoluée" que ifstream.
Mais il est clair que un petit tour sur la msdn devrait être relativement
fructueuse.
"Frédéri MIAILLE" <bobranger_no_spam@wanadoo.fr> a écrit dans le message de
news:bihmdr$c3u$1@biggoron.nerim.net...
"Jean-Philippe Iafrate" <jeanTIRETphilippePOINTiafrate@wanadoo.fr> a écrit
dans le message de news:biginf$6qr$1@news-reader1.wanadoo.fr...
> Bonjour,
>
> Je cherche à savoir quelle est l'API d'un lecteur de cassettes de type
DAT
> sous windows (2000).
uh !!??
Pas d'API, juste des fonctions de l'API Windows qui permettent de gérer
ça.
> Peut-on voir une cassette comme un répertoire contenant
> des fichiers ou est-on seulement capable d'écrire des fichiers les uns à
la
> suite des autres ?
Si ça marche sur un ordinateur ça veut dire que oui, tu ne crois pas ?
Ton lecteur DAT est un lecteur.
En C++ :
ifstream SOURCE("J:/File", ios::nocreate);
ouvre le fichier File sur le lecteur J qui est ton lecteur de cassette.
voir doc <fstream.h>.
A merde ! je me suis planté de news-group. Bon, dans l'API windows, il existe une gestion de fichiers un peu plus "évoluée" que ifstream. Mais il est clair que un petit tour sur la msdn devrait être relativement fructueuse.
"Frédéri MIAILLE" a écrit dans le message de news:bihmdr$c3u$
"Jean-Philippe Iafrate" a écrit dans le message de news:biginf$6qr$ > Bonjour, > > Je cherche à savoir quelle est l'API d'un lecteur de cassettes de type
DAT
> sous windows (2000). uh !!?? Pas d'API, juste des fonctions de l'API Windows qui permettent de gérer
ça.
> Peut-on voir une cassette comme un répertoire contenant > des fichiers ou est-on seulement capable d'écrire des fichiers les uns à la > suite des autres ? Si ça marche sur un ordinateur ça veut dire que oui, tu ne crois pas ? Ton lecteur DAT est un lecteur. En C++ : ifstream SOURCE("J:/File", ios::nocreate); ouvre le fichier File sur le lecteur J qui est ton lecteur de cassette. voir doc <fstream.h>.
A merde ! je me suis planté de news-group. Bon, dans l'API windows, il existe une gestion de fichiers un peu plus "évoluée" que ifstream.
Question de point de vue : Je ne connais rien dans l'API Windows qui permette de faire proprement et de manière fiable de la conversion de données en flux d'octet (à la printf/scanf, mais en fiable et sécurisé!), alors que c'est précisémment ce que propose fstream.
Arnaud MVP - VC
Frédéri MIAILLE wrote:
A merde ! je me suis planté de news-group.
Bon, dans l'API windows, il existe une gestion de fichiers un peu plus
"évoluée" que ifstream.
Question de point de vue : Je ne connais rien dans l'API Windows qui
permette de faire proprement et de manière fiable de la conversion de
données en flux d'octet (à la printf/scanf, mais en fiable et sécurisé!),
alors que c'est précisémment ce que propose fstream.
A merde ! je me suis planté de news-group. Bon, dans l'API windows, il existe une gestion de fichiers un peu plus "évoluée" que ifstream.
Question de point de vue : Je ne connais rien dans l'API Windows qui permette de faire proprement et de manière fiable de la conversion de données en flux d'octet (à la printf/scanf, mais en fiable et sécurisé!), alors que c'est précisémment ce que propose fstream.
Arnaud MVP - VC
Jean-Philippe Iafrate
"Frédéri MIAILLE" a écrit dans le message de news:bihmdr$c3u$
"Jean-Philippe Iafrate" a écrit dans le message de news:biginf$6qr$ > Bonjour, > > Je cherche à savoir quelle est l'API d'un lecteur de cassettes de type
DAT
> sous windows (2000). uh !!?? Pas d'API, juste des fonctions de l'API Windows qui permettent de gérer
ça.
> Peut-on voir une cassette comme un répertoire contenant > des fichiers ou est-on seulement capable d'écrire des fichiers les uns à la > suite des autres ? Si ça marche sur un ordinateur ça veut dire que oui, tu ne crois pas ? Ton lecteur DAT est un lecteur. En C++ : ifstream SOURCE("J:/File", ios::nocreate); ouvre le fichier File sur le lecteur J qui est ton lecteur de cassette. voir doc <fstream.h>.
Merci pour ta réponse.
Je suis un peu surpris cependant. Je connais bien le monde Unix dans lequel j'ai manipulé des périphériques de type Hexabyte et j'ai imaginé que ça ressemblait à du DAT. Tout ce que l'on savait faire (sur machine Convex) c'était écrire des fichiers les uns à la suite des autres (à condition d'utiliser le device no-rewind). Avec des fonctions ioctl on pouvait rembobiner la cassette et faire des sauts de fichier à fichier. En plus il y avait des contraintes sur la taille des blocs que l'on écrivait. Et on n'avait pas de structure de type répertoire donc pas moyen d'accéder à un fichier par son nom.
JP
"Frédéri MIAILLE" <bobranger_no_spam@wanadoo.fr> a écrit dans le message de
news:bihmdr$c3u$1@biggoron.nerim.net...
"Jean-Philippe Iafrate" <jeanTIRETphilippePOINTiafrate@wanadoo.fr> a écrit
dans le message de news:biginf$6qr$1@news-reader1.wanadoo.fr...
> Bonjour,
>
> Je cherche à savoir quelle est l'API d'un lecteur de cassettes de type
DAT
> sous windows (2000).
uh !!??
Pas d'API, juste des fonctions de l'API Windows qui permettent de gérer
ça.
> Peut-on voir une cassette comme un répertoire contenant
> des fichiers ou est-on seulement capable d'écrire des fichiers les uns à
la
> suite des autres ?
Si ça marche sur un ordinateur ça veut dire que oui, tu ne crois pas ?
Ton lecteur DAT est un lecteur.
En C++ :
ifstream SOURCE("J:/File", ios::nocreate);
ouvre le fichier File sur le lecteur J qui est ton lecteur de cassette.
voir doc <fstream.h>.
Merci pour ta réponse.
Je suis un peu surpris cependant. Je connais bien le monde Unix dans lequel
j'ai manipulé des périphériques de type Hexabyte et j'ai imaginé que ça
ressemblait à du DAT. Tout ce que l'on savait faire (sur machine Convex)
c'était écrire des fichiers les uns à la suite des autres (à condition
d'utiliser le device no-rewind). Avec des fonctions ioctl on pouvait
rembobiner la cassette et faire des sauts de fichier à fichier. En plus il y
avait des contraintes sur la taille des blocs que l'on écrivait. Et on
n'avait pas de structure de type répertoire donc pas moyen d'accéder à un
fichier par son nom.
"Frédéri MIAILLE" a écrit dans le message de news:bihmdr$c3u$
"Jean-Philippe Iafrate" a écrit dans le message de news:biginf$6qr$ > Bonjour, > > Je cherche à savoir quelle est l'API d'un lecteur de cassettes de type
DAT
> sous windows (2000). uh !!?? Pas d'API, juste des fonctions de l'API Windows qui permettent de gérer
ça.
> Peut-on voir une cassette comme un répertoire contenant > des fichiers ou est-on seulement capable d'écrire des fichiers les uns à la > suite des autres ? Si ça marche sur un ordinateur ça veut dire que oui, tu ne crois pas ? Ton lecteur DAT est un lecteur. En C++ : ifstream SOURCE("J:/File", ios::nocreate); ouvre le fichier File sur le lecteur J qui est ton lecteur de cassette. voir doc <fstream.h>.
Merci pour ta réponse.
Je suis un peu surpris cependant. Je connais bien le monde Unix dans lequel j'ai manipulé des périphériques de type Hexabyte et j'ai imaginé que ça ressemblait à du DAT. Tout ce que l'on savait faire (sur machine Convex) c'était écrire des fichiers les uns à la suite des autres (à condition d'utiliser le device no-rewind). Avec des fonctions ioctl on pouvait rembobiner la cassette et faire des sauts de fichier à fichier. En plus il y avait des contraintes sur la taille des blocs que l'on écrivait. Et on n'avait pas de structure de type répertoire donc pas moyen d'accéder à un fichier par son nom.
Je suis un peu surpris cependant. Je connais bien le monde Unix dans
lequel
j'ai manipulé des périphériques de type Hexabyte
Je ne connais pas Hexabyte.
et j'ai imaginé que ça ressemblait à du DAT. Tout ce que l'on savait faire (sur machine Convex)
Je ne connais pas Convex.
c'était écrire des fichiers les uns à la suite des autres (à condition d'utiliser le device no-rewind). Avec des fonctions ioctl on pouvait rembobiner la cassette et faire des sauts de fichier à fichier. En plus il
y
avait des contraintes sur la taille des blocs que l'on écrivait. Et on n'avait pas de structure de type répertoire donc pas moyen d'accéder à un fichier par son nom.
Visiblement sur bande, il y a des contraintes de gestion de fichiers. Apparemment et si j'ai bien deviné, les fichiers ne s'accèdent pas comme ça mais dans un certain ordre. Sur disque dur, jusqu'à présent, pour moi, c'étai transparent. Je le savais, j'aurai dû commencer l'assembleur sur mon Oric atmos et sur mon Atari.
Je suis navré mais je n'ai pas cette expérience là et je serai certainement de mauvais ou d'instable conseil. J'aime bien donner des idées sur ce dont je suis relativement sûr. Et quand je suis sur terrain un peu inconnu, je n'oublie pas de le préciser. Je te recommandais fstream car je sais que ça gère des choses standard et à très bas niveau et également les accès binaires, ce qui semblait correspondre à ce que tu recherchais. De plus, comme le disait Arnaud, les flux sont sécurisés (ce que j'ignorai et ce que je ne comprend pas d'ailleurs -Arnaud, tu m'explique ?- ).
Donc, solution, voir les programmes de l'époque des bandes&cassettes certainement rédigés en C. Ou éventuellement trouver des développeurs assez *âgés* (si vous avez des cheveux blancs, ne le prenez pas mal, l'âge c'est dans la tête) pour avoir connu ce système.
Je suis un peu surpris cependant. Je connais bien le monde Unix dans
lequel
j'ai manipulé des périphériques de type Hexabyte
Je ne connais pas Hexabyte.
et j'ai imaginé que ça
ressemblait à du DAT. Tout ce que l'on savait faire (sur machine Convex)
Je ne connais pas Convex.
c'était écrire des fichiers les uns à la suite des autres (à condition
d'utiliser le device no-rewind). Avec des fonctions ioctl on pouvait
rembobiner la cassette et faire des sauts de fichier à fichier. En plus il
y
avait des contraintes sur la taille des blocs que l'on écrivait. Et on
n'avait pas de structure de type répertoire donc pas moyen d'accéder à un
fichier par son nom.
Visiblement sur bande, il y a des contraintes de gestion de fichiers.
Apparemment et si j'ai bien deviné, les fichiers ne s'accèdent pas comme ça
mais dans un certain ordre. Sur disque dur, jusqu'à présent, pour moi,
c'étai transparent.
Je le savais, j'aurai dû commencer l'assembleur sur mon Oric atmos et sur
mon Atari.
Je suis navré mais je n'ai pas cette expérience là et je serai certainement
de mauvais ou d'instable conseil.
J'aime bien donner des idées sur ce dont je suis relativement sûr.
Et quand je suis sur terrain un peu inconnu, je n'oublie pas de le préciser.
Je te recommandais fstream car je sais que ça gère des choses standard et à
très bas niveau et également les accès binaires, ce qui semblait
correspondre à ce que tu recherchais. De plus, comme le disait Arnaud, les
flux sont sécurisés (ce que j'ignorai et ce que je ne comprend pas
d'ailleurs -Arnaud, tu m'explique ?- ).
Donc, solution, voir les programmes de l'époque des bandes&cassettes
certainement rédigés en C. Ou éventuellement trouver des développeurs assez
*âgés* (si vous avez des cheveux blancs, ne le prenez pas mal, l'âge c'est
dans la tête) pour avoir connu ce système.
Je suis un peu surpris cependant. Je connais bien le monde Unix dans
lequel
j'ai manipulé des périphériques de type Hexabyte
Je ne connais pas Hexabyte.
et j'ai imaginé que ça ressemblait à du DAT. Tout ce que l'on savait faire (sur machine Convex)
Je ne connais pas Convex.
c'était écrire des fichiers les uns à la suite des autres (à condition d'utiliser le device no-rewind). Avec des fonctions ioctl on pouvait rembobiner la cassette et faire des sauts de fichier à fichier. En plus il
y
avait des contraintes sur la taille des blocs que l'on écrivait. Et on n'avait pas de structure de type répertoire donc pas moyen d'accéder à un fichier par son nom.
Visiblement sur bande, il y a des contraintes de gestion de fichiers. Apparemment et si j'ai bien deviné, les fichiers ne s'accèdent pas comme ça mais dans un certain ordre. Sur disque dur, jusqu'à présent, pour moi, c'étai transparent. Je le savais, j'aurai dû commencer l'assembleur sur mon Oric atmos et sur mon Atari.
Je suis navré mais je n'ai pas cette expérience là et je serai certainement de mauvais ou d'instable conseil. J'aime bien donner des idées sur ce dont je suis relativement sûr. Et quand je suis sur terrain un peu inconnu, je n'oublie pas de le préciser. Je te recommandais fstream car je sais que ça gère des choses standard et à très bas niveau et également les accès binaires, ce qui semblait correspondre à ce que tu recherchais. De plus, comme le disait Arnaud, les flux sont sécurisés (ce que j'ignorai et ce que je ne comprend pas d'ailleurs -Arnaud, tu m'explique ?- ).
Donc, solution, voir les programmes de l'époque des bandes&cassettes certainement rédigés en C. Ou éventuellement trouver des développeurs assez *âgés* (si vous avez des cheveux blancs, ne le prenez pas mal, l'âge c'est dans la tête) pour avoir connu ce système.
"Frédéri MIAILLE" a écrit dans le message de news:bj836u$8qg$ [...]
> j'ai manipulé des périphériques de type Hexabyte Je ne connais pas Hexabyte.
Les cassettes sont un peu plus grande qu'une cassette de caméra vidéo.
> et j'ai imaginé que ça > ressemblait à du DAT. Tout ce que l'on savait faire (sur machine Convex) Je ne connais pas Convex.
C'est un mini super calculateur (ça date seulement des années 90 ); ) [...]
Visiblement sur bande, il y a des contraintes de gestion de fichiers. Apparemment et si j'ai bien deviné, les fichiers ne s'accèdent pas comme
ça
mais dans un certain ordre. Sur disque dur, jusqu'à présent, pour moi, c'étai transparent.
Même chez Microsoft, un dispositif de type bande est essentiellement séquentiel. [...]
Donc, solution, voir les programmes de l'époque des bandes&cassettes certainement rédigés en C.
L'API Win32 (en C) existe toujours non (CreateFile, WriteFile) ?
Ou éventuellement trouver des développeurs assez *âgés* (si vous avez des cheveux blancs, ne le prenez pas mal, l'âge c'est dans la tête) pour avoir connu ce système.
Je n'ai "que" la quarantaine donc je ne mes sens pas concerné ); En tous cas, merci pour la réponse¨.
-- JP
"Frédéri MIAILLE" <bobranger@wanadoo.fr> a écrit dans le message de
news:bj836u$8qg$1@news-reader1.wanadoo.fr...
[...]
> j'ai manipulé des périphériques de type Hexabyte
Je ne connais pas Hexabyte.
Les cassettes sont un peu plus grande qu'une cassette de caméra vidéo.
> et j'ai imaginé que ça
> ressemblait à du DAT. Tout ce que l'on savait faire (sur machine Convex)
Je ne connais pas Convex.
C'est un mini super calculateur (ça date seulement des années 90 ); )
[...]
Visiblement sur bande, il y a des contraintes de gestion de fichiers.
Apparemment et si j'ai bien deviné, les fichiers ne s'accèdent pas comme
ça
mais dans un certain ordre. Sur disque dur, jusqu'à présent, pour moi,
c'étai transparent.
Même chez Microsoft, un dispositif de type bande est essentiellement
séquentiel.
[...]
Donc, solution, voir les programmes de l'époque des bandes&cassettes
certainement rédigés en C.
L'API Win32 (en C) existe toujours non (CreateFile, WriteFile) ?
Ou éventuellement trouver des développeurs assez
*âgés* (si vous avez des cheveux blancs, ne le prenez pas mal, l'âge c'est
dans la tête) pour avoir connu ce système.
Je n'ai "que" la quarantaine donc je ne mes sens pas concerné );
En tous cas, merci pour la réponse¨.
"Frédéri MIAILLE" a écrit dans le message de news:bj836u$8qg$ [...]
> j'ai manipulé des périphériques de type Hexabyte Je ne connais pas Hexabyte.
Les cassettes sont un peu plus grande qu'une cassette de caméra vidéo.
> et j'ai imaginé que ça > ressemblait à du DAT. Tout ce que l'on savait faire (sur machine Convex) Je ne connais pas Convex.
C'est un mini super calculateur (ça date seulement des années 90 ); ) [...]
Visiblement sur bande, il y a des contraintes de gestion de fichiers. Apparemment et si j'ai bien deviné, les fichiers ne s'accèdent pas comme
ça
mais dans un certain ordre. Sur disque dur, jusqu'à présent, pour moi, c'étai transparent.
Même chez Microsoft, un dispositif de type bande est essentiellement séquentiel. [...]
Donc, solution, voir les programmes de l'époque des bandes&cassettes certainement rédigés en C.
L'API Win32 (en C) existe toujours non (CreateFile, WriteFile) ?
Ou éventuellement trouver des développeurs assez *âgés* (si vous avez des cheveux blancs, ne le prenez pas mal, l'âge c'est dans la tête) pour avoir connu ce système.
Je n'ai "que" la quarantaine donc je ne mes sens pas concerné ); En tous cas, merci pour la réponse¨.
-- JP
adebaene
"Frédéri MIAILLE" wrote in message news:<bj836u$8qg$...
De plus, comme le disait Arnaud, les flux sont sécurisés (ce que j'ignorai et ce que je ne comprend pas d'ailleurs -Arnaud, tu m'explique ?- ).
Pour faire de l'E/S formatté, les solutions autres que les ofstreams présentent plusieurs dangers : - buffers overrun (le plus évident, et la source de tant de virus). Par exemple : char buffer[512]; fscanf (fichier, "%s", buffer); Inutile de parler des dangers de ce genre de truc. L'utilisation de getline avec les flux C++ résoud le problème.
- Autre problème de la famille printf/scanf : il n'y a aucun contrôle de type des paramètres, et tu peux te gourrer sur la chaine de formattage: int i=5; printf("%f"; i); //oups, erreur pas détectée par le compilo.
- De plus, les flux C++ permettent de définir les operateurs << et >> pour ses propres types complexes, et permettent donc d'étendre le mécanisme d'I/O. On peut aussi éventuellement définir de nouveaux opérateurs de formattage.
Enfin, si on s'intéresse aux mécanismes internes, les flux dissocient le formattage des données (classe stream) du stockage des octets non formattés (classe streambuf), ce qui permet relativement facilement de faire, par exemple, un streambuf pour les sockets et de l'intégrer de manière transparente avec les flux standards. Enfin, ca c'est pour la théorie parce qu'en pratique, l'implémentation de streambuf est tellement tordue que c'en est difficilement utilisable.
Arnaud MVP - VC
"Frédéri MIAILLE" <bobranger@wanadoo.fr> wrote in message news:<bj836u$8qg$1@news-reader1.wanadoo.fr>...
De plus, comme le disait Arnaud, les
flux sont sécurisés (ce que j'ignorai et ce que je ne comprend pas
d'ailleurs -Arnaud, tu m'explique ?- ).
Pour faire de l'E/S formatté, les solutions autres que les ofstreams
présentent plusieurs dangers :
- buffers overrun (le plus évident, et la source de tant de virus).
Par exemple :
char buffer[512];
fscanf (fichier, "%s", buffer);
Inutile de parler des dangers de ce genre de truc.
L'utilisation de getline avec les flux C++ résoud le problème.
- Autre problème de la famille printf/scanf : il n'y a aucun contrôle
de type des paramètres, et tu peux te gourrer sur la chaine de
formattage:
int i=5;
printf("%f"; i); //oups, erreur pas détectée par le compilo.
- De plus, les flux C++ permettent de définir les operateurs << et >>
pour ses propres types complexes, et permettent donc d'étendre le
mécanisme d'I/O. On peut aussi éventuellement définir de nouveaux
opérateurs de formattage.
Enfin, si on s'intéresse aux mécanismes internes, les flux dissocient
le formattage des données (classe stream) du stockage des octets non
formattés (classe streambuf), ce qui permet relativement facilement de
faire, par exemple, un streambuf pour les sockets et de l'intégrer de
manière transparente avec les flux standards. Enfin, ca c'est pour la
théorie parce qu'en pratique, l'implémentation de streambuf est
tellement tordue que c'en est difficilement utilisable.
"Frédéri MIAILLE" wrote in message news:<bj836u$8qg$...
De plus, comme le disait Arnaud, les flux sont sécurisés (ce que j'ignorai et ce que je ne comprend pas d'ailleurs -Arnaud, tu m'explique ?- ).
Pour faire de l'E/S formatté, les solutions autres que les ofstreams présentent plusieurs dangers : - buffers overrun (le plus évident, et la source de tant de virus). Par exemple : char buffer[512]; fscanf (fichier, "%s", buffer); Inutile de parler des dangers de ce genre de truc. L'utilisation de getline avec les flux C++ résoud le problème.
- Autre problème de la famille printf/scanf : il n'y a aucun contrôle de type des paramètres, et tu peux te gourrer sur la chaine de formattage: int i=5; printf("%f"; i); //oups, erreur pas détectée par le compilo.
- De plus, les flux C++ permettent de définir les operateurs << et >> pour ses propres types complexes, et permettent donc d'étendre le mécanisme d'I/O. On peut aussi éventuellement définir de nouveaux opérateurs de formattage.
Enfin, si on s'intéresse aux mécanismes internes, les flux dissocient le formattage des données (classe stream) du stockage des octets non formattés (classe streambuf), ce qui permet relativement facilement de faire, par exemple, un streambuf pour les sockets et de l'intégrer de manière transparente avec les flux standards. Enfin, ca c'est pour la théorie parce qu'en pratique, l'implémentation de streambuf est tellement tordue que c'en est difficilement utilisable.
