Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Visual C++ 6.0 ; debug ; fichier

Visual C++ 6.0 ; debug ; fichier

29 réponses
Avatar
Laurent
c'est simple, ce programme fonctionne normallement sans debug, et en debug,
il me trouve un eof() des le premier input.read()


JE NE COMPRENDS PAS !!!!!!!!!!!

merci.


#include <iostream.h>
#include <fstream.h>
#include <stdio.h>

void main(void)
{

ifstream input;
char Carac[1];
int Taille;

input.open("fichier.txt",ios::in);

do
{
input.read(Carac, sizeof(Carac));
if(input.good())
{
Taille++;
}
}
while(!input.eof());

cout << "Taille : " << Taille << " octets.";


}
Signaler un problème avec ce contenu

9 réponses

Supprimer
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
1 2 3
Avatar
Michel Michaud
Dans news:oXiMb.3529$, Michel
ce qu'on pense est un peu différent (certains ont avancé que ça ne
renvoyait pas une valeur numérique, confondant donc fgetpos et
ftell...).


Désolé, ce n'est pas vraiment ce qui a été dit... (Loïc parlait
de la valeur de retour de seek probablement)

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Avatar
Gabriel Dos Reis
"Michel Michaud" writes:

| Dans news:, James
| > "Michel Michaud" writes:
| >>> Je lis ceci dans la norme C89 (la seule norme C que j'ai et il me
| >>> semble celle sur laquelle est basé C++) :
| >
| >>> The ftell function obtains the current value of the file
| >>> position indicator [...]. For a binary stream, the value is
| >>> the number of characters from the beginning of the file. [...]
| >
| >>> Il me semble donc qu'avec un stream en mode binaire, ça
| >>> fonctionne pas si mal. Et ftell renvoie un long par ailleur...
| >
| > Et voilà le problème. Sur pas mal de systèmes, encore
| > aujourd'hui, un long, ça n'a que 32 bits. Or qu'un système
| > aujourd'hui qui limite la taille d'un fichier à 2^32, c'est vraiment
| > taré (et je n'en connais pas). Alors, quoiqu'en dit la norme...
|
| Les fichiers de plus de 4 gigaoctets sont plutôt rares sur ma
| machine (je n'en ai aucun pour le moment !). Pas sur la tienne ?

en conséquence, tu utilises un système vraiment taré et James ne le
connait pas. C'est faux ? ;-p

-- Gaby
Avatar
Michel Michaud
Dans news:, Gabriel Dos
"Michel Michaud" writes:

Dans news:, James
Et voilà le problème. Sur pas mal de systèmes, encore
aujourd'hui, un long, ça n'a que 32 bits. Or qu'un système
aujourd'hui qui limite la taille d'un fichier à 2^32, c'est
vraiment taré (et je n'en connais pas). Alors, quoiqu'en dit la
norme...


Les fichiers de plus de 4 gigaoctets sont plutôt rares sur ma
machine (je n'en ai aucun pour le moment !). Pas sur la tienne ?


en conséquence, tu utilises un système vraiment taré et James ne le
connait pas. C'est faux ? ;-p


Mon système permet des fichiers plus gros, mais moi je n'en ai
pas vraiment besoin (jusqu'à maintenant). J'imagine qu'un système
taré (aujourd'hui) serait un système qui ne permettrait que des
fichiers occupant 4 giga ou plus :-)

Et je crois que James connaît mon système d'exploitation... un
peu, au moins de nom !

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/



Avatar
kanze
"Michel Michaud" wrote in message
news:<oXiMb.3529$...
Dans news:, James
"Michel Michaud" writes:
Je lis ceci dans la norme C89 (la seule norme C que j'ai et il me
semble celle sur laquelle est basé C++) :

The ftell function obtains the current value of the file
position indicator [...]. For a binary stream, the value is the
number of characters from the beginning of the file. [...]

Il me semble donc qu'avec un stream en mode binaire, ça
fonctionne pas si mal. Et ftell renvoie un long par ailleur...



Et voilà le problème. Sur pas mal de systèmes, encore aujourd'hui,
un long, ça n'a que 32 bits. Or qu'un système aujourd'hui qui limite
la taille d'un fichier à 2^32, c'est vraiment taré (et je n'en
connais pas). Alors, quoiqu'en dit la norme...


Les fichiers de plus de 4 gigaoctets sont plutôt rares sur ma machine
(je n'en ai aucun pour le moment !). Pas sur la tienne ?


Ils ne sont pas courants. Mais est-ce que tu conseilles écrire un
programme qui ne marche qu'à coup d'hazard, même quand la plupart du
temps, l'hazard marche.

En fait, déjà avant la norme C90, le problème était connu. C'est
pour ça que C90 a introduit fpos_t et fgetpos/fsetpos. Les veilles
fonctions, fseek et ftell, continuent à fonctionner comme avant dans
les cas où elles peuvent marcher (ce qui devient assez rare de nos
jours), mais le code nouveau doit se servir des


Il me semble qu'il y a bien des cas où l'analyse nous dira que les
fichiers qu'on veut traiter auront moins de 4 gigaoctets et ce, encore
pour longtemps.

nouvelles.


Je verrais bien ftell faire exactement ce que voulait la personne qui
a posé la question originalement. Ton explication détaillée permet de
voir les limites. Dire simplement que ftell ne donne pas ce qu'on
pense est un peu différent (certains ont avancé que ça ne renvoyait
pas une valeur numérique, confondant donc fgetpos et ftell...).


Ou les fonctions gseek et pseek de iostreams.

--
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




Avatar
kanze
"Michel Michaud" wrote in message
news:<2%jMb.3971$...
Dans news:, Gabriel Dos
"Michel Michaud" writes:

Dans news:, James
Et voilà le problème. Sur pas mal de systèmes, encore aujourd'hui,
un long, ça n'a que 32 bits. Or qu'un système aujourd'hui qui
limite la taille d'un fichier à 2^32, c'est vraiment taré (et je
n'en connais pas). Alors, quoiqu'en dit la norme...


Les fichiers de plus de 4 gigaoctets sont plutôt rares sur ma
machine (je n'en ai aucun pour le moment !). Pas sur la tienne ?


en conséquence, tu utilises un système vraiment taré et James ne le
connait pas. C'est faux ? ;-p


Mon système permet des fichiers plus gros, mais moi je n'en ai pas
vraiment besoin (jusqu'à maintenant). J'imagine qu'un système taré
(aujourd'hui) serait un système qui ne permettrait que des fichiers
occupant 4 giga ou plus :-)

Et je crois que James connaît mon système d'exploitation... un
peu, au moins de nom !


Mais pas beaucoup plus que de nom. Mais même sans le connaître plus que
ça, ça m'aurait étonné qu'il limite la taille des fichiers à 4 Go.

Et la question était bien ça. Moi non plus, je n'ai pas de fichiers plus
de 4 Go. Parce que je n'en ai pas actuellement besoin, non parce que le
système ne les supporte pas. Et à mon avis, la question est plus
simple@; étant donné qu'ils puissent exister, est-ce qu'on peut
considérer correct un programme qui fait comme si ils n'existaient pas ?
La réponse n'est pas complètement blanc et noir, parce que j'imagine
bien des contextes où on sait quelque chose du fichier avant, et qu'on
peut réelement exclure la possibilité d'un fichier plus grand. Mais dans
le cas général, où c'est l'utilisateur qui donne le nom du fichier, je
dirais que c'est une erreur.

--
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




Avatar
Michel Michaud
Dans news:,
"Michel Michaud" wrote in message
news:<oXiMb.3529$...
Les fichiers de plus de 4 gigaoctets sont plutôt rares sur ma
machine (je n'en ai aucun pour le moment !). Pas sur la tienne ?


Ils ne sont pas courants. Mais est-ce que tu conseilles écrire un
programme qui ne marche qu'à coup d'hazard, même quand la plupart du
temps, l'hazard marche.


Pas du tout. Je dis que si tu sais que tu n'auras pas de tels
fichiers, alors ftell (ou d'autres équivalentes des stream C++)
fait l'affaire. Si tu ne sais pas ou que tu sais que tu en auras,
alors il faut faire autrement. Si je dois faire un programme pour
analyser une liste de fichiers qu'il faut copier sur CD ou
disquette, alors je sais que je n'aurai pas de tels fichiers. Par
contre, s'il faut copier sur un DVD...

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/


Avatar
kanze
"Michel Michaud" wrote in message
news:<r0AMb.6262$...
Dans news:,
"Michel Michaud" wrote in message
news:<oXiMb.3529$...
Les fichiers de plus de 4 gigaoctets sont plutôt rares sur ma
machine (je n'en ai aucun pour le moment !). Pas sur la tienne ?


Ils ne sont pas courants. Mais est-ce que tu conseilles écrire un
programme qui ne marche qu'à coup d'hazard, même quand la plupart du
temps, l'hazard marche.


Pas du tout. Je dis que si tu sais que tu n'auras pas de tels
fichiers, alors ftell (ou d'autres équivalentes des stream C++) fait
l'affaire.


Mais comment tu le sais ? Si c'est ton programme qui les a écrit,
d'accord, mais c'est à peu près la seule façon que je vois.

Si tu ne sais pas ou que tu sais que tu en auras, alors il faut faire
autrement. Si je dois faire un programme pour analyser une liste de
fichiers qu'il faut copier sur CD ou disquette, alors je sais que je
n'aurai pas de tels fichiers.


Et d'où vient cette liste ? Comment sais-tu qu'il n'y a pas de fichiers
plus gros dans la liste ? Le fait qu'un fichier soit trop gros pour
passer sur le support cible n'empêche pas à l'utilisateur de le nommer.

Par contre, s'il faut copier sur un DVD...


Tu utiliserais le même programmer que tu utilises pour copier sur le CD,
n'est-ce pas ?

C'est exactement ce que je voualis dire. Aujourd'hui, tu écris un
programme de copie, et tu sais qu'aucun fichier n'a plus que 4 Go. Mais
qu'est-ce qui t'assure que ce serait toujours le cas ?

--
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



Avatar
Michel Michaud
Dans news:,
"Michel Michaud" wrote in message
news:<r0AMb.6262$...
Pas du tout. Je dis que si tu sais que tu n'auras pas de tels
fichiers, alors ftell (ou d'autres équivalentes des stream C++)
fait l'affaire.


Mais comment tu le sais ? Si c'est ton programme qui les a écrit,
d'accord, mais c'est à peu près la seule façon que je vois.


Non, il y en a plein d'autres. Je fais actuellement un programme
pour une amie qui fera (entre autres) la copie de sécurité de sa
base de données de clients et de factures. Le fichier fera
probablement un jour quelques centaines de K, mais je vois mal
comment il pourrait même arriver à un méga-octets. Alors je sais
qu'il ne fera jamais un giga-octets et encore moi 4... Et j'ai
plusieurs autres exemples en tête : tu manques vraiment
d'imagination si tu n'en trouves pas d'autres toi-même :-)

Ceci dit, je ne nie pas qu'en général, ce soit un problème, mais
je vois autant de problème à conserver la taille quelque part
(si long a 32 bits) qu'à l'obtenir...

Si tu ne sais pas ou que tu sais que tu en auras, alors il faut
faire autrement. Si je dois faire un programme pour analyser une
liste de fichiers qu'il faut copier sur CD ou disquette, alors je
sais que je n'aurai pas de tels fichiers.


Et d'où vient cette liste ? Comment sais-tu qu'il n'y a pas de
fichiers plus gros dans la liste ? Le fait qu'un fichier soit trop
gros pour passer sur le support cible n'empêche pas à l'utilisateur
de le nommer.


Je crois que si quelqu'un veut faire une copie de ses données sur
une disquette ou un CD, il aura probablement remarqué s'il traite
des fichiers de plus de 4 giga-octets. Sérieusement James as-tu
vraiment besoin de vérifier sur ta machine pour me dire si tu as
des fichiers de plus de, disons, 800 méga-octets ? Moi je crois
que je sais si j'en ai potentiellement sans vérifier.

Par contre, s'il faut copier sur un DVD...


Tu utiliserais le même programmer que tu utilises pour copier sur
le CD, n'est-ce pas ?


Je n'ai jamais fait de logiciel de gravure, mais j'ai l'impression
que ce n'est pas identique pour un CD que pour un DVD... Mais on
devient HS...

C'est exactement ce que je voualis dire. Aujourd'hui, tu écris un
programme de copie, et tu sais qu'aucun fichier n'a plus que 4 Go.
Mais qu'est-ce qui t'assure que ce serait toujours le cas ?


Ce qui m'assure que ce sera le cas ? La documentation ! :-)

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/


Avatar
kanze
"Michel Michaud" wrote in message
news:<stYMb.10164$...
Dans news:,
"Michel Michaud" wrote in message
news:<r0AMb.6262$...
Pas du tout. Je dis que si tu sais que tu n'auras pas de tels
fichiers, alors ftell (ou d'autres équivalentes des stream C++)
fait l'affaire.


Mais comment tu le sais ? Si c'est ton programme qui les a écrit,
d'accord, mais c'est à peu près la seule façon que je vois.


Non, il y en a plein d'autres. Je fais actuellement un programme pour
une amie qui fera (entre autres) la copie de sécurité de sa base de
données de clients et de factures. Le fichier fera probablement un
jour quelques centaines de K, mais je vois mal comment il pourrait
même arriver à un méga-octets. Alors je sais qu'il ne fera jamais un
giga-octets et encore moi 4... Et j'ai plusieurs autres exemples en
tête : tu manques vraiment d'imagination si tu n'en trouves pas
d'autres toi-même :-)


Qui ne vaut toujours que dans le cas où c'est le programme même qui a
écrit le fichier, et qui en choisit le nom. Dès que l'utilisateur peut
choisir le nom, un jour ou l'autre, fatalement, il va donner un mauvais
nom, et tu vas tomber sur un fichier de plus de 4Go. (Une exception
évidente est un programme d'expérimentation, qui ne tournera qu'une
fois.)

Ceci dit, je ne nie pas qu'en général, ce soit un problème, mais je
vois autant de problème à conserver la taille quelque part (si long a
32 bits) qu'à l'obtenir...


Ce qui est réelement un problème aussi.

En général, les langages C/C++ ne connaissent pas la notion de la taille
d'un fichier. Ils n'offrent aucun moyen de l'obtenir, ni de le stocker.
Il faut se retourner vers le système d'exploitation, qui typiquement
offrira les fonctions et les typedefs qu'il faut. (stat() et off_t sous
Unix.)

Pour le positionnement à l'intérieur du fichier, il y a fpos_t (en C) ou
std::fpos_t (en C++).

Si tu ne sais pas ou que tu sais que tu en auras, alors il faut
faire autrement. Si je dois faire un programme pour analyser une
liste de fichiers qu'il faut copier sur CD ou disquette, alors je
sais que je n'aurai pas de tels fichiers.


Et d'où vient cette liste ? Comment sais-tu qu'il n'y a pas de
fichiers plus gros dans la liste ? Le fait qu'un fichier soit trop
gros pour passer sur le support cible n'empêche pas à l'utilisateur
de le nommer.


Je crois que si quelqu'un veut faire une copie de ses données sur une
disquette ou un CD, il aura probablement remarqué s'il traite des
fichiers de plus de 4 giga-octets.


C'est donc que tu comptes sur des utilisateurs de ne pas se tromper. Tu
dois avoir d'autres utilisateurs qui moi.

Sérieusement James as-tu vraiment besoin de vérifier sur ta machine
pour me dire si tu as des fichiers de plus de, disons, 800
méga-octets ? Moi je crois que je sais si j'en ai potentiellement sans
vérifier.


À vrai dire, je ne saurais dire aujourd'hui s'il y a des fichiers de
plus de 4Go ou non sur ma machine. Je le doute, mais il y a un tas de
fichiers qui font partie du système, qui sont installés et gerés sans
que je m'en occupe, et dont je ne doute même pas de l'existance.

Mais surtout, même si je le savais aujourd'hui, je ne sais pas ce qu'il
en sera demain.

Par contre, s'il faut copier sur un DVD...


Tu utiliserais le même programmer que tu utilises pour copier sur le
CD, n'est-ce pas ?


Je n'ai jamais fait de logiciel de gravure, mais j'ai l'impression que
ce n'est pas identique pour un CD que pour un DVD... Mais on devient
HS...


Un peu. Mais quand même. La gestion physique du périphérique est certes
différente entre un CD et un DVD. Mais cette couche-là se trouve dans le
système d'exploitation, j'espère. Et la gestion logique doit être à peu
près identique.

C'est exactement ce que je voualis dire. Aujourd'hui, tu écris un
programme de copie, et tu sais qu'aucun fichier n'a plus que 4 Go.
Mais qu'est-ce qui t'assure que ce serait toujours le cas ?


Ce qui m'assure que ce sera le cas ? La documentation ! :-)


Voyons. Dans la documentation :

L'utilisateur n'entrera jamais le nom d'un fichier dont la taille
est supérieur à 4Go.

Dans ce cas-là, tout ce que je peux dire, c'est que la documentation
ment.

--
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



1 2 3