IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++/CLI Discussion :

passage de tableaux (matrices) entre managé et non managé


Sujet :

C++/CLI

  1. #1
    Membre régulier
    Inscrit en
    Juillet 2006
    Messages
    298
    Détails du profil
    Informations forums :
    Inscription : Juillet 2006
    Messages : 298
    Points : 117
    Points
    117
    Par défaut passage de tableaux (matrices) entre managé et non managé
    Tout d'abord, bonne année à vous tous pour 2007.

    J'ai un projet en c++/cli utilisant des winforms pour entréés et sorties de mon programme. J'utilise des matrices(100x100) et vecteurs(100) que j'ai crée et alimenté dans mon code managé.
    J'ai une soubroutine critique (à exécuter rapidement). J'ai appris grâce à vous que cette fonction (sa définition) devait etre encadrée par #pragma unmanaged et #pragma managed.
    Plusieurs questions:

    1 - la fonction sera-t-elle compilée en natif ou en MSIL ? J'ai un doute car dans le forum MSDN, un internaute m'a écrit que le code de cette fonction serait en MSIL.

    2 - comment utiliser ces matrices et vecteurs dans ma fonction non managée ?
    marshaler, ou sauvegarder ces mat et vect dans un fichier et les rappeler par la fonction dans des pointeurs normaux ?

    3 - comment retourner ces valeurs dans mon code managé ?

    Merci beaucoup et d'avance pour vos réponses .

    Fredkr

  2. #2
    Rédacteur
    Avatar de nico-pyright(c)
    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    6 414
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 6 414
    Points : 16 075
    Points
    16 075
    Par défaut
    attention,
    il faut mesurer si le gain de temps est interessant, car les changements de monde managé à monde non managé sont couteux

    ensuite, tout dépend de comment sont stockées tes matrices, ce sont des array cli ?

    normalement, un code entouré des pragmas est compilé en natif

  3. #3
    Membre régulier
    Inscrit en
    Juillet 2006
    Messages
    298
    Détails du profil
    Informations forums :
    Inscription : Juillet 2006
    Messages : 298
    Points : 117
    Points
    117
    Par défaut
    Cher Nico-pyright, merci tout d'abord pour votre prompte réponse.

    J'ai bien lu un peu partout que du code non managé (géré) serait compilé en natif mais j'ai inclus ci-dessous une petite partie d'une de vos FAQ qui m'interpelle.
    En outre, peut-on dire que si la fonction non gérée n'effectue que des calculs mathématiques (produits de matrices, opérations bas niveaux, quelques conditions genre if, for....) et n'utilisant pas des fonctions compliquées serait compilée en code natif ou MSIL très performant proche du natif.


    "Une classe non managée par le CLR est dite native. Il faut cependant préciser que dans ce cas, natif ne veut pas dire forcément langage machine. Quand le mode de compilation est l'un des /clr, alors le code généré est toujours du MSIL (sauf dans le cas où le compilateur ne sait pas le générer).
    Par contre, quand le compilateur ne compile pas en mode /clr, alors le code est bien du langage machine."

    Excuse-moi encore pour mon entêtement mais je dois prendre une décision rapidement. C'est soit créer une DLL pour ma fonction et le reste en c# (plus facile à développer pour les winforms), soit rester en c++/cli et la fonction en non managé.

    Merci d'avance pour vos réponses, qui me seront, j'en suis sûr, très importantes.

    FredKr

  4. #4
    Rédacteur
    Avatar de nico-pyright(c)
    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    6 414
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 6 414
    Points : 16 075
    Points
    16 075
    Par défaut
    je ne sais plus exactement quelle est ta question

    il existe deux types de "natif", abus de langage certainement ...

    - dans un environnement .Net (mode de compilation /clr), une classe native est une classe compilée en .Net (MSIL), mais est une classe non gérée par le garbage collector. Donc pour faire simple, c'est une classe qui n'est pas précédée par le mot clé ref. Cependant, le code généré sera bien du MSIL

    - dans un environnement non .net (mode de compilation natif ou pour les zones entourées par les pragma #unmanaged #managed), le code (fonction ou classes) généré sera du code natif (du code x86)

  5. #5
    Membre régulier
    Inscrit en
    Juillet 2006
    Messages
    298
    Détails du profil
    Informations forums :
    Inscription : Juillet 2006
    Messages : 298
    Points : 117
    Points
    117
    Par défaut
    Je peux donc en c++/cli, avoir le mode de compilation /clr et tout ce qui est entre #pragma unmanaged et #pragma managed sera en code natif (x86).

    Ma confusion est grande et a été amplifiée quand j'ai regardé les webcasts c# où il y a notamment des comparaisons de codes assembleurs résultants pour 2 fonctions simples identiques, l'une compilée en MSIL et l'autre en c++ standard. Il y avait 4 fois plus de lignes de code en MSIL.
    Je me suis donc dit que le temps d'éxecution pouvait être dans le même rapport (je pourrais retrouver ce webcast chez MSDN).

    encore merci pour vos réponses.
    FredKr

  6. #6
    Rédacteur
    Avatar de nico-pyright(c)
    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    6 414
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 6 414
    Points : 16 075
    Points
    16 075
    Par défaut
    c'est certain qu'il y a plus de code en MSIL, mais bien souvent, il y a une optimisation ensuite par .Net

    Je veux bien le lien de la webcast

  7. #7
    Membre régulier
    Inscrit en
    Juillet 2006
    Messages
    298
    Détails du profil
    Informations forums :
    Inscription : Juillet 2006
    Messages : 298
    Points : 117
    Points
    117
    Par défaut
    Bonjour Nico,
    Voici le lien :
    http://www.microsoft.com/France/Visi...2-d83a8ec21926

    C'était une comparaison entre c# et c++ exactement, donc pas entre c++/cli managé et c++ dur.
    Mais comme pour le c# on obtient du code MSIL j'avais pensé que le C++/CLI managé pouvait fournir le même genre de code.
    C'est vrai je suis un peu perdu avec tous ces différents codes. Mon souci primordial est la rapidité d'execution. Si cette partie n'est pas rapide je me dirigerai vers visual Fortran (que j'ai déjà installé) mais avec tous ses inconvénients pour la convivialité des entrées et sorties.

    Salutations,

    fredKr

  8. #8
    Rédacteur
    Avatar de nico-pyright(c)
    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    6 414
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 6 414
    Points : 16 075
    Points
    16 075
    Par défaut
    Merci, je regarderais ca

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. C# DLL managé et non managé
    Par damien77 dans le forum C#
    Réponses: 1
    Dernier message: 01/07/2007, 03h32
  2. Echange d'objet entre classe managée et non managée
    Par alexadvance dans le forum C++/CLI
    Réponses: 15
    Dernier message: 13/04/2007, 14h45
  3. convertir un type non managé en type managé.
    Par poporiding dans le forum MFC
    Réponses: 6
    Dernier message: 22/05/2006, 10h49
  4. convertir un type non managé en type managé.
    Par poporiding dans le forum C++
    Réponses: 3
    Dernier message: 22/05/2006, 09h44
  5. code non managé avec interface managée ...
    Par izbad dans le forum MFC
    Réponses: 6
    Dernier message: 19/12/2005, 16h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo