Softwareprojekt: Strukturierung, Packages & Headerfragen

[Gumble]

Aaalso, hät da mal wieder einige Fragen:
Im Großen und Ganzen handelt sich um 3 größere Module - EVA-prinzip halt. Frage mich nun wie man das am schönsten Gruppiert und strukturiert.
Als erstes gibt es 2 Dateien (+ dazugehörige Header) die elementare Datentypen beschreiben (die überall gebraucht werden). Dann gibts die Eingabe: die liest aus nem Ini-File Werte ein und speichert diese in einem dicken Objekt. In der Verarbeitung werd aus diesem Objekt gelesen und 2dimensionale Felder angelegt (x/y Koordinaten) die die Ausgaben (GUI) kriegt. Die GUI hat außerdem auch noch Zugriff auf das "dicke Objekt" mit allen Daten. Hoff das ging noch zu verstehen - ein Diagramm wär wohl schöner.
Jetzt hab ich leider wenig Ahnung vom "schön" Programmieren. Habe gelesen das Packages mit einfachen Ordner und Namespaces realisiert werden. Wie sollen dann die Pfadangaben der include-dateien aussehn? Macht man es relativ (z.B. "../../include/common/common.h") oder mittels Path < >? Bei zweiterem muss man ja jeden einzelnen Ordner im Projekt (VC7) einbinden!? Ist halt plöd, wenn man die Files mit einer anderen Entwicklungsumgebung angucken möchte...
braucht man dann noch namespaces, wenn man den quellcode schon in verschiedenen Ordner sortiert?
Gibts im Netz irgendwo ein gutes Beispiel, wo ein (kleines überschaubares) Softwareprojekt, am besten vom Beginn an, komplett entwickelt wird?
Danke schonmal für die Hilfe?

[davie]

relative und absolute pfadangaben sollten allerdings unter "" kein problem darstellen, bei normalen compilern. allerdings sind die verzeichnisse, in denen die so eingebundenen headern gesucht werden sollen, von der implementation abhängig (implementation-defined).
wenn allerdings nach diesen regeln in einem pfad unter "" keine passende datei gefunden wird, wird die include direktive automatisch als ein #include<...> aufgefasst. d.h.

#include "iostream"
using namespace std;

int main () { cout << "Hello World\n"; }

//bewirkt dasselbe wie mit #include <iostream>

wo allerdings sonst noch gesucht wird, hängt von der implementierung ab. die einzige auflage:
im pfad unter "" darf kein " oder newline vorkommen, bei <> kein > oder newline.
im normalfall sollten relative und absolute pfadangaben aber wie gesagt kein problem darstellen.

namespaces solltest du auf jeden fall benutzen, denn verzeichnisse schützen nicht vor namenszusammenstößen.

[DrGreenthumb]

Also absolute Pfadangaben sind nun ganz daneben.

Ich meine auch mal gelesen zu haben, man soll relative Pfadangaben vermeiden, wenn man erst eine Ebene runter muss, also etwas wie "../../bla.h". Allerdings sehe ich da nicht wirklich ein Problem, ausser wenn man auf einmal auf die Idee kommt, seine Verzeichnisse umzustrukturieren.

[HumeSikkins]

Hallo,
also ich bevorzuge ein Projekthauptverzeichnis, das ich im Makefile dem Compiler per entsprechendem Flag bekannt gebe (-I). Der Code inkludiert dann relativ zu diesem.

#include <fred.h>         // liegt im Projekthauptverzeichnis
#include <details/bar.h>  // liegt im Verzeichnis Projekthauptverzeichnis/details
...

[RHBaum]

handelt sich um 3 größere Module - EVA-prinzip halt

Dann wuerd ich auch "richtige" Module draus machen, also binaere Unabhaengigkeit zumindest eigenstaendige Libs(lib / .a .so ), wenn nicht gar dlls (unter windows)

Ich organisiere meine Ressourcen meist nach folgendem Schema

-Projektname
    -sourcen
        -ProjektModuleELib
        -ProjektModuleVLib
        -ProjektModuleALib
    -temp
    -bin
    -shared

Naja, handelt man sich meist Kritik von den Windows programmierern ein:

DIe Projecte bekommen alle als Zusaetzlichen include Pfad den Pfad aufs Source Verzeichnis (am besten per "/.." also relativ), und als zusaetzichen Lib Pfad, den Pfad zum bin verzeichniss (auch relativ)
WIchtig:
Unter windows stelle ich das Project immer so ein, das die kompilierte Datei die Konfiguration anzeigt.
also sowas wie ProjektModuleE.U.dbg.lib -> Unicode Debug Config
und die erzeugten dateien werden gleich ins bin verzeichnis erstellt
Im Abhaengigen module bind ich dann die benoetigte Lib ein, also fuer unicode debug dann die ProjektModuleE.U.dbg.lib
Die header im Quelltext kannst dann mit <ProjektModuleVLib/datatypes.h> einbinden

Ist zwar beim anlegen neuer projekte erst mal ne tuechtige Mehrerei ... kann man aber automatisieren. Bei groesseren Projekten und vor allen wenn man mit CVS arbeitet, lohnt sich das schon ...

Ciao ...

[Gumble]

Danke! Hat mir echt was geholfen. Im Makefile, bzw Projekteigenschaften werd ich nur das "project-root"-Verzeichnis eintragen und die includes alle relativ darauf machen.
@RHBaum
mit libs/dlls hab ich bisher noch nicht gearbeitet. Momentan wird einfach nur eine Exe-erstellt (auf MFC-Basis) - du schickst also die "Teilkompilate" ins bin-Verzeichnis? Wird dann eine exe auch automatisch erstellt?
Lohnt es sich eigentlich ein Handbuch (wenn ja welches) fürs VS.net zu kaufen?
Und wie ist es nochmal mit dem Makefile? kann man sich das von VS irgendwie anzeigen lassen? So in guter alter gcc/unix manier?

[RHBaum]

du schickst also die "Teilkompilate" ins bin-Verzeichnis?

Du meinst die obj dateien ?
Noe, die kommen ins Temp verzeichnis ... mit denen faengt ja normalerweise keiner mehr was an ....
ins bin verzeichniss zu ich nur das, womit ich meine Umwelt begluecken will, also weiterverwendbare module, exe, dll, lib (unter windows)

Wird dann eine exe auch automatisch erstellt?

Jo , Abhaengigkeitsmanagement ist ne wichtige Sache, auch schon beim design ... Aber prinzipiell unterstuetzt dich da make. DU kannst halt Abhaengigkeiten definieren ...
Unter VC (ich hab die 6.0) geht das auch gut. ist alles richtig configuriert, stellst dein exe-project als aktives project ein, wahlst die Config aus (Unicode debug, z.b.) und der compiler (oder besser nmake in dem fall) schaut selbststaendig bei welchen abhaengigen libs / dlls sich was gaendert hat, und compiliert alles bei bedarf neu ....

Ciao ...