Sortierung der Projektfiles

[Namenloser324]

Hi,

wie sortiert ihr eure Projektdateien? Alle in einem Folder (+ separates für cpp) wird gerade zu unübersichtlich bei mir, bräuchte mal Anregungen^^

[DarkShadow44]

Naürlich mit OpenGL. Oder warum bist du sonst in diesem Forum ?
Ich habe für jede Projektmappe einen extra Ordner. In diesem dann Unterordner die jeweils ein Projekt einthalten. Was gibts da groß für Methoden der Sortierung ?

[volkard]

Namenloser324 schrieb:

Hi,
wie sortiert ihr eure Projektdateien? Alle in einem Folder (+ separates für cpp) wird gerade zu unübersichtlich bei mir, bräuchte mal Anregungen^^

Es gibt Banausen, die *.h(pp) und *.cpp in getrennte Verteichnisse stopfigen.
Der Sinn dessen ist mir nicht klar. Es ist ja nicht so, daß Headers noch wesentlich stabiler wären, weil da lauter aktiver Template-Code reinkommt.

Ich trenne nach Sinnzusammenhang irgendwie. Zum Beispiel zuerst (gar kein typisches Game)
Projektname //Wie grafische Anwendung, Klickibunti
test //Konsoleanwendung zum Erforschen, Testen, die ist fast immer aktiv
abc //hier liegt die Programmlogik, von der Oberfläche getrennt
ulib //universelle lib, Projektübergreifend

Und wenn was zu fett wird oder auch so einfach danach schreit, gib's Abspaltungen, vielleicht ulib/containers, Projektname/helpfiles…

Aber ich trenne erst, wenns ungetrennt nervt, also reichlich spät.

[Nathan]

volkard schrieb:

