소득공제
아름다운 C++
클린하고 안전하며 빠른 코드 작성을 위한 핵심 가이드라인 30선
- 베스트
- 프로그래밍 언어 top100 5주
이미 소장하고 있다면 판매해 보세요.
- 해외배송 가능
- 최저가 보상
- 문화비소득공제 신청가능
카드뉴스로 보는 책
상세 이미지
책소개
목차
|
옮긴이 머리말 xii
베타리더 후기 xiii 선정 가이드라인 목록 xvi 추천 서문(비야네 스트롭스트룹) xvii 시작하며 xix 감사의 글 xxiv PART 1 사소한 것 때문에 중요한 문제를 놓치지 말자 CHAPTER 1.1 [P.2] ISO 표준 C++로 작성하라 3 __1.1.1 ISO 표준 C++란 무엇인가? 3 __1.1.2 차이를 캡슐화하기 5 __1.1.3 예전 방식 학습하기 9 __1.1.4 표준 개발 현황 파악하기 11 CHAPTER 1.2 [F.51] 선택의 여지가 있다면 오버로딩 대신 기본 인수를 사용하라 13 __1.2.1 소개 13 __1.2.2 추상화 다듬기: 추가 인수냐, 오버로딩이냐 14 __1.2.3 오버로드 확인의 미묘한 차이 16 __1.2.4 예제로 돌아가기 18 __1.2.5 모호하지 않다는 기본 인수의 특성 19 __1.2.6 오버로드의 대안 21 __1.2.7 반드시 오버로드해야 하는 경우 21 __1.2.8 요약 22 CHAPTER 1.3 [C.45] 데이터 멤버를 초기화하기만 하는 기본 생성자를 정의하지 말고 기본 멤버 초기화자로 초깃값을 설정하라 24 __1.3.1 어쨌거나 기본 생성자가 있는 이유는? 24 __1.3.2 데이터 멤버를 초기화하려면? 26 __1.3.3 두 사람이 클래스 하나를 유지보수하면 무슨 일이 발생하나요? 28 __1.3.4 요약 31 CHAPTER 1.4 [C.131] 자명한 getter와 setter는 피하라 32 __1.4.1 아주 오래된 이디엄 32 __1.4.2 추상화 33 __1.4.3 단순한 캡슐화 36 __1.4.4 클래스 불변 조건 39 __1.4.5 명사와 동사 41 __1.4.6 요약 42 CHAPTER 1.5 [ES.10] 선언당 단 하나의 이름만 선언하라 43 __1.5.1 소개합니다 43 __1.5.2 하위 호환성 47 __1.5.3 더 명확하게 선언하기 48 __1.5.4 구조적 바인딩 49 __1.5.5 요약 51 CHAPTER 1.6 [NR.2] 함수에 단일 반환문을 고집하지 말라 52 __1.6.1 규칙은 진화합니다 52 __1.6.2 정리를 보장하기 54 __1.6.3 RAII 사용하기 57 __1.6.4 좋은 함수 작성하기 59 __1.6.5 요약 61 PART 2 자기 발등을 찍지 말라 CHAPTER 2.1 [P.11] 지저분한 구조체는 코드에 펼쳐놓지 말고 캡슐화하라 65 __2.1.1 한 번에 처리하기 65 __2.1.2 지저분한 구조체를 캡슐화한다는 의미 67 __2.1.3 언어의 목적과 추상화의 본질 69 __2.1.4 추상화 수준 72 __2.1.5 리팩터링과 구분 짓기를 통한 추상화 74 __2.1.6 요약 75 CHAPTER 2.2 [I.23] 함수의 인수를 적게 유지하라 76 __2.2.1 얼마나 벌어야 할까요? 76 __2.2.2 추상화를 통해 문제를 단순화하기 78 __2.2.3 가능한 한 적게 하되, 덜 하지는 말기 81 __2.2.4 실제 사례 83 __2.2.5 요약 85 CHAPTER 2.3 [I.26] 크로스 컴파일러 ABI가 필요하면 C 방식의 하위 집합을 사용하라 86 __2.3.1 라이브러리 만들기 86 __2.3.2 ABI란 무엇인가? 87 __2.3.3 최소한으로 줄이기 89 __2.3.4 예외 전파 91 __2.3.5 요약 92 CHAPTER 2.4 [C.47] 멤버를 선언한 순서대로 데이터 멤버를 정의하고 초기화하라 94 __2.4.1 요약 103 CHAPTER 2.5 [CP.3] 쓰기 가능한 데이터의 명시적 공유는 최소화하라 104 __2.5.1 전통적 실행 모델 104 __2.5.2 잠깐, 더 있습니다 106 __2.5.3 교착 상태 및 데이터 경쟁 피하기 109 __2.5.4 잠금과 뮤텍스 외의 사항 111 __2.5.5 요약 114 CHAPTER 2.6 [T.120] 꼭 필요할 때만 템플릿 메타프로그래밍을 사용하라 115 __2.6.1 std::enable_if에서 requires로 123 __2.6.2 요약 128 PART 3 그만 사용하라 CHAPTER 3.1 [I.11] 절대로 원시 포인터(T*)나 참조(T&)로 소유권을 넘기지 말라 131 __3.1.1 자유 공간 사용하기 131 __3.1.2 스마트 포인터의 성능 비용 134 __3.1.3 데코레이터 없는 참조 시맨틱 사용하기 135 __3.1.4 gsl::owner 136 __3.1.5 요약 139 CHAPTER 3.2 [I.3] 싱글턴을 피하라 140 __3.2.1 전역 객체는 나쁩니다 140 __3.2.2 싱글턴 디자인 패턴 141 __3.2.3 정적 초기화 순서 실패 142 __3.2.4 싱글턴 숨기는 법 144 __3.2.5 하지만 이 중 하나만 존재해야 합니다 145 __3.2.6 잠깐만요... 147 __3.2.7 요약 149 CHAPTER 3.3 [C.90] memset과 memcpy에 의존하지 말고 생성자와 할당 연산자를 사용하라 150 __3.3.1 최대 성능 추구하기 150 __3.3.2 끔찍한 생성자 오버헤드 151 __3.3.3 가장 간단한 클래스 152 __3.3.4 어쨌든 표준에서 설명하는 내용은 무엇인가요? 155 __3.3.5 그러면 memcpy는 어때요? 158 __3.3.6 컴파일러를 절대 과소평가하지 말라 159 __3.3.7 요약 161 CHAPTER 3.4 [ES.50] const를 형 변환하지 말라 162 __3.4.1 이야기 162 __3.4.2 훨씬 더 많은 데이터 다루기 163 __3.4.3 상수 방화벽 165 __3.4.4 이중 인터페이스 구현 166 __3.4.5 캐싱과 느긋한 계산법 168 __3.4.6 두 종류의 const 169 __3.4.7 const의 놀라운 점 171 __3.4.8 요약 172 CHAPTER 3.5 [E.28] 전역 상태에 따른 에러 처리는 피하라(예: errno) 173 __3.5.1 에러 처리는 어렵습니다 173 __3.5.2 C와 errno 173 __3.5.3 반환 코드 175 __3.5.4 예외 176 __3.5.5 〈system_error〉 177 __3.5.6 Boost.Outcome 177 __3.5.7 에러 처리는 왜 이렇게 어려운가? 179 __3.5.8 고생 끝에 낙이 온다 180 __3.5.9 요약 182 CHAPTER 3.6 [SF.7] 헤더 파일의 전역 범위에 using namespace를 사용하지 말라 183 __3.6.1 이렇게 하지 말라 183 __3.6.2 명확하게 하기 184 __3.6.3 using 사용법 185 __3.6.4 심벌은 어디로 가나? 187 __3.6.5 한층 더 은밀히 퍼지는 문제 190 __3.6.6 복잡한 범위 지정 연산자 문제 해결하기 191 __3.6.7 유혹과 타락 193 __3.6.8 요약 194 PART 4 새로운 기능을 제대로 사용하라 CHAPTER 4.1 [F.21] ‘출력값’을 여러 개로 반환하려면 구조체로 반환하라 197 __4.1.1 함수 시그니처의 형태 197 __4.1.2 설명과 애너테이션 198 __4.1.3 이제 객체를 반환할 수 있습니다 199 __4.1.4 튜플도 반환할 수 있습니다 203 __4.1.5 비상수 참조로 전달 및 반환하기 205 __4.1.6 요약 209 CHAPTER 4.2 [Enum.3] 단순 열거형보다는 클래스 열거형을 택하라 210 __4.2.1 상수 210 __4.2.2 범위가 있는 열거형 213 __4.2.3 숨겨진 타입 215 __4.2.4 암묵적 형 변환 217 __4.2.5 요약 219 __4.2.6 추신 219 CHAPTER 4.3 [ES.5] 범위는 작게 유지하라 220 __4.3.1 범위의 본질 220 __4.3.2 블록 범위 222 __4.3.3 네임스페이스 범위 223 __4.3.4 클래스 범위 226 __4.3.5 함수 매개변수 범위 228 __4.3.6 열거형 범위 229 __4.3.7 템플릿 매개변수 범위 230 __4.3.8 맥락으로서의 범위 231 __4.3.9 요약 232 CHAPTER 4.4 [Con.5] 컴파일 타임에 계산할 수 있는 값은 constexpr를 사용하라 233 __4.4.1 const부터 constexpr에 이르기까지 233 __4.4.2 C++ 기본값 235 __4.4.3 constexpr 사용하기 237 __4.4.4 inline 241 __4.4.5 consteval 242 __4.4.6 constinit 243 __4.4.7 요약 245 CHAPTER 4.5 [T.1] 템플릿을 사용하여 코드의 추상화 수준을 높이라 246 __4.5.1 이야기 246 __4.5.2 추상화 수준 높이기 248 __4.5.3 함수 템플릿과 추상화 250 __4.5.4 클래스 템플릿과 추상화 253 __4.5.5 작명은 어렵습니다 255 __4.5.6 요약 256 CHAPTER 4.6 [T.10] 모든 템플릿 인수의 콘셉트를 명시하라 257 __4.6.1 어떻게 여기까지 왔을까요? 257 __4.6.2 매개변수 제한하기 260 __4.6.3 콘셉트를 추상화하는 법 263 __4.6.3 콘셉트를 통해 분해하기 266 __4.6.5 요약 268 PART 5 기본적으로 코드를 잘 작성하라 CHAPTER 5.1 [P.4] 프로그램은 최대한 정적으로 타입에 안전해야 한다 273 __5.1.1 타입 안전성은 C++의 보안 기능입니다 273 __5.1.2 공용체 275 __5.1.3 형 변환 277 __5.1.4 unsigned 280 __5.1.5 버퍼와 크기 283 __5.1.6 요약 285 CHAPTER 5.2 [P.10] 가변 데이터보다는 불변 데이터를 택하라 286 __5.2.1 잘못된 기본값 286 __5.2.2 함수 선언의 상수성 289 __5.2.3 요약 293 CHAPTER 5.3 [I.30] 규칙 위반을 캡슐화하라 294 __5.3.1 일상에서 보기 싫은 것 숨기기 294 __5.3.2 체면 차리기 296 __5.3.3 요약 301 CHAPTER 5.4 [ES.22] 값으로 초기화하기 전까지는 변수를 선언하지 말라 303 __5.4.1 표현식과 문의 중요성 303 __5.4.2 C 언어 방식의 선언 304 __5.4.3 선언 후 초기화하기 305 __5.4.4 최대한 지연된 선언 307 __5.4.5 맥락에 따른 기능의 지역화 309 __5.4.6 상태 제거하기 311 __5.4.7 요약 313 CHAPTER 5.5 [Per.7] 최적화할 수 있도록 설계하라 314 __5.5.1 프레임 레이트 최대화하기 314 __5.5.2 하드웨어 수준에서 더 나아가 작업하기 316 __5.5.3 추상화를 통한 최적화 320 __5.5.4 요약 322 CHAPTER 5.6 [E.6] 메모리 누수를 방지하려면 RAII를 사용하라 324 __5.6.1 결정론적 소멸 324 __5.6.2 파일 누수 없애기 327 __5.6.3 왜 굳이 이렇게 할까요? 330 __5.6.4 미래의 가능성까지 고려해야 하는가 332 __5.6.5 어디에서 얻을 수 있나요? 335 마치며 338 후기(허브 서터) 340 찾아보기 342 |
저자 소개3
J. Guy Davidson
크리에이티브 어셈블리의 엔지니어링 실무장으로, 〈토탈 워〉 프랜차이즈 개발, 카탈로그 큐레이션, 엔지니어링 팀의 프로그래밍 표준 개선 작업을 담당하고 있다. ISO C++ 위원회에서 활동하고, #include 〈C++〉 디스코드 서버를 운영하며, C++ 행사에서 연설한다. Prospela, BAME in Games 등 C++ 멘토링 활동도 하고 있다.
Kate Gregory
40년 이상의 경력을 보유한 개발자로, 5개 대륙에서 기조연설을 했으며, 업계를 더욱 포용적이고 따뜻하게 만드는 #include 〈C++〉를 비롯한 여러 C++ 활동에서 자원봉사를 하고 있다. 1986년부터 그레고리 컨설팅을 운영하며 전 세계 고객들이 더 효율적으로 일할 수 있도록 돕고 있다.
주중엔 코드를 짜고 주말엔 미디를 찍는 삶을 지향하는 개발자이자 번역가. VST와 DAW 개발에 관심이 있어 C/C++를 기웃대는 프런트엔드 개발자로 살고 있다. 서울대학교 재학 중 미술대학 연합전공 영상매체예술(미디어 아트)을 복수전공한 것을 계기로 웹과 전자음악에 관심을 갖게 되었다. 언젠가는 웹 공간에 원하는 비주얼과 사운드를 펼쳐놓을 수 있기를 꿈꾸지만, 예술가가 되기보다는 예술가가 사용하는 도구를 만드는 데 관심이 더 많다. 현재 넥슨 코리아에 재직 중이며, 역서로는 『전문가를 위한 C』(한빛미디어, 2022) 등이 있다.
박지윤의 다른 상품
품목정보
- 발행일
- 2024년 08월 02일
- 쪽수, 무게, 크기
- 372쪽 | 718g | 188*245*19mm
- ISBN13
- 9791193926185
책 속으로
|
사용자가 키보드를 눌렀을 때 그 특정 키를 알고 싶은 경우를 예로 들겠습니다. 한 가지 접근법은 사용 중인 플랫폼을 감지하는 전처리기를 사용해서 알맞은 코드를 아래와 같이 실행하는 방법입니다.
#if defined WIN32 auto a_pressed = bool{GetKeyState('A') & 0x8000 != 0}; #elif defined LINUX auto a_pressed = /*아주 길고 긴 코드*/ #endif 아주 보기 나쁩니다. 잘못된 추상화 수준에서 작동하기 때문입니다. 윈도우나 리눅스 전용 코드는 헤더 파일에 적힌 다른 별도의 파일에 있어야 하기 때문에, 이 코드는 다음과 같아야 합니다. --- p.5 이 함수에서 중요한 것은 옵션 파일을 구문 분석하여 각 키에 무언가를 한다는 점입니다. 안타깝게도 그러는 동안 공백이 포함되는 기능을 잃었습니다. 화살괄호 연산자는 공백에 도달하면 추출을 중단합니다. 이에 대해서는 곧 다시 살펴보겠습니다. / 하지만 한결 나아졌습니다. 이제 키와 함수 포인터에 대한 맵을 초기화하기만 하면 됩니다. 그러나 문제를 빙 돌아온 것일 뿐입니다. 사용자가 초기화자 업데이트를 깜빡할 수 있기 때문에 여기서 또 실수가 발생할 수 있습니다. 이걸 자동화할 수 있을까요? --- p.70-71 gsl::owner의 정의는 매우 간단합니다. T가 포인터 타입이라면 gsl::owner〈T〉는 T의 별칭이고 그렇지 않다면 정의되지 않습니다. / 이 타입은 소유권을 강제하려는 것이 아니라 사용자에게 소유권 변경이 발생함을 알리려는 것입니다. 함수 이름에 이러한 정보를 담지 않고 타입에 포함시켰습니다. (…) GSL이 더 널리 쓰임에 따라 IDE가 해당 타입을 익히고 빨간 밑줄이나 전구 힌트 표시 같은 표시로 작성자에게 소유권 남용에 대해 경고하리라 기대할지도 모르겠네요. 그때까지는 gsl::owner를 소유권을 강제하는 타입으로 사용하기보다는 소유권을 설명하는 타입으로 사용하세요. 궁극적으로 gsl::owner는 고수준의 소유권 추상화를 정말로 사용할 수 없을 때 최후의 수단으로 사용하세요. --- p.138-139 보다시피 범위를 작게 유지하면 몇 배의 보상으로 돌아옵니다. 근본적으로 범위란 어떤 것의 부분에 대해 생각하는 방식입니다. 범위와 관련성이라는 개념은 밀접하게 연관되어 있습니다. / 범위는 추상화를 식별하고 묶는 방식입니다. 범위는 이름의 집합입니다. 클래스 범위이든 함수 범위이든 네임스페이스 범위이든 해당 추상화와 관련된 선언을 포함하는 것이 바로 범위입니다. 범위는 솔루션 도메인의 근본적인 기본 요소입니다. 범위를 작게 유지하라는 것은 또한 추상화를 작게 유지하라는 말이 됩니다. --- p.231 C에서는 모든 코드가 실행되기 전에 함수 위쪽에 모든 변수를 선언해야 했습니다. 함수에서 사용하는 것보다 더 많은 변수를 무심코 선언하는 일은 꽤 흔했습니다. (…) 이 함수는 10년 전에 처음 작성했고 여러 번 수정을 거쳤습니다. 5년 전에 distribution_median은 distribution_mode라는 합계로 대체되었는데, 둘 다 중앙값의 필요 여부는 고려하지 않고 계산되었습니다. 아무도 알고리즘에서 사용하지 않는 부분을 지원하기 위해 선언된 상태를 제거하지 않았습니다. 눈에서 멀어지면 마음에서도 멀어지는 법입니다. 게다가 알맞은 위치를 찾기보다는 목록에 추가하는 것이 엔지니어의 습관이기 때문에 range_average와 range_max는 range_floor와 range_ceiling으로 분리되었습니다. --- p.304 진심으로 바라건대, 여러분이 이 책을 읽고 나면 프로그램이란 일련의 작업이 스크립팅된 것이 아니라 당면한 문제를 모델링하는 작은 추상화 집합이라는 개념에 초점을 맞추기를 바랍니다. C++는 제로 오버헤드 추상화 기능과 하드웨어 수준의 성능 향상 가능성이 혼합되었다는 특징이 있습니다. 성능 향상의 이점만 취하고 추상화 기능은 버린다면 코드는 유지보수가 어려워지고, 다른 코드베이스에 통합하기도 어려워집니다. --- p.338 |
출판사 리뷰
|
클린하고 안전하며 빠른 코드 작성을 위한 핵심 가이드라인 30선
C++는 역사가 오래되었고, 긴 시간에 걸쳐 언어 자체는 물론 그 작성법도 진화했다. 비야네 스트롭스트룹(C++ 창시자)과 허브 서터가 작성한, C++ 코딩 스타일 가이드의 바이블이라고 할 수 있는 오픈 소스 ‘C++ 핵심 가이드라인(C++ Core Guidelines)’ 역시 지금 이 순간에도 끝없이 개정되고 있다. 백과사전처럼 구성된 핵심 가이드라인 전체를 차례대로 정독하는 것은 지루한 일이다. 이 책은 256개에 달하는 핵심 가이드라인 중에서도 정수 30개를 선별해 다섯 개 카테고리로 묶고, 맥락과 함께 가이드라인의 내용을 해설한다. 경험 많은 게임 프로그래머 가이 데이비슨과 C++ 강연으로 유명한 케이트 그레고리가 실제 사례와 실무 지식을 덧붙여 공식 C++ 핵심 가이드라인 웹사이트와 긴밀하게 연계되도록 집필했다. 전문적인 샘플 코드를 통해, 긴 역사만큼이나 오용되는 지식을 바로잡고 추상화, 템플릿, 타입 안전성 등 주요 프로그래밍 개념에 대한 통찰력을 얻을 수 있다. 레거시 코드나 지침을 무조건 배척하는 대신, 개념의 원래 의미와 역사적 맥락을 돌아보고 예시를 살펴본다. 새로운 언어 기능과 오래된 언어 기능 모두를 성공적으로 사용하는 검증된 방법을 조명함으로써, 기본적으로(by default) 강력하고 성능이 뛰어난 프로그램을 작성하는 방법을 보여준다. ‘핵심 가이드라인의 핵심’을 유려하게 풀어내는 아름다운 책이다. 주요 내용 ● ‘바이크셰딩’ 방지하기(사소한 것 때문에 중요한 문제를 놓치지 말자) ● 나중에 문제를 일으킬 수 있는 코드를 작성하지 않기 ● 피해야 할 레거시 기능과 대신 사용할 최신 기능을 파악하기 ● 최신 기능을 올바르게 사용하여 새로운 문제를 일으키지 않고 이점을 누리기 ● 정적으로 타입 안전하며, 누출이 없고, 발전시키기 쉬운 고품질 코드를 기본값으로 삼기 ● 모든 C++ 버전(C++11, C++14, C++17, C++20)에서 핵심 가이드라인 사용하기 |
추천평
|
이 책은 규칙을 따를 때 얻는 이점과 무시한 결과 발생할 수 있는 끔찍한 일에 주안점을 두고 개발자의 관점에서 규칙을 제시합니다. 해당 규칙의 동기에 대해서는 C++ 핵심 가이드라인 자체에서 설명하는 것보다 더 폭넓게 다룹니다. (…) 핵심 가이드라인을 취향, 관점, 경험에 따라 선택적으로 살펴보고 싶다면 이 책을 읽어보세요. 진정한 괴짜(geek)라면 읽기 쉽고 재미있을 겁니다. 대부분의 소프트웨어 개발자에게 이 책은 새롭고 유용한 내용을 전합니다. - 비야네 스트롭스트룹 (C++ 창시자)
|
|
이 책의 제목 ‘아름다운 C++’는 기억하기 쉬운 제목일 뿐만 아니라 제 개인적인 목표이기도 하고, 제가 C++의 진화 과정에서 가장 높이 평가하는(바라는) 것입니다. (…) 케이트와 가이는 각 장에서 이야기의 플롯을 발전시키면서 유쾌하고 읽기 쉬운 내러티브로 전달하여 독자를 즐겁고, 밝고, 만족스러운 여정으로 인도합니다. 이 책을 재미있게 읽었다면 저와 마찬가지로 여러분도 저자들이 이 가이드라인에 자신의 전문 지식과 경험을 녹여낸 방식을 잘 알아보았을 것입니다. - 허브 서터 (‘C++ 핵심 가이드라인’ 공동 편집자)
|
|
책 제목은 ‘아름다운(beautiful) C++’이지만, 아름다울 뿐만 아니라 위트와 재미가 더해져 마법같이 ‘황홀한(enchanting) C++’가 더 어울린다는 생각마저 들었습니다. 모던 C++ 패턴과 C++ 핵심 가이드라인을 재료로, 케이트 그레고리의 발표 내용에 가이 데이비드슨의 경험이 멋진 컬래버레이션을 이룬 책입니다. - 김용현 (Microsoft MVP)
|
29,700원
총 1개
29,700원
