java - round - ¿Por qué se usa Math.floor() en lugar de la división de enteros en BER Codec?

quitar decimales javascript

Question

Estoy mirando el SNMPBEECodec que se puede ver en esta ubicación
En particular, estoy buscando la función encodeLength()
Un fragmento en el que estoy interesado

 int numBytes = 0;
int temp = length;
while (temp > 0)
{
++numBytes;
temp = (int)Math.floor(temp / 256);
} 

(de la biblioteca Drexel SNMP ).

Me gustaría saber por qué se utiliza Math.floor() lugar de solo una división entera simple como temp/256 . Parece que la división entera simple daría el mismo resultado. ¿O hay una diferencia técnica?

Answer 1

Bueno, desafortunadamente el autor ya no puede leer su mente, han pasado unos 12 años desde que escribí esto, así que me olvido de la razón por la que no utilicé solo la división de enteros. Algunos pensamientos: utilizo la división de enteros en otro lugar asumiendo el comportamiento habitual, por lo que no habría sido una confusión básica en las reglas para la división de enteros en Java; es posible (aunque poco probable) que en algún momento utilicé un tipo de datos no integrales para el argumento, y no me deshice del piso superfluo () cuando cambié; o quizás (más probable) estuve en algún momento intentando redondear en lugar de hacia abajo mientras desarrollaba el algoritmo, usando ceil () como una forma barata (= menos caracteres) para hacer esto, y simplemente cambié a piso () cuando cambiado

Por lo tanto, desafortunadamente, la verdadera razón se pierde en las brumas del tiempo ... pero estoy de acuerdo, el piso () es superfluo. Realmente debería publicar el código en Github o similar para que la gente pueda mejorarlo y evolucionar. / Jon

Answer 2

Para responder la parte técnica de su pregunta:

Usar math.floor() es superfluo: temp / 256 es un entero (según las reglas de Java para la aritmética de enteros), y usar Math.floor() en un entero no tiene sentido. Simplemente podría usar temp / 256 .

Por qué el autor hizo esto es imposible de responder sin leer su mente. El autor podría haber estado confundido sobre el comportamiento de la división en Java y decidió "ir a lo seguro", pero eso es solo especulación.