이전

리뷰 (7)

한줄평
평점 분포
  • 리뷰 총점10 100%
  • 리뷰 총점8 0%
  • 리뷰 총점6 0%
  • 리뷰 총점4 0%
  • 리뷰 총점2 0%
연령대별 평균 점수
  • 10대 0.0
  • 20대 10.0
  • 30대 10.0
  • 40대 10.0
  • 50대 10.0

포토/동영상 (4)

리뷰 총점 종이책
아름다운 C++
"아름다운 C++" 내용보기
제가 C++언어를 처음 접할때 즈음, C언어는 2년 배워서 20년을 써먹고, C++언어는 20년을 배워서 2년 써먹는다는 우스겟소리가 있었는데, 정말 20년은 가뿐히 넘어 서며 계속 새로운 표준과 디자인 패턴들이 나오고 그럴 때 마다 배우고 따라잡기를 반복하다 보니 단순한 우스겟소리지만 다시 한번 곱씹어 보게 됩니다.물론 그 당시 저 말이 나온 이유는 표준이 계속 나올걸 예상한 건 아
"아름다운 C++" 내용보기
제가 C++언어를 처음 접할때 즈음, C언어는 2년 배워서 20년을 써먹고, C++언어는 20년을 배워서 2년 써먹는다는 우스겟소리가 있었는데, 정말 20년은 가뿐히 넘어 서며 계속 새로운 표준과 디자인 패턴들이 나오고 그럴 때 마다 배우고 따라잡기를 반복하다 보니 단순한 우스겟소리지만 다시 한번 곱씹어 보게 됩니다.

물론 그 당시 저 말이 나온 이유는 표준이 계속 나올걸 예상한 건 아니고, 메타 프로그래밍과 언어적 특성 상 자유도가 높은 문법으로 인해 배워야 할 것이 많고, 잘 사용하기도(좋은 코드를 작성하기) 어려운 C++ 언어의 난이도를 풍자한 것이었겠습니다만, C++ 11 이후 3년 마다 새 표준이 나오게 되면서 좀 익숙해 질만하면 새 표준이 나오고, 배워서 좀 써먹을만 해 지면 또 새 표준이 나오는 현재의 C++ 개발자들의 애환을 정확히 예측한 게 되어 버리기도 했습니다.

이렇게 그 오래된 언어 특유의 난이도에 더해 새로운 표준이 계속 나오면서 배워야 할 것도 계속 쌓여서 현대의 Modern C++ 은 학습 곡선이 정말 높은 프로그래밍 언어 중 하나일 것있습니다. 그나마 다행인 것은 이러한 학습과 사용의 어려움에 대해 C++ 표준 위원회에서도 잘 알고 있다 보니, C++ 핵심 가이드라인(https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)를 통해 소위 말하는 Best Practice, 모범 사례를 제시하고 있다는 점이 그나마 다행이라고 할 수 있을 것입니다. 간단히 얘기하자면 C++ 을 잘, 그리고 제대로 쓰기 위한 가이드라인이라 할 수 있겠습니다.

하지만 그 가이드라인의 분량이... 정말 너무 많다 보니, 정말 좋은 내용이지만 어느 세월에 이걸 다 보나 싶은 수준이고 내용도 초보자나 입문자가 보기에는 아무래도 어려운 부분이 없지 않다보니 여전히 C++ 은 배우기 어려운 언어라는 타이틀을 벗어나기가 쉽지 않아 보입니다.

이 책은 C++ 핵심 가이드라인 중 30개를 선정하여 보다 읽고 이해하기 쉽게 풀어 쓴 내용이 담겨있습니다. C++ 핵심 가이드라인을 논문에 비유하자면 이 책은 그 해설서라는 느낌을 받았습니다. C++ 핵심 가이드라인을 읽다가 그 방대한 분량에 포기했거나, C++ 언어를 보다 잘 사용하기 위해 참고할 만한 책을 찾는 분에게 딱 맞는 책입니다. 간단히 표현하자면 스캇 마이어스의 Effective C++ 같은 도서의 현대 C++ 버전이라고 할까요, 물론 시간이 지나도 여전히 가치있는 내용을 담고 있는 명서이지만 최신 표준의 내용과 변화는 담지 못하고 있는 만큼, 지금 C++ 언어 책을 고른다면 그런 아쉬운 부분도 커버해 줄 수 있는 이 책이 더 적합할 거라 생각됩니다.

내용 특성 상, C++ 언어에 입문하는 분 보다는 C++ 언어를 어느정도 사용해 본 분들에게 적합한 내용이 담겨있으며 번역도 크게 아쉬운 부분 없이 무난했습니다. 최근 출간된 C++ 언어를 다루는 책이 많지 않다보니, 가뭄에 단비같은 C++ 책을 번역 출간해 주신 제이펍에 감사드립니다.
YES마니아 : 로얄 m******o 2024.08.26. 신고 공감 0 댓글 0
리뷰 총점 종이책
내 C++지식을 한단계 업그레이드 시켜줄 책
"내 C++지식을 한단계 업그레이드 시켜줄 책" 내용보기
일단 아름다운건 책제목만 그렇고 내용은 C++가 원래 그렇지만 메모리 스택 같은 머리복잡해지는 내용들이 가득한 책입니다. 그래서 유용하고 좋은책이지요. 일단 초보자들 보라고 쓴책은 아니고 C++ 몇년은 써보신 중급자분들을 위한 책입니다. 목차만 보셔도 아시겠지만 고수의 냄새가 풀풀납니다. 여러가지 하지 말아야할 것들과 각종 팁과 고수의 가이드들이 가득합니다. 자바보다 이
"내 C++지식을 한단계 업그레이드 시켜줄 책" 내용보기
일단 아름다운건 책제목만 그렇고 내용은 C++가 원래 그렇지만 메모리 스택 같은 머리복잡해지는 내용들이 가득한 책입니다. 그래서 유용하고 좋은책이지요. 일단 초보자들 보라고 쓴책은 아니고 C++ 몇년은 써보신 중급자분들을 위한 책입니다. 목차만 보셔도 아시겠지만 고수의 냄새가 풀풀납니다. 여러가지 하지 말아야할 것들과 각종 팁과 고수의 가이드들이 가득합니다. 자바보다 이책보니 확실히 C는 접근이 어려운 언어입니다. 지금은 게임프로그래밍이나 임베디드애서나 주로 쓰이는데 게임프그래밍 하는 저에게 코드 이해와 아키텍트 설계에 분명 도움이 될거 같습니다. 그리고 이 책의 내용이 원서로 보기엔 너무 어렵습니다. 내용 자체가 영어로 설명되 있다면 이런 내용 일부러 번역해서 보기는 보통 엔지니어에게는 엄청 어려울 겁니다. 그래서 좀 가치있는 번역서라는 생각이 듭니다 템플릿으로 코드 추상화 높여라 이런거 해석이 좀 어렵정. 그리고 내용이 연결되 있지 않으니 책상에 꽃아두고 한챕터씩 두고두고 보기 좋아보입니다.

s****3 2024.08.11. 신고 공감 0 댓글 0
리뷰 총점 종이책
아름다운 C++ (Beautiful C++)
"아름다운 C++ (Beautiful C++)" 내용보기
By Guy Davidson and Kate Gregory이 책은 “아름다운” C++ Code를 작성하기 위해서 지켜야 하는 C++ Core Guidelines에서 30개만 저자가 엄선해서 해석과 함께 예제를 제시하는 형태로 구성된 책입니다. 앞에서부터 꼭 읽어야 할 필요는 없고 관심있는 부분만 골라봐도 됩니다. 읽다보면 하나하나 빼지않고 읽는 부분도 있었지만 머리에 잘 안들어오거나 체감이 안되어서 슥 넘어가는
"아름다운 C++ (Beautiful C++)" 내용보기

By Guy Davidson and Kate Gregory

이 책은 “아름다운” C++ Code를 작성하기 위해서 지켜야 하는 C++ Core Guidelines에서 30개만 저자가 엄선해서 해석과 함께 예제를 제시하는 형태로 구성된 책입니다. 앞에서부터 꼭 읽어야 할 필요는 없고 관심있는 부분만 골라봐도 됩니다. 읽다보면 하나하나 빼지않고 읽는 부분도 있었지만 머리에 잘 안들어오거나 체감이 안되어서 슥 넘어가는 부분도 있었습니다.

그러나, 전체적으로 제가 느낀 것은 과거와의 호환성 때문에 이제는 버려야 하는 방식을 고집하지 말고 새 술은 새 부대에 이런 방식으로 담자는 내용이 담긴 책이라고 봅니다. 하지만, 중요한 메시지를 보내는 대상으로는 이제 C++ 을 배워서 작성하는 사람들보다는 레거시 코드와 함께 일해야 하는 사람들, 다른 언어에서는 없는 함정이 숨어있는지 모르는 사람들에게 더욱 도움이 될 책이라고 봅니다. 이 책을 읽고 C++ core guideline 전문으로 확대해 보는 것도 좋겠지요.

읽으면서 참 희한한 것 때문에 발목 잡히는 경우도 있구나 하는 생각이 자주 들었습니다. 그만큼 길들이기 어려운 역사와 전통을 자랑하는(?) C++이기 때문이겠지요. 아름답지 않은 코드가 많은 C++이기에 이제부터라도 “아름답게” 써보자는 책이기도 합니다. 좋은 책을 리뷰할 기회를 준 제이펍에 감사드립니다.

Part 1. 사소한 것 때문에 중요한 문제를 놓치지 말자

이 Part에는 사소한 부분이라 신경쓰지 않다가 의외의 뒤통수를 맞는 부분에 대해서 사례와 함께 설명이 되어 있습니다. 개인적으로 F.51과 C.45가 유익했습니다. C++ 관련해서는 늘 과거와의 호환성을 유지해야 한다는 “절대명제”가 수많은 버그와 문제를 일으킨다고 봅니다. 특히, C와의 호환성을 유지하기 위한 여러가지는 더더욱 그렇습니다. 물론, 과거의 수 많은 레거시 코드와 호환이 안 되면 어떻게 하느냐!도 맞는 말인데, 뭐 현재 모던 C++부터 배워서 시작하는 사람은 되도록이면 레거시 코드와 상호작용을 해야 할 때 주의해야 할 부분을 이런 가이드라인에서 신경써서 보는 것이 좋다고 생각합니다.

1.2장: F.51 - 선택의 여지가 있을 때는 오버로딩보다 기본 인수를 선호하라

이 장에서는 기본 인수를 사용하는 것과 함수 오버로딩 간의 설계 선택을 다룹니다. 기본 인수가 함수 오버로딩에 비해 더 간단하고 이해하기 쉬운 API를 제공할 수 있다고 설명합니다.

주요 내용:

  • 기본 인수: 기본 인수를 사용하면 여러 오버로드된 함수보다 명확하고 간결하게 함수의 매개변수를 정의할 수 있습니다.
  • 오버로딩의 위험: 오버로딩은 암묵적 변환을 통해 복잡성과 모호성을 초래할 수 있으며, 이는 잠재적인 버그로 이어질 수 있습니다.
  • 아래와 같은 암묵적 변환의 골때림을 사례로 접하니 더더욱 머리가 아팠습니다. 실전에서 이런 버그를 만나면 얼마나 머리가 아플까요?

  • 암묵적 변환의 결과로 원하지 않는 오버로딩된 함수가 호출되는 결과

1.4장: C.131 - 자명한(trivial) Getter와 Setter를 피하라

이 장에서는 의미 있는 캡슐화나 추상화를 제공하지 않는 사소한 getter와 setter 사용을 피해야 한다고 조언합니다. 뭐든 외부로 노출되어 있는 것은 getter와 setter로 감싸야 한다고 배워서 실제로도 그렇게 짜면서도 왜 이렇게 하지 하는 생각이 늘 들었는데 여기서 명확히 해 주네요.

주요 내용:

  • 캡슐화: 자명한 getter와 setter는 클래스 인터페이스에 추가적인 가치를 제공하지 않으며, 공개 데이터 멤버로 대체할 수 있습니다.
  • 클래스 불변성: 클래스의 불변성을 유지하고 제한 조건 및 비즈니스 로직을 적용하기 위해 setter를 사용해야 한다고 강조합니다.
  • 추상화: 좋은 클래스 설계는 raw 데이터를 getter와 setter를 통해 노출하기보다는 행동과 동작을 추상화하는 데 중점을 두어야 합니다.
  • 명명 규칙: get/set 접두사를 피하고 문제 도메인에서의 목적을 반영하는 멤버 함수에 설명적인 이름을 사용할 것을 권장합니다.


Part 2: 자기발등을 찍지말라

2장은 유지보수 가능하고 견고하며 효율적인 코드를 작성하기 위해 복잡한 구조를 캡슐화하고, 함수 인수를 현명하게 관리하며, 안정적인 ABI를 보장하는 방법에 중점을 둡니다. 이 Part는 복잡성을 줄이고 C++ 프로그래밍에서 흔히 발생하는 함정을 피하는 것을 강조합니다.

인상깊은 내용은 2.3장과 2.4장이었습니다. 크로스 컴파일하는 환경에서 일하지 않았기에 2.3장의 내용은 실전에서 마주친다면 수렁에 빠지는 기분이었을 거 같습니다. 덕분에 이런 부분을 신경써서 체크해야 하는 구나 하는 것을 배웠습니다. 2.4장은 뭐랄까….. 조금 방심하면 뒤통수를 때리는 존재를 데리고 일해야 하는 느낌이랄까? 예제를 보면서 그런 느낌이 들었습니다. 왜 이런 규칙이 존재하는 것일까요? 그리고, 우리는 왜 이 부분에 대해서 제대로, 확실히 배운적이 없을까요?? 이 Part에서는 이 두 가지 배운 것으로도 충분했습니다.

2.3장: I.26 - 크로스 컴파일러 ABI가 필요하면 C 스타일 서브셋을 사용하라

  • ABI 안정성: 이 장에서는 크로스 컴파일러 사용을 위한 라이브러리를 만들 때 안정적인 ABI를 유지하는 것의 중요성을 논의합니다. ABI는 이진 수준에서 소프트웨어 간의 상호작용을 정의하며, ABI 안정성을 보장하는 것은 장기적인 호환성을 위해 매우 중요합니다.
  • 예제: 이 장에서는 std::string을 시그니처로 사용하는 라이브러리 함수의 예를 제공합니다. std::string 구현의 변경은 다른 컴파일러나 버전 간에 사용될 때 ABI 문제가 발생할 수 있습니다. 이 장에서는 크로스 컴파일러 ABI 호환성을 위해 C 스타일의 char* 및 int 타입을 사용할 것을 제안합니다.
  • 고정 폭 정수 타입: 이 장에서는 <cstdint>에서 제공하는 고정 폭 정수 타입(int32_tuint8_t 등)을 사용하여 플랫폼 간 일관된 데이터 크기를 보장하고 ABI 관련 문제를 피할 것을 권장합니다. 오래된 언어인 C++에서는 많은 플랫폼에서 다양한 변종(?)의 타입이 사용되었고 이것이 만약 지금에도 사용되는 레거시 코드라면 생각지 못한 부분에서 문제를 발생시킬 수 있음을 배웠습니다.
  • 예외 처리: 이 장에서는 예외 처리가 ABI 안정성에 미치는 영향에 대해서도 언급합니다. 예외를 던지지 않는 함수를 나타내는 noexcept를 사용하여 안정적인 ABI를 유지할 것을 제안합니다.
  • 요약: 크로스 컴파일러 ABI 안정성을 위해 C 스타일 서브셋(C의 primitive type)을 사용하고, 라이브러리 인터페이스에서 복잡한 C++ 타입을 피하여 다양한 컴파일러와 플랫폼 간의 호환성을 보장하는 것이 핵심입니다.


2.4장: C.47 - 멤버 선언한 순서대로 데이터 멤버를 정의하고 초기화하라

  • 초기화 순서: 이 장에서는 클래스 멤버 변수를 선언된 순서대로 초기화하는 것이 중요하다고 강조합니다. C++는 멤버가 선언된 순서대로 초기화된다는 것을 보장하여 일관성을 유지하고 예기치 않은 동작을 방지합니다.
  • 예제: 이 장에서는 멤버 초기화 순서를 변경하여 잘못된 동작이 발생하는 클래스의 예를 제공합니다. 멤버 함수를 초기화 중에 호출할 때 발생할 수 있는 잠재적인 함정과 초기화 순서를 이해하는 것이 중요합니다.
    • 아래처럼 단지 생성자 본문에서 초기화 하던 것을 초기화 리스트로 옮겼더니 (아래코드) 버그가 발생!! (아, 생각만 해도 두통이 ㅠㅠ). 당연히 아무 문제 없어야 하는데 왜 컴파일 에러가?? → 멤버 변수가 선언된 순서대로 초기화를 해야 한답니다. 순서를 어길 경우 버그가 터질 수 있답니다! (세상에나)
  • 결정적 소멸: 이 장은 결정적 소멸에 대한 논의로 마무리되며, 객체는 생성의 역순으로 소멸(이거 항상 중요하다고 배웠죠!) 되어야 하며, 이는 자원 정리와 효율적인 자원 관리를 보장합니다.
  • 요약: 멤버 변수를 선언 순서에 따라 정의하고 초기화하며, 메모리 레이아웃과 정렬을 이해하고, 결정적 소멸을 활용하여 효율적인 자원 관리를 추구하는 것이 중요하다고 강조합니다.

Part 3 : 그만 사용하라

이 장의 제목만 봐도 알 수 있듯이 안전한 코드를 쓰기 위해서는 하지 말아야 할 것이 있습니다. 과거에는 하지마라까지 아니었기 때문에 사용했으나 이제는 그 폐해가 밝혀져서 단호히 “이젠 사용하지마라”라고 할 만한 정도로 얘기하는 내용들입니다.

Chapter 3.1: I.11 - 절대로 원시포인터(T*)나 참조(T&)로 소유권을 넘기지 말라

  • 동적 메모리 관리: 이 장에서는 C++에서 동적 메모리를 사용할 때 소유권과 관련된 문제점을 설명합니다. 동적 메모리는 명시적으로 해제하지 않으면 메모리 누수가 발생할 수 있으며, Raw 포인터를 사용하여 메모리 소유권을 전달하는 것은 위험합니다.
  • 예제: 함수가 new 키워드를 사용하여 메모리를 할당한 후 포인터를 반환하는 경우, 호출자가 해당 메모리를 관리해야 하며, 이는 소유권의 모호성과 메모리 누수로 이어질 수 있습니다.
  • 스마트 포인터std::unique_ptr 및 std::shared_ptr와 같은 스마트 포인터를 사용하여 소유권을 명확하게 관리할 수 있습니다. std::unique_ptr은 복사할 수 없고 이동만 가능하며, std::shared_ptr은 소유권을 공유하여 객체가 더 이상 필요 없을 때 안전하게 삭제됩니다.
  • GSL.owner: GSL(Guidelines Support Library)은 소유권을 나타내기 위해 gsl::owner와 같은 타입을 제공하며, 이는 코드를 명확하게 만들고 정적 분석 도구의 효과를 높입니다.

→ Raw 포인터나 참조를 통해 소유권을 추론하지 말고, 스마트 포인터를 사용하십시오.


Chapter 3.2: I.3 - 싱글턴을 피하라

  • 글로벌 객체 문제: 글로벌 객체는 프로그램의 모든 곳에서 접근할 수 있으며, 소유권이 불분명하고, 초기화 순서 문제를 일으킬 수 있습니다.
  • 싱글톤 패턴: 싱글톤은 특정 클래스의 인스턴스를 하나만 생성하도록 제한하는 디자인 패턴이지만, 이는 초기화 순서 문제를 야기할 수 있습니다.
  • Meyers Singleton: C++11 이후로는 static 키워드가 붙은 함수 내에서 객체를 생성하여 초기화 순서 문제를 피할 수 있지만, 이는 여전히 멀티스레딩 환경에서 안전하지 않을 수 있습니다.

→ 네임스페이스 사용: 싱글톤 대신 네임스페이스를 사용하여 싱글톤 패턴을 구현하는 것이 좋습니다. 네임스페이스는 멀티스레드 환경에서 더 안전한 대안을 제공합니다.


Chapter 3.4: ES.50 - const를 형 변환하지 말라

  • const의 중요성const는 인터페이스를 보기와 제어로 나누어 주며, 사용자가 더 쉽게 배울 수 있게 합니다.
  • 게임 개발 예시: 멀티플레이어 게임에서 각 클라이언트는 동일한 상태를 유지해야 하므로, const를 사용하여 모델과 뷰를 분리해야 했습니다.
  • const_cast 사용 금지const_cast를 사용하여 const를 제거하는 것은 매우 위험합니다. 이는 코드의 명확성을 해치고, 동기화 문제를 일으킬 수 있습니다.
  • 이중 인터페이스 구현const와 non-const 멤버 함수를 함께 구현하여 인터페이스를 분리할 수 있습니다.


Part 4 : 새로운 기능을 제대로 사용하라

이번 Part는 현대 C++ 기능을 활용하여 더 깔끔하고, 안전하며, 효율적인 코드를 작성하는 데 중점을 둡니다. 여러 반환 값을 처리하기 위해 구조체나 튜플을 사용하는 것, 범위가 있는 열거형을 선호하는 것, 범위를 작게 유지하는 것, 그리고 컴파일 타임 계산을 위해 constexpr를 활용하는 등의 모범 사례를 다루고 있습니다. 이러한 지침을 따르면 개발자는 C++ 프로그램의 가독성, 유지보수성, 성능을 향상시킬 수 있습니다.

Chapter 4.1: F.21 - ‘출력값’을 여러 개로 반환하려면 구조체로 반환하라

  • 함수 시그니처: 함수는 일반적으로 여러 개의 인수를 받아서 하나의 값을 반환합니다. 이러한 제한으로 인해 에러 조건을 처리하거나 여러 값을 반환할 때 어려움이 생길 수 있습니다.
  • 구조체와 튜플 사용: C++11 이후, 구조체나 튜플을 사용하여 여러 값을 반환하는 것이 더 효율적입니다. 반환값 최적화(Return Value Optimization, RVO)와 이동 생성자가 이 과정에서 성능을 향상시킬 수 있습니다.
  • 예제: 반환된 객체가 유효함을 나타내기 위해 특별한 제로 에러 코드를 사용하여 에러가 없음을 아래의 예제처럼 알릴 수 있습니다.
  • std::pair<BigObj, error_code> do_stuff(int a, int b) {
  •   // 입력 유효성 검사 후
  •   return { {a, b}, {error} };
  • }

  • 구조체와 튜플의 차이: 반환 값들이 논리적으로 관련이 있다면, 구조체를 사용하여 추상화를 명확하게 하고, 그렇지 않다면 튜플을 사용할 수 있습니다.

Chapter 4.2: Enum.3 - 단순 열거형 보다는 클래스 열거형을 택하라

  • 상수의 역사: 과거에는 전처리기 매크로를 통해 상수를 정의했지만, 이는 타입과 범위가 없고 오류를 일으킬 수 있었습니다.
  • 전역 범위 문제: 전역 범위에서 선언된 상수는 어디서나 접근 가능하지만, 이는 좋은 설계가 아닙니다.
  • 범위가 있는 열거형: C++11에서는 범위가 있는 열거형(enum class)이 도입되어, 각 열거형을 구분할 수 있는 명확한 범위를 제공합니다.
  • 암시적 변환 방지enum class를 사용하면 열거형과 정수 간의 암묵적 변환을 방지하여 타입 안전성을 높일 수 있습니다.


Chapter 4.4: Con.5 - 컴파일 타임에 계산할 수 있는 값은 constexpr을 사용하라

  • const에서 constexpr로constexpr는 C++11에서 도입된 키워드로, 컴파일 시간에 평가될 수 있는 상수를 정의하는 데 사용됩니다.
  • 컴파일 시간 프로그래밍constexpr는 컴파일 시간에 함수와 표현식을 평가할 수 있게 하여, 코드의 효율성을 높이고 오류를 줄입니다.
  • 제약과 확장: C++14에서는 단일 표현식 제한이 해제되어, 더 복잡한 constexpr 함수와 라이브러리를 작성할 수 있게 되었습니다. C++20에서는 constexpr STL 알고리즘과 동적 할당도 가능해졌습니다.
  • 기본 C++constexpr 사용은 타입 안전성과 성능을 향상시켜 주며, 새로운 디폴트가 되어야 한다고 제안됩니다.


Part 5 : 기본적으로 코드를 잘 작성하라

기본적으로 잘 작성된 코드는 아래와 같은 내용으로 구성되어야 합니다. 이 내용은 “기본”이 되어야 하는 내용입니다.

5.1장: P.4 - 프로그램은 최대한 정적으로 타입에 안전해야 한다

  • Auto 키워드: C++의 auto 키워드는 타입 선언을 단순화하여 컴파일러가 타입을 추론하게 하여, 타입 관련 오류의 가능성을 줄입니다.
  • 공용체와 Variant: C 스타일의 유니언은 동일한 메모리 공간을 다른 타입이 차지하게 하여 타입 안전성을 해칠 수 있지만, C++17은 std::variant를 도입하여 런타임에 타입을 알 수 있는 안전한 타입 처리를 제공합니다.
  • 형변환 : C++는 여러 캐스팅 연산자(static_castdynamic_castconst_castreinterpret_cast)를 제공하여 타입 변환을 처리합니다. 이러한 캐스트는 잘못 사용하면 타입 안전성을 해칠 수 있으므로 주의해서 사용해야 합니다.
  • 부호 없는 타입부호 없는 타입은 특히 부호 있는 타입과 혼합될 때 미묘한 버그를 일으킬 수 있습니다. 주로 비트 조작이나 하드웨어 레지스터와 상호작용할 때 사용해야 합니다.  이런 내용을 신경써야 하는 상황이 된다면 너무 싫을거 같습니다.


