user6666
Anmeldungsdatum: 26. Juli 2014
Beiträge: 12
|
Hallo, ich habe vor ein bisschen mit c++ zu experimentieren. Als Programmtool habe ich mich für Code::Blocks entschieden. Ich probiere zur Zeit mit den vielen Beispielprogrammen herum, die man so im Netz findet. Und nun zu meinem Problem oder besser zu meiner Frage: Ich habe mir ein kleines Beispielprogramm aus dem Netz kopiert, welches ein Fenster erzeugt. Beim compilieren habe ich aber Probleme: ich habe im Code::Blocks bereits alle Verzeichnisse für die lib's nachgepflegt und trotzdem erhalte ich immer noch Fehlermeldungen: g++ -Wall -g -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/harfbuzz -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/include/gtk-3.0 -I/usr/include/gtk-3.0/gdk -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -c /fenster.cpp -o /fenster.o
g++ -o /fenster /fenster.o
/fenster.o: In Funktion `main':
/fenster.cpp:7: Nicht definierter Verweis auf `gtk_init'
/fenster.cpp:9: Nicht definierter Verweis auf `gtk_window_new'
/fenster.cpp:10: Nicht definierter Verweis auf `gtk_label_new'
/fenster.cpp:15: Nicht definierter Verweis auf `gtk_container_get_type'
/fenster.cpp:15: Nicht definierter Verweis auf `g_type_check_instance_cast'
/fenster.cpp:15: Nicht definierter Verweis auf `gtk_container_add'
/fenster.cpp:17: Nicht definierter Verweis auf `gtk_widget_show_all'
/fenster.cpp:20: Nicht definierter Verweis auf `gtk_main'
collect2: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 0 second(s))
8 error(s), 0 warning(s) (0 minute(s), 0 second(s)) Wenn ich aber im Terminal mit g++ -Wall -g fenster.cpp -o fenster pkg-config --cflags --libs gtk+-2.0 compiliere, wird eine Datei erzeugt, die ausführbar ist und das Fenster anzeigt. Warum ist dies mit Code::Blocks nicht genauso möglich? Schon mal vielen Dank für Eure Hilfe. LG
User6666
|
microft
Anmeldungsdatum: 6. August 2009
Beiträge: 454
Wohnort: Norddeutschland
|
Das Ding erzeugt offensichtlich eine falsche Compilerzeile. Aber warum machst du dir darum einen Kopf? Du hast doch raus gekriegt wie es richtig geht. cu
|
user6666
(Themenstarter)
Anmeldungsdatum: 26. Juli 2014
Beiträge: 12
|
Ich möchte zum programmierern Code::Blocks nutzen und somit auch seine Funktionalität. Wenn ich von dem Tool mein Programm testen lasse und es mir mitteilt, dass ich Fehler gemacht habe, reagiere ich darauf. Aber bei dem Programm sind ja scheinbar keine Programmierfehler enthalten, weil es sich ja compilieren lässt. Warum werden mir dann Fehler angezeigt. Solte ich ein anderes Tool als Code::Blocks verwenden?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13892
|
user6666 schrieb: Aber bei dem Programm sind ja scheinbar keine Programmierfehler enthalten, weil es sich ja compilieren lässt. Warum werden mir dann Fehler angezeigt.
Es werden Fehler beim Linken sein. Du hast die richtige "Reihenfolge" evtl. nicht eingehalten.
|
user6666
(Themenstarter)
Anmeldungsdatum: 26. Juli 2014
Beiträge: 12
|
lubux schrieb: user6666 schrieb: Aber bei dem Programm sind ja scheinbar keine Programmierfehler enthalten, weil es sich ja compilieren lässt. Warum werden mir dann Fehler angezeigt.
Es werden Fehler beim Linken sein. Du hast die richtige "Reihenfolge" evtl. nicht eingehalten.
Wie finde ich denn heraus, was die richtige Riehenfolge ist? hier mal der Code um den es geht:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23 | #include <gtk/gtk.h> /* GTK einbinden */
int main( int argc, char *argv[]) /* Normale main Funktion */
{
GtkWidget *window, *label; /* Das Fensterobjekt - Ja, GTK ist objektorientiert */
gtk_init(&argc, &argv); /* gtk system starten */
window = gtk_window_new(GTK_WINDOW_TOPLEVEL); /* Toplevel Window erstellen */
label = gtk_label_new("Hallo, Welt"); /* Das Static Widget fuer Text in GTK */
/* Gtk arbeitet ausschliesslich mit Sizern anstatt pixelgenauer Positionierung.
Ein GtkWindow ist ein Container, der genau ein Kind haben kann (GtkBin).
Der kann aber wieder ein Container wie GtkVBox, GtkTable, etc sein. */
gtk_container_add(GTK_CONTAINER(window), label);
gtk_widget_show_all(window); /* Das Fenster und alle Kindobjekte anzeigen */
gtk_main(); /* Den Event Loop starten */
return 0;
}
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13892
|
user6666 schrieb: lubux schrieb: user6666 schrieb: Aber bei dem Programm sind ja scheinbar keine Programmierfehler enthalten, weil es sich ja compilieren lässt. Warum werden mir dann Fehler angezeigt.
Es werden Fehler beim Linken sein. Du hast die richtige "Reihenfolge" evtl. nicht eingehalten.
Wie finde ich denn heraus, was die richtige Riehenfolge ist? hier mal der Code um den es geht:
Ich denke, das hat weniger mit dem Code zu tun als z. B. mit einer Makefile-Datei bzw. den Eingaben mit der Kommandozeile.
|
user6666
(Themenstarter)
Anmeldungsdatum: 26. Juli 2014
Beiträge: 12
|
microft schrieb: Das Ding erzeugt offensichtlich eine falsche Compilerzeile. Aber warum machst du dir darum einen Kopf? Du hast doch raus gekriegt wie es richtig geht. cu
Gibt es denn hier noch andere Anwender, die "Fenster" programmieren? Wie macht Ihr das? Benutzt Ihr kein Tool um Euer Programm zu überprüfen, bzw. das Tool in dem IDE? Ich möchte doch mit dem IDE arbeiten und nicht "umständlich" nach vermeindlicher Fertigstellung ins Terminal wechseln müssen. Gibt es noch andere Ideen?
|
microft
Anmeldungsdatum: 6. August 2009
Beiträge: 454
Wohnort: Norddeutschland
|
Hallo ich programmiere nicht nur Fenster sondern durchaus ein wenig mehr 😉 siehe Signatur Grundsätzlich brauchst du keine IDE. Ein Editor, der Programmieren unterstützt, reicht z.B. Bluefish oder Geany. Zum übersetzen nimmst du dann die schon bekannte Compilerzeile. Die IDE prüft übrigens garnix, das tut der Compiler. Die IDE zeigt dir dessen Output nur "hübsch" an. In den Terminal wechseln musst du sowieso, spätestens wenn es ans debuggen geht, denn nur dort siehst du das gemecker vom GTK, deine asserts und deine Debugmeldungen. Apropos GTK meckert gerne und viel, auch wenn das Programm vermeintlich läuft, nimm diese Meldungen ernst. Das erspart dir Zahnabdrücke in der Tischkante. Was du aber unbedingt brachst ist das Paket devhelp. cu
|
Lysander
Anmeldungsdatum: 30. Juli 2008
Beiträge: 2669
Wohnort: Hamburg
|
microft schrieb: Die IDE prüft übrigens garnix, das tut der Compiler.
Das ist dann aber eine ziemlich schlechte IDE 😉 Zugegebener Maßen ist das bei Sprachen wie C oder C++ auch deutlich schwieriger als bei Java oder etwa C# (also Sprachen, die in einen Byte-Code kompilieren, der explizit Meta-Informtionen mitnimmt), aber z.B. KDevelop beweist, dass man auch bei C++ (neuerdings über clang) durchaus syntaktische und semantische Prüfungen vor dem eigentlichen Kompilieren in Echtzeit durchführen kann! In statisch typisierten Sprachen würde ich anders auch nicht mehr entwickeln wollen ☺ @user6666: Es ist definitiv ein Linker-Problem. Du scheinst eine benötigte Lib nicht anzugeben. Wie man das in Deiner IDE einstellt, weiß ich nicht. Aber da gibt es sicherlich ein Handbuch. Du solltest beide Aufrufe mal exakt miteinander vergleichen hinsichtlich der Linker-Optionen. Irgend eine wird wohl beim Aufruf der IDE fehlen!
|
microft
Anmeldungsdatum: 6. August 2009
Beiträge: 454
Wohnort: Norddeutschland
|
Lysander schrieb: Das ist dann aber eine ziemlich schlechte IDE 😉 Zugegebener Maßen ist das bei Sprachen wie C oder C++ auch deutlich schwieriger als bei Java oder etwa C# (also Sprachen, die in einen Byte-Code kompilieren, der explizit Meta-Informtionen mitnimmt), aber z.B. KDevelop beweist, dass man auch bei C++ (neuerdings über clang) durchaus syntaktische und semantische Prüfungen vor dem eigentlichen Kompilieren in Echtzeit durchführen kann! In statisch typisierten Sprachen würde ich anders auch nicht mehr entwickeln wollen ☺
Warum soll ich für ein und denselben Job, nämlich die Syntaxkontrolle, zwei verschiedene Programme nutzen. Die sich dann im schlimmsten Fall noch darüber streiten wer den nun richtig interpretiert. Zu Zeiten als ein Compilerlauf noch nn Minuten oder mehr dauerte, waren Tools wie lind ne feine Sache. Heute braucht der Compiler 2 Sekunden um 10000 Zeilen zu Prüfen und zu übersetzen. Da ist sowas einfach überflüssig. Noch dazu da es im Zweifelsfall sowieso heißt "der Compiler hat immer recht". Als ich das letzte mal mit KDevelop gearbeitet (schon eine weile her) habe hat der im Hintergrund mit dem Compiler geprüft und das Ergebniss dann ganz "hübsch" im Editorfenster angezeigt. cu
|
user6666
(Themenstarter)
Anmeldungsdatum: 26. Juli 2014
Beiträge: 12
|
Danke für die Hilfe. Es scheint wirklich an den Parametern bzw. am Aufruf in dem IDE zu liegen. Bei Code::Blocks habe ich es nicht hinbekommen. Aber der Tip mit Geany war gut. Hier habe ich die Parameter so eingestellt, das ich mit diesem Tool auch fehlerfrei compilieren kann und direkt eine ausführbare Datei erzeugt wird. Vielleicht findet ja jemand noch die richtigen Einstellungen bei Code::Blocks, ich gebe hier zumindest auf. Nochmals Danke an alle.
|
Lysander
Anmeldungsdatum: 30. Juli 2008
Beiträge: 2669
Wohnort: Hamburg
|
microft schrieb: Warum soll ich für ein und denselben Job, nämlich die Syntaxkontrolle, zwei verschiedene Programme nutzen.
Solange es komfortabel ist, spielt es doch keine Rolle, wer das prüft!
Die sich dann im schlimmsten Fall noch darüber streiten wer den nun richtig interpretiert.
In diesem Falle wäre die IDE unbrauchbar - mir ist das noch nicht untergekommen! (Zumal die Prüfungen ja bei vielen IDEs auch mit denselben Komponenten durchgeführt werden, die später für das tatsächliche Kompilieren verwendet werden) Im übrigen geht es auch nicht nur um reine Syntaxprüfung; semantische Aspekte und statische Code-Analyse spielen dabei auch eine Rolle. Und genau da bieten IDEs imho den größten Mehrwert (ja ok, Debugging und eine Unit-Testing Ansicht sind natürlich auch ne feine Sache 😉 ). Und dies ist ja gerade insbesondere bei statisch und stark typisierten Sprachen enorm wichtig und vor allem auch leichter umsetzbar, als bei dynamisch typisierten oder auch schwach typisierten Sprachen (a la C oder C++). Wobei sich dank C++11 und C++14 sowie eben dem clang-Projekt bei C++ einiges tut.
|