구조(배열)에 대한 포인터 배열을 생성합니다. 후속 초기화 for(i){ S[i] = GetPointer(StaticStruct[i]); }
2. 의미 있는 데이터 배열의 견고한(포장된) 형태를 유지합니다.
원시 OpenCL 버퍼에 대한 데이터 출력으로 작업할 때 중요합니다(또는 DLL로 보내기, 파일에 쓰기 등).
이것은 데이터를 다시 쓰지 않고 데이터 액세스를 재정렬할 가능성(예: 포인터 를 정렬할 때 )을 유지(나타납니다)합니다.
보안 언어는 직접 액세스를 노출/제공해서는 안 됩니다.
클래스에는 더 많은 보호 기능이 있으므로 핸들이 있습니다.
클래스 객체에만 포인터가 있습니다. 단순 포인터 유형의 구조 및 변수 인스턴스에는 없습니다. new() 연산자를 사용하여 생성되지 않았지만 예를 들어 객체 배열에서 자동으로 생성된 클래스의 객체에는 여전히 포인터가 있습니다. 이 포인터만 POINTER_AUTOMATIC 유형이며 delete() 연산자를 적용할 수 없습니다. 그렇지 않으면 유형 포인터는 POINTER_AUTOMATIC 유형의 동적 포인터와 다르지 않습니다.
유형 구조 및 단순 유형의 변수에는 포인터가 없으므로 GetPointer() 함수를 적용하는 것이 금지됩니다. 포인터를 함수 인수로 전달하는 것도 금지됩니다. 이 모든 경우에 컴파일러는 오류를 보고합니다.
보안이 더 중요하기 때문에 다른 개체에 대한 핸들은 중요하지 않습니다.
구조를 포함하여 모든 데이터 유형을 사용하여 데이터를 OpenCL에 전달할 수 있습니다. void*를 사용합니다. 균일한 데이터 를 올바른 형식으로 준비하고 작업하기만 하면 됩니다. "하지만 나는 그것을 원하지 않는다, 나는 그것을 내 방식대로 원한다"라는 질문을 예상하고 나는 그것이 작동하지 않을 것이라고 대답 할 것입니다. 안전이 더 중요합니다.
1. 데이터를 OpenCL로 전송하려면 구조를 포함한 모든 데이터 유형 을 사용할 수 있습니다. void*를 사용합니다. 균일한 데이터 를 올바른 형식으로 준비하고 작업하기만 하면 됩니다. "하지만 난 원하지 않아, 난 내 방식대로 원해"라는 질문을 예상하고 나는 그것이 작동하지 않을 것이라고 대답 할 것입니다. 안전이 더 중요합니다.
2. 보안 실행 언어는 공개/직접 액세스를 제공해서는 안 됩니다.
1. '나만의 방식으로' 원하는 것은 전혀 아니다. 그리고 가장 원시적인 클래스를 포함하여 모든 클래스에 대해 mql5 컴파일러는 객체에 해당하는 숨겨진 필드(VMT에 대한 포인터)와 함께 VMT를 생성합니다. 그리고 원시 버퍼(파일)에 있는 이 포인터는 제 목에 무리를 줍니다. 공간을 차지하는 쓰레기일 뿐만 아니라 패킷의 데이터 정렬을 완전히 부적절하게 위반합니다(OpenCL 버퍼에서 정렬은 128비트임). 그게 요점입니다. 클래스를 사용하고 싶은 유혹이 있습니다. mql에서 클래스와 함께 작업하는 것이 편리합니다. 하지만... 위를 참조하세요.
델파이에는 좋은 대안 구현 예가 있습니다. VMT 및 따라서 VMT에 대한 포인터는 클래스 계층 구조에서 첫 번째 가상 메서드가 나타난 후에만 클래스에 나타납니다. mql5에 동일한 항목이 있었다면 상황을 훨씬 더 관리하기 쉬웠을 것입니다. 구조 대신 가상 메소드 없이 클래스를 사용하는 것이 가능하며 구조를 망치는 "부속품"이 없습니다.
이제 구조체 배열을 캡슐화하는 추상 (상속을 위한) 클래스의 구현이 여기에 상속된 서비스(예: 정렬)를 주입할 수 없는 상황에 직면해 있습니다. 구조 배열을 클래스 배열로 교체하면 이 문제가 해결되지만 또 다른 문제가 발생합니다....(위 참조).
2. 그리고 저는 "직접 접근"을 요구하지 않습니다. 주소 산술에 관심이 없습니다. 이유도 없이 왜 애들을 겁주는거야? :) mql5 핸들은 "원시" 포인터에 가깝지 않습니다. 그리고 (교활하게) 그렇다면 실제 보안 허점이 여기에 있으며 사용자 데이터에 대한 핸들(의사 포인터) 구현이 아닙니다.
---
이제 가상 기능(및 각각 VMT)이 없는 실제로 클래스인 구조가 있습니다. 글쎄요. 좋습니다. 클래스 기능(핸들)을 몇 개 더 추가하기만 하면 됩니다. 본격적인 작업의 경우 옳을 것입니다. 그러면 배열에 대한 포인터가 더 이상 긴급하게 필요하지 않습니다(필요한 경우 구조로 래핑할 수 있음).
1. '나만의 방식으로' 원하는 것은 전혀 아니다. 그리고 가장 원시적인 클래스를 포함하여 모든 클래스에 대해 mql5 컴파일러는 객체에 해당하는 숨겨진 필드(VMT에 대한 포인터)와 함께 VMT를 생성합니다. 그리고 원시 버퍼(파일)에 있는 이 포인터는 제 목에 무리를 줍니다. 공간을 차지하는 쓰레기일 뿐만 아니라 패킷의 데이터 정렬을 완전히 부적절하게 위반합니다(OpenCL 버퍼에서 정렬은 128비트임). 그게 요점입니다. 클래스를 사용하고 싶은 유혹이 있습니다. mql에서 클래스와 함께 작업하는 것이 편리합니다. 하지만... 위를 보십시오.
델파이에는 좋은 대안 구현 예가 있습니다. VMT 및 따라서 VMT에 대한 포인터는 클래스 계층 구조에서 첫 번째 가상 메서드가 나타난 후에만 클래스에 나타납니다. mql5에 동일한 기능이 있었다면 상황을 훨씬 더 관리하기 쉬웠을 것입니다. 구조 대신 가상 메소드 없이 클래스를 사용하는 것이 가능하고 구조를 망치는 "부속품"이 없습니다.
이제 구조체 배열을 캡슐화 하는 추상 (상속을 위한) 클래스의 구현이 정렬과 같은 상속된 서비스를 주입할 수 없는 상황에 직면했습니다. 구조 배열을 클래스 배열로 바꾸면 이 문제가 해결되지만 또 다른 문제가 발생합니다....(위 참조).
2. 그리고 저는 "직접 접근"을 요구하지 않습니다. 주소 산술에 관심이 없습니다. 이유도 없이 왜 애들을 겁주는거야? :) mql5 핸들은 "원시" 포인터에 가깝지 않습니다. 그리고 (교활하게) 그렇다면 실제 보안 허점이 여기에 있으며 사용자 데이터에 대한 핸들(의사 포인터) 구현이 아닙니다.
추상 데이터(이미 많은 내부 메타데이터 및 관계를 의미함)로 복잡한 시스템을 구축한 다음 까다로운 방식으로 변경할 수 있는 제어되지 않는 OpenCL 환경으로 전송하려고 합니다. 이것이 바로 우리가 가상 테이블을 덮어쓸 수 있는 기능 없이 단순한 개체와 배열에 대해서만 자유롭게 작업할 수 있도록 허용하는 이유입니다.
실제로 "추상 구성의 자유"를 통해 직접 액세스를 암시적으로 요청하고 있습니다. 이 주제는 우리가 잘 연구했으며 안전을 위해 구조적으로 다룹니다. MQL5의 클래스는 보안에 중점을 둔 자체 규칙에 따라 진행됩니다. 다른 유형에는 핸들이 없습니다. 단순한 유형 및 구조에 대한 핸들 대신 배열에 인덱스를 사용할 수 있습니다.
1. 추상 데이터(이미 많은 내부 메타데이터 및 관계를 의미함)로 복잡한 시스템을 구축한 다음 까다로운 방식으로 변경할 수 있는 제어되지 않는 OpenCL 환경으로 전송하려고 합니다. 이것이 바로 우리가 가상 테이블을 덮어쓸 수 있는 기능 없이 단순한 개체와 배열에 대해서만 자유롭게 작업할 수 있도록 허용하는 이유입니다.
2. 실제로 "추상 구성의 자유"를 통해 직접 액세스를 암시적으로 요청하고 있습니다. 이 주제는 우리가 잘 연구했으며 안전을 위해 구조적으로 다룹니다. MQL5의 클래스는 보안에 중점을 둔 자체 규칙에 따라 진행됩니다.
3. MQL5의 핸들이 올바른지(1에서 증가) 직접 확인할 수 있습니다.
1. 모든 것이 완전히 반대입니다. 메타데이터(핸들) 없이 완전히 순수한 데이터를 버퍼로 전송하고 싶습니다. mql5 처리 내부에서 편리한 작업을 위해 핸들이 필요합니다. 버퍼에 이 메타데이터가 필요하지 않습니다. 그들은 나를 방해합니다. 그리고 나는 그것들을 거기에 둘 수 없을 것입니다 - CLBufferWrite() 가 저를 허락하지 않을 것입니다. 그리고 맞습니다.
2. 직접적인 접근 을 요구하는 것이 아닙니다 . 직접 액세스를 위해(원한다면) DLL을 사용할 수 있습니다. 일반 memcpy()
aPointer = memcpy(a,a);
원시 포인터를 얻는 문제를 해결합니다. 레나트, 진짜 문제를 파헤쳐 보세요. 존재하지 않는 "실제로" 를 발명하지 마십시오. 실제로 있는 모든 것 - 요청에 설명된 잠수함 없이 직접 나. 가능한 한 건설적이고 보안 문제를 완전히 이해합니다.
3. 멋져요.
--
구조의 동적 생성 및 삭제(신규, 삭제)는 전혀 수행할 필요가 없습니다. 어떤 경우에도 아닙니다. 그러면 보안 문제가 발생하지 않습니다. 문제가 "정말"(귀하의 언어로) 무엇인지 이해합니다. 동적 객체의 실제 유형을 판별하는 데 문제가 있습니다. 클래스의 경우 VMT에 대한 포인터 분석을 통해 해결될 가능성이 큽니다. 그러나 동적 구조가 없습니다. 그런 문제가 없습니다.
적절한 수의 개체(클래스, 파일 등)에 핸들을 제공하는 것이 가능합니다. 그러나 모든 크기의 배열 영역으로 이동하면 모든 핸들이 메모리 조각에 대한 직접 링크일 가능성이 있습니다 . 그렇지 않으면 "핸들 -> 메모리" 매핑 테이블이 참조된 엔터티보다 더 많은 메모리를 소비합니다.
그리고 보안 상황에 따라 메모리를 직접 가리키는 핸들을 가질 수 없습니다. 따라서 "무제한 엔티티"에 대한 핸들이 없습니다.
1. 적절한 수의 개체(클래스, 파일 등)에 핸들을 제공할 수 있습니다. 그러나 모든 크기의 배열 영역으로 이동하면 모든 핸들이 메모리 조각에 대한 직접 링크일 가능성이 있습니다 . 그렇지 않으면 "핸들 -> 메모리" 매핑 테이블이 참조된 엔터티보다 더 많은 메모리를 소비합니다.
2. 그리고 보안 상황에 따라 메모리를 직접 가리키는 핸들을 가질 수 없습니다. 따라서 "무제한 엔티티"에 대한 핸들이 없습니다.
1. 건설적이다. 나는 생각했다. 문제는 거대한 구조와 관련하여 정확하게 발생했습니다. 소규모 구조의 경우 복사 시간이 이미 짧습니다. 여기서 문제는 사용자의 불합리함 때문에 발생할 수 있는 것 같습니다. 그러나 "어리석음"이므로 메모리를 무엇이든 채울 수 있습니다(예: 표시기 버퍼 포함). 절대적으로 필요한 경우가 아니면 아무도 핸들 을 정적 구조 보다 선호할 것으로 기대하지 않습니다. 글쎄, 기억이 넘칠 것이다 - 그것은 그 자신의 잘못이다. 사람들의 어리 석음에 대해 너무 걱정하지 마십시오. 모든 것을 예방 (그리고 예측) 할 수있는 방법은 없습니다. :)
2. 아니, 아니. 직접 포인터는 필요하지 않습니다. 그러나 핸들은 "무한한 엔터티"라도 아프지 않을 것입니다. 가장 중요한 것은 사용할 의무가 없다는 것입니다. 그러면 모든 사람에게 충분한 메모리가 제공됩니다. :)
Статья о традиционных и не совсем традиционных алгоритмах усреднения, упакованных в максимально простые и достаточно однотипные классы. Они задумывались для универсального использования в практических разработках индикаторов. Надеюсь, что предложенные классы в определенных ситуациях могут оказаться достаточно актуальной альтернативой громоздким, в некотором смысле, вызовам пользовательских и технических индикаторов.
Не секрет, что большую часть информации об окружающем мире человек получает при помощи зрения. Справедливо это и в такой области как трейдинг. Новая платформа MetaTrader 5 и язык MQL5 открывают новые возможности для представления визуальной информации трейдеру. В данной статье предлагается универсальная и расширяемая система классов, которая берет на себя всю черновую работу по организации вывода произвольной текстовой информации.
1. 문제가 되는 것은 바로 그 점이다. 버퍼에 클래스 배열을 쓸 필요가 없습니다(이는 불가능합니다). 거기에 구조를 작성해야 합니다. 그리고 빠르게(클래스에서 구조로 멤버별로 다시 작성하지 않고). 그리고 재정렬된 액세스를 위해 핸들이 필요합니다(또한 다른 키로 정렬하기 위해).
교체는 내 자신의 인덱스 테이블이 될 수 있지만 한 번 작성된 서비스(정렬 및 이진 검색)와 함께 상속할 가능성이 있는 구조 배열로 작업을 캡슐화하는 클래스를 만들 수 없습니다.
하나.
구조(배열)에 대한 포인터 배열을 생성합니다. 후속 초기화 for(i){ S[i] = GetPointer(StaticStruct[i]); }
2. 의미 있는 데이터 배열의 견고한(포장된) 형태를 유지합니다.
원시 OpenCL 버퍼에 대한 데이터 출력으로 작업할 때 중요합니다(또는 DLL로 보내기, 파일에 쓰기 등).
이것은 데이터를 다시 쓰지 않고 데이터 액세스를 재정렬할 가능성(예: 포인터 를 정렬할 때 )을 유지(나타납니다)합니다.
보안 언어는 직접 액세스를 노출/제공해서는 안 됩니다.
클래스에는 더 많은 보호 기능이 있으므로 핸들이 있습니다.
보안이 더 중요하기 때문에 다른 개체에 대한 핸들은 중요하지 않습니다.
구조를 포함하여 모든 데이터 유형을 사용하여 데이터를 OpenCL에 전달할 수 있습니다. void*를 사용합니다. 균일한 데이터 를 올바른 형식으로 준비하고 작업하기만 하면 됩니다. "하지만 나는 그것을 원하지 않는다, 나는 그것을 내 방식대로 원한다"라는 질문을 예상하고 나는 그것이 작동하지 않을 것이라고 대답 할 것입니다. 안전이 더 중요합니다.
1. 데이터를 OpenCL로 전송하려면 구조를 포함한 모든 데이터 유형 을 사용할 수 있습니다. void*를 사용합니다. 균일한 데이터 를 올바른 형식으로 준비하고 작업하기만 하면 됩니다. "하지만 난 원하지 않아, 난 내 방식대로 원해"라는 질문을 예상하고 나는 그것이 작동하지 않을 것이라고 대답 할 것입니다. 안전이 더 중요합니다.
2. 보안 실행 언어는 공개/직접 액세스를 제공해서는 안 됩니다.
1. '나만의 방식으로' 원하는 것은 전혀 아니다. 그리고 가장 원시적인 클래스를 포함하여 모든 클래스에 대해 mql5 컴파일러는 객체에 해당하는 숨겨진 필드(VMT에 대한 포인터)와 함께 VMT를 생성합니다. 그리고 원시 버퍼(파일)에 있는 이 포인터는 제 목에 무리를 줍니다. 공간을 차지하는 쓰레기일 뿐만 아니라 패킷의 데이터 정렬을 완전히 부적절하게 위반합니다(OpenCL 버퍼에서 정렬은 128비트임). 그게 요점입니다. 클래스를 사용하고 싶은 유혹이 있습니다. mql에서 클래스와 함께 작업하는 것이 편리합니다. 하지만... 위를 참조하세요.
델파이에는 좋은 대안 구현 예가 있습니다. VMT 및 따라서 VMT에 대한 포인터는 클래스 계층 구조에서 첫 번째 가상 메서드가 나타난 후에만 클래스에 나타납니다. mql5에 동일한 항목이 있었다면 상황을 훨씬 더 관리하기 쉬웠을 것입니다. 구조 대신 가상 메소드 없이 클래스를 사용하는 것이 가능하며 구조를 망치는 "부속품"이 없습니다.
이제 구조체 배열을 캡슐화하는 추상 (상속을 위한) 클래스의 구현이 여기에 상속된 서비스(예: 정렬)를 주입할 수 없는 상황에 직면해 있습니다. 구조 배열을 클래스 배열로 교체하면 이 문제가 해결되지만 또 다른 문제가 발생합니다....(위 참조).
2. 그리고 저는 "직접 접근"을 요구하지 않습니다. 주소 산술에 관심이 없습니다. 이유도 없이 왜 애들을 겁주는거야? :) mql5 핸들은 "원시" 포인터에 가깝지 않습니다. 그리고 (교활하게) 그렇다면 실제 보안 허점이 여기에 있으며 사용자 데이터에 대한 핸들(의사 포인터) 구현이 아닙니다.
---
이제 가상 기능(및 각각 VMT)이 없는 실제로 클래스인 구조가 있습니다. 글쎄요. 좋습니다. 클래스 기능(핸들)을 몇 개 더 추가하기만 하면 됩니다. 본격적인 작업의 경우 옳을 것입니다. 그러면 배열에 대한 포인터가 더 이상 긴급하게 필요하지 않습니다(필요한 경우 구조로 래핑할 수 있음).
1. '나만의 방식으로' 원하는 것은 전혀 아니다. 그리고 가장 원시적인 클래스를 포함하여 모든 클래스에 대해 mql5 컴파일러는 객체에 해당하는 숨겨진 필드(VMT에 대한 포인터)와 함께 VMT를 생성합니다. 그리고 원시 버퍼(파일)에 있는 이 포인터는 제 목에 무리를 줍니다. 공간을 차지하는 쓰레기일 뿐만 아니라 패킷의 데이터 정렬을 완전히 부적절하게 위반합니다(OpenCL 버퍼에서 정렬은 128비트임). 그게 요점입니다. 클래스를 사용하고 싶은 유혹이 있습니다. mql에서 클래스와 함께 작업하는 것이 편리합니다. 하지만... 위를 보십시오.
델파이에는 좋은 대안 구현 예가 있습니다. VMT 및 따라서 VMT에 대한 포인터는 클래스 계층 구조에서 첫 번째 가상 메서드가 나타난 후에만 클래스에 나타납니다. mql5에 동일한 기능이 있었다면 상황을 훨씬 더 관리하기 쉬웠을 것입니다. 구조 대신 가상 메소드 없이 클래스를 사용하는 것이 가능하고 구조를 망치는 "부속품"이 없습니다.
이제 구조체 배열을 캡슐화 하는 추상 (상속을 위한) 클래스의 구현이 정렬과 같은 상속된 서비스를 주입할 수 없는 상황에 직면했습니다. 구조 배열을 클래스 배열로 바꾸면 이 문제가 해결되지만 또 다른 문제가 발생합니다....(위 참조).
2. 그리고 저는 "직접 접근"을 요구하지 않습니다. 주소 산술에 관심이 없습니다. 이유도 없이 왜 애들을 겁주는거야? :) mql5 핸들은 "원시" 포인터에 가깝지 않습니다. 그리고 (교활하게) 그렇다면 실제 보안 허점이 여기에 있으며 사용자 데이터에 대한 핸들(의사 포인터) 구현이 아닙니다.
추상 데이터(이미 많은 내부 메타데이터 및 관계를 의미함)로 복잡한 시스템을 구축한 다음 까다로운 방식으로 변경할 수 있는 제어되지 않는 OpenCL 환경으로 전송하려고 합니다. 이것이 바로 우리가 가상 테이블을 덮어쓸 수 있는 기능 없이 단순한 개체와 배열에 대해서만 자유롭게 작업할 수 있도록 허용하는 이유입니다.
실제로 "추상 구성의 자유"를 통해 직접 액세스를 암시적으로 요청하고 있습니다. 이 주제는 우리가 잘 연구했으며 안전을 위해 구조적으로 다룹니다. MQL5의 클래스는 보안에 중점을 둔 자체 규칙에 따라 진행됩니다. 다른 유형에는 핸들이 없습니다. 단순한 유형 및 구조에 대한 핸들 대신 배열에 인덱스를 사용할 수 있습니다.
MQL5의 핸들 자체가 올바른지(1에서 증가) 확인할 수 있습니다.
1. 추상 데이터(이미 많은 내부 메타데이터 및 관계를 의미함)로 복잡한 시스템을 구축한 다음 까다로운 방식으로 변경할 수 있는 제어되지 않는 OpenCL 환경으로 전송하려고 합니다. 이것이 바로 우리가 가상 테이블을 덮어쓸 수 있는 기능 없이 단순한 개체와 배열에 대해서만 자유롭게 작업할 수 있도록 허용하는 이유입니다.
2. 실제로 "추상 구성의 자유"를 통해 직접 액세스를 암시적으로 요청하고 있습니다. 이 주제는 우리가 잘 연구했으며 안전을 위해 구조적으로 다룹니다. MQL5의 클래스는 보안에 중점을 둔 자체 규칙에 따라 진행됩니다.
3. MQL5의 핸들이 올바른지(1에서 증가) 직접 확인할 수 있습니다.
1. 모든 것이 완전히 반대입니다. 메타데이터(핸들) 없이 완전히 순수한 데이터를 버퍼로 전송하고 싶습니다. mql5 처리 내부에서 편리한 작업을 위해 핸들이 필요합니다. 버퍼에 이 메타데이터가 필요하지 않습니다. 그들은 나를 방해합니다. 그리고 나는 그것들을 거기에 둘 수 없을 것입니다 - CLBufferWrite() 가 저를 허락하지 않을 것입니다. 그리고 맞습니다.
2. 직접적인 접근 을 요구하는 것이 아닙니다 . 직접 액세스를 위해(원한다면) DLL을 사용할 수 있습니다. 일반 memcpy()
aPointer = memcpy(a,a);
원시 포인터를 얻는 문제를 해결합니다. 레나트, 진짜 문제를 파헤쳐 보세요. 존재하지 않는 "실제로" 를 발명하지 마십시오. 실제로 있는 모든 것 - 요청에 설명된 잠수함 없이 직접 나. 가능한 한 건설적이고 보안 문제를 완전히 이해합니다.
3. 멋져요.
--
구조의 동적 생성 및 삭제(신규, 삭제)는 전혀 수행할 필요가 없습니다. 어떤 경우에도 아닙니다. 그러면 보안 문제가 발생하지 않습니다. 문제가 "정말"(귀하의 언어로) 무엇인지 이해합니다. 동적 객체의 실제 유형을 판별하는 데 문제가 있습니다. 클래스의 경우 VMT에 대한 포인터 분석을 통해 해결될 가능성이 큽니다. 그러나 동적 구조가 없습니다. 그런 문제가 없습니다.
어떤 규모의 엔티티와 관련하여 "핸들"이 무엇인지 생각해보십시오.
적절한 수의 개체(클래스, 파일 등)에 핸들을 제공하는 것이 가능합니다. 그러나 모든 크기의 배열 영역으로 이동하면 모든 핸들이 메모리 조각에 대한 직접 링크일 가능성이 있습니다 . 그렇지 않으면 "핸들 -> 메모리" 매핑 테이블이 참조된 엔터티보다 더 많은 메모리를 소비합니다.
그리고 보안 상황에 따라 메모리를 직접 가리키는 핸들을 가질 수 없습니다. 따라서 "무제한 엔티티"에 대한 핸들이 없습니다.
Renat :
1. 적절한 수의 개체(클래스, 파일 등)에 핸들을 제공할 수 있습니다. 그러나 모든 크기의 배열 영역으로 이동하면 모든 핸들이 메모리 조각에 대한 직접 링크일 가능성이 있습니다 . 그렇지 않으면 "핸들 -> 메모리" 매핑 테이블이 참조된 엔터티보다 더 많은 메모리를 소비합니다.
2. 그리고 보안 상황에 따라 메모리를 직접 가리키는 핸들을 가질 수 없습니다. 따라서 "무제한 엔티티"에 대한 핸들이 없습니다.
1. 건설적이다. 나는 생각했다. 문제는 거대한 구조와 관련하여 정확하게 발생했습니다. 소규모 구조의 경우 복사 시간이 이미 짧습니다. 여기서 문제는 사용자의 불합리함 때문에 발생할 수 있는 것 같습니다. 그러나 "어리석음"이므로 메모리를 무엇이든 채울 수 있습니다(예: 표시기 버퍼 포함). 절대적으로 필요한 경우가 아니면 아무도 핸들 을 정적 구조 보다 선호할 것으로 기대하지 않습니다. 글쎄, 기억이 넘칠 것이다 - 그것은 그 자신의 잘못이다. 사람들의 어리 석음에 대해 너무 걱정하지 마십시오. 모든 것을 예방 (그리고 예측) 할 수있는 방법은 없습니다. :)
2. 아니, 아니. 직접 포인터는 필요하지 않습니다. 그러나 핸들은 "무한한 엔터티"라도 아프지 않을 것입니다. 가장 중요한 것은 사용할 의무가 없다는 것입니다. 그러면 모든 사람에게 충분한 메모리가 제공됩니다. :)
젠장, 여기서 창을 부수는 게 이해가 안 가요. 핸들을 원하면 구조를 클래스로 선언하는 것이 요점입니다.
메모리에 직접 액세스하려면 dll을 작성하십시오.
젠장, 여기서 창을 부수는 게 이해가 안 가요.
1. 핸들을 원하면 구조체를 클래스로 선언하는 것이 요점입니다.
2. 메모리에 직접 접근하려면 dll을 작성하십시오.
1. 문제가 되는 것은 바로 그 점이다. 버퍼에 클래스 배열을 쓸 필요가 없습니다(이는 불가능합니다). 거기에 구조를 작성해야 합니다. 그리고 빠르게(클래스에서 구조로 멤버별로 다시 작성하지 않고). 그리고 재정렬된 액세스를 위해 핸들이 필요합니다(또한 다른 키로 정렬하기 위해).
교체는 내 자신의 인덱스 테이블이 될 수 있지만 한 번 작성된 서비스(정렬 및 이진 검색)와 함께 상속할 가능성이 있는 구조 배열로 작업을 캡슐화하는 클래스를 만들 수 없습니다.
2. 하기 싫어! !! !!! 내가 갑자기 꿰매기에 충분한 사업입니다! :))
아니요, 우리는 그러한 처리를 하지 않을 것입니다. 이것은 우리가 끝까지 대답해야 할 솔직한 악입니다.
이상적인 솔루션은 매개변수화 가능한 클래스입니다.
class MyClass<T> { T MyArray[]; .... };그러나 나는 더 이상 그것에 연연하지 않습니다. 어쩌면 헛된?