Seite 1 von 4
Größe von 'time_t' ?
Verfasst: 29.08.2014 18:38
von SBond
Hallo Leute,
ich habe in PB Funktionen eingebunden, mit denen ich Zeitmessungen durchführen kann...
Code: Alles auswählen
[...]
CompilerCase #PB_OS_Linux
;Clock-ID's = Type of clock to use
#CLOCK_REALTIME = 0
#CLOCK_MONOTONIC = 1
#CLOCK_PROCESS_CPUTIME_ID = 2
#CLOCK_THREAD_CPUTIME_ID = 3
#CLOCK_REALTIME_HR = 4
#CLOCK_MONOTONIC_HR = 5
Structure timespec
tv_sec.???
tv_nsec.l
EndStructure
ImportC ""
clock_getres.i(clock_id.i, *res.timespec)
clock_gettime.i(clock_id.i, *tp.timespec)
EndImport
[...]
die Struktur 'timespec' wird wie folgt definiert:
Code: Alles auswählen
struct timespec
{
time_t tv_sec; /* seconds *
long tv_nsec; /* nanoseconds *
}
'tv_nsec' ist ein normaler Long und somit 4 Byte groß. Wie sieht es mit 'tv_sec' aus? Ich finde keine eindeutigen Angaben. Es ist entweder ein long oder ein long long. Kann ich notfalls ein long long (tv_nsec.q) daraus machen oder besteht die Gefahr, dass beim befüllen der Struktur Fehler auftreten.
viele Grüße,
SBond
Re: Größe von 'time_t' ?
Verfasst: 29.08.2014 19:11
von ts-soft
time_t sollte ein Integer sein! Also long auf 32-bit und quad auf 64-bit.
Gruß
Thomas
Re: Größe von 'time_t' ?
Verfasst: 29.08.2014 19:52
von SBond
ahh ok.
Ich bin bei sowas immer sehr vorsichtig, da ich zumindest unter C++ schon öfters Probleme bei falscher Dimensionierung hatte.
Re: Größe von 'time_t' ?
Verfasst: 29.08.2014 20:48
von Sicro
SBond hat geschrieben:Kann ich notfalls ein long long (tv_nsec.q) daraus machen oder besteht die Gefahr, dass beim befüllen der Struktur Fehler auftreten.
Nehmen wir mal an, die Funktion erwartet tv_sec und tv_nsec als Long, du definierst tv_sec jedoch als Quad (Doppel-Long), dann schreibt die Funktion beide Werte (tv_sec und tv_nsec) in tv_sec, weil ja beide Longs in das Quad passen und tv_nsec bleibt unberührt.
Die Funktion weiß nicht, dass der Speicher von dir strukturiert ist, weil ein strukturierter und unstrukturierter Speicher gleich aussieht. Die Struktur, die du definierst, erleichtert dir nur den Zugriff auf die Teildaten des Speichers, da du nicht mit Bytes rechnen musst, sondern nur noch angeben brauchst: Ich will tv_sec. Der Computer weiß, weil du das ja so definiert hast, dass tv_sec hier im Beispiel 4-Bytes groß ist (eine Long-Variable) und liest die aus dem Speicher. Möchtest du tv_nsec, weiß der Computer er muss die 4-Bytes von tv_sec überspringen und dann 4-Bytes für tv_nsec lesen.
Die Struktur gibt es also im fertigem (kompiliertem) Programm-Code nicht mehr, sondern nur noch die aus der Struktur berechneten Positionen und Längen in Bytes.
Re: Größe von 'time_t' ?
Verfasst: 29.08.2014 21:29
von Makke
Re: Größe von 'time_t' ?
Verfasst: 29.08.2014 21:49
von ts-soft
GLib Reference Manual: Date and Time Function hat geschrieben:Note that GTime is defined to always be a 32-bit integer, unlike time_t which may be 64-bit on some systems.
Demnach ist es Integer, anders als GTime. Aber will mich da nicht festlegen
da ich nicht weiß was "some systems" sind. Für mich hört sich das an, wie alle 64-Bit Architekturen.
Re: Größe von 'time_t' ?
Verfasst: 29.08.2014 22:39
von SBond
Sicro hat geschrieben:Nehmen wir mal an, die Funktion erwartet tv_sec und tv_nsec als Long, du definierst tv_sec jedoch als Quad (Doppel-Long), dann schreibt die Funktion beide Werte (tv_sec und tv_nsec) in tv_sec, weil ja beide Longs in das Quad passen und tv_nsec bleibt unberührt.
exakt. Genau das meinte ich.
@Makke: Aber auch auf 64-Bit systeme?
Re: Größe von 'time_t' ?
Verfasst: 30.08.2014 07:57
von Makke
Der zweite Link ist für 64bit Systeme der dritte für 32bit. Demnach ist es immer ein Long.
Re: Größe von 'time_t' ?
Verfasst: 30.08.2014 08:55
von NicTheQuick
Ich hab erst vor kurzem hier irgendwo einen Code veröffentlicht, wo ich diese Struktur im Kommentar genau aufgeschlüsselt. Ich habe nur leider keine Lust auf meinem Smartphone hier im Forum zu suchen. Sollte aber einer der neueren Beiträge sein. Jedenfalls ist es bei mir immer Quad gewesen, soweit ich mich erinnere.
Re: Größe von 'time_t' ?
Verfasst: 30.08.2014 13:03
von SBond
meinst du diesen?:
http://www.purebasic.fr/german/viewtopi ... 12#p325012
NicTheQuick hat geschrieben:
Code: Alles auswählen
;Linux only
Structure timeval
tv_sec.q ;__time_t -> __TIME_T_TYPE -> __SYSCALL_SLONG_TYPE -> __SQUAD_TYPE -> long int | __quad_t
tv_usec.q ;__suseconds_t -> __SUSECONDS_T_TYPE -> __SYSCALL_SLONG_TYPE -> __SQUAD_TYPE -> long int | __quad_t
EndStructure
Procedure.d seconds()
Protected tim.timeval
gettimeofday_(tim, #Null)
ProcedureReturn tim\tv_sec + tim\tv_usec / 1000000.
EndProcedure
Define today.d = seconds()
Define seconds.q = Round(today, #PB_Round_Down)
Define hours.q = seconds / 3600
Define minutes.q = seconds / 60 - 60 * hours
seconds % 60
hours % 24
Debug "Zeit: " + hours + ":" + minutes + ":" + today
Define time.d = seconds()
Delay(1000)
time = seconds() - time
Debug time
puh... ich hätte nicht gedacht, dass mir so eine kleine Struktur derartige Probleme bereitet. Wenn man mal in PB-Foren sucht, dann findet man diese Struktur mal mit integer und mal mit long. Ich wollte nur sichergehen, das die Struktur je nach Architektur sicher ist.
@Makke: Hatte mich bei den Links gewundert, dass oben in der Seite "Architecture: [ i386 ]" stand. Hätte ja eigentich auch ein long long erwartet, denn ein einfacher long verursacht das Jahr 2038-Problem. Eventuell denke ich auch einfach zu weit und die Lösung ist ganz einfach.
...notfalls mach ich einfach aus beidem ein Long, so wie es in der Seite steht. Ist keine wirklich schöne Lösung, aber naja ^^...
Code: Alles auswählen
[...]
CompilerCase #PB_OS_Linux
; Clock-IDs
#CLOCK_REALTIME = 0
#CLOCK_MONOTONIC = 1
#CLOCK_PROCESS_CPUTIME_ID = 2
#CLOCK_THREAD_CPUTIME_ID = 3
#CLOCK_MONOTONIC_RAW = 4
#CLOCK_REALTIME_COARSE = 5
#CLOCK_MONOTONIC_COARSE = 6
#CLOCK_BOOTTIME = 7
#CLOCK_REALTIME_ALARM = 8
#CLOCK_BOOTTIME_ALARM = 9
Structure timespec
tv_sec.l
tv_nsec.l
EndStructure
[...]
ich danke euch wieder für eure Hilfe.