음 님이 쓰신 글 :
: 2차원 배열 동적할당을 하고
: 동적할당된 배열의 사이즈를 찾아보았습니다.
:
: 1x1 배열을 만든 경우는
: 동적할당된 배열의 사이즈는 3x1로 나왔습니다.
:
: 12x1 배열을 만든 경우는
: 동적할당된 배열의 사이즈는 13x1이 나왔습니다.
:
: 비쥬얼스튜디오에서 한 경우에는 정상적으로 나왔는데 c++ 빌더 커뮤니티 에디션으로 한 결과는 같은 코드에서 이상하게 나왔습니다.
: 어디에 문제가 있을까요?
:
: 아니면 다른 방법이 있다면 추천 부탁드립니다.
: 
:
: 아래는 제가 만든 코드입니다.
:
: - 2차원 배열 동적 할당   
:         double** data;
:     //2차원 배열 동적 할당
:     data = new double*[m_Rows];
:     for(int i = 0; i< m_Rows; i++){
:         data[i] = new double[m_Cols];
:         for(int j = 0; j<m_Cols; j++){
:             data[i][j] = 0;
:         }
:     }
:
: - 동적할당된 배열의 사이즈 찾기
:     m_Rows = _msize(data)/sizeof(data[0]);
:     m_Cols = _msize(data[0])/sizeof(data[0][0]);
:




답변:


바빠서 요점만 남깁니다.


델파이 버전 몇 부터인가 부터...
메모리 매니지먼트 코드로 fastMM 을 베겨서 쓰고 있는데

fastMM은 힙 블럭을 small, medium, large로 구분해서 메모리를 관리하는
간단한 방법으로 구현되어 있고, 파스칼 컴파일러 자체가 옵티마이징이 후져서
속도를 낸답시고 단무지 같은 방법으로 어셈블리 코드를 잔뜩 쓰고 있죠. (델파이 RTL도 마찬가지)

델파이에서 베껴쓰고 있는 메모리 매니지먼트 코드는 fastMM 의 간략화된 버전이라고 보면 되고.

C++빌더는 파스칼로 컴파일 되어 있는 델파이 RTL, VCL에 종속되어 있기 때문에
메모리 매니지먼트 구조도 종속성을 피할 수 없고.

64비트 컴파일 환경에선 _msize() 자체가 아예 구현되어 있지도 않고
'Link with Dynamic RTL'로 지정하지 않으면 32비트로도 컴파일 할 수 없는 문제도 갖고 있지요.



델파이가 베껴 쓰고 있는 fastMM 메모리 매니지먼트 내부 구조를 변경해서
RTL과 C++ 런타임 코드를 후킹하지 않으면 정확한 사이즈를 얻는 게 델파이 때문에 구조적으로 불가능 합니다.


델파이와 완전히 분리해서 C++ 독립적인 구조로 개발환경이 바뀌지 않는 이상.
지금의 C++빌더는 족보도 없는 이상한 컴파일러에 불과한 거고.

C++17 스펙으로 반드시 정의되어 있어야 할 scoped lock 조차도 구현되어 있지 않은 엉터리 컴파일러.
이런 엉터리 컴파일러를 돈 받고 파는 뻔뻔함은 도대체 어디서 나오는 건지...