In che modo un compilatore Java analizza i typecasts?

Question

Un'espressione semplice come

(x) - y

viene interpretato in modo diverso a seconda che x sia o meno un nome di tipo. Se x non è un nome di tipo, (x) - y sottrae y da x . Ma se x è un nome di tipo, (x) - y calcola il negativo di y e lancia il valore risultante per digitare x .

In un tipico compilatore C o C ++, la domanda se x è un tipo o meno è responsabile perché il parser comunica tali informazioni al lexer non appena elabora una dichiarazione typedef o struct. (Penso che tale violazione richiesta dei livelli sia stata la parte più cattiva del progetto di C.)

Ma in Java, x non può essere definito fino a tardi nel codice sorgente. Come fa un compilatore Java a chiarire tale espressione?

È chiaro che un compilatore Java necessita di più passaggi, poiché Java non richiede una dichiarazione prima dell'uso. Ma ciò sembra implicare che il primo passaggio debba svolgere un lavoro molto approssimativo sull'analisi delle espressioni, e quindi in un passaggio successivo eseguire un'altra analisi, più accurata, delle espressioni. Sembra uno spreco.

C'è un modo migliore?

Answer 1

Penso di aver trovato la soluzione che mi soddisfa. Grazie a mmyer, mi sono reso conto che dovevo controllare le specifiche formali della sintassi per i tipi di cast.

L'ambiguità è causata dal fatto che + e - sono operatori unari e binari. Java risolve il problema con questa grammatica:

CastExpression:
        ( PrimitiveType Dimsopt ) UnaryExpression
        ( ReferenceType ) UnaryExpressionNotPlusMinus

(vedi http: //java.sun. com / docs / libri / JLS / third_edition / html / expressions.html # 238146 )

Quindi, '+' e '-' sono esplicitamente vietati immediatamente dopo il ')' di un cast a meno che il cast non usi un tipo primitivo - che sono conosciuti dal compilatore a priori.

Answer 2

L'ho appena provato e questo codice:

Double y = new Double(0.1);
System.out.println((Double)-y);

dà un errore di compilazione:

  Operatore

- non può essere applicato a Double, java.lang.Double .

Mettere le parentesi attorno a -y rende la compilazione corretta. Quindi apparentemente Java risolve questo problema semplicemente non consentendolo nella grammatica (se questa è la terminologia giusta; non sono un esperto di compilatori).