한글화 프로젝트 진행상황 공유

Question

한글화 프로젝트 진행상황 공유

luncliff opened this issue 6 years ago · 2 comments

luncliff commented 6 years ago

한글화 프로젝트 진행상황을 공유할 수 있도록 Issue를 개설합니다.

체크박스의 마킹을 통해 번역이 진행된 부분/필요한 부분을 확인하실 수 있습니다.
마킹된 항목들은 한글화가 진행된 부분을 의미하며, 나머지는 한글화가 필요한 항목들입니다.

현재는 전부 원문을 표기하고 있습니다만, 점진적으로 한글화가 진행된 부분은 한글 제목으로 교체하겠습니다.

Guidelines

이하의 진행상황은 master 브런치를 대상으로 합니다.

ReadMe
Abstract
Reference

Introduction

Philosophy

Performance

Naming and Layout Rules

Guidelines Support Library

Source Files

The Standard Library

SL.1: 가능한 곳 어디에서든 라이브러리를 사용하라
SL.2: 다른 라이브러리보다는 표준 라이브러리를 우선적으로 사용하라
SL.3: 비표준 개체를 네임스페이스 std에 추가하지 말라
SL.4: 타입 안전성을 지키면서 표준 라이브러리를 사용하라

Containers

SL.con.1: C 배열을 사용하기보다 STL의 array나 vector를 사용하라
SL.con.2: 다른 컨테이너를 사용할 이유가 있지 않다면 STL vector를 기본으로 사용하라
SL.con.3: 경계조건에서 발생하는 에러를 피하라

String

SL.str.1: 문자열을 제대로 소유하기 위해서는 std::string을 사용하라
SL.str.2: 문자들의 나열을 참조하기 위해서는 std::string_view나 gsl::string_span을 사용하라
SL.str.3: 0으로 끝나는 문자들의 나열인 C 스타일의 문자열을 표현하려면 zstring나 czstring을 사용하라
SL.str.4: 하나의 단일 문자에 대한 참조를 의도할 때 char*를 사용하라
SL.str.5: 문자열을 표현할 필요없이 바이트 값을 참조하려면 std::byte를 사용하라
SL.str.10: 지역 언어에 민감한 문자열에 대한 처리가 필요할 때에는 std::string을 사용하라
SL.str.11: 문자열을 수정할 필요가 있을때는 std::string_view보다는 gsl::string_span을 사용하라
SL.str.12: 표준 라이브러리 std::string을 의도할 때는 s 접미사를 사용하라

I/O Stream

SL.io.1: 단일 문자 단위의 입력은 꼭 필요할때에만 사용하라
SL.io.2: 항상 읽을때에는 형식화되지 않은 입력을 고려하라
SL.io.3: 입출력을 위해서는 iostream을 선호하라
SL.io.10: printf계열의 함수를 사용하지 않는다면 ios_base::sync_with_stdio(false)를 호출하라
SL.io.50: endl의 사용을 피하라

Regex

Time

The C Standard Library

S.C.1: setjmp/longjmp를 사용하지 말라

Templates and Generic Programming

템플릿 사용 규칙 요약:

T.1: 코드의 추상화 수준을 높이기 위해 템플릿을 사용하라
T.2: 여러가지 실행인자 타입들에 적용되는 알고리즘을 표현할 때 템플릿을 사용하라
T.3: 컨테이너와 구간(range)을 표현할때 템플릿을 사용하라
T.4: 문법 트리 조작을 표현하기 위해 템플릿을 사용하라
T.5: 제네릭 프로그래밍과 개체지향 기술을 결합해 비용이 아닌 강점을 증폭시켜라

컨셉 사용 규칙

T.10: 모든 템플릿 인자에 컨셉을 명시하라
T.11: 가능한 모든 경우 표준 컨셉을 사용하라
T.12: 지역 변수에 auto 보다는 컨셉의 이름을 사용하라
T.13: 단순하거나 단일 타입을 인자로 받는 컨셉에는 약식 표기를 사용하라

