이직하고 적응하느라 야근 철야.. 1년 반을 그렇게 보냈네요.
작년에 비야네 스트롭스트룹 교수의 The C++ programming Language 4판 원서를 읽었습니다.
올해 1월에 번역서가 나와서 이 책도 구입을 해서 전부 읽었습니다.
중용한 번역서가 나와서 기뻤지만 아쉽게도 번역서는 오타가 참 많더 군요.
읽고 나서 혹시 잘못 번역한 내용으로 내가 잘못 이해하고 있지 않을까 하는 두려움이 있어서 최소한 책의 요약과 같은 advice 부분만은 직접 번역해 보는 것이 좋겠다는 생각이 들었습니다.
하다보니 A Tour of C++와 많이 겹치는 것을 알게 되었습니다.
The C++ programming Language 4판은 번역서가 있어서 아직 번역되지 않은 것을 해보는 것이 좋을 것 같아서 A Tour of C++의 advice 부분만 제 수준에 맞는 발 번역을 해보았습니다.
유려한 의역 보다는 중학교 수준에 맞는 단어와 문법을 활용한 직독 직해 발 번역의 충격을 미리 말씀 드리며...
암튼...
A Tour of C++ Advice번역
1 The Basics
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapters 5-6, 9-10, and 12 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013] 5-6, 9-10, 그리고 12장과 거의 일치한다.
[2] Don't panic! All will become clear in time;
당황하지 말아라. 때가 대면 모든 것이 분명해질 것이다.
[3] You don't have to know every detail of C++ to write good programs.
좋은 프로그램을 작성하기 위해서 C++을 모두 자세히 할 필요는 없다.
[4] Focus on programming techniques, not on language features.
언어의 기능이 아닌 프로그래밍 기법에 집중하라.
[5] For the final word on language definition issues, see the ISO C++ standard;
언어 정의 이슈에 대한 최종 표명에 대해서 ISO C++ 표준을 보라.
[6] "Package" meaningful operations as carefully named functions;
"패키지는" 주의 깊게 명명된 기능들의 의미있는 동작들이다.
[7] A function should perform a single logical operation;
하나의 함수는 단일한 논리적인 연산을 수행해야한다.
[8] Keep functions short;
함수를 짧게 유지하라
[9] Use overloading when functions perform conceptually the same task on different types;
개념적으로 다른 타입에 같은 작업을 함수가 수행할 때 다중 정의(overloading)을 사용하라
[10] If a function may have to be evaluated at compile time, declare it constexpr;
만약 함수가 컴파일 시간에 평가될 수 있다면 이 함수를 constexpr 로 선언하라
[11] Avoid "magic constants;" use symbolic constants;
"마법 상수"를 피하라. 기호 상수를 사용하라
[12] Declare one name (only) per declaration.
(오직) 선언당 하나의 이름을 선언하라
[13] Keep common and local names short, and keep uncommon and nonlocal names longer.
공통으로 사용하는 것과 지역 이름은 짧게 유지하라. 그리고 공통으로 사용하지 않고 비지역적인 이름은 길게 유지하라
[14] Avoid similar-looking names.
비슷하게 보이는 이름은 피하라
[15] Avoid ALL_CAPS names.
"모두_대문자" 이름들은 피하라
[16] Prefer the {}-initializer syntax for declarations with a named type;
이름이 있는 타입에 대해서 {}-초기화 문법을 선호하라
[17] Prefer the = syntax for the initialization in declarations using auto;
auto를 사용한 선언에서 초기화에 대해서 = 문법을 선호하라
[18] Avoid uninitialized variables;
초기화하지 않은 변수들을 피하라
[19] Keep scopes small; §1.6.
(유효)범위를 최소화하라
[20] Keep use of pointers simple and straightforward;
작게 그리고 복잡하지 않게 포인터의 사용을 유지하라
[21] Use nullptr rather than 0 or NULL;
0 이나 NULL 보다 nullptr를 사용하라
[22] Don't declare a variable until you have a value to initialize it with;
변수를 초기화할 값을 가질 때까지 변수를 선언하지 말아라
[23] Don't say in comments what can be clearly stated in code.
코드에서 명확하게 명시해야할 것을 주석에서 말하지 말하라
[24] State intent in comments.
주석에 의도를 명시하라
[25] Maintain a consistent indentation style.
일관된 들여쓰기 스타일을 유지하라
[26] Avoid complicated expressions.
복잡한 표현은 삼가하라
[27] Avoid narrowing conversions;
축소 변환은 피하라
2 User-Defined Types
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapter 8 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013] 8장과 거의 일치한다.
[2] Organize related data into structures (structs or classes);
연관된 데이터를 (구조체 혹은 클래스) 구조 안의 데이터로 구성하라
[3] Represent the distinction between an interface and an implemetation using a class;
클래스를 사용해서 인터페이스와 구현 사이의 분리를 표현하라
[4] A struct is simply a class with its members public by default;
구조체는 모든 멤버가 기본적으로 public인 단순한 클래스이다.
[5] Define constructors to guarantee and simplify initialization of classes;
클래스의 초기화를 보증하고 단순화하기위해서 생성자를 정의하라
[6] Avoid "naked" unions; wrap them in a class together with a type field;
클래스 안에서 타입 필드와 함께 감싼 이름이 없는 공용체는 피하라
[7] Use enumerations to represent sets of named constants;
명명된 상수의 집합을 표현하기 위해서 열거형을 사용하라
[8] Prefer class enums over "plain" enums to minimize surprises;
뜻밖의 사건을 최소화 하기위해서 단순한 enum보다 class enum을 사용하라
[9] Define operations on enumerations for safe and simple use;
안정하고 단순한 사용을 위해서 열거형 동작을 정의하라
3 Modularity
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapters 13-15 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013] 13-15장과 거의 일치한다.
[2] Distinguish between declarations (used as interfaces) and definitions (used as implementations);
(인터페이스로 사용될) 선언과 (구현으로 사용될) 정의를 구분하라
[3] Use header files to represent interfaces and to emphasize logical structure;
인터페이스를 표현하고 지역 구조체를 강조 하기위해서 헤더파일을 사용하라
[4] #include a header in the source file that implements its functions;
함수를 구현하는 원시 파일 안에 헤더파일을 #include 하라
[5] Avoid non-inline function definitions in headers;
헤더에서 비-인라인 함수 정의를 피하라
[6] Use namespaces to express logical structure;
논리적인 구조를 표현하기위해서 이름 공간을 사용하라
[7] Use using-directives for transition, for foundational libraries (such as std), or within a local scope;
전이, 기초 라이브러리(std와 같은), 또는 지역 유효 범위안에서 using-지시문을 사용하라
[8] Don't put a using-directive in a header file;
헤더 파일에 using-지시문을 넣지 말아라
[9] Throw an exception to indicate that you cannot perform an assigned task;
할당된 작업을 수행할 수 없는 것을 나타 내기위해서 예외를 던져라
[10] Use exceptions for error handling;
에러 관리를 위해서 예외를 사용하라
[11] Develop an error-handling strategy early in a design;
(프로그램) 설계에서 에러-처리 전략을 미리 개발하라
[12] Use purpose-designed user-defined types as exceptions (not built-in types);
(기본적으로 제공하는 타입보다) 예외를 목적으로 하는 사용자 정의 타입을 사용하라
[13] Don't try to catch every exception in every function;
모든 함수에서 모든 예외를 잡을려고 하지 말아라
[14] If your function may not throw, declare it noexcept;
함수가 예외를 던지지 않는 다면 nonexcept로 선언하라
[15] Let a constructor establish an invariant, and throw if it cannot;
생성자를 불변성으로 만들어라. 그리고 할 수 없다면 예외를 던져라
[16] Design your error-handling strategy around invariants;
에러-처리 전략과 불변성을 설계하라
[17] What can be checked at compile time is usually best checked at compile time (using static_assert);
(static_assert을 사용해서) 컴파일 시간에 검사될 수 있는 것은 대개 가장 최고의 컴파일 시간 검사이다.
4 Classes
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapters 16-22 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013] 16-22장과 거의 일치한다.
[2] Express ideas directly in code;
아이디어를 코드에 직접 표현하라
[3] A concrete type is the simplest kind of class. Where applicable, prefer a concrete type over more complicated classes and over plain data structures;
구체 타입은 가장 단순한 클래스의 한 종류 이다. 적용할 수 있는 곳에서, 복잡하게 구성된 클래스와 평범한 데이터 구조들보다 구체 타입을 좀 더 선호하라
[4] Use concrete classes to represent simple concepts and performance-critical components;
간단한 concept과 성능-임계 컴포넌트를 표현 하기위해서 구체 클래스를 사용하라
[5] Define a constructor to handle initialization of objects;
객체의 초기화를 관리하기 위해서 생성자를 정의하라
[6] Make a function a member only if it needs direct access to the representation of a class;
오직 클래스의 표현을 직접 접근이 필요한 경우에 함수 멤머를 만들어라
[7] Define operators primarily to mimic conventional usage;
통상적인 사용을 융내내기 위해서 연산자를 우선 정의하라
[8] Use nonmember functions for symmetric operators;
대칭적인 연산에 대해서 비 멤버 함수를 사용하라
[9] Declare a member function that does not modify the state of its object const;
객체 상수화의 상태를 수정하지 않는 멤버 함수를 사용하라
[10] If a constructor acquires a resource, its class needs a destructor to release the resource;
만약 생성자가 자원을 요구한다면 클래스는 자원을 해제 하기위해서 소멸자를 필요로한다.
[11] Avoid "naked" new and delete operations;
무방비의 new와 delete 연산을 피하라
[12] Use resource handles and RAII to manage resources;
자원 관리를 위해서 자원 관리자와 RAII를 사용하라
[13] If a class is a container, give it an initializer-list constructor;
클래스가 컨테이러라면 초기화 리스트 생성자를 주어라
[14] Use abstract classes as interfaces when complete separation of interface and implementation is needed;
완전하게 인터레이스와 구현을 분리하는 것이 필요한 때에 추상 클래스를 인터페이스로 사용하라
[15] Access polymorphic objects through pointers and references;
포인터와 참조자로 다형 객체를 접근하라
[16] An abstract class typically doesn't need a constructor;
추상 클래스는 전형적으로 생성자를 필요로하지 않는다.
[17] Use class hierarchies to represent concepts with inherent hierarchical structure;
계층적인 구조를 상속받는 copncept을 표현하기 위해서 클래스 계층을 사용하라
[18] A class with a virtual function should have a virtual destructor;
가상함수가 있는 클래스는 가상 소멸자를 가져야 한다.
[19] Use override to make overriding explicit in large class hierarchies;
거대한 클래스 계층에서 명시적으로 재정의를 만들기 위해서 override를 사용하라
[20] When designing a class hierarchy, distinguish between implementation inheritance and interface inheritance;
클래스 계층을 설계할 때, 구현 상속과 인터페이스 상속을 구분하라
[21] Use dynamic_cast where class hierarchy navigation is unavoidable;
클래스 계층 탐색을 피할 수 없다면 dynamic_cast를 사용하라
[22] Use dynamic_cast to a reference type when failure to find the required class is considered a failure;
요구하는 클래스 찾기의 실패가 실패로 간주될 때 dynamic_cast를 참조자로 사용하라
[23] Use dynamic_cast to a pointer type when failure to find the required class is considered a valid alternative;
요구하는 클래스 찾기의 실패가 유효한 선택으로 간주될 때 dynamic_cast를 포인터로 사용하라
[24] Use unique_ptr or shared_ptr to avoid forgetting to delete objects created using new;
new를 사용해서 생성한 객체를 소멸하는 것을 잊는 것을 피하고 싶을 때 unique_ptr 또는 shared_ptr를 사용하라
[25] Redefine or prohibit copying if the default is not appropriate for a type;
기본적으로 제공되는 것이 타입에 맞지 않는 다면 재정의하거나 또는 복사를 막아라
[26] Return containers by value (relying on move for efficiency);
(효율적으로 이동 연산에 의존하는) 값으로 컨테이너를 반환하라
[27] For large operands, use const reference argument types;
거대한 피연산자에 대해서, const 참조 인수 타입을 사용하라
[28] If a class has a destructor, it probably needs user-defined or deleted copy and move operations;
만약 클래스가 소멸자를 가지고 있다면 그것은 아마도 사용자 정의 또는 소멸하는 복사 그리고 이동 연산을 필요로할 것이다.
[29] Control construction, copy, move, and destruction of objects;
객체의 생성자, 복사, 이동 그리고 소멸자를 제어하라
[30] Design constructors, assignments, and the destructor as a matched set of operations;
연산과 집합과 일치하는 것 생성자, 대입, 그리고 소멸자를 설계하라
[31] If a default constructor, assignment, or destructor is appropriate, let the compiler generate it (don't rewrite it yourself);
기본 생성자, 대입, 또는 소멸자가 적합하다면 컴파일러가 그것을 만들도록 하라( 이러한 것을 다시 작성할 필요가 없다)
[32] By default, declare single-argument constructors explicit;
기본적으로, 하나의 인수가 있는 생성자는 explict로 선언한다
[33] If a class has a pointer or reference member, it probably needs a destructor and non-default copy operations;
만약 클래스가 포인터나 참조자 멤버를 가지고 있다면, 이것은 아마도 소멸자와 비-기본 복사 연산을 필요로할 것이다.
[34] Provide strong resource safety; that is, never leak anything that you think of as a resource;
강한 자원 안전성을 제공하라; 즉, 결코 누수가 자원으로 생각할 수 없도록 한다.
[35] If a class is a resource handle, it needs a constructor, a destructor, and non-default copy operations;
만약 클래스가 자원 관리자라면, 그것은 생성자, 소멸자, 그리고 비-기본 복사 연산을 필요로할 것이다.
5 Templates
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapters 20-29 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013] 20-29장과 거의 일치한다.
[2] Use templates to express algorithms that apply to many argument types;
많은 인수 타입을 적용하는 알고리즘을 표현하기 위해서 템플릿을 사용하라
[3] Use templates to express containers;
컨테이너를 표현하는 템플릿을 사용하라
[4] Use templates to raise the level of abstraction of code;
코드의 추상화 수준을 올리기 위해서 템플릿을 사용하라
[5] When defining a template, first design and debug a non-template version; later generalize by adding parameters.
첫번째로 비-템플릿 버전을 설계하고 디버깅하라. 후에 인수를 추가해서 일반화하라.
[6] Templates are type-safe, but checking happens too late;
템플릿은 타입-안전이나, 늦게 검사된다.
[7] A template can pass argument types without loss of information.
템플릿은 정보의 손실없이 인수 타입을 전달할 수 있다.
[8] Use function templates to deduce class template argument types;
템플릿 인수 타입을 추론하기 위해서 함수 템플릿을 사용하라
[9] Templates provide a general mechanism for compile-time programming;
템플릿은 컴파일-시간 프로그래밍을 위한 일반화 메커니즘을 제공한다
[10] When designing a template, carefully consider the concepts (requirements) assumed for its template arguments;
템플릿을 설계하는데, concept의 템플릿 인수로 추정된 concept (요구사항)을 주의깊게 고려하라.
[11] Use concepts as a design tool;
컨셉을 설계 도구로 사용하라.
[12] Use function objects as arguments to algoritms;
함수 객체를 알고리즘의 인수로 사용하라
[13] Use a lambda if you need a simple function object in one place only;
오직 한 장소에서 간단한 함수 객체가 필요하다면 람다를 사용하라
[14] A virtual function member cannot be a template member function.
가상 함수 멤버는 템플릿 멤버가 될 수 없다.
[15] Use template aliases to simplify notation and hide implementation details;
표기를 단순화하고 상세한 구현을 숨기기위해서 템플릿 별칭을 사용하라
[16] Use variadic templates when you need a function that takes a variable number of arguments of a variety of types;
다양한 타입의 가변적인 숫자의 인수를 갖고 있는 함수가 필요하다면 가변인수 템플릿을 사용하라
[17] Don't use variadic templates for homogeneous argument lists (prefer initializer lists for that);
동차 인수 리스트에 대해서 가변 인수 템플릿을 사용하지 말아라(동차 인수 리스트에 대해서 초기화 리스트를 선호하라)
[18] To use a template, make sure its definition (not just its declaration) is in scope;
템플릿을 사용하고, (템플릿의 선언이 아닌) 템플릿의 정의는 휴효 범위안에 있도록 확실히 하라.
[19] Templates offer compile-time "duck typing";
템플릿은 컴파일-시간 "덕 타이핍"을 제공한다.
[20] There is no separate compilation of templates: #include template definitions in every translation unit that uses them.
템플릿의 분리 컴파일은 없다: 템플릿을 사용하는 모든 번역 단위 안에서 #include templete 하라
6 Library Overview
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapter 30 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013] 20-29장과 거의 일치한다.
[2] Don't reinvent the wheel; use libraries; §6.1.
수레바퀴를 다시 만들지 말아라; 라이브러리를 사용하라
[3] When you have a choice, prefer the standard library over other libraries;
선택이 있다면, 다른 라이브러리보다 표준 라이브러리를 사용하라
[4] Do not think that the standard library is ideal for everything;
모든 것에서 표준 라이브러리가 이상적일 것이라는 생각은 하지 말아라
[5] Remember to #include the headers for the facilities you use;
당신이 사용하고 있는 기능들에서 #include 헤더를 기억하라
[6] Remember that standard-library facilities are defined in namespace std;
표준 라이브러리 기능은 namespace std; 안에 정의 되어 있다.
7 Strings and Regular Expressions
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapters 36-37 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013] 36-37장과 거의 일치한다.
[2] Prefer string operations to C-style string functions;
C-스타일의 함수보다 (std)string 연산을 선호하라
[3] Use string to declare variables and members rather than as a base class;
기반 클래스로보다 변수와 멤버를 선언하는 것으로 (std)string을 사용하라
[4] Return strings by value (rely on move semantics);
값으로 (이동 의미 구조를 의존하는)string을 반환하라
[5] Directly or indirectly, use substr() to read substrings and replace() to write substrings;
직접 혹은 간접적으로 하부 문자열을 읽기위해서 substr()을 사용하고 하부 문자열을 쓰기 위해서replace()를 사용하라
[6] A string can grow and shrink, as needed;
필요에따라 string은 (메모리가) 커지거나 줄어든다
[7] Use at() rather than iterators or
[] when you want range checking;
범위 검사가 필요할 때 반복자나
[]보다 at()을 사용하라
[8] Use iterators and
[] rather than at() when you want to optimize speed;
속도 최적화를 원한다면 at()보다 반복자와
[]을 사용하라
[9] string input doesn't overflow;
표준 input은 오버플로하지 않는다.
[10] Use c_str() to produce a C-style string representation of a string (only) when you have to;
(오직) 필요한 경우의 문자열에만 C-스타일 문자열 표현을 생성하기 위해서 c_str()을 사용하라
[11] Use a string_stream or a generic value extraction function (such as to<X>) for numeric conversion of strings;
string의 수치변환에 대해서 string_stream 또는 일반화 값 추출 함수(to<X>와 같은)를 사용하라.
[12] A basic_string can be used to make strings of characters on any type;
basic_string 은 어떤 타입의 문자들로 문자열을 만드는 것으로 사용될 수 있다.
[13] Use regex for most conventional uses of regular expressions;
가장 통상적인 정규 표현의 사용으로 regex 를 사용하라
[14] Prefer raw string literals for expressing all but the simplest patterns;
가장 단순한 패턴을 제한 모두를 표현하는 것으로 가공되지 않은 문자열을 선호하라
[15] Use regex_match() to match a complete input;
입력과 완전히 일치하는 것에 regex_match()을 사용하라
[16] Use regex_search() to search for a pattern in an input stream;
입력 스트림안에 찾고자 하는 패턴에 regex_search()을 사용하라
[17] The regular expression notation can be adjusted to match various standards;
정규 표현 표기법은 다양한 표준에 맞추기 위해서 조정될 수 있다.
[18] The default regular expression notation is that of ECMAScript;
기본 정규 표현 표기법은 ECMA 스크립트이다.
[19] Be restrained; regular expressions can easily become a write-only language;
제한하라; 정규 표현은 쉽게 쓰기-전용 언어가 될 수 있다.
[20] Note that \i allows you to express a subpattern in terms of a previous subpattern;
\i는 이전 부분 패턴의 관점에서 부분 패턴을 표현할 수 있게함을 주목하라
[21] Use ? to make patterns "lazy";
"게으른" 패턴을 만들기 위해서 ?을 사용하라
[22] Use regex_iterators for iterating over a stream looking for a pattern;
패턴을 검색하는 스트림 순회로 regex_iterator를 사용하라
8 I/O Streams
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapter 38 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013] 38장과 거의 일치한다.
[2] iostreams are type-safe, type-sensitive, and extensible;
iostream은 타입에 안전하고, 타입에 민감하며, 확장성이 있다.
[3] Define << and >> for user-defined types with values that have meaningful textual representations;
의미있는 텍스트의 표현을 가지는 값이 있는 사용자 정의 타입을 위해서 << 와 >>을 정의하라
[4] Use cout for normal output and cerr for errors;
일반적인 출력에서 cout을 사용하고 에러에 대해서 cerr를 사용하라
[5] There are iostreams for ordinary characters and wide characters, and you can define an iostream for any kind of character;
일반 문자에 대한 것과 확장문자에 대한 iostream이 있으며, 어떤 종류의 문자에 대해서 iostream을 정의 할수 있다.
[6] Binary I/O is supported;
이진 I/O는 제공이 된다.
[7] There are standard iostreams for standard I/O streams, files, and strings;
표준 I/O 스트림, 파일, 그리고 문자열에대한 표준 iostream이 있다.
[8] Chain << operations for a terser notation;
좀더 간결한 표기를 위해서 << 연산자를 연쇄적으로 사용하라
[9] Chain >> operations for a terser notation;
좀더 간결한 표기를 위해서 >> 연산자를 연쇄적으로 사용하라
[10] Input into strings does not overflow;
string으로 입력은 오버플로가 없다
[11] By default >> skips initial whitespace;
기본적으로 >> (연산자)는 초기 공백을 지나친다.
[12] Use the stream state fail to handle potentially recoverable I/O errors;
잠재적으로 극복할 수 있는 I/O 에러를 관리하기위해서 스트림 상태 실패를 사용하라
[13] You can define << and >> operators for your own types;
당신의 자신의 타입으로 <<와 >> 연산자를 정의할 수 있다.
[14] You don't need to modify istream or ostream to add new << and >> operators;
새로운 <<와 >>연산자를 추가하기 위해서 istream이나 ostream을 수정할 필요는 없다.
[15] Use manipulators to control formatting;
서식화를 제어 하기 위해서 조작자를 사용하라
[16] precision() specifications apply to all following floating-point output operations;
precision() 명세는 모든 딸려오는 부동소수점 출력 연산에 적용된다.
[17] Floating-point format specifications (e.g., scientific) apply to all following floating-point output operations;
부동소수점 서식 명세는(예를 들어 scientific) 모든 딸려오는 부동소수점 출력 연산에 적용된다.
[18] #include <ios> when using standard manipulators;
표준 조작자를 사용할 때 #include <ios>하라
[19] #include <iomanip> when using standard manipulators taking arguments;
인수를 가진 표준 조작자를 사용할 때 #include <iomanip>하라
[20] Don't try to copy a file stream.
파일 스트림 복사를 시도하지 말아라
[21] Remember to check that a file stream is attached to a file before using it;
파일 스트림을 사용하기 전에 파일에 파일 스트림 부착 검사를 기억하라
[22] Use stringstreams for in-memory formatting;
메모리-내부 서식화에서 stringstreams을 사용하라
[23] You can define conversions between any two types that both have string representation;
둘다 문자열 표현을 가지는 어떤 두 타입 사이에서 변환을 정의할 수 있다.
9 Containers
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapter 31 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013] 31장과 거의 일치한다.
[2] An STL container defines a sequence;
STL 컨테이너는 시퀀스를 정의한다
[3] STL containers are resource handles;
STL 컨네이너는 자원 핸들이다.
[4] Use vector as your default container;
기본 컨테이너로 vector를 사용하라
[5] For simple traversals of a container, use a range-for loop or a begin/end pair of iterators;
간단한 컨테이너의 순회에서 범위 기반 for 또는 begin/end 쌍의 반복자를 사용하라
[6] Use reserve() to avoid invalidating pointers and iterators to elements;
원소에 대한 유효하지 포인터와 반복자를 피하기 위해서 reserve()를 사용하라
[7] Don't assume performance benefits from reserve() without measurement;
측정없이 reserve()로 부터 성능 잇점을 가정하지 말아라
[8] Use push_back() or resize() on a container rather than realloc() on an array;
배열에 realloc() 보다 컨테이너에 push_back() 또는 resize()를 사용하라
[9] Don't use iterators into a resized vector;
(벡터 케퍼서티가 변하면 반복자는 무효화 되기 때문에) 길이가 변경된 vector에 반복자를 사용하지 말아라
[10] Do not assume that [] range checks;
[] 가 범위 검사 한다는 가정은 하지 말아라
[11] Use at() when you need guaranteed range checks;
보증된 범위 검사를 필요로 한다면 at()을 사용하라
[12] Elements are copied into a container;
원소들은 컨테이너로 복사될 수 있다.
[13] To preserve polymorphic behavior of elements, store pointers;
원소의 다형적인 행위를 유지하기 위해서, 포인터를 적재하라
[14] Insertion operators, such as insert() and push_back() are often surprisingly efficient on a vector;
insert() 과 push_back() 같은, 삽입 연산은 벡터에서 종종 놀랍게도 효과적일 때가 있다.
[15] Use forward_list for sequences that are usually empty;
시퀀스가 대개 비어 있어 있는 경우에 forward_listf를 사용하라
[16] When it comes to performance, don't trust your intuition: measure;
성능에 대해서, 직관을 믿지 말아라: 측정하라.
[17] A map is usually implemented as a red-black tree;
map은 대게 red-black 트리로 구현된다.
[18] An unordered_map is a hash table;
unordered_map은 해시 테이블이다.
[19] Pass a container by reference and return a container by value;
참조자로 컨테이너를 전달하고 값으로 컨테이너를 반환하라
[20] For a container, use the ()-initializer syntax for sizes and the {}-initializer syntax for lists of elements;
컨테이너에 대해서, 크기에 대해서 ()-초기화 문법을 사용하고, 원소의 리스트에 대해서 {}-초기화 문법을 사용하라
[21] Prefer compact and contiguous data structures;
꽉차고 연속적인 데이터 구조를 선호하라
[22] A list is relatively expensive to traverse;
리스트는 상대적으로 순회에서 (비용이) 비싸다
[23] Use unordered containers if you need fast lookup for large amounts of data;
데이터의 거대한 용량에서 빠른 검색이 필요하다면 비순서화 컨테이너를 사용하라
[24] Use ordered associative containers (e.g., map and set) if you need to iterate over their elements in order;
순서대로 컨테이너의 원소를 순회할 필요가 있다면 순서화 연관 컨테이너(예를 들어, map과 set)를 사용하라
[25] Use unordered containers for element types with no natural order (e.g., no reasonable <);
자연적인 순서(예를 들어, 타당한 <이 없는) 원소의 타입에 비순서화 연관 컨테이너를 사용하라
[26] Experiment to check that you have an acceptable hash function;
수용할 수 있는 해시 함수를 가지고 있는지 검사하기 위해서 실험하라
[27] Hash function obtained by combining standard hash functions for elements using exclusive or are often good;
배타적 or를 사용하는 원소들과 표준 해시 함수들의 조합으로 얻어진 해시 함수들은 종종 훌륭하다
[28] Know your standard-library containers and prefer them to hand-crafted data structures;
당신의 표준 라이브러리 컨테이너를 알아라 그리고 손으로 만든 데이터 구조보다 표준 라이브러리 컨테이너를 선호하라
10 Algorithms
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapter 32 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013]의 32장과 거의 일치한다.
[2] An STL algorithm operates on one or more sequences;
STL 알고리즘은 하나 또는 그 이상의 시퀀스 위에서 동작한다.
[3] An input sequence is half-open and defined by a pair of iterators;
입력 시퀀스는 반-개방이고 반복자 쌍으로 정의된다
[4] When searching, an algorithm usually returns the end of the input sequence to indicate "not found";
검색에서 알고리즘은 대개 "찾을 수 없음"을 지시하기 위해서 입력 시퀀스의 end를 반환한다.
[5] Algorithms do not directly add or subtract elements from their argument sequences;
알고리즘은 인수 시퀀스로부터 원소들을 직접 추가 되거나 제거되지 않는다
[6] When writing a loop, consider whether it could be expressed as a general algorithm;
루프를 작성할 때 일반화 알고리즘으로 표현할 수 있는 지 고려하라.
[7] Use predicates and other function objects to give standard algorithms a wider range of meanings;
표준 알고리즘에 좀 더 넒은 의미의 범위를 주기 위해서 술어 함수와 다른 함수 객체를 사용하라
[8] A predicate must not modify its argument;
술어함수는 (자신의) 인수를 수정하지 말아야 한다.
[9] Know your standard-library algorithms and prefer them to hand-crafted loops;
표준 라이브러리 알고리즘을 알아라 그리고 손으로 만든 루프보다 표준 라이브러리 알고리즘을 선호하라
[10] When the pair-of-iterators style becomes tedious, introduce a container/range algorithm;
반복자의 쌍 스타일이 지겨워 질 때, 컨테이너/범위 알고리즘을 도입하라.
11 Utilities
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapters 33-35 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013] 33-35장에 있는 것과 거의 일치한다.
[2] A library doesn't have to be large or complicated to be useful;
라이브러리는 사용하기에 거대하거나 복잡할 필요는 없다.
[3] A resource is anything that has to be acquired and (explicitly or implicitly) released;
자원은 획득 되거나 (명시적 또는 암시적으로) 해제되어야 하는어떤 것이다.
[4] Use resource handles to manage resources (RAII);
자원을 관리하기 위해서 자원 핸들을 사용하라(RAII)
[5] Use unique_ptr to refer to objects of polymorphic type;
다형적인 타입의 객체들을 참조하기 위해서 unique_ptr을 사용하라
[6] Use shared_ptr to refer to shared objects;
공유된 객체를 참조하기 위해서shared_ptr를 사용하라
[7] Prefer resource handles with specific semantics to smart pointers;
스마트 포인터보다 특정한(명세된) 의미 구조를 가진 자원 핸들을 선호하라
[8] Prefer unique_ptr to shared_ptr;
shared_ptr 보다 unique_ptr를 선호하라
[9] Prefer smart pointers to garbage collection;
가비지 컬랙션보다 스마트 포인터를 선호하라
[10] Use array where you need a sequence with a constexpr size;
constexpr 크기를 가진 시퀀스가 필요하다면 (std::)array를 사용하라
[11] Prefer array over built-in arrays;
기본형 배열보다 (std::)array를 사용하라
[12] Use bitset if you need N bits and N is not necessarily the number of bits in a built-in integer type;
만약 N 비트가 필요하고 기본 정수형 타입에서 N이 비트의 숫자일 필요가 없다면 bitset을 사용하라
[13] When using pair, consider make_pair() for type deduction;
pair를 사용할 때, 타입 추론을 위한 make_pair()를 고려하라
[14] When using tuple, consider make_tuple() for type deduction;
tuple을 사용할 때, 타입 추론을 위한 make_tuple()을 고려하라
[15] Time your programs before making claims about efficiency;
효율성을 요구하기 전에 당신의 프로그램 시간을 측정하라
[16] Use duration_cast to report time measurements with proper units;
적당한 단위의 시간 측정을 보고 하기 위해서 duration_cast를 사용하라
[17] Often, a lambda is an alternative to using bind() or mem_fn();
때로는, 람다는 bind()나 mem_fn() 사용의 대안이다.
[18] Use bind() to create variants of functions and function objects;
함수와 함수 객체의 변형을 만들기 위해서 bind()를 사용하라
[19] Use mem_fn() to create function objects that can invoke a member function when called using the traditional function call notation;
기존의 함수 호출 표기를 사용해서 호출되는 멤버 함수를 호출 할 수 있는 함수 객체를 생성하기 위해서 mem_fn() 을 사용하라
[20] Use function when you need to store something that can be called;
호출 될 수 있는 어떤 것을 저장할 필요가 있다면 함수를 사용하라
[21] You can write code to explicitly depend on properties of types;
명시적으로 타입의 속성에 의존하는 코드를 작성할 수 있다.
12 Numerics
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapter 40 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013] 40장에 거의 일치한다.
[2] Numerical problems are often subtle. If you are not 100% certain about the mathematical aspects of a numerical problem, either take expert advice, experiment, or do both;
수치 문제는 종종 어렵다. 만약 수치문제의 수학적 측면에서 100% 확신이 없다면, 전문가의 충고를 얻거나 실험하거나, 둘다 해야한다.
[3] Don't try to do serious numeric computation using only the bare language; use libraries;
오직 언어 만을 사용해서 중대한 수치 계산을 시도하지말아라; 라이브러리를 사용하라
[4] Consider accumulate(), inner_product(), partial_sum(), and adjacent_difference() before you write a loop to compute a value from a sequence;
시퀀스로부터 값을 계산하기 위해서 루프를 작성하기 전에 accumulate(), inner_product(), partial_sum(), 그리고 adjacent_difference() 를 고려하라
[5] Use std::complex for complex arithmetic;
복소수 산술 연산에 std::complex를 사용하라
[6] Bind an engine to a distribution to get a random number generator;
난수 생성기를 얻기 위해서 엔진에 분포를 결합하라
[7] Be careful that your random numbers are sufficiently random;
난수가 충분히 무작위가 될 수 있도록 주의하라
[8] Use valarray for numeric computation when run-time efficiency is more important than flexibility with respect to operations and element types;
연산과 원소의 타입을 고려하는 유연성보다 실시간 효율성이 좀 더 중요하다면 수치 계산에 대해서 valarray를 사용하라.
[9] Properties of numeric types are accessible through numeric_limits;
수치 타입의 속성은 numeric_limits 통해서 접근할 수 있다.
[10] Use numeric_limits to check that the numeric types are adequate for their use;
수치 타입을 사용하는데 이 수치 타입이 적합한 지를 검사하기 위해서 numeric_limits을 사용하라
13 Concurrency
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapters 41-42 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013] 41-42장과 거의 일치한다.
[2] Use concurrency to improve responsiveness or to improve throughput;
응답성 또는 처리량을 개성하기 위해서 병행성을 사용하라
[3] Work at the highest level of abstraction that you can afford;
할 수 있는 한 추상화의 최상위 수준에서 작업하라
[4] Consider processes as an alternative to threads;
프로세스를 스레드의 대안으로 고려하라
[5] The standard-library concurrency facilities are type safe;
표준 라이브러리 병행성 기능은 타입 안전하다
[6] The memory model exists to save most programmers from having to think about the machine architecture level of computers;
메모리 모델은 대부분의 프로그래머를 컴퓨터의 기계 구조 수준에 관한 고민을 해야만 하는 것으로부터 구출하기 위해서 존재한다
[7] The memory model makes memory appear roughly as naively expected;
메모리 모델은 메모리를 단순하게 기대한 모양으로 거의 나타내게한다.
[8] Atomics allow for lock-free programming;
원자성은 무잠금(lock-free) 프로그램을 허락한다.
[9] Leave lock-free programming to experts;
lock-free 프로그래밍은 전문가에게 남겨두어라
[10] Sometimes, a sequential solution is simpler and faster than a concurrent solution;
때로는, 병행성 해결책보다 순차적인 해결책이 좀 더 단순하고 빠르다.
[11] Avoid data races;
데이터 경합을 피하라
[12] A thread is a type-safe interface to a system thread;
스레드는 시스템 스레드에 대해서 타입-안전한 인터페이스이다.
[13] Use join() to wait for a thread to complete;
스레드가 완료를 기다리기 위해서 join()을 사용하라
[14] Avoid explicitly shared data whenever you can;
할 수 있다면 명시적으로 공유되는 데이터는 피하라
[15] Use unique_lock to manage mutexes;
mutexe를 관리하기 위해서 unique_lock을 사용하라
[16] Use lock() to acquire multiple locks;
다중 lock을 얻기 위해 lock()을 사용하라
[17] Use condition_variables to manage communication among threads;
스레드 사이의 통신을 관리하기 위해서 condition_variable을 사용하라
[18] Think in terms of tasks that can be executed concurrently, rather than directly in terms of threads;
직접적으로 스레드의 관점보다 병행적으로 실행이 될 수 있는 테스크의 관점에서 생각하라.
[19] Value simplicity;
값은 단순하게
[20] Prefer packaged_task and futures over direct use of threads and mutexes;
직접적인 스레드의 사용과 mutex보다 packaged_task와 future를 선호하라
[21] Return a result using a promise and get a result from a future;
primise를 사용한 결과를 반환하고 future로부터의 결과를 얻어라
[22] Use packaged_tasks to handle exceptions thrown by tasks and to arrange for value return;
task로 던져진 예외를 처리하고 값 반환을 준비하기 위해서 packaged_task를 사용하라
[23] Use a packaged_task and a future to express a request to an external service and wait for its response;
외부 서비스에 요청하고 응답에 대한 대기를 표현하기 위해서 packaged_task와 future를 사용하라
[24] Use async() to launch simple tasks;
단순한 테스크를 시작하기 위해서 async()을 사용하라
14 History and Compatibility
[1] The material in this chapter roughly corresponds to what is described in much greater detail in Chapters 1 and 44 of [Stroustrup,2013].
이 장에 있는 자료는 훨씬 더 자세한 설명이 있는 [Stroustrup,2013]의 1과 44장과 거의 일치한다.
[2] The ISO C++ standard [C++,2011] defines C++.
ISO C++ 표준 [C++,2011]은 C++을 정의한다.
[3] When learning C++, don't focus on language features in isolation.
C++을 배울 때, 고립적으로 언어의 기능에 촛점을 맞추지 말아라
[4]
[1] Use constructors to establish invariants.
불변성을 설립하기위해서 생성자를 사용하라
[2] Use constructor/destructor pairs to simplify resource management (RAII;).
자원 관리를 단순화하기 위해서 생성자/소멸자 쌍을 사용하라
[3] Avoid "naked" new and delete.
무방비의 new와 delete 를 피하라
[4] Use containers and algorithms rather than built-in arrays and ad hoc code (Chapter 9, Chapter 10).
기본형 배열과 특별 코드 대신 컨테이너와 알고리즘을 사용하라
[5] Prefer standard-library facilities to locally developed code.
지역적으로 개발된 코드 보다 표준 라이브러리 기능들을 선호하라
[6] Use exceptions, rather than error codes, to report errors that cannot be handled locally.
지역적으로 관리가 될 수 없는 에러를 표현하기 위해서 에러 코드 보다, 예외를 사용하라.
[7] Use move semantics to avoid copying large objects.
거대아 객체의 복사를 피하기 위해서 이동 의미 구조를 사용하라
[8] Use unique_ptr to reference objects of polymorphic type.
다형적인 타입의 객체를 참조하기 위해서 unique_ptr을 사용하라
[9] Use shared_ptr to reference shared objects, that is, objects without a single owner that is responsible for their destruction.
공유된 객체, 즉, 소멸에 대한 책임이 있는 단일 소유자가 없는 객체 를 참조하기 위해서 shared_ptr를 사용하라
[10] Use templates to maintain static type safety (eliminate casts) and avoid unnecessary use of class hierarchies.
정적 타입 안정성을 유지하기 위해서 템플릿을 사용하고, 불필요한 계층 클래스의 사용을 피하라
[5] Before using a new feature in production code, try it out by writing small programs to test the standards conformance and performance of the implementations you plan to use.
제품 코드에서 새로운 기능을 사용하기 전에, 표준 적합성과 사용하고자 했던 구현들의 성능을 시험하기 위한 작은 프로그램을 작성해서 시험해 봐라.
[6] For learning C++, use the most up-to-date and complete implementation of Standard C++ that you can get access to.
C++을 배우기 위해서, 구할 수 있는 것 중에서 가장 최신이면서 표준 C++의 구현이 가장 완전한 것을 사용하라.
[7] The common subset of C and C++ is not the best initial subset of C++ to learn;
C와 C++의 공통 부분 집합은 가장 먼저 C++을 배우기 위한 집합은 아니다.
[8] Prefer named casts, such as static_cast over C-style casts;
C-스타일 캐스잉보다 static_cast와 같은 명명된 캐스팅을 선호하라
[9] When converting a C program to C++, first make sure that function declarations (prototypes) and standard headers are used consistently;
C프로그램을 C++로 변환 할 때, 첫번째로 함수의 선언(프로토타입)과 표준 헤더는 일관성 있게 사용되는지 확실히 하라
[10] When converting a C program to C++, rename variables that are C++ keywords;
C프로그램을 C++로 변환 할 때, C++ 키워드들은 새이름으로 변경하라.
[11] For portability and type safety, if you must use C, write in the common subset of C and C++;
호환성과 안전성을 위해서, 만약 C를 사용해야 한다면, C와 C++의 공통 집합 안에서 작성하라
[12] When converting a C program to C++, cast the result of malloc() to the proper type or change all uses of malloc() to uses of new;
C프로그램을 C++로 변환 할 때, 적절한 타입으로 malloc()의 결과를 캐스팅하고나 모든 malloc()의 사용을 new 사용으로 변경하라.
[13] When converting from malloc() and free() to new and delete, consider using vector, push_back(), and reserve() instead of realloc();
malloc()과 free()를 new와 delete로 변환할 때, 벡터, push_back(), 그리고 realloc() 대신 reserve() 사용을 고려하라.
[14] In C++, there are no implicit conversions from ints to enumerations; use explicit type conversion where necessary.
C++에서 int에서 열거형으로 암시적인 변환은 없다; 필요한 곳에서 명시적 타입 변환을 사용하라.
[15] Use <string> to get std::string (<string.h> holds the C-style string functions).
std::string을 얻기위해서<string>을 사용하라 (<string.h>은 C-스타일 문자열 함수를 가지고 있다.)
[16] For each standard C header <X.h> that places names in the global namespace, the header <cX> places the names in namespace std.
전역 공간에 이름을 둔 표준 C 헤더 <X.h>에 대해서 헤더 <cX>는 이름들을 std 이름 공간 안에 둔다.
[17] Use extern "C" when declaring C functions;
C 함수를 선언할 때 extern "C" 을 사용하라
[18] Prefer string over C-style strings (direct manipulation of zero-terminated arrays of char).
C-스타일 문자열(0으로 끝나는 char형 배열의 직접적인 조작)보다 (std::) string을 선호하라
[19] Prefer iostreams over stdio.
stdio보다 iostream을 사용하라
[20] Prefer containers (e.g., vector) over built-in arrays.
기본 자료형 배열보다 container를 사용하라
