Connaitre le nom de la fonction qui l'a appelé

Version imprimable

17/03/2011, 08h33
Fr33dom

Connaitre le nom de la fonction qui l'a appelé
Bonjour a toutes et tous,

Vous allez d'abords me dire : as tu déjà cherché sur le net ?
Je vous dirais bien sur, je préfère essayer de chercher par mes moyens avant de venir demander de l'aide.

Mais la je vous avoue que je patauge un peux.
En effet, je voudrais savoir s'il existe un moyen de connaitre le nom de la fonction qui en appel une autre.
Cela ne me parait pas claire, je m'explique :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 sub SUB1() SUB3() End Sub sub SUB2() SUB3() End sub sub SUB3() SI appel par SUB1 ALORS SI appel par SUB2 ALORS End sub
Merci de votre aide

Et pardonné moi si la réponse a déjà été donné ou si je suis censé la connaitre.

Tu passes tout simplement par une variable

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
sub SUB1()
         SUB3("SUB1")
End Sub
 
sub SUB2()
         SUB3("SUB2")
End sub
 
sub SUB3(ProcedureAppelante as String)
         if ProcedureAppelante ="SUB1" ......
 
         if ProcedureAppelante ="SUB2" ......
End sub

Pas besoin de connaître la méthode appelante, il suffit de passer un paramètre à la méthode appelée.

Par exemple
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 sub SUB1() SUB3(True) End Sub sub SUB2() SUB3(False) End sub sub SUB3(param As Boolean) If param Then ... Else ... End If End sub
En espérant que je ne me sois pas trompé dans l'écriture, ne faisant pas de VB.Net ^^

Edit : Grilled :aie:

17/03/2011, 09h09
Fr33dom

Merci pour ces réponses.
J'avais envisagé de faire ce genre de chose, mais je pensais qu'il existait une autre manière de le faire, comme par exemple, dans le SUB3, connaitre le nom du sub appelant.

caller of a method,nom de l'appelant

bonjour
tu veux connaitre le nom de l'appelant ,quova dis?
oui tu peux acceder au frame la pile:
voici un code exhaustif avec 2 formes:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
 
'1er forme appele ses methodes internes
'appele les methodes d'un autre forme
Imports System.Reflection
Public Class Form1
    Private maForme2 As Form2 = New Form2
    Private Sub btnExecuteMethode1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnExecuteMethode1.Click
        Call Method1()
    End Sub
 
    Public Sub Method1()
        Dim n As Integer = 5
        n = n + 1
        Me.TextBox1.Text = n.ToString & vbCrLf
        Dim stTraceFrame As StackFrame = New StackFrame(1)
        Dim methode As MethodBase = stTraceFrame.GetMethod
        MessageBox.Show("Objet : " & methode.DeclaringType.FullName & " Appele par Sub : " & methode.Name)
        Me.TextBox3.Text = ""
        Me.TextBox3.Text = "Objet : " & methode.DeclaringType.FullName & " Appele par Sub : " & methode.Name & vbCrLf
        Call Method2()
    End Sub
    Public Sub Method2()
        Dim n As Integer = 3
        Dim d As Double = 125.45
        d = n * d
        Me.TextBox2.Text = d.ToString
        Dim stTraceFrame As StackFrame = New StackFrame(1)
        Dim methode As MethodBase = stTraceFrame.GetMethod
        MessageBox.Show("Objet Appelant  : " & methode.DeclaringType.FullName & " Appele par Sub : " & methode.Name)
 
        Me.TextBox3.Text = Me.TextBox3.Text & "Objet Appelant : " & methode.DeclaringType.FullName & " Appele par Sub : " & methode.Name
    End Sub
 
    Private Sub btnExecuteMethode2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnExecuteMethode2.Click
        maForme2.Method3()
        maForme2.Show()
 
    End Sub
End Class
'2eme forme
Imports System.Reflection
Public Class Form2
    Public Sub New()
 
        ' Cet appel est requis par le Concepteur Windows Form.
        InitializeComponent()
 
        ' Ajoutez une initialisation quelconque après l'appel InitializeComponent().
 
    End Sub
 
    Public Sub Method3()
        Dim n As Integer = 0
        Dim d As Double = 0
        d = n * 125.45
        Me.TextBox1.Text = d.ToString
        Dim stTraceFrame As StackFrame = New StackFrame(1)
        Dim methode As MethodBase = stTraceFrame.GetMethod
        MessageBox.Show("Objet Appelant : " & methode.DeclaringType.FullName & " Appele par Sub : " & methode.Name)
        Me.TextBox2.Text = Me.TextBox2.Text & "Objet Appelant : " & methode.DeclaringType.FullName & " Appele par Sub : " & methode.Name
    End Sub
