추신: 하지만 그렇게 했다면 표준 플러스 라이브러리(이름, 동작 등)와 최대한 비슷하게 했을 것이므로 선택의 여지가 없습니다. 모든 것이 이미 작성되어 있는데 왜 다른 사양을 생성합니까?
- 동적 OOP 내에서 자동 구조 생성은 넌센스
- 동적 구조는 특정 프로세스를 위해 생성된 구조(예: 샘플 요청) 또는 기존 요소 집합의 샘플(혼합 유형이 있을 수 있음)으로 분할되어야 합니다.
- 나는 여전히 객체에 대한 "자신의" 참조 수를 고려하는 방법을 알고 있습니다. 이를 위해 래퍼를 생성할 필요가 전혀 없기 때문입니다(사실 이것이 어떻게 문제를 해결할지 모르겠습니다) , 그러나 나는 µl에 이미 존재하는 포인터의 메커니즘을 복제해야 할 것입니다. 여기에는 최소한 참조 카운터를 포함하는 고유한 방법이 추가됩니다(이는 Habr에서 인용한 기사에서 논의되었지만 방금 며칠 전에 포인터에 대한 솔루션을 찾고 있었고 나 자신이 이미 동일한 솔루션에 도달했음을 깨달았을 때 그것을 읽었습니다.
- 이 모든 것을 구현하려고 노력할 것입니다. 가치 있는 것이 있으면 포럼 및/또는 어떤 식으로든 코드베이스에 게시할 것입니다. :)
- 동적 구조는 특정 프로세스를 위해 생성된 구조(예: 샘플 요청) 또는 기존 요소 집합의 샘플(혼합 유형이 있을 수 있음)으로 분할되어야 합니다.
- 나는 여전히 객체에 대한 "자신의" 참조 수를 고려하는 방법을 알고 있습니다. 이를 위해 래퍼를 생성할 필요가 전혀 없기 때문입니다(사실 이것이 어떻게 문제를 해결할지 모르겠습니다) , 그러나 나는 µl에 이미 존재하는 포인터의 메커니즘을 복제해야 할 것입니다. 여기에는 최소한 참조 카운터를 포함하는 고유한 방법이 추가됩니다(이는 Habr에서 인용한 기사에서 논의되었지만 방금 며칠 전에 포인터에 대한 솔루션을 찾고 있었고 나 자신이 이미 동일한 솔루션에 도달했음을 깨달았을 때 그것을 읽었습니다.
- 이 모든 것을 구현하려고 노력할 것입니다. 가치 있는 것이 있으면 포럼 및/또는 어떤 식으로든 코드베이스에 게시할 것입니다. :)
음, 배열을 생성할 때 추가 옵션을 전달하는 것을 금지하는 사람은 아무도 없습니다. 삭제 여부와 관계없이 요소를 삭제하고 기본적으로 (취향에 따라) 켜거나 끌 필요가 있습니다. 그리고 결국, 당신이 그것을 삭제할 필요가 있는지 여부를 추측하지 않을 것입니다.))
그래서 당신은 그러한 배열을 작성했고 결과적으로 당신은 놀라움을 얻게 될 것입니다. 삭제해야 하는 포인터 배열에서 복사 operator=() 및 복사 생성자(기본적으로 µl에 있지 않음)를 금지하는 방법은 무엇입니까? 여기서 생성자를 통한 매개변수가 정크임이 분명해집니다. 두 가지 아이디어가 있습니다.
1. 템플릿 매개변수를 통해 원격 연산자가 있는 유형을 전달 하고 클래스의 구성원으로 만듭니다(이는 추가 리소스 비용이 듭니다).
0. 그래서 당신은 그러한 배열을 작성했고 결과적으로 당신은 놀랄 것입니다: 복사 operator=() 및 복사 생성자를 금지하는 방법 삭제? 여기서 생성자를 통한 매개변수가 정크임이 분명해집니다. 두 가지 아이디어가 있습니다.
1. 템플릿 매개변수를 통해 원격 연산자가 있는 유형을 전달 하고 클래스의 구성원으로 만듭니다(이는 추가 리소스 비용이 듭니다).
2. 래퍼에 포인터를 전달합니다.
3. 부분 전문화의 도움으로 탈출이 가능하지만 그렇지 않습니다.
일반적으로 플러스 라이브러리는 걸작입니다. 글을 더 잘 쓴다고 생각하면 큰 오산입니다.
가장 그럴듯하고 걸작이지만 가장 합리적인 TS를 구축하는 데 필요한 것보다 훨씬 더 광범위한 작업을 위해 작성되었습니다. 신경망, 그래픽 프로세서 사용 및 기타 탬버린과의 춤과 같은 옵션은 고려하지 않습니다.
0. 이미 생성된 동적인 객체는 그대로 옮겨진다고 합니다. 이들은 선택을 위해 특별히 생성된 개체(나중에 삭제해야 함)이거나 사용되었지만 삭제되지 않은 개체에 대한 링크입니다. 목록 객체는 생성에 대한 책임이 없습니다. 필요한 만큼만 주소 지정, 액세스 및 저장을 위한 것입니다.
하나. ...
2. ...
삼...
간단히 말해서 추상적인 작업이 아닌 구체적인 세부 작업을 고려해야 합니다. 어떤 종류의 GUI를 작성해야 하는 경우에도 이에 대해 이야기하지 않습니다. 여기 다음 분기의 어떤 친구는 나쁜 GUI가 아닙니다. 그는 순수 구조에 대해 아무 것도 쓰지 않은 것 같습니다)
혹시 피라미드 형태의 지지자 코드가 있었던 걸까요? 그렇다면 내가 첫 번째가 될 것입니다.
혹시 피라미드 형태의 지지자 코드가 있었던 걸까요? 그렇다면 내가 첫 번째가 될 것입니다.
이것은 수평 코드 지지자들의 진영에 기인할 수 있습니다.
이것은 수평 코드 지지자들의 진영에 기인할 수 있습니다.
동의합니다. 잘하지 못했습니다. 가장 좋은 예는 너무 초월적이어서 우리의 필멸의 현실로의 전환에서 살아남지 못했습니다...
혹시 피라미드 형태의 지지자 코드가 있었던 걸까요? 그렇다면 내가 첫 번째가 될 것입니다.
이것은 난독화입니다.
이것은 난독화입니다.
네, 저는 당신에게서 멀리 떨어져 있습니다. 말하자면, 노력해야 할 것이 있습니다))
일반적으로 예, 할 수 있습니다.
래퍼가 없으면 삭제되지 않고 래퍼가 있으면 삭제되며 모든 것이 매우 깨끗합니다.
추신: 하지만 그렇게 했다면 표준 플러스 라이브러리(이름, 동작 등)와 최대한 비슷하게 했을 것이므로 선택의 여지가 없습니다. 모든 것이 이미 작성되어 있는데 왜 다른 사양을 생성합니까?
- 동적 OOP 내에서 자동 구조 생성은 넌센스
- 동적 구조는 특정 프로세스를 위해 생성된 구조(예: 샘플 요청) 또는 기존 요소 집합의 샘플(혼합 유형이 있을 수 있음)으로 분할되어야 합니다.
- 나는 여전히 객체에 대한 "자신의" 참조 수를 고려하는 방법을 알고 있습니다. 이를 위해 래퍼를 생성할 필요가 전혀 없기 때문입니다(사실 이것이 어떻게 문제를 해결할지 모르겠습니다) , 그러나 나는 µl에 이미 존재하는 포인터의 메커니즘을 복제해야 할 것입니다. 여기에는 최소한 참조 카운터를 포함하는 고유한 방법이 추가됩니다(이는 Habr에서 인용한 기사에서 논의되었지만 방금 며칠 전에 포인터에 대한 솔루션을 찾고 있었고 나 자신이 이미 동일한 솔루션에 도달했음을 깨달았을 때 그것을 읽었습니다.
- 이 모든 것을 구현하려고 노력할 것입니다. 가치 있는 것이 있으면 포럼 및/또는 어떤 식으로든 코드베이스에 게시할 것입니다. :)
- 동적 OOP 내에서 자동 구조 생성은 넌센스
- 동적 구조는 특정 프로세스를 위해 생성된 구조(예: 샘플 요청) 또는 기존 요소 집합의 샘플(혼합 유형이 있을 수 있음)으로 분할되어야 합니다.
- 나는 여전히 객체에 대한 "자신의" 참조 수를 고려하는 방법을 알고 있습니다. 이를 위해 래퍼를 생성할 필요가 전혀 없기 때문입니다(사실 이것이 어떻게 문제를 해결할지 모르겠습니다) , 그러나 나는 µl에 이미 존재하는 포인터의 메커니즘을 복제해야 할 것입니다. 여기에는 최소한 참조 카운터를 포함하는 고유한 방법이 추가됩니다(이는 Habr에서 인용한 기사에서 논의되었지만 방금 며칠 전에 포인터에 대한 솔루션을 찾고 있었고 나 자신이 이미 동일한 솔루션에 도달했음을 깨달았을 때 그것을 읽었습니다.
- 이 모든 것을 구현하려고 노력할 것입니다. 가치 있는 것이 있으면 포럼 및/또는 어떤 식으로든 코드베이스에 게시할 것입니다. :)
매우 흥미로운. 파이 @ # unov에 지쳤습니다.
음, 배열을 생성할 때 추가 옵션을 전달하는 것을 금지하는 사람은 아무도 없습니다. 삭제 여부와 관계없이 요소를 삭제하고 기본적으로 (취향에 따라) 켜거나 끌 필요가 있습니다. 그리고 결국, 당신이 그것을 삭제할 필요가 있는지 여부를 추측하지 않을 것입니다.))
그래서 당신은 그러한 배열을 작성했고 결과적으로 당신은 놀라움을 얻게 될 것입니다. 삭제해야 하는 포인터 배열에서 복사 operator=() 및 복사 생성자(기본적으로 µl에 있지 않음)를 금지하는 방법은 무엇입니까? 여기서 생성자를 통한 매개변수가 정크임이 분명해집니다. 두 가지 아이디어가 있습니다.
1. 템플릿 매개변수를 통해 원격 연산자가 있는 유형을 전달 하고 클래스의 구성원으로 만듭니다(이는 추가 리소스 비용이 듭니다).
2. 래퍼에 포인터를 전달합니다.
3. 부분 전문화의 도움으로 탈출이 가능하지만 그렇지 않습니다.
일반적으로 플러스 라이브러리는 걸작입니다. 글을 더 잘 쓴다고 생각하면 큰 오산입니다.
0. 그래서 당신은 그러한 배열을 작성했고 결과적으로 당신은 놀랄 것입니다: 복사 operator=() 및 복사 생성자를 금지하는 방법 삭제? 여기서 생성자를 통한 매개변수가 정크임이 분명해집니다. 두 가지 아이디어가 있습니다.
1. 템플릿 매개변수를 통해 원격 연산자가 있는 유형을 전달 하고 클래스의 구성원으로 만듭니다(이는 추가 리소스 비용이 듭니다).
2. 래퍼에 포인터를 전달합니다.
3. 부분 전문화의 도움으로 탈출이 가능하지만 그렇지 않습니다.
일반적으로 플러스 라이브러리는 걸작입니다. 글을 더 잘 쓴다고 생각하면 큰 오산입니다.
가장 그럴듯하고 걸작이지만 가장 합리적인 TS를 구축하는 데 필요한 것보다 훨씬 더 광범위한 작업을 위해 작성되었습니다. 신경망, 그래픽 프로세서 사용 및 기타 탬버린과의 춤과 같은 옵션은 고려하지 않습니다.
0. 이미 생성된 동적인 객체는 그대로 옮겨진다고 합니다. 이들은 선택을 위해 특별히 생성된 개체(나중에 삭제해야 함)이거나 사용되었지만 삭제되지 않은 개체에 대한 링크입니다. 목록 객체는 생성에 대한 책임이 없습니다. 필요한 만큼만 주소 지정, 액세스 및 저장을 위한 것입니다.
하나. ...
2. ...
삼...
간단히 말해서 추상적인 작업이 아닌 구체적인 세부 작업을 고려해야 합니다. 어떤 종류의 GUI를 작성해야 하는 경우에도 이에 대해 이야기하지 않습니다. 여기 다음 분기의 어떤 친구는 나쁜 GUI가 아닙니다. 그는 순수 구조에 대해 아무 것도 쓰지 않은 것 같습니다)