Größe eines Datentyps dynamisch zur Laufzeit erkennen?
-
Man könnte fast meinen das ist ein Trollthread.
-
Die information wie groß die typen auf dem system sind auf dem das programm läuft, bekommst du eigentlich wirklich zur compilezeit, denn du musst das programm ja für 64bit neu compilieren, und dann funktioniert sizeof.
Okay, das ist ein Argument, ich muss dir Recht geben. Aber darf ich meine Frage nochmal stellen? Ich will zur Laufzet feststellen können, wie groß ein Datentyp ist. Wie mache ich das? Und bitte klammert euch nicht an irgendwelchen anderen Tatsachen fest, sondern beantwortet mir doch endlich meine Frage. Danke.
-
Du müsstest halt in der ersten Bytes der Datei das Encoding festlegen.
Oder du speicherst einfach nicht binär, sondern z.B. als XML ab.
-
Ich muss mir widersprechen. Es ist nicht zwingend notwenidg, ein auf einem 32 Bit System kompiliertes Programm neuzukompilieren, wenn es auf einem 64 Bit Sys laufen soll.
Du müsstest halt in der ersten Bytes der Datei das Encoding festlegen.
Das ist eine Idee. Bringt mir aber auch nichts, wenn das Programm nicht neukompiliert wird. Gibt es denn aber sonst keine alternative STL Methode, die mir die Größe zurückliefert? std::numeric_limits ist aber statisch, oder?
Oder du speicherst einfach nicht binär, sondern z.B. als XML ab.
geht nicht.
-
Wird ein 32-bit Programm auf einer 64-bit Maschine ausgeführt haben die Datentypen diesselbe Größe, wie auf einem 32-bit System. Schließlich sind ja auch auf einem 32-bit Windows die Integer in einem DOS-Programm 16-bit groß. Das wird einfach emuliert, oder irgendwie anders gelöst.
Wenn du dein Programm also in 32-bit kompilerst, sollte es auch die Datei korrekt lesen können, oder irre ich mich da?
In C++ gibt es aber soweit ich weiß kein Mittel zur Laufzeit die Größe eines Datentyps herauszufinden schließlich existieren zur Ausführung eh nur noch Nullen und Einsen. Eine Binäre-Datei besteht auch nur aus Bits; die Interpretation liegt bei dem Anwender. Du könntest ja immer nur einzelne Bytes einlesen und dir dann den Integer zusammenschiften, einfacher wäre aber - wie schon erwähnt - einfach nicht binär, sondern text-basiert zu arbeiten.Gruß
Don06
-
Wird ein 32-bit Programm auf einer 64-bit Maschine ausgeführt haben die Datentypen diesselbe Größe, wie auf einem 32-bit System. Schließlich sind ja auch auf einem 32-bit Windows die Integer in einem DOS-Programm 16-bit groß.
Nicht wenn man sie dynamisch anfordert. Und was ist, wenn ein auf 'nem 64 Bit System kompiliertes Programm eine auf einem 32 Bit System generierte Datenbank einliest? Crash.
Das wird einfach emuliert, oder irgendwie anders gelöst.
Das Schlagwort: "irgendwie". Und das "irgendwie anders lösen" muss schon der Programmierer. In dem Fall ich.
Wenn du dein Programm also in 32-bit kompilerst, sollte es auch die Datei korrekt lesen können, oder irre ich mich da?
Du irrst dich. Siehe oben.
In C++ gibt es aber soweit ich weiß kein Mittel zur Laufzeit die Größe eines Datentyps herauszufinden schließlich existieren zur Ausführung eh nur noch Nullen und Einsen.
Soweit du weist, ja... Muss aber nicht so sein, deshalb habe ich diesen Thread hier eröffnet.
Eine Binäre-Datei besteht auch nur aus Bits; die Interpretation liegt bei dem Anwender.
Gut erkannt, die Interpretation liegt beim Anwender.
Du könntest ja immer nur einzelne Bytes einlesen und dir dann den Integer zusammenschiften,
Tatsache! Aber dazu muss man wissen, wie groß der Datentyp auf dem Hostsystem ist!
einfacher wäre aber - wie schon erwähnt - einfach nicht binär, sondern text-basiert zu arbeiten.
Unter Berücksichtigung dieser Tatsache vielleicht schon. Man kann aber nicht alle Daten einfach textbasiert in die Datei speichert, schließlich handelt es sich mit den Datentypen nur um ein Beispiel. Es gibt auch komplexe binäre Strukturen, die man eben nicht als Text abspeichern kann. Und genau da scheitert die Idee mit dem XML Script.
-
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???