문자열에 "ABCDEFG"이 포함 된 메모리에 할당되어 있지만 포인터가 'E' 인 경우를 가정 해 보겠습니다. win32에서 () 내에있는 포인터가 있지만 그 블록을 해제 할 수 있습니까? 모든 할당 방법이 작동하지만 Heap* 함수는 저항이 가장 적은 경로가됩니다.오프셋 포인터를 사용하여 메모리를 비울 수 있습니까?
네이티브 솔루션이 아닌 경우이 기능을 제공하는 맞춤 메모리 관리자가 있습니까?
편집 : 이것은 엉성한 표현이 아닙니다. 나는 100 % 컴파일 타임 메타 데이터를 사용하는 자동 메모리 관리 시스템을 개발 중이다. 이 이상한 요구 사항은 작동시키는 방식으로 서있는 유일한 것으로 보이며 심지어 배열 (슬라이스 가능)을 기반으로하는 데이터 유형에만 필요합니다.
malloc() 가드 블록이 어떤 모양인지 알면 원래 메모리 주소의 '가장 추측 된'값을 찾아 free()을 호출 할 때까지 포인터를 전달하는 함수를 작성할 수 있습니다. 왜 그냥 기본 포인터의 사본을 보관하지 않는 것이 좋을까요?
VirtualAlloc을 사용하여 메모리를 할당하는 경우 VirtualQuery을 사용하여 포인터가 속한 블록을 파악할 수 있습니다. 기본 주소를 얻은 후에는 VirtualFree에 전달하여 전체 블록을 비울 수 있습니다.
페이지 단위 단위 할당을 제외하고 이것은 멋지게 보입니다. 내일과 32 비트 주소 제한이없는 것처럼 나의 메모리 요구 사항은 급증 할 것입니다. – zildjohn01
런타임 라이브러리의 메모리 할당 루틴은 할당 된 모든 블록의 시작과 끝에 대해 주어진 메모리 주소를 검사 할 수 있습니다. 검색이 완료되면 블록을 처음부터 해제하는 것이 쉬울 것입니다.
그 뒤에있는 영리한 알고리즘을 사용하더라도 각 메모리 할당 해제로 일종의 검색이 발생합니다. 그리고 왜? 그들이 할당 한 메모리 블록의 시작 부분을 추적하기에 너무 어리석은 잘못된 프로그램을 지원하기 위해?
표준 C 언어는 배열과 같이 할당 된 메모리 블록을 처리하는 데 번창합니다. * alloc에서 반환 된 포인터는 배열의 시작 부분에 대한 포인터이며 포인터는 해당 배열의 요소에 액세스하기 위해 첨자와 함께 사용할 수 있습니다 (0에서 시작하는 첨자). 이것은 40 년 동안 충분히 잘 작동하지 않았습니다. 여기에 변화를 가져올 현명한 이유를 생각해보십시오.
+1 - "왜? 잘못된 프로그램을 너무 바보로 지원하여 할당 된 메모리 블록의 시작을 추적 할 수 없습니까?" –
일부 런타임 패널티를 기꺼이 받아 들일 의향이 있습니다. 어쨌든 쉽게 최소화 할 수 있다고 생각합니다 (생각 : 바이너리 검색). 모든 동적 할당은 수행 중이라고 비 결정적이라는 것을 기억하십시오. 그리고 40 년 동안 똑같은 일이 있었기 때문에 혁신을하지 않을 이유가 없습니다. 사실 그 반대가 사실이라고 말하고 싶습니다. 내 편집을 참조하십시오. – zildjohn01
음, 메모리 관리 시스템을 작성하는 경우 문제를 해결할 수있는 완벽한 위치에 있습니다. 당신은 할당 된 메모리 덩어리의 시작 주소의 균형 잡힌 b-tree를 유지하기를 원할 것이고, 그 안에 어딘가에 포인터가있는 메모리 덩어리를 풀고 싶다면, 당신의 나무보다 더 낮은 시작 주소를 찾아라. 바늘. 나무를 가꾸기위한 노력 이외에도 문제가 해결됩니다. 검색 시간은 할당 된 청크 수에 O (logN)가됩니다. –
(a) 순차 스캔의 성능과 (b) 메모리에서 찾은 패턴이 실제로 가드 블록이라는 것을 확신하기 가드 블록으로 다시 스캔하는 것은 좋지 않습니다. 블록 할당의 시작 주소를 추적하는 것이 유일한 합리적인 해결책이라는 사실에 동의 할 것입니다. –