warten

_matze

asdca schrieb:

Du kannst einen zähler einbauen wenn du es langsamer runterzählen möchtest, also ungefär so
int i,c;

for(i=0; i<0xffffffff;i++) {
 for(c=0; c<0xfffffff;c++)
   1+2;
}
mit den werten kannst du experementieren, bis die verzögerung die richtige länge hat

Ja, und das variiert dann je nach CPU... keine gute Lösung...

Hallo
kann hier vll jemand mal etwas an beispielcode posten wie das unter windows mit Sleep() gemacht wird?
Irgendwie funktioniert das bei mir nicht

gruß

Tachyon

#include <stdlib.h>
#include <stdio.h>
#include <windows.h>

int main()
{

    int n;
    puts("Bitte Warten...Der Prozess wird ausgefuehrt... ");
    for(n = 10; n >= 0; --n)
    {
        printf("%3d\r", n);
        Sleep(1000);
    }
    puts("\nErgebnis : Sie haben nichts zu zahlen.");

    return EXIT_SUCCESS;
}

_matze

Jaepen schrieb:

Hallo
kann hier vll jemand mal etwas an beispielcode posten wie das unter windows mit Sleep() gemacht wird?
Irgendwie funktioniert das bei mir nicht

gruß

Was denn genau? Hier sind geschätzte 1000 Varianten besprochen worden. Vielleicht zeigst du einfach mal, was du bislang hast.

Ansonsten hier mal Javaners Version mit Sleep und für die typische 25-Zeilen-Konsole:

int main() { 
	int i; 
	int j; 
	printf("Bitte Warten...Der Prozess wird ausgeführt...\n"); 
	for (i=10; i >= 1; --i) { 
		for (j=0; j < 25; j++) {
			printf("\n");
			Sleep(50);
		}
		printf("%d\n", i); 
		Sleep(300);
	} 
	printf("Ergebnis : Sie haben nichts zu zahlen.\n");
	getchar();
}

rüdiger

Azad schrieb:

ich arbeite unter Linux und mit C.

Als Editor benutze ich Eclipse.( mit C/C++ IDE)

Könntest du bitte das unter Linux nochmal beschreiben?

Danke

Azad

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

int main()
{

    int n;
    puts("Bitte Warten...Der Prozess wird ausgefuehrt... ");
    for(n = 10; n >= 0; --n)
    {
        printf("%3d\r", n);
        sleep(1);
    }
    puts("\nErgebnis : Sie haben nichts zu zahlen.");

    return EXIT_SUCCESS;
}

vlad_tepesch

kann man niht die aktuelle konsolenzeile mit \r löschen? dann kann man sich die 100 Zeilen Vorschub sparen.
Zumindest muss das irgendwie gehen, hab sowas doch schon mehr mals in anderen Konsolenanwendungen gesehen.
(Bsp: upx)

Brauchst nix zu löschen. Einfach überschreiben. Gibt doch (zumindest für Windows) eine Riesenmenge an Funktionen für die Steuerung von Konsolenoutput.

Javaner schrieb:

Azad schrieb:

Also,
nehmen wir an:...

Das ist doch schon was ganz anderes:

Werden deine Prozesse vom selben Programm ausgeführt
das auch die Ausgaben machen soll? Dann mußt du die
Ausgaben in einen selbständigen Thread auslagern und
diesem mit dem Teile, das die Prozesse steuert, synchronosieren.

Werden deine Prozesse "extern" ausgeführt?
Dann müssen deine Prozesse (Ausgabeprozess und eigentlicher Prozess)
miteinander kommunizieren.

Aber egal: Beide Varianten sind innerhalb des Ansi-C Bereichs
nicht zu lösen

Was soll dieser Quatsch: Ist mit Ansi-C nicht zu lösen?
Zumindest unter Windows ist es kein Problem, einen oder auch zig Threads zu starten, zu synchronisieren und verschiedene Prozesse miteinander kommunizieren zu lassen. Alles mit Ansi-C! Und vermutlich geht das unter Linux genau so gut.

TheTester

Belli schrieb:

