C의 "자유"는 왜 자유로워지는 바이트 수를 가져가지 않는가?

C의 "자유"는 왜 자유로워지는 바이트 수를 가져가지 않는가?

확실히 하자면:난 그걸 알아.malloc그리고freeC 라이브러리에서 구현되며, 이 라이브러리는 대개 OS에서 메모리 덩어리를 할당하고 애플리케이션에 더 적은 양의 메모리를 배포하기 위해 자체 관리를 하며 할당된 바이트 수를 추적한다.이 질문은 자유가 어떻게 자유로워야 하는지 아는 것이 아니다.

오히려 그 이유를 알고 싶다.free애초에 이런 식으로 만들어졌지낮은 수준의 언어인 나는 C 프로그래머에게 어떤 메모리가 할당되었는지뿐만 아니라 얼마나 많이 할당되었는지 추적하도록 요청하는 것이 지극히 합리적일 것이라고 생각한다(사실, 나는 일반적으로 어쨌든 나는 결국 멀로케이션된 바이트 수를 추적하게 된다는 것을 알게 된다).바이트 수를 명시적으로 주는 것도 생각난다.free일부 성능 최적화를 허용할 수 있다. 예를 들어, 서로 다른 할당 크기에 대해 별도의 풀을 가진 할당자는 입력 인수를 보는 것만으로도 어떤 풀을 사용할지 결정할 수 있을 것이며, 전체적으로 공간 오버헤드가 줄어들 것이다.

그래서 요컨대 왜 그랬을까.malloc그리고free할당된 바이트 수를 내부적으로 추적해야 하는 경우그냥 역사적 사고일까.

작은 편집:몇몇 사람들은 "할당한 금액과 다른 금액을 비우면 어떨까"와 같은 포인트를 제공했다.내가 상상하는 API는 정확히 할당된 바이트의 수를 자유롭게 하는 것을 요구할 수 있다; 자유는 UB 또는 구현이 정의될 수 있다.하지만 다른 가능성에 대한 토론을 방해하고 싶지는 않다.

원론free(void *)(유닉스 V7에 소개됨) 이전의 두 가지 주장보다 또 다른 주요 이점을 가지고 있음mfree(void *, size_t)내가 여기서 언급하지 않은 것: 한 가지 논쟁free힙 메모리와 함께 작동하는 모든 다른 API를 획기적으로 간소화하십시오.예를 들어, 다음과 같다.free메모리 블록의 크기가 필요했고,strdup어떻게 해서든 하나의 값(점퍼)이 아닌 두 개의 값(점퍼 + 크기)을 반환해야 할 것이며, C는 단일 값 반환보다 다중 값 반환이 훨씬 더 번거롭다.대신에char *strdup(char *)우리는 편지를 써야 할 것이다.char *strdup(char *, size_t *)또는 그 밖의struct CharPWithSize { char *val; size_t size}; CharPWithSize strdup(char *)(요즘 두 번째 옵션은 NUL 종단 문자열이 "컴퓨팅 역사상 가장 치명적인 설계 버그"라는 것을 알기 때문에 꽤 유혹적으로 보이지만, 그것은 사후 판단이다.70년대에 C의 현악기 다루는 능력은 단순하다.char *실제로 Pascal과 Algol과 같은 경쟁자들에 비해 결정적인 우위로 여겨졌다.)게다가, 그것은 단지strdup힙 메모리를 할당하는 모든 시스템 또는 사용자 정의 기능에 영향을 미침

초기 유닉스 디자이너들은 매우 영리한 사람들이었고, 많은 이유들이 있다.free보다 낫다mfree그래서 기본적으로 나는 그 질문에 대한 답은 그들이 이것을 알아차리고 그에 따라 시스템을 설계했다는 것이라고 생각한다.그들이 그 결정을 내린 순간 그들의 머릿속에서 무슨 일이 벌어지고 있었는지에 대한 어떤 직접적인 기록도 찾을 수 없을 것이다.하지만 우리는 상상할 수 있다.

V6 Unix에서 실행할 애플리케이션을 C에서 작성하는 것처럼 두 가지 주장으로 가정해 보십시오.mfree. 지금까지 잘 관리해 왔지만 프로그램이 점점 더 야심 차게 되고 힙할당 변수를 점점 더 많이 사용하게 되면서 이러한 포인터 크기를 추적하는 것이 점점 더 번거로워지고 있다.하지만 당신은 훌륭한 아이디어를 가지고 있다: 이것들을 복사하는 대신에.size_t항상 할당된 메모리 내에 크기를 직접 저장하는 몇 가지 유틸리티 기능을 쓸 수 있다.

