Zitat:

---

Original von thomas:
Sicher, wenn man Probleme hat, mit den 32 Signalen (oder 24, die man als User benutzen kann) auszukommen, dann muß man sparen.

---

Zitat:

---

Aber wann kommt das schonmal vor ?

---

Zitat:

---

Gut, ich habe noch keinen Word-Processor geschrieben, bei dem man beliebig viele Dokumenten-Fenster aufmachen kann. Aber bei sowas würde ich dann wohl auch jedem Fenster eine Sub-Task spendieren, ...

---

Zitat:

---

Schon aus dem Grund, daß man, wenn mal einer abstürzt, die anderen noch sauber speichern und schließen kann.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:
timerequest enthält am Anfang einen engebetteten IORequest und genau den übergibt man mittels &req->tr_node. Damit hat man ohne cast den richtigen Typ. In Amiga-Programmen wird viel zu oft mit Casts gearbeitet...

---

Zitat:

---

Original von whose:
So kann man es natürlich auch machen. Mit dem Cast geht es auch, noch dazu für beinahe jedes Device gleich, ohne jedesmal in den Strukturen schauen zu müssen, wie der eingebettete IORequest nun gerade heißt...

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von gni:
timerequest enthält am Anfang einen engebetteten IORequest und genau den übergibt man mittels &req->tr_node. Damit hat man ohne cast den richtigen Typ. In Amiga-Programmen wird viel zu oft mit Casts gearbeitet...

---

Amen.

Zitat:

---

Original von whose:
So kann man es natürlich auch machen. Mit dem Cast geht es auch, noch dazu für beinahe jedes Device gleich, ohne jedesmal in den Strukturen schauen zu müssen, wie der eingebettete IORequest nun gerade heißt...

---

Wenn Du mit einem spezifischen IORequest arbeitest, dann im Allgemeinen, weil Du dessen erweiterte Struktur benötigst. Dann mußt Du so oder so in die Dokumentation der Struktur schauen. Wenn Du allerdings nur den Basistyp brauchst, kann Du auch den Basistyp benutzen.

---

Hm, ich sehe schon, die Vertreter der "reinen Lehre" gewinnen die Oberhand Nun ja, die Leser dieses Threads werdens lesen und hoffentlich auffassen. Ich sehe das ganze zwar leicht anders (IORequest vs. IOStdRequest (da gibts keine Warnings? ), völlig unterschiedliche Bezeichner etc.), aber um solche Sachen will ich keinen Streit auslösen.

Ich kann ja das Beispiel entsprechend ergänzen, kein Problem.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Hm, ich sehe schon, die Vertreter der "reinen Lehre" gewinnen die Oberhand ;) Nun ja, die Leser dieses Threads werdens lesen und hoffentlich auffassen. Ich sehe das ganze zwar leicht anders (IORequest vs. IOStdRequest (da gibts keine Warnings? :D ), völlig unterschiedliche Bezeichner etc.), aber um solche Sachen will ich keinen Streit auslösen.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

whose:
Hm, ich sehe schon, die Vertreter der "reinen Lehre" gewinnen die Oberhand Nun ja, die Leser dieses Threads werdens lesen und hoffentlich auffassen. Ich sehe das ganze zwar leicht anders (IORequest vs. IOStdRequest (da gibts keine Warnings? ), völlig unterschiedliche Bezeichner etc.), aber um solche Sachen will ich keinen Streit auslösen.

---

