- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
// check that all selected vertices are one 3d vertex.
bool UsedIndex = 0;
bool IndexIsRegistered = false;
for (int t = 0; t < Indices.count(); t++)
{
zUVVertex Vertex = OldVerts->at(t);
if (!IndexIsRegistered)
{
IndexIsRegistered = true;
UsedIndex = Vertex.BaseVertexIndex;
}
else if (UsedIndex != OldVerts->at(t).BaseVertexIndex)
{
// quit on fail
return;
}
}
NewList = new QList<zUVVertex>();
zUVVertex NewVertex;
bool VertexIsInitialized = false;
bool CapIsHoled = false;
for (quint32 t = 0; t < OldVerts->count(); t++)
{
bool Taked = false;
for (quint32 j = 0; j < Indices.count(); j++)
{
if (OldVerts->at(t).index == Indices.at(j))
{
if (!VertexIsInitialized)
{
VertexIsInitialized = true;
NewVertex = OldVerts->at(t);
}
Taked = true;
NewVertex.IndicesBeforeWeld << t;
break;
}
}
if (!Taked)
{
(*NewList) << OldVerts->at(t);
}
else
{
zUVVertex Stub;
if (!CapIsHoled)
{
Stub = NewVertex;
}
else
{
Stub.Index = 0x7FFFFFFF;
}
(*NewList) << Stub;
}
}
(*NewList) << NewVertex;
Taked = false;
QList<zUVFace> *TempFacesList = new QList<zUVFace>();
for (int t = 0; t < Faces->count(); t++)
{
zUVFace Face = Faces->at(t);
zUVFace NewFace;
for (int j = 0; j < Face.VertsIndices; j++)
{
quint32 Index0 = Face.VertsIndices.at(j);
zUVVertex TestVertex = NewList->at(Index0);
if (TestVertex.Index == 0x7FFFFFFF)
{
// need to replace
NewFace = Faces->at(t);
NewFace.VertsIndices.operator [](j) = NewList->count() - 1;
Taked = true;
}
}
if (Taked)
{
(*TempFacesList) << NewFace;
}
}
Follow us!
NewFace.VertsIndices.operator [](j) = NewList->count() - 1;
И вообще я не понял, какой извращенец придумал контейнер QList в Qt.
Другое дело QLinkedList. Там тоже куча, но зато у него есть свои сильные стороны над вектором типа вставки в середину.
Может я конечно понял что-то не так, потому что только вчера решил глянуть в документации Qt, что из себя представляет QList и на что больше похож - список или вектор. Но там примерно про эти затраты памяти писали, а в оправдание QList вместо QVector написали какой-то тухлый аргумент типа того, что зато общий код работы с памятью не шаблонный, и QList меньше весит. Хотя в QVector для POD'ов это тоже ничто не мешает сделать.
Пока писал, пришло в голову, что QList наверное можно использовать для полиморфных объектов.
Задал бы этот вопрос полгода назад, и я бы честно ответил: чаще, чем контейнерами.
Там была хитрая система — у каждого потока своя куча, чтобы, если что, её можно просто освободить одним куском. Все пользовались аллокаторами. Глобальный new был перегружен вызывать abort. Не помню, что с malloc сделали.
И, кстати, я не выступаю за аллокаторы, я ответил на сообщение CHayT'а. Мне не нравится система аллокаторов STL тем, что контейнеры с разными аллокаторами имеют разный тип. Поэтому и в своих велосипедах ничего подобного не делал. Но продолжать закладываться на какой-то конкретный вариант типа new\malloc тоже не хочется. Я ещё подумаю над этим в будущем и может быть придумаю какой-то другой вариант. А может быть получится так, что аллокаторы вообще будут не нужны, например я разделю динамический массив на две самодостаточные части, разные варианты которых будут легко комбинироваться друг с другом. Например выделенная память подаётся извне, а вся логика работы с элементами или её большая часть реализуется отдельным классом.
Я в последнее время меняю подход и делаю как можно всего открытым и модульным, избавляясь от лишней инкапсуляции. Судя по всему, так можно очень многие вещи разложить на составные части и использовать повторно код. Но пока только начало, через месяц посмотрю, что получится из этого...
Советую посмотреть на polymorphic allocators в С++17. И алиасы типа pmr::vector...
Ну в общем, я над этим буду думать позже, когда придёт время и я реализую все другие свои задумки. К тому времени, глядишь, само всё придумается, как очевидное следствие того, что уже будет сделано. Вероятно, это будет что-то, основывающееся на диапазонах (range) и алгоритмах над ними, которые я уже сделал по образу и подобию диапазонов из стандартной библиотеки D. Примеры использования диапазонов были в моём предыдущем "говнокоде".
Ты не поверишь... https://github.com/ericniebler/range-v3
В D это сделано через UFCS, а у меня через наследование всех range от базового класса с нужными методами.
Ну и ещё у меня в своём стиле всё равно всё, который отличается от STL. И это будет частью моей библиотеки, где всё родное и хорошо интегрируется друг с другом.
нет, он внутри или конструирует копии объектов типа T, или аллоцирует куски памяти под memcpy, в зависимости от хитрых qt-шных характеристик типа
аллокаторы - хуй
конструктор из двух итераторов - хуй
stl-овский .empty() - хуй скрылся под сраным псевдонимом .isEmpty()
reverse iterator - хуй только с qt5
тьфу!
Итераторы - Qt так сделан, что там итераторы по факту нужны только для range-based for/foreach и итерации по ассоциативным контейнерам. Работая с QList/QVector можно вообще забыть про begin/end.
По поводу аллокаторов - я рассматриваю с точки зрения multi-purpose контейнера. Для каких-то слишком специфичных задач (к которым работа с кастомными аллокаторами относится всегда) не подойдет, да.
когда последний раз пользовался (вчера) - .empty() не было
> Qt так сделан, что там итераторы по факту нужны только для range-based for/foreach
qt, может, и не нужны, а мне, например, нужно было сконструировать qlist из двух и итераторов на qvector, один из которых не указывал на начало или конец диапазона
http://doc.qt.io/qt-4.8/qlist.html
в 4.8 есть. Вот в QString/QByteArray нет
QList::fromVector(v.mid(...));
У Qt и STL маленько разный подход к API