Größe eines Datentyps dynamisch zur Laufzeit erkennen?
-
Ihr empfehlt mir aus Unwissenheit irgendwelche Alternativmethoden, die ich allerdings nicht brauche. Wenn ihr nichts sinnvolles zum Thema beitragen könnt, und keine Antwort auf die Frage wisst, dann lasst es doch einfach!
-
Gut, also wenn ich dich richtig verstehe, schreibt ein Programm von dir binäre Daten in eine Datei. Das Programm soll hinterher die Datei wieder korrekt auslesen können, ohne zu wissen, ob in der Datei nun ein int 4 oder 8 Byte groß ist.
So, du öffnest die Datei und siehst, sie ist 16 Bytes groß. Was sagt dir das? Nix, genau. Und deinem Programm kann diese Information auch nichts sagen, schließlich ist das die einzige die du hast.
Lösungen gibt es viele. Z.B. könntest du aufpassen, dass deine Datenstrukturen immer gleich groß sind, egal unter welchem System du kompilierst. Du musst nur einige "weite" Grenzen setzen, z.B. dass ein char immer 8 Bit groß ist. Ich weiß nicht, auf was für Systemen dein Programm laufen soll, aber an Desktop- und Serversystemen hast du dann über 99% der Fälle abgedeckt.Und wenn sowieso nur _dein_ Programm auf diese Datenbank zugreift bzw reinschreibt und du dein Programm nur für 32-Bit kompilierst, kann es sowieso keine Probleme geben. Und 64-Bit bringt dir bei vielen Anwendungen so gut wie keinen Vorteil.
Edit: Um es kurz zu fassen: Du bekommst nicht die Antwort, die du willst, weil es diese Antwort nicht gibt. Es ist unmöglich, ohne irgendwelche Information zu sagen, mit wie großen Datentypen das Programm gearbeitet hat, dass die Datenbank erzeugt hat.
-
Das Programm soll hinterher die Datei wieder korrekt auslesen können, ohne zu wissen, ob in der Datei nun ein int 4 oder 8 Byte groß ist.
Wenn du dir den Thread aufmerksam durchgelesen hättest, wüsstest du auch, dass ich ganz genau weis, wie groß ein Datentyp in der Datei ist. Stichwort Encoding.
So, du öffnest die Datei und siehst, sie ist 16 Bytes groß. Was sagt dir das? Nix, genau.
Siehe oben.
Lösungen gibt es viele. Z.B. könntest du aufpassen, dass deine Datenstrukturen immer gleich groß sind, egal unter welchem System du kompilierst. Du musst nur einige "weite" Grenzen setzen, z.B. dass ein char immer 8 Bit groß ist.
Deine vielen Ideen bringen nichts, wenn eine 32 Bit breite Datenbank auf einem 64 Bit System mit einem 32 Bit Programm eingelesen wird. Sobald ich nämlich dynamisch Speicherplatz für einen Integer anfordern möchte, unterscheiden sich die Größen des Datentypes im Heap und dem in der Datei. Fehler.
Und wenn sowieso nur _dein_ Programm auf diese Datenbank zugreift bzw reinschreibt und du dein Programm nur für 32-Bit kompilierst, kann es sowieso keine Probleme geben.
Meine Fresse.... Wenn es wirlich so wäre, hätte ich dann diesen Thread eröffnet?
Und 64-Bit bringt dir bei vielen Anwendungen so gut wie keinen Vorteil.
Also mal ehrlich, jetzt platzt mir der Kragen!! Das hat nichts mit Performance zu tun!
Es ist unmöglich, ohne irgendwelche Information zu sagen, mit wie großen Datentypen das Programm gearbeitet hat, dass die Datenbank erzeugt hat.
In der Datei kann drin stehen, auf welchem System sie generiert wurde.
Du bekommst nicht die Antwort, die du willst, weil es diese Antwort nicht gibt.
In deinem Kontext.
Zusammenfassen, ich will in etwa sowas:
dynamic_sizeof(int)Gibt es sowas?
-
CodeOriginator schrieb:
Ihr empfehlt mir aus Unwissenheit irgendwelche Alternativmethoden, die ich allerdings nicht brauche. Wenn ihr nichts sinnvolles zum Thema beitragen könnt, und keine Antwort auf die Frage wisst, dann lasst es doch einfach!
Haha, und du bezeichnest mich als streitsüchtig? Burner!
Falls du tatsächlich nicht einfach nur rumtrollst, solltest du so langsam mal raffen dass du entweder zu wenig Informationen dazu lieferst was du nun konkret machen willst (nicht was du meinst dass dein Problem ist). So wie es sich anhört willst du nicht die "Größe eines Datentyps dynamisch zur Laufzeit erkennen" (was verhältnismäßig trivial ist), sondern herausfinden in welchem Format deine Daten gespeichert sind. Entweder greifst du die Idee mit dem Encoding auf oder, falls auch das nicht möglich ist, versuchst einen Teil der Datei zu lesen und schaust nach ob die Werte plausibel sind.
-
CodeOriginator schrieb:
Badestrand schrieb:
Lösungen gibt es viele. Z.B. könntest du aufpassen, dass deine Datenstrukturen immer gleich groß sind, egal unter welchem System du kompilierst. Du musst nur einige "weite" Grenzen setzen, z.B. dass ein char immer 8 Bit groß ist.
Deine vielen Ideen bringen nichts, wenn eine 32 Bit breite Datenbank auf einem 64 Bit System mit einem 32 Bit Programm eingelesen wird. Sobald ich nämlich dynamisch Speicherplatz für einen Integer anfordern möchte, unterscheiden sich die Größen des Datentypes im Heap und dem in der Datei. Fehler.
Quatsch, mit "new int" bekommt der int die gleiche Größe wie mit "int a" - und selbst wenn nicht, der Compiler würde trotzdem die Größe seines "int"s nutzen.
Wieso denkst du eigentlich, ein 32-Bit-Programm würde sich auf einem 64-Bit-System anders verhalten? Das einzige, was anders ist, sind die aufgerufenen OS-Funktionen und die sind für den Fall echt egal.dynamic_sizeof(int) -> Wenn du so scharf drauf bist, dann frag doch einfach dein OS, ob's mit 64 oder 32 Bit arbeitet.
CodeOriginator schrieb:
Wenn du dir den Thread aufmerksam durchgelesen hättest, wüsstest du auch, dass ich ganz genau weis, wie groß ein Datentyp in der Datei ist. Stichwort Encoding.
Wenn du's weißt, wofür dann diesen Thread
-
Wie bereits erwähnt, ist das mit dem Encoding eine gute Idee, und durchaus auch eine Lösung. Folgendes Szenario:
Die Datenbank wird auf einem 32 Bit System generiert, und gleichzeitg mit einer Signatur versehen, die angibt, wie groß die Datentypen sind (Encoding).
Die Datenbank wird auf einem 64 Bit System von einem 32 Bit Programm eingelesen. Das Programm stellt fest, dass es sich um eine 32 Bit Datenbank handelt, und gibt das OK. Anschließend möchte es beim OS dynamisch Speicherplatz für einen Integer anfordern, um dann in diesen den Integer aus der Datei lesen zu können. Was das Programm aber nicht weis, ist, dass es in Wirklichkeit einen 64 Bit breiten Datentyp angefordert hat. Somit gibt es einen Fehler. Eventuelle Lösung wäre also, dynamisch zur Laufzeit erkennen zu können, wie groß ein Integer auf dem Hostsystem ist, um so gezielt darauf reagieren zu können. Was ist also die Lösung?
Wenn du's weißt, wofür dann diesen Thread
Oh Gott. Das habe ich im Laufe des Threads erfahren. Du liest dir den Thread nichtmal vollständig durch, und laberst dementsprechend völligen Mist!
-
Also Badestrand, wenn es wirklich so ist, dass dynamisch angeforderter Speicher auf einem 64 Bit System genauso groß wie auf einem 32 Bit System ist, dann hat sich das Problem schon erldigt!
-
nimm java
-
CodeOriginator schrieb:
Oh Gott. Das habe ich im Laufe des Threads erfahren. Du liest dir den Thread nichtmal vollständig durch, und laberst dementsprechend völligen Mist!
-
wie wärs wenn du auf einen datentyp zugreifst, der auf allen systemen 32 bit breit ist, wie z.b. (uint32_t oder so) oder ihn dir selbst baust? so wie ich das verstanden habe, soll dein system sowohl zu 64-bit also auch zu 32-bit prozessoren kompatibel sein. wenn du also beim kompilieren einen 64-bit prozessor hast (sizeof(int)==8) dann kriegst du auf den 32-bit systemen probleme... also bleibt dir nix anderes übrig als durchgehend 4-byte-ints zu verwenden.
-
CodeOriginator schrieb:
Die Datenbank wird auf einem 64 Bit System von einem 32 Bit Programm eingelesen.
Das Programm stellt fest, dass es sich um eine 32 Bit Datenbank handelt, und gibt das OK.
Anschließend möchte es beim OS dynamisch Speicherplatz für einen Integer anfordern, um dann in diesen den Integer aus der Datei lesen zu können.
Was das Programm aber nicht weis, ist, dass es in Wirklichkeit einen 64 Bit breiten Datentyp angefordert hat.
-
django schrieb:
also bleibt dir nix anderes übrig als durchgehend 4-byte-ints zu verwenden.
blöde logik... wollte eigentlich sagen, dass die größe des verwendeten datentyps gleich groß bleiben muss, ob das nun 64-bit (uint64_t) oder 32 bit (uint32_t) sind...
-
trau mich ja fast garnicht eine Idee zu posten, weil meine skills meilenweit unter denen des CodeOriginators sind .. Termin-Druck, ey?
ich würds so versuchen:
gesichert zwei gewünschte Typen nebeneinander im Speicher erzeugen und deren Adressen ermitteln, die Differenz besitimmen und glauben das wäre die tatsächliche Byte-Größe des Typs ... wenn ich mich geirrt habe bin ich jetzt wohl tot!
-
weil meine skills meilenweit unter denen des CodeOriginators sind
Social-Skills???
-
Ich habe bereits eine 32 Bit Integer-Klasse geschrieben. Eigentlich wollte ich es unkomplizierter durch eben dieses dynamische sizeof() lösen. Aber danke, dann werde ich wohl diese Alternative ergreifen müssen.
-
CodeOriginator schrieb:
Ich habe bereits eine 32 Bit Integer-Klasse geschrieben. Eigentlich wollte ich es unkomplizierter durch eben dieses dynamische sizeof() lösen. Aber danke, dann werde ich wohl diese Alternative ergreifen müssen.
ich glaube jeder andere gedanke, den du jemals hattest war komplizierter als
typedef uuint32_t { unsigned char value[4]; }uint32_t;
-
Im Gegenteil, sogar einfacher:
typedef unsigned char uint32[4];
-
lol
-
rofl, der thread ist der hammer.
ich nominiere codeoriginator für die wahl zum troll des jahres 2007!
-
Gibt's jetzt nen Keks?