ProgChild schrieb:
audacia schrieb:
Sagst du auch "Haselnuß-Brotaufstrich" statt "Nutella"?
Sagst du etwa "Rama", statt "Margarine"? :p
Bitte Fett und Schoko auf mein Brötchen!
Dann eben nicht. Pöh. Hab mittlerweile rausgekriegt dass das leider nicht geht. Ich benutz sowieso lieber Code::Blocks. Visual C++ Express ist mir zu aufwändig, und man sollte nicht mit "Kanonen" auf "Spatzen" schießen. Dev-cpp ist sowieso hoffnungslos veraltet. Naja und mehr fallen mir grad nicht ein
Hat sich also erledigt.
mfg
steve84 schrieb:
Ja, und abgesehen von rein C, für C++ und API Programmieren soll er doch reichen, oder? Gibst da leicht auch was besseres?
Nein, kostenlos unter Windows gibt es für C++ nichts besseres. MS vernachlässigt lediglich den C-Teil in ihrem Compiler, weil sie C++ bevorzugen. Und für C++ braucht man nun mal kein C.
Wie gesagt, in der Kommandozeile kannst du "zypper install" oder kurz "zypper in" verwenden um software zu installieren. Mit "zypper search" oder "zypper se" suchst du nach einem Begriff und "zypper remove" oder "zyppper rm" entfernt ein Paket. Es gibt aber natürlich noch weit mehr was zypper so kann.
Wie hast du dir denn YaST zerschossen? Auf beiden Rechnern? Dann musst du irgendetwas grundlegend falsch machen. Gib mir mal bitte die Ausgabe von "zypper lr -p", das zeigt deine aktiven Repositories an (-p für die Priorität). Hast du bereits andere Pakete am Paketmanager vorbei installiert (Installationsskripts)? Hast du mal von der Kommandozeile versucht und explizit "/usr/bin/gnomesu /sbin/yast2", bzw "/usr/bin/kdesu /sbin/yast2" in KDE probiert?
Noch als kleiner Tipp: Solltest du doch mal gezwungen sein ein Paket manuell vom Source zu installieren, kannst du das trotzdem provisorisch über den Paketmanager machen. Installiere dir einfach "checkinstall" ("zypper in checkinstall"). Beim "make install" Schritt startest du dann mit "checkinstall" davor, also "checkinstall make install". Checkinstall leitet die Installation in eine Sandbox um und erstellt aus den dort angelegten Dateien ein Paket, das du dann mit "rpm -i" (oder durch anklicken) installieren und mit "rpm -e" oder auch aus zypper oder YaST löschen kannst. Mit ein bischen Glück kannst du so auch bereits angerichtetetn Schaden korrigieren, indem du alle bisher am Paketmanager vorbei installierten Pakete nochmal mit Checkinstall installierst und anschließend das erstellte Paket über die bisherige Installation drüberinstallierst. Bei einer anschließenden Deinstallation ist das Paket dann hoffentlich komplett sauber entfernt.
wie schaut es aus mit remove_definitions(-Wextra)
im man cmake steht zwar
Removes -D define flags added by add_definitions.
aber ein Versuch wäre es wert!
pcAlko
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Compiler- und IDE-Forum verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.
rüdiger schrieb:
Wenn man also ein komplett neues System entwerfen würde, dann würde man dafür sicher kein UTF-16 nehmen.
Und deiner Meinung nach was dann? Aber bitte mit genauer Begründung.
rüdiger schrieb:
Unicode im Web ist ja eine relativ neue Sache und da nimmt man eben UTF-8. Nicht nur weil es keine Unterscheidung zwischen LE und BE braucht. Sondern vorallem weil es sehr platzsparend ist. Selbst bei Webseiten mit asiatischem Text spart man locker 40% gegenüber UTF-16.
Also in erster Linie nimmt man im Web UTF-8, weil das Web ein Legacy System ist, welches früher auf ASCII aufgebaut hat (oder noch tut). Und der zweite Grund wäre das Problem mit LE und BE, weil man im Web beides antrifft. Der Platz käme erst an 3. Stelle und habe ich persönlich noch kaum als Begründung aufgeführt gesehen.
Das ist im übrigen sowieso einer der Hauptgründe, wieso UTF-8 so weit verbreitet ist, da jedes System/Bibliothek/Program/usw., welches ASCII verarbeiten konnte, auch UTF-8 durchreichen kann. strlen aus C kann man auch auf UTF-8 anwenden, während dies bei UTF-16 und UTF-32 ziemlich problematisch wird. UTF-8 ist so wahnsinnig verbreitet wegen den Legacy Systemen. Da finde ich es schon sehr verwunderlich, dass du UTF-8 nicht in diese Gruppe nimmst.
rüdiger schrieb:
UTF-16 kombiniert den Nachteil von UTF-8 (keine feste Zuordnung der Codepoints) mit den Nachteilen von UTF-32 (viel Speicherverbraucht).
Man könnte es auch anders sehen. UTF-16 ist einfacher zu dekodieren, da die üblichen Zeichen sogar mit den asiatischen, immer in 2 Bytes platz haben. Meistens muss also nichts gross dekodiert werden. Allerdings verbraucht man dabei auch nicht gleich so viel Speicherplatz wie bei UTF-32.
Im übrigen finde ich noch witzig, dass du von einem neuen Betriebsystem redest. Wir reden aber von aktuellen Anwendungen und sogar in diesem Thread von Windows. Und wenn du in diesem Kontext UTF-16 als nicht sinnvoll bezeichnest, da habe ich schon so meine Mühe mit. Und gerade dieser riesen Windows- und Java-Markt empfinde ich irgendwie nicht als "Sonderfall".
Grüssli
Programmiere gerade etwas OpenGL.
g++ *.cpp glut32.lib -lopengl32 -lglu32
Funktioniert alles soweit. Möchte jetzt ein spiel, dass den glm loader benutzt kompilieren.
Das problem ist, dass ich dann folgende fehler bekomme:
Warning: resolving ___glutInitWithExit by linking to ___glutInitWithExit@12
Warning: resolving __imp__glEnable by linking to __imp__glEnable@4
Warning: resolving __imp__glDisable by linking to __imp__glDisable@4
Warning: resolving __imp__glTexEnvf by linking to __imp__glTexEnvf@12
Warning: resolving __imp__glMaterialfv by linking to __imp__glMaterialfv@12
Warning: resolving __imp__glBindTexture by linking to __imp__glBindTexture@8
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x48ca): undefined r
eference to `_imp__glDeleteTextures'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5c74): undefined r
eference to `_imp__glMaterialf'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5ce2): undefined r
eference to `_imp__glColor3fv'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5cf0): undefined r
eference to `_imp__glBegin'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5d66): undefined r
eference to `_imp__glNormal3fv'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5d93): undefined r
eference to `_imp__glNormal3fv'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5dbb): undefined r
eference to `_imp__glTexCoord2fv'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5ddb): undefined r
eference to `_imp__glVertex3fv'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5e08): undefined r
eference to `_imp__glNormal3fv'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5e30): undefined r
eference to `_imp__glTexCoord2fv'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5e51): undefined r
eference to `_imp__glVertex3fv'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5e7e): undefined r
eference to `_imp__glNormal3fv'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5ea6): undefined r
eference to `_imp__glTexCoord2fv'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5ec7): undefined r
eference to `_imp__glVertex3fv'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5ed9): undefined r
eference to `_imp__glEnd'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5f06): undefined r
eference to `_imp__glGenLists'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5f1e): undefined r
eference to `_imp__glNewList'
C:\Users\chris\AppData\Local\Temp/cc3Frolz.o:glm.cpp:(.text+0x5f37): undefined r
eference to `_imp__glEndList'
collect2: ld returned 1 exit status
ich verstehe einfach nicht warum NUR in der "glm.cpp" die ganzen gl-Befehle aufeinmal zu fehlern führen. in dne anderen dateien funktioniren die gl-befehle doch noch...
das problem scheinen auch andere zu haben, aber hab leider noch keine antwort gefunden.
http://translate.google.de/translate?js=n&prev=_t&hl=de&ie=UTF-8&layout=2&eotf=1&sl=fr&tl=de&u=http%3A%2F%2Fforum.hardware.fr%2Fhfr%2FProgrammation%2FC-2%2Fquel-librairie-wavefront-sujet_49251_1.htm
Ich habe eine dll von einer Camera zu der ich die .lib Datei habe (für Visual Studio). Ich möchte diese nun in eine .a konvertieren.
probiert habe ich eine def Datei zu erzeugen mit:
dlltool -D SMX150.dll -z SMX150.def
das liefert mir aber nur ein
; dlltool -D SMX150.dll -z SMX150.def
EXPORTS
also gar nichts.
Wenn ich direkt eine .a Datei erzeuge (dlltool -D SMX150.dll -l libSMX150.a) enthält die entsprechend auch keine Funktionen (enthält keine Funktionsnamen).
Was könnte ich noch probieren?
Hey danke. Ich habe eigentlich schon im Visual Assist-Forum und auch bei Google gesucht, aber den Beitrag zu den Konstruktoren übersehen. Die Entfernung von Codesymbolen habe auch ich nirgends gefunden, deshalb habe ich hier gefragt (vielleicht ist das irgendwie versteckt oder mit einem Workaround möglich, was mir nur ein erfahrener Benutzer sagen könnte). Aber das scheint eine kaum benötigte Funktionalität zu sein, was mich ehrlich gesagt etwas überrascht.
Dann werde ich mich wohl mal ins offizielle Forum begeben.
SeppJ schrieb:
Also, manchmal sind die Fragesteller selbst ihr größtes Hindernis beim finden einer Antwort. Was ist eine Seite zum VI Editor? Was soll da drauf stehen? Wie soll man auf diese Frage anders antworten als so?
http://en.wikipedia.org/wiki/Vi
Google: vi
Woran haperst am Lesen oder Verstehen? Du kannst mir nicht erzählen dass du nicht verstehst was eine Webseite über den Editor VI ist?
Und du kannst weiter nicht verstehen dass ich nach einer Empfehlung aus dieser riesigen Auswahl an Seiten gefragt habe?
Wenn dich jemand nach einem guten Arzt fragst dann ist deine Antwort: "Schau doch ins Branchenbuch"? So eine asoziale Antwort habe ich ja noch nie erlebt. Und wie pampig du wirst, wenn jemand sich nicht durch 100 Seiten klicken möchte sondern nach einer Empfehlung fragt.
Haste schlecht geschlafen? Lebst du noch alleine weil dich keine will? Bist du irgendwie geistig zurück? Was ist dein Problem mit einer ganz einfachen Frage?
ok bei mir war folgendes die lösung:
wenn die compiler option "präprozess to a file" (/P) angeschaltet tritt bei mir dieser fehler auf... wenn die option abgeschaltet ist geht es...
ich hatte die option angeschaltet um einen fehler zu finden, der bei angeschalteter /P option allerdings nicht auftritt oder nicht angezeigt wird..
habe eine frage und nähere erläuterung unter link gepostet.
habs hinbekommen. falls jemaand auch solche probleme hat:
1.) MinGW installieren.
2.) unter http://sourceforge.net/projects/glfw/files/glfw/2.6/glfw-2.6.bin.WIN32.zip/download die libs runterladen
3.) in den include\GL ordner von MinGW die glfw.h datei aus dem zip ordner kopieren
4.) in den lib ordner von MinGW die 3 dateien (glfw.dll, libglfw.a und libglfwdll.a) aus dem heruntergeladenen zip ordner (lib-mingw) kopieren.
5.) mit
g++ -o myprog -source.cpp -lglfw -opengl32 -lglu32
ganz einfach übersetzen. wenn man keine glu primitiven/befehle benutzt kann man das -lglu32 auch weglassen.
so....eigentlich ganz einfach wenn man mal weiss wie
