Discussion :

[lapanne]

Bonjour à tous,

Aujourd'hui, l'utilisation des pointeurs avec c# :

Je suis en train de faire un p'tit moteur 3D avec DirectX et je suis confronté à un petit problème :

Voilà un bout de code qui permet de modifier une instance de Device depuis l'appel de la méthode d'une classe Balle, un bête ref :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public void BalleRendering(ref Device device)
 {
      for (int i = 0; i < meshmat.Length; i++)
      {
            device.Material = meshmat[i];
            device.SetTexture(0, meshtext[i]);
 
            mesh.DrawSubset(i);
      }
 
 }

Appel de cette méthode dans le code program.cs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 balle.BalleRendering(ref device);
 
//device a été modifié gràce à l'appel de BalleRendering()
device.EndScene();

Mais :
J'aimerais cependant que ma signature de méthode soit plus du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 public void BalleRendering()
{
    for (int i = 0; i < meshmat.Length; i++)
    {
         device.Material = meshmat[i];
         device.SetTexture(0, meshtext[i]);
          //On dessine le mesh
           mesh.DrawSubset(i);
    }
}

Et que dans mon objet, je possède une référence à l'objet device. Un truc du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public ref Device MyDevice
{
    set { ... }
}

Ensuite dans mon program.cs, je ferai l'appel de cette façon :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
//on "lie" l'objet device à l'objet balle
balle.MyDevice = device;
 
balle.BalleRendering();
 
device.EndScene();

Alors j'ai pensé aux pointeurs de c++ mais il doit bien exister une autre manière non ? Ou alors je dois forcément passer par du code unsafe ? Ou alors je me plane complètement ?

[SirJulio]

Salut,

je n'ai peut etre pas tres bien compris le probleme, mais pourquoi ne pas gerer le rendu depuis Device ? Par exemple, on pourrait voir ca avec une interface IRenderable comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
    interface IRenderable
    {
        void Render(Device dev);
    }

ou chaque objet de ta scene implementerai cette interface.

Ensuite dans ton device, tu aurais une List<IRenderable> (ainsi qu'un Add(IRenderable) et une methode void RenderAll(void) qui encapsulerai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
        public void RenderAll()
        {
            listRender.ForEach(delegate(IRenderable rend) { rend.Render(this);});
        }

Pour l'idée principale, ca donnerai ca, apres il faut voir si il y a des priorités dans le rendu, ou des rendus partiels. Au final, on aurait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
            Device dev = new Device();
 
            dev.AddObject(new Balle());
 
            dev.RenderAll();
 
            dev.EndScene();

[lapanne]

Merci pour la réponse, ça m'a ouvert une piste de réflexion.

D'où quelques questions :

Device est un objet de la librairie Direct X. Je suis en train d'écrire un classe héritant de Device pour pouvoir rajouter des méthodes qui m'intéresse. Et notamment :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Dev.AddObject(Mesh Mesh)

Bon pour le moment, j'ai du mal mais ça arrive

Second remarque :

Je n'ai toujours pas compris l'interet d'implémenter une interface ? Est-ce pour obliger la classe à respecter la signature ? Ou y-a-t-il une uatre raison bien cacher ?

Merci d'avance

[SirJulio]

Salut,

pour l'interface, ca permet de faire MaCLasse.Render() sans te soucier de l'objet sous-jacent, de fait en appelant Render sur chaque objet d'une List<IRenderable> tu es sur que tous les objets de la liste appellerons leur Render quelqu'il soit (l'un dessinera une balle, l'autre un bonhomme, un autre le ciel etc ...). Donc l'interface sert à donner à tous tes objets de rendus une methode commune appelable qui effectuera le traitement suivant l'objet sous-jacent et dont l'implementation imcombera à la classe.

Pour le probleme du device, je ne peux pas trop t'aider, DirectX et moi ca fait 2.

Bon courage. =)

[ced600]

Je n'ai toujours pas compris l'interet d'implémenter une interface ? Est-ce pour obliger la classe à respecter la signature ?

Bah normalement c'est bien cela. Lorsque tu utilise un objet qui implémente une interface bien précise, tu es sur qu'elle redéfinie telle ou telle méthode.

