4. vorhandenes ANSI C Projekt

vorhandenes ANSI C Projekt

  • S

    Hallo alle miteinander.

    Beschäftige mich grad mit Partikelschwarmoptimierung und habe nun von einem Wissenschaftler ein Programm gefunden, welches in ANSI C geschrieben ist und öffentlich verfügbar ist. Ich wollte dieses nun mal ausprobieren. Da ich leider keine Ahnung von C/C++ habe, hab ich es leider nicht geschafft es zum laufen zu bringen. Habe Visual Studio 2008 und habe mir schon Dev-C++ installiert, aber auch mit google hab ich es nicht geschafft es zum rennen zu bekommen.

    Quelle des Programms: http://clerc.maurice.free.fr/pso/pso_tsp/pso_tsp_ansi_c.zip
    Seite: http://clerc.maurice.free.fr/pso/

    Habe es mir runtergeladen und versucht mit Visual Studio und der Win-32 Konsolenanwendung ein Projekt zu erstellen und dann den Code und die anderen Dateien eingefügt, gibt mir leider massig Fehlermeldungen zurück. In Dev-C++ habe ich es auch probiert.

    Möchte das Programm einfach ausführen und gegebenfalls Parameter mal verändern. Falls ein anderes Programm besser hierfür geeignet ist, wäre ich für jeden Tipp dankbar. (Benutze Win 7 prof 64bit)

    Eventuell hat einer einen link, wo beschrieben ist, wie man sowas macht. Google hat mir bei diesem Problem leider nicht weitergeholfen (oder ich war zu doof die richtigen Begriffe einzugeben...).

    Gruß

    0
  • ?

    Moin,

    kannst mal folgendes Versuchen: Code::Blocks installieren, alle Dateien aus dem Archiv entpacken, main.c öffnen, Strg+F9 zum compilieren. Erste Fehlermeldung "main.c 145 syscall.h: No such file or directory" anklicken, die Zeile wird mit einem roten Rechteck markiert. Cursor an Zeilenanfang, zwei Backslashes tippen (Zeile auskommentieren). Das gleiche mit der 2 Meldung "global_var.c 59 error: redefinition of `FILE*f_trace'". Oben wieder main.c anwählen, danach Strg+F9.

    Compiliert bei mir, allerdings mit 29 Warnungen... *grusel* Ob das so vermurkst funktioniert musst du selbst ausprobieren...

    0
  • ?

    Ich liebe es wenn die Leute ne Frage stellen und sich dann nie wieder melden! 😡

    0
  • S

    Hi, sry hatte net mehr dran gedacht hier gepostet zu haben, erst nach deiner zweiten Antwort ne mail bekommen. Mit auskommentieren hatte ich es auch versucht, aber hat auch bei mir so viele Fehler geworfen. Hab absolut ka, wie der das zum rennen gebracht hat und das deprimierende ist, in seinem Buch steht, dass diese Beispiele keine Probleme beim kompilieren geben sollen. Hab nun nochmal nen Bekannten gefragt, ob er das zum laufen bekommt.

    Trotzdem vielen Dank für deinen Versuch und deine Mühe. Falls ich es noch zum laufen bekomme, sag ich mal Bescheid, wie ich es geschafft hab, falls es jm interessiert.

    VG

    0
  • ?

    Moin,

    passst schon. Wenn du obige Anleitung befolgst gibts jede Menge Warnungen, die zeugen zwar von schlechtem Programmierstil, hindern den Compiler aber nicht an seiner Arbeit (d.h. es wird eine .exe erzeugt). Fehler hingegen sind fatal und führen zum Abbruch des Compiliervorgangs.

    0
  • ?

    PS: Und was zum Teufel ist eigentlich "Partikelschwarmoptimierung" für ein Dings?

    0
  • S

    Bin grad an nen paar Papern zu diesem Thema dran, werde es morgen oder am WE nochmals ausprobieren.
    Partikelschwarmoptimierung ist eine Metaheuristik zur Lösung von Optimierungsproblemen. In diesem Programm ist diese Heuristik implementiert und auf das Travelling Sales Man Problem angewendet.

    kurz: Partikelschwärme sind einzelne Partikel(mögliche Lösungen) in einem Lösungsraum, die nun durch Nachbarschaftsbeziehungen und eigene Geschwindigkeit sich in diesem Lösungsraum bewegen und eine optimale (oder bessere als die bisherige) Lösung suchen.

    Hoffe war verständlich, das kurz und knapp zu fassen, fällt mir nen bissl schwer.

    Suche grad ein Diplomarbeitsthema und das klang sehr interessant und ich schaue nun was es schon alles gibt und was ich dann machen könnte.

    Gruß

    0
  • ?

    Hoffe war verständlich

    Nein... *lach*

    Vom Handlungsreisenden hab ich schon gehört, aber der Rest...

    Lass mal stecken, klingt nach komplizierter Mathematik. 😮

    0
  • ?

    Ach du heilige Scheiße, scheinbar gibt es zwei Leute im Universum, die solchen Blödsinn machen. Zitat:

    #include "global_var.c"

