Hallo
Viele Libarys funktionieren ja nur für bestimmte Compiler....
Manche nur für Visual Studio manche nur für Cygwin manche nur für Mingw und manche funktionieren teilweise :/ Deshalb entstehen oft Probleme wenn ich mehrer Libaries benutzen will.
Gibt es eine Möglichkeit die Libaries neu zu bauen für den Compiler? Leute mit eigenem Compiler müssen dass doch auch hinkriegen, oder?
Vielleicht auch einfach nur Stichworte geben dass ich selber recherchieren kann, stehe bloß etwas auf dem Schlauch.
Um welche Libraries geht es? Generell sind eigentlich alle Libraries compilerübergreifend kompatibel. Wäre ja auch bescheuert, wenn man für jeden Compiler anderen Code schrieben müsste, dafür gibts ja extra die C++ Standards.
Was du warscheinlich meinst, sind die Projekteinstellungen / Compile-schritte (Makefile vs. Visual Studio Projekt). Das zu portieren ist manchmal gar nicht so einfach.
Um welche Libraries geht es? Generell sind eigentlich alle Libraries compilerübergreifend kompatibel. Wäre ja auch bescheuert, wenn man für jeden Compiler anderen Code schrieben müsste, dafür gibts ja extra die C++ Standards.
Was du warscheinlich meinst, sind die Projekteinstellungen / Compile-schritte (Makefile vs. Visual Studio Projekt). Das zu portieren ist manchmal gar nicht so einfach.
Tatsächlich ist das manchnaml gar nicht so einfach. Ich selbst bekomme zum Beispiel auch noch regelmäßig Probleme, wenn ich "*.lib" files in meinen GNU unter Windows linken will. Offiziell werden lib Dateien zwar unterstützt, aber ich hatte auch schon genug fälle in denen lediglich das neukompilieren vom Source aus geholfen hat.
Kann also schon durchaus manchmal Probleme machen, in 90% der Fälle sollte es aber echt einwandfrei laufen.
Wenn CMake als build system von der Library genutzt wird brauchst du das. Und wenn davon was in den Installations dokumenten steht wird die Library das wohl benutzen. Falls du irgendwo nicht weiter kommst kannst du ja entweder hier was genaueres fragen und den namen der Library nennen oder Leute fragen, die an der Library arbeiten.
Um welche Libraries geht es? Generell sind eigentlich alle Libraries compilerübergreifend kompatibel. Wäre ja auch bescheuert, wenn man für jeden Compiler anderen Code schrieben müsste, dafür gibts ja extra die C++ Standards.
Was du warscheinlich meinst, sind die Projekteinstellungen / Compile-schritte (Makefile vs. Visual Studio Projekt). Das zu portieren ist manchmal gar nicht so einfach.
Das ist absolut nicht der Fall, nein. Zum einen sind die generierten Binaries in der Regel nicht zwischen den diversen Compilern und Linkern kompatibel (teilweise nicht mal zwischen unterschiedlichen Versionen des gleichen Compilers). Darüber schreibt der Standard auch gar nichts vor. Und dann hat auch noch jeder Compiler zig Extensions, die bestimmte Code-Konstrukte erlauben, die nur mit diesem Compiler funktionieren. Auch die Verwendung solcher Extensions ist keine Seltenheit.
Davon abgesehen enthalten die Standardbibliotheken vergleichsweise sehr wenig Funktionalität und sobald du externe Abhängigkeiten hast (z.B. zur Win32 API), ist der Code nicht mehr plattformübergreifend. Dann musst du in der Tat für jede Plattform (und das ist in der Regel der Grund, wieso man verschiedene Compiler nutzt) anderen Code schreiben.
Die einzige Möglichkeit, C++ Bibliotheken zuverlässig und (möglichst) für alle Compiler bereitzustellen, ist in Quellcode-Form. Benutzer einer Bibliothek müssen den Code dann einmal selbst passend für ihren Compiler compilen. Andernfalls (z.B. bei closed-source Bibliotheken) ist man darauf angewiesen, dass für den jeweiligen Compiler (und dessen Version) auch ein passendes Binary zur Verfügung gestellt wird.
Das ist absolut nicht der Fall, nein. Zum einen sind die generierten Binaries in der Regel nicht zwischen den diversen Compilern und Linkern kompatibel (teilweise nicht mal zwischen unterschiedlichen Versionen des gleichen Compilers). Darüber schreibt der Standard auch gar nichts vor. Und dann hat auch noch jeder Compiler zig Extensions, die bestimmte Code-Konstrukte erlauben, die nur mit diesem Compiler funktionieren. Auch die Verwendung solcher Extensions ist keine Seltenheit.
Korrekt! Ich ging von reinem Quellcode aus, nicht von vorkompilierten lib-files. Hätte ich vll. dazu-schreiben sollen^^
Korrekt! Ich ging von reinem Quellcode aus, nicht von vorkompilierten lib-files. Hätte ich vll. dazu-schreiben sollen^^
Ja ich weiß, du hast dich bestimmt nur falsch ausgedrückt, aber um auf Nummer sicher zu gehen und eventuellen Googlern Klarheit zu verschaffen:
Nicht einmal der Quellcode wird in vielen Projekten (selbst großen Open-Source Projekten) Compilerübegreifend geschrieben, selbst wenn man es auf derselben Plattform kompiliert.
Das fängt bei Macros wie "#pragma-once" an, geht über "GNU 128-Bit"-Extension bis hin zu unterschiedlichen ABIs (das mag auf den ersten Blick keinen Sinn ergeben, wenn man sich aber darauf verlässt, dass man eine bestimmte ABI vorliegen hat und darauf basierend "MAGIC" macht, kanns schnell krachen wenn sich was ändert).
Die ersten zwei Punkte lassen sich natürlich bei strikter Einhaltung des Standards weitestgehend eliminieren, wobei dann wiederum neue Probleme auftreten ala "Not implemented yet" u.ä.
Punkt 3 ist eigentlich auch vermeidbar, jedoch nicht indem man sich an den Standard hält (denn dieser, so viel ich weiß, macht keinerlei Aussagen über die ABI), sondern indem man sich nicht auf "Design-Fragen" verlässt. Und mal ehrlich, wie oft gibt es wirklich keine andere Möglichkeit als im Call-Stack o.ä. rumzupfuschen? Vielleicht in einem von 1000 Fällen...
Alles in allem:
Wenn man sich an den Standard hält, hat man gute Chancen, dass der Source-Code überall kompiliert, ein Garant ist es jedoch mit Nichten.
Punkt 3 ist eigentlich auch vermeidbar, jedoch nicht indem man sich an den Standard hält (denn dieser, so viel ich weiß, macht keinerlei Aussagen über die ABI)
Nun ja, das ist ja der Punkt. Man verlässt sich nicht auf undefiniertes Verhalten, also vermeidet man das Problem, indem man sich ausschließlich an den Standard hält Letztendlich ist man in C/C++ aber hochgradig eingeschränkt, wenn man sich nur exakt an das hält, was im Standard steht. Man kommt bei so einer low-level Sprache ganz einfach nicht drum herum, sich mit der Plattform zu beschäftigen, für die man programmieren möchte.
Quote:
Wenn man sich an den Standard hält, hat man gute Chancen, dass der Source-Code überall kompiliert, ein Garant ist es jedoch mit Nichten.
Auch wenn er es tut, weißt du nicht sicher, ob das Programm funktioniert, wie es soll. Es ist auf den gängigen Plattformen zwar der Fall, aber eben nicht von der Sprache garantiert. Wenn z.B. die Endianess anders ist als erwartet, wird diverse Logik im Code vielleicht schon komplett falsch.
Zum Beispiel in der Dokumentation von libcurl steht "then run 'mingw32-make mingw32' in the root dir."
Heißt das ich muss immer diesen Befehl ausführen wenn ich eine libary compilen will?
Und macht es einen Unterschied ob ich mingw oder mingw-64 benutze?
Und letzte Frage, muss ich i686-w64-mingw32-g++.exe, oder g++.exe benuzten? (genauso mit den anderen z.B. ar.exe)
[C#] CsgoDouble Libary 04/26/2016 - .NET Languages - 3 Replies C# Libary für csgodouble!
Arbeitet direkt mit dem Websocket von CsgoDouble.
Es wurde nicht alles getestet.
Bei Fragen oder Fehlern bitte melden!
https://github.com/Lucaber/CsgoDoubleClient
Help| C++ libary error 05/26/2011 - SRO Private Server - 0 Replies guys i know its an poplar error
and its seems its happan for me and my firend's
the error title say 'sro_client C++ libary run-time error'
now i dont know what to do other silkroad work for ex ' ISRO Newest
EliteSro just isro 1.265 say libary c++ error
P.S. thank for helpers ;)
Accsess DM Libary without a key. 07/27/2006 - WoW Exploits, Hacks, Tools & Macros - 1 Replies Just take a look here: Video
Note: That can be also done with unstuck.
Cords für DM Libary 08/16/2005 - World of Warcraft - 2 Replies Hat jemand die Cords für die Libary in DM?
Wäre nett, danke
Client Libary 07/12/2004 - General Gaming Discussion - 1 Replies So also ich hab doch eine gefunden :) die recht vernünftig ausschaut :)
http://client-library.ra-doersch.de/
Letztendlich ist man in C/C++ aber hochgradig eingeschränkt, wenn man sich nur exakt an das hält, was im Standard steht. Man kommt bei so einer low-level Sprache ganz einfach nicht drum herum, sich mit der Plattform zu beschäftigen, für die man programmieren möchte.
