[MacOSX] CLang und long |war: Compiler baut für 64bit, und

[Schrompf]

Moinzeit,

komische Dinge. Ich versuche aktuell, Splatter auf MacOSX zum Laufen zu bekommen. Und da scheitert neben vielen anderen Sachen auch das Cross Compiling für 32bit. Ich nutze QMake, aber das nur nebenbei. Die Kommandozeile, mit der eine .cpp-Datei am Ende kompiliert wird, sieht aktuell so aus:

Code: Alles auswählen

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -c -pipe -arch i386 -m32 -msse2 -static -g -fPIC -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -mmacosx-version-min=10.7 -std=c++11 -stdlib=libc++ -o ../../obj/dir/DatDatei.o DerDatei.cpp

Gekürzt um Include-Verzeichnisse und Warnung-Parameter. Deutlich zu sehen: "-arch i386" und mein Zweitversuch "-m32". Trotzdem kompiliert der anscheinend für 64bit, was ich daran zu erkennen glaube, dass der size_t in meinem Code ein 64bit-Integer ist.

Code: Alles auswählen

./Tile.h:95:29: error: invalid operands to binary expression ('SomeClass' and 'size_t' (aka 'unsigned long'))
  sgmt >> some_size_t;

Warum? Wie kriege ich den Compiler dazu, für eine 32bit-Architektur zu bauen?

[edit]Von dem entsprechenden >> Operator gibt es Overloads für int32_t und uint32_t, aber keine 64bit-Overloads. Daher meckert da der Compiler.

Danke.

Bye, Thomas

[Schrompf]

Absonderlich: Ich habe ihm jetzt spaßeshalber mal eine Überladung angeboten, die uint64_t nimmt. Und trotzdem meckert CLANG immernoch.

Code: Alles auswählen

./Tile.h:95:29: error: invalid operands to binary expression ('SomeClass' and 'size_t' (aka 'unsigned long'))
  sgmt >> some_size_t;
  ~~~~ ^  ~~~~~~~~~~~~~~~
note: candidate function not viable: no known conversion from 'size_t' (aka 'unsigned long') to 'int &' for 2nd 
note: candidate function not viable: no known conversion from 'size_t' (aka 'unsigned long') to 'unsigned int &' for 2nd argument
note: candidate function not viable: no known conversion from 'size_t' (aka 'unsigned long') to 'uint64_t &' (aka 'unsigned long long &') for 2nd argument

Einer von den dreien MUSS doch viable sein, oder?

[kimmi]

Unter gcc musst du die entsprechende Toolchain installieren und benutzen. Dann benutzt der werte Compiler für die gewählte Architektur mit 32 bit besagte Toolchain. Ich vermute, dass man ähnliches für clang machen muß.

Gruß Kimmi

[Punika]

Hi
hast du es mal mit der option: -march=x86 versucht?
Sonst würde ich noch sagen das bei clang es nicht -arch i386 sondern -arch x86 heißten könnte.

Zudem glaube ich sollte man eher -target anstatt -arch verwenden.

Grüße

[Spiele Programmierer]

@kimmi
Clang ist von Natur aus ein Cross Compiler, also nein.
Theoretisch sollte es also viel einfacher sein, als mit GCC.

[kimmi]

Gut zu wissen, hab noch nichts mit clanc cross-compiliert :).

Kimmi

[Schrompf]

Die Exe ist 32bit. Es stellt sich heraus, das Cross-Compilen ist gar kein Problem. size_t ist das Problem.

Code: Alles auswählen

sizeof( size_t) // 4
std::is_unsigned<size_t>::value // true

Der size_t ist also ein banaler 32bit-Integer. Außer dass er hier halt als unsigned long definiert ist. Und anscheinend ist für CLang ein unsigned long eben nicht das selbe wie ein unsigned int. Sowas hier jedenfalls geht nicht:

Code: Alles auswählen

void MachFuenf( unsigned int& v) { v = 5; }
size_t t;
MachFuenf( t);

CLang sagt dazu:

Code: Alles auswählen

