SCNRkimx hat geschrieben:Jetzt gehts. Habe leider den Post mit der korrekten Methode nicht gesehen.
Sehr gutes Forum, danke nochmal
kimx
Funktionsname in Variable speichern und wieder aufrufen
[url=http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29]PEP 8[/url] - Quak!
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Inwiefern?mikehydro hat geschrieben:Danke Hyperion.
Nun hast Du zum Abschluß noch eine schöne Schlammschlacht geliefert.
Hat hoffentlich gut getan.
Das ist hier im Forum eigentlich ein Standard!Ich bin jedenfalls nicht persönlich verbal beleidigend geworden.
Was denn? Ich kapiere den Bezug zum Satz davor nicht...Wo lernt man so was?
Inwiefern?Nun weiß hier jeder über Dich Bescheid.
Danke, ich bemühe mich stests. Jaja, ich weiß, das was Ironie von Dir. Ich nehme es aber mal als unironisches Kompliment aufDu hast ein tolles Niveau.
Pluralis majestatis?Wir sind stolz auf Dich.
Wieso eigentlich kannst Du nicht mal inhaltlich auf Dinge antworten, sondern flüchtest Dich permanent auf diese Meta-Ebene, sobald Du das gefühl hast, man würde Dich persönlich angreifen?
Hab ich irgendwelche Beiträge von Hyperion überlesen oder hat der TS Halluzinationenmikehydro hat geschrieben:Danke Hyperion.
Nun hast Du zum Abschluß noch eine schöne Schlammschlacht geliefert.
Hat hoffentlich gut getan.
Ich bin jedenfalls nicht persönlich verbal beleidigend geworden.
Wo lernt man so was?
Nun weiß hier jeder über Dich Bescheid.
Du hast ein tolles Niveau.
Wir sind stolz auf Dich.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Ha, ich wußte doch ich hatte mal so etwas ausprobiert:pillmuncher hat geschrieben:Schon. Und die Ähnlichkeiten gehen weiter, da man ja auch in C ein Mapping funcname --> function bräuchte. Dem OP Viel Spaß beim selber bauen.Hyperion hat geschrieben:Wobei man sich doch auch in C einen Zeiger auf die Funktion merken würde, oder nicht? Speziell bei diesem Problem sehe ich da sogar durchaus Ähnlichkeiten zu C.pillmuncher hat geschrieben:Python != C, und eine Lösung, die in C gut ist, braucht deswegen nicht auch in Python gut sein.
Gruß,
Mick.
http://paste.pocoo.org/show/145708/
Ich finde die Zeilen 42-46 und dann der Aufruf in Zeile 53 zeigen doch sehr schön die Ähnlichkeit zu dicts in Python.
- pillmuncher
- User
- Beiträge: 1484
- Registriert: Samstag 21. März 2009, 22:59
- Wohnort: Pfaffenwinkel
Stimmt. Aber mal angenommen, eine Funktion heißt "Zeitscheibe"? (Tipp: Buchstaben zählen )Hyperion hat geschrieben:Ha, ich wußte doch ich hatte mal so etwas ausprobiert:
http://paste.pocoo.org/show/145708/
Ich finde die Zeilen 42-46 und dann der Aufruf in Zeile 53 zeigen doch sehr schön die Ähnlichkeit zu dicts in Python.
Code: Alles auswählen
struct funcmap {
char name[10];
void (*func)(void);
};
...
// define our mapping
struct funcmap dispatch[CALLS] = {
{"foo", foo},
{"bar", bar},
{"index", bar},
{"Zeitscheibe", Zeitscheibe}
};
Gruß,
Mick.
In specifications, Murphy's Law supersedes Ohm's.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Gäbe aber zumindest beim Compilieren ein Warningpillmuncher hat geschrieben: Stimmt. Aber mal angenommen, eine Funktion heißt "Zeitscheibe"? (Tipp: Buchstaben zählen )Code: Alles auswählen
struct funcmap { char name[10]; void (*func)(void); }; ... // define our mapping struct funcmap dispatch[CALLS] = { {"foo", foo}, {"bar", bar}, {"index", bar}, {"Zeitscheibe", Zeitscheibe} };
Müßte man also statt dem char-Array einen Zeiger auf ein solches nehmen und dann die Länge beim Anlegen dynamisch allocieren?
Stimmt! Da müßte man also irgend wie hashen, um die Zugriffszeit zu verbessern und näher an ein dict zu kommen. Ich sollte mir mal den C-Quellcode zum dict in Python angucken... vermutlich werde ich ihn wohl aber nicht durchschauenAußerdem ist die Suche nach der passenden Funktion O(n) (naja, bei drei oder vieren...). Nicht, dass dein Code irgendwie schlecht wäre, man programmiert halt so in C.
Klar. Ich wollte ja nur mal zeigen, dass es in C nicht unbedingt anders läuft. Letzteres scheint der OP ja super zu verstehen; evtl. hilft es ihm ja auf die Sprünge.Aber die Verwendung eines Python-dicts ist im Vergleich dazu die flexiblere, einfachere und fehlertolerantere Lösung, insbesondere deswegen, weil man dict nicht erst selber programmieren muss.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Danke für den Hinweis. Die Glib ist für C ja mittlerweile fast ein Muss. Werde mein Beispiel dahingehend mal anpassenlunar hat geschrieben:@Hyperion: Du kannst auch GHashTable nutzen.
- pillmuncher
- User
- Beiträge: 1484
- Registriert: Samstag 21. März 2009, 22:59
- Wohnort: Pfaffenwinkel
Den Aufwand würde ich gar nicht treiben, sondern nur das char-Array vergrößern. Ist ja dein Code, und du weißt ja, wie lang deine Funktionsnamen sind. Vielleicht noch einen Kommentar daneben, damit man's nicht vergisst.Hyperion hat geschrieben:Gäbe aber zumindest beim Compilieren ein Warningpillmuncher hat geschrieben: Stimmt. Aber mal angenommen, eine Funktion heißt "Zeitscheibe"? (Tipp: Buchstaben zählen )Code: Alles auswählen
struct funcmap { char name[10]; void (*func)(void); };
Müßte man also statt dem char-Array einen Zeiger auf ein solches nehmen und dann die Länge beim Anlegen dynamisch allocieren?
Vielleicht wollte er auch nur zu erkennen geben, dass er eine "richtige" Programmiersprache kann, statt "bloß" eine "Scriptsprache". Aber wahrscheinlich nicht, denn man soll ja von den Menschen immer nur das beste denken......nur mal zeigen, dass es in C nicht unbedingt anders läuft. Letzteres scheint der OP ja super zu verstehen; evtl. hilft es ihm ja auf die Sprünge.
Gruß,
Mick.
In specifications, Murphy's Law supersedes Ohm's.
Gemäß Murphys Law vergisst man es irgendwann aber doch, und den Fehler muss man dann erstmal finden.pillmuncher hat geschrieben:Den Aufwand würde ich gar nicht treiben, sondern nur das char-Array vergrößern. Ist ja dein Code, und du weißt ja, wie lang deine Funktionsnamen sind. Vielleicht noch einen Kommentar daneben, damit man's nicht vergisst.
Für seine Zwecke nichts... Manchmal habe ich den Hang, die gestellte Frage genau zu beantworten; gelegentlich ist sie ja auch tatsächlich genau so gemeint und sinnvoll. Hier wären aber die dictionary- oder deque-Lösungen, die direkt das Funktionsobject beinhalten, besser.Hyperion hat geschrieben:Und was genau ist daranbesser / leichter verständlich alsCode: Alles auswählen
def tolle_funktion(s): print "Hipp, Hipp,", s func_name = tolle_funktion.func_name # Aufruf dann... eval(func_name)("Hurra!")
?Code: Alles auswählen
def tolle_funktion(s): print "Hipp, Hipp", s func = tolle_funktion func("Hurra!")
(Es gibt Ausnahmen, z.B. wenn der User selbstdefinierte Funktionen ausführen lassen können soll, oder wenn Funktionen erst später definiert werden.)
Dem OP möchte ich noch die Regel "eval is evil" mitgeben, auch wenn eval sein konkretes Problem löst.
Und noch "eigentlicher" ist sie im Code konstant, da die Anzahl der Funktionen im Voraus veststeht.pillmuncher hat geschrieben:Außerdem ist die Suche nach der passenden Funktion O(n) (naja, bei drei oder vieren...).
Und wenn du jetzt noch verstehst, warum es funktioniert, aber warum man es so auf keinen Fall machen sollte, dann hast du etwas wichtiges gelerntmikehydro hat geschrieben:Zum Abschluß nochmal danke an bords0.
Diese Antwort hat mich am besten weitergebracht.
Das was Du hier schreibst funktioniert prima.
Ich kann auch nicht nachvollziehen, warum du Hyperion so angehst. Er ist meiner Meinung nach, so weit es deine (magere) Problembeschreibung zulässt, vernünftig auf deine Fragen eingegangen und hat eine sinnvolle Lösung vorgeschlagen. Wie du das Problem in C gelöst hast/hättest, würde mich schon interessieren. Ich kann mir nämlich gerade keine (ordentliche) Lösung vorstellen, die dieses Problem nicht in ähnlicher Weise angeht.
Das Leben ist wie ein Tennisball.
- pillmuncher
- User
- Beiträge: 1484
- Registriert: Samstag 21. März 2009, 22:59
- Wohnort: Pfaffenwinkel
EyDu hat geschrieben:Und noch "eigentlicher" ist sie im Code konstant, da die Anzahl der Funktionen im Voraus veststeht.pillmuncher hat geschrieben:Außerdem ist die Suche nach der passenden Funktion O(n) (naja, bei drei oder vieren...).
Code: Alles auswählen
for(int i=0; i<CALLS; i++) {
if(strcmp(dispatch[i].name, argv[1]) == 0) {
dispatch[i].func();
return 0;
}
}
Gruß,
Mick.
In specifications, Murphy's Law supersedes Ohm's.
Nur weil dort eine for-Schleife ist, bedeutet dies noch nicht, dass die Suche linear ist.
Code: Alles auswählen
#define CALLS 3
...
// define our mapping
struct funcmap dispatch[CALLS] = {
{"foo", foo},
{"bar", bar},
{"index", bar}
};
Das Leben ist wie ein Tennisball.
Na da hab ich hier ja wieder was verpasst...
Das eigentliche Problem (nicht jedoch der Tonfall des OP!)
erinnert mich an
http://www.python-forum.de/topic-18873.html
Das eigentliche Problem (nicht jedoch der Tonfall des OP!)
erinnert mich an
http://www.python-forum.de/topic-18873.html
@EyDu: Wie definierst Du denn eine "lineare Suche"?! Und worauf willst Du mit deinem Quelltextausschnitt hinaus?
Im Allgemeinen jedenfalls ist es völlig ohne Belang, ob die Anzahl der Eingabewerte nun zufälligerweise konstant ist oder nicht. Der gezeigte Suchalgorithmus ist linear, und sofern der gesuchte Name nicht ebenfalls konstant ist, kann der Compiler das auch nicht in einen Zugriff in konstanter Zeit optimieren.
Im Allgemeinen jedenfalls ist es völlig ohne Belang, ob die Anzahl der Eingabewerte nun zufälligerweise konstant ist oder nicht. Der gezeigte Suchalgorithmus ist linear, und sofern der gesuchte Name nicht ebenfalls konstant ist, kann der Compiler das auch nicht in einen Zugriff in konstanter Zeit optimieren.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
So, hier mal die Glib-Fassung meines Beispiels:
http://paste.pocoo.org/show/145746/
An der ein oder anderen Stelle ist da sicher Luft für Optimierungen... muss mir diesen ganzen Zeiger-Kram noch mal genauer angucken.
http://paste.pocoo.org/show/145746/
An der ein oder anderen Stelle ist da sicher Luft für Optimierungen... muss mir diesen ganzen Zeiger-Kram noch mal genauer angucken.
Link? Laut Leonidas soll das zumindest in comp.lang.c (Recht groß?) nicht der Fall sein. Und ich hab noch von keiner nicht-C Version von Ulrich "WTF is this crap" Drepper gehört (ohne damit sagen zu wollen, daß alle C Programmierer so wären).In den C-Foren klappt das besser. Ohne Überheblichkeit.
Könnte man. Übringens könntest du noch alle Elemente der Struktur "const" machen. (Wobei ich gar nicht weiß, ob das bei Funktionszeigern klappt).Müßte man also statt dem char-Array einen Zeiger auf ein solches nehmen und dann die Länge beim Anlegen dynamisch allocieren?
Wenn du dir einfache C Implementationen für solche Datenstrukturen ansehen willst: Ich habe vor kurzer Zeit diese Seite gefunden. Sieht recht gut aus, hab ich aber selbst nur oberflächlich durchgeschaut .Ich sollte mir mal den C-Quellcode zum dict in Python angucken... vermutlich werde ich ihn wohl aber nicht durchschauen Very Happy
Übringens kann man auch für Funktionspointer die "&" Syntax benutzen. C erlaubt für diesen speziellen Fall beide Notationen, einfach nur "func" und "&func".
Ja, der Suchalgorithmus ist linear, das will ich auch gar nicht bestreiten. Mir ging es hier um die konkrete Ausprägung mit drei Elementen. Dafür ist es sehr einfach eine Abschätzung mit konstanter Schranke zu machen.lunar hat geschrieben:@EyDu: Wie definierst Du denn eine "lineare Suche"?! Und worauf willst Du mit deinem Quelltextausschnitt hinaus?
Im Allgemeinen jedenfalls ist es völlig ohne Belang, ob die Anzahl der Eingabewerte nun zufälligerweise konstant ist oder nicht. Der gezeigte Suchalgorithmus ist linear, und sofern der gesuchte Name nicht ebenfalls konstant ist, kann der Compiler das auch nicht in einen Zugriff in konstanter Zeit optimieren.
Das Leben ist wie ein Tennisball.