End Class

bon code....

17/03/2011, 15h16
Guulh

Citation:

Envoyé par MABROUKI

bonjour
tu veux connaitre le nom de l'appelant ,quova dis?
oui tu peux acceder au frame la pile:

Attention !
1,
2,
3

Nooooooooooooooooooooooon, pas la réflexion ! :)

Le besoin est suuuuper simple, c'est même pas de la POO, c'est juste d'avoir une méthode dont le comportement dépend du contexte, et ça tombe pile poil bien parce que c'est précisément à ça que servent les paramètres des méthodes.

Blague à part: sans parler d'objet, de module, etc. le strict minimum d'encapsulation que l' on peut espérer, et que même C (et l'assembleur, je suppose) permet, c'est au niveau de la fonction. Et si une fonction doit remonter la pile d'appels pour savoir quoi faire, à quoi ça sert de faire une fonction...

Ca mérite un haiku (sans diérèse):

La réflexion est puissante,
mais n'est solution
que de bien peu de problèmes.
17/03/2011, 15h39
Fr33dom

Merci, c'est exactement ce que je cherchais.
17/03/2011, 19h39
MABROUKI

encapsulation,assembleur

bonjour guulh
Depuis quand l'assembleur permet d'encapsuler l'exploration de la pile et du pointeur de pile.C'est meme pour ca qu'il est fais et sans ca tu n'aurais pas à à ce jour les languages symboliques ( le c ,le c++ et le vb.net).
Ensuite connaitre le nom de l'appelant en quoi ca enfreint le principe de l'encapsulation puisque l'on ne fait que de la "reflection" qui est dans l'infrastructure du .Net Framework.
A quoi servirait d'ailleurs la "reflection",à mediter sur le .Net Framework?
Mais l'esprit de systeme,portee aux abstractions est un travers francais.
Bonne soiree
17/03/2011, 21h23
Guulh

Citation:

Envoyé par MABROUKI

Ensuite connaitre le nom de l'appelant en quoi ca enfreint le principe de l'encapsulation

Ben quand même, si il est codé en dur dans le SUB3 la chaîne "SUB1" et "SUB2", ca veut déjà dire que SUB3 sera pas appelable par une autre méthode, et qu'on pourra pas renommer SUB1 et SUB2 sans devoir modifier SUB3. On peut difficilement imaginer couplage plus fort.

Quand même, les différentes abstractions au dessus de l'assembleur servent à découper le code en modules les plus découplés possible. Donc déjà qu'en objet c'est pas forcément facile de concevoir une structure avec des ensembles de classes suffisamment découplés les uns des autres pour faciliter la maintenance, faciliter la réutisabilité, bref le b.a. ba de l'hygiène du développeur qui affectionne peu les plats de spaghettis qui ne survivent à leur concepteur qu'au prix d'un arrachage de cheveux qui rendrait Demis Roussos chauve, si en plus les méthodes triviales (je parle pas de cas complexes, de lib de binding, de log, ...) se mettent à se comporter différemment selon l'endroit où on les appelle...

Citation:

puisque l'on ne fait que de la "reflection" qui est dans l'infrastructure du .Net Framework.
A quoi servirait d'ailleurs la "reflection",à mediter sur le .Net Framework?

Ca sert pas à remplacer un paramètre booléen dans une fonction. Quand on a juste un clou à planter, on se sert pas d'une moissoneuse batteuse, même si ça peut marcher avec beaucoup d'efforts.

Citation:

Mais l'esprit de systeme,portee aux abstractions est un travers francais.
Bonne soiree

Je suis certes français, mais je t'assure que le même code présenté sur un forum anglophone aura strictement la même réaction. Et Dvp.com fait référence, je pense aux générations futures (:mouarf:) qui vont tomber sur ce thread, et je n'ai pas envie dans mes prochaines missions de tomber sur du code inutilement compliqué. Ca fait des choses à poster sur www.thedailywtf.com , mais il y a mieux à faire.

Bonne soirée :)
17/03/2011, 21h41
Nathanael Marchand

D'autant plus que remonter dans la StackFrame peut s'avérer faux si le code est optimisé lors de la compilation jit

bonjour guulh
Ton avis sur l'utilisation stackframe et caller by name,je l'ai bien deja c'est l'avis d'un francais ou d'un francophone qui n'est surement l'avis des anglophones .
en voici un exemple anglophone en c# :

Code:

1
2
3
4
5
6
7
8
9
10
 