컨셉 정의 규칙

T.20: 유의미한 의미구조가 없는 "컨셉"을 피하라
T.21: 컨셉에서는 연산들의 완전한 집합(complete set)을 요구하라
T.22: 컨셉에서 쓸 수 있도록 공리를 명시하라
T.23: 정제된 컨셉(refined concept)은 더 범용적인 경우에 새로운 패턴을 더해서 차별화하라
T.24: 의미구조만 다른 컨셉은 Tag 클래스 혹은 Traits를 사용해 차별화하라
T.25: 제약이 서로 대비되지 않게 하라
T.26: 단순한 문법보다는 사용 패턴을 고려해서 컨셉을 정의하라

템플릿 인터페이스 규칙

T.40: 알고리즘에 연산(operation)을 전달할때는 함수 개체를 사용하라
T.41: 템플릿의 컨셉에서는 오직 필요한 특성(property)만 요구하라
T.42: 템플릿 별칭을 구현사항을 숨기거나 표기를 간단히 할 때 사용하라
T.43: 타입에 별명을 붙일때 typedef 보다는 using을 사용하라
T.44: (할 수 있다면) 함수 템플릿은 클래스 템플릿의 인자 타입을 유도(deduce)할 때 사용하라
T.46: 템플릿 인자들은 최소한 Regular혹은 SemiRegular하도록 하라
T.47: 일반적인 이름을 가지고 있으면서 쉽게 찾을 수 있고 제약이 거의 없는 템플릿은 지양하라
T.48: 컴파일러가 컨셉을 지원하지 않는다면 enable_if로 유사하게 작성하라
T.49: 가능하다면 타입 제거는 피하라

템플릿 정의 규칙

T.60: 문맥에 따라 달라질 수 있는 템플릿은 최소화 하라
T.61: 너무 많은 멤버를 매개변수화 하지 말라 (SCARY)
T.62: 종속적이지 않은 클래스 템플릿 멤버들은 템플릿이 아닌 상위 클래스에 배치하라
T.64: 클래스 템플릿의 대안적(alternative) 구현을 제공할 때는 특수화를 사용하라
T.65: 함수의 대안적(alternative) 구현을 제공할 때는 Tag dispatch를 사용하라
T.67: 정규적이지 않은 타입(irregular types)들의 대안적 구현을 제공할 때는 특수화를 사용하라
T.68: 모호하지 않도록 템플릿에서는 () 보다는 {}를 사용하라
T.69: 제약없는(unqualified) 비-멤버 함수 호출은 해당 부분이 변경될 수 있도록 하려는게 아니라면 템플릿 내에서 사용하지 말아라

템플릿과 상속구조 규칙

T.80: 충분한 고려 없이 클래스 계층구조를 템플릿으로 바꾸지 말아라
T.81: 계층구조와 배열을 섞어서 사용하지 말아라
T.82: 가상 함수를 원하지 않는다면 계층 구조를 제거하라(linearize)
T.83: 멤버 함수는 템플릿이면서 virtual한 함수로 선언해선 안된다
T.84: 안정된 ABI를 지원하고자 할때는 핵심 구현에 템플릿을 쓰지 마라

가변인자 템플릿규칙

T.100: 다양한 타입을 가지고 가변적인 수의 실행인자들을 처리하는 함수가 필요할 때는 가변 템플릿을 사용하라
T.101: ??? How to pass arguments to a variadic template ???
T.102: ??? How to process arguments to a variadic template ???
T.103: 동일 타입의 실행인자들을 위해서 가변템플릿을 사용하지 마라

메타프로그래밍 규칙

T.120: 정말 필요한 경우에만 템플릿 메타프로그래밍을 사용하라
T.121: 컨셉을 모방(emulate)하기 위해 템플릿 메타프로그래밍을 사용하라
T.122: 템플릿(대부분 템플릿 별칭)은 컴파일 시간에 타입을 계산할때 사용하라
T.123: 컴파일 시간에 값을 계산한다면 constexpr 함수를 사용하라
T.124: 가능한 표준 라이브러리의 TMP 기능들을 사용하라
T.125: 만약 표준 라이브러리의 TMP 기능으로 충분하지 않다면, 가능한 이미 존재하는 라이브러리를 사용하라