Warum mußt Du jetzt mit "Birnen" anfangen? Wir haben über "Äpfel" geredet :-( Das diese beiden Strukturen nicht zueinander passen, sollte klar sein. Warum mußt Du andere fragen. Eventuell kann Olsen ja was dazu sagen.

---

Hm, da unterscheiden sich vermutlich unsere Sichtweisen, deswegen vielleicht... ich sehe das Ganze als "Benutzen eines AmigaOS-Devices auf dem empfohlenen Weg" und nicht als "wir übermitteln ohne jeglichen Bezug zum API die Adresse einer Struktur" (woher weiß man auf Anhieb, daß tr_node eine struct IORequest ist, wenn man länger nichts mit dem timer.device zu tun hatte?).

Bei allem Verständnis für "formal korrekte" Wege, es wird oft vergessen, daß viele Leute kein fotographisches Gedächtnis besitzen und manche Dinge schlicht vergessen werden (weil selten benötigt).

Die IO-Funktionen für Devices erwarten nun einmal den Zeiger auf eine Struktur vom Typ "IORequest", da kann ich nichts für.

Ich hätte vermutlich weniger Probleme mit Deiner Sichtweise, wenn Deine Vorgehensweise für alle Device-bezogenen Strukturen zutreffend wäre. Das ist sie aber nun mal nicht. Deswegen mein Vergleich von IORequest und IOStdRequest (spätestens da muß man ja so oder so wieder casten,um die Warnings loszuwerden. Da kann man das auch gleich konsequent tun, finde ich).

Möglicherweise ist das aber ein Punkt, den man nun (mit OS4 z.B.) ändern könnte. Einheitliche Typen und Bezeichner für die IORequests, Erweiterungen der Strukturen dahin, wo sie hingehören. Ans Ende der Device-spezifischen Struktur.

Wenn bei allen Devices mit Erweiterungen der IORequest-Struktur diese zu Beginn mit (device-Kürzel)_Node stehen würde, dann wäre das kein Thema. Man weiß, daß bei jedem Device zu Beginn der IO-Struktur ein IORequest mit dem Bezeichner bla_Node steht und gut.

So verwirrt es aber nur beim Lesen (wie gesagt, wer weiß schon, das tr_node eine struct IORequest ist? Man kanns "vermuten", weil es sich um eine Device-IO-Funktion handelt, aber "Vermuten" beim Lesen eines Programms? Ich weiß ja nicht...).

Meiner Meinung nach sinds einfach nur zwei verschiedene Sichtweisen des (mehr oder weniger) gleichen Vorgangs, die uns hier beschäftigen.

Du siehst es mehr aus der formalen (und keineswegs falschen) Sicht, ich mehr aus der Sicht des "Otto Normal"-Entwicklers, der eben nicht die Zeit und die Möglichkeiten hat, sich bis in alle Einzelheiten in ein API einzuarbeiten (nicht falscher als die formale Sicht, meiner Meinung nach).

Fallstricke in Sachen Cast gibt es genug, zweifellos, aber genauso gibt es Fallstricke in Sachen "nichtssagende Bezeichner". Ich glaube, das gleicht sich irgendwo aus.

Um es auf den Punkt zu bringen: Ich sehe ein, daß Du (im Hinblick aufs reichliche Casten) Recht hast. Nur bringt uns das nicht weiter und den Anfängern hilft es relativ wenig bei dem Versuch, AmigaOS zu verstehen und zu verwenden, wenn sie mit Formalien zugeworfen werden.

Was nicht heißen soll, daß erfahrene Leute wie Du nicht darauf aufmerksam machen dürfen, daß da einiges im Argen liegt. Ich bin mir sicher, daß das von den Mitlesenden aufgenommen und verwertet wird.

Nur meine 2 Cent...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233



[ Dieser Beitrag wurde von whose am 30.06.2006 um 15:49 Uhr geändert. ]

[ Dieser Beitrag wurde von whose am 30.06.2006 um 16:11 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

Sorry wenn ich diesen Zombie-Thread nochmal rauskrame, aber ich bekomme das mit dem Timer Device einfach nicht auf die Reihe. Könnte mal ein Fachmann den hier gezeigten "Uhren-Source" eindampfen und mir zeigen wie ich die vergangenen Millisekunden erhalte?

Ich habe versucht den hier gezeigten Source anzupassen, bin aber kläglich gescheitert. Der Overkill an Strukturen und Funktionsaufrufen ist einfach irre und für einen Windows-Programmierer kaum verständlich
--
PanzerZ |
methusalem | basic

[ - Antworten - Zitieren - Direktlink - ]

code:

---

#include <proto/timer.h>
#include <proto/dos.h>

int main (void)

{
struct timeval start;
struct timeval ende;
struct timeval diff;

GetSysTime (&start);

Delay (50);

GetSysTime (&ende);

diff = ende;
SubTime (&diff,&start);

Printf ("Startzeit: %10lu.%06lun",start.tv_secs,start.tv_micro);
Printf ("Endezeit:  %10lu.%06lun",ende.tv_secs,ende.tv_micro);
Printf ("Differenz: %10lu.%06lun",diff.tv_secs,diff.tv_micro);

return (0);
}

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

code:

---

timer.device/GetSysTime                               timer.device/GetSysTime

   NAME
	GetSysTime -- Get the system time. (V36)

   SYNOPSIS
	GetSysTime( Dest )
	            A0

	void GetSysTime( struct timeval * );

   FUNCTION
	Ask the system what time it is.  The system time starts off at
	zero at power on, but may be initialized via the TR_SETSYSTIME
	timer.device command.

	System time is monotonocally increasing and guarenteed to be
	unique (except when the system time is set back).

	A0 will be left unchanged.

	This function is less expensive to use than the TR_GETSYSTIME
	IORequest.

   INPUTS
	Dest -- pointer to a timeval structure to hold the system time.

   RESULTS
	Dest -- the timeval structure will contain the system time.

   NOTES
	This function may be called from interrupts.

   SEE ALSO
	timer.device/TR_GETSYSTIME,
	timer.device/TR_SETSYSTIME,

   BUGS

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

code:

---

#include <proto/exec.h>
#include <proto/dos.h>
#include <proto/timer.h>

struct Library *TimerBase;

int main (void)

{
struct MsgPort *port = CreateMsgPort();
if (port)
	{
	struct timerequest *timer = (struct timerequest *) CreateIORequest (port,sizeof(struct timerequest));
	if (timer)
		{
		if (0 == OpenDevice ("timer.device",UNIT_MICROHZ,(struct IORequest *)timer,0))
			{
			struct timeval start;
			struct timeval ende;
			struct timeval diff;

			TimerBase = (struct Library *) timer->tr_node.io_Device;

			timer->tr_node.io_Command = TR_GETSYSTIME;
			timer->tr_node.io_Flags   = IOF_QUICK;
			DoIO ((struct IORequest *)timer);
			start = timer->tr_time;

			Delay (50);

			timer->tr_node.io_Command = TR_GETSYSTIME;
			timer->tr_node.io_Flags   = IOF_QUICK;
			DoIO ((struct IORequest *)timer);
			ende = timer->tr_time;

			diff = ende;
			SubTime (&diff,&start);

			Printf ("Startzeit: %10lu.%06lun",start.tv_secs,start.tv_micro);
			Printf ("Endezeit:  %10lu.%06lun",ende.tv_secs,ende.tv_micro);
			Printf ("Differenz: %10lu.%06lun",diff.tv_secs,diff.tv_micro);

			CloseDevice ((struct IORequest *)timer);
			}
		DeleteIORequest ((struct IORequest *)timer);
		}
	DeleteMsgPort (port);
	}

return (0);
}

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

m68k-amigaos-g++ timer.cpp -O6 -o timer

timer.cpp:5: error: conflicting declaration 'Library*TimerBase' /usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/../../../../m68k-amigaos/sys-include/proto/timer.h:12: error: 'TimerBase' has a previous declaration as 'Device*TimerBase'
timer.cpp:5: error: type mismatch with previous external decl of 'Library*TimerBase' /usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/../../../../m68k-amigaos/sys-include/proto/timer.h:12: error: previous external decl of 'Device*TimerBase'
timer.cpp:5: error: declaration of 'Library*TimerBase' /usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/../../../../m68k-amigaos/sys-include/proto/timer.h:12: error: conflicts with previous declaration 'Device*TimerBase'

timer.cpp: In function 'int main()':
timer.cpp:22: error: cannot convert 'Library*' to 'Device*' in assignment
timer.cpp:51:2: warning: no newline at end of file

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Ich bekomme jetzt Daten aber die scheinen nicht zu stimmen. 9FPS in einem Programm das fast nichts tut? Zudem geht der Wert alle naselang in den negativen Bereich obwohl die Variable als unsigned deklariert ist.

Ich brauche doch einfach nur eine Möglichkeit zu jedem Zeitpunkt die Millisekunden zu erhalten der seit System- oder Programmstart vergangen sind
--
PanzerZ |
methusalem | basic

[ - Antworten - Zitieren - Direktlink - ]