Ich würde gerne einmal wissen, was die kritische Datumsgrenze in C++ ist; 2039 oder 2047 oder??? Danke Holger
42 Was erwartest Du als Antwort? Erstens, völlig falsches Forum. Zwar kann auch ein avr-gcc C++, aber ich sehe in Deiner Frage trotzdem keinen Bezug zu AVR. Zweitens, Programmiersprachen kennen kein Datum. Nur Betriebssysteme kennen eins. Du mußt also das Betriebssystem Deiner Wahl fragen, wie es intern mit dem Datum umgeht.
@Joerg Wunsch: Falsche Antwort. Programmiersprachen können sehr wohl das Datum kennen. Wenngleich sie dafür natürlich oftmals auf BS-Routinen zurückgreifen.
@Jochen, Falsche Antwort. Du sagst ja selbst: "Wenngleich sie dafür natürlich oftmals auf BS-Routinen zurückgreifen." Also liegt der Schwarze Peter doch beim BS und nicht beim Compiler. Peter
@Peter: Falsche Antwort. Wie man ja am Jahr-2000-Problem gesehen hat, liegt der schwarze Peter eben doch an der Programmiersprache oder beim Compiler. So haben beispielsweise einige Cobol-Compiler die Jahreszahl nur zweistellig zurückgegeben, obwohl das BS vierstellig lieferte. Andere Effekte bei anderen Sprachen gibt es ebenso. Die Sprachen reichen nämlich meistens nicht die vom BS angelieferten Werte einfach so durch.
@Alle: Falsche Antwort. C und C++ kennen gar keinen Datentypen 'Datum oder so'. Die bekannten Funktionen sind jeweils in Compilerspezifischen Libraries hinterlegt (z.b: time). Diese Libraries greifen immer (!) auf Betriebssytemfunktionen zu um die aktuelle Uhrzeit abzufragen. Also ist die Datumsgrenze ganz klar BS-abhängig. Wenn ein Compiler dann diese Grenzen noch weiter einschränkt ist dies natürlich ärgerlich. Der grösste Teil der 2000-er Probleme lag allerdings an den jeweiligen Applikationsprogrammen, welche die entsprechenden Jahrzahlen tatsächlich nur 2-stellig abgespeichert haben um Platz zu sparen. Gruss Christian
auf jeden fall wäre die einschränkun immer compilerspezifisch. C++ als sprache ansich hat keine limits... alle compiler-implementationen haben datumsgrenzen, zusätzlich noch alle betriebssysteme... (wenn diese grenze auch oft weit weit in der kuhzunft liegt)
Das nächste Problem wird es wohl im Jahr 2037 geben, wenn die Programme die über Funktion time() und speziell über time_t als Datentyp die Zeit des Betriebsystem ermitteln. Hintergrund: time liefert die Anzahl der Sekunden seit den 1.1.1970 in Form einer unsigned long (also auf x86 System mit 4 Bytes ) welche IMHO im April 2037 bei 2^32 überläuft.
Naja, fast. Es ist 2038: % date -r 0x7fffffff Tue Jan 19 04:14:07 MET 2038 % date -r 0x80000000 Fri Dec 13 21:45:52 MET 1901 Woran Du auch siehst, das es noch mehr ,,fast'' ist: der Datentyp ist nicht unsigned, sondern signed. Sonst wäre der rollover noch viel später, dafür werden so auch Zeiten vor der ,,Unix Epoche'' bis zurück 1901 erfaßt. Aber das Ganze stimmt natürlich nur für 32-bit Unix-artige Betriebssysteme. Inwiefern davon außer Museumsstücken in 35 Jahren noch etwas betroffen sein wird, ist natürlich zweifelhaft. (Unix ist mittlerweile selbst gerade mal reichlich 30 Jahre alt.) Aber um auf den Ausgangspunkt zurückzukommen: eine Programmiersprache, sei es C oder C++, ist davon nicht zwangsweise betroffen. Die einzigen C-Funktionen, die sich mit der Uhrzeit befassen, sind abstrakt genug, als daß sie praktisch jedes Datum darstellen können. (Daß man vom Jahr 1900 subtrahieren muß ist zwar ein Lapsus, der auf eine zu kurzsichtige Definition aus der Anfangszeit zurückzuführen ist, die spä?er einfach per definitionem durch Einführung des Offset 1900 korrigiert worden ist. Das hat uns ein Gutteil der Y2K-Probleme in C-Programmen beschert, aber den Wertebereich wirklich nennenswert beschränken tut der Offset auch nicht.) Der time_t ist für den Anwender ein undurchsichtiger Datentyp. Im Prinzip kann eine Implementierung ihn sogar als Struktur aus mehr als einem Wert darstellen, da der C-Standard ja die Möglichkeit, eine Struktur aus einer Funktion zurückzugeben, definiert (im Gegensatz zum ursprünglichen K&R Standard, der das nicht konnte). Sagt also niemand, daß ein time_t ein skalarer Typ sein muß, erst recht nicht, daß es ein Integertyp einer bestimmten Länge sein muß. Mit x86 liegst Du übrigens auch nicht richtig: ein gcc auf IA32 kann locker auch mit 64-Bit Integern umgehen. Also wäre selbst dort ein 64-bit int time_t möglich... Der off_t (Offset innerhalb einer Datei für Betriebssystemrufe) ist auf einigen IA32-Unixen schon seit einem Jahrzehnt ein 64-bit Typ, d. h. sie können mit Dateien größer 4 GB umgehen.
time_t als struktur? in meiner C-Referenz steht: struct tm *localtime(const time_t t); oder z.B. time_t mktime(struct tm t); also bei time_t ist struct nicht explizit angegeben, bei tm schon... gibts wahrscheinlich ne einfache erklärung für...? :-)
Nun, daß kein struct explizit davor steht heißt ja nicht, daß es keine sein muß. time_t ist eben einfach ``opaque'' für die Applikation, was sich genau dahinter verbirgt, muß die Applikation nicht interessieren. Es gibt eine Funktion, die ein Resultat vom Typ time_t zurückgibt (time()), und diesen Wert kann man an andere Funktionen (localtime, difftime) weitergeben. Was sich in ihm exakt verbirgt, ist ``implementation defined''. Habe nochmal den Standard nachgelesen: The types declared are ... clock_t and time_t which are arithmetic types capable of representing times; and struct tm which holds the components of a calendar time, called the broken-down time. Hmm, demnach muß es doch ein skalarer Typ sein. Eigentlich unverständlich, da eben selbst Operationen wie die Differenz via difftime() geregelt sind.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.