[C++] 정규 프로젝트 구조(Canonical Project Structure)

Canonical Project Structure

OpenStd, Canonical Project Structure를 참고 함

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1204r0.html

---

헤더와 CPP는 같은 디렉토리에

헤더와 소스는 옆에 있음

Header and source files (or module interface and implementation files) are next to each other (no include/ and src/ split).

의외라고 생각한 부분. 헤더는 include/ 소스는 src/ 로 나누는 방식을 권할 줄 알았음.

---

프로젝트의 소스 코드는 프로젝트와 동일한 이름의 디렉토리 아래에 배치

name/

├─ name/

│   ├─ foo.hpp

│   ├─ foo.cpp

├─ README.md

├─ LICENSE.md

 

프로젝트의 루트 디렉토리 아래엔 doc, test, examples 또는 license 같은 것들이 있을 수 있다.

그리고 소스코드는 <name/foo.hpp> 같은 형식으로 include 될 수 있도록 프로젝트의 소스 코드는 프로젝트와 동일한 이름 아래에 배치한다.

The project's source code is placed into a subdirectory of the root directory named the same as the project, for example, hello/hello/ or libhello/libhello/. It is called the project's source subdirectory.
There are several reasons for this layout: It implements the canonical inclusion scheme (discussed below) where each header is prefixed with its project name. It also has a predictable name where users (and tools) can expect to find the project's source code. Finally, this layout prevents clutter in the project's root directory which usually contains various other files (like README, LICENSE) and directories (like doc/, tests/, examples/).

---

프로젝트 내 헤더 Include는 <> 스타일만 사용

프로젝트 내 모든 헤더는 <> 스타일 include를 사용하며 프로젝트 이름을 디렉토리 접두사로 포함해야 함.

 

이 부분은 나도 크게 공감 함.
"" 스타일의 include는 include를 쓰는 파일의 위치에 위치에 따라 상대적인 경로를 계산해서 입력을 해야 함.
반면 <> 스타일을 사용한다면 어느 파일에서든 동일한 경로 접근이 가능.

 

// #include "utility.hpp"           // Wrong.
// #include <utility.hpp>           // Wrong.
// #include "../hello/utility.hpp"  // Wrong.

#include <hello/utility.hpp>

---

프로젝트가 라이브러리와 실행 파일로 구성된 경우 서로 별도 프로젝트로 분리. 그리고 라이브러리 프로젝트 이름에 lib를 접두어로 사용하는 것을 "권장"

An initial draft of these guidelines made the lib prefix for libraries a requirement. This, however, encountered strong push-back from early reviewers. Based on this feedback as well as to help with the adoption of these guidelines by existing projects, the lib prefix has been made optional.
However, it is still strongly recommended to follow this convention in new projects since it offers several benefits:
It is clear from the name to both humans and tools what kind of project it is.All libraries are consistently named (as opposed to some with the lib prefix and some without).All library names are future-proofed to co-exist with executables. If one starts with a library without the lib prefix but later decides to add an executable, renaming the library would unlikely be an option. And there is no need to spend mental energy on thinking whether it's possible that an executable will be added later.

---

파일의 확장자는 .?pp

즉, 헤더는 hpp, 소스는 cpp

The C source file extensions should be .h/.c and the C++ source file extension scheme should be .?pp:

file        .?pp

header      .hpp
module      .mpp
inline      .ipp
template    .tpp
source      .cpp

---