Anwendung.cpp:24:3: error: no matching function for call to 'MachFuenf'
  MachFuenf( t);
  ^~~~~~~~~
Anwendung.cpp:12:6: note: candidate function not viable: no known conversion from 'size_t' (aka 'unsigned long') to 'unsigned int &' for 1st argument
void MachFuenf( unsigned int& v) { v = 5; }
     ^

Trotz dass er drei Zeilen höher behauptet, size_t wäre ein unsigned 32bit-Integer. Was Zur Hecke passiert hier? Irgendwer schonmal CLang benutzt und auf dieses Phänomen gestoßen? Ich habe das Problem jetzt gelöst, indem ich ihm jeweils einen zusätzlichen Overload für unsigned long gegeben habe, aber jetzt scheitert das natürlich und völlig zu Recht auf jedem anderen Compiler, da es ja schon einen Overload für vorzeichenlose 32bit-Integer gibt. So ein verdammter Dreck.

Außerdem bekomme ich einen wirren Crash in __dynamic_cast, wobei der Quell-Zeiger laut Debugger völlig in Ordnung ist. Und alle beteiligten Klassen stecken in statisch gelinkten und frisch mitkompilierten Quellen. Damit scheiden alle Tipps aus, die das Internet so zu bieten hat. Verdammter Dreck.

[Spiele Programmierer]

Das ist in der Tat sehr ärgerlich und einer der Gründe, warum ich die eingebauten Typen in C abgrundtief verachte und eigentlich überall vermeide, auch wenn es mehr Tippaufwand mit sich bringt.
Nichtsdestotrotz sollte das für dich wirklich keine Neuheit sein. Das ist sogar in Microsofts Compiler exakt genauso.
"long" ist 32 Bit(Danke MSDOS Kompatiblität!) und inkompatible zu "int"(obwohl auch 32 Bit).

Bist du sicher, dass du "dynamic_cast" wirklich brauchst? Ich habe ehrlich gesagt noch nie einen Fall gehabt, in dem das notwendig gewesen wäre. Und das obwohl ich Mehrfachvererbung manchmal schon verwende. Ich habe aber Programmierer schon häufig irrtümlicherweise "dynamic_cast" verwenden sehen, wenn es "static_cast" auch wunderbar getan hätte.

[Schrompf]

Das ist in der Tat sehr ärgerlich und einer der Gründe, warum ich die eingebauten Typen in C abgrundtief verachte und eigentlich überall vermeide, auch wenn es mehr Tippaufwand mit sich bringt.
Nichtsdestotrotz sollte das für dich wirklich keine Neuheit sein. Das ist sogar in Microsofts Compiler exakt genauso.
"long" ist 32 Bit(Danke MSDOS Kompatiblität!) und inkompatible zu "int"(obwohl auch 32 Bit).

Nein, sowohl GCC als auch VC haben kein Problem mit dem obigen Code. [edit] Ne, halt, ich glaube, Du meinst, dass size_t dort per int/longlong definiert ist und ich daher diese Probleme jetzt erst habe.

Visual Studio: LP-Speichermodelldingens, also long immer 32bit, aber size_t ist als uint/ulonglong definiert.
GCC/Linux: LLP-Speichermodelldingens, also long 32 oder 64bit, aber size_t ist also uint/ulonglong definiert.
CLang/OSX: LLP-Speichermodelldingens, also long 32 oder 64bit, und size_t als ulong definiert.

Wie krieg ich die drei jetzt unter einen Hut. Wahrscheinlich nur mit ordentlicher Konsequenz beim Schreiben/Lesen von Binärspielständen. Trotzdem - Mistgriebel.

Bist du sicher, dass du "dynamic_cast" wirklich brauchst? Ich habe ehrlich gesagt noch nie einen Fall gehabt, in dem das notwendig gewesen wäre. Und das obwohl ich Mehrfachvererbung manchmal schon verwende. Ich habe aber Programmierer schon häufig irrtümlicherweise "dynamic_cast" verwenden sehen, wenn es "static_cast" auch wunderbar getan hätte.