[[...]
Was soll dieser Quatsch: Ist mit Ansi-C nicht zu lösen?
[...]

Ist es auch nicht, im C Standard ist keinerlei Funktionalität für die Verwendung mehrere Prozesse und der Kommunkation zwischen ihnen festgelegt. Das ist bei C Sache externer Bibliotheken bzw. des Betriebssystems und das gehört eben nicht mehr zum Sprachkern von Ansi C. Die Verwendung von Funktionen die das OS zur Verfügung stellt ist eine ganz andere Sache.

TheTester schrieb:

Belli schrieb:

[[...]
Was soll dieser Quatsch: Ist mit Ansi-C nicht zu lösen?
[...]

Ist es auch nicht, im C Standard ist keinerlei Funktionalität für die Verwendung mehrere Prozesse und der Kommunkation zwischen ihnen festgelegt.

Die Frage war ja nicht, ob das im C Standard festgelegt ist, sondern ob es mit C zu lösen ist.

TheTester schrieb:

Das ist bei C Sache externer Bibliotheken bzw. des Betriebssystems und das gehört eben nicht mehr zum Sprachkern von Ansi C. Die Verwendung von Funktionen die das OS zur Verfügung stellt ist eine ganz andere Sache.

C besteht nun mal in der Hauptsache aus Funktionen. printf() und getch() würden nicht funktionieren, ohne Funktionen, die das OS zur Verfügung stellt.
Und besteht mein Programm nicht mehr aus Ansi-C, wenn ich selbst eine Funktion schreibe, die Funktionen des OS aufruft?

supertux

Belli schrieb:

TheTester schrieb:

Belli schrieb:

[[...]
Was soll dieser Quatsch: Ist mit Ansi-C nicht zu lösen?
[...]

Ist es auch nicht, im C Standard ist keinerlei Funktionalität für die Verwendung mehrere Prozesse und der Kommunkation zwischen ihnen festgelegt.

Die Frage war ja nicht, ob das im C Standard festgelegt ist, sondern ob es mit C zu lösen ist.

das ändert aber aus der Aussage von TheTester nicht. Mit ANSI-C ist es nicht möglich, im ANSI C Forum wird man vergeblich nach einer Lösung suchen, denn ich könnte hier eine POSIX Lösung posten, während jemand anders eine Windows Lösung postet. Wir sind *im* ANSI-C Forum, hier geht es an sich fast auschließlich, um das was man mit ANSI-C mitteln lösen kann (oder ohne externe Bibliotheken).

TheTester schrieb:

C besteht nun mal in der Hauptsache aus Funktionen. printf() und getch() würden nicht funktionieren, ohne Funktionen, die das OS zur Verfügung stellt.
Und besteht mein Programm nicht mehr aus Ansi-C, wenn ich selbst eine Funktion schreibe, die Funktionen des OS aufruft?

Es spielt keine Rolle, ob das Betriebssystem Systemaufrufe zur Verfügung stellt oder nicht. Laut Standard ist es garantiert, dass die Funktion printf/getch so arbeiten, wie man sie kennt. Die Implementierung der C Bibliothek (z.b. gnu gcc) entscheidet, wie man printf/getch/usw implementiert. Für mich als Benutzer ist es egal, ob printf write aufruft oder nicht. Aber im Standard gibt es keine Funktionen, um solche genaue Timinganforderungen zu erfüllen, die sind eben nicht Umfang des ANSI-C Standards.

Okay, das heißt, wenn in meinem Programm für die WindowsPlattform die Instruktion

CreateThread(NULL, NULL, MyThread, NULL, 0, NULL);

vorkommt, dann ist das kein Ansi-C?
Wenn das so ist, dann habt Ihr sicher recht, aber um was handelt es sich dann?

Bedeutet das nicht konsequenterweise, daß dann kein Programm mehr dem Ansi-C - Standard entspricht, in dem der Autor selbst entwickelte Funktionen aufruft? Denn das sind ja dann Funktionen, die es im Standard nicht gibt ...

TheTester

Belli schrieb:

Okay, das heißt, wenn in meinem Programm für die WindowsPlattform die Instruktion
CreateThread(NULL, NULL, MyThread, NULL, 0, NULL);
vorkommt, dann ist das kein Ansi-C?
Wenn das so ist, dann habt Ihr sicher recht, aber um was handelt es sich dann?

Das ist eine Funktion des WinAPI, also der Schnittstelle die dir Windows zur Verwendung von betriebssystemspezifischen Funktionen zur Verfügung stellt. Das die Schnittstelle nun ein C-kompatibles Format besitzt liegt wohl daran das Windows sicher größtenteils mit C entwickelt wurde.

Belli schrieb:

Bedeutet das nicht konsequenterweise, daß dann kein Programm mehr dem Ansi-C - Standard entspricht, in dem der Autor selbst entwickelte Funktionen aufruft? Denn das sind ja dann Funktionen, die es im Standard nicht gibt ...

Nein so kann man das nicht sehen. Du kannst schreiben was du möchtest, dabei musst du dich an die Konventionen im C Standard halten um ein kompilierbares Stück Programm zu haben. Wenn du während der Entwicklung auf Funktionalität zurückgreifst die nicht mehr in der Standard C Libary enthalten ist (welche auch im C Standard erläutert wird) bewegst du dich ausserhalb des Standards und bist somit nicht mehr Ansi-C kompatibel, das gilt auch für z.B. spezielle Funktionalität die dir ein Compiler bietet, ein Bsp. wäre hier z.B. die Funktionsüberladung vom Lccwin32, das ist auch nicht im Standard hinterlegt.

supertux

Belli schrieb:

Bedeutet das nicht konsequenterweise, daß dann kein Programm mehr dem Ansi-C - Standard entspricht, in dem der Autor selbst entwickelte Funktionen aufruft? Denn das sind ja dann Funktionen, die es im Standard nicht gibt ...

es ist nur dann ANSI-C, wenn auf jedem System, wo ein C-Compiler drauf ist und nur die LIBC (also keine weitere externe Bibliotheken) vorhanden ist, kompilierbar und ausführbar ist.

supertux schrieb:

es ist nur dann ANSI-C, wenn auf jedem System, wo ein C-Compiler drauf ist und nur die LIBC (also keine weitere externe Bibliotheken) vorhanden ist, kompilierbar und ausführbar ist.

Na ... wenn das die Definition für Ansi-C ist, dann presche ich zurück und behaupte das Gegenteil.
Ich habe das noch nie so gesehen. Das bedeutet doch dann aber, daß ich mit Ansi-C nicht viel anfangen kann.
Nicht mal ein einfaches Windows-Fenster kann ich dann damit erstellen ...

Na gut - Ihr habt dann wohl Recht.

Tachyon

Belli schrieb:

[bla...]Ich habe das noch nie so gesehen. Das bedeutet doch dann aber, daß ich mit Ansi-C nicht viel anfangen kann.
Nicht mal ein einfaches Windows-Fenster kann ich dann damit erstellen ...

Na gut - Ihr habt dann wohl Recht.

Tja, wenn man meint, das Programme alle ein Windows-Fenster brauchen...

Tachyon schrieb:

Belli schrieb:

[bla...]Ich habe das noch nie so gesehen. Das bedeutet doch dann aber, daß ich mit Ansi-C nicht viel anfangen kann.
Nicht mal ein einfaches Windows-Fenster kann ich dann damit erstellen ...

Na gut - Ihr habt dann wohl Recht.

Tja, wenn man meint, das Programme alle ein Windows-Fenster brauchen...

Wer meint das denn?
Manche Programme brauchen das halt, andere brauchen einen oder mehrere Threads, wieder andere brauchen einen Timer, einen Socket ...

Tachyon

Belli schrieb:

Tachyon schrieb:

Belli schrieb:

[bla...]Ich habe das noch nie so gesehen. Das bedeutet doch dann aber, daß ich mit Ansi-C nicht viel anfangen kann.
Nicht mal ein einfaches Windows-Fenster kann ich dann damit erstellen ...

Na gut - Ihr habt dann wohl Recht.

Tja, wenn man meint, das Programme alle ein Windows-Fenster brauchen...

Wer meint das denn?
Manche Programme brauchen das halt, andere brauchen einen oder mehrere Threads, wieder andere brauchen einen Timer, einen Socket ...

Jo, und einige kommen auch ohne das alles aus.
Bibliotheken z.B. für so sinnlose Sachen wie digitale Signalverarbeitung oder mathematische Berechnungen...

Tachyon schrieb:

Jo, und einige kommen auch ohne das alles aus.
Bibliotheken z.B. für so sinnlose Sachen wie digitale Signalverarbeitung oder mathematische Berechnungen...

Wiederum hat niemand behauptet, daß es keine Programme gibt, die ohne das alles auskommen.
Dein erstes Beispiel verstehe ich allerdings nicht so recht. Digitale Signalverarbeitung hört sich so an, als ob es da um etwas spezielles, hardwareabhängiges geht, was auch nicht so recht in einen generellen Standard passt?

Ist aber auch egal, ich habe den Eindruck, wir haben uns verstanden und sind uns ja auch im Grunde einig.