typedef void (*pf)(std::string);
pf pointer = hallo;
pointer("Sag hallo");

Ich schreibe gerade ein php script in C/C++ um

Mit Funktionszeigern läuft das eingeschränkt

Im Falle von C, ja kann man sowas aehnliches Nachbilden .

Willst du C++ programmieren, vergiss funktionspointer, und nimmm virtuelle Funktionen fuer ! In C++ macht man solche Sachen eleganter mit Funktionsobjekten !

Ciao ...

Willst du C++ programmieren, vergiss funktionspointer, und nimmm virtuelle Funktionen fuer ! In C++ macht man solche Sachen eleganter mit Funktionsobjekten !

Nein, das ist nicht richtig.

Polymorphie ist _eine_ Möglichkeit, aber nicht zwangsläufig die beste. Callbacks sind oft eine super Lösung. Man muss ja nicht alles in Klassen packen - da kommt dann die Interfacehölle von Java/Swing-Listener raus...

Virtuelle funktionen sind nunmal das Sprachmittel fuer c++ um Funktionalitaet erst zur laufzeit zu koppeln. Also damit fuer mich der Ersatz fuer funktionspointer !

Callbacks nehm ich naturlich nur noch, wenn ich die ueber ne C-Schnittstelle exportieren muss ... und ne Hoelle hatt ich bisher noch nicht ...
Das geht auch alles ueber genau eine h-datei mit genau 1 basisklasse und Implementationsklassen fuer die entsprechenden Ausprägungen ... wo iss das unuebersichtlich ?

Ich hoffe du machst wenigstens die deklaration deiner funktionen static an ner klasse oder in nen namespace, oder magst mir erklaeren das globale funktionen sauber sind ?

Naja elegant is relativ, also ich find die C-Deklaration fuer den FunktionspointerTyp schon mega haesslich !

Ciao ...

Virtuelle funktionen sind nunmal das Sprachmittel fuer c++ um Funktionalitaet erst zur laufzeit zu koppeln. Also damit fuer mich der Ersatz fuer funktionspointer !

Schau dir Java an. Dort werden alle Funktionszeiger mit virtuellen Methoden implementiert. Das ist nicht so das wahre...

Schau dir mal ein simples foreach(), find_if(), etc. an. Du hast ueberall functors - die sind auch nichts anderes als Funktionszeiger, nur dass sie auch einen status haben können.

Mit templates kommt man zu richtig coolen sachen wie du zB an boost::signal oder sigc++ siehst.

wenn du es über polymorphie machst, verlangst du automatisch objekte. das ist etwas nervig. klar, oft ist es sinnvoll, keine frage, aber immer sicher nicht.

