Quali sono le linee guida per un albero di sorgenti C ++ Win / Mac / Linux? [chiuso]

Question

Quali sono le linee guida per un albero di sorgenti C ++ Win / Mac / Linux? [chiuso]

#1 da (3 voti)

-1

Sto imparando C ++ (C ++ 11), specificamente per lo sviluppo di giochi multipiattaforma usando SDL.

su Windows, uso Visual Studio 2012 (considerando l'acquisto di '14' una volta uscito), su Mac OS X e iOS userò qualunque sia l'ultimo XCode (in questo momento 5.1) e non ho esaminato ancora per Linux.

Tuttavia, poiché sto ancora cercando di capire come sono strutturate le applicazioni C ++, non sono sicuro di come dovrebbe essere organizzato il progetto. Suppongo che il 95% dei file .cpp / .h sia condiviso tra tutte le piattaforme (logica di gioco reale), con alcuni file .cpp / .h aggiuntivi per materiale specifico della piattaforma, e poi ci sono i file di progetto, ad es. i file .xcodeproj / .plist per XCode, il .vcxproj per Visual Studio e qualsiasi altra cosa abbia bisogno di Linux.

Ci sono linee guida o esempi su come dovrebbe essere strutturare le cose? Dovrei usare qualche formato indipendente come CMake o SCons? Non voglio compattare la mia ripida curva di apprendimento introducendo un sistema di compilazione indipendente, voglio comunque essere in grado di premere "Esegui" nell'IDE e avviare l'app con gli strumenti di debug e di profilazione.

Dovrei solo fare questo:

+ root
+-- Code (shared .cpp/.h)
+-- Win (.vcxproj and Windows Specific .cpp/.h)
+-- Max (.xcodeproj and Mac specific .cpp/h)
+-- Linux/iOS/Android/etc... (Other platforms)

Credo che per un degre sia un gusto personale, ma mi chiedo se ci sono le migliori pratiche.

c++ visual-studio project-structure xcode

posta Michael Stum 16.09.2014 - 09:57

fonte

1 risposta

Leggi altre domande sui tag c++ visual-studio project-structure xcode

SQLDatabase: legge molti dati contemporaneamente e processa in memoria o legge i dati quando ne ho bisogno? È statico che farà qualsiasi differenza in questo frammento di codice

score 3 · Answer 1

However, since I'm still trying to understand how C++ applications are structured, I'm not sure how the project should be organized.

Questo dipende molto da quali strumenti e processi userete. Si parla di Visual Studio e XCode. Ognuno ha le sue quirche e entrambi ottimizzano le fonti per le loro stesse interruzioni con loro (il che rende le fonti scarsamente organizzate per l'altro IDE).

Se desideri eseguire uno sviluppo multipiattaforma, devi creare un albero dei sorgenti che abbia senso per te (cioè non per un IDE). Ciò significa che probabilmente ne creerai almeno parti, manualmente.

Ad esempio, di solito ho una directory root del progetto, con qualcosa di simile all'interno:

src (file sorgente C ++)
include (include i file C ++)
documenti (documentazione, elenco / i di todo, storie degli utenti, ecc.)
strumenti (strumenti di compilazione, script python personalizzati per i sorgenti, ecc.)
build (per build artefatti e binari)
test (per il codice sorgente di test)

Lavoro principalmente con strumenti da riga di comando.

Se voglio (per esempio) integrare il progetto con Visual Studio, vorrei creare una nuova directory (ad esempio vstudio-2013) e creare lì la soluzione e altri file specifici. Questo assicura che quando si utilizza un IDE, non si vedano file specifici dall'altro IDE (ovvero non si deve guardare il file di soluzione di Visual Studio da XCode).

In questi giorni, tendo a mantenere un file CMakeLists.txt e ad utilizzarlo per generare una configurazione build CLI o configurazioni specifiche IDE (è in grado di generare progetti Visual Studio, Netbeans e XCode e può anche generare un file basato su Makefile costruire la configurazione).

Should I just do this? root/Code (shared .cpp/.h), root/Win, root/Mac, ...

Probabilmente no. Puoi considerare di centralizzare tutti gli elementi di un singolo tipo in una directory e quindi specializzarlo per tipo, categoria, modulo, ecc.

Esempio:

root / src (src - tutte le fonti)
root / src / os / win (specifico per Windows)
root / src / os / linux (specifico per linux)
root / src / os.h (intestazione che nasconde l'implementazione os specifica dietro all'interfaccia del sistema operativo astratto)
root / src / gamelogic (o qualsiasi altra cosa)
root / src / unittest (probabilmente dovresti avere una directory per libreria / modulo)
root / build / tmp (artefatti di build temporanei)
root / build / bin (output binari)

Ciò consentirà di trattare tutti i file di un singolo tipo in modo unificato (ad esempio, aggiungere tutte le origini specifiche di Windows a una libreria, fornendo solo la directory).

I guess to a degre it's personal taste, but I do wonder if there are best practices.

Altre linee guida simili per le cose che funzionano (e queste non sono universali). Le "best practice" che si applicano a un progetto linux & mac dovranno probabilmente essere modificate un po 'per adattarsi anche a Windows (e simili negli altri casi).

on Windows, I use Visual Studio 2012 (Considering buying '14' once it's out), on Mac OS X and iOS I'll be using whatever the latest XCode is (right now 5.1) and I haven't looked into options for Linux yet.

Uso NetBeans (C ++) su Linux e OSX. Uso anche un terminale e CLI su entrambi (eseguendo principalmente modifiche in NetBeans e compilazione, SCM, esecuzione e test nella CLI. Inoltre, poiché uso test di unità, raramente ho bisogno di usare un debugger (quando possibile, preferendo unità prova per il debug, può essere considerato una "best practice").