Errore di sintassi sottile nel parametro predefinito non rilevato dal compilatore

Question

Ho iniziato a ricevere l'errore, "errore C2059: errore di sintassi: 'argomento predefinito'" per una riga di codice che ha dichiarato una funzione con un argomento stringa a cui è stato assegnato un parametro predefinito . Questo era ovviamente un po 'frustrante, poiché il messaggio di errore non era esattamente illuminante (so che è un' argomento predefinito '!), E la dichiarazione esatta funzionerebbe altrove.

Dopo aver spostato un po 'la dichiarazione, ho trovato che la sua posizione nella sua classe contenente ha effettivamente avuto un effetto. Restringendolo, ho scoperto che stavo dichiarando una funzione diversa in qualche modo erroneamente, includendo un punto e virgola dopo uno di i suoi parametri di default. Il compilatore sembrava perfettamente a posto, il che sembrava un po 'strano. Ho studiato un po 'di più, e si avvicinò con la seguente banco di prova per cercare di capire l'essenza di quello che stava succedendo:

enum TestEnum1 
{ 
    TEST_ONE 
}; 
class TestClass 
{ 
public: 
    enum TestEnum2 
    { 
     TEST_TWO, 
     TEST_THREE, 
     TEST_FOUR 
    }; 
    void Func1(int iParm = TEST_ONE;); // additional semicolon here 
    void Func2(std::string strParm = ""); 
}; 

Come il codice sta al di sopra, Func2 produrrà l'errore di compilazione che ho citato sopra. Se sposto Func2 sopra Func1, allora tutto si compila bene.

Se posso passare il parametro predefinito in Func1 ad un numero esplicito o utilizzare un enum dichiarato all'interno TestClass, tanto sono un errore di sintassi prevista per quella linea.

Quindi, in sostanza, la cosa strana sembra essere che se ho impostato il valore di un parametro di default per un enum non definito direttamente nella classe corrente e sono un po 'troppo virgola-felice, il compilatore ignorerà l'errore di sintassi, fino a quando un'altra cosa apparentemente non correlata alla fine fa sì che il parser muoia in un modo molto imperscrutabile.

Mi manca qualcosa di completamente? È questo comportamento previsto? Sono riluttante a chiamarlo un bug nel compilatore, certamente, ma questo sembra appena corretto. Se sono solo io a fraintendere qualcosa sullo standard, mi piacerebbe sapere dove mi sbaglio.

Answer 1

Concordato con @tlayton. Avendo preso un po 'da solo gli parser, posso attestare che generare buoni messaggi di errore per errori di sintassi che confondono il senso di scope del parser può essere molto difficile da fare.

Questo caso particolare è comunque vicino a un difetto.L'ironia è che in VS2010, il compilatore genera ancora lo stesso messaggio di errore schifoso ma il parser IntelliSense in realtà afferra:

3 IntelliSense: expected a ')' c:\projects\cpptemp14\cpptemp14.cpp 20 36 cpptemp14 

Questo è BORKED. È possibile segnalarlo su connect.microsoft.com. Fammi sapere se non vuoi prenderti il ​​tempo, lo segnalerò (dovere di MVP).

Answer 2

direi che questo non è esattamente un bug nel compilatore, quanto che l'incapacità del compilatore di analizzare il codice è espresso in modo inaspettato.

Quando il compilatore colpisce che punto e virgola errante, si pensa che si sa qualcosa il codice che non dovrebbe essere vero. Il compilatore non vede nulla che contraddica questa convinzione fino a quando non raggiunge l'argomento predefinito della seconda funzione, che apparentemente non si configura con lo stato in cui ha pensato che il codice fosse sintatticamente. Chiama l'errore lì perché è lì che ha visto il problema, ma non garantisce che è lì che si trova effettivamente il problema con il codice.

Questo è qualcosa che vedo spesso coinvolgono fuori posto o mancante parentesi graffe, parentesi o altri supporti delimitano. Il compilatore pensa che tutto vada bene fino a quando non raggiunge la fine di un blocco di codice e si rende conto che non c'è lo stesso numero di parentesi sinistra e destra, quindi chiama l'errore lì. In realtà non è in grado di dire dove doveva andare la parentesi mancante.

Poiché questo comportamento dipende dal processo di analisi esatto utilizzato, dipende dal compilatore. Tuttavia, mentre questo spesso può cambiare il tipo di errore chiamato e dove, di solito è un errore di qualche tipo su ogni compilatore.