자체 포함 라이브러리를 구현하는 다양한 단일 파일 크로스 플랫폼 C/C++ 헤더.
도서관 | 설명 | 최신 버전 | 언어 |
---|---|---|---|
귀엽다_c2 | 프리미티브, 부울 결과 및/또는 다양체 생성, 형태 캐스트/스윕 테스트, 레이캐스트에 대한 2D 충돌 감지 루틴 | 1.10 | C/C++ |
귀여운_넷 | 보안 체계가 내장된 UDP를 통한 선택적 신뢰성 계층이 필요한 게임용 네트워킹 라이브러리 | 1.03 | C/C++ |
귀여운_타일 | JSON 형식으로 내보낸 타일 맵을 위한 매우 효율적인 로더 | 1.07 | C/C++ |
Cute_aseprite | .ase/.aseprite 파일을 작고 편리한 구조체 컬렉션으로 구문 분석합니다. | 1.04 | C/C++ |
귀여운_소리 | 모노/스테레오의 로드/재생/루프(플러그인 포함)/팬 WAV + OGG(OGG용 stb_vorbis 래퍼), 고성능 맞춤형 믹서, 음악 + 크로스페이드 지원 | 2.08 | C/C++ |
귀여운_수학 | SSE 내장 함수를 통한 전문가 수준의 3D 벡터 수학 | 1.02 | C++ |
귀엽다_png | PNG 로드/저장, 텍스처 아틀라스 컴파일러, DEFLATE 호환 압축 해제기 | 1.05 | C/C++ |
Cute_spritebatch | 런타임 2D 스프라이트 배처. 메모리 내에서 즉시 아틀라스를 구축합니다. 디스크에 텍스처 아틀라스를 미리 컴파일할 필요 없이 고성능 렌더링을 위해 어떤 목적(2D 게임 등)으로든 스프라이트 배처를 구현하는 데 유용합니다. | 1.06 | C/C++ |
귀여운_동기화 | 읽기/쓰기 잠금 및 스레드 풀/작업 시스템을 포함한 실용적인 동기화 기본 요소 모음 | 1.01 | C/C++ |
귀여운_tls | HTTPS 요청에 유용한 TCP를 통해 웹사이트에 대한 TLS 연결을 만듭니다. | 1.01 | C/C++/OBJ-C |
일반적으로 이러한 헤더는 종속성이 없으며 소스에 직접 포함되도록 만들어졌습니다(파일 상단의 특정 문서에 대한 각 헤더를 확인하세요). 각 헤더에는 LIBNAME_IMPLEMENTATION 기호가 있습니다. 이를 코드의 단일 번역 단위에 추가하고 라이브러리 기호를 정의하기 위해 바로 뒤에 헤더를 포함합니다. 그렇지 않으면 헤더를 정상적으로 포함하십시오.
일부 헤더에는 예제 코드나 데모도 있습니다. 이 저장소에서 해당 예제 또는 테스트 폴더를 찾으세요. 예제 폴더는 특정 헤더를 사용하는 방법을 알아내는 데 특히 유용합니다.
다음은 Cute_headers의 디스코드 채팅 링크입니다. 언제든지 들러서 질문하고, 제안하고, 토론해 보세요. 혹시 Cute_headers를 사용해보신 분 계시다면 여러분의 경험을 들려주시면 좋을 것 같습니다! https://discord.gg/2DFHRmX
저와 연락할 수 있는 또 다른 쉬운 방법은 트위터 @randypgaul을 이용하는 것입니다.
- 단일 파일을 만드는 이유는 무엇입니까? 헤더에 구현 및 정적 함수가 있는 이유는 무엇입니까?
이러한 헤더를 포함하는 것은 일반 헤더를 포함하는 것과 같습니다. 그러나 구현을 정의하기 위해 각 헤더는 다음과 같습니다.
// Do this ONCE in a .c/.cpp file
#define LIBNAME_IMPLEMENTATION
#include "libname.h"
// Everywhere else, just include like a typical header
#include "libname.h"
그러면 파일이 헤더 + C 파일 콤보로 한 번만 변환됩니다. 요점은 다음과 같습니다. A) 헤더를 처리하거나 사람들에게 보내는 것은 쉽습니다. zip 파일이나 다른 어떤 것도 없이 단일 파일을 복사하여 붙여넣기만 하면 됩니다. B) 빌드 스크립트는 정말 골치 아픈 작업이며 이러한 단일 파일 라이브러리는 단일 빌드 스크립트를 수정하지 않고도 모든 프로젝트에 통합될 수 있습니다.
- 헤더에 모든 코드를 작성하면 컴파일 시간이 망치지 않나요?
헤더 구현으로 인해 컴파일 시간이 느려진다는 낙인은 인라인 코드와 템플릿 스팸에서 비롯됩니다. 두 경우 모두 모든 단일 번역 단위는 헤더를 통해 함수의 인라인 버전을 배치하거나 템플릿의 경우 다양한 유형별 기능을 생성해야 합니다. 링커가 시작되어 번역 단위를 함께 통합하고 중복된 기호를 삭제해야 하면 상황은 더욱 악화됩니다. 링커는 단일 스레드 작업인 경우가 많으며 빌드 시간에 실제로 병목 현상을 일으킬 수 있습니다.
잘 구성된 단일 파일 헤더는 템플릿을 사용하지 않으며 인라인을 드물게 사용합니다. 또한 잘 구성된 단일 파일 헤더는 #define을 사용하여 구현(함수 정의 및 기호)을 단일 번역 단위에 배치합니다. 이런 방식으로 잘 만들어진 단일 파일 헤더는 빌드 시간에 관한 한 C 컴파일러가 만날 수 있는 가장 좋은 것입니다. 특히 헤더가 불필요한 기능을 선택적으로 #define할 수 있는 경우에는 더욱 그렇습니다.
- 이러한 헤더 전용 라이브러리는 단지 새로운 유행이 아닌가?
개인적으로 그것이 유행인지 아닌지는 잘 모르겠지만, 이 파일들은 실제로 단순한 헤더가 아닙니다. 끝에 .C 파일 부분(구현)이 첨부된 헤더입니다. C 전처리기와 함께 붙어 있는 두 개의 다른 파일이지만 사용자가 #define LIB_IMPLEMENTATION을 수행하지 않는 한 구현 부분은 표시되지 않습니다. 이 정의 단계는 이러한 헤더를 사용하는 데 필요한 유일한 통합 단계입니다.
불행하게도 좋은 헤더 라이브러리를 작성하는 것은 꽤 어렵습니다. 따라서 세상에 존재하는 임의의 헤더 라이브러리는 아마도 좋은 것이 아닐 것입니다. STB와 RJM은 꽤 좋은 헤더 라이브러리이며, 좋은 헤더 라이브러리가 어떤 것인지에 대한 아이디어를 얻는 데 좋은 참고 자료입니다. Mattias Gustavsson은 제가 가장 좋아하는 헤더 컬렉션을 가지고 있습니다.
- 라이센스는 무엇입니까?
각 lib에는 파일 끝에 라이센스 정보가 포함되어 있습니다. 공개 도메인과 zlib 중에서 선택할 수 있습니다.
- 이전에 본 헤더를 찾고 있었는데 없어졌습니다. 어디로 갔나요?
인기가 없거나 그다지 유용하지 않은 헤더 중 일부는 더 이상 사용되지 않으며 현재 여기에 있습니다.
- *더 높은 수준의 라이브러리가 있습니까? 이건 너무 낮은 수준인 것 같습니다.
귀여운 헤더는 실제로 다소 낮은 수준입니다. 그들은 특정 문제를 해결합니다. 더 높은 수준의 게임 제작 프레임워크를 찾고 있다면 여기에 표시된 다양한 낮은 수준의 귀여운 헤더 위에 주로 구축된 2D 게임 제작 프레임워크인 Cute Framework를 사용해 보시기 바랍니다.