저는 쓰레드 동기화로 TMonitor::Enter와 TMonitor::Exit를 쓰고있는데요
scoped lock은 다른가요?


빌더(TWx) 님이 쓰신 글 :
: 음 님이 쓰신 글 :
: : 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 조차도 구현되어 있지 않은 엉터리 컴파일러.
: 이런 엉터리 컴파일러를 돈 받고 파는 뻔뻔함은 도대체 어디서 나오는 건지...
:
:
: