Danke für deine Hinweise, ich werde es jetzt dann nocheinmal genau ausprobieren. Das Problem ist das wir die Studienarbeit auf dem RaspberryPi machen und dort noch einige Headerdateien für Sensoren(Lage&Temperator) benötigen. Diese sind in diesem C/C++ Mix programmiert worden
Du solltest dir wohl oder übel ein Makefile basteln und dann dort steuern, dass die .c Files mit gcc (und entsprechenden Optionen) und die .cpp Files mit g++ (und entsprechenden Optionen) separat compiliert werden.
Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (alle ISO-Standards) 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.
Manchmal steht man vor einem verschlossenen Tor und
müsste sich nur noch umdrehen, um wieder drin zu sein.
Ich war die gesamten letzten 24 Stunden mit makefiles und CMAKE beschäftigt/verwirrt.
DANKE, thanks community.
Ich habe den Schalter gefunden und gesetzt.
Für alle weiteren Suchenden.
http://stackoverflow.com/questions/13613295/how-can-i-compile-c11-code-with-orwell-dev-c
For non-project compilations, go to: Tools >> Compiler Options >> (select your compiler) >> Settings >> Code Generation >> (set 'Language standard' to a C++11 option)
For project compilations, go to: Project >> Compiler >> Code Generation >> (set 'Language standard' to a C++11 option)
greets;
SchlitzInDaHaus schrieb:
SeppJ schrieb:
Ich wette, du benutzt nirgendwo das Ergebnis deiner Aktion. define ist eine reine Textersetzung, das definiert keine Linkersymbole.
Das verstehe ich jetzt nicht. Ich wollte ja nicht beides machen, sondern nur die Lösung ab "build.h".
Die Objektdatei die das Zeitmakro enthält wird doch bei jedem Buildvorgang gelöscht und muss deswegen neu erzeugt werden.
Warum wird denn dann da nicht das Datum aktualisiert.
Wie ich doch gerade schon sagte: Ein Makro ist eine reine Textersetzungsregel für den Quelltext eines Programms. Das ist kein Objekt, das hinterher irgendwie Maschinencode landet. Was du brauchst, ist eine Konstante oder eine Funktion, die die Buildnummer enthält bzw. zurück gibt.
Vielen Dank für diese erneut sehr gute Hilfe.
Nein, die += v hatte ich in jeder Schleife stehen.
Mit deinem Code, wird es in meinen Augen noch etwas seltsamer ,
alle ganzzahligen Operationen bis auf die Multiplikation/Division von Short werden mir nun mit 0 ausgegeben,
selbst bei einer Erhöhung der Test-Läufe von 10 Millionen auf 1 Milliarden.
Resultate des Q6600 bei 1 Milliarden Testläufe wie folgt:
Durchschnittliche Zeit für Short Addition/Subtraction: 0
Durchschnittliche Zeit für Short Multipikation/Division: 98492
Durchschnittliche Zeit für Int Addition/Subtraction: 0
Durchschnittliche Zeit für Int Multipikation/Division: 0
Durchschnittliche Zeit für Long Addition/Subtraction: 0
Durchschnittliche Zeit für Long Multipikation/Division: 0
Durchschnittliche Zeit für Float Addition/Subtraction: 50054
Durchschnittliche Zeit für Float Multipikation/Division: 183505
Durchschnittliche Zeit für Double Addition/Subtraction: 50048
Durchschnittliche Zeit für Double Multipikation/Division: 308593
Die Short Multiplikation/Division ist weiterhin deutlich langsamer als die Addition/Subtraktion der Fließkommazahlen.
Mit Assembler habe ich mich bisher nur am Rande beschäftigt,
da müsste ich mich dann einmal ordentlich einlesen.
Nur muss ich dann nicht für jede zu testende CPU einen eigenen Code schreiben,
oder sind die Unterschiede (Ich nenne sie jetzt mal Dialekte) nicht so gravierend in den verschiedenen CPU Generationen,
getestet werden sollen CPUs die den x64 Befehlssatz unterstützen.
Mit Assembler könntest du recht haben, denn direkter kann man meines Wissens nicht auf die CPU zugreifen.
Gibt es ebenso einen Assembler für die Programmierung von GPUs? Dies sind ja doch schon "etwas" anders aufgebaut.
Der Zweck dieses Projektes ist,
zu ermitteln bei welchem Datentyp und ab welcher Datenmenge es sich lohnt, auf die GPU statt der CPU zu setzen.
Das erwartetes Resultat bei den GPU Tests: Fließkommaoperationen sind deutlich schneller als Ganzzahloperationen.
(Jedoch schlage ich mich noch mit OpenCL herum und fühle mich, als wenn ich auf der Stelle trete)
Bitte entschuldigt, falls das jetzt alles etwas durch gewürfelt klingt
Hallo Zusammen,
ich habe eine paar alte Projekte, die mit Visual Studio 2008 + Qt4 PlugIn erstellt wurden.
Wir haben uns entschlossen, die projekte in Visual Studio 2015 + Qt5 PlugIn zu migrieren.
Die Migration an sich ist eigentlich kein Problem.
Die Projekte können erfolgreich übersetzt werden(Build ).
Problem ist: Projekte können nicht gestartet werden (.exe).
Woraus ist bei Migrieren von alten Projekte (Visual Studio 2008) ins Visual Studio 2015 zu achten?
Problem ist mir nicht verständlich
Ich habe es folgenden ausprobiert:
Wenn ich die .exe in Debug Modus starte, dann habe ich folgende Fehlermeldung:
FileLoadException was unhandled
An unhandled exception of type System.IO.FileLoadexception occured in Example.dll
Additional Information: Die Assembly im gemischten Modus wurde während Version v2.0.50727 der Laufzeit erstellt und kann nicht während der 4.0-Laufzeit ohne zuzätzlich Konfigurationsinformationen geladen werden.
Ich weiss es nicht, ob diese Information weiterhilft.
In dieses Zusammenhang stelle sich die Frage: Wie kann man im C++_Projekt so konfigurieren dass es einen bestimmten .NET Framework verwenden werden soll?
Danke
So, das ist ja einfach phänomenal, was sich die Herren aus dem Hause Microsoft mal wieder ausgedacht haben.
Für's Archiv: Man muss dem Linker noch manuell eine Definitionsdatei (.DEF) zu fressen geben, damit er die Symbole auch tatsächlich exportiert. Weil der Compiler dem Linker anscheinend nur eine Liste der generierten Funktionen übergibt, und nicht eine Liste der Funktionen, die explizit als __declspec(dllexport) definiert sind. Die also später in der DLL landen sollen! Weil Visual Studio das anscheinend nicht kann, warum auch immer.
LIBRARY bla.dll
EXPORTS foo
EXPORTS bar
Und die Datei setzt man dann in den Projekteinstellungen unter Linker->Eingabe->Moduldefinitionsdatei.
Und den hier auch noch: wenn man explizit keine Stack-Frame-Generierung haben will, muss man vor dem relevanten Code:
option prologue:none
option epilogue:none
einfügen. Quelle.
Thread kann somit also geschlossen werden.
Das gratis GhostDoc ist lediglich ein Tool zum Erzeugen von "Undocumentation". Also zum automatisierten Erzeugen von "Beschreibungen" von Methoden, Parametern etc., nach dem Motto "GetBlub() - returns the Blub" -- woah, echt jetzt?
GhostDoc Pro würde dann CHM Files etc. erzeugen können, nur das geht auch mit SHFB. Ob bzw. wie viel besser GhostDoc Pro ist kann ich nicht sagen, aber SHFB funktioniert i.A. ganz gut. Bissi langsam, aber ich konnte bisher damit leben. Man muss ja nicht unbedingt 3x am Tag die Doku neu bauen lassen.
Schau dir mal bei den Linker-Optionen "Output File" an - steht dort evtl. der absoluter Pfadname drin? (s.a. error MSB3191)
Ansonsten einfach mal die .csproj-Datei in einem Texteditor öffnen und nach dem Pfad suchen.
Danke, werde es mir merken!
Auf phony targets bin ich auch schon gestoßen, hatte aber, da ich nach anderen Sachen Ausschau hielt, nicht weiter den Bezug gesehen
Werde es mir dann aber auch mal angucken!
ein einheitliches Build-System kann ja offen für Custom Targets sein, solange garantiert ist, daß einige wesentliche Targets (incremental build, clean, debug, release) vorhanden sind, um aus Quellcode X die Binaries Y zu machen.
Wenn ich eine 3rd Party Library kompilieren muß, weil mein Code diese benötigt (und weil es keine plattformspezifisch einheitliche Spezifikation für Object Files gibt), dann interessiere ich mich weniger für Signaturen und Installationspakete, sondern mehr dafür, aus dem Quellcode Binaries zu machen, die ich linken kann, und zwar möglichst ohne daß ich in Makefiles herumfrickeln muß oder Build-Systeme installieren muß, die ich sonst gar nicht benutze.
Plattformspezifisch einheitliche Formate für Object Files und einheitliches Build-System für die o.g. Grund-Targets wären wirklich wünschenswert und würden die Schlagkraft von C++ vermutlich erhöhen, weil sich die Entwickler von Projekten mit zahlreichen 3rd Party Libraries mehr auf die eigentliche Entwicklung konzentrieren könnten und C++-Anfänger nicht noch Experten in make, cmake, bash ... werden müßten.
IlIIIllllIlIIlIIlI schrieb:
Mein Einwand bei den ganzen IDEs, die es gibt, ist, dass ich meine eigene Infrastruktur zum Compilen und zum Linken nicht aufgeben möchte. Ich will den Build-Prozess selbst verwalten. Ich will kein Programm (i.e. die IDE), das sowohl Texteditor, Makefile-Generator als auch Debugging-Frontend darstellt. Es geht immer schief mit solchen Eier legenden Wollmilchsauen. Daher will ich wirklich nur ein Frontend, das das Debuggen von fertigen ausführbaren Dateien ein wenig angenehmer gestaltet, egal ob CLI oder GUI.
Etwas einfacheres als QtCreator wirst du beim Besten Willen nicht finden. Das Warten der Projekt-Dateien ist unter C/C++ kaum einfacher machbar. QtCreator hat außerdem auch einen vim Mode.
Ich hasse cmake so sehr....
Entschuldigung, das ist Off Topic, aber musste sein.
Hatte beruflich die Tage den Auftrag das neue Root mit Jupyter Kernel vom CERN zu compilieren. So viel abfuck...
klanger schrieb:
Danke, dass du dir die Zeit genommen hast.
Jo gern. Vielleicht fragst du das nächste mal jedoch besser nach konkreten Lösungsvorschlägen für dein Problem. Dein Eingangsposting war ja eher ein "Rant" ohne eine konkrete
Frage - du hast Glück dass ich mich in dieser Frustration wiedererkannt habe, weil ich diese Phase auch schon hinter mir habe - nicht selten werden solche Postings nicht ganz unberechtigt einfach ignoriert ;).
Viele dieser fixen Verzeichnisstrukturen stammen aus der Linux/Unix-Welt und machen natürlich manchmal Probleme, wenn man das Programm unter Windows verwenden will.
Diese vorgegebenen Verzeichnisse können aber auch durchaus vorteilhaft sein - mit vielen komplexen Konfigurationsdateien kann man auch schnell im Chaos versinken.
klanger schrieb:
Finnegan schrieb:
P.S.: Bei meinem selbstgebauten Clang ist mir das mit dem "default target" nicht aufgefallen, da ich dort Clang so konfiguriert habe,
dass er ohnehin 64bit-MinGW verwendet: "... default target x86_64-w64-windows-gnu"
Kann ich das auch erreichen, ohne Clang selbst neu kompilieren zu müssen?
Unwahrscheinlich. Letzendlich ist das Default Target höchstwahrscheinlich ein fest einkompiliertes #define . Nimm das einfach in deine Compiler-Flags
auf - spätestens wenn man irgendwann für andere Systeme (Cross-)kompiliert muss man das ohnehin immer angeben.
Finnegan
Mich würde halt im Kern interessieren wie ich die Pfadangabe und die regulären Ausdrücke unter Windows anpassen muss.
welcher Kompiler? g++ vom MinGW oder Cygwin Projekt?
welche regulären Ausdrücke meinst du?
Außerdem ist in meinen Augen das Makefile der Industriestandard.
"das Makefile" - von welchem Makesystem? GNU make, nmake, cmake usw. - so einen richtigen Industriestandard gibt es da doch gar nicht
warum hier alle immer mit ihrer Erfahrung kommen müssen was wo wie Standard ist - völlig unrelevant und absolut Firmen/Projektbezogen - was für dich 1000 mal wichtiger ist das du es SELBST unter Windows ausprobierst bevor du es lehrst - alles andere ist unprofessionell
Arbeite dich mit Vim ein und dann füge sobald du den Funktionsumfang von Vim auskennst die entsprechenden benötigten Plugins hinzu. Wenn du ernsthaft entwickeln willst arbeitet es sich so am Besten. Außerdem empfehle ich zusätzlich zum angenehmen arbeiten TMUX als Terminal-Multiplexer.
Was ist an der Fehlermeldung jetzt bitte unklar?
Installier' das Windows 8.1 SDK oder stell dein Projekt um dass das Windows 10 SDK verwendet werden soll.
audacia schrieb:
Für Windows-spezifische Software ist Qt meiner Meinung nach nicht das Optimum. Der Komponentenmarkt ist überschaubar (gibt es mittlerweile Ribbons für Qt?), und es ist nicht ganz leicht, ein nativ wirkendes GUI zu erstellen.
Warum kommt .NET für euch nicht in Frage?
Um ehrlich zu sein kenne ich mich mit dem MS VS und GUI Toolkits kaum aus. Nach dem Borland Fiasko möchten wir eigentlich so nah wie möglich am C++ Standard bleiben. .NET setzt managed C++ ein, was ja wieder eine microsoft-spezifische Erweiterung von C++ ist. Wer weiß, auf welche Probleme man da wieder stößt.
