Java se dice que ignorar espacios en blanco extra. ¿Por qué c = a + ++ ++ b no compila sin los espacios?

John Allison:

En todos los libros sobre Java, He leído que los compilador trata todos los espacios de la misma manera y simplemente ignora espacios en blanco extra, así que es la mejor práctica para usarlos libremente para mejorar la legibilidad del código. He encontrado la prueba de que en cada expresión que he escrito: No importaba si había espacios o no, y cómo muchos (o tal vez simplemente no prestar atención).

Recientemente decidí experimentar un poco con la precedencia y asociatividad de operadores para probar la tabla de precedencia en la acción y trató de compilación

int a = 2;
int b = 3;    
int c = a+++b;
int d = a+++++b;

Mientras que el primero compila perfectamente comunicado, este último produce una excepción:

Excepción en hilo java.lang.RuntimeException "principal": código fuente Uncompilable - tipo inesperado. Requerido: variable. Encontrado: valor.

Sin embargo, cuando he añadido espacios: int d = a++ + ++b, se compiló. ¿Por qué es este el caso? Java se dice que ignorar espacios en blanco extra de todos modos. (Tengo Java 8 y el IDE Netbeans 8.2, si esto es importante).

Supongo que esto podría tener algo que ver con la forma en que se analizan las expresiones, pero no estoy seguro. Probé mirando hacia arriba varias preguntas sobre el análisis sintáctico, espacios en blanco, y los operadores de SO y en Google, pero no pude encontrar una respuesta definitiva.

UPD. Para hacer frente a los comentarios de que es la materia de 'extra' que, no todos los espacios en blanco: desde int c = a++ + b;y int c=a+++b;tanto de compilación, se podría decir, por analogía, que en el int d = a ++ + ++b;espacio en blanco es 'extra' también.

Daniel Pryden :

Especificación del lenguaje Java la sección 3.2 , "Las traducciones léxicas", dice (el énfasis es mío):

Una corriente en bruto de caracteres Unicode se tradujo en una secuencia de tokens , usando la siguiente tres pasos de traducción léxica, que se aplican a su vez:

  1. Una traducción de Unicode escapa [...]

  2. Una traducción [...] en una corriente de caracteres de entrada y terminaciones de línea [...].

  3. Una traducción de la corriente de caracteres de entrada y terminadores de línea resultantes de la etapa 2 en una secuencia de elementos de entrada (§3.5) que, después de un espacio en blanco (§ 3.6) y comentarios (§3.7) se descartan, comprenden los tokens (§3.5) que son los símbolos terminales de la gramática sintáctica (§2.3).

La traducción más larga posible se utiliza en cada paso , aunque el resultado no acaba de hacer un programa correcto, mientras que otra traducción léxica haría.

los caracteres de espacio tan blanco se descartan, pero después de la "secuencia de elementos de entrada" se determina. Sección 3.5, "Entrada Elementos y tokens", dice:

El espacio en blanco (§ 3.6) y comentarios (§3.7) pueden servir para tokens separados que, si son adyacentes, podría ser tokenizados de otra manera. Por ejemplo, los caracteres ASCII - y = en la entrada puede formar el operador de contadores - = (§3.12) sólo si hay no está interviniendo el espacio en blanco o comentario.

Supongo que te gusta

Origin http://43.154.161.224:23101/article/api/json?id=182695&siteId=1
Recomendado
Clasificación