다른 템플릿 규칙

T.140: 재사용 가능성이 있는 모든 연산은 이름을 붙여라
T.141: 단순한 함수 개체가 한곳에서만 필요하다면 이름없는 람다를 사용하라
T.142: 템플릿 변수로 표기를 간단히 하라
T.143: 범용적이지 않은 코드는 계획없이 작성하지 말아라
T.144: 함수 템플릿은 특수화하지 말라
T.150: 해당 클래스가 개념에 부합하는지를 static_assert를 사용해 확인하라

Resource management

R.1: 자원 핸들과 RAII(자원 획득시 초기화)를 사용해서 자동적으로 관리되도록 하라
R.2: 인터페이스에서는, 포인터는 서로 다른 개체들을 표시하기 위해서만 사용하라
R.3: 원시 포인터(T*)는 소유를 의미하지 않는다
R.4: 참조(T&)는 소유를 의미하지 않는다
R.5: 유효 범위 안의 개체를 선호하라. 불필요한 동적할당을 하지 마라
R.6: const가 아닌 전역 변수를 지양하라

할당과 해제

R.10: malloc()과 free()의 사용을 피하라
R.11: 명시적인 new와 delete 호출을 지양하라
R.12: 명시적인 할당의 결과는 즉시 관리 개체에 전달하라
R.13: 하나의 표현식 구문에서 명시적 자원 할당은 최대 한번만 수행하라
R.14: ??? 배열 vs. 포인터 매개변수
R.15: 할당/해제가 짝을 이루도록 중복정의하라

스마트 포인터

Profiles

Pro.type: 타입 안전성
Pro.bounds: 경계 안전성
Pro.lifetime: 수명 안전성

규칙이 아닌 것들과 근거없는 이야기들

NR.1: 금지: 모든 선언이 함수의 상단에 오게 하라
NR.2: 금지: 함수에서 오직 하나의 return 구문을 사용하라
NR.3: 금지: 예외를 사용하지 마라
NR.4: 금지: 클래스 선언을 각각의 파일에 배치하라
NR.5: 금지: 생성자에서 많은 일을 하지마라; 대신 2 단계 초기화를 사용하라
NR.6: 금지: 모든 정리 동작을 함수 끝에 배치하고 goto exit을 사용하라
NR.7: 금지: 모든 데이터 멤버를 protected로 하라

Interfaces

인터페이스 규칙

Functions

함수 정의

F.1: 의미있는 동작들을 "묶어서" 함수로 만들고 신중하게 이름을 지어라
F.2: 함수는 하나의 논리적 동작만 수행해야 한다
F.3: 함수는 간결하고 단순하게 유지하라
F.4: 함수가 컴파일 시간에 평가되어야 한다면 constexpr로 선언하라
F.5: 함수가 매우 짧고 수행시간이 중요하다면 inline으로 선언하라
F.6: 함수가 예외를 던지지 않는다면 noexcept로 선언하라
F.7: 보편성을 고려한다면, 스마트 포인터 대신에 T*나 T& 타입의 인자를 사용하라
F.8: 순수 함수를 선호하라
F.9: 사용되지 않는 인자는 이름이 없어야 한다

매개변수 전달 표현(parameter passing expression)

F.15: 정보를 전달 할 때 단순하고 관습적인 방법을 선호하라
F.16: "입력(in)" 매개변수는 복사 비용이 적게 드는 타입의 경우 값으로 전달하고, 그 외에는 상수 참조형으로 전달하라
F.17: "입출력(in-out)" 매개변수는 비상수 참조형으로 전달하라
F.18: "넘겨주는(will-move-from)" 매개변수는 X&&타입과 std::move로 전달하라
F.19: "전달(forward)" 매개변수는 TP&&타입과 std::forward로만 전달하라
F.20: "출력(out)"에는 매개변수보다는 값을 반환하는 방법을 선호하라
F.21: "출력"값 여러 개를 반환할 때는 튜플이나 구조체를 선호하라