beispiel aus meinem TicTacToe (siehe mein Tutorial) - da hat man ein Menu. Statt die Funktionalitaet des Menüs über virtuelle Methoden zu implementieren (und somit ne menge kleiner Klassen zu haben (was zB in Java wiederum cool wäre, weil ein menu.register(new MenuItem() { void action() { call_someone(); } }); geht) registriert man callbacks auf die applikation.

das spart viele objekte und macht den code auch recht klar:

menu.register("Help", make_callback(this, Application::help));
ist doch schön, oder?

sonst müsste man

class HelpItem : public MenuItem
{
private:
  Application* app;
public:
  HelpItem(Application* app)
  : app(app)
  {}

  void action()
  {
    app->help();
  }
};

menu.register(new HelpItem(this));

Das geht auch alles ueber genau eine h-datei mit genau 1 basisklasse und Implementationsklassen fuer die entsprechenden Ausprägungen ... wo iss das unuebersichtlich ?

Beispiel: Menü mit 7 Einträgen.
Du hättest plötzlich 7 Klassen die nichts anderes sind als forwarder. In Java kein Problem, in C++ sehr verwirrend, weil du wirklich nur lokale Klassen hast, die du nie mehr anfasst, nur einmal instanziierst.

Ich hoffe du machst wenigstens die deklaration deiner funktionen static an ner klasse oder in nen namespace, oder magst mir erklaeren das globale funktionen sauber sind ?

Was hat das damit zu tun?
static mache ich funktionen aber eigentlich nie, da nehme ich lieber nen unnamed namespace...

Naja elegant is relativ, also ich find die C-Deklaration fuer den FunktionspointerTyp schon mega haesslich !

Man muss ja auch nicht rohe zeiger anfassen.

Du hast ueberall functors - die sind auch nichts anderes als Funktionszeiger

Aehm bitte ?
Paar beitraege weiter vorn hasst mir noch erklaert, das funktor != Funktionspointer :p Sonst wuerde das mit inlinen ned funktionieren ....

wenn du es über polymorphie machst, verlangst du automatisch objekte. das ist etwas nervig.

Ja, aber in klassischen Anwendungsfall (also da wo C Funktionspointer nimmt) brauchst du ja genau so viele funktionsdefinitionen ... ob die alle einzeln deklarierst oder an Klassen haengst, mir sind in diesem Falle die Klassen lieber.

Recht hasst, wenn die funktion schon exisiert, und die eigentlich in ner operation nur noch verlinken willst (daran hab ich grad ned gedacht) ... Ich nutz aber dann den funktionspointer auch nicht roh, sondern ueber makros (windows message queue) oder ueber funktoren !

Dein Besipiel mit dem menu iss nen reiner funktionspointer ?
make_callback(this, Application::help) Application::help iss doch ned static ? Wie ist eigentlich die Aufrufsyntax ? denk this ist dein Applikation object was datzughoert ?
Was passiert, wenn wer von Application ableitet um nen neues Help zu implementieren?
Sorry, hab mir dein beispiel ned angeschaut ...

Wie gesagt in deinem fall vielleicht ned relavant, weil er sein Application Object selber coden muss ... aber in Biblios mit vielen vordefinierten Grundfunktionalitaet isses doof, weil die virtualitaet eigentlich aushebelst / verbietet ...

Naja, in vielen sachen isses wirklich geschmacks -Sache ... QT benutzt auch extensiv funktionspointer (Signal / Slot) Ich finds ned schoen, weil man, wenn man eigene "Frameworks" auf sowas aufbaut, immer zwischenfunktionen reinhaengen muss, nur dafuer dass ableitungen spaeter funktionieren
oder man kann ihm Signal - Slot verbindungen ned vordefinieren ... auch doof(find ich)

Ciao ...

Methodenzeiger in Kombination mit Templates sind eine sehr schöne Sache, damit kann man elegante Callbacks realisieren. Funktor-Objekte sind auch recht praktisch - ein großer Teil der STL nutzt das.

Aehm bitte ?
Paar beitraege weiter vorn hasst mir noch erklaert, das funktor != Funktionspointer :p Sonst wuerde das mit inlinen ned funktionieren ....

Sind wir lustig?
functors sind eine Art von Funktionszeigern, lediglich ein bisschen mächtiger. Aber sie haben das selbe Prinzip wie ein Funktionszeiger...

Ja, aber in klassischen Anwendungsfall (also da wo C Funktionspointer nimmt) brauchst du ja genau so viele funktionsdefinitionen ... ob die alle einzeln deklarierst oder an Klassen haengst, mir sind in diesem Falle die Klassen lieber.

Blödsinn.
Funktion != Klasse
Es geht hierbei darum, dass du nicht immer eine fette Klasse machen kannst die alle Interfaces implementiert (schau dir mal schlecht designte Java Klasse an die 500 interfaces implementieren...) und man nicht immer für jeden forwarder eine eigene Klasse schreiben kann.

Wie würdest du mein Menü Beispiel mit nur einer Klasse implementieren?

Recht hasst, wenn die funktion schon exisiert, und die eigentlich in ner operation nur noch verlinken willst (daran hab ich grad ned gedacht) ... Ich nutz aber dann den funktionspointer auch nicht roh, sondern ueber makros (windows message queue) oder ueber funktoren !

Makros sind böse. Und rohe Zeiger fasst man sowieso nicht an...

Dein Besipiel mit dem menu iss nen reiner funktionspointer ?
make_callback(this, Application::help) Application::help iss doch ned static ? Wie ist eigentlich die Aufrufsyntax ? denk this ist dein Applikation object was datzughoert ?
Was passiert, wenn wer von Application ableitet um nen neues Help zu implementieren?
Sorry, hab mir dein beispiel ned angeschaut ...

Schau dir boost::signal oder sigc++ an.
Application::help ist nicht statisch und this ist vom Typ Application*

Wie gesagt in deinem fall vielleicht ned relavant, weil er sein Application Object selber coden muss ... aber in Biblios mit vielen vordefinierten Grundfunktionalitaet isses doof, weil die virtualitaet eigentlich aushebelst / verbietet ...

Wie willst du 10 Menü Einträge in ein Menü packen wenn jedes Item eine andere Funktion aufruft? Du kannst natürlich jedesmal das ganze Menü neu implementieren, aber das will man nicht. Man 'hängt' einfach die passende Funktion ein und fertig.

Naja, in vielen sachen isses wirklich geschmacks -Sache ... QT benutzt auch extensiv funktionspointer (Signal / Slot) Ich finds ned schoen, weil man, wenn man eigene "Frameworks" auf sowas aufbaut, immer zwischenfunktionen reinhaengen muss, nur dafuer dass ableitungen spaeter funktionieren
oder man kann ihm Signal - Slot verbindungen ned vordefinieren ... auch doof(find ich)

Das ist aber der C++ weg.
Warum wird denn gtkmm als schön empfunden? Eben weil es solche Sachen schön löst. Virtuelle Methoden sind nicht die Antwort auf alles, sieht man super an Java.

Findest du die STL Algorithm auch schlecht? Die verlangen auch oft einen Funktionszeiger. Weil Vererbung einfach blödsinnig wäre...