C'est très utile lorsque tu utilises des modèles du genre MVC (Modèle Vue Controlleur) où tu va séparer ta partie calcul de ta partie accés au données et de ta partie affichage.
Ainsi par exemple tu va utiliser une interface entre le code qui lit les données et le code qui fait du calcul pour l'échange de donnée entre ces deux éléments. Cela te permet de les mettre dans des dll différentes. Pareil pour l'ihm et le partie calcul.
Ainsi si tu veux changer d'IHM et passé sur un affichage web par exemple, tu n'as qu'à modifier la partie Vue et tu n'as pas besoin de toucher au Controlleur ni au Modele, et donc de repasser les tests et tu n'as pas de risque d'introduire des bugs .

De façon général, le mot "interface" parle de lui même, il va permettre de définir les échanges de données entre un où plusieurs composants.

[lapanne]

Salut,

pour l'interface, ca permet de faire MaCLasse.Render() sans te soucier de l'objet sous-jacent, de fait en appelant Render sur chaque objet d'une List<IRenderable> tu es sur que tous les objets de la liste appellerons leur Render quelqu'il soit (l'un dessinera une balle, l'autre un bonhomme, un autre le ciel etc ...). Donc l'interface sert à donner à tous tes objets de rendus une methode commune appelable qui effectuera le traitement suivant l'objet sous-jacent et dont l'implementation imcombera à la classe.

Je vais surement dire une grosse c******* mais pour ça, j'utilise des classes virtuelles pour ça J'ai bon ou pas ? Vraiment, j'ai lu des bouquins mais j'arrive vraiment pas à saisir le truc et je sais que ça a un interet, c'est ça le pire

Bah normalement c'est bien cela. Lorsque tu utilise un objet qui implémente une interface bien précise, tu es sur qu'elle redéfinie telle ou telle méthode.

C'est très utile lorsque tu utilises des modèles du genre MVC (Modèle Vue Controlleur) où tu va séparer ta partie calcul de ta partie accés au données et de ta partie affichage.
Ainsi par exemple tu va utiliser une interface entre le code qui lit les données et le code qui fait du calcul pour l'échange de donnée entre ces deux éléments. Cela te permet de les mettre dans des dll différentes. Pareil pour l'ihm et le partie calcul.
Ainsi si tu veux changer d'IHM et passé sur un affichage web par exemple, tu n'as qu'à modifier la partie Vue et tu n'as pas besoin de toucher au Controlleur ni au Modele, et donc de repasser les tests et tu n'as pas de risque d'introduire des bugs .

De façon général, le mot "interface" parle de lui même, il va permettre de définir les échanges de données entre un où plusieurs composants.

Et tu pourrais pas me donner un exemple concret please ? Je sais j'abuse mais c'est pour la bonne cause... enfin ma bonne cause...

[ced600]

J'en ai pas sous la main, desole. Mais cela doit se trouver sur le net.

[cinemania]

En fait la vraie question c'est de savoir avec quoi tu travail...

Native DirectX ou avec DirectX Extension Managées.

dans tous les cas, il est inutile de te perturber l'esprit avec ces notions de références.

A moins que le type Device ne soit de type STRUCT il est dans tous les cas passé par référence. la seule différence quand tu écrit ref Device device sur un objet passé par référence, c'est que tu passe la référence de la référence... ce qui equivaut à **device en C++, ce qui signifie que tu souhaite modifier non pas l'objet Device mais la référence contenue dans device...

je ne suis pas sûre que modifier le "pointeur" device soit vraiment ce que tu souhaite.

[lapanne]

En fait la vraie question c'est de savoir avec quoi tu travail...

Native DirectX ou avec DirectX Extension Managées.

dans tous les cas, il est inutile de te perturber l'esprit avec ces notions de références.

A moins que le type Device ne soit de type STRUCT il est dans tous les cas passé par référence. la seule différence quand tu écrit ref Device device sur un objet passé par référence, c'est que tu passe la référence de la référence... ce qui equivaut à **device en C++, ce qui signifie que tu souhaite modifier non pas l'objet Device mais la référence contenue dans device...

je ne suis pas sûre que modifier le "pointeur" device soit vraiment ce que tu souhaite.

Effectivement, je viens de m'en rendre compte. J'ai enlevé les ref et ça marche tout seul.

Je viens d'implementer mon interface et de dérivé la classe Device afin d'y ajouter quelques méthodes. Ca marche
le code est plus propre mais c'est pas clair dans ma tête, va falloir bucher tout ça.
Merci à tous pour vos conseils !

[SirJulio]

Ben en fait, tu peux aussi utiliser une classe comme tu le dis (j'imagine qu'une classe virtuelle est une classe avec toutes ses methodes marquées comme virtiual ou abstract), mais vu qu'en C#, il n'existe pas d'heritage d'implementation multiple, ca peut etre genant. Faire une interface à la place est la meme idée sauf que tu peux implementer plusieurs interfaces dans une classe et que l'interace ne peut avoir de champs.

Pour comprendre l'utilité de l'interface, et bien, une classe implementant une interface quelqu'elle soit, tu es sur que tu peux appeler la methode de l'interface sur cette classe. Par exemple, dans une appli, tu as un "moteur" pour l'IHM, un autre pour l'accès aux données et enfin un dernier pour la relation entre les deux (le MVC cité ci dessus) implementant chacun leur interface (IUIEngine, IDac, IAdapter, par exemple). Si un jour tu veux changer l'accès aux données, il te suffit de créer le nouvel accès et le faisant deriver de IDac, et d'ecrire le code de la classe, tu n'auras rien d'autres à reecrire dans ton code puisque l'interface est la meme. Sans ca, tu aurais surement du reecrire de grands pans de ton code.

Donc le but d'une interface, c'est que la classe qui l'implemente passe un "contrat", quelle que soit la classe, tu es sur que tu pourras appeler la methode X (ou l'event Y, ou la propriété Z) presente dans l'interface.

[SirJulio]

Ben en fait, tu peux aussi utiliser une classe comme tu le dis (j'imagine qu'une classe virtuelle est une classe avec toutes ses methodes marquées comme virtiual ou abstract), mais vu qu'en C#, il n'existe pas d'heritage d'implementation multiple, ca peut etre genant. Faire une interface à la place est la meme idée sauf que tu peux implementer plusieurs interfaces dans une classe et que l'interace ne peut avoir de champs.

Pour comprendre l'utilité de l'interface, et bien, une classe implementant une interface quelqu'elle soit, tu es sur que tu peux appeler la methode de l'interface sur cette classe. Par exemple, dans une appli, tu as un "moteur" pour l'IHM, un autre pour l'accès aux données et enfin un dernier pour la relation entre les deux (le MVC cité ci dessus) implementant chacun leur interface (IUIEngine, IDac, IAdapter, par exemple). Si un jour tu veux changer l'accès aux données, il te suffit de créer le nouvel accès et le faisant deriver de IDac, et d'ecrire le code de la classe, tu n'auras rien d'autres à reecrire dans ton code puisque l'interface est la meme. Sans ca, tu aurais surement du reecrire de grands pans de ton code.

Donc le but d'une interface, c'est que la classe qui l'implemente passe un "contrat", quelle que soit la classe, tu es sur que tu pourras appeler la methode X (ou l'event Y, ou la propriété Z) presente dans l'interface.

[ced600]

Pour déterminer les architectures dont tu pourrais avoir besoin, il faut faire une architecture de ton programme.
C'est à dire définir un blog programme et déterminer avec quoi ce programme va dialoguer. Les échanges de donées entres ce programme et les entités exterieurs te permettent de déterminer une ou plusieurs interfaces.
Puis dans ton blog programme tu le divise en composants et les données echangées entre chaque composant détermineront une autre interface.

L'idée est de regrouper les éléments de ton code qui concernent un même "sujet" et de les séparer du reste du code, et de définir comment ils vont échanger des informations avec le reste du monde.
Ainsi en spécifiant tout ceci, tu limites les actions des développeurs en leur imposant une façon de fiare, mais aussi tu leurs assures l'existence de certaine fonctionnailités.
Tout cela facilite énormement le maintien et l'évolution d'un programme