Ja, die Häkchen sind alle gesetzt. Ich arbeite auch schon länger mit MSVS 08, derlei Probleme hatte ich jedoch bisher noch nie.
@Th69: Ja, die vcproj-Dateien muss ich mir mal morgen anschauen. Ich denke mit WinDiff (Vergleich zwischen Backup und neuer Datei).
Für weitere Ideen wäre ich natürlich weiterhin offen...
@SeppJ danke fürs verschieben, was du mit der Reihenfolge meinst
wird mir leider nicht schlüssig
Im Terminal kann ich es ja ohne Probleme compilieren.
Nur in Netbeans bekomme ich den Fehler, das sqrt unbekannt ist.
Hoffe jemand weis noch Rat, die Lösung aus dem Netbeans forum funktioniert
leider nicht.
Make File? hmm, normalerweise nutzt Eclipse ein Internal Builder.
Die Libs werden gewöhnlicherweise unter
Project Property (Rechts klick auf Project -> Properties)
C/C++ Build -> Settings -> Tool Settings -> GCC Linker (evtl steht auch C++ oder C dabei) -> Library
Libraries (-l) nur Libname eintragen, falls benötigt wird
Library search path (-L) mitgeben.
eingetragen.
Kann sein, dass diese Option nicht angezeigt wird, weil es als Build ein Makefile benutzt.
Du meinst wohl VS10EE (Express Edition), da ist (natürlich) kein Profiler bei.
Du kannst aber eine 90-Tage-Demo Version der Professional-Version runterladen, da ist dann ein Profiler mit bei.
http://www.microsoft.com/visualstudio/en-us/products/2010-editions/test-professional/overview
Also ich muss wohl die CMakeLists editieren..
mit:
include_directories(/usr/local/MATLAB/R2012a/extern/include)
findet er zumindestens die engine.h Datei. Jetzt muss ich nur noch rausfinden in welcher lib Datei die Implementierung davon ist und wie ich die mit CMakeLists einbinde.. kann mir jemand was zur Einbindung sagen? Die Lib-Datei erfrage ich mal in nem Matlab-Forum.
Habe es mit target_link_libraries(listener libeng.so) und link_directories() versucht aber erhalte weiterhin die Fehlermeldung, dass die einzelnen Funktionen nicht gefunden werden.
edit: In der Matlab doku habe ich gefunden: 32-bit Linux LD_LIBRARY_PATH matlabroot/bin/glnx86: matlabroot/sys/os/glnx86
RussianTux schrieb:
1. Ist es möglich, GCC / G++ Flags in dem zu kompilierendem Quellcode zu erläutern ohne sie beim kompilieren jedes mal dem Compiler mitteilen zu müssen?
Jain. Nicht so wie du es formulierst und das ist auch gut so. Aber man kann eine Menge angeben. Ich sag mal: RTFM! Insbesondere:
http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html#C-Extensions
http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Extensions.html#C_002b_002b-Extensions
http://gcc.gnu.org/onlinedocs/gcc/Pragmas.html#Pragmas
2. ist es möglich, so wie im ersten Beispiel wo es sich um die Ermittlung des Betriebssystems handelt, eigene Bedingungen zu definieren welche der Compiler während der Kompilierung berücksichtigt?
Beispiel:
#ifndef _WIN32
//Plattform == windows
#endif
Ziel:
g++ main.cpp -o main -einschalten
#if einschalten
//kompiliere dies
#else
//ansonsten...
#endif
Ja:
http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#Preprocessor-Options
Und halte dich deiner eigenen Gesundheit wegen bitte an übliche Makrokonventionen:
- Alle Makros komplett großschreiben, diese Schreibweise nur für Makros benutzen
- Alle Makros mit einem möglichst einzigartigen Präfix (analog zu einem namespace) versehen, zum Beispiel deinen Initialen oder einer Abkürzung des Projektnamens.
Ich habe mir mal den von Zeus verlinkten Vergleich angesehen. Rein von den Y/N-Fakten hätte ich sofort SD installiert. Es bietet anscheinend die für meine Bedürfnisse besseren Argumente. Z.B. benötige ich keine ASP.NET und auch keine WinForms. Fehlende WPF-Komponenten im Designer würde ich auch direkt über XAML-Sourcen eingeben. Entscheidend ist für mich die Arbeit im Codeeditor, der WiX-Support (cool!) usw.
Was ist den an VC# Express geiler? Ich selber bin VisualC++ Fan (habe auch VisualAssist X), habe also keine Ablehnung keine VisualStudio-Produkte! Aber die Express Editionen sind immer eingeschränkt. Ich kann mir gut vorstellen, das deshalb SD zumindest der VC# EE davon zieht. Bei der VC# Pro wird es wahrscheinlich wieder anders aussehen.
Ich denke, ich werde mir mal zumindest SD ausprobieren.
Wenn Du ein Konsolenprogramm willst, sollte unter Linker/System folgendes zu finden sein:
Konsole (/SUBSYSTEM:CONSOLE)
Eigentlich ist dieses Feld eine DropDown Box und mit einem Klick auf den Pfeil am rechten Rand erhält man eine Auswahl.
rüdiger schrieb:
-static Flag vor die Bibliotheken setzen. Du musst dann aber die Bibliotheken alle in einer statischen Variante haben! (sdl-config hat --static-libs als Option)
also wie jetzt? ich versteh es nicht ganz..
kannst du villeicht den Befehl aufschreiben wie es dann aussehen würde?
Hio!
Ich entwickle momentan in einer Projektgruppe realtiv low-level C++-Code, sodass wir uns dazu entschlossen haben, den Code auch ordentlich zu kommentieren. Sowas soll ja hilfreich sein In C/C++ gibt es ja sehr unterschiedliche Ansätze: Von Doxygen bis XML ist ja irgendwie alles dabei. Nach langem Hin und Her wollen wir die Doku nun mit Doxygen erzeugen und nutzen dann diesen "@param-Stil":
/** @param a Der Parameter a
* @return Der Returnwert
**/
int foo(int a) {
//...
}
Das Programm wird für Linux entwickelt, sodass ich die meiste Zeit mti Vim am Laptop arbeite - dafür gibts auch einige Plugins, die Doxygen in vim einbinden, also die Kommentare automatisch erzeugen. Jetzt wollte ich ein wenig zu Hause für das Projekt machen und am liebsten an meinem Desktop-PC mit Windows arbeiten. Am Windows nutze ich notepad++, wofür es offensichtlich keine Plugins in diese Richtung gibt? Ich hab mir auf Sourceforge die Plugins angeschaut, aber da scheint nichts Doxygen-Konforme Kommentare automatisch zu erzeugen.
Was ich im Endeffekt suche, ist ein Plugin, welches bei der Eingabe "/**" automatisch die passende Komemmentarstruktur erzeugt (also mit @param,@return,@exception etc).
Gibt es sowas für Notepad++ oder könnt Ihr für sowas einen anderen Editor empfehlen? (IDE brauche ich nicht, weil das Programm eh für Linux programmiert wird). Oder ist das einfach nicht der "normale" Weg C/C++ zu kommentieren? Visual Studio nutzt ja z.B. diese XML-artige Struktur für seine Kommentare.
Gruß
Pille
SeppJ schrieb:
..., aber du bist einfach noch nicht so weit.
Ich weiss nicht, ob man das so sagen kann. Wie wäre es damit:
Ist es sinnvoll das du emacs lernst, wenn du eigentlich noch andere grundlegende Wissenslücken aufweist, welche du womöglich zuerst stopfen solltest?
Wozu willst du emacs lernen? Wieso? Was ist die Motivation? Wäre es nicht sinnvoller zuerst andere Dinge zu lernen, welche dir mehr bringen, als so einen Grossvater-Editor (:D) bedienen zu können?
Grüssli
PS: SeppJ ist schuld
Code::Blocks ist kein Compiler sondern eine IDE, die etwa 20 verschiedene Compiler ansteuern kann.
Welchen der in C::B vorbereiteten Compiler hast du denn auf deiner Festplatte
Wer sich Mühe gibt bekommt sicher noch weitere als die vorbereiteten Compiler ans Laufen.
Die Compiler können noch mehr als C::B als Vorgaben zeigt. Das nicht Gezeigte lässt sich nachrüsten.
Die für Anfänger meist einfachste Variante mit C::B -> C::B mit dem Compiler MinGW als Paket laden. Aber Achtung - bin nicht auf dem aktuellen Stand - die Dateien. die der MinGW 4.4.1 baut werden zum Teil von einigen Virenscanern angemahnt. Abhilfe sofort aktuellere MinGW installieren: MinGW 4.6.?
Oder, wenn ihr euch nicht mit dem MinGW 4.4.1 vergnügen wollt:
Aktuellen MinGW 4.6.3 installieren. Danach C::B 10.05 installieren. die IDE C::B sollte den MinGW (gcc) automatisch finden und du kannst loslegen.
Sollte dir ein anderer Compiler besser gefallen schau in C::B unter -
Settings -> Compiler and Debugger Settings und klick dich da durch. Als Anfänger brauchst du da meist nichts zu ändern. Wenn du dich auskennst, dann zu
Viel Spass
f.-th.
Hallo,
ich versuche gerade, OpenCV zu kompilieren (unter OS X), kriege aber Fehler vom linker:
z.B.:
ld: warning: in /sw/lib/libjpeg.dylib, file was built for i386 which is not the architecture being linked (x86_64)
Als Compiler wird c++-4.2 benutzt, was mit -dumpmachine "i686-apple-darwin" ausgibt, wenn ich allerdings ohne spezielle Angabe kompiliere, sind die *.o dateien x86_64. (?)
(Das ist doch merkwürdig, ich kenn mich damit nicht wirklich aus, aber i686 klingt irgendwie mehr wie i386 als x86...)
Das lässt sich umgehen mithilfe der angabe von "-arch i386", was zu den Bibliotheken passen würde.
Die makefiles werden mit cmake erstellt und ich denke ich verstehe etwas falsch:
ich dachte:
cmake CMAKE_CXX_COMPILER="anderer compiler" oder CMAKE_CXX_FLAGS="-arch i386" oder OSX_ARCHITECTURES="i386"
würde helfen,
aber das ergebnis ist immer dasselbe.
Die manpage sagt dazu z.b.:
CMAKE_SYSTEM_PROCESSOR
The name of the CPU CMake is building for.
On systems that support uname, this variable is set to the out-
put of uname -p, on windows it is set to the value of the envi-
ronment variable PROCESSOR_ARCHITECTURE
[Edit] uname -p gibt auch i386 aus.
Dann wäre es doch sinnvoll, auch mit -arch i386 zu kompilieren.
Wie auch immer, wie mache ich es richtig? es müsste doch eigentlich so funktionieren.
Vielen Dank im voraus!
rüdiger schrieb:
Normalerweise arbeitet man mit einer Codeverwaltung ala Git. Aber wenn ihr wirklich gemeinsam in einem Editor arbeiten wollte, dann schaut euch mal Gobby an (gibt auch einen Emacs Mode dafür).
Naja so was änliches, nur halt, wo man direkt compilen kann, wäre sehr toll.
Debugger ist wichtig schrieb:
SeppJ schrieb:
Editor und Kommandozeile. Da lernt man als Anfänger viel schneller, was im Hintergrund abgeht. Das wird später extrem wichtig, wenn es mal Probleme mit einem Build gibt. So komplex sind Anfangerprogramme nicht, dass eine IDE nennenswerte Vorteile hätte, eher bringt die IDE unnötige Zusatzkomplexität.
Der Editor sollte natürlich einigermaßen gut sein, Syntaxhighlighting, Klammernprüfung, Einrückung, evtl auch Autovervollstandigung sind schon ganz angenehm und helfen viele dumme Fehler zu vermeiden (hier im Forum kommen immer mal wieder Fragen, wo die Leute einfach nicht richtig geklammert haben!).
Leider gehört zum Programmieren auch dazu, Debuggen zu lernen und hier mit dem Konsolenfrontend von gdb zu arbeiten ist für Einsteiger ne Zumutung.
Ja, das normale Konsoleninterface bietet (imo) einfach zu wenig Übersicht. Es gibt aber graphische Frontends für GDB die unabhängig von einer spezifischen IDE sind. http://www.kdbg.org/ fand ich zB ganz gut. Selbst wenn man auf die Konsole steht kann man mit cgdb ein curses basiertes Frontend benutzen.
Ich persönlich benutze mittlerweile hauptsächlich das in Emacs integrierte GDB Frontend.
pyhax schrieb:
Debugger ist wichtig schrieb:
Beim Debugger von Eclipse oder VS (Windows only) kann man sich das sparen.
Sobald der Debugger gestartet und der Breakpoint gesetzt wurde, bieten beide IDEs eine Variablenansicht an, die dann alle Änderungen schön anzeigen.
Und wie funktioniert das mit eigene Typen?
Der GDB kann selbst geschriebene Prettyprinter. Damit kannst du die interne Struktur schön anzeigen lassen und musst dich nicht durch irgend welche Pointer hangeln.
Hallöchen
ich benötige eure Hilfe. Ich versuche schon seit einiger Zeit das Plugin Together zu installieren. Hierzu haben wir von der UNI ein zip file und die passende lizens erhalten.
Wenn ich jetzt aber das Plugin Installieren möchte bekomme ich folgenden fehlermeldung:
Cannot complete the install because one or more required items could not be found.
Software being installed: Together extensions for Eclipse MDT UML2 Tools (optional) 1.2.3.v20101117-1439 (com.borland.together.uml2tools.feature.group 1.2.3.v20101117-1439)
Missing requirement: Together Enhanced Rich Text Editing 8.2.3.v20101117-1439 (com.borland.csf.richtext.feature.group 8.2.3.v20101117-1439) requires 'org.eclipse.sdk.feature.group [3.6.0,4.0.0)' but it could not be found
Cannot satisfy dependency:
From: Together extensions for Eclipse MDT UML2 Tools (optional) 1.2.3.v20101117-1439 (com.borland.together.uml2tools.feature.group 1.2.3.v20101117-1439)
To: com.borland.uml2.feature.group [1.2.3.v20101117-1439]
Cannot satisfy dependency:
From: Together UML 2.2 Diagrams (Eclipse MDT) 1.2.3.v20101117-1439 (com.borland.uml2.feature.group 1.2.3.v20101117-1439)
To: com.borland.csf.richtext.feature.group 8.2.0
Als Eclipse habe ich eine Indigo version.
kann mir jemand weiterhelfen???
Typischerweise wird nach dem Builden nichts automatisch ausgeführt.
Du musst dein Programm entweder gleich in Eclipse starten (mit oder ohne Debugger) oder es auf der Kommandozeile ausführen.
Ein paar Grundlagen: Bibliotheken werden unter Linux nicht im aktuellen oder im Executableverzeichnis gesucht! Das aktuelle Verzeichnis oder das Verzeichnis der Exe haben keinerlei Sonderbedeutung (außer dass relative Pfadangaben beim aktuellen Verzeichnis losgehen). Du denkst an Windows und sieh, zu was das führt:
Google: windows dll load hijacking
Der LD_LIBRARY_PATH wird zwar oft als falscher Ansatz zur Lösung von Suchpfadproblemen dargestellt, ist bei dem von dir beschriebenen Fall jedoch das richtige Mittel. Sei dir sicher, dass du ihn auch korrekt gesetzt hast. In einem Bashscript musst du Variablen beispielsweise mit export kennzeichnen, damit sie auch nach Beenden des Scripts noch gültig sind. Mach mal ein echo auf den Suchpfad, bevor du ein ldd auf die Datei machst.
Ihr könntet auch beim Linken der Anwendung einen rpath angeben ( gcc -R /pfad/zur/lib ... ). Das ist dann ein Suchpfad speziell nur für diese Anwendung.
Oder ihr installiert die Bibliotheken einfach in den Standardsuchpfaden . Wenn ihr die selber geschrieben habt, dann solltet ihr euch doch wohl auch selber vertrauen können.
