none
Le code générer automatiquement ne compile plus RRS feed

  • Question

  • La ligne

    int main(array<System::String ^> ^args)

    sort avec les messages d'erreurs suivants:

    SpecificationLoader.cpp(15): error C2976: 'std::tr1::array' : nombre d'arguments modèle insuffisant
    1>          D:\Program Files\Microsoft Visual Studio 10.0\VC\include\array(18) : voir la déclaration de 'std::tr1::array'
    1>SpecificationLoader.cpp(15): error C3699: '^' : impossible d'utiliser cette indirection sur le type 'std::tr1::array'
    1>          le compilateur remplace '^' par '*' pour poursuivre l'analyse

    Il faut que j'arrive a linker ce paquet de code avant d'avancer, car l'ajout de paquets de code peut induire des effets de bord

    J'ai essayé de modifier ce code pas a pas en suivant les documentations, mais je ne suis pas arrivé au bout

    int main(std::tr1::array<System::String ^> args[])

    Seul la première erreur apparait encore


    Jean Noël Martin




    • Modifié JeanNoel53 dimanche 9 septembre 2012 13:11
    samedi 8 septembre 2012 11:27

Réponses

  • J'ai régénéré trois fois la maquette et à la troisième fois je n'ai pas touché au fichier SpecificationLoader.cpp. après avoir ajouté 11 fichiers la génération a été réussi et on but sur le même problème d'exécution que celui documenté dans le Post ci dessous mais comme le problème de démarrage a repris, j'ai regénéré une fois de plus et modifiant à minima SpecificationLoader.cpp pour remplacer Form1 par MainMenue. Ça a marché au niveau de la maquette puis j'ai ajouté deux fichiers de bas niveau et le problème est réapparu. il semble que ce soit au niveau du téléchargement de System::Form. Comment exécuter normalement le chargement de l'environnement d'exécution dans un contexte ou on rajoute des fichiers existants. Il faut préciser que tous les fichiers rajoutés ont déjà été compilés et eu une édition du lien positif avec Visual Studio, et pour limiter les risques d'unresolved symboles, j'inclus les fichiers  un par un en commençant par les couches basses.

    J'ai donc suivi pas à pas les directives de msdn et du compilateur et j'ai codé:

    int argv = 10;
    array<std::string, 10> args;
    int main( argv, args)

    et le compilateur me répond:

    SpecificationLoader.cpp(11): error C2448: 'main' : l'initialiseur de style fonction semble être une définition de fonction

    Comment puis je m'en sortir?

    J'ai donc regardé le type et il demande bien un argument numérique pour la dimension du tableau, mais le compilateur n’accepte ni un chiffre, ni une variable int

    int main( array<System::String ^> args)

      Ça se reproduit chaque fois qu'on ajoute un fichier déjà existant, Même si on prend la précaution de les créer d'abord puis de les changer. C'est quand même de la doc de array _size que j'ai trouvé comme directive de compiler avec l'option /EHsc mais je ne sais pas comment d'exprimer. j'ai fait un essai à la volé qui a été infructueux. Déjà si je savais comment exécuter cette consigne ça m'aiderait.

    en attendant j'ai continué a travailler sur la syntaxe. et pas à pas je suis venu à ce résultat qui est insuffisant:

    int main( array<System::String ^, 10>^ args)

    avec le résultat de compilation suivant:

    1>SpecificationLoader.cpp(9): error C3699: '^' : impossible d'utiliser cette indirection sur le type 'std::tr1::array<_Ty,_Size>'
    1>          with
    1>          [
    1>              _Ty=System::String ^,
    1>              _Size=10
    1>          ]
    1>          le compilateur remplace '^' par '*' pour poursuivre l'analyse

    il semble donc que la taille ne soit pas mal initialisée et que le type args doivent être un handeler. Mais le compilateur ne l’accepte pas, alors un pointeur, mais il ne serait pas managé et c'est la demande du compilateur précédente qui dit que le type doit être un handeler.

    Je conclue que ce problème est du fait de la non génération de la maquette qui recopiait des fichiers de l'implémentation précédente, ce qui rompt les bases de données associées à Visual Studio.



    Jean Noël Martin









    • Marqué comme réponse JeanNoel53 lundi 10 septembre 2012 06:18
    • Non marqué comme réponse JeanNoel53 lundi 10 septembre 2012 06:46
    • Modifié JeanNoel53 mercredi 12 septembre 2012 14:52
    • Marqué comme réponse JeanNoel53 mercredi 12 septembre 2012 14:52
    lundi 10 septembre 2012 06:18

