Programm im hintergrund laufen lassen?

Hi,

da ich gerade versuche ein kleines Programm zu schreiben das mir nach einer gewünschten zeit den PC herunterfährt (siehe auch post zu system("shutdown");),
habe ich ein kleines Problem, und zwar muss ich ja die lokale Zeit immer wieder abfragen und mit der eingegebenen vergleichen... so etwa:

for(;;)
     {      tm = time(NULL);
            zeit = localtime(&tm);
            if(zeit->tm_hour == zeitshuth && zeit->tm_min == zeitshutm)
            std::cout<<"SHUTDOWN"<<std::endl;

            }

nur ist die auslastung der cpu sehr sehr hoch in der Zeit,m was ja nicht sinn und zweck der sache ist...

Kann mir einer eine hilfestellung bzw. Link geben womit ich das Programm quasi im Hintergrund ablaufen lassen könnte?

Danke schonmal
MfG

audacia

http://msdn.microsoft.com/en-us/library/aa383614(VS.85).aspx

Irgendwelche Seiten in deutsch gibt es nicht?

Tobias Gerg

Ohne Englisch wirst du nicht weit kommen...

Dafür schreibt man am besten ein Windows-Programm das in der endlos-schleife windows-messages verarbeitet, dann ist die Auslastung niedriger. Wie das geht, steht aber zu Hauf im Netz.
http://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows
rya.

Wenn schon Win-API, dann doch lieber einen Timer verwenden. Dürfte das Ressourcen schonenste sein...

Joe_M. schrieb:

Wenn schon Win-API, dann doch lieber einen Timer verwenden. Dürfte das Ressourcen schonenste sein...

Wenn schon richtig, dann würde ICH es mit wxWidgets schreiben, das ist das schnellste und einfachste vom Code her :p.. und es würde auch auf Linux laufen...
Stichworte: wxTimer, wxTaskBarIcon, wxAppConsole
rya.

Dravere

Scorcher24 schrieb:

Wenn schon richtig, dann würde ICH es mit wxWidgets schreiben, ...

Aber bitte nicht für sowas kleines. Bis er nur wxWidgets auf der Platte hat und sein Programm richtig eingerichtet, wäre er auf dem anderen Weg fertig.
Des Weiteren ist wxWidgets ein altes und hässliches Framework. Ich nutze es nur für Platformunabhängige GUIs und würde am liebsten sogar darauf verzichten. Die Leute von wxWidgets sind der C++ Zeit um Jahrzehnte hintennach.

Scorcher24 schrieb:

... das ist das schnellste und einfachste vom Code her :p.. und es würde auch auf Linux laufen...

Ich hoffe du meinst schnellste vom schreiben her. Denn wxWidgets wrappt ja einfach die WinAPI, daher kann es nicht schneller von der Ausführungszeit sein
Allerdings habe ich so meine Zweifel mit dem schnell schreiben. Das wxWidgets Framework ist wirklich hässlich. Gerade einen Timer kann man mit der WinAPI womöglich schneller programmieren.

Alles was du brauchst ist:
SetTimer - http://msdn.microsoft.com/en-us/library/ms644906.aspx
KillTimer - http://msdn.microsoft.com/en-us/library/ms644903(VS.85).aspx
Eine Callback Funktion - http://msdn.microsoft.com/en-us/library/ms644907(VS.85).aspx

Scorcher24 schrieb:

Stichworte: wxTimer, wxTaskBarIcon, wxAppConsole

Taskbar Icon hat er nicht verlangt

Grüssli

Des Weiteren ist wxWidgets ein altes und hässliches Framework

Jedem seine Meinung.

Ich hoffe du meinst schnellste vom schreiben her. Denn wxWidgets wrappt ja einfach die WinAPI, daher kann es nicht schneller von der Ausführungszeit sein

Korinthenkackerei. Und ja, ich meine vom Schreiben her. Das sind einige Zeilen Code. Der Unterschied im Speed dürfte minimal sein.

Taskbar Icon hat er nicht verlangt

Service des Hauses.
rya.

Tachyon

Scorcher24 schrieb:

Des Weiteren ist wxWidgets ein altes und hässliches Framework

Jedem seine Meinung.

Die Meinung bildet sich aber automatisch, wenn man die Programmierrichtlinien von wxWidgets liest.
Hier nur mal so die ersten 8:

http://www.wxwidgets.org/develop/standard.htm schrieb:

New or not widely supported C++ features

Don't use C++ templates

Don't use C++ exceptions

Don't use RTTI

Don't use namespaces

Don't use STL

Don't declare variables inside for()

Don't use nested classes

Don't use new logical operators keywords

Man beachte, was die als "neue, wenig unterstützte C++-Features bezeichnen".

Man muss sich auf der Seite aber auch die Begründungen durchlesen nud wxWidgets ein wenig kennen. Und einiges ist schon gar nicht mehr wahr. So kann man mit wxUSE_STL wxWidgets die STL nutzen lassen. RTTI bringt wxWidgets von Haus aus mit, um Exceptions streiten sich ja hier aufm Board schon alle und die Templates haben etwas damit zu tun, dass viele Compiler unterstützt werden sollen. Vor allem der VC6 hat ja seine Probleme mit Templates hab ich so gelesen.
Aber nur so aufgelistet ohne Hintergrundwissen liest sich das freilich schlecht.
Was STL betrifft: wxWIdgets wurde in den 90ern geschrieben... so viel dazu^^.
Und die wxString-Klasse unterstützt i18n wirklich großartig mit Konvertierungsmöglichkeiten wie als bsp. wxString("foobar", wxConvUTF8) etc. Aber es funktioniert einwandfrei und so manche Dinge gehen mit wxWidgets besser als mit QT und andersrum.
rya.

Dravere

@Scorcher24,
Das wxWidgets alt ist, sollte klar sein. Das Schlimme allerdings ist, dass die Entwickler hinter wxWidgets konservativer als wir Schweizer sind. Und das bedeutet etwas!
Viele haben ja auch gehofft, dass mit wxWidgets 3.0 endlich ein Bruch gemacht werden würde, dass man endlich auch modernes C++ einführen würde, aber nada. Man will lieber den VC6 unterstützen, welcher inzwischen über 10 Jahre alt ist. Und genau da liegt auch eines der Probleme von wxWidgets. Die werden auch in 100 Jahren noch den VC6 unterstützen wollen, nur weil ein paar wenige diesen noch verwenden. Dadurch wird es aber nie möglich sein, die Bibliothek auf Vordermann zu bringen.

Auch sehr hässlich an wxWidgets ist der massive Einsatz von MAKROS und das halt eben nur, weil sie unbedingt auf Templates verzichten wollen.

Ich meine, wenn man wxWidgets mit den C++ Augen von 1990 anschaut, dann ist die Bibliothek echt gut. Sie ist einfach extrem veraltet. Und die Entwickler wollen sie unbedingt nicht modernisieren.

Aber eben in diesem gesamten Kontext ist es ein wenig fraglich, dass du dieses riesige Framework bei so einem Problem empfiehlst. Die Bibliothek ist uralt und ist nicht irgendwie speziell auf Timer spezialisiert.

Grüssli

Tachyon

Scorcher24 schrieb:

...

Man sollte meinen, dass knapp 6 Jahre (ich beziehe mich jetzt mal auf den Standard von 2003) reichen, um zumindest die Programmierrichtlinien mal anzupassen. Vom Code mal ganz zu schweigen.