✔ Event Timer in C/C++?

[Clund]

Hallo zusammen,
ich wüsste gerne, ob es eine Timerfunktion in C/C++ gäbe, für Linux. So änlich wie die in Java (java.util.timer).
Am besten wäre, wenn man dem Timer eine Funktion übergeben könnte, die dann dem Zeitintervall entsprechend aufgerufen wird.
Clund

 

[sheel]

Hi

Verschiedene Frameworks haben sowas, oder sonst einen einfachen Thread.
Sowas:

struct timerstruct
{
    void (*func)(void *);
    void *param;
    unsigned int ms;
};
void timerth(void *p)
{
    Sleep(((struct timerstruct *)p)->ms);
    ((struct timerstruct *)p)->f(((struct timerstruct *)p)->param);
    free(p);
}
void starttimer(int ms, void (*funktion)(void *), void *funktionsparameter)
{
    struct timerstruct *p;
    p = (struct timerstruct *)malloc(sizeof(struct timerstruct));
    p->func = funktion;
    p->param = funktionsparameter;
    p->ms = ms;
    _beginthread(p);
}
//...
void meinefunktion(void *meinparameter)
{
}
//...
char c[1024];
starttimer(1000, meinefunktion, c); //1 Sekunde

Das ist jetzt nur schnell hingekritzelt, besserer Pseudocode.
Hat nirgends Fehlerprüfung, ist nicht kompiliert, nicht getestet.

Zu beachten: Threadsafezeug in der aufgerufenen Funktion.
Und Sleep ist nicht wirklich exakt mit den Millisekunden.
Für die Framerate in einem Spiel oder so ist das damit nicht zu gebrauchen.

Gruß

 

[Clund]

Danke für die schnelle Antwort,
wofür brauchst du "timerth"?
Clund

 

[saftmeister]

Hallo,

auch wenn es vielleicht noch andere oder schönere Lösungen gibt, fällt mir grad nur das ein:

1. Schleife evtl. auch endlos z.B. mit while(1)
2. SIGALRM mit eigenem Handler registrieren
3. alarm()-Funktion benutzen, Anzahl der Sekunden als Parameter übergeben.
4. Im eigenen Handler die Geschäfslogik implementieren.

Dieses Beispiel ist aber unter Windows nicht so ohne weiteres umsetzbar, da weder MinGW noch MSVC alarm() oder SIGALRM kennen.

Grundsätzlich wäre es auch mit fork() oder Threads und sleep() lösbar.

 

[Clund]

Achso ja, wofür ich das brauche:
ich schreib grad nen sfml Projekt und will die Aktualisierung per Timer steuern
wärenddessen wird ganz unabhängig noch gerechnet
also kein while(), und keine exakt Abarbeitung ...
Clund

 

[sheel]

timerth ist der Thread.

SFML: Genau sowas mein ich mit Framerate=ungeeignet.
Wenn man den Minicode für die Bildaktualisierung einsetzt bekommt man lustige Sachen,
aber keine flüssige Animation.

SFML hat doch schon einen (um einiges besseren) Timer
Generell sollte man die Hauptschleife aber für die Animation lassen
und den Rest in Threads auslagern. Macht weniger Probleme.

 

[Clund]

Gut, muss ich wohl genauer erklären:
Der Inhalt meiner (erstmal 2D Graphik) soll eine Visualisierung (bzw. Funktionsplotter) für ART und SRT sein. Da brauche ich keine Fließenden Bewegungen.
Und danke, dass du mich auf den Timer von sfml aufmerksam gemacht hast, ich hab den in nem Testprogramm schon verwendet.
In der Hauptschleife werden dann (erstmal nur über Konsole) die Terme eingegeben, die dann angezeigt werden.
ich werde jetzt mal rumprobieren, und mich (in diesem Thread) wieder melden.
Clund
Edit: Ich verwende Linux, also saftmeister, das würde ja im Prinzip klappen

 

[Clund]

meine Lösung:
die Grafikklasse hab ich von Timer abgeleitet, und die Run() Funktion ruft draw() auf, was wiederum jede Sekunde eine FPS-Statistik ausgibt. d.h. es läuft mit maximaler FPS, derzeit (noch) über 1500 fps
Clund

 

[Clund]

nächstes Problem: nachdem ich mein Programm weiter geschrieben habe (von Thread, ... abgeleitet), gibt mir der Computer eine Fehlermeldung aus:

X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  26 (X_GLXMakeContextCurrent)
  Serial number of failed request:  52
  Current serial number in output stream:  52

Der Code, der dies verursacht ist:

Fenster.draw();

Fenster ist ein sfml-Window, als private deklariert, hat auch schon funktioniert, public hilft leider nicht.
Clund

 

[deepthroat]

Hi.

Ich kenne mich mit SFML nicht aus. Allerdings sind eigentlich alle graf. Nutzerschnittstellen single-threaded und nicht threadsafe, außer es ist explizit angegben.

Man darf also nicht von unterschiedlichen Threads auf die Grafikroutinen zugreifen.

Du kannst aber z.B. aufwendige Berechnungen in Threads auslagern und trotzdem auf GUI Ereignisse reagieren.

Gruß