5.2장: P.10 - 가변데이터보다는 불변 데이터를 택하라

  • 불변 데이터: 불변 데이터는 이해하고 유지보수하기가 더 쉽습니다. C++는 기본적으로 변경 가능한 객체를 제공하지만, const를 사용하여 불변성을 강화하면 프로그램이 더 안전해지고 인지적 부담이 줄어듭니다. → Rust처럼 기본이 불변으로 하는 것까지는 아니라도 최대한 immutable하게 데이터를 다루어야 한다는 것에는 매우 동의합니다.
  • 상수 정확성: 가능한 경우 객체와 함수를 const로 선언하여 객체의 상태가 예상치 못하게 변경되지 않도록 합니다. 이는 버그를 예방하고 코드 예측 가능성을 높입니다.
  • 함수에서의 Const 자격: 함수가 객체의 상태를 수정하지 않는 경우 const로 선언해야 합니다. 이는 API 설계에서 함수의 동작을 사용자에게 전달하는 데 중요합니다.
  • 함수 매개변수: 불필요한 복사를 피하고 함수 호출자에게 불변성을 신호하기 위해 매개변수를 const 참조나 포인터로 전달하는 것이 좋습니다.

→ 할 수 있는 모든 곳에 const를 붙여보고 에러나면 제거하는 게 어떨까 싶습니다.

5.4장: ES.22 - 값으로 초기화하가 전까지는 변수를 선언하지 말라

  • 변수 초기화: 변수를 초기화할 값이 있을 때까지 선언을 지연하면 코드의 명확성과 안전성을 개선하고 초기화되지 않은 변수를 사용하는 위험을 줄입니다.
  • C 스타일 선언 피하기: C 스타일 프로그래밍처럼 함수의 상단에 모든 변수를 선언하면 사용되지 않는 변수가 생기고 코드의 가독성이 떨어질 수 있습니다.
  • 선언 후 초기화: 현대 C++는 필요한 경우 변수를 선언하고 의미 있는 값으로 초기화하는 것을 지원합니다. 이 접근 방식은 오류를 줄이고 유지보수성을 개선합니다.
  • 상태 감소: 지역 스코프와 즉시 초기화를 사용하여 함수 내 상태를 최소화합니다. 이는 인지적 부담과 오류 가능성을 줄입니다.

→ C++의 초기화는 다른 언어에 비하면 초기화 방법도 많고 방법마다 미묘한 차이를 발생시킬 수도 있어서 악명이 높습니다. 이런 가이드라인은 기초적이지만 아주 영향력이 크다고 생각합니다.

5.6장: E.6 - RAII를 사용하여 리소스 누수를 방지하라

  • 리소스 관리: RAII는 C++의 기본적인 관용구로, 리소스를 안전하게 관리하고 누수를 방지합니다. 객체 수명 주기에 리소스 획득을 연결하여 더 이상 필요하지 않은 경우 리소스를 자동으로 해제합니다.
  • 스마트 포인터: 스마트 포인터(std::unique_ptrstd::shared_ptr)를 사용하여 동적 메모리를 안전하게 관리하고 메모리 누수를 방지하며 적절한 정리를 보장합니다.
  • 예외 안전성: RAII는 예외가 발생할 때 리소스를 자동으로 해제하여 누수를 방지하고 프로그램 안정성을 보장합니다.


한번 읽고 모든 것을 이해할 수준이 안 되어서 앞으로 두고 두고 찾아보면서 참고하려고 합니다. 다시 한번 좋은 책을 리뷰하게 해 주신 제이펍에 감사드립니다.


f******s 2024.08.05. 신고 공감 0 댓글 0
리뷰 총점 종이책
[서평] 아름다운 C++
"[서평] 아름다운 C++" 내용보기
몇 달 전 회사에 취업하게 되어 python과 C++을 공부하게 되었습니다. python은 예전부터 했기 때문에 문제 없이 사용하였지만 C++인 경우 MFC만 사용하였기에 C++ 그 자체로는 처음이었습니다. 책을 읽으면서 든 생각들은 제가 정말 아는 것 하나 없이 들어왔구나 라는 생각이 들더군요. 반대로 책에서 나온 내용들을 찾아가 보며 기능들도 새로 익힐 수 있고, 팁을 얻을 수 있었던 것
"[서평] 아름다운 C++" 내용보기
몇 달 전 회사에 취업하게 되어 python과 C++을 공부하게 되었습니다. python은 예전부터 했기 때문에 문제 없이 사용하였지만 C++인 경우 MFC만 사용하였기에 C++ 그 자체로는 처음이었습니다.
 책을 읽으면서 든 생각들은 제가 정말 아는 것 하나 없이 들어왔구나 라는 생각이 들더군요. 반대로 책에서 나온 내용들을 찾아가 보며 기능들도 새로 익힐 수 있고, 팁을 얻을 수 있었던 것 같습니다.
w*******1 2024.08.02. 신고 공감 0 댓글 0
리뷰 총점 종이책
[서평] 아름다운 C++/ 제이펍
"[서평] 아름다운 C++/ 제이펍" 내용보기
<<아름다운 C++>>은 C++을 처음 접하거나 깊이 있게 공부해본 경험이 없는 독자들에게는 도전적일 수 있습니다.제이펍은 책 뒤에 난이도를 표기하고 있어,책을 선택할 때 참고하기 좋습니다.프로그래밍 언어는 시간이 지남에 따라 변화합니다. 인간의 자연어와 마찬가지로, 프로그래밍 언어도 시대에 따라 문법이 바뀌고 새로운 기능이 추가됩니다. 새로운 언어가 등장하기도 하며,
"[서평] 아름다운 C++/ 제이펍" 내용보기


