Wie kann ich feststellen, aus welcher Methode eine andere aufgerufen wurde?

Pseudocode-Beispiel:

class MyClass {
    void a() {
        b();
    }
    void x() {
        b();
    }

    void b() {
        // woher weis ich, welche methode aufgerufen hat?
    }
};

Grüße, pktm

Gar nicht und du solltest dein Programm eher so gestalten, dass es egal ist, von wo die Funktion aufgerufen wird

Wo die funktion aufgerufen wird ist mir auch egal, aber ich brauche einen Aufrufkontext, um das Verhalten der Methode zu bestimmen.
So wird es halt ein Parameter.

Mit Methoden bezeichnet man im Übrigen nur die Funktionen von Klassen und Strukturen (ich sehe bei dir weder noch).

Oder du baust in die Funktionen, die die andere aufrufen, eine Erkennung ein (in deinem Falle a() und x()). Denn Anweisungen, die in einer Funktion stehen, haben auch den Zweck, dass sie von mehreren Orten aufgerufen werden können. Der Teil, der sich dabei unterscheidet, kann vor die Aufrufstelle eingebaut werden - oder eben als Parameter übergeben werden.

Mit Methoden bezeichnet man im Übrigen nur die Funktionen von Klassen und Strukturen (ich sehe bei dir weder noch).

Klasse ist jetzt dabei
Ich dachte, wenn ich Methode sage funktioniert das auch anders herum, so dass du dir Vorstellst, dass das alles in einer Klasse spielt.

Mit Methoden bezeichnet man im Übrigen nur die Funktionen von Klassen und Strukturen (ich sehe bei dir weder noch).

1. Strukturen sind Klassen.
2. Der Begriff "Methode" ist im Kontext von C++ nicht eindeutig, der Standard benutzt dieses Wort nicht. Der Begriff wird primär in der objektorientierten Programmierung gerne verwendet; da C++ nicht rein objektorientiert ist, gibt es dort dafür aber keine exakte Entsprechung. Je nach Kontext könnten nur virtuelle Funktionen, oder sonst nur nicht-statische Memberfunktionen, oder sonst jede Art Memberfunktion, oder sonst jede Memberfunktion und solche freien Funktionen, die mit der Klasse direkt assoziert sind, gemeint sein. Aus diesem Grunde sollte der Begriff hier nur mit Bedacht verwendet werden und jedenfalls kann er nicht so ohne Weiteres auf obige Definition reduziert werden - oder man legt das "von" sehr weit aus.

Im Endeffekt ist mir das aber auch Wumpe.

Für mich ist eine Methode eine Funktion ohne Rückgabewert. Und eine Funktion eine Methode mit.

Ich glaube da verwechselst Du jetzt aber Methode mit Prozedur

Für mich ist eine Methode eine Funktion ohne Rückgabewert. Und eine Funktion eine Methode mit....

Also diese Variante habe ich noch nie gehört.

Gruß,

Simon2.

Fellhuhn schrieb:

Für mich ist eine Methode eine Funktion ohne Rückgabewert. Und eine Funktion eine Methode mit.

Ich glaube da verwechselst Du jetzt aber Methode mit Prozedur

Nö. Prozedure umschließt alles. Habe ich auch noch nie anders gehört. *shrug*

Nö. Prozedure umschließt alles. Habe ich auch noch nie anders gehört

Dann schließe ich mich Simon an, diese Variante habe ich noch nie gehört. Die Unterscheidung die Du meinst kenne ich nur von Basic als Sub <-> Function und von Pascal als Procedure <-> Function.

LordJaxom schrieb:

Fellhuhn schrieb:

Für mich ist eine Methode eine Funktion ohne Rückgabewert. Und eine Funktion eine Methode mit.

Ich glaube da verwechselst Du jetzt aber Methode mit Prozedur

Nö. Prozedure umschließt alles. Habe ich auch noch nie anders gehört. *shrug*

Also wenn ich auf die Fachliteratur zurück schließe die ich zu Hause habe [Schwerpunkt C++/UML/C#], ist der verbreitete Konsenz (Der sich doch recht stark herauskristallisiert; Ich schätze mal mit etwa 80+%):

Funktion vs. Methode: Der Begriff Funktion wird für die Freien, der Begriff Methoden für die an Klassen gebundenen Funktionen verwendet. Letzteres gilt auch wenn die Funktion statisch deklariert wird (dann namentlich statische Methode genannt).

Prozedur: (Sofern der Begriff überhaupt noch in aktueller Lektüre verwendet wird)
Eine Funktion ohne Rückgabewert.

Aber um nochmal auf das Thema zurück zu kommen: Häufig (aber nicht immer) deutet es nach meiner Erfahrung auf einen Designfehler hin wenn das Verhalten einer Methode sich durch seinen Aufruf beeinflusst (Meist gibt es dann bessere Möglichkeiten über Überladung oder Polymorphie).

cu André

Wenn man schon objektorientiert Programmiert, sollte man auch die eindeutigen Namenskonventionen kennen und auch verwenden.
...

Das ist ein hehres Ziel, halte ich aber für illusorisch.
Man kann einfach nicht sagen "is OO" und damit ist alles gleich - es bleiben einfach doch recht unterschiedliche (sprachspezifische) Konzepte/Denk- und Herangehensweisen. ... und diese resultieren einfach auch in unterschiedlichen Begriffen.
Da wird eine "Zwangsharmonisierung der Begriffe" eher mehr Verwirrung erzeugen als beseitigen. Als Beispiel nehme ich mal den Begriff "Referenz", der in Java und in C++ etwas sehr anderes meint - und das wirkt sich gerade NICHT positov aus.
Ein anderes Beispiel ist der Begriff "Schnittstelle", zu der in C++ auch "freie Funktionen" gehören können (deswegen auch spezielle Lookup-Regeln), während man in Java darunter schon eine bestimmte (sprachspezifische) Technik versteht.

Gruß,

Simon2.

...
Aber um nochmal auf das Thema zurück zu kommen: Häufig (aber nicht immer) deutet es nach meiner Erfahrung auf einen Designfehler hin wenn das Verhalten einer Methode sich durch seinen Aufruf beeinflusst (Meist gibt es dann bessere Möglichkeiten über Überladung oder Polymorphie).

cu André

Ein Arbeitskollege von mir drückt das aus als "'Do_This_Or_That'-Parameter sind immer schlecht !"
... und in meiner Erfahrung sich das immer bestätigt.
(Klar, manchmal waren alle Alternativen NOCH schlechter, aber das macht diese nicht "gut")

Gruß,

Simon2.

int moep() ist eine Funktion
void moep() ist eine Methode
int Narf::moep() ist eine Member-Funktion
void Narf::moep() ist eine Member-Methode

"Durchsetzen" tut das aber auch niemand. Da werden meist alle Begriffe durcheinander geworfen und trotzdem versteht jeder was gemeint ist.

Dann erläutere ich mal partiell das Problem:
Es geht um einen Chartparser. Das ist ein System um einen Satz mit einer syntaktischen (Struktur zu versehen). Diese wird in einer Chart gespeichert.
Da ein Satz aber nicht immer nur mit genau 1 Syntaxbaum geparst werden kann muss man die Ambiguitäten irgendwie verwalten.

Naumann/Langer schlagen dafür die implizite Kantenrepräsentation vor. Siehe dazu S. Naumann & H. Langer: Parsing. Eine Einführung in die maschinelle Analyse natürlicher Sprache. Teubner, Stuttgart 1994, S. 161, Kapitel 7.4.2.

Wens wirklich interessiert: Hier gibts das Buch: http://www.uni-trier.de/index.php?id=13891

[Kauderwelsch]
Und in Prolog hab ich das damals so gemacht, dass ich mir gemerkt habe, in welchem Kontext eine Kante in die Chart eingetragen wurde um die implizite Kanten-Repräsentation umzusetzen.
[/Kauderwelsch]

...
int moep() ist eine Funktion
void moep() ist eine Methode
int Narf::moep() ist eine Member-Funktion
void Narf::moep() ist eine Member-Methode
...

Das klingt ja alles sehr schön .... aber kennst Du außer Dir noch jemanden, der das so sieht ?

Gruß,

Simon2.

..
Und in Prolog hab ich das damals so gemacht, dass ich mir gemerkt habe, in welchem Kontext eine Kante in die Chart eingetragen wurde um die implizite Kanten-Repräsentation umzusetzen.
...

Also "Kontext" ist doch eigentlich immer nur ein Euphemismus für "globale Variable" - in der Hoffnung, dass man mit dem Namen auch deren Probleme ablegen könnte.
Mach's doch mit globalen Variablen, wenn's sein muss - ich würde einen Parameter vorziehen (und sei es nur in separaten Aufruffunktionen oder einem anderen Parameter gekapselt).

Gruß,

Simon2.

pktm schrieb:

..
Und in Prolog hab ich das damals so gemacht, dass ich mir gemerkt habe, in welchem Kontext eine Kante in die Chart eingetragen wurde um die implizite Kanten-Repräsentation umzusetzen.
...

Also "Kontext" ist doch eigentlich immer nur ein Euphemismus für "globale Variable" - in der Hoffnung, dass man mit dem Namen auch deren Probleme ablegen könnte.
Mach's doch mit globalen Variablen, wenn's sein muss - ich würde einen Parameter vorziehen (und sei es nur in separaten Aufruffunktionen oder einem anderen Parameter gekapselt).

Gruß,

Simon2.

Nix globale Varibale - pfui! ^^
Das wurde in Prolog auch schön mit einem Parameter gelöst, auch wenn das eher der untypischere Weg war.

camper schrieb:

Nexus schrieb:

Mit Methoden bezeichnet man im Übrigen nur die Funktionen von Klassen und Strukturen (ich sehe bei dir weder noch).

1. Strukturen sind Klassen.
2. Der Begriff "Methode" ist im Kontext von C++ nicht eindeutig, der Standard benutzt dieses Wort nicht. Der Begriff wird primär in der objektorientierten Programmierung gerne verwendet; da C++ nicht rein objektorientiert ist, gibt es dort dafür aber keine exakte Entsprechung. Je nach Kontext könnten nur virtuelle Funktionen, oder sonst nur nicht-statische Memberfunktionen, oder sonst jede Art Memberfunktion, oder sonst jede Memberfunktion und solche freien Funktionen, die mit der Klasse direkt assoziert sind, gemeint sein. Aus diesem Grunde sollte der Begriff hier nur mit Bedacht verwendet werden und jedenfalls kann er nicht so ohne Weiteres auf obige Definition reduziert werden - oder man legt das "von" sehr weit aus.

1. Ich bin mir im Klaren darüber, dass struct und class in C++ bis auf die Zugriffsrechte identisch sind, aber kann man sie deshalb nicht namentechnisch trennen? Also "Struktur" für alle mit public als Defaultberechtigung, "Klasse" für jene mit private? Selber brauche ich eigentlich auch eher "Klasse", hier wollte ich betonen, dass es für beide gelte.

2. Danke für die Berichtigung; ich war mir relativ sicher, mit Methode eine Klassen-Memberfunktion zu bezeichnen.

In C++ ist es aber relativ häufig so, dass irgendwelche Bezeichnungen nicht ganz eindeutig sind, oder? Gerade wenn man z.B. von Struktur spricht, kann man neben dem Schlüsselwort struct und dessen Anwendung auch z.B. Programmstruktur, Dateistruktur etc. meinen... Klar muss man das halt eindeutig schreiben, meistens ist es auch aus dem Kontext ersichtlich. Ich denke nur, es gibt einige Begriffe, die sich nicht so leicht definieren lassen.

1. Man übergibt der Funktion alles was sie braucht um zu entscheiden was sie tun muss
2. Man macht unterschiedliche Funktionen die unterschiedliche Dinge tun
   3a) Man entscheidet anhand von Member-Variablen was zu tun ist
   3b) Man entscheidet anhand der konkreten Klasse eines Objekts was zu tun ist

Jede dieser Möglichkeiten kann man gut anwenden, allerdings kommt es sehr darauf an worum es geht. Wo z.B. viel konfiguriert und gescriptet wird wird man um (1) nicht herumkommen. (2) hat ansich keinen eigentlichen "Zweck", sondern ist IMO eher als "Normalzustand" anzusehen bzw. anzustreben. Und (3) ist bei Objektorientierter Programmierung oft angesagt, z.B. immer dort wo man Programmteile hat die mit einem abstrakten Interface arbeiten.

Globale Variablen sind IMO böse, und sollten vermieden werden solange nicht sehr gute Gründe für deren Einsatz sprechen. Und das tun sie wie Anfangs angedeutet nur ganz selten.

Um auf die eigentliche Fragestellung zurückzukommen: Unter Vernachlässigung einiger weniger Spezialfälle kenne ich nur folgende Möglichkeiten die Sinn machen. (Und Vernachlässigung von allem was mit jetzt u.u. entgangen ist)

Mit anderen Worten:
Unter Vernachlässigung dessen, was ich nicht weis, kenne ich folgende Möglichkeiten:

So wird es halt ein Parameter.

ja.