Discussion :

[Le Furet]

Je voudrais savoir le nombre d'octets lus depuis le début du fichier que je suis en train de parcourir.

Y'a-t-il une méthode qui permet cela ? Je ne la trouve pas dans les méthodes de DataInputStream ni ses prédécesseurs (FilterInputStream et InputStream).

[Gfx]

Chaque appel a read() dans un InputStream renvoie le nombre d'octets que tu viens de lire... de la a t'expliquer qu'il suffit d'additionner ces resultats...

[Le Furet]

Et qu'est-ce qui me prouve qu'additionner va me donner le bon résultat ? D'abord ? Hein ?

Merci, preuve qu'il vaut mieux un qui sait que dix qui cherchent (ou que moi qui cherche)...

[Gfx]

Non, en programmation pour beaucoup de questions il vaut mieux 10 qui cherchent justement. Quand la reponse se trouve dans la documentation, ce n'est jamais une bonne chose de ne pas trouver tout seul

[Le Furet]

En fait, j'étais persuadé que toutes les méthodes commençant par read servaient à lire une donnée (du type adéquat) du flux. Je ne m'attendais pas à ce que ça renvoit le nombre d'octets lus. D'ailleurs, en lisant la documentation de l'API, je lis :

public abstract int read()
throws IOException

Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown.

A subclass must provide an implementation of this method.

Returns:
the next byte of data, or -1 if the end of the stream is reached.
Throws:
IOException - if an I/O error occurs.

Ce qui n'est pas ce que je demande (mais je vais lire un peu plus loin pour éviter de passer pour un con une 2ème fois).

[Gfx]

Argh la c'est ma faute, j'ai oublie un detail important dans ma reponse. Il faut lire : read(byte[]). J'ai tellement l'habitude de l'utiliser que j'ai oublie de preciser, desole.

La documentation de cette methode donne l'information suivante :

Returns:
the total number of bytes read into the buffer, or -1 is there is no more data because the end of the stream has been reached.

Note que si tu utilise le read() qui ne renvoie qu'un byte, le principe reste le meme, tu additionne le nombre de bytes lus.

[Le Furet]

Je crois que j'avais mal compris ta réponse. Auquel cas, je précise :

j'avais bien sûr pensé à utiliser un compteur externe que j'incrémente à chaque appel à une fonction read(), au cas où il n'était pas possible de faire autrement. Mais :

- il me semblait que ma requête était suffisament naturelle pour que ça existe déjà.
- ça m'oblige à faire suivre tous mes readxxx() d'une mise à jour du compteur. C'est long, j'ai beaucoup de readxxx() (pour être plus précis, je suis en train de parcourir un fichier .otf ou .ttf. Je sais que la classe Font le fait, mais elle ne donne pas toutes les infos dont j'ai besoin). Je peux aussi créer une classe étendant DataInputStream et gardant les mises à jour du compteur, mais ça me paraissait un peu lourd (et j'ai quand même une dizaine de méthodes read() à définir).

[Le Furet]

Note : j'ai écrit la réponse précédente avant d'avoir lu ta réponse précédant la précédente

Je crois que je vais étendre DataInputStream.

[jak0]

Après si tu travail en socket, il me semble qu'il y a une méthode permettant de connaitre les octects transférés dans cette socket.

Je sais qu'ici, ça n'est pas la question, mais c'est juste une précision annexe.

Par contre, je pense que pour un flux de lecture, il n'y a aucune raison qu'il existe un compteur de donnés intégré à Java.
La mise à jour manuelle d'une variable est donc pour moi la seule et unique solution, et je trouve ça bien normal...

[Le Furet]

