Discussion :

[ChPr]

Bonjour à toutes et à tous,

Dans une procédure de récupération de données, j'ai le code qui suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
	byte buffer[] = new byte[100];
	int k = receiveStream.read(buffer, 0, 100);
	if (k > 0) {
		byte rawdata[] = new byte[k];
		for (int i = 0; i < k; i++)
			rawdata[i] = buffer[i];
		String data = new String(rawdata);

On passe par un deuxième buffer (rawdata) pour récupérer les données. En faisant des tests, selon que j'utilise ce buffer ou pas, le résultat est le même ; que le nombre de caractères envoyés soit inférieur ou supérieur à la taille du buffer (100 bytes). Je n'en vois donc pas l'utilité.

J'ai raté quelque chose ?

Cordialement.

Pïerre

[sevyc64]

Perso, je ne connais rien aux particularités de Java et encore moins à celle d'android. La seule utilité que j'y vois effectivement ça serait de ne pas traduire dans la string des caractères aléatoires et totalement farfelus situés au delà des k premiers bytes qui sont ceux réellement retournés par le stream. De cette façon on ne traduit en string qu'un tableau de longueur K, et non pas un tableau de longueur 100 si jamais il n'y pas eu 100 bytes de retournés.

Mais effectivement, c'est un code curieux, qui consomme de la mémoire en doublant le tableau et du temps de traitement en faisant une copie byte à byte, mais peut-être n'existe-il pas d'autres solutions.

[ChPr]

Je viens de voir qu'il existe un autre moyen (grâce à Android Studio), c'est d'utiliser la fonction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

System.arraycopy(buffer1, 0, buffer2, 0, k);

où buffer2 peut être buffer1 (les données sont copiées dans un buffer temporaire avant d'être réintégrées dans le buffer lui même).

Pour autant, c'est faire la même chose qu'avant sous une autre forme d'écriture.

En ce qui concerne des caractères bizarres après les "k" valides, je ne vois pas comment ils pourraient être intégrés en ce sens que "k" a été trouvé car un délimiteur de chaîne à été trouvé (tout du moins, c'est ce que je pense). Donc, buffer ne peut que contenir les "k" premiers caractères plus le caractères de délimitation.

Oui, non ?

Cordialement.

Pierre

[grunk]

Ca pourrait avoir un intérêt si la boucle for ne s'effectuait pas sur la totalité du buffer. Que en gros on reçoive X bytes dans le buffer et qu'on ne veuille que les X -5 bytes.
Dans ton exemple c'est une copie pure et simple du tableau , donc que tu utilise buffer ou rawdata c'est pareil.

[nicroman]

Je pense surtout que le mec qui a pondu le code ne connait pas les subtilités de java.

Entre autre que:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

buffer[] = new byte[100];

sera forcément un tableau de 100 bytes à 0 (oui oui c'est normalement dans les requisites des JVM).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

String data = new String(rawdata,0,k);

ferait exactement la même chose sans avoir à changer le tableau.

Mais encore une fois, ce n'est utile que le si le tableau (buffer) est conservé de manière statique d'une execution à l'autre, pas si il est réalloué à chaque fois !

Bizarrement d'ailleurs il utilise:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

stream.read(buffer,0,100)

alors que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

stream.read(buffer)

ferait exactement la même chose (offset 0, length = length du buffer).

[tchize_]

Effectivement ce code fait de manière peu performante ce que le constructeur a 3 arguments de string fait proprement.