만약 컨테이너에 알고리즘을 적용할때 일반적인 알고리즘을 적용한다면 컨테이너의 특성을 고려하지 않고 동작하게 된다. 하지만 멤버함수의 경우 각 컨테이너의 구현 방식에 따른 동작을 수행하기 때문에 좀더 효율적인 수행을 할수 이다.
예를 들어 연관 컨테이너인 set에 아이템이 100만개 들어있고 find를 실행한다면 일반 알고리즘인 find는 순처적으로 검색해 나가는 반면 맴버함수인 find는 set의 기본을 이루고 있는 트리구조에 기반한 검색을 할것이다. 성능은 전자는 평균 50만. 최악의 경우 100만번의 비교가 필요하지만 후자는 최악이라 해도 40번 안쪽으로 종료가 가능하다.
또한 연관 컨테이너에서 비교에 근간을 이루고 있는 동등성과 상등성에 관한것도 일반 알고리즘을 적용시 동일하게 적용시키지 못한다.(EffectiveSTL19 참고)
게다가 map, multimap 같은 경우 일반적으로 키값만을 비교하기 원하겠지만 일반 알고리즘은 pair를 이루고 있는 아이탬 전체를 비교하여 결과값이 달라질수 있다.(물론 그걸 원할수도 있기는 하지만)
게다가 map, multimap 같은 경우 일반적으로 키값만을 비교하기 원하겠지만 일반 알고리즘은 pair를 이루고 있는 아이탬 전체를 비교하여 결과값이 달라질수 있다.(물론 그걸 원할수도 있기는 하지만)
순차 컨테이너의 하나인 list의 경우 일반 알고리즘은 아이탬의 동작에 있어서 노드 단위의 복사를 수행하는 경우가 많지만 list 맴버함수는 포인터의 조작을 통해서 동작한다. 즉 효율성에서 차이가 나게 된다. 또한 동작 자체가 약간 다른 경우도 존재한다.
일반 알고리즘의 remove, remove_if는 실제로 삭제를 실행하지 않고 위치를 바꿀 뿐이며(EffectiveSTL32 참고) 실제 삭제를 위해서는 erase를 호출해야 하지만 list의 remove, remove_if, unique등의 함수는 자신이 실제로 객체를 삭제한다.
일반 알고리즘의 remove, remove_if는 실제로 삭제를 실행하지 않고 위치를 바꿀 뿐이며(EffectiveSTL32 참고) 실제 삭제를 위해서는 erase를 호출해야 하지만 list의 remove, remove_if, unique등의 함수는 자신이 실제로 객체를 삭제한다.
위와 같은 사실을 생각해 볼때 특정 알고리즘을 적용할 경우 컨테이너에서 제공하는 알고리즘이 존재한다면 그것을 사용하는 것이 바람직하다.