void *my_alloc(size_t size) {
    void *block = malloc(sizeof(size) + size);
    *(size_t *)block = size;
    return (void *) ((size_t *)block + 1);
}
void my_free(void *block) {
    block = (size_t *)block - 1;
    mfree(block, *(size_t *)block);
}

그리고 이 새로운 기능을 사용하여 코드를 더 많이 쓸수록, 그것들은 더 멋져 보인다.그것들은 여러분의 코드를 쓰기 쉽게 만들 뿐만 아니라, 여러분의 코드를 더 빨리 만들기도 한다. 자주 함께 쓰지도 않는 두 가지!이것들을 통과하기 전에size_ts 여기저기를 돌아다녀 복사용 CPU 오버헤드가 추가되었고, 추가 함수 인수의 경우 레지스터를 더 자주 흘려야 했고, 메모리 낭비(중첩 함수 호출로 인해 종종 여러 개의 복사본이 생성되기 때문에)size_t다른 스택 프레임에 저장됨).당신의 새로운 시스템에서는, 당신은 여전히 메모리를 저장해야 한다.size_t하지만 딱 한 번 뿐이고, 어디에도 복사되지 않는다.이것들은 작은 효율성처럼 보일지 모르지만, 우리가 256KiB의 RAM을 가진 고급 기계들에 대해 이야기하고 있다는 것을 명심해라.

이것은 너를 행복하게 해!그래서 당신은 다음 유닉스 릴리즈에서 작업하는 수염을 기른 남자들과 멋진 묘기를 공유하지만, 그것은 그들을 행복하게 하는 것이 아니라, 그들을 슬프게 만든다.알다시피, 그들은 단지 다음과 같은 많은 새로운 유틸리티 기능들을 추가하는 과정에 있었다.strdup그리고 그들은 당신의 멋진 트릭을 사용하는 사람들이 그들의 새로운 기능을 사용할 수 없다는 것을 깨닫는다. 왜냐하면 그들의 새로운 기능들은 모두 거추장스러운 포인터+사이즈 API를 사용하기 때문이다.그리고 그건 너도 슬프게 만들거야 왜냐면 넌 네가 좋은걸 다시 써야한다는걸 깨달았으니까strdup(char *)시스템 버전을 사용할 수 있는 대신, 당신이 쓰는 모든 프로그램에서 당신 자신의 기능을 한다.

하지만 기다려!이것은 1977년이고, 역호환성은 앞으로 5년 동안 발명되지 않을 것이다!게다가, 아무도 이 불명확한 "유닉스"를 비색깔의 이름으로 사용하지 않는다.K&R 초판은 지금 출판사로 가는 중이지만, 그건 문제가 되지 않는다. 첫 페이지에 "C는 문자열과 같은 복합물체를 직접 다룰 수 있는 작업을 제공하지 않는다...라고 쓰여 있다.더미도 없고..역사의 현 시점에서string.h그리고malloc벤더 확장(!)그래서, Bearded Man #1을 제안한다. 우리가 원하는 대로 바꿀 수 있다; 우리는 단지 당신의 까다로운 할당자를 공식 할당자로 선언하는 것이 어떨까?

며칠 후, Bearded Man #2는 새로운 API를 보고, Hey, wait, this is better better, but it's all words all over all assignment, size를 저장한 채 여전히 할당량당 한 단어씩을 쓰고 있다.그는 이것을 신성모독 다음으로 여긴다.다른 사람들은 모두 그를 미친 사람처럼 쳐다봐, 네가 또 뭘 할 수 있겠어?그날 밤 그는 늦게까지 머물며 크기를 전혀 저장하지 않고 대신 포인터 값에 블랙 매직 비트셰이프를 수행하여 즉석에서 주입하고, 새로운 API를 제자리에 유지하면서 교환한다.새로운 API는 아무도 스위치를 알아차리지 못한다는 것을 의미하지만, 그들은 다음날 아침 컴파일러가 10% 적은 RAM을 사용한다는 것을 알아차린다.

그리고 이제 모두가 행복하다.쓰기 쉽고 빠른 코드를 얻으면, Bearded Man #1은 멋진 간단한 코드를 쓸 수 있다.strdup사람들이 실제로 사용하게 될 것이고, Bearded Man #2는 잠시 동안 자신의 몫을 챙겼다고 확신하며, 다시 쿼터를 가지고 장난치는 것으로 돌아간다.배송해!

아니면 적어도 그렇게 될 수도 있었다.

"왜 그렇지.freeC에서 해방될 바이트의 수를 가져가지 않는가?"

왜냐하면 그럴 필요도 없고, 어차피 말이 되지 않을 것이기 때문이다.

무언가를 할당할 때 시스템에 할당해야 할 바이트 수(명확한 이유로)를 알려면 된다.

그러나 개체를 이미 할당했을 때 이제 반환되는 메모리 영역의 크기가 결정된다.암묵적이야.그것은 기억의 연속적인 블록이다.일부분을 할당해제할 수는 없다(잊어버리자)realloc(), 그것은 어쨌든 그것이 하고 있는 것이 아니다), 당신은 단지 전체 일을 할당해제할 수 있을 뿐이다."X바이트 할당"도 할 수 없으며 -- 받은 메모리 블록을 해제하십시오.malloc()그렇지 않으면 그렇지 않다.

그리고 이제, 만약 당신이 그것을 자유롭게 하고 싶다면, 당신은 메모리 관리자 시스템에 다음과 같이 말할 수 있다."여기에 이 포인터가 있다.free()그것이 가리키는 블록." - 그리고 메모리 매니저는 크기를 암묵적으로 알기 때문에 혹은 크기가 필요치 않을 수도 있기 때문에 그것을 어떻게 하는지 알게 될 것이다.

예를 들어, 가장 일반적인 구현은malloc()사용 가능한 메모리 블록 및 할당된 메모리 블록을 위해 연결된 포인터의 목록을 유지 관리하십시오.만약 당신이 에 포인터를 건네준다면free()는 "free" 목록에 있는 포인터를 검색하고 해당 노드의 연결을 해제한 후 "free" 목록에 첨부할 것이다.지역 규모도 필요 없었다.그것은 잠재적으로 문제의 블록을 재사용을 시도할 때에만 그 정보가 필요할 것이다.

사실 고대 유닉스 커널 메모리 할당자에서는mfree()시간이 걸렸다.size언쟁을 벌이다 malloc()그리고mfree()자유 블록 주소 및 크기에 대한 정보가 포함된 두 개의 어레이(핵심 메모리용 하나, 스왑용 하나)를 유지했다.

Unix V6(프로그램만 사용할 경우)까지 사용자 공간 할당자가 없음sbrk()). Unix V6에서 iolib는 다음과 같은 할당자를 포함했다.alloc(size)그리고 afree()큰 말다툼을 하지 않은 전화각각의 메모리 블록은 그 크기와 다음 블록으로 가는 포인터가 선행되었다.포인터는 프리 리스트를 걸을 때 프리 블록에만 사용되었고, 사용 중인 블록의 블록 메모리로 재사용되었다.