//This can be useful e.g. to write debugging logs.
[C#]
using System.Diagnostics;
 
// get call stack
StackTrace stackTrace = new StackTrace();
 
// get calling method name
Console.WriteLine(stackTrace.GetFrame(1).GetMethod().Name);

Encore un autre exemple :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
using System.Diagnostics;
 
[STAThread]
public static void Main()
{
  StackTrace stackTrace = new StackTrace();           // get call stack
  StackFrame[] stackFrames = stackTrace.GetFrames();  // get method calls (frames)
 
  // write call stack method names
  foreach (StackFrame stackFrame in stackFrames)
  {
    Console.WriteLine(stackFrame.GetMethod().Name);   // write method name
  }
}

A quoi pourrait servir ce code-ci par exemple à ton avis d'une methode qui retourne un simple string.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
[public static string InvokeStringMethod(string typeName, string methodName)
{
    // Get the Type for the class
    Type calledType = Type.GetType(typeName);
 
    // Invoke the method itself. The string returned by the method winds up in s
    String s = (String)calledType.InvokeMember(
                    methodName,
                    BindingFlags.InvokeMethod | BindingFlags.Public | 
                        BindingFlags.Static,
                    null,
                    null,
                    null);
 
    // Return the string that was returned by the called method.
    return s;
}  
/CODE]

Et celui la par exemple pour la meme methode avec parametre:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
Below is a version that calls a method that expects one parameter of type string. 
public static string InvokeStringMethod2
    (string typeName, string methodName, string stringParam)
{
    // Get the Type for the class
    Type calledType = Type.GetType(typeName);
 
    // Invoke the method itself. The string returned by the method winds up in s.
    // Note that stringParam is passed via the last parameter of InvokeMember,
    // as an array of Objects.
    String s = (String)calledType.InvokeMember(
                    methodName,
                    BindingFlags.InvokeMethod | BindingFlags.Public | 
                        BindingFlags.Static,
                    null,
                    null,
                    new Object[] { stringParam });
 
    // Return the string that was returned by the called method.
    return s;
}

ces bouts de code sont facilement transposables en vb.net .
Bien sur on peut utiliser egalement le mapping de properties et methodes pour un objet cree dynamiquement (mappe sur un objet on n'a pas le code source) et on aurait besoin du StackFrame et de MethodeName pour decider du mappage ou non .
bonne soiree...

18/03/2011, 00h17
Nathanael Marchand

C'est pas parcequ'un anglophone l'utilise que c'est bien :aie:
Utiliser les StackFrame dans un code de production... Bof! Surtout pour l'utilisation dans ce thread! Pour débugger, c'est autre chose... Comme je l'ai dit plus haut, si la fonction qui navigue dans les frames et inliné on a un niveau qui saute. Son comportement est un peu imprévisible et surtout elle très gourmande!
18/03/2011, 01h00
Guulh
Mabrouki,

je ne dis pas que la stackframe ne sert jamais. Comme je l'ai écrit ci-dessus, il y a des cas où ca se justifie, j'avais cité le log justement, et tu l'as détaillé.

Bien.

Maintenant, le cas concret du créateur du thread : il a deux méthodes sub1 et sub2, et il veut qu'elles appellent toutes deux une même méthode Sub3, et que Sub3 se comporte un peu différemment dans les deux cas.

Il faudrait demander à fr33dom plus de détail sur son besoin. Mais t'es d'accord que si c'est du style (j'écris en C# parce que je connais pas la syntaxe VB.Net)
Code:

1 2 3 4 5 6 7 void Sub3() { if (méthodeAppelante == "Sub1") this.Label.Color = Color.Red else this.Label.Color = Color.Green }
T'es quand même d'accord que c'est crado ? Qu'il vaut mieux, soit ajouter un paramètre booléen à la méthode comme suggéré par StormimOn, soit carrément une couleur, et Sub3 se contente de faire this.Label.Color = color ?

Hormis le cas de log que tu cites, et qui est justifié, t'es quand même d'accord qu'une méthode est sensée se contenter des paramètres qui lui sont fournis, en plus des membres de la classe dans laquelle est déclarée ?
Surtout que le log que tu cites ne récupère pas la stacktrace pour se comporter différemment selon qui l'appelle ; elle s'en sert juste pour la logger. Et t'es d'accord que du code qui a besoin de connaitre sa stacktrace, c'est rare. Sinon, comment feraient les langages qui n'ont pas d'API de réflexion, C++ au hasard ?

Je dis pas que la réflexion sert à rien : je dis que son usage inconsidéré est nuisible.

Je demanderai à mes collègues maghrébins demain si c'est du délire de franchouillard :)
18/03/2011, 01h10
Anklor

J'ai placé en paramètre un type string, car rien ne dit que Fr33dom ne devait utiliser seulement 2 méthodes appelantes. Mais je suis d'accord avec toi, c'est carrément crado et qu'il faut mieux placer directement les paramètres plutôt que de savoir quelle procédure à fait appel et d'appliquer les paramètres en fonction.