Naja, sicher kann man das alles am Ende irgendwie auf ne normale Ableitung umbiegen. Ich seh aber auch, dass jede einzelne Anmeldung einer Klassenmethode beim Skriptinterpreter schiefgeht. Ich habe ein grundsätzliches Problem mit der C++-Runtime. Nur keine Ahnung von OSX, um es zu lösen.

[Spiele Programmierer]

Achso, du hast dich also nicht darüber aufgeregt, dass der Compiler "unsigned int" und "unsigned long" als unterschiedliche Typen behandelt, obwohl es letzendlich der Gleiche bei deiner Konfiguration ist, sondern darüber, dass "size_t" unterschiedlich definiert ist? Ich würde dir empfehlen konsequent die Typen fester Breite wie "uint64_t" beim Schreiben und Lesen zu verwenden und explizit anzugeben.

"dynamic_cast" brauchst du nicht unbedingt bloß weil du (ggf. sogar virtuelle) Mehrfachvererbung hast. Du kannst auch bei gewöhnlicher Mehrfachvererbung einen "static_cast" einsetzen. Der einzige wichtige Unterschied ist, dass es bei der Konvertierung keine C++ Exception gibt, falls sie fehlschlägt.

[Schrompf]

Wut? Du bist da auf nem völlig falschen Pfad. dynamic_cast wirft *nie* eine Exception, sondern er gibt NULL zurück, falls die Konvertierung unzulässig ist. Und er sollte definitiv nicht crashen, wenn der Pointer gültig ist. Können wir jetzt also die Diskussion um Sinn oder Unsinn sein lassen und am eigentlichen Problem arbeiten?

Und ich brauche size_t. Schon allein, weil es von der kompletten Standardlib benutzt wird. Ich *will* einen Typ, der 32bit auf 32bit-Architekturen und 64bit auf 64bit-Archs ist. Es war nur ne dumme Idee, size_t für Bitmuster-Basteleien zu benutzen oder die per Stream-Operatoren in Binärdateien zu schreiben. Das war damals ein bisschen Faulheit und ein bisschen unklare Formulierung. Ok. Aber es sollte trotzdem gehen. Und dieses Rumgeeier um int, long, longlong geht mir doch massiv auf die Nerven. Auch weil man bei Operatoren nicht sinnvoll casten kann.

Code: Alles auswählen

size_t x;
stream >> x;

Wie schreibe ich nun, dass der Trottel das Ding als uint32_t liest. Hm? Casten darfst Du ja nicht, weil's ja ein LValue sein muss. Man müsste dann den Operator-Aufruf manuell ausschreiben, was nun der ultimative Hass ist. So ein Elend. Gleichzeitig sind das nun aber im Spiel alles Array-Indizes gewesen, also war size_t dafür exakt der richtige Typ. Egal wie man's dreht - das ist einfach so richtig kacke.

[edit] Bei Splatter werd ich wohl alles auf uint32_t umstellen. Von dem Spiel wird's eh keine 64Bit-Variante geben, damit isses dann wurscht.

[Jonathan]

Naja, du könntest eine temporäre Variable vom passenden Typen verwenden und dann hinterher zuweisen.
Das ganze könntest du auch kapseln, indem du eine Klasse schreibst, deren Konstruktor eine Referenz auf den Zieltyp entgegen nimmt und die die >> Operator überladen hat, der dann den Wert in eine temporäre Variable schreibt und anschließend der Referenz zuweist. Müsste man in 15 Zeilen hinkriegen und würde ab dann im Code nicht hässlicher sein, als ein cast.

[Punika]

Schrompf, eine kleine Fragen. Wieso gibt es keine 64bit Version wenn du alles auf uint32_t umstellst? Also aus meiner Erfahrung kommt man mit dem size_t problem zurecht. Ich benutze size_t in der Regel nur beim sizeof operator. Ich muss dazu sagen das ich selber noch mal meine typen deklariert habe aber immer nach dem Prinzip gearbeitet habe "wie groß kann dieser Wert werden". Und man braucht wirklich sehr selten 64bit werte.

