 |
Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 563
Wohnort: Jüterbog
|
 Verfasst am: 08.08.2015, 14:31 Titel: ein kleines 64bit Problem |
 |
|
da ich nun die 64Bit Version des FBC benutzen kann und will habe ich beim neukompilieren meiner Projekte doch diverse Fehlermeldungen bzw auch Abstürze ohne Meldungen fabriziert. Etwas demotivierend aber naja...
<32> habe ich schon entdeckt und erfolgreich eingebaut 
nächstes Problem hier:
eine kleine Casting Geschichte, der String ist im Original ein Funktionsergebnis und das Zielformat ist auch ein anderes, aber der Fehler ist der gleiche:
| Code: | print cast(integer ptr, valint ("12345"))'nur 32bit kompatibel
print cast(integer ptr, vallng ("12345"))'nur 64bit kompatibel |
geht das auch mit nem Einzeiler ohne Fehlermeldung? Oder muß ich das über ein Metakonstrukt lösen
| Code: | #ifdef __FB_64BIT__
print cast(integer ptr, vallng ("12345"))'nur 64bit kompatibel
#else
print cast(integer ptr, valint ("12345"))'nur 32bit kompatibel
#endif |
Mutton |
|
| Nach oben |
|
 |
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 08.08.2015, 16:37 Titel: |
|
|
Ich würde ja sagen, wenn du Strings in Pointer umwandeln musst, ist dein Programm kaputt.
Ohne es getestet zu haben, warum funktioniert vallng nicht bei 32-bit? Wenn du das wirklich tun musst, würde ich den Cast in eine Funktion packen, das würde auch jede Menge Redundanz entfernen bei den Casts, sodass du dieses ifdef nur an einer Stelle verwenden müsstest.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
| Nach oben |
|
|
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 563
Wohnort: Jüterbog
|
| Verfasst am: 08.08.2015, 17:02 Titel: |
|
|
Warum das so ist, keine Ahnung. Jeweils die eine oder andere zeile erzeugt mit aktuellem beim jeweiligen compiler ein fehlermeldung.
Ich geb zu pointer in nen string zu speichern...war die einfachste Lösung zum speichern einer kleinen pointerliste... Das könnte ich generell ändern. |
|
| Nach oben |
|
|
St_W
Anmeldungsdatum: 22.07.2007
Beiträge: 949
Wohnort: Austria
|
| Verfasst am: 09.08.2015, 01:21 Titel: |
|
|
Ich kann mir nicht vorstellen dass Pointer als dezimalzahl in einem String zu speichern eine "einfache Lösung" sein kann, aber zum Problem:
ValInt gibt einen Long-Wert (32-bit) zurück, ValLng einen LongInt (64-bit) (die Funktionsbezeichnung ist da etwas verwirrend - musste in der Doku nachschaun) - was du brauchst ist aber ein Integer Typ (der je nach Architektur immer so groß ist wie ein Pointer). Da es soweit ich gesehen hab keine VAL-Funktion gibt, die einen Integer-Typ zurückgibt kannst du dir z.B. mit einem weiteren cast helfen:
| Code: | | print cast(integer ptr, cast(Integer, vallng ("12345"))) |
Es wird also der String in einen 64-Bit Wert konvertiert, dieser in einen Integer konvertiert (ggf. 32 bit) und dieser dann als Pointer verwendet. Ist zwar nicht schön, sollte aber funktionieren. Und, ehrlich gesagt, wenn man Pointer in einem String speichert dann macht noch ein wenig mehr hässlicher Code auch keinen Unterschied mehr.
_________________
Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken) |
|
| Nach oben |
|
|
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 09.08.2015, 12:26 Titel: |
|
|
Warum ValInt einen Long zurückliefert, ist mir ein Rätsel. Die rtlib liefert einen int zurück, erst der Compiler definiert die Rückgabe dann als Long. Das wurde im Zug der 64bit Umstellung gemacht (ich meine auch irgendwo mal eine Diskussion zu dem Thema gesehen zu haben).
Dass ValLng einen LongInt und keinen Long zurückliefert, ist seltsamerweise schon seit langem so (die Funktion hieß auch mal Val64, was mehr Sinn macht), allerdings hat ValInt bis vor kurzem noch einen Integer zurückgeliefert.
Interessant finde ich das Verhalten der aktuellen 1.03 Version trotzdem:
| Code: | | Print Cast(Integer Ptr, ValInt("12345")) |
Dieser Code funktioniert in der 32bit Variante problemlos, beschwert sich in der 64bit Variante aber nicht über falsche Datentypen (Integer vs. Long), sondern darüber, dass er einen Ptr möchte. Die Auto-Casting-Magie greift wohl hier nicht.
Ich habe noch diese Version als funktionsfähig gefunden (hat aber den Nachteil einer Ptr Variable, die man theoretisch wieder aufräumen muss):
| Code: | | Print Cast(Integer Ptr, *New Integer (ValInt("12345"))) |
|
|
| Nach oben |
|
|
St_W
Anmeldungsdatum: 22.07.2007
Beiträge: 949
Wohnort: Austria
|
| Verfasst am: 10.08.2015, 05:19 Titel: |
|
|
Zu deinen Beispielen: Es ist schon Richtig dass sich fbc über einen falschen Datentyp beschwert (der kein Pointer ist) und auch nicht automatisch konvertiert, wie wenn es ein "normaler" Zahlenwert wäre. Denn einen 32bit Wert in einen 64bit Wert zu konvertieren ist bei Pointern auf einem 64bit System schlicht falsch. Unter demselben Problem leidet übrigens auch dein zweites Beispiel.
_________________
Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken) |
|
| Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