<<아름다운 C++>>은 C++을 처음 접하거나 
깊이 있게 공부해본 경험이 없는 독자들에게는 도전적일 수 있습니다.


제이펍은 책 뒤에 난이도를 표기하고 있어,
책을 선택할 때 참고하기 좋습니다.



프로그래밍 언어는 시간이 지남에 따라 변화합니다. 
인간의 자연어와 마찬가지로, 
프로그래밍 언어도 시대에 따라 문법이 바뀌고 새로운 기능이 추가됩니다. 

새로운 언어가 등장하기도 하며, 
기존 언어의 버전별로 기능이 달라지기도 합니다. 
이러한 변화는 빠르고 뚜렷하게 나타나므로, 
최신 표준을 유지하는 것이 중요합니다.

그러나 과거의 언어와 그 발전 과정을 이해하는 것도 필요합니다.
고대 및 중세 언어를 배우는 것처럼, 
C++의 역사와 발전 과정을 아는 것은 이 언어의 목적과 기능을 이해하는 데 도움이 됩니다.

최신 표준을 사용하는 것은 여러 면에서 유리합니다. 
향상된 기능과 성능, 코드의 안전성 및 안정성 등 많은 이점이 있지만, 
실무 환경에서는 최신 표준을 적용하기 어려운 경우도 있습니다. 
규제나 인증 과정에서 구버전을 사용해야 하는 상황도 존재합니다.

저자들은 표준 C++의 채택이 코드의 품질을 어떻게 향상시킬 수 있는지를 명확히 설명하며, 
오버로딩 대신 기본 인수를 사용하는 방법과 기본 멤버 초기화의 중요성을 강조합니다. 


이러한 지침은 코드 작성 시 자주 간과할 수 있는 세부 사항들을 점검하게 하며, 
실제 프로그래밍에서 오류를 예방하는 데 중요한 역할을 합니다. 
이러한 접근은 C++ 프로그래머들이 코드의 기본 구조를 이해하고, 
불필요한 복잡성을 제거하는 데 유용합니다.

또한,  "그만 사용하라"는 주제로, 
구식 기능을 피하고 현대적인 대안을 사용하라는 권고를 담고 있습니다. 
특히 원시 포인터와 싱글턴 패턴의 사용에 대한 경각심을 일깨우며, 
최신 C++의 특징과 장점을 잘 활용할 수 있는 방법을 설명합니다. 

저자들은 메모리 누수와 같은 문제를 방지하기 위해 RAII패턴의 중요성을 부각시키며, 
현대 C++에서의 올바른 메모리 관리 방법을 제시합니다. 
또한, memset과 memcpy의 사용을 피하고, 
생성자와 할당 연산자를 통해 보다 안전하고 명확한 코드 작성을 권장합니다. 
이러한 지침은 코드의 안정성과 가독성을 높이며, 유지보수를 용이하게 만듭니다.
이 책은 C++의 복잡성과 다양성을 인정하면서도,
최신 언어 기능과 방법론을 통해 코드를 정돈하고 최적화하는 방안을 제시합니다. 
특히 Part 1과 Part 3의 접근법은 
프로그래머들에게 코드의 기본 원칙과 최신 기술을 동시에 고려하며, 
코드 품질을 향상시킬 수 있는 실용적인 지침을 제공합니다. 

<<아름다운 C++>>은 
초보자부터 전문가까지 폭넓은 독자층에게 유용하며, 
코드 작성에 있어 깊이 있는 이해와 실용성을 동시에 추구할 수 있도록 돕습니다.
 C++ 프로그래밍의 본질을 재조명하며 고품질 소프트웨어 개발을 위한 강력한 지침이 될 것입니다.


▶▶ 이 리뷰는 출판사에서 도서를 제공 받아, 직접 읽고 작성한 리뷰입니다.


#아름다운C++  #박지윤 #가이데이비드슨 #가이_데이비드슨 #케이트_그레고리 #케이트그레고리 #개발자 #프로그래밍 #코딩 #소프트웨어 #C++ #Jpub #제이펍


n*********a 2024.08.02. 신고 공감 0 댓글 0
리뷰 총점 종이책
아름다운 C++을 위해서
"아름다운 C++을 위해서" 내용보기
#제이펍 #C++ #아름다운C++저자들은 독자에게 상황을 제시하며, 재밌는 스토리텔링으로 가이드라인을 간과한 코드가 어떻게 실패하는지 보여준다. 그로부터 우리는 저자들과 함께, "아름다운" C++ 코드는 어떻게 작성해야 하는지 가이드라인을 같이 만들어갈 수 있다. 이를 통해 우리는 코드의 기능을 단편적으로 해석하는 것이 아니라, 코드의 의도를 읽고 코드 작성자와 대화를 할 수
"아름다운 C++을 위해서" 내용보기
#제이펍 #C++ #아름다운C++

저자들은 독자에게 상황을 제시하며, 재밌는 스토리텔링으로 가이드라인을 간과한 코드가 어떻게 실패하는지 보여준다. 그로부터 우리는 저자들과 함께, "아름다운" C++ 코드는 어떻게 작성해야 하는지 가이드라인을 같이 만들어갈 수 있다. 이를 통해 우리는 코드의 기능을 단편적으로 해석하는 것이 아니라, 코드의 의도를 읽고 코드 작성자와 대화를 할 수 있는 엔지니어로 거듭날 수 있을 것이다.