[
Es gibt Banausen, die *.h(pp) und *.cpp in getrennte Verteichnisse stopfigen.
Der Sinn dessen ist mir nicht klar. Es ist ja nicht so, daß Headers noch wesentlich stabiler wären, weil da lauter aktiver Template-Code reinkommt.

Wenn man eine Bibliothek schreibt, muss man nur den Header und lib-Ordner freigeben, denn den Source braucht der User nicht. So muss man da nicht manuell durchgehen und die Sourcedateien löschen.

[rapso]

Nathan schrieb:

volkard schrieb:

[
Es gibt Banausen, die *.h(pp) und *.cpp in getrennte Verteichnisse stopfigen.
Der Sinn dessen ist mir nicht klar. Es ist ja nicht so, daß Headers noch wesentlich stabiler wären, weil da lauter aktiver Template-Code reinkommt.

Wenn man eine Bibliothek schreibt, muss man nur den Header und lib-Ordner freigeben, denn den Source braucht der User nicht. So muss man da nicht manuell durchgehen und die Sourcedateien löschen.

wenn man eine lib schreibt, macht man sicherlich mehr als einmal releases und da waere es nicht gerade ruhmreich fuer den entwickler wenn er monkey arbeit mehr als einmal macht statt einmal ein script zu schreiben um den lib build zu automatisieren.
und dann ist es egal wo die hpp sind.

[hustbaer]

@rapso
Willst du jedes neue öffentliche .hpp File manuell in das Skript eintragen?
Oder hast du nie LIBs mit privaten .hpp Files?

Gerade aus dem Grund weil die Dinger vom Build Skript automatisch rumkopiert werden sollen liegen die öffentlichen .hpp Files bei mir in einem eigenen Verzeichnis.

[rapso]

hustbaer schrieb:

@rapso
Willst du jedes neue öffentliche .hpp File manuell in das Skript eintragen?
Oder hast du nie LIBs mit privaten .hpp Files?

Gerade aus dem Grund weil die Dinger vom Build Skript automatisch rumkopiert werden sollen liegen die öffentlichen .hpp Files bei mir in einem eigenen Verzeichnis.

ich weiss dass es dir klar ist dass es hier allgemein um header vs implementierung ging, nicht um interface-header vs private-header+implementierung.
aber dem trollen zum trotz: ja, bei mir sind interfaces auch in einem verzeichnis und dieses ist, wie der ganze andere source code im selben source verzeichnis. es gibt dennoch keinen split zwischen datei typen, splits gibt es nur nach organisatorischen gesichstpunkten.
und ich mache mir das leben noch einfacher
*.h - interface
*.hpp - private header
*.inl - inline implementation
*.cpp - private implementation

[TyRoXx]

Eine vernünftige Struktur ist:

my-public-lib
  CMakeLists.txt
  *.hpp
  *.cpp
my-private-lib
  CMakeLists.txt
  *.hpp
  *.cpp
tests ...
CMakeLists.txt

Die öffentliche Bibliothek nutzt die private. Zum Ausliefern werden die Header der öffentlichen Bibliothek genommen.

[hustbaer]

rapso schrieb:

ich weiss dass es dir klar ist dass es hier allgemein um header vs implementierung ging, nicht um interface-header vs private-header+implementierung.
aber dem trollen zum trotz:

Hier in diesem Thread - vielleicht. Keine Ahnung worum es in diesem Thread "allgemein" geht. Du hast aber auf einen Beitrag von Nathan geantwortet, und dort hat er ganz klar Libraries angesprochen. Und da ist das mMn. eben ein Thema.
Also wieso jetzt trollen? Wenn dann wirf das bitte Nathan vor. Grmpf.

ja, bei mir sind interfaces auch in einem verzeichnis und dieses ist, wie der ganze andere source code im selben source verzeichnis. es gibt dennoch keinen split zwischen datei typen, splits gibt es nur nach organisatorischen gesichstpunkten.
und ich mache mir das leben noch einfacher
*.h - interface
*.hpp - private header
*.inl - inline implementation
*.cpp - private implementation

OK, so kann man es auch machen. Auf die Idee unterschiedliche Extensions zu verwenden bin ich noch nie gekommen. Finde ich auch nicht sonderlich elegant - und ich stelle es mir nicht sehr übersichtlich vor (wobei ich das natürlich nicht wirklich beurteilen kann, da ich es ja nicht ausprobiert habe). Praktikabel ist es aber sicher - wie gesagt, auf die Idee wäre ich nicht gekommen.

[hustbaer]

TyRoXx schrieb:

Eine vernünftige Struktur ist:
(...)

Die öffentliche Bibliothek nutzt die private. Zum Ausliefern werden die Header der öffentlichen Bibliothek genommen.

Und was machst du mit Implementierungs-Details in der öffentlichen Bibliothek? Den ganzen Inline-Code (Templates, ...) mit ausliefern?
Oder wird der ganze private Inline-Code in die private Bibliothek reingezwängt?

Davon abgesehen finde ich das irgendwie Overkill. Da müsste ich so-gut-wie jede Bibliothek in zwei aufteilen. Ein eigenes Verzeichnis für public Headers ist da doch wesentlich weniger Aufwand.

[Scorcher24]

Namenloser324 schrieb:

Hi,

wie sortiert ihr eure Projektdateien? Alle in einem Folder (+ separates für cpp) wird gerade zu unübersichtlich bei mir, bräuchte mal Anregungen^^

Ein typisches Projektverzeichnis sieht bei mir so aus:

- ProjektName
  - Debug 
  - Release
  - GUI/Assets
  - .obj
  - src
  - lib
  - wizard.py

Ein Überordner mit dem Projektnamen, Debug und Release sind Verzeichnisse in denen jeweils die Debug oder Release Erzeugnisse liegen und eventuelle, externe DLL. In GUI liegt die script datei für die GUI (wxWidgets), bei Spielen heisst der Ordner Assets und da sind dann halt die sprites etc drin, weiter getrennt durch Ordner, falls nötig. In .obj liegen Zwischenprodukte und in src, naja der Sourcecode halt :D.
In lib liegen benötigte 3rd Party Bibliotheken und deren header. Für größere, externe, Libs wie wxWidgets habe ich aber ein globales Verzeichnis das mit globalen Variablen zugänglich ist, wie $(WXDIR) oder $(BOOST).

wizard.py ist ein von mir gebautes script, das Dateien für eine Klasse automatisch erzeugt und include guards sowie Lizenzkommentar generiert.
(wizard.py MyClass -n MyNameSpace -l license.txt als bsp.)

[rapso]

hustbaer schrieb:

rapso schrieb:

ich weiss dass es dir klar ist dass es hier allgemein um header vs implementierung ging, nicht um interface-header vs private-header+implementierung.
aber dem trollen zum trotz:

Hier in diesem Thread - vielleicht. Keine Ahnung worum es in diesem Thread "allgemein" geht. Du hast aber auf einen Beitrag von Nathan geantwortet, und dort hat er ganz klar Libraries angesprochen. Und da ist das mMn. eben ein Thema.
Also wieso jetzt trollen? Wenn dann wirf das bitte Nathan vor. Grmpf.

na, nathan ist von den kewl ppl, ich muss schon dich beschimpfen

ja, bei mir sind interfaces auch in einem verzeichnis und dieses ist, wie der ganze andere source code im selben source verzeichnis. es gibt dennoch keinen split zwischen datei typen, splits gibt es nur nach organisatorischen gesichstpunkten.
und ich mache mir das leben noch einfacher
*.h - interface
*.hpp - private header
*.inl - inline implementation
*.cpp - private implementation

OK, so kann man es auch machen. Auf die Idee unterschiedliche Extensions zu verwenden bin ich noch nie gekommen. Finde ich auch nicht sonderlich elegant - und ich stelle es mir nicht sehr übersichtlich vor (wobei ich das natürlich nicht wirklich beurteilen kann, da ich es ja nicht ausprobiert habe). Praktikabel ist es aber sicher - wie gesagt, auf die Idee wäre ich nicht gekommen.

das ist nur als zusatz zu den verzeichnissen. das elegante daran ist, dass die interfaces genau wie die private header heissen koennen. wenn man z.b. ueber pure virtuals als interface baut, kann man Texture.h als interface haben und Texture.hpp als objekt deklaration.
was ich sonst sehe ist ITexture.h und Texture.h oder Texture_.h oder Texture_impl.h oder Texture_pimpl.h ... oder man hat nur eines und liefert den private header als interface aus, aber ich finde ein extra interface header der so minimal wie moeglich ist eleganter. (natuerlich koennte man interface header die im anderen verzeichnis sind exakt gleich wie private header nennen, aber trau ich compilern bzw environments nicht).

[C++ Forumbot]

Dieser Thread wurde von Moderator/in rapso aus dem Forum Spiele-/Grafikprogrammierung in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

[rapso]

als ob nur spieleprogrammierer sich darueber flamen koennten...

[Scorcher24]

rapso schrieb:

als ob nur spieleprogrammierer sich darueber flamen koennten...

LOL rapso

[volkard]

rapso schrieb:

das elegante daran ist, dass die interfaces genau wie die private header heissen koennen. wenn man z.b. ueber pure virtuals als interface baut, kann man Texture.h als interface haben und Texture.hpp als objekt deklaration.

Und das Texture-Interface und das Texture-Objekt, die heißen beide Texture? Vermute, das würde mich verwirren.

[rapso]

volkard schrieb:

rapso schrieb:

das elegante daran ist, dass die interfaces genau wie die private header heissen koennen. wenn man z.b. ueber pure virtuals als interface baut, kann man Texture.h als interface haben und Texture.hpp als objekt deklaration.

Und das Texture-Interface und das Texture-Objekt, die heißen beide Texture? Vermute, das würde mich verwirren.

bedenke dass es sich gerade speziel um libraries handelt. (obwohl das topic allgemeiner gefragt wurde, imo).

und ja, die heissen in meinem fall beide gleich, sind aber in unterschiedlichen namespaces. nach aussen hin wird ueber das interface gearbeitet, intern direkt ueber die privaten klassen.

[volkard]

rapso schrieb:

und ja, die heissen in meinem fall beide gleich, sind aber in unterschiedlichen namespaces. nach aussen hin wird ueber das interface gearbeitet, intern direkt ueber die privaten klassen.

Bildest Du die Namespaces auch in Verzeichnissen ab?