cooky451 schrieb:
WTF? Hat Microsoft nicht mal die Aussage gemacht, dass die ganze Standardbibliothek implementiert sei?
Nun offensichtlich wohl nicht. Wo hast du die Aussage denn her? Ich kann sie nirgends finden. Hingegen finde ich bei Google eine Menge Leute, die auch feststellen, dass diese Funktionen fehlen (und es keinen Trick dagegen gibt).
Sicher, dass du das richtige Projekt kompilierst?
Und wenn du nur was in Headern änderst, musst du darauf achten, die auch zu inkludieren in einer Sourcedatei, sonst macht der nichts.
Tatsächlich verändert sich teilweise die Semantik eines Programms durch -Ofast .
GCC-Manual:
Disregard strict standards compliance. ‘-Ofast’ enables all ‘-O3’
optimizations. It also enables optimizations that are not valid for all standardcompliant programs. It turns on ‘-ffast-math’ and the Fortran-specific ‘-fno-protect-parens’ and ‘-fstack-arrays’.
-ffast-math ist AFAIK besonders kritisch.
Mahlzeit, ich versuche gerade ein CMake-Projekt zusammen zu basteln. Soweit funktioniert es, nur weiß ich nicht so recht, wie ich ein Unterprojekt als Shared Library linken kann. Bis jetzt werden die Dateien im common - Verzeichnis für jedes weitere Unterprojekt extra übersetzt.
Ich habe schonmal etwas mit dem target_link_libraries Makro in der CMakeLists.txt im cpu-Verzeichnis rumgespielt, aber ich weiß nicht so wirklich, welche Variable ich dort einsetzen soll bzw. wie ich das common Target überhaupt den restlichen Projekten bekannt machen kann. Außerdem konnte ich dort unsinnige Variablen einsetzten, ohne dass sich CMake beschwert hätte^^
Wäre nett, wenn mal jemand drüber schauen könnte!
Verzeichnisstruktur:
truemon // Hauptprojekt
src
common // Unterprojekt (soll als Shared Lib zum Rest gelinkt werden)
cpu // Unterprojekt, was auf common zugreifen soll
Meine CMakeLists:
CMakeLists.txt in truemon
cmake_minimum_required(VERSION 2.6)
project(TRUEMON)
find_package(KDE4 REQUIRED)
include(KDE4Defaults)
include(MacroLibrary)
set(CMAKE_BINARY_DIR ${CMAKE_CURRENT_SOURCE_DIR}/build)
set(LIBRARY_OUTPUT_DIR ${CMAKE_BINARY_DIR})
include_directories(
#${CMAKE_SOURCE_DIR}
${CMAKE_BINARY_DIR}
${KDE4_INCLUDES}
)
add_subdirectory(src)
CMakeLists.txt in src
set(TRUEMON_INCLUDES ${CMAKE_CURRENT_SOURCE_DIR}/common)
include_directories(
${TRUEMON_INCLUDES})
add_subdirectory(common)
add_subdirectory(cpu)
CMakeLists.txt in common
project(truemon-common)
#include_directories(
# ${CMAKE_CURRENT_SOURE_DIR}
# ${CMAKE_BINARY_DIR}
#)
set(TRUEMON_COMMON_SRCS
sensor.cpp
)
kde4_add_library(truemon-common ${TRUEMON_COMMON_SRCS})
CMakeLists.txt in cpu
project(truemon-cpu)
set(TRUEMON_CPU_SRCS
truemon.cpp
#sensor.cpp
)
kde4_add_plugin(truemon-cpu ${TRUEMON_CPU_SRCS})
target_link_libraries(truemon-cpu
${KDE4_PLASMA_LIBS}
${KDE4_KDEUI_LIBS}
)
install(TARGETS truemon-cpu DESTINATION ${PLUGIN_INSTALL_DIR})
install(FILES truemon-cpu.desktop DESTINATION ${SERVICES_INSTALL_DIR})
cooky451 schrieb:
Also ich vergleiche ab und zu mal die Performance auf Windows, und da gewinnt VS eigentlich durchgängig. Mal nur knapp, mal um ~15%, und selten um Faktor 3. (Das lag aber an der Library, da hat Microsoft wohl einfach eine bessere Implementierung von std::map oder so gehabt.)
Wobei das ganze etwas unfair ist, da ich normalerweise mit VS optimiere und den Kram dann nur hinterher mal mit GCC ausprobiere.
naja, das liegt aber daran, dass GCC auf Linux-Systemen zu Hause ist, und die Windows-gcc Version lediglich ein Port von der Linux Version ist.
Wahrscheinlich ist der Port auch nicht sonderlich optimiert, aber das braucht man meiner Meinung nach auch nicht.
Außerdem ist es dem Anwender egal, ob jetzt die exe, auf die er doppelklickt, mit MingW oder mit MS-Zeugs kompiliert wurde. Einen wirklichen "Geschwindigkeitsvorteil" wird es auch nicht wirklich geben.
also nochmal:
1. die lib muss im selben verzeichnis liegen wie t.c
2. die lib muss den namen haben: libqrbg-c.a
3. aufruf:
gcc -o t.exe t.c -L .\ -l qrbg-c
Wenn du die IDE DEV richtig bedienst, funktioniert die.
Hast du noch die alte bis Version 4.9.9.2 am Start? Dann suche dir die aktuelle Version. Oder brauchst du die weil ihr in der Schule noch die alte habt?
Hier zum aktuellen Stand:
http://orwelldevcpp.blogspot.de/
Sonst kannst du in alten Beiträgen hier im Forum nachsehen. Wurde schon oft darüber geschrieben.
Oder ist obriges gar nicht dein Problem, sondern folgendes:
http://www.c-plusplus.net/forum/111042
MfG f.-th.
It0101 schrieb:
Bist du denn sicher, dass dein Buildprozess überhaupt erfolgreich ist?
Wann immer ich keine EXE gefunden habe, lag es daran, dass es noch irgendwo einen Fehler, meist beim Linken, gab.
Wie könnte ein solcher Fehler aussehen? Bzw. Wie sollte ich es wiederholen?
Ich danke euch jetzt schon für die ganzen Antworten !
Danke für eure Hilfe. Die in den Fehlern angegebene Datei war zwar dem Projekt zugefügt, allerdings musste ich sie trotzdem noch zum Moc'en hinzufügen. Damit lief alles.
Hallo,
ich verwende Eclipse zur C++-Programmierung und lasse die Standard-Ausgabe und die Fehler-Ausgabe zur Console umleiten (wie es wohl per Default ist). Dabei kommt es häufig dazu, dass sich die beiden Ausgaben vermischen, so dass sie nicht mehr in der korrekten chronologischen Reihenfolge stehen.
Kann man das irgendwie abstellen? Insbesondere Fehlermeldungen kann man so leicht übersehen, da man sie an der falschen Stelle sucht.
Hallo.
Ich entwickle schon einige Zeit mit dem Visual Studio C++ unter Linux und da die jetzige Situation nicht zufriedenstellend ist, suche ich nach einer Lösung die eine Verbesserung bringt.
Ausgangsbasis:
- PC mit Win7 + Visualstudio (damit wird der c++-Code geschrieben)
- es wird kein automatisch generiertes Makefile erstellt, sondern manuell von mir selbst
- PC mit Ubuntu (dieser PC dient zum compilieren, debuggen mittels gdb und testen)
Verbesserungswunsch:
- PC mit Win7 - Visualstudio kann auch compilieren und nach bedarf auch debuggen
- makefile sollte weiterhin von mir erstellt werden und nicht automatisch.
- PC mit Ubuntu bleibt weiterhin bestehen (am besten sollte dort quasi das remote-compiling/debugging stattfinden)
Es gibt Visual Studio-Tools die so etwas unterstützen http://visualgdb.com/ und http://www.wingdb.com/
Hat mit diesen Tools wer Erfahrung, kann mir eines der beiden für meine Zwecke empfehlen oder gar ein total anderes VS-Tool?
Schon vorab ein großes DANKE für eure Hilfe!
Johannes
Also ich habe nur schlechte Erfahrungen mit boost-ähnlichen abgefahrenen Template-Bibliotheken gemacht, ansonsten konnte ich Visual Studio noch nicht sonderlich beeindrucken, selbst in größeren Projeken. Vielleicht liegt hier wirklich ein Fehler vor...
KN4CK3R schrieb:
du sollst die auch nicht zu den Includepfaden hinzufügen sondern in die Projektmappe aufnehmen, damit sie kompiliert werden.
greetz KN4CK3R
mensch bin ich blöd danke
Decimad schrieb:
Ich habe das bei mir folgendermaßen geregelt:
Bibliotheks-Projekte, die ich in die Solutions als Projekte auschecke. Im Solution-Verzeichnis gibt es ein Verzeichnis (lib_config), in dem die Projektspezifischen Config-Header der Bibliotheken gesucht werden. So bekommt jede Bibliothek Solution-Spezifische Konfigurationsdaten. Zudem erstelle ich für jede Bibliothek Propertysheet-Dateien, die man im verwendenden Projekt einfach nur in die Konfigurations-Eigenschaften hinzufügen braucht.
Also, auschecken, zur Solution hinzufügen, Propertyconfig anpassen, Propertysheet hinzufügen und schwupps ist man fertig.
Das schau ich mir mal an
ist von mir gelöst: man darf nicht mit Cut & Paste sondern mit Import der XML-Datei arbeiten. Funktioniert auch mit der JUNO Version von Eclipse. Es kommt zwar eine Fehlermeldung zum Schluss, die kann man aber ignorieren. Das XML ist signiert.
johan schrieb:
Wie kann man ein einmal gespeichertes Projekt komplett aus dem Repository entfernen (es soll nur die Arbeitskopie übrig bleiben - die ich danach z. B. wieder neu einchecken möchte)? Anscheinend nicht vorgesehen.
Viele Systeme supporten das gar nicht oder nur über schlimme Umwege.
Bei SVN z.B. geht es theoretisch, indem man die komplette History "dumpt", aus dem Dump-File dann (mittels diverser Tools) das entfernt was gelöscht werden soll, und aus dem modifizierten Dump-File dann ein neues Repo erzeugt.
Das Angebot an Tools zum bearbeiten von Dump-Files sowie deren Fähigkeiten sind aber sehr begrenzt. Und es kann u.U. auch Überraschungen geben, z.B. dass bei nem File auf einmal ein grosser Teil der History fehlt, weil es in seiner "copy-from" Geschichte irgendwann mal nen Pfad durchlaufen ist der gelöscht wurde.
Genau so können Files übrigbleiben die man eigentlich weg haben wollte, wenn man nicht alle Pfade angibt unter denen die irgendwann mal zu erreichen waren.
Wenns nur um ein paar MB Platz geht, ist das einfachste ein "delete" zu committen, und sich damit abzufinden dass man jetzt durch eigene Dummheit ein wenig Platz verschwendet hat. (Wenn das Repo quasi noch frisch ist, kann man natürlich auch so wie du ganz neu anfangen, aber wenn da mal Wochen, Monate oder Jahre an History drin sind...)
Was andere Systeme angeht... bei Source Safe ging es, aber hui, an Source Safe will ich gar nimmer denken. *würg*
Und mit den restlichen kenn ich mich viel zu wenig aus als dass ich da was sagen könnte.