책은 https://isocpp.github.io/CppCoreGuidelines/ 에서 명시되어 있는 가이드라인 중 저자들이 특별히 30개를 선정하여 작성되었다. 하지만 이들이 연관성이나 종속성을 크게 띄고 있는 것은 아니며 중요도가 특별히 높은 것은 아니라고 저자들도 말한다. 다만, 이 책에 등장한 것을 염두에 둔다면 이전보다도 훨씬 더 나은 코드를 작성할 수 있는 내용들이 풀어져 있다. 그뿐 아니라 C++이 등장한 이래 C++23이 작년에 확정되고 C++26을 바라보고 있는 지금, 하위 호환성부터 deprecate되거나 대체 가능한 기능들이 무엇이 있는지도 알려준다.

이 책은 C++을 처음 시작하는 초심자인 독자에게는 추천하지 않고, C++를 어느 정도 알고 있는 중급자부터 도움이 많이 되는 책이라고 생각한다. 한번에 읽으려고 할 수 있는 책이 아니며, 여러 번 곱씹어보면서 코드를 돌아보고 발전해나갈 수 있는 책일 것이다.

- 사소한 것 때문에 중요한 문제를 놓치지 말자.
- 자기 발등을 찍지 말라.
- 그만 사용하라.
- 새로운 기능을 제대로 사용하라.
- 기본적으로 코드를 잘 작성하라.

이 책의 다섯 챕터의 제목을 다시 스스로에게 상기시키면서 C++을 다시 공부해야겠다.


h******4 2024.08.02. 신고 공감 0 댓글 0
리뷰 총점 종이책
C++ 답게 아름다운 C++
"C++ 답게 아름다운 C++" 내용보기
#제이펍 #C++C++언어 아버지 Bjarne Stroustrup는 자신의 홈페이지에서(https://www.stroustrup.com/C++.html)is a better C,supports data abstraction,supports object-oriented programming,supports generic programming.라고 소개하고 있죠그래서 C++ 이라는 이름은 C에 ++연산자를 더해서 붙여진 이름 20여년 전 졸업 논문을 Visual C++로 쓰고 직장에선 Power Builder 같은 4GL이
"C++ 답게 아름다운 C++" 내용보기


#제이펍 #C++

C++언어 아버지 Bjarne Stroustrup는 자신의 홈페이지에서

(https://www.stroustrup.com/C++.html)

is a better C,

supports data abstraction,

supports object-oriented programming,

supports generic programming.

라고 소개하고 있죠

그래서 C++ 이라는 이름은 C에 ++연산자를 더해서 붙여진 이름

 

20여년 전 졸업 논문을 Visual C++로 쓰고 직장에선 Power Builder 같은 4GL이나 PHP, Java 같은 언어를 쓰는 바람에 손을 놓았던 언어였조.

책장에 꽂혀 있는 C++ 책들의 먼지를 털고 얼마나 더 아름답게 뿔뿔(++)해졌는지 알아보려고 이 도서에 도전했지만...

첫 챕터를 읽는 순간 탈탈 멘탈이 털리는 느낌이었죠.

보조로 보려고 책장에서 꺼낸 책들이 너무 구판이고 그동안 많은 진화를 해온 C++언어였습니다.

 

그래서 추천서문, 시작하며 소개의 글부터 다시 읽고 첫 챕터부터 차근차근 읽었습니다. 이 책에서 이해 안되는 부분은 여러 C++ 사이트를 기웃거리며 참조자료를 찾아봤습니다.

 

오버로딩을 잘하면 C++을 잘하는 걸로 알고 있었는데, get() set() 메써드는 기본적으로 작성하던 것인데...

Power Builder 같은 언어에서도 오버로딩 함수들을 제공하고 내장 class에서 get(), set() 계열 메써드를 제공하고 있는...

 

최근 C++을 알고 있었다면 이 책을 더 재미있게 읽었을 것입니다.

하지만 다시 C++을 시작하려고 시도하는 이에게도 유용한 도서가 될 것입니다.

전문 C++ 프로그래머 Guy Davidson과 Kate Gregory 두 명이 30가지 핵심적인 지침을 고르고 C++ 스타일을 개선할 수 있는 상세하고 쉽게 참조할 수 있도록 설명하고 있습니다.

실무에서는 많은 가이드 라인을 제공할 것 같습니다.

이 책에서 설명한 30가지 외 나머지도 홈페이지에서 읽어 보는 것을 권장한다.(https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)

 

이 책을 13페이지의 ‘코드는 코드 자신을 설명 할 수 있어야 한다.’ 글귀가 가슴에 남았습니다.

Keep it simple stupid! 프로그래밍을 공부하면 들었던 KISS 철학과 상통 하기도 합니다.

이 도서의 난이도는 중급으로 표시되어 있다. C++을 시작하는 이에게 이해하기 힘들 수도 있습니다.

시간들을 들여 C++ 입문 최신 판을 구해서 다시 C++을 공부하고 다시 한번 더 이 책을 읽어 봐야겠습니다.


YES마니아 : 플래티넘 t****o 2024.07.31. 신고 공감 0 댓글 0