STL 할당자는 애초에 다양한 플랫폼에서의 메모리 관리 방식 차이로 인한 비호환성을 제거하려는 추상층으로 등장했지만, 성능상의 문제 때문에 제대로 사용되는 경우가 없었다. STL 할당자는 대단히 매력적인 아이디어였지만, 이와 같은 고전적인 이유 때문에 실제로 컨테이너를 구현하는데 사용된 적은 별로 없었다. 더구나, 현 시점에서는 다음과 같은 새로운 요소들 때문에 STL 할당자를 직접 작성하려는 것은 회의적으로 생각된다.
첫째, STL 할당자는 STL 자체에서의 효율성 저하 문제 때문에, 모든 STL 구현이 할당자를 사용하는 것은 아니다. 즉, 애써 STL 할당자를 만들어도, 모든 플랫폼에서 동작한다거나, 기대한만큼 성능을 내주리라 보장할 수 없다.
둘째, C++0x에서의 rvalue reference 도입으로 인해 STL 할당자가 활약할 영역이 더욱 줄어들었다. STL 할당자를 직접 작성하는 것으로 얻는 이득은 생각보다 크지 않을 것이다.
셋째, 그럼에도 기본 STL 할당자를 교체하고 싶다면, 먼저 부스트 풀 라이브러리(boost pool library)를 고려하라.
STL 할당자의 기본적인 사항에 대해 알고 싶다면 조슈티스의 저서(The C++ Standard Library)를 참고하거나, Meyers의 Effective STL을 참고하면 좋을 것이다. STL 할당자가 필요로 하는 사항은 생각보다 그리 많지 않기 때문에, 구현 경험을 위해 직접 STL 할당자를 만들어 보는 것은 나쁘지 않지만, 다른 이득은 별로 없다.
첫째, STL 할당자는 STL 자체에서의 효율성 저하 문제 때문에, 모든 STL 구현이 할당자를 사용하는 것은 아니다. 즉, 애써 STL 할당자를 만들어도, 모든 플랫폼에서 동작한다거나, 기대한만큼 성능을 내주리라 보장할 수 없다.
둘째, C++0x에서의 rvalue reference 도입으로 인해 STL 할당자가 활약할 영역이 더욱 줄어들었다. STL 할당자를 직접 작성하는 것으로 얻는 이득은 생각보다 크지 않을 것이다.
셋째, 그럼에도 기본 STL 할당자를 교체하고 싶다면, 먼저 부스트 풀 라이브러리(boost pool library)를 고려하라.
STL 할당자의 기본적인 사항에 대해 알고 싶다면 조슈티스의 저서(The C++ Standard Library)를 참고하거나, Meyers의 Effective STL을 참고하면 좋을 것이다. STL 할당자가 필요로 하는 사항은 생각보다 그리 많지 않기 때문에, 구현 경험을 위해 직접 STL 할당자를 만들어 보는 것은 나쁘지 않지만, 다른 이득은 별로 없다.
