Seite 3 von 3

Verfasst: Sonntag 18. Oktober 2009, 20:06
von jbs
kimx hat geschrieben:Jetzt gehts. Habe leider den Post mit der korrekten Methode nicht gesehen.
Sehr gutes Forum, danke nochmal

kimx
SCNR

Verfasst: Sonntag 18. Oktober 2009, 20:09
von Hyperion
mikehydro hat geschrieben:Danke Hyperion.

Nun hast Du zum Abschluß noch eine schöne Schlammschlacht geliefert.
Hat hoffentlich gut getan.
Inwiefern?
Ich bin jedenfalls nicht persönlich verbal beleidigend geworden.
Das ist hier im Forum eigentlich ein Standard!
Wo lernt man so was?
Was denn? Ich kapiere den Bezug zum Satz davor nicht...
Nun weiß hier jeder über Dich Bescheid.
Inwiefern?
Du hast ein tolles Niveau.
Danke, ich bemühe mich stests. Jaja, ich weiß, das was Ironie von Dir. Ich nehme es aber mal als unironisches Kompliment auf :-)
Wir sind stolz auf Dich.
Pluralis majestatis?

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?

Verfasst: Sonntag 18. Oktober 2009, 20:09
von ms4py
mikehydro 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.
Hab ich irgendwelche Beiträge von Hyperion überlesen oder hat der TS Halluzinationen
:?

Verfasst: Sonntag 18. Oktober 2009, 20:15
von Hyperion
pillmuncher hat geschrieben:
Hyperion hat geschrieben:
pillmuncher hat geschrieben:Python != C, und eine Lösung, die in C gut ist, braucht deswegen nicht auch in Python gut sein.
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.
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.

Gruß,
Mick.
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.

Verfasst: Sonntag 18. Oktober 2009, 20:38
von pillmuncher
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.
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}
    };
Auß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. 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.

Gruß,
Mick.

Verfasst: Sonntag 18. Oktober 2009, 20:49
von Hyperion
pillmuncher 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}
    };
Gäbe aber zumindest beim Compilieren ein Warning ;-)
Müßte man also statt dem char-Array einen Zeiger auf ein solches nehmen und dann die Länge beim Anlegen dynamisch allocieren?
Auß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.
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 durchschauen :-D
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.
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.

Verfasst: Sonntag 18. Oktober 2009, 21:00
von lunar
@Hyperion: Du kannst auch GHashTable nutzen.

Verfasst: Sonntag 18. Oktober 2009, 21:06
von Hyperion
lunar hat geschrieben:@Hyperion: Du kannst auch GHashTable nutzen.
Danke für den Hinweis. Die Glib ist für C ja mittlerweile fast ein Muss. Werde mein Beispiel dahingehend mal anpassen :-)

Verfasst: Sonntag 18. Oktober 2009, 21:14
von pillmuncher
Hyperion hat geschrieben:
pillmuncher 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);
};
Gäbe aber zumindest beim Compilieren ein Warning ;-)
Müßte man also statt dem char-Array einen Zeiger auf ein solches nehmen und dann die Länge beim Anlegen dynamisch allocieren?
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.
...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.
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...

Gruß,
Mick.

Verfasst: Sonntag 18. Oktober 2009, 21:21
von lunar
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.
Gemäß Murphys Law vergisst man es irgendwann aber doch, und den Fehler muss man dann erstmal finden.

Verfasst: Sonntag 18. Oktober 2009, 21:29
von bords0
Hyperion hat geschrieben:Und was genau ist daran

Code: Alles auswählen

def tolle_funktion(s):
    print "Hipp, Hipp,", s

func_name = tolle_funktion.func_name

# Aufruf dann...

eval(func_name)("Hurra!")
besser / leichter verständlich als

Code: Alles auswählen

def tolle_funktion(s):
    print "Hipp, Hipp", s

func = tolle_funktion
func("Hurra!")
?
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.

(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.

Verfasst: Sonntag 18. Oktober 2009, 21:30
von EyDu
pillmuncher hat geschrieben:Außerdem ist die Suche nach der passenden Funktion O(n) (naja, bei drei oder vieren...).
Und noch "eigentlicher" ist sie im Code konstant, da die Anzahl der Funktionen im Voraus veststeht.
mikehydro hat geschrieben:Zum Abschluß nochmal danke an bords0.

Diese Antwort hat mich am besten weitergebracht.
Das was Du hier schreibst funktioniert prima.
Und wenn du jetzt noch verstehst, warum es funktioniert, aber warum man es so auf keinen Fall machen sollte, dann hast du etwas wichtiges gelernt ;-)

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.

Verfasst: Sonntag 18. Oktober 2009, 21:59
von pillmuncher
EyDu hat geschrieben:
pillmuncher hat geschrieben:Außerdem ist die Suche nach der passenden Funktion O(n) (naja, bei drei oder vieren...).
Und noch "eigentlicher" ist sie im Code konstant, da die Anzahl der Funktionen im Voraus veststeht.

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.

Verfasst: Sonntag 18. Oktober 2009, 22:37
von EyDu
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}
    };

Verfasst: Sonntag 18. Oktober 2009, 23:00
von yipyip
Na da hab ich hier ja wieder was verpasst... :shock:

Das eigentliche Problem (nicht jedoch der Tonfall des OP!)
erinnert mich an
http://www.python-forum.de/topic-18873.html

Verfasst: Sonntag 18. Oktober 2009, 23:06
von lunar
@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.

Verfasst: Sonntag 18. Oktober 2009, 23:19
von Hyperion
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.

Verfasst: Montag 19. Oktober 2009, 09:40
von str1442
In den C-Foren klappt das besser. Ohne Überheblichkeit.
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).
Müßte man also statt dem char-Array einen Zeiger auf ein solches nehmen und dann die Länge beim Anlegen dynamisch allocieren?
Könnte man. Übringens könntest du noch alle Elemente der Struktur "const" machen. (Wobei ich gar nicht weiß, ob das bei Funktionszeigern klappt).
Ich sollte mir mal den C-Quellcode zum dict in Python angucken... vermutlich werde ich ihn wohl aber nicht durchschauen Very Happy
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 :).

Übringens kann man auch für Funktionspointer die "&" Syntax benutzen. C erlaubt für diesen speziellen Fall beide Notationen, einfach nur "func" und "&func".

Verfasst: Montag 19. Oktober 2009, 15:49
von EyDu
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.
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.