Ich denke das wenn du erstmal alle size_t umwandelst in entweder ein uint32_t oder uint64_t je nach Bedarf sollten 99% der Probleme gelöst sein. ich komme jedenfalls sehr gut damit aus, es eliminiert auch direkt eine hohe Anzahl von Problemen mit dem Speichermodell.

[Schrompf]

Das war unglücklich ausgedrückt von mir. Ich habe dem Ding zusätzliche Operator Overloads für unsigned long gegeben, die 32bit schreiben bzw. lesen. Das geht an einer nicht-ganz-zentralen Stelle, so dass jetzt die ganze Spielstandmagie wieder funktioniert. Bzw. funktionieren sollte, weil ich ja soweit nicht komme. Das geht so natürlich, weil ich praktisch betrachtet nie mehr als 32bit Array-Indizes oder mehr als 32bit-Speicherblock-Größen haben werde. Theoretisch wär das aber ne fiese Falle für die Zukunft einer 64bit-Version, was man halt im Hinterkopf behalten sollte. Das Framework wird ja auch vom nächsten Projekt schon verwendet, und das wird wohl nur 64bit. Also muss ich das Problem lösen, ohne an zentraler Stelle Größen auf 32bit einzugrenzen, die auch 64bit groß werden könnten.

Praktisch kotzt mich das Ganze aber trotzdem noch an. Ich habe für die Texturgrößenberechnung z.B. "Bestimme höchstes gesetztes Bit einer Zahl", einmal für uint32_t, einmal für uint64_t. Wär ja schon, wenn der Trottelcompiler einfach die passende Überladung wählen würde, wenn ich ihm ein size_t PixelBreite gebe. Tut er aber nicht. Stattdessen ist es ein ambibuous call, weil's ein long ist, der zwar 32bit unsigned ist, aber NIE NIE NIE das gleiche wie ein uint32_t. Es ist zum Kotzen. Man merkt hier halt einfach, dass C/C++ ein riesiger Haufen Altlasten ist.

Mein wirklich akutes Problem ist: warum crasht dynamic_cast trotz validem Zeiger? Liegt wahrscheinlich an -stdlib=libc++, aber ohne das kriege ich Millionen Linkerfehler bei so banalen Sachen wie std::string.

[Spiele Programmierer]

Ich war jetzt selbst kurz verunsichert, weil ich dynamic_cast wie erwähnt, schon seit Ewigkeiten nicht mehr gebraucht habe.
Allerdings steht hier ganz klar: "Returns a value of type new_type or throws an exception."
Wenn du also "dynamic_cast" tatsächlich deswegen brauchst, weil du dir nicht sicher sein kannst, dass das Basisklassen Objekt tatsächlich überhaupt von dem gesuchten Typen ist, würde ich lieber bei static_cast bleiben und Prüfung vorher durchführen. Zum Beispiel über einen Idenitfier in der Basisklasse.

Ich benutzt auch gerne "size_t", allerdings sollte man den offensichtlicherweise nie in eine Datei schreiben. Das würde unerwünschterweise ja auch zu inkompatiblen Speicherständen zwischen 32 Bit und 64 Bit führen. Ich würde zum Lesen/Schreiben von Binärstreams ähnlich folgenden Syntax empfehlen:

Code: Alles auswählen

size_t x = stream.Read<std::uint32_t>();

Das ist nicht viel länger, missbraucht keine Operatorüberladung, bietet Platz zum Übergeben weiterer Parameter bei komplexeren Typen und vermeidet das sonst sehr leicht auftretende Problem, dass man mal einen architekturabhänigen Typen in eine Datei schreibt. Und implizite Konvertierung gibt es auch noch.

[Krishty]

Nein. dynamic_cast wirft NUR, falls man es mit Referenzen nutzt, weil es ja dann keine andere Möglichkeit gibt, einen Fehler mitzuteilen. Auf Zeigern gibt es nullptr zurück. Das steht auch explizit so in deinem Link oben:

Otherwise, the runtime check fails. If the dynamic_cast is used on pointers, the null pointer value of type new_type is returned. If it was used on references, the exception std::bad_cast is thrown.

Das ist sogar explizit für Schrompfs Fall so gemacht worden!

[Schrompf]

[edit]Noch vor Krishty getippt, bezieht sich auf Spieleprogrammierer[/edit] Guter Hinweis, aber stimmt nicht. Also: nicht ganz :-) Weiter unten steht da:

If the dynamic_cast is used on pointers, the null pointer value of type new_type is returned. If it was used on references, the exception std::bad_cast is thrown

Wir haben also beide recht, aber mein Fall ist ein Zeiger und damit krieg ich keine Exception, sondern nullptr zurück.

Und was das size_t-Schreiben angeht: ja, das schrieb ich ja schon, das war eine Faulheitslösung von mir. Dein Vorschlag des expliziten Lesens und Schreibens war meine erste Lösung, aber nach all den Jahren des manuellen Serialisierens war das meine zweite Stufe, die mir zumindest einiges an Tipparbeit erspart hat. Hat halt aber auch seine Nachteile, wie ich jetzt festgestellt habe.

Nuja, das Problem ruht jetzt erstmal, weil ich den Mac wieder an seinen Besitzer zurückgeben musste. In zwei Wochen oder so geht's weiter. Eigenes Geld für eigene Hardware ausgeben werde ich sicher nicht - das ist Prinzipsache.

[Schrompf]

Hab den Mac wieder, und den Crash in dynamic_cast quasi sofort gefunden. Abschließender Bericht also:

1) 32 vs. 64 bit - war mein Fehler. long ist auf jedem Compiler ein anderer Typ als int oder longlong, also kann ich dafür auch einen Overload anbieten, der klar zugeordnet werden kann.
2) size_t als long anstatt int/longlong - Immernoch zum Kotzen, weil damit einige Funktionen, die ich sowohl als 32bit als auch als 64bit da habe, ambiguous overloads sind.
3) Der Crash in dynamic_cast - mein Fehler. Ich hatte durch das Umbenennen einer Funktion in einem DoubleDispatch-Pattern, um eine Warnung zu beseitigen, aus Versehen eine Endlosrekursion ausgelöst. Unter OSX war der dynamic_cast halt vier oder fünf Aufrufe tief, so dass der einfach der erste Punkt im Code war, bei dem der Stack überlief. Einmal den Stacktrace um die nächsten zehn Einträge erweitert und das Problem wurde offensichtlich.

Jetzt läuft Splatter auch auf Mac, nur ein bisschen Input-Behandlung fehlt noch. Da bringt OSX allerdings eine erstaunlich freundliche API mit, so dass ich mir Hoffnung mache, in den nächsten Tagen alles zum Laufen zu bekommen. Hat irgendwer einen spieletauglichen Mac und kann mir Testen helfen?

[Punika]

Hey

ich könnte mit nem MacBook 15 retina, 2011 war das glaub ich. Nvidia GT950M und 16Gig RAM.

[Schrompf]

Cool, Danke für das Angebot! Ich melde mich per PN bei Dir in den nächsten Tagen.

[RustySpoon]

Kann dir 'nen 13" Mac 2011 Early anbieten. Core-i5, 8GB RAM und Intel HD3000.

[Schrompf]

Danke nochmal! Habe euch gerade jeweils eine Mail geschickt.

[Dummie]

Ich könnte ab Ende der nächsten Woche auf einem brandaktuellen Mac Book Air testen. Sprich aus 2015 mit Intel i7, 8 GB RAM und Intel HD 6000 GPU.

Ist natürlich kein reinrassiges Spielesystem und für den Preis auch eigentlich ein Witz. Hatte aber selber Bedarf und das schien mir die beste Lösung. :D

[Schrompf]

Danke für das Angebot! Ich hätte durchaus gern eine IntelGPU im Testprogramm, aber eigentlich wollte ich bis Ende letzter Woche veröffentlicht haben. Ich wollte unbedingt vor dem Steam Summer Sale rauskommen.

[Dummie]

RustySpoon hat ja auch eine Intel GPU :) Insgesamt ist die Variation bei Apple ja nicht ganz so groß wie bei einem Windows System :)