이러한 주장을 실제 측정 가능한 현상으로 나누겠습니다.

• 더 가벼움 : Qt 컨테이너는 STL 컨테이너보다 적은 메모리를 사용합니다
• 더 안전한 : Qt 컨테이너는 부적절하게 사용될 기회가 적습니다.
• 더 쉬워 진 : Qt 컨테이너는 지적 부담이 적습니다.

더 쉬움

이 문맥에서 주장하는 것은 자바 스타일 반복이 STL 스타일보다 어떻게 든 “더 쉽다”는 것입니다. 따라서이 추가 인터페이스로 인해 Qt가 더 사용하기 쉽습니다.

자바 스타일 :

QListIterator<QString> i(list);
while (i.hasNext())
    qDebug() << i.next();

STL 스타일 :

QList<QString>::iterator i;
for (i = list.begin(); i != list.end(); ++i)
    qDebug << *i;

Java 반복자 스타일은 조금 작고 깨끗하다는 이점이 있습니다. 문제는 더 이상 STL 스타일이 아닙니다.

C ++ 11 STL 스타일

for( auto i = list.begin(); i != list.end(); ++i)
    qDebug << *i;

또는

C ++ 11 foreach 스타일

for (QString i : list)
    qDebug << i;

C ++ 11을 지원하지 않는 한 다른 것을 사용할 이유가 전혀없는 매우 간단합니다.

그러나 내가 가장 좋아하는 것은 다음과 같습니다.

BOOST_FOREACH(QString i, list)
{
    qDebug << i;
}

보시다시피,이 인터페이스는 이미 매끄럽고 간결하며 현대적인 인터페이스 외에 추가 인터페이스를 제외하고는 아무것도 얻지 못합니다. 이미 안정적이고 사용 가능한 인터페이스 위에 불필요한 추상화 수준을 추가 하시겠습니까? “보다 쉬운”아이디어는 아닙니다.

또한 Qt foreach 및 Java 인터페이스는 오버 헤드를 추가합니다. 그것들은 구조를 복사하고 불필요한 간접적 인 수준을 제공합니다. 이처럼 보이지 않을 수도 있지만 왜 그렇게 간단하지 않은 인터페이스를 제공하기 위해 오버 헤드 계층을 추가합니까? java에는 연산자 오버로딩이 없기 때문에 Java에는이 인터페이스가 있습니다. C ++는 않습니다.

더 안전한

Qt가 제공하는 정당성은 암시 적 공유 문제이며 암시 적이거나 문제가 아닙니다. 그러나 공유는 포함됩니다.

QVector<int> a, b;
a.resize(100000); // make a big vector filled with 0.

QVector<int>::iterator i = a.begin();
// WRONG way of using the iterator i:
b = a;
/*
Now we should be careful with iterator i since it will point to shared data
If we do *i = 4 then we would change the shared instance (both vectors)
The behavior differs from STL containers. Avoid doing such things in Qt.
*/

첫째, 이것은 암시 적이 지 않습니다. 한 벡터를 다른 벡터에 명시 적으로 할당하고 있습니다. STL 반복자 사양은 반복자가 컨테이너에 속한다는 것을 명확하게 나타내므로 b와 a 사이에 공유 컨테이너를 명확하게 소개했습니다. 둘째, 이것은 문제가되지 않습니다. 반복자 스펙의 모든 규칙을 따르는 한 절대로 아무 문제가 없습니다. 문제가있는 유일한 시간은 다음과 같습니다.

b.clear(); // Now the iterator i is completely invalid.

Qt는이 시나리오에서 문제가 발생하는 것과 같은 것을 의미하는 것처럼 이것을 지정합니다. 그렇지 않습니다. 이터레이터는 무효화되고 여러 분리 된 영역에서 액세스 할 수있는 것과 마찬가지로 이것이 작동하는 방식입니다. 실제로 이것은 Qt의 Java 스타일 반복자와 함께 쉽게 발생합니다. 암시 적 공유에 크게 의존하기 때문입니다. 이는 여기 및 기타 여러 영역 에서 설명한 반 패턴 입니다. 이 “최적화”가 멀티 스레딩으로 점점 더 이동하는 프레임 워크에서 사용되는 것은 특히 이상해 보이지만, 그것은 당신을위한 마케팅입니다.

거룻배

이것은 조금 까다 롭습니다. 쓰기시 복사 및 암시 적 공유 및 성장 전략을 사용하면 컨테이너가 특정 시간에 사용할 메모리 양을 실제로 보장하기가 매우 어렵습니다. 이것은 강력한 알고리즘 보장을 제공하는 STL과 다릅니다.

우리 는 벡터의 최소 낭비 공간이 벡터 길이의 제곱근이라는 것을 알고 있지만 Qt에서는 이것을 구현할 방법이없는 것 같습니다. 그들이 지원하는 다양한 “최적화”는이 중요한 공간 절약 기능을 배제 할 것입니다. STL은이 기능을 필요로하지 않으며 (이는 대부분 두 배의 성장을 사용하므로 더 낭비입니다) 필요한 경우 최소한이 기능을 구현할 수 있다는 점에 유의해야합니다.

XOr 연결을 사용하여 사용 된 공간을 크게 줄일 수있는 이중 연결 목록도 마찬가지입니다. 다시 말하지만, 이것은 성장과 COW에 대한 요구로 인해 Qt에서는 불가능합니다.

COW는 실제로 더 가벼운 것을 만들 수 있지만 boost 에서 지원하는 것과 같은 Intrusive Containers도 가능 하며 Qt는 이전 버전에서 자주 사용했지만 더 이상 사용하기 어렵고 안전하지 않으며 부담을 가하기 때문에 더 이상 사용되지 않습니다. 프로그래머에. COW는 훨씬 덜 관입적인 솔루션이지만 위에 제시된 이유로 매력이 없습니다.

메모리 비용이 같거나 Qt의 컨테이너보다 적은 STL 컨테이너를 사용할 수없는 이유는 없으며, 주어진 시간에 얼마나 많은 메모리를 낭비하는지 실제로 알 수 있다는 이점이 있습니다. 불행히도, 원시 메모리 사용량에서 두 ​​가지를 비교하는 것은 불가능합니다. 그러한 벤치 마크는 사용 사례마다 크게 다른 결과를 보여 주므로 STL이 수정하도록 설계된 정확한 종류의 문제입니다.

결론적으로

복사 비용을 부과하지 않고 가능한 경우 Qt 컨테이너를 사용하지 말고 가능하면 랩퍼 또는 새 구문을 통해 STL 유형 반복을 사용하십시오.

답변