매개변수 전달 의미구조(parameter passing semantic)

F.22: T* 혹은 owner<T*>를 단일 개체를 지정하기 위해 사용하라
F.23: "null"이 허용되지 않는다면 not_null<T>를 사용해 표시하라
F.24: 범위를 지정할 때는 span<T>혹은 span_p<T>를 사용하라
F.25: C 스타일 문자열에는 zstring 혹은 not_null<zstring>을 사용하라
F.26: 포인터가 필요한 곳에 소유권을 전달할 때는 unique_ptr<T>를 사용하라
F.27: 소유권을 공유할 때는 shared_ptr<T>를 사용하라
F.60: "인자가 없을 경우"를 허용한다면 T&보다는 T*를 선호하라

값 반환 의미구조

F.42: 위치를 나타내는 경우에만 T*를 반환하라
F.43: 절대로 (직접적이든 간접적이든) 지역 개체의 포인터나 참조를 반환하지 말아라
F.44: 복사를 권장하지 않거나 "개체를 항상 반환"한다면 T&를 반환하라
F.45: T&&를 반환하지 말아라
F.46: main()는 int를 반환해야 한다
F.47: 대입 연산자는 T&를 반환하라
F.48: return std::move(local)은 사용하지 말아라

기타 함수 규칙

F.50: 함수를 쓸 수 없을 때는 람다를 사용하라(지역 변수를 캡쳐하거나 지역 함수를 작성할 때)
F.51: 선택할 수 있다면, 중복 정의보다는 기본 전달인자를 선호하라
F.52: 지역적으로 사용된다면 람다의 참조 캡쳐를 선호하라
F.53: 지역적으로 사용되지 않는다면 참조 캡쳐를 피하라
F.54: this를 캡쳐할 때는, 모든 변수를 명시적으로 캡쳐하라(기본 캡쳐를 사용하지 않는다)
F.55: va_arg 전달인자를 사용하지 말아라

Expressions and statements

ES.1: 다른 라이브러리나 "직접 짠 코드" 대신 표준 라이브러리를 사용하라
ES.2: 언어 기능을 바로 사용하기는 보다 적절히 추상화하라

선언

표현식

구문

산술연산

ES.100: 부호가 있는 타입과 없는 타입을 함께 연산하지 마라
ES.101: 비트 조작시에는 부호가 없는(unsigned) 타입을 사용하라
ES.102: 연산에는 부호가 있는(signed) 타입을 사용하라
ES.103: Overflow가 발생하지 않게 하라
ES.104: Underflow가 발생하지 않게 하라
ES.105: 0으로 나누지 않도록 하라
ES.106: 음수값을 막으려고 unsigned를 사용하지 마라
ES.107: 배열 접근에는 unsigned를 쓰지 말고 gsl::index를 사용하라

Error handling

Enumerations

Enum.1: 매크로보다 열거형을 사용하라
Enum.2: 서로 관련있는 상수들의 집합을 표현하기 위해 열거형을 사용하라
Enum.3: 단순한 enum보다 enum class를 선호하라
Enum.4: 안전하고 단순한 사용을 위해 열거형들을 위한 연산을 정의하라
Enum.5: 열거체들을 ALL_CAPS형태로 사용하지 마라
Enum.6: 이름없는 열거형을 지양하라
Enum.7: 필요할 때만 기본 타입을 명시하라
Enum.8: 열거체들의 값은 필요할때만 명시하라

C-Style Programming

CPL.1: C보다 C++를 사용하라
CPL.2: 반드시 C를 써야한다면, C와 C++의 공통집합을 쓰고, C++로 코드를 컴파일하라
CPL.3: C 인터페이스를 써야한다면, 호출되는 코드 안에서는 C++를 사용하라

Constants and Immutability

Con.1: 기본적으로 객체를 변경 불가능하도록 만들어라
Con.2: 기본적으로 멤버 함수들은 const로 만들어라
Con.3: 기본적으로 포인터와 참조는 const로 전달하라
Con.4: 개체 생성 이후 변하지 않는 값은 const로 정의하라
Con.5: 컴파일 시간에 계산될 수 있는 값은 constexpr을 사용하라

Concurrency and Parallelism

CP.1: 코드가 멀티스레드 프로그램의 일부로 동작할 것이라 가정하라
CP.2: 데이터 경쟁을 피하라
CP.3: 쓰기 가능한 데이터의 명시적인 공유를 최소화하라
CP.4: 스레드보단 작업 단위로 생각하라
CP.8: 동기화를 위해 volatile을 사용하지 말아라
CP.9: 가능한 모든 경우에, 도구 (tool) 를 이용하여 자신의 병행 실행 코드를 검증하라

Concurrency

Parallelism

적합하다고 판단되면, 표준 라이브러리의 병렬 알고리즘들을 사용하라.
병렬성을 위해 설계된 알고리즘들을 사용하라. 불필요한 의존성을 지닌 알고리즘을 사용하지 말아라.

Message passing

CP.60: 동시적인 작업으로부터 반환값을 받는데 future를 사용하라
CP.61: 동시적인 작업을 생성하기 위해선 async()를 사용하라

Vectorization

Lock-free programming

CP.100: 정말 필요할 때만 lock-free 프로그래밍을 사용하라
CP.101: 하드웨어/컴파일러 조합을 불신하라
CP.102: 문헌을 세심하가 공부하라
CP.110: 초기화를 위한 독자적인 이중 확인 잠금 (double-checked locking) 코드를 작성하지 말라
CP.111: 이중 확인 잠금이 꼭 필요할 경우에는 전통적인 패턴을 사용하라

Etc

CP.200: volatile은 C++가 아닌 메모리에 대해서만 사용하라
CP.201: ??? 시그널

Classs and Class Hierarchies

C.1: 관련된 데이터를 조직화 하라 (struct 와 class)
C.2: 타입이 불변조건을 가진다면, class를 사용하라; 데이터 멤버들에 대한 제약이 자유롭다면 struct를 사용하라
C.3: 클래스를 사용해 인터페이스와 구현을 분리하라
C.4: 클래스에 직접적으로 접근할 필요가 있는 경우에만 함수를 멤버함수로 작성하라
C.5: 보조 함수들은 관련 클래스와 같은 namespace에 배치하라
C.7: 클래스 또는 열거형에 대한 정의와 변수 선언을 같은 구문에 넣지 말아라
C.8: non-public 멤버가 있다면 struct보단 class를 사용하라
C.9: 멤버들의 노출을 최소화하라

C.concrete: Concrete types

C.10: 클래스 계층 보다 실제(Concrete) 타입들을 선호하라
C.11: 실제 타입들은 정규적으로 만들어라

C.ctor: Constructors, assignments, and destructors

C.con: Containers and other resource handles

C.100: 컨테이너를 정의할때는 STL을 따르라
C.101: 값 의미구조(value semantics)를 제공하라
C.102: 이동 연산을 제공하라
C.103: 초기화 리스트 생성자를 지원하라
C.104: 기본 생성자는 빈 컨테이너를 만들도록 하라
C.109: 리소스 핸들이 포인터 의미구조를 따를 경우에는, * 과 -> 연산자를 제공하라

C.lambdas: Function objects and lambdas

F.50: 함수를 사용할 수 없다면 람다를 사용하라 (지역 변수를 복사하거나, 지역적으로 사용되는 함수를 작성하는 경우)
F.52: 지역적으로 사용되거나 알고리즘에 전달된다면 람다 캡쳐로는 참조를 선호하라
F.53: 반환되거나, 외부에 저장되거나, 다른 스레드로 전달하는 경우처럼 비 지역적으로 사용된다면 람다의 참조 캡쳐를 지양하라
ES.28: 복잡한 초기화에는, 특히 상수 변수들의 초기화에는 람다를 사용하라

C.hier: Class hierarchies (OOP)

C.over: Overloading and overloaded operators

C.union: Unions

C.180: union은 메모리를 절약하기 위해 사용하라
C.181: 표지 없는(naked) union을 사용하지 말아라
C.182: Tagged union 구현에는 익명 union을 사용하라
C.183: 타입 재해석(type punning)을 위해 union을 사용하지 말아라

Biblography

Architectural Idea

A.1: Separate stable from less stable part of code
A.2: Express potentially reusable parts as a library
A.4: There should be no cycles among libraries

Appendix

Discussion
Libraries
Modernizing
Tools

Answer 1 · 2019-04-20T13:13:42.000Z

Constant (Con)의 번역을 조금 다듬는 방안을 건의드리니 검토 부탁드립니다.
(git을 잘 쓸 줄 몰라서 답글로 다는데, 양해해 주시면 감사드리겠습니다.)

Con
내부의 많은 개체가 값을 바꾸지 않는 프로그램이라면 해석하기가 쉬울 것이다.
-> 프로그램 내의 객체 중 그 값이 바뀔 수 없는 것이 많다면 해석하기가 쉬울 것이다.

Con.1
Exception
함수의 인자는 지역 변수로써 이를 변경하는 것 역시 지역적임을 유념하라.
-> 함수 내부의 변수는 지역 변수이므로 이를 변경하는 영향도 지역적임을 짚고 가자.

Con.2
멤버 함수가 해당 객체의 식별 가능한 상태 변경을 야기하지 않는다면 const 로 표시되어야 한다. 이는 디자인 의도를 더욱 명확하게 설명하며, 향상된 가독성과 컴파일러에 의해 검출되는 더 많은 에러를 제공할 뿐만 아니라, 때에 따라서는 최적화 기회까지도 추가적으로 가져올 수 있다.
-> 멤버 함수가 해당 객체의 상태를 변경하지 않는다면 const로 표시하도록 한다. 이렇게 하면 디자인 의도를 더욱 명확하게 드러내고, 가독성을 높이며, 컴파일러가 더 많은 오류를 잡아낼 수 있게 도우며, 때에 따라서는 최적화를 더 잘 할 수 있도록 한다.
Note
const-정확한 방식으로 라이브러리를 업데이트한다; 선호되는 장기적인 대안이다
-> 정확하게 const를 이용하도록 라이브러리를 업데이트한다; 장기적인 대안으로 좋다
Note
"const속성을 cast를 통해 해지한다 "
-> "const속성을 타입 변환(cast)을 통해 해지한다 "
Example
이 wrapper 해결책은 f() 의 선언 자체를 수정할 수 없는 경우에만 (e.g. 수정할 수 없는 라이브러리에서 제공된다거나 하는 이유로) 사용되어야 하는 방법임을 유의하라.
-> 이렇게 wrapper를 이용하는 해결책은 (라이브러리 안에 들어 있어 직접 수정할 수 없다든가 하는 이유로) f()의 선언을 수정할 수 없는 경우에만 사용해야 하는 임시방편임에 유의하라.

Con.3
Note
Do not cast away const.
-> const속성을 타입 변환을 통해 해지하지 말라.

Con.5
향상된 성능, 향상된 컴파일-시점 검사, 보장된 컴파일-시점 변환 (evaluation) 이 제공될 뿐만 아니라, 경합 조건 (race condition) 위험도 피할 수 있다
-> 성능이 향상되고, 컴파일-시점 검사가 원활해지며, 컴파일-시점 연산(evaluation)이 보장되며, 경합 조건 (race condition) 위험도 피할 수 있다

Answer 2 · 2019-06-18T22:35:31.000Z

엇 댓글을 늦게 보았네요, 말씀 주신 부분은 제가 번역해 올린 부분이라 제가 A/S 하도록 하겠습니다 ㅎㅎ 다듬어 주셔서 감사합니다, 번역 참여가 처음이라 너무 직역만 한 것 같네요^^;