Toutes les réponses

  • J'ai régénéré trois fois la maquette et à la troisième fois je n'ai pas touché au fichier SpecificationLoader.cpp. après avoir ajouté 11 fichiers la génération a été réussi et on but sur le même problème d'exécution que celui documenté dans le Post ci dessous mais comme le problème de démarrage a repris, j'ai regénéré une fois de plus et modifiant à minima SpecificationLoader.cpp pour remplacer Form1 par MainMenue. Ça a marché au niveau de la maquette puis j'ai ajouté deux fichiers de bas niveau et le problème est réapparu. il semble que ce soit au niveau du téléchargement de System::Form. Comment exécuter normalement le chargement de l'environnement d'exécution dans un contexte ou on rajoute des fichiers existants. Il faut préciser que tous les fichiers rajoutés ont déjà été compilés et eu une édition du lien positif avec Visual Studio, et pour limiter les risques d'unresolved symboles, j'inclus les fichiers  un par un en commençant par les couches basses.

    J'ai donc suivi pas à pas les directives de msdn et du compilateur et j'ai codé:

    int argv = 10;
    array<std::string, 10> args;
    int main( argv, args)

    et le compilateur me répond:

    SpecificationLoader.cpp(11): error C2448: 'main' : l'initialiseur de style fonction semble être une définition de fonction

    Comment puis je m'en sortir?

    J'ai donc regardé le type et il demande bien un argument numérique pour la dimension du tableau, mais le compilateur n’accepte ni un chiffre, ni une variable int

    int main( array<System::String ^> args)

      Ça se reproduit chaque fois qu'on ajoute un fichier déjà existant, Même si on prend la précaution de les créer d'abord puis de les changer. C'est quand même de la doc de array _size que j'ai trouvé comme directive de compiler avec l'option /EHsc mais je ne sais pas comment d'exprimer. j'ai fait un essai à la volé qui a été infructueux. Déjà si je savais comment exécuter cette consigne ça m'aiderait.

    en attendant j'ai continué a travailler sur la syntaxe. et pas à pas je suis venu à ce résultat qui est insuffisant:

    int main( array<System::String ^, 10>^ args)

    avec le résultat de compilation suivant:

    1>SpecificationLoader.cpp(9): error C3699: '^' : impossible d'utiliser cette indirection sur le type 'std::tr1::array<_Ty,_Size>'
    1>          with
    1>          [
    1>              _Ty=System::String ^,
    1>              _Size=10
    1>          ]
    1>          le compilateur remplace '^' par '*' pour poursuivre l'analyse

    il semble donc que la taille ne soit pas mal initialisée et que le type args doivent être un handeler. Mais le compilateur ne l’accepte pas, alors un pointeur, mais il ne serait pas managé et c'est la demande du compilateur précédente qui dit que le type doit être un handeler.

    Je conclue que ce problème est du fait de la non génération de la maquette qui recopiait des fichiers de l'implémentation précédente, ce qui rompt les bases de données associées à Visual Studio.



    Jean Noël Martin









    • Marqué comme réponse JeanNoel53 lundi 10 septembre 2012 06:18
    • Non marqué comme réponse JeanNoel53 lundi 10 septembre 2012 06:46
    • Modifié JeanNoel53 mercredi 12 septembre 2012 14:52
    • Marqué comme réponse JeanNoel53 mercredi 12 septembre 2012 14:52
    lundi 10 septembre 2012 06:18
  • C'est un peu beaucoup le Bronx votre projet, là.

    C'est quoi ces signatures de main avec un mixe de array à la C++11 (le TR1 dans les messages d'erreurs, c'est pour la version Draft de C++11) et d'handler d'objet managé C++/CLI (le ^).

    Je doute fort que ce genre de code chimérique soit le fruit d'une génération de code à la création d'un projet.

    Quel VS et quel type et options de projet avez-vous choisi pour tombé sur cette signature de main "exotique" ?

    Je pense que vous essayez de corriger des problèmes sans prendre le recul pour analyser le problème pour correctement l'éradiquer.

    Je vois 2 motifs comme source à ce genre de micmac :

     - modification anarchique des options de compilations du projet qui résulte par l'utilisation d'options incompatibles

     - ajout de fichiers sources au projet qui ne sont pas adaptés au type du projet (comme des sources MFC par exemple) et qui peuvent redéfinir les options incompatibles avec le reste du projet (via des "#pragma comment(...)" par exemple).


    Paul Bacelar, Ex - MVP VC++

    mercredi 19 septembre 2012 17:37
    Modérateur
  • Ce problème venait d'une désynchronisation entre la base de donnés des forms et l'application.

    Jean Noël Martin

    jeudi 20 septembre 2012 08:21
  • Idem " la base de donnés des forms " , C'est quoi ce truc ?

    Paul Bacelar, Ex - MVP VC++

    jeudi 20 septembre 2012 08:27
    Modérateur
  • quand on crée un form l'application tien à jour le lien entre le .h et le .h design;

    Moi je recopias les deux dans le nouveau projet par copier coller et ça ne présentait pas de la même manière. c'est ce que j'appelle la Base de données.


    Jean Noël Martin

    jeudi 20 septembre 2012 08:55
  • C'est pas une base de données, c'est du code généré par le Design, mais c'est du code aussi valide que celui que vous faites "à la main".

    Si vous vous amusez à copier-coller du code, par extrait ou totalement, dans un autre projet qui n'a rien à voir, en termes d'options ou de framework, c'est normal que ça pète.

    Faudrait maitriser un peu plus les actions que vous faites, parce que là, vous me faites pensez à Mickey dans Fantasia.


    Paul Bacelar, Ex - MVP VC++

    jeudi 20 septembre 2012 10:02
    Modérateur