mikrocontroller.net

Forum: Compiler & IDEs kritische Datumsgrenze C++


Autor: Holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde gerne einmal wissen, was die kritische  Datumsgrenze in C++ 
ist; 2039 oder 2047 oder???
Danke Holger

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Joerg Wunsch:
Falsche Antwort. Programmiersprachen können sehr wohl das Datum kennen.
Wenngleich sie dafür natürlich oftmals auf BS-Routinen zurückgreifen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Christian Schifferle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jonas Diemer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jonas Diemer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...? :-)

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.