Ressourcensparend nicht, aber so muss man sich jedesmal einen neuen pc/rechner anschaffen, wenn ein bit neu dazukommt, und auf den meisten pc's ist nun mal m$ beim kauf drauf...

Ok...stimmt...mit dynamischen variablen ist das so ne sache...64-bit = ewigkeit ist schon ok, aber vom theoretischen standpunkt aus, wenn du programmcodes auf ihre sicherheit hin überprüfst, hast du sozusagen nur wahre aussagen mit einer bestimmten einschränkung und nicht eine "immer" wahre aussage...oder nicht?

Sry über diese komischen fragen, aber sowas ist eig recht interessant für mich :)

~markus



Thomas Pircher <tehpeh@gmx.net> schrieb:
Markus Windegger wrote:
Wurden fie biosprogrammierer von m$ bezahlt?

Wieso? MS wird ja vieles nachgesagt, aber Sparsamkeit mit Resourcen ist
meines Erachtens nicht dabei... ;)

Also ich wäre ja für eine sich selbst vergrößernde variable...so eine
art
datumsvariablenliste...keine ahnung wie eigentlich geplant ist die
datumssache auf lange zeit zu lösen (sprich auf ewig). Wäre auch mal
interessant zu wissen!

http://en.wikipedia.org/wiki/Year_2038_problem#Solutions

Die verschiedenen Lösungsansätze sind:
- time_t als unsigned (32 bit) definieren. Gibt uns Zeit bis 2106 (und
dann: SEP).
- time_t als 64 bit definieren, gibt uns Zeit bis 2,147,483,647 + Start.
(Start kann 1970 sein, oder 1900 etc).
- oder eine ganz neue Funktion zu definieren und time(2) als obsolet
markieren.

"Sich selbst vergrößernde Variablen" sind im Datenaustausch sehr
praktisch, zum Beispiel DER, BER und PER
(http://en.wikipedia.org/wiki/X.690) aber als interne Variablen in einem
Programm sind sie nicht geeignet. Zum Beispiel kannst du mit solchen
Variablen nicht gut rechnen, und du weißt nicht im voraus, wie viel
Spiecher du allokieren musst, wenn du die Zeit vom OS ausliest. Da ist es
praktischer, eine Integer Variable zu verwenden, die "groß genug" ist.

Thomas


http://lists.lugbz.org/cgi-bin/mailman/listinfo/lugbz-list