Je suis d'accord avec ton affirmation : je ne vois pas pourquoi l'interface InputStream préciserait un compteur. Par contre, je suis surpris qu'il n'existe pas de classe le faisant (c'est quand même souvent utile). Maintenant, je suis bien conscient que ce que je pense n'a aucun intérêt.

[jak0]

Perso je ne vois pas l'intéret de l'existence d'une classe le permettant.
Maintenant c'est mon avis.
Et il faudrait pas non plus que tout existe, sinon on n'aurait plus rien à faire , non ???

[Le Furet]

Tu as raison : je vais me remettre au C

[afrikha]

Perso je ne vois pas l'intéret de l'existence d'une classe le permettant.
Maintenant c'est mon avis.
Et il faudrait pas non plus que tout existe, sinon on n'aurait plus rien à faire , non ???

Pas d'accord..., connaitre le nomre de bytes lu dans un flux est certe une operation "banale" mais fréquemment utilisé, pour moi elle aurait toute sa place dans l'api (sous forme de classe ou de méthode ).
C'est le mème principe que pour les LinkedList par exemple.
Mais bon tout cela n'est que mon avis.

[jak0]

Pas d'accord..., connaitre le nomre de bytes lu dans un flux est certe une operation "banale" mais fréquemment utilisé, pour moi elle aurait toute sa place dans l'api (sous forme de classe ou de méthode ).
C'est le mème principe que pour les LinkedList par exemple.
Mais bon tout cela n'est que mon avis.

Un autre argument :
Cette fonctionnalité existe pour les sockets, en effet, si tu ouvre une socket et que tu ecoute, tu ne controle pas le nombre d'octet que tu va recevoir en tout (tu peut limiter mais pas savoir combien il en reste...)
Par contre quand tu ouvre un flux sur un fichier, c'est toi qui controle tout, donc il est très aisé de savoir le nombre de bits analysés...
Quest ce ten pense ??

[afrikha]

Un autre argument :
Cette fonctionnalité existe pour les sockets, en effet, si tu ouvre une socket et que tu ecoute, tu ne controle pas le nombre d'octet que tu va recevoir en tout (tu peut limiter mais pas savoir combien il en reste...)
Par contre quand tu ouvre un flux sur un fichier, c'est toi qui controle tout, donc il est très aisé de savoir le nombre de bits analysés...
Quest ce ten pense ??

je ne saisis pas très bien ton argument (c'est peut-étre ma faute ): un fichier tu peux ne pas connaitre sa taille à l'avance.
mais pour simplifier et se concentrer sur le sujet de la discussion: qu'est-ce qui te génerait qu'une telle fonctionnalité soit présente dans l'api? moi je vois que des avantages: grand nombre d'utilisateurs donc grand nombre de tests et au final une fonction plus fiable et optimisée certainement plus que si elle est implémenté par un développeur dans son coin.

[Gfx]

Cette fonctionnalite serait inutile pour la plupart des developpeurs. Je fais du Java depuis maintenant 8 ans et je ne me souviens pas d'avoir eu besoin de faire ca. On ne peut pas integrer dans l'API tout ce dont chaque developpeur a besoin. Sache egalement que plus on ajoute des choses dans l'API plus il y a des risques de bugs et des problemes de maintenance pour nous.

Et puis tu peux connaitre la taille d'un fichier a l'avance

[afrikha]

En fait ,je crois qu'on n'a pas la mème conception de la chose: pour moi quelque chose d'integrer à l'api est synonyme de fiabilité ,et performances car il a été sujet à des millions de tests et les developpeurs sun auront eu un feedback d'echelle mondiale.
=> conséquence de ceci, le code produit par les développeurs java sera plus sùr, stable et performant.En gros,il vaut mieux un bug dans le jdk qui sera rapidement corrigé et ce de la meilleure manière possible que plein de petit bugs à travers le monde qui résultent du fait que chaque developpeur ait developper dans son coin.

Je suis d'accord qu'on ne peut pas (et on ne doit pas) tout inclure dans le jdk pour la bonne et simple raison que la qualité de ce dernier baissera en conséquence.

Gfx, assez de paresse et au boulot...et produit du bon code swing sur lequel on pourra s'appuyer pour nos appli (je plaisante, j'admire particulierement le travail de l'equipe swing )

[jak0]

Un autre argument :
Cette fonctionnalité existe pour les sockets, en effet, si tu ouvre une socket et que tu ecoute, tu ne controle pas le nombre d'octet que tu va recevoir en tout (tu peut limiter mais pas savoir combien il en reste...)
Par contre quand tu ouvre un flux sur un fichier, c'est toi qui controle tout, donc il est très aisé de savoir le nombre de bits analysés...
Quest ce ten pense ??

je ne saisis pas très bien ton argument (c'est peut-étre ma faute ): un fichier tu peux ne pas connaitre sa taille à l'avance.
mais pour simplifier et se concentrer sur le sujet de la discussion: qu'est-ce qui te génerait qu'une telle fonctionnalité soit présente dans l'api? moi je vois que des avantages: grand nombre d'utilisateurs donc grand nombre de tests et au final une fonction plus fiable et optimisée certainement plus que si elle est implémenté par un développeur dans son coin.

Et le file.length() t'en fait quoi ?

[afrikha]

je voulais parler de la taille de ce que tu lis et non pas la taille du fichier entier. Mais mea culpa, je me suis mal exprimé

[Le Furet]

Je fais du Java depuis maintenant 8 ans et je ne me souviens pas d'avoir eu besoin de faire ca.

Ca vois-tu, ça m'étonne. Je suis novice en Java, mais pas en programmation, et il m'est souvent arrivé de devoir farfouiller dans des formats binaires avec des spécifications curieuses (celle des ttf/otf n'étant pas la moins bizarre, curieux pour un format aussi répandu d'ailleurs), et à chaque fois, j'étais bien content d'avoir un index dans mon fichier, pour calculer les offsets qui ne sont jamais référencés par rapport à l'octet courant mais par rapport au début de la sous-sous table bidule...

Je suis complètement d'accord avec Afrikha. Et tant que j'y suis, Java, ça fait un mois que je m'y plonge, je trouve ça absolûment fabuleux et intelligent à tous les points de vue. C'est peut-être pour ça que je ne m'attendais pas à devoir gérer mon index à la main (voilà une phrase curieuse...)