Unix 32V와 Unix V7에서는 이것이 새로운 것으로 대체되었다.malloc()그리고free()구현(wherefree()하지 않았다size언쟁을 벌이다구현은 원형 목록이었고, 각 청크는 다음 청크로 가는 포인터가 포함된 단어와 "바쁜"(할당) 비트 앞에 있었다.그렇게malloc()/free()명확한 사이즈는 추적도 안 했어

C는 C++만큼 "추상적"이 아닐 수도 있지만, 여전히 조립에 대한 추상화일 뿐이다.이를 위해 가장 낮은 수준의 세부사항을 방정식에서 빼낸다.이렇게 하면 대부분의 경우 정렬과 패딩으로 허우적거리지 않아도 되고, 이는 모든 C 프로그램을 휴대할 수 없게 만든다.

요컨대 이것이 추상화를 쓰는 전체 요점이다.

왜 그럴까?freeC에서 해제할 바이트 수를 사용하지 않는 경우

그럴 필요가 없기 때문이다.그 정보는 이미 말로크/무료에 의해 수행되는 내부 관리에서 이용할 수 있다.

다음은 두 가지 고려사항(이 결정에 기여했거나 기여하지 않았을 수 있음)이다.

• 함수가 필요 없는 매개 변수를 수신할 것으로 예상하는 이유는?

  (이러하면 동적 메모리에 의존하는 거의 모든 클라이언트 코드가 복잡해지고 애플리케이션에 완전히 불필요한 중복성을 추가하게 된다.)포인터 할당을 추적하는 것은 이미 어려운 문제다.관련 크기와 함께 메모리 할당을 추적하는 것은 불필요하게 클라이언트 코드의 복잡성을 증가시킬 것이다.

• 무엇이 변했을까?free이런 경우에 기능할 수 있는가?

  void * p = malloc(20);
  free(p, 25); // (1) wrong size provided by client code
  free(NULL, 10); // (2) generic argument mismatch
  

  (메모리 누수로 인해) 무료가 되지 않을까?두 번째 매개 변수를 무시하시겠습니까?종료를 호출하여 응용 프로그램을 중지하시겠습니까?이를 구현하면 애플리케이션에 추가 장애 지점이 추가되며, 필요하지 않은 기능에는 추가 장애 지점이 추가된다(필요하다면 "애플리케이션 레벨에서 솔루션 구현" 아래의 마지막 요점을 참조하십시오).

오히려 나는 애초에 왜 자유가 이런 식으로 만들어졌는지 알고 싶다.

왜냐하면 이것이 그것을 하는 "적절한" 방법이기 때문이다.API는 그것 이상의 작업을 수행하는 데 필요한 인수를 요구해야 한다.

또한 바이트 수를 명시적으로 비워두면 일부 성능 최적화가 가능할 수 있다는 생각이 든다. 예를 들어, 서로 다른 할당 크기에 대해 별도의 풀을 가진 할당자는 입력 인수를 보는 것만으로도 어떤 풀을 해제할지 결정할 수 있고, 전체적으로 공간 오버헤드가 적을 수 있다.

이를 구현하는 적절한 방법은 다음과 같다.

• (시스템 수준에서) malloc의 구현 내에서 - 도서관 시행자가 malloc를 쓰는 것을 막을 수 있는 것은 아무것도 없으며, 수신된 크기에 따라 내부적으로 다양한 전략을 사용한다.

• (애플리케이션 레벨에서) 자신의 API 내에서 malloc를 무료로 포장하고 대신 malloc를 사용(필요할 수 있는 모든 위치)

다섯 가지 이유가 떠오른다.

1. 편리하다.그것은 프로그래머로부터 전체 오버헤드를 제거하고 오류를 추적하기 매우 어려운 클래스를 피한다.

2. 그것은 블록의 일부를 해제할 가능성을 열어준다.하지만 메모리 매니저들은 보통 추적 정보를 갖고 싶어하기 때문에 이것이 무엇을 의미하는지 분명하지 않다.

3. 궤도에서의 가벼움 레이스는 패딩과 정렬에 관한 것이다.메모리 관리의 특성은 실제 할당된 크기가 당신이 요청한 크기와 상당히 다를 수 있다는 것을 의미한다.라는 뜻이다.free장소뿐만 아니라 사이즈도 필요하다malloc할당된 실제 크기를 반환하려면 변경해야 한다.

4. 어쨌든 그 크기로 통과하면 어떤 실질적인 이점이 있다는 것은 확실하지 않다.일반적인 메모리 관리자에는 각 메모리 청크에 대해 4-16바이트의 헤더가 있으며, 여기에는 크기가 포함된다.이 청크 헤더는 할당되거나 할당되지 않은 메모리에 공통적일 수 있으며 인접 청크가 해제되면 함께 축소될 수 있다.호출자가 사용 가능한 메모리를 저장하도록 할 경우 할당된 메모리에 별도의 크기 필드를 포함하지 않음으로써 청크당 4바이트를 확보할 수 있지만, 호출자가 저장해야 하기 때문에 해당 크기 필드는 얻을 수 없는 것일 수 있다.그러나 이제 정보는 예측 가능한 헤더 청크에 위치하기 보다는 메모리에 분산되어 있어, 어쨌든 운용 효율성이 떨어질 가능성이 높다.

5. 비록 그것이 더 효율적이었다고 해도, 어쨌든 당신의 프로그램이 메모리를 확보하는데 많은 시간을 할애할 가능성은 극히 낮기 때문에 그 이득은 아주 작을 것이다.

우연히, 다른 크기의 항목에 대한 별도의 할당자에 대한 당신의 생각은 이 정보 없이도 쉽게 구현된다. (주소를 사용하여 할당이 발생한 위치를 결정할 수 있다.)이것은 일상적으로 C++로 행해진다.

나중에 추가됨

다른 대답은 다소 우스꽝스럽게 std::Allocator를 의 증거로 내세웠다.free이런 식으로 작동할 수 있지만, 사실, 그것은 왜 그런지를 보여주는 좋은 본보기가 된다.free이런 식으로는 안 되지무엇에는 두 가지 주요한 차이점이 있다.malloc/free하는 것, 그리고 std::destator가 하는 것.일단.malloc그리고free사용자 대면(일반 프로그래머와 함께 작업하도록 설계됨)인 반면std::allocator표준 라이브러리에 전문적인 메모리 할당을 제공하도록 설계되었다.이것은 내 요점 중 첫 번째 요점이 중요하지 않거나 중요하지 않을 때를 보여주는 좋은 예를 제공한다.도서관인 만큼 어차피 추적크기의 복잡성을 다루는 어려움도 사용자에게는 감춰져 있다.

둘째, std::allocator는 항상 동일한 크기의 항목과 함께 작동한다. 이는 원래 전달된 요소 수를 사용하여 얼마의 무료인지 결정하는 것이 가능하다는 것을 의미한다.이것이 왜 다른가free그 자체가 예증이다.인std::allocator할당되는 항목은 항상 동일하고, 알려져 있고, 크기가 동일하며, 항상 같은 종류의 항목이므로 항상 동일한 종류의 정렬 요건을 갖는다.즉, 이러한 항목의 배열을 처음부터 간단히 할당하고 필요에 따라 할당자가 처리하도록 전문화할 수 있다.넌 이 일을 할 수 없어free반품하기에 가장 좋은 크기가 요청된 크기라고 보장할 방법이 없기 때문에, 대신, 발신자가 요구하는 것보다 더 큰 블록을 반품하는 것이 훨씬 더 효율적이기 때문에 사용자나 관리자 중 한 사람이 실제로 부여한 정확한 크기를 추적해야 한다.이러한 종류의 이행 세부사항을 사용자에게 전달하는 것은 발신자에게 아무런 이득도 주지 않는 불필요한 두통이다.

-* 아직 이 점을 이해하기 어려운 사람이 있다면, 이를 고려하십시오. 일반적인 메모리 할당자는 소량의 추적 정보를 메모리 블록 시작 부분에 추가한 다음 여기서 포인터 오프셋을 반환한다.예를 들어 여기에 저장된 정보는 일반적으로 다음 자유 블록에 대한 포인터를 포함한다.헤더 길이가 4바이트에 불과하고(실제로 대부분의 실제 도서관보다 작다), 크기를 포함하지 않는다고 가정해 봅시다. 그리고 나서, 사용자가 16바이트 블록을 요구할 때 20바이트의 자유 블록이 있다고 상상해 봅시다. 순진한 시스템은 16바이트 블록을 반환하지만, 4바이트 조각은 결코, 매번 시간을 낭비하는데 사용될 수 없을 정도로 남겨놓습니다.malloc부름을 받다만약 관리자가 20바이트 블록을 단순히 반환한다면, 그것은 이 지저분한 조각들이 쌓이는 것을 막아내고 사용 가능한 메모리를 더 깨끗하게 할당할 수 있다.그러나 시스템이 크기 자체를 추적하지 않고 이를 올바르게 실행하려면 사용자가 모든 단일 할당에 대해 무료로 다시 전달하기 위해 실제로 할당된 메모리 양을 추적해야 한다.동일한 인수가 원하는 경계와 일치하지 않는 유형/배열에 대한 패딩에도 적용된다.따라서 기껏해야 요구 사항이다.free메모리 할당자가 실제 할당된 크기와 일치하도록 전달된 크기에 의존할 수 없기 때문에 크기를 선택하는 것은 완전히 무용지물이다. 또는 (b) 사용자가 분별 있는 메모리 관리자가 쉽게 처리할 수 있는 실제 크기를 추적하는 작업을 무차별적으로 요구한다.

나는 단지 답안으로서 이것을 게시하는 것이 당신이 바라는 것이기 때문이 아니라, 나는 그것이 그럴듯하게 맞는 유일한 것이라고 믿기 때문이다.

그것은 아마도 원래 편리하다고 여겨졌고, 그 후에 개선될 수 없었다.
그럴 만한 납득할 만한 이유는 없을 것 같다.(그러나 이것이 틀렸다는 것을 보여 준다면 기꺼이 삭제하겠다.)

가능하다면 이득이 있을 것이다: 작은 메모리 덩어리를 반복적으로 할당하고 분리하는 것이 아니라, 미리 알고 있던 큰 메모리 한 조각을 할당하고, 한 번에 조금씩 자유롭게 할 수 있다.현재 이와 같은 업무는 불가능하다.

---

사이즈를 넘기는 것이 너무 우스꽝스럽다고 생각하는 여러분 중 많은 (많은¹) 사람들에게:

방법에 대한 C++의 설계 결정을 참고해도 될까?

void deallocate(pointer p, size_type n);

전부 T이 호출 전에 옆을 가리키는 영역의 물체가 파괴되어야 한다.
n 전달된 값과 일치해야 한다.allocate이 기억을 얻기 위해

나는 당신이 이 디자인 결정을 분석하는 데 다소 "흥미로운" 시간을 가질 것이라고 생각한다.

---

에 관하여operator delete, 2013 N3778 제안("C++ Size Deallocation")도 이를 수정하기 위한 것으로 밝혀졌다.

---

원문 아래에 있는 코멘트를 보면 '크기를 요구하는 것은 통화에 전혀 쓸모가 없다'는 식의 섣부른 주장을 얼마나 많이 했는지를 알 수 ¹있다.size parameter.

malloc and free go hand in hand, with each "malloc" being matched by one "free". Thus it makes total sense that the "free" matching a previous "malloc" should simply free up the amount of memory allocated by that malloc - this is the majority use case that would make sense in 99% of cases. Imagine all the memory errors if all uses of malloc/free by all programmers around the world ever, would need the programmer to keep track of the amount allocated in malloc, and then remember to free the same. The scenario you talk about should really be using multiple mallocs/frees in some kind of memory management implementation.

I would suggest that it is because it is very convenient not to have to manually track size information in this way (in some cases) and also less prone to programmer error.

Additionally, realloc would need this bookkeeping information, which I expect contains more than just the allocation size. i.e. it allows the mechanism by which it works to be implementation defined.

You could write your own allocator that worked somewhat in the way you suggest though and it is often done in c++ for pool allocators in a kind of similar way for specific cases (with potentially massive performance gains) though this is generally implemented in terms of operator new for allocating pool blocks.

I don't see how an allocator would work that does not track the size of its allocations. If it didn't do this, how would it know which memory is available to satisfy a future malloc request? It has to at least store some sort of data structure containing addresses and lengths, to indicate where the available memory blocks are. (And of course, storing a list of free spaces is equivalent to storing a list of allocated spaces).

Well, the only thing you need is a pointer that you'll use to free up the memory you previously allocated. The amount of bytes is something managed by the operating system so you don't have to worry about it. It wouldn't be necessary to get the number of bytes allocated returned by free(). I suggest you a manual way to count the number of bytes/positions allocated by a running program:

If you work in Linux and you want to know the amount of bytes/positions malloc has allocated, you can make a simple program that uses malloc once or n times and prints out the pointers you get. In addition, you must make the program sleep for a few seconds (enough for you to do the following). After that, run that program, look for its PID, write cd /proc/process_PID and just type "cat maps". The output will show you, in one specific line, both the beginning and the final memory addresses of the heap memory region (the one in which you are allocating memory dinamically).If you print out the pointers to these memory regions being allocated, you can guess how much memory you have allocated.

Hope it helps!

Why should it? malloc() and free() are intentionally very simple memory management primitives, and higher-level memory management in C is largely up to the developer. T

Moreover realloc() does that already - if you reduce the allocation in realloc() is it will not move the data, and the pointer returned will be the the same as the original.

It is generally true of the entire standard library that it is composed of simple primitives from which you can build more complex functions to suit your application needs. So the answer to any question of the form "why does the standard library not do X" is because it cannot do everything a programmer might think of (that's what programmers are for), so it chooses to do very little - build your own or use third-party libraries. If you want a more extensive standard library - including more flexible memory management, then C++ may be the answer.

You tagged the question C++ as well as C, and if C++ is what you are using, then you should hardly be using malloc/free in any case - apart from new/delete, STL container classes manage memory automatically, and in a manner likely to be specifically appropriate to the nature of the various containers.

ReferenceURL : https://stackoverflow.com/questions/24203940/why-does-free-in-c-not-take-the-number-of-bytes-to-be-freed