// (...)

#include "display.c"
#include "display_position_TSP.c"
#include "graph_tools.c"
#include "math_add.c"
#include "particle_tools.c"
#include "swarm_tools.c"

// (...)

#include "f_TSP.c"

    😮

    Ansonsten verrät der Einsatz der syscall.h, dass es sich dabei um ein POSIX-Programm handelt, ich bin also nicht sicher, ob das unter Windows so laufen wird. gcc 4.5.1 frisst es hier selbst mit -Wall ohne Warnungen, wenn man erst einmal raus hat, was eigentlich kompiliert werden muss. Allerdings lässt die #includerei von Quellcodedateien natürlich alle Warnglocken schrillen.

    Umso merkwürdiger ist es allerdings, dass sämtliche Codedateien CRLF-Zeilenenden haben - ist das vielleicht zur Benutzung mit Cygwin o.ä. gedacht?

    0
  • ?

    Von Posix hatte mir Google erzählt, aber die Datei scheint nicht gebraucht zu werden, zu mindestens kompiliert es auch ohne...

    Allerdings lässt die #includerei von Quellcodedateien natürlich alle Warnglocken schrillen.

    Anfängerfrage: Warum? 😕

    0
  • ?

    (Sry für Doppelpost, kann als Gast nicht editieren.)

    In CodeBlocks bekomme ich nachdem ich wie oben beschrieben syscall.h und eine doppelte Deklaration auskommentiert habe 29 Warnungen. OS ist XP, Compiler ist MinGW, gcc -v sagt Version 3.4.5, -Wall hab ich in CodeBlocks standardmäßig aktiviert.

    Compiling: ...\pso_tsp_ansi_c\main.c
    In file included from ...\pso_tsp_ansi_c\main.c:156:
    ...\pso_tsp_ansi_c\math_add.h:12:30: warning: no newline at end of file
    In file included from ...\pso_tsp_ansi_c\main.c:157:
    ...\pso_tsp_ansi_c\particle_tools.h:21:81: warning: no newline at end of file
    In file included from ...\pso_tsp_ansi_c\main.c:163:
    ...\pso_tsp_ansi_c\graph_tools.c: In function val graph\_min\_tour(graph)': ...\\pso\_tsp\_ansi\_c\\graph\_tools.c:133: warning: converting to \int' from `double'
    ...\pso_tsp_ansi_c\graph_tools.c:150: warning: converting to `int' from `double'
    ...\pso_tsp_ansi_c\graph_tools.c:152: warning: converting to `int' from `double'
    In file included from ...\pso_tsp_ansi_c\main.c:164:
    ...\pso_tsp_ansi_c\math_add.c: In function int alea(int, int)': ...\\pso\_tsp\_ansi\_c\\math\_add.c:12: warning: converting to \int' from `float'
    ...\pso_tsp_ansi_c\math_add.c:16: warning: converting to `int' from `float'
    ...\pso_tsp_ansi_c\math_add.c: In function float alea_float(float, float)': ...\\pso\_tsp\_ansi\_c\\math\_add.c:64: warning: converting to \int' from `float'
    In file included from ...\pso_tsp_ansi_c\main.c:164:
    ...\pso_tsp_ansi_c\math_add.c:244:1: warning: no newline at end of file
    In file included from ...\pso_tsp_ansi_c\main.c:165:
    ...\pso_tsp_ansi_c\particle_tools.c: In function velocity coeff\_times\_vel(velocity, double, int, int)': ...\\pso\_tsp\_ansi\_c\\particle\_tools.c:646: warning: converting to \int' from `double'
    ...\pso_tsp_ansi_c\particle_tools.c:659: warning: converting to `int' from `double'
    ...\pso_tsp_ansi_c\particle_tools.c: In function particle move_towards(particle, particle, coeff, int, int, int, int, int)': ...\\pso\_tsp\_ansi\_c\\particle\_tools.c:1178: warning: converting to \int' from `double'
    ...\pso_tsp_ansi_c\particle_tools.c:1179: warning: converting to `int' from `double'
    ...\pso_tsp_ansi_c\particle_tools.c:1180: warning: converting to `int' from `float'
    ...\pso_tsp_ansi_c\particle_tools.c:1207: warning: converting to `int' from `double'
    ...\pso_tsp_ansi_c\particle_tools.c:1239: warning: converting to `int' from `double'
    ...\pso_tsp_ansi_c\particle_tools.c:1240: warning: converting to `int' from `double'
    ...\pso_tsp_ansi_c\particle_tools.c:1241: warning: converting to `int' from `float'
    ...\pso_tsp_ansi_c\particle_tools.c:1256: warning: converting to `int' from `double'
    ...\pso_tsp_ansi_c\particle_tools.c:1257: warning: converting to `int' from `double'
    ...\pso_tsp_ansi_c\particle_tools.c:1258: warning: converting to `int' from `float'
    ...\pso_tsp_ansi_c\particle_tools.c: In function velocity vel\_plus\_vel(velocity, velocity, int, int)': ...\\pso\_tsp\_ansi\_c\\particle\_tools.c:1748: warning: converting to \int' from `float'
    In file included from ...\pso_tsp_ansi_c\main.c:166:
    ...\pso_tsp_ansi_c\swarm_tools.c: In function swarm init_swarm(int, graph, int)': ...\\pso\_tsp\_ansi\_c\\swarm\_tools.c:68: warning: converting to \int' from `float'
    ...\pso_tsp_ansi_c\swarm_tools.c:83: warning: converting to `int' from `float'
    ...\pso_tsp_ansi_c\swarm_tools.c:115: warning: converting to `int' from `float'
    ...\pso_tsp_ansi_c\main.c: In function int main()': ...\\pso\_tsp\_ansi_c\\main.c:283: warning: converting to \int' from `float'
    ...\pso_tsp_ansi_c\main.c:314: warning: converting to `int' from `float'
    ...\pso_tsp_ansi_c\main.c:322: warning: converting to `int' from `float'
    ...\pso_tsp_ansi_c\main.c:472: warning: converting to `int' from `double'
    Linking console executable: ...\pso_tsp_ansi_c\main.exe
    Process terminated with status 0 (0 minutes, 6 seconds)
    0 errors, 29 warnings

    0

  • Bingo, jetzt hast du das vorausgesagte Ergebnis selbst erzeugt; und, fliegen deine Schwärme jetzt?

    0
  • ?

    Ich bin nicht der Fragesteller (Irren ist menschlich 😉 )...

    0
  • ?

    Gast4585945874 schrieb:

    Von Posix hatte mir Google erzählt, aber die Datei scheint nicht gebraucht zu werden, zu mindestens kompiliert es auch ohne...

    Allerdings lässt die #includerei von Quellcodedateien natürlich alle Warnglocken schrillen.

    Anfängerfrage: Warum? 😕

    Der übliche Ablauf der Kompilation eines C-Programms ist hier ganz gut veranschaulicht:

    http://www.eng.hawaii.edu/Tutor/Make/1-3.html

    Jede Toolchain der Welt ist darauf ausgelegt, dass das so gemacht wird. Jeder C-Programmierer der Welt, der nicht absoluter Anfänger oder völlig verrückt ist, erwartet, dass Code so funktioniert. Quellcodedateien werden kompiliert, Header können an verschiedenen Stellen eingebunden werden, das ist die Konvention.

    Weicht man davon ab, läuft man in eine ganze Reihe von Problemen. Das erste und wichtigste ist, dass es einen Wildwuchs befördert, durch den das Projekt sehr schnell höchst unübersichtlich wird. Du hast eine main.c, die modul1.c und modul2.c #includet, von denen modul1.c noch untermodul1.c, untermodul3.c und untermodul6.c einbindet, modul2.c dagegen untermodul4.c und untermodul5.c (untermodul2.c wurde überflüssig und entfernt). Wenn dann eine Forwärtsdeklaration notwendig wird, wird diese zunächst über die ganzen #includes geschrieben (oder auch dazwischen), bis jemand das Konzept von Headerdateien erklärt und etwa anderthalb Headerdateien zusammengehackt und oben davor geschrieben werden. Solche Änderungen dauern zunehmend länger, weil die Zusammenhänge unklar sind - modul2.c verlässt sich beispielsweise darauf, dass modul1.c untermodul3.c einbindet, weil darin eine bestimmte Funktion definiert wird, so dass untermodul3.c aus modul1.c auch dann nicht entfernt wird, wenn modul1.c diese eigentlich gar nicht mehr benötigt.

    Wenn der ursprüngliche Coder dann lernt, wie ordentliche Projektorganisation eigentlich gemacht wird, endet man mit einem Projekt, das 30 Quellcodedateien hat, von denen fünf einzeln kompiliert werden müssen und jeweils einen Baum von ge#includeten Quellcodedateien, die nicht einzeln kompiliert werden dürfen bzw. können hinter sich herziehen. Einige Jahre später muss das ganze von Grund auf neu geschrieben werden, weil sich keine Sau mehr durch das Dickicht durchfindet.

    Es ist wichtig zu verstehen, dass Programmierung sich in erster Linie nicht darum dreht, den Computer dazu zu überreden, etwas zu tun, sondern um Daten- und Projektorganisation.

    Zusätzlich läuft man an bestimmten Stellen in technisch sinnloses Verhalten. Beispielsweise ist es bei statischen Bibliotheken üblich, dass nur die Übersetzungseinheiten an das benutzende Programm gelinkt werden, die dieses auch benutzt. Hat man jetzt bei der Kompilation alles in einem großen Monolithen verpackt, ist eine sinnvolle Auswahl natürlich nicht möglich. Auch wird es einem Buildsystem durch solche Konstrukte unmöglich, nur die Teile neu zu kompilieren, die sich tatsächlich geändert haben, und es kann in einer IDE unmöglich werden, alle zu einem Projekt gehörigen Dateien auch in die Projektstruktur der IDE aufzunehmen, was schon bei einfacher Verwendung der IDE höchst unpraktisch ist, aber beispielsweise in Verbindung mit Versionskontrolle vernünftiges Arbeiten unmöglich macht.

    0
  • ?

    Wow, Danke für die ausführliche Erklärung. 👍 C ist ja eine tolle Sache, aber das ganze "Drumherum" mit Toolchain, make, Objektdateien und Co... *stöhn*

    Und dann greift Anfänger, noch dazu unter Windows, natürlich zur nächstbesten IDE wo es nur Strg+F9 braucht um zu funktionieren und die Grundlagen bleiben auf der Strecke... 🙄

    Da muss ich nochmal ganz genau lesen um deine Ausführungen zu verstehen. 😮

    0
Anmelden zum Antworten