Morgen, uch versuch gerade ein GUI Toolkit zu finden, dabei bin ich auf AGAR gestossen. http://libagar.org/index.html.en Hab mal ein Bsp. von dort versucht zu kompilieren und bekomm eine Unmenge von Syntaxfehlern. Das Muster ist immer gleich Source ist AG_Surface * AG_ReadSurfaceFromBMP(AG_DataSource *ds) { ... } Declaration im Headerfile extern DECLSPEC AG_Surface *AG_ReadSurfaceFromBMP(AG_DataSource *); Fehlermeldung error #2001: Syntax error: expected ')' but found '*'. Das sollte doch eigentlich passen? Compiler = PellesC 6.00 unter Windows XP Kann mir einer sagen warum der Compiler meckert? Gruss Heinz
heinz schrieb: > Das sollte doch eigentlich passen? Nur wenn AG_Surface, AG_DataSource und DECLSPEC auch an der Stelle bekannt sind.
//int *AG_Surface; typedef int AG_DataSource; extern DECLSPEC AG_Surface *AG_ReadSurfaceFromBMP(AG_DataSource *);
ups - falsche taste //int *AG_Surface; gibt Redeclaration typedef int AG_DataSource; extern DECLSPEC AG_Surface *AG_ReadSurfaceFromBMP(AG_DataSource *); so läufts durch (für die Zeile) danke für den Tip Gruss heinz
@andi Qt == C++ bei Qt gefällt mir die Abhängigkeit (von Qt) nicht. Ich such was einfaches statisch linkbar zu C passt und platform unabhängig ist spiel zur Zeit mit iup rum. Gruss heinz
heinz schrieb: > typedef int AG_DataSource; > extern DECLSPEC AG_Surface *AG_ReadSurfaceFromBMP(AG_DataSource *); > > so läufts durch (für die Zeile) Das ist keine Lösung, sondern ein Verdecken des Fehlers. Wo wird AG_Surface deklariert? Die betreffende Headerdatei ist vor Deiner Definition einzubinden.
das war kein verdecken sondern feststellen was undefined ist. Dass ich die headerdatei bzw. die def. vorher includen muss ist klar. Dumm ist nur das die wieder abhaengigkeiten hat. griss heinz
heinz schrieb: > Dumm ist > nur das die wieder abhaengigkeiten hat. Dann bindest Du die falsche Headerdatei ein; das Agar-Toolkit wird da irgendeine standardisierte Vorgehensweise haben, die möglicherweise auch mit der Installation des Toolkits zu tun haben, also z.B. bestimmte Symbole definieren, um Plattformabhängikeiten zu definieren etc. Welche Sourceversion des Toolkits hast Du heruntergeladen? [Nachtrag] Hast Du Dir die "platform-specific notes" auf http://libagar.org/docs/index.html.en angesehen? Wenn Du einen anderen C-Compiler als die dort angegebenen verwendest, wirst Du herausfinden müssen, wie Du compilerspezifische Anpassungen für Deinen Compiler anpassen musst. [/Nachtrag] Im übrigen ist es bei solchen Problemen immer wichtig, sich mit den Fehlermeldungen der Reihe nach zu beschäftigen. Willkürlich eine herauszupicken ist sinnlos, da es sich fast immer um Folgefehler handelt.
yeo, die notes hab ich gelesen. Die beziehen sich aber auf MS VC ich benutz Pelles. Ist schon klar dass daher die Probleme kommen. Ich will aber auch nicht im Source des Toolkit rumändern. War nur mal ein Blick auf was anderes, aber viel Arbeit damit will ich mir auch nicht machen. gruss heinz
heinz schrieb: > yeo, die notes hab ich gelesen. Die beziehen sich aber auf MS VC ich > benutz Pelles. Ist schon klar dass daher die Probleme kommen. > > Ich will aber auch nicht im Source des Toolkit rumändern. Darum geht es ja auch nicht, Du musst halt nur die Umgebungsbedingungen soweit anpassen, daß Du "Deinen" Compiler verwenden kannst. Alternative: Nimm einen anderen Compiler. Die Express-Version des MS-Compilers ist kostenlos.
Darim gehts schon. C != C Das ist nicht so portable wie viele meinen. Steig ich im auf MS werd ich automatisch incompatibel zu ANSI. Die schaffen es sogar dass Ihre eigenen Lib´s von einer Version zur nächsten nio sind. Wie gesagt ich habs mal angeschaut (macht auch einen guten Eindruck wenn ich die Doc. überfliege) aber ich bleib bei iup. gruss heinz
heinz schrieb: > @andi > Qt == C++ > bei Qt gefällt mir die Abhängigkeit (von Qt) nicht. Bei jeder Bibliothek hast du eine Abhängigkeit von ebendieser Bibliothek. > Ich such was > einfaches Im Sinne von einfach zu verwenden oder im Sinne von wenig Gesamtumfang? > statisch linkbar Auch Qt ist statisch linkbar, allerdings ist statisches Linken meist eher weniger sinnvoll. > zu C passt C halte ich für eher weniger geeignet für GUI-Programmierung. Ich hatte mir mal Gtk angschaut und fand es grauenvoll zu programmieren. Für vernünftige GUIs ist objektorientierte Programmierung quasi Voraussetzung, und die läßt sich zwar auch in C machen, aber teils nur sehr umständlich. > und platform unabhängig ist Qt gibt es für fast alle gängigen Plattformen. > spiel zur Zeit mit iup rum. Ist mir unbekannt. heinz schrieb: > Darim gehts schon. C != C > Das ist nicht so portable wie viele meinen. Steig ich im auf MS werd ich > automatisch incompatibel zu ANSI. Dann nimm GCC. Den gibt's kostenlos und für so gut wie jede Plattform, auch für Windows (MinGW). Im Gegensatz zu Microsoft bemüht sich GCC um hohe Konformität, und das auch zu C-Normen, die weniger als 20 Jahre alt sind.
Eine mögliche Alternative zu Qt ist wxWidgets: http://www.wxwidgets.org/ Weitere Alternativen sind hier aufgelistet: http://en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries
Mark Brandis schrieb: > Eine mögliche Alternative zu Qt ist wxWidgets: Das hilft jemandem nicht, der kein C++ einsetzen will.
Rufus Τ. Firefly schrieb: > Mark Brandis schrieb: >> Eine mögliche Alternative zu Qt ist wxWidgets: > > Das hilft jemandem nicht, der kein C++ einsetzen will. Es scheint da was in Richtung eines C-bindings zu geben: http://wxc.sourceforge.net/ Weiß aber nicht, ob das noch gepflegt wird bzw. schon vollständig umgesetzt ist. Abgesehen davon, GUIs ohne OOP machen doch keinen rechten Spaß. Wenn man zum Beispiel an die Win32 API denkt... (schauder)
Also ich finds WIN API gut :) aber ich find ja auch OGL gut. Als ich gesagt hab "einfach" dachte ich eher an die Abhängigkeiten siehe zB. GTK. Entweder x DLLs oder statisch aufgeblasen. Zu der Qt Abhängigkeit - ich denk man soll GUI und das eigentliche Programm trennen. Das was ich bei Qt gesehen hab find ich grausam (nie Qt programmiert, nur ein paarmal reingeschaut). Da ist das Prigramm durchsetzt mit Qt abhaengigen Sachen. Ich link gern statisch weils dann keine Abhängigkeiten gibt. Ist schon klar dass ich da manchmal Speicher verschwende, aber wo ist der Sinn wenn ich ein Prg. schreib geteilt in eine kleine Exe und ein paar DLLs wenn kein anders Prg auf diese DLLs zugreift (benötigt)? Zu GUI und C http://www.tecgraf.puc-rio.br/iup/ recht schlank und (fast) alles was ich brauch http://otk.sourceforge.net/ ganz schlank und fast nichts was ich brauch (find ich aber im Ansatz gut) gruss heinz
heinz schrieb: > Zu der Qt Abhängigkeit - ich denk man soll GUI und das eigentliche > Programm trennen. Das kann man doch gut mit Qt machen. > Das was ich bei Qt gesehen hab find ich grausam (nie Qt programmiert, nur ein > paarmal reingeschaut). Da ist das Prigramm durchsetzt mit Qt abhaengigen > Sachen. Was hat denn das eine mit dem anderen zu tun? Qt besteht aus mehreren Bibliotheken, und eine davon ist die GUI-Bibliothek. Man kann mit Qt auch Programme ganz ohne GUI schreiben, die dann auch nicht an irgendwelche GUI-Komponenten von Qt linken müssen. Wenn also ein Programm durchgehend Qt-Abhängigkeiten hat, heißt das nicht, daß deshalb der GUI-Code nicht vom restlichen Programm getrennt wurde. > Ich link gern statisch weils dann keine Abhängigkeiten gibt. Ist schon > klar dass ich da manchmal Speicher verschwende, aber wo ist der Sinn > wenn ich ein Prg. schreib geteilt in eine kleine Exe und ein paar DLLs > wenn kein anders Prg auf diese DLLs zugreift (benötigt)? Naja, unter Windows ist diese Sache nie zufriedenstellend gelöst worden. Beim statischen Linken mußt du übrigens ggf. mit der Lizenz aufpassen. Wenn du statisch an Bilbiotheken unter der LGPL linkst, gibt es Einschränkungen, die zu beachten sind.
Zu Qt - hab uch wie gesagt nie was selbst gemacht, ich find halt (beim lesen) in jeder Programmzeile irgendwas das mit Qt anfängt. Ob man das sauber trennen kann kann ich nicht beurteilen. Das mit den DLL hab ich anders gemeint. Ich hab da ein grundsätzliches Problem. Eine DLL macht Sinn wenn mehrere Programme drauf zu greifen zB. Opengl32.dll ist sinnvoll weil zB. mein CAD den Code braucht und irgend ein Spiel - der Code ist nur einmal im Speicher. Schreib ich ein Programm das aus x.exe und y.dll besteht znd y.dll code enthält der nur von x.exe gebraucht wird sehe ich da kein Vorteil. Zu den Lizensproblemen - die entfallen wenn ich opensource schreib.
heinz schrieb: > Zu den Lizensproblemen - die entfallen wenn ich opensource schreib. Nein, das tun sie eben nicht. Es gibt verschiedenen 'open-source' lizenzen, die aber zueinander inkompatibel sind.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.