Erreur de syntaxe subtile dans le paramètre par défaut non capturé par le compilateur

Question

J'ai commencé à recevoir l'erreur, "erreur C2059: erreur de syntaxe: 'argument par défaut'" pour une ligne de code qui a déclaré une fonction avec un argument de chaîne auquel un paramètre par défaut a été donné . C'était évidemment un peu frustrant, car le message d'erreur n'était pas vraiment éclairant (je sais que c'est un 'argument par défaut'!), Et la déclaration exacte fonctionnerait ailleurs. Après avoir légèrement décalé la déclaration par rapport à la déclaration, j'ai trouvé que sa position dans la classe qui la contient avait effectivement un effet. En rétrécissant, j'ai constaté que je déclarais une fonction différente quelque peu erronée, en incluant un point-virgule après l'un des ses paramètres par défaut. Le compilateur semblait parfaitement bien avec ça, ce qui semblait un peu étrange. J'ai étudié un peu plus, et est venu avec le cas de test suivant pour essayer de comprendre l'essence de ce qui se passait:

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 = ""); 
}; 

Comme le code est au-dessus, Func2 produira l'erreur de compilation je l'ai mentionné ci-dessus. Si je déplace Func2 au dessus de Func1, alors tout se compile bien.

Si je mets le paramètre par défaut dans Func1 à un nombre explicite ou utilise une énumération déclarée dans TestClass, alors j'obtiens une erreur de syntaxe attendue pour cette ligne.

Donc, essentiellement, la chose étrange semble que si je mets une valeur de paramètre par défaut à un ENUM pas défini directement dans la classe actuelle et je suis un peu trop des points-virgules heureux, le compilateur ignorer l'erreur de syntaxe, jusqu'à ce qu'une autre chose apparemment sans rapport provoque finalement la mort de l'analyseur d'une manière très impénétrable.

Est-ce que je manque quelque chose complètement? Est-ce que ce comportement est attendu? J'hésite à dire que c'est un bogue dans le compilateur, mais cela ne semble guère correct. Si c'est juste que je me méprends sur la norme, alors j'aimerais savoir où je me trompe.

Answer 1

D'accord avec @tlayton. Ayant moi-même essayé un peu les analyseurs, je peux affirmer que générer de bons messages d'erreur pour des erreurs de syntaxe qui confondent le sens de la portée de l'analyseur peut être très difficile à faire.

Ce cas particulier est cependant proche d'un défaut.L'ironie est que dans VS2010, le compilateur génère toujours le même message d'erreur moche, mais l'analyseur IntelliSense attrape réellement:

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

C'est complètement foireuse. Vous pouvez le signaler sur connect.microsoft.com. Faites-moi savoir si vous ne voulez pas prendre le temps, je vais le signaler (devoir MVP).

Answer 2

Je dirais que ce n'est pas exactement un bogue dans le compilateur tant que l'incapacité du compilateur à analyser le code est exprimée de façon inattendue. Lorsque le compilateur rencontre ce point-virgule errant, il pense qu'il connaît quelque chose à propos du code qui n'est pas censé être vrai. Le compilateur ne voit rien pour contredire cette croyance jusqu'à ce qu'il atteigne l'argument par défaut de la seconde fonction, qui apparemment ne correspond pas à l'état qu'il pensait que le code était syntaxiquement. Il appelle l'erreur parce que c'est là qu'il a vu le problème, mais il ne garantit pas que c'est là que réside le problème avec le code.

C'est quelque chose que je vois souvent avec des accolades, des parenthèses ou d'autres supports de délimitation mal placés ou manquants. Le compilateur pense que tout va bien jusqu'à ce qu'il atteigne la fin d'un bloc de code et réalise qu'il n'y a pas le même nombre de parenthèses gauche et droite, donc appelle l'erreur là. Il ne peut pas réellement dire où la parenthèse manquante était supposée aller. Étant donné que ce comportement dépend du processus d'analyse syntaxique exact utilisé, il est dépendant du compilateur. Cependant, alors que cela peut souvent changer quel type d'erreur est appelée et où, ce sera généralement une erreur de quelque sorte sur chaque compilateur.