J'ai rencontré un problème étrange. Le code simplifié suivant reproduit le problème dans MSVC 2010:
// crashes the compiler, credit to Tarydon
int main(void)
{
struct dummy {};
auto x = []{ dummy d; };
}
// works as expected
int main(void)
{
typedef int integer;
auto x = []{ integer i = 0; };
}
4 Réponses :
Ce n'est pas vraiment une réponse à votre question, mais simplement explorer le problème plus loin. Je me demandais si le compilateur a des problèmes liés à types déclarés dans une portée enfermante, alors essayé cela: ici, j'essaie juste de créer un Type local dans la portée enfermante et l'utilisez à partir de la fonction Lambda. Non seulement cela ne compile pas (avec Visual Studio 2010, Beta 2) mais elle bloque en fait le compilateur avec une erreur interne C1001.
Un peu, si vous faites un typlef local au type local, l'accident s'en va.
de N3000, 5.1.2 / 6,
L'expression de la Lambda L'instruction composée donne le corps de fonction (8.4) de la fonction opérateur, mais à des fins de Nom Recherche (3.4), ... le L'énoncé composé est considéré dans le contexte de l'expression de la Lambda.
Sans surprise, le type local doit être visible.
Ah, je viens de réaliser que j'étais accidentellement en train de regarder un ancien brouillon.
J'accepte cela pour répondre à mon original "Est-ce autorisé" question. :)
J'ai déposé deux rapports de bugs.
Nous verrons comment ça se passe. :)
Les deux bugs ont été marqués comme corrigé:
Nous apprécions vos commentaires. Ce bug a été vu par nous avant et nous l'avons résolu dans la prochaine version. Merci d'avoir utilisé le produit.
merci
Ulzii luvsanbat
Équipe Windows C ++Alors, nous y allons.
Il ne semble pas être lié aux modèles, mais à chaque fois que l'opérateur de résolution de la portée (: :) est nécessaire. Une méthode FOO non statique fonctionne comme prévu.
Qu'en est-il de votre problème d'espace de noms? Il utilise :: pour obtenir l'espace de noms d'origine (la version de travail.) C'est peut-être une définition locale requiert :: ?
Ouais c'est ce que je voulais dire. test d'espace de noms = foo; auto x = [] (vide) {test de retour :: bar (); };
@dvide: ça va. :) Utilisez les back-ticks: `code va ici" devient code va ici . (Remarque, vous pouvez vous échapper avec une barre oblique inverse.) Je modifie le deuxième rapport pour correspondre à nos données.
@DVide: J'ai modifié le bogue "Typedef-of-Modèle" à la résolution plus générique "Lambda Scope Scope échoue avec des étendues définies localement.". Belle trouvaille.
On dirait qu'aucun d'entre eux ne sera résolu dans le VS2010 RTM. J'ai référencé le bogue de crash dans une chat e-mail que j'avais avec l'un des développeurs VC ++, ainsi que plusieurs bugs que j'ai rapportés. Elle a déclaré: "Je montre actuellement que tous les bugs ci-dessous sont toujours actifs dans notre système. Depuis que nous sommes à la fin du cycle de produit pour VS2010, ces problèmes seront pris en compte pour une version suivante."
@James: Ah, c'est dommage. J'ai remarqué qu'ils étaient toujours présents dans RC, dommages, ils ont été poussés si loin. C'est surprenant depuis, du moins pour moi, la situation de ces insectes devrait se présenter un peu.
@James @dvide: Selon les rapports de bogues, les deux problèmes sont fixes.
Fonction-local Enums ne peut pas être détecté par Lambdas non plus.
int main()
{
enum E {A, B, C};
auto x = [=](){ int a = A; };
// typedef E F;
// auto y = [=](){ F a = A; }; // this compiles ok
}
même chose avec des alias d'espace de noms local
Les trois cas de test compilent avec succès à l'aide de Intel C ++ Compiler 11.1.
Les trois cas de test compilent avec succès à l'aide de G ++ 4.5.