다른 사람들은 이미 다른 문제를 해결 했으므로 한 가지 사항 만 살펴 보겠습니다. 개체를 수동으로 삭제 하시겠습니까?
대답은 '예'입니다. @DavidSchwartz가 한 가지 예를 제공했지만 상당히 드문 경우입니다. 많은 C ++ 프로그래머가 항상 사용하는 후드 아래에있는 예제를 제공 할 것입니다. std::vector(그리고 std::deque많이 사용되지는 않지만).
대부분의 사람들이 알다시피, std::vector은 (는) 현재 할당이 보유 할 수있는 것보다 더 많은 항목을 추가 할 때 더 큰 메모리 블록을 할당합니다. 그러나 이렇게하면 현재 벡터에있는 것보다 더 많은 객체 를 보유 할 수있는 메모리 블록 이 있습니다.
이를 관리하기 위해 내부적으로하는 vector일은 객체 를 통해 원시 메모리를 할당 하는 Allocator것입니다 (달리 지정하지 않는 한를 사용함을 의미 함 ::operator new). 그런 다음 (예를 들어) push_back를 사용 하여에 항목을 추가하면 vector내부적으로 벡터는 a placement new를 사용하여 메모리 공간의 (이전) 사용되지 않은 부분에 항목을 만듭니다.
이제 erase벡터의 항목이 있으면 어떻게됩니까 ? 그냥 사용할 수는 없습니다 delete. 전체 메모리 블록을 해제합니다. 다른 개체를 파괴하지 않거나 제어하는 메모리 블록을 해제하지 않고 해당 메모리에있는 한 개체를 파괴해야합니다 (예 erase: 벡터에서 push_back5 개 항목 을 즉시 5 개 더 추가 하면 벡터가 재 할당 되지 않음을 보장 합니다. 당신이 그렇게 할 때 기억.
이를 위해 벡터는를 사용 하지 않고 소멸자를 명시 적으로 호출하여 메모리의 객체를 직접 파괴합니다 delete.
만약 다른 사람이 대략 같은 방식 vector(또는 std::deque실제 방식 과 같이 그 변형)을 사용하여 연속 저장소를 사용하여 컨테이너를 작성 한다면 거의 확실하게 동일한 기술을 사용하고 싶을 것입니다.
예를 들어 원형 링 버퍼에 대한 코드를 작성하는 방법을 고려해 보겠습니다.
#ifndef CBUFFER_H_INC
#define CBUFFER_H_INC
template <class T>
class circular_buffer {
T *data;
unsigned read_pos;
unsigned write_pos;
unsigned in_use;
const unsigned capacity;
public:
circular_buffer(unsigned size) :
data((T *)operator new(size * sizeof(T))),
read_pos(0),
write_pos(0),
in_use(0),
capacity(size)
{}
void push(T const &t) {
// ensure there's room in buffer:
if (in_use == capacity)
pop();
// construct copy of object in-place into buffer
new(&data[write_pos++]) T(t);
// keep pointer in bounds.
write_pos %= capacity;
++in_use;
}
// return oldest object in queue:
T front() {
return data[read_pos];
}
// remove oldest object from queue:
void pop() {
// destroy the object:
data[read_pos++].~T();
// keep pointer in bounds.
read_pos %= capacity;
--in_use;
}
~circular_buffer() {
// first destroy any content
while (in_use != 0)
pop();
// then release the buffer.
operator delete(data);
}
};
#endif
표준 컨테이너와 달리 이는 operator new및 operator delete직접 사용 합니다. 실제 사용을 위해서는 할당 자 클래스를 사용하고 싶겠지 만, 현재로서는 기여하는 것보다주의를 분산시키는 것이 더 많을 것입니다 (IMO, 어쨌든).