24.03.17 - appendix/discussion #169

twoo0220 · 2024-03-16T15:15:34Z

Resolve #165

appendix/Discussion 부분 번역

This reverts commit 45d965e.

twoo0220 · 2024-05-07T14:45:11Z

sections/appendix/DIscussion.md


-### <a name="Cr-list"></a>Discussion: If a class is a container, give it an initializer-list constructor
+### <a id="Cr-list"></a>토론: 클래스가 컨테이너인 경우, 초기화리스트 생성자를 제공하라


name / id 위와 통일 필요

twoo0220 · 2024-05-07T14:45:24Z

sections/appendix/DIscussion.md


-### <a name="Cr-handle"></a>Discussion: If a class is a resource handle, it needs a constructor, a destructor, and copy and/or move operations
+### <a id="Cr-handle"></a>토론: 클래스가 리소스 핸들인 경우 생성자, 소멸자, 복사 및/또는 이동 연산이 필요하다


name / id 위와 통일 필요

twoo0220 · 2024-05-07T14:45:33Z

sections/appendix/DIscussion.md

        int sz;
    };
 ```

-### <a name="Cr-value-return"></a>Discussion: Return containers by value (relying on move or copy elision for efficiency)
+### <a id="Cr-value-return"></a>토론: (효율성을 위해 이동 또는 복사 생략에 의존하는)값으로 컨테이너 반환하라


name / id 위와 통일 필요

luncliff

늦게 처리를 시작해서 죄송합니다 태우님. 우선 아래와 같이 제안을 남겨봅니다.

남은 부분도 며칠 내로 제안을 드리겠습니다.

sections/appendix/DIscussion.md

luncliff · 2024-05-07T15:10:16Z

sections/appendix/DIscussion.md


-If the class definition and the constructor body are in separate files, the long-distance influence that the order of member variable declarations has over the constructor's correctness will be even harder to spot.
+클래스의 정의부와 생성자 본문이 서로 다른 파일에 있다면, 멤버 변수의 선언 순서가 생성자의 정확성에 미치는 장거리 영향력을 파악하기 훨씬 더 어려워진다.


the long-distance 라는 수식이 없어도 자연스러울 것 같습니다.

Suggested change

클래스의 정의부와 생성자 본문이 서로 다른 파일에 있다면, 멤버 변수의 선언 순서가 생성자의 정확성에 미치는 장거리 영향력을 파악하기 훨씬 더 어려워진다.

클래스의 정의부와 생성자 본문이 서로 다른 파일에 있다면, 멤버 변수의 선언 순서가 생성자의 정확성에 미치는 영향을 파악하기 훨씬 더 어려워진다.

luncliff · 2024-05-07T15:15:48Z

sections/appendix/DIscussion.md


-### <a name="Sd-init"></a>Discussion: Use of `=`, `{}`, and `()` as initializers
+### <a name="Sd-init"></a>토론: 초기화로 `=`, `{}`, `()` 를 사용하라 


"초기화"라고 적으면 읽는 분들께서 initialization을 떠올리지 않을까 생각했습니다.
표준 C++ 20에서 "9. Declaration [dcl.dcl]" 하위에 "9.4 Initializer [dcl.init]"이 위치하므로, Initializer를 "초기화 선언"이라고 적으면 "초기화"와 구분하기 좋을 것 같습니다.

Suggested change

### <a name="Sd-init"></a>토론: 초기화로 `=`, `{}`, `()` 를 사용하라

### <a name="Sd-init"></a>토론: 초기화 선언에는 `=`, `{}`, `()` 를 사용하라

luncliff · 2024-05-07T15:16:39Z

sections/appendix/DIscussion.md

    };


-    class D : public B {                 // some derived class
+    class D : public B {                 // 일부 파생 클래스


Suggested change

class D : public B { // 일부 파생 클래스

class D : public B { // 임의의 파생 클래스

luncliff · 2024-05-07T15:23:16Z

sections/appendix/DIscussion.md


-If your design wants virtual dispatch into a derived class from a base class constructor or destructor for functions like `f` and `g`, you need other techniques, such as a post-constructor -- a separate member function the caller must invoke to complete initialization, which can safely call `f` and `g` because in member functions virtual calls behave normally. Some techniques for this are shown in the References. Here's a non-exhaustive list of options:
+`f`와 `g` 같은 함수에 대한 기반 클래스 생성자 또는 소멸자로부터 파생 클래스로 가상 디스패치를 원하는 경우, 다른 기법이 필요하다. 예를 들어 포스트 생성자 기법은 호출자가 초기화를 완료하기 위해 호출해야 하는 별도의 멤버 함수로, 멤버 함수에서는 가상 호출이 정상적으로 작동하므로 `f`와 `g`를 안전하게 호출할 수 있다. 이외에도 몇 가지 기법이 참고 문헌에 나와있다. 다음은 전체가 아닌 옵션 목록이다:


Suggested change

`f`와 `g` 같은 함수에 대한 기반 클래스 생성자 또는 소멸자로부터 파생 클래스로 가상 디스패치를 원하는 경우, 다른 기법이 필요하다. 예를 들어 포스트 생성자 기법은 호출자가 초기화를 완료하기 위해 호출해야 하는 별도의 멤버 함수로, 멤버 함수에서는 가상 호출이 정상적으로 작동하므로 `f`와 `g`를 안전하게 호출할 수 있다. 이외에도 몇 가지 기법이 참고 문헌에 나와있다. 다음은 전체가 아닌 옵션 목록이다:

`f`와 `g` 같은 함수에 대한 기반 클래스 생성자 또는 소멸자에서 파생 클래스의 코드를 사용하기를 원하는 경우(virtual dispatch), 다른 기법이 필요하다.

예를 들어 호출자가 초기화를 완료하기 위해 별도의 멤버 함수를 사용하는 포스트 생성자 기법을 사용하면, 멤버 함수는 가상 호출이 정상적으로 작동하므로 `f`와 `g`를 안전하게 호출할 수 있다.

이외에도 몇 가지 기법이 참고 문헌에 나와있다.

전체는 아니지만 일부 선택 가능한 방법 들은 다음과 같다.

luncliff · 2024-05-07T15:37:44Z

sections/appendix/DIscussion.md

+* `D`와 같은 파생 클래스는 공개적으로 호출 가능한 생성자를 노출해서는 안된다. 그렇지 않으면 `D`의 사용자가 `초기화 후 함수(PostInitialize)`를 호출하지 않은 `D`객체를 생성할 수 있다.
+* 할당은 `operator new`로 제한된다. 그러나 `B`는 `new`를 재정의할 수 있다([SuttAlex05](../Bibliography.md)의 Items 45 and 46 참조).
+* `D`는 `B`가 선택한 것과 동일한 매개변수를 가진 생성자를 정의해야만 한다. 그러나 `create`의 여러 오버로드를 정의하면서 이 문제를 완화할 수 있으며, 오버로드는 인수 유형에 템플릿을 지정할 수도 있다.  

-If the requirements above are met, the design guarantees that `PostInitialize` has been called for any fully constructed `B`-derived object. `PostInitialize` doesn't need to be virtual; it can, however, invoke virtual functions freely.
+위의 요구사항이 충족되면, 설계는 완전히 생성된 모든 `B` 파생 객체에 대해 `PostInitialize`가 호출되었음을 보장한다. `PostInitialize`는 가상일 필요는 없지만 가상 함수를 자유롭게 호출할 수 있어야 한다.

-In summary, no post-construction technique is perfect. The worst techniques dodge the whole issue by simply asking the caller to invoke the post-constructor manually. Even the best require a different syntax for constructing objects (easy to check at compile time) and/or cooperation from derived class authors (impossible to check at compile time).
+요약하면, 완벽한 생성 후 기법은 존재하지 않는다. 최악의 기법은 호출자에게 생성자 이후 수동으로 호출하도록 요청함으로써 모든 문제를 회피하는 것이다. 가장 좋은 방법도 객체를 구성하는 다른 구문(컴파일 때 쉽게 확인 가능)이나 파생 클래스 작성자의 협조(컴파일 때 확인 불가능)가 필요하다.


예시 코드에서는 post_initialize 로 되어있는 것을 보면 어느 순간부터 차이가 생겼던 것 같습니다.
번역문에서는 예제와 같이 post_initialize로 통일하는게 혼란이 없을 것 같습니다.

luncliff · 2024-05-07T15:39:54Z

sections/appendix/DIscussion.md


-### <a name="Sd-dtor"></a>Discussion: Make base class destructors public and virtual, or protected and nonvirtual
+### <a name="Sd-dtor"></a>토론: 기반 클래스 소멸자를 공개, 가상 또는 보호 및 비가상으로 설정하라


영어 쓰는 친구들은 소괄호가 없어도 우선순위가 잘 떠오르는가 보네요...

Suggested change

### <a name="Sd-dtor"></a>토론: 기반 클래스 소멸자를 공개, 가상 또는 보호 및 비가상으로 설정하라

### <a name="Sd-dtor"></a>토론: 기반 클래스는 공개된 가상 소멸자(public virtual) 또는 상속해야만 접근 가능한 소멸자(protected nonvirtual)를 사용한다

luncliff · 2024-05-07T15:44:33Z

sections/appendix/DIscussion.md


-Should destruction behave virtually? That is, should destruction through a pointer to a `base` class be allowed? If yes, then `base`'s destructor must be public in order to be callable, and virtual otherwise calling it results in undefined behavior. Otherwise, it should be protected so that only derived classes can invoke it in their own destructors, and nonvirtual since it doesn't need to behave virtually virtual.
+소멸이 가상으로 작동해야만 하는가? 즉, `base` 클래스에 대한 포인터를 통한 소멸이 허용되어야 하는가?  


평소 같으면 직역문을 썼을 것 같은데, '이런 느낌이면 좀 더 자연스럽나?' 하는 생각이 듭니다

Suggested change

소멸이 가상으로 작동해야만 하는가? 즉, `base` 클래스에 대한 포인터를 통한 소멸이 허용되어야 하는가?

"소멸이 가상으로 작동해야만 하는가?"라는 질문은, "소멸이 `base` 클래스에 대한 포인터로 가능해야 하는가?"라고 할 수 있다

luncliff · 2024-05-07T15:46:00Z

sections/appendix/DIscussion.md


 ```c++
    class Base {
    public:
-        ~Base();                   // BAD, not virtual
+        ~Base();                   // BAD, 비가상


이 예제에서는 virtual specifier(지정자?)를 소멸자에 사용하는 부분에 대해서 적고 있으므로 virtual 단어를 최대한 살려둬야 할 것 같습니다.

Suggested change

~Base(); // BAD, 비가상

~Base(); // BAD, virtual 이 아니다

luncliff · 2024-05-07T15:51:41Z

sections/appendix/DIscussion.md

 ```

-In rarer cases, such as policy classes, the class is used as a base class for convenience, not for polymorphic behavior. It is recommended to make those destructors protected and nonvirtual:
+단위 전략(policy) 클래스와 같이 드문 경우에 다형성 동작이 아닌 편의상 기반 클래스로 사용된다. 이러한 소멸자는 protected와 비가상으로 만드는 것이 좋다:


Suggested change

단위 전략(policy) 클래스와 같이 드문 경우에 다형성 동작이 아닌 편의상 기반 클래스로 사용된다. 이러한 소멸자는 protected와 비가상으로 만드는 것이 좋다:

드물게, 아래의 `Policy` 클래스와 같이, 다형성이 아닌 편의성을 위한 기반 클래스로 사용되기도 한다.

이러한 경우 소멸자는 `protected`로 제한하되 `virtual`을 사용하지 않는 것이 권고된다:

Co-authored-by: Park DongHa <luncliff@gmail.com>

utilForever

저는 동하님의 리뷰 반영이 끝나고 나서 보도록 하겠습니다.
반영한 뒤에 저 멘션 부탁드립니다.

24.03.17 - appendix/discussion

4f9e417

luncliff self-assigned this Mar 18, 2024

luncliff added the Update label Mar 18, 2024

utilForever requested review from utilForever and luncliff March 18, 2024 15:00

utilForever assigned twoo0220 and unassigned luncliff Mar 18, 2024

luncliff requested review from a team and removed request for luncliff March 19, 2024 02:53

twoo0220 added 2 commits April 4, 2024 08:02

Performance section Update

45d965e

Revert "Performance section Update"

07e0b83

This reverts commit 45d965e.

twoo0220 commented May 7, 2024

View reviewed changes

luncliff reviewed May 7, 2024

View reviewed changes

Update sections/appendix/DIscussion.md

9c31dbf

Co-authored-by: Park DongHa <luncliff@gmail.com>

utilForever requested changes May 21, 2024

View reviewed changes

Merge branch 'CppKorea:master' into master

d9bcd7c

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

24.03.17 - appendix/discussion #169

24.03.17 - appendix/discussion #169

twoo0220 commented Mar 16, 2024 •

edited by luncliff

twoo0220 May 7, 2024

twoo0220 May 7, 2024

twoo0220 May 7, 2024

luncliff left a comment

luncliff May 7, 2024

luncliff May 7, 2024

luncliff May 7, 2024

luncliff May 7, 2024

luncliff May 7, 2024

luncliff May 7, 2024

luncliff May 7, 2024

luncliff May 7, 2024

luncliff May 7, 2024

utilForever left a comment


		### <a name="Cr-list"></a>Discussion: If a class is a container, give it an initializer-list constructor
		### <a id="Cr-list"></a>토론: 클래스가 컨테이너인 경우, 초기화리스트 생성자를 제공하라


		### <a name="Cr-handle"></a>Discussion: If a class is a resource handle, it needs a constructor, a destructor, and copy and/or move operations
		### <a id="Cr-handle"></a>토론: 클래스가 리소스 핸들인 경우 생성자, 소멸자, 복사 및/또는 이동 연산이 필요하다


		If the class definition and the constructor body are in separate files, the long-distance influence that the order of member variable declarations has over the constructor's correctness will be even harder to spot.
		클래스의 정의부와 생성자 본문이 서로 다른 파일에 있다면, 멤버 변수의 선언 순서가 생성자의 정확성에 미치는 장거리 영향력을 파악하기 훨씬 더 어려워진다.


		### <a name="Sd-init"></a>Discussion: Use of `=`, `{}`, and `()` as initializers
		### <a name="Sd-init"></a>토론: 초기화로 `=`, `{}`, `()` 를 사용하라

	### <a name="Sd-init"></a>토론: 초기화로 `=`, `{}`, `()` 를 사용하라
	### <a name="Sd-init"></a>토론: 초기화 선언에는 `=`, `{}`, `()` 를 사용하라

	class D : public B { // 일부 파생 클래스
	class D : public B { // 임의의 파생 클래스


		If your design wants virtual dispatch into a derived class from a base class constructor or destructor for functions like `f` and `g`, you need other techniques, such as a post-constructor -- a separate member function the caller must invoke to complete initialization, which can safely call `f` and `g` because in member functions virtual calls behave normally. Some techniques for this are shown in the References. Here's a non-exhaustive list of options:
		`f`와 `g` 같은 함수에 대한 기반 클래스 생성자 또는 소멸자로부터 파생 클래스로 가상 디스패치를 원하는 경우, 다른 기법이 필요하다. 예를 들어 포스트 생성자 기법은 호출자가 초기화를 완료하기 위해 호출해야 하는 별도의 멤버 함수로, 멤버 함수에서는 가상 호출이 정상적으로 작동하므로 `f`와 `g`를 안전하게 호출할 수 있다. 이외에도 몇 가지 기법이 참고 문헌에 나와있다. 다음은 전체가 아닌 옵션 목록이다:

-`f`와 `g` 같은 함수에 대한 기반 클래스 생성자 또는 소멸자로부터 파생 클래스로 가상 디스패치를 원하는 경우, 다른 기법이 필요하다. 예를 들어 포스트 생성자 기법은 호출자가 초기화를 완료하기 위해 호출해야 하는 별도의 멤버 함수로, 멤버 함수에서는 가상 호출이 정상적으로 작동하므로 `f`와 `g`를 안전하게 호출할 수 있다. 이외에도 몇 가지 기법이 참고 문헌에 나와있다. 다음은 전체가 아닌 옵션 목록이다:
+`f`와 `g` 같은 함수에 대한 기반 클래스 생성자 또는 소멸자에서 파생 클래스의 코드를 사용하기를 원하는 경우(virtual dispatch), 다른 기법이 필요하다.
+예를 들어 호출자가 초기화를 완료하기 위해 별도의 멤버 함수를 사용하는 포스트 생성자 기법을 사용하면, 멤버 함수는 가상 호출이 정상적으로 작동하므로 `f`와 `g`를 안전하게 호출할 수 있다.
+이외에도 몇 가지 기법이 참고 문헌에 나와있다.
+전체는 아니지만 일부 선택 가능한 방법 들은 다음과 같다.


		### <a name="Sd-dtor"></a>Discussion: Make base class destructors public and virtual, or protected and nonvirtual
		### <a name="Sd-dtor"></a>토론: 기반 클래스 소멸자를 공개, 가상 또는 보호 및 비가상으로 설정하라

	### <a name="Sd-dtor"></a>토론: 기반 클래스 소멸자를 공개, 가상 또는 보호 및 비가상으로 설정하라
	### <a name="Sd-dtor"></a>토론: 기반 클래스는 공개된 가상 소멸자(public virtual) 또는 상속해야만 접근 가능한 소멸자(protected nonvirtual)를 사용한다


		Should destruction behave virtually? That is, should destruction through a pointer to a `base` class be allowed? If yes, then `base`'s destructor must be public in order to be callable, and virtual otherwise calling it results in undefined behavior. Otherwise, it should be protected so that only derived classes can invoke it in their own destructors, and nonvirtual since it doesn't need to behave virtually virtual.
		소멸이 가상으로 작동해야만 하는가? 즉, `base` 클래스에 대한 포인터를 통한 소멸이 허용되어야 하는가?

	소멸이 가상으로 작동해야만 하는가? 즉, `base` 클래스에 대한 포인터를 통한 소멸이 허용되어야 하는가?
	"소멸이 가상으로 작동해야만 하는가?"라는 질문은, "소멸이 `base` 클래스에 대한 포인터로 가능해야 하는가?"라고 할 수 있다

	~Base(); // BAD, 비가상
	~Base(); // BAD, virtual 이 아니다

	단위 전략(policy) 클래스와 같이 드문 경우에 다형성 동작이 아닌 편의상 기반 클래스로 사용된다. 이러한 소멸자는 protected와 비가상으로 만드는 것이 좋다:
	드물게, 아래의 `Policy` 클래스와 같이, 다형성이 아닌 편의성을 위한 기반 클래스로 사용되기도 한다.
	이러한 경우 소멸자는 `protected`로 제한하되 `virtual`을 사용하지 않는 것이 권고된다:

24.03.17 - appendix/discussion #169

Are you sure you want to change the base?

24.03.17 - appendix/discussion #169

Conversation

twoo0220 commented Mar 16, 2024 • edited by luncliff

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

luncliff left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

utilForever left a comment

Choose a reason for hiding this comment

twoo0220 commented Mar 16, 2024 •

edited by luncliff