(STL LIST SORT) Сортировка по некольким критериям

Здравствуйте!
Столкнулся с такой проблемой при сортировке списка.

Есть структура:

А также контейнер list, элемент которого задан соответсвующей структурой.
Требуется отсортировать данный контейнер наполненый некой информацией по
1) Имени сцены "SceneAlias"
2) Аттрибутам текстуры TexMipMap;TexGray;TexJpeg;
3) По размерам текстуры TexWidth; TexHeight;

ЭТО НЕ ОЗНАЧЕТ СДЕЛАТЬ 3 РАЗНЫХ СОРТИРОВКИ!!! ЭТО ЗНАЧИТ ЧТОБЫ СВЕРХУ ВНИХ ОБЪЕКТЫ БЫЛИ ОТСОРТИРОВАННЫ ПО ДАННЫМ КРИТЕРИЯМ!

Т.е.
1) Scene1 JPEG MIPMAP GRAY 1000x900
2) Scene1 JPEG MIPMAP GRAY 800x900
3) Scene1 JPEG MIPMAP 1000x900
4) Scene1 JPEG MIPMAP 700x700
5) Scene1 JPEG GRAY 1500x1500
6) Scene1 JPEG GRAY 700x700
7) Scene1 JPEG 2000x700
8) Scene1 JPEG 1000x700
8) Scene1 100x100
9) Scene1 100x50
10) Scene2 .......

Т.е. номера пунктов 3-ех аттрибутов являются как бы приоритетами (важностью) 1) 2) 3)


НО ПРОБЛЕМА НЕ В ТОМ КАК ОТСОРТИРОВАТЬ!!!!!!

Проблема заключается в том что функция PREDICATE для списка LIST отказывается сортировать корректно его элементы!

Вот один из испробованных мною вариантов PREDICATE функции (до этого я пытался делать эту функцию разными способами в том числе перегрузкой скобок () и перегрузкой знака ">" )

Пояснения!
1) Переменные bool sortmem_apartscenes и bool sortmem_apartjpeg являются глобальными. Увы от них избавится не вышло а добавлять еще 3 варианта сортировки было бы некрасиво. Перед сортировкой эти переменные устанавливаются в нужное значение.

2) Переменные TexJpeg TexMipMap и TexGray пробывал сравнивать знаком > но все равно безрезультатно.

3) bool result - это якобы варинт написания функции как в Дельфи. Просто во время отладки я заметил очень странную весчь. Оказывается в PREDICATE функции при к примеру "return true" не происходит выход из функции а продолжает обрабатывать всею последующие команды Я не понимать что это за баг?

4) Если проверять по отдельности то разделив на 3-и блока всю функцию сортировки

- мы получим что 1-ый блок с сортировкой по алфавиту, не выполняется (хотя список элементов string успешно сортирует имена файлов но только в другом участке в другом контейнере в моей работе)

- 2 блок кода выполняется только отдельно к примеру только сортировка по JPEG аттрибуту.

- 3 блок сортироки по размерам блестяще выполняется.

ПРИТОМ! Если по всем 3 блокам одновременно я пытаюсь сортировать данный список то у меня получается что
1) По именам сцен сортирует но имена сцен и без того изначально были уже в отсортированном виде еще при добавлении в список элементов (отсортировать в обратном порядке при изменении знака > на знак < ничего не меняется но если блок убрать то порядок теряется)
2) Также сортирует по именьшению сверху вниз размеров текстур.
Аттрибуты же текстур остаются в произвольном порядке....


Как это можно вылечить. Может кто уже сталкивался со сложными сортировками?

Добавлено через 3 часа 58 минут 39 секунд
Вопрос был решен на rsdn.ru
Вот Цитата:

От: Jenkas Дата: 18.07.09 22:11 Здравствуйте, tatsu, Вы писали: T>ЭТО НЕ ОЗНАЧЕТ СДЕЛАТЬ 3 РАЗНЫХ СОРТИРОВКИ!!! ЭТО ЗНАЧИТ ЧТОБЫ СВЕРХУ ВНИХ ОБЪЕКТЫ БЫЛИ ОТСОРТИРОВАННЫ ПО ДАННЫМ КРИТЕРИЯМ! T>Т.е. T>1) Scene1 JPEG MIPMAP GRAY 1000x900 T>2) Scene1 JPEG MIPMAP GRAY 800x900 T>3) Scene1 JPEG MIPMAP 1000x900 T>4) Scene1 JPEG MIPMAP 700x700 T>5) Scene1 JPEG GRAY 1500x1500 T>6) Scene1 JPEG GRAY 700x700 T>7) Scene1 JPEG 2000x700 T>8) Scene1 JPEG 1000x700 T>8 ) Scene1 100x100 T>9 ) Scene1 100x50 T>10) Scene2 ....... T>Т.е. номера пунктов 3-ех аттрибутов являются как бы приоритетами (важностью) 1) 2) 3) В вашей функции есть ошибка. Продолжать проверку по след. приоритетному атрибуту стоит только если предидущик атрибуты были равны. Попробуйте так: bool PackPred(PackObject &obj1, PackObject &obj2) { if (sortmem_apartscenes) { string str1 = obj1.SceneAlias; string str2 = obj2.SceneAlias; if (str1 > str2) { return true; //немедленый выход, если больше } if (str1 < str2) { return false; //немедленый выход, если меньше } } //если равно то делаем проверку по след. параметру if (sortmem_apartjpeg) { // Объекты одной сцены сортируем по параметрам текстуры if ((obj1.TexJpeg) && (!obj2.TexJpeg)) { return true; //немедленый выход, если больше } if ((!obj1.TexJpeg) && (obj2.TexJpeg)) { return false; //немедленый выход, если меньше } } //если равно то делаем проверку по след. параметру if ((obj1.TexMipMap) && (!obj2.TexMipMap)) { return true; //немедленый выход, если больше } if ((!obj1.TexMipMap) && (obj2.TexMipMap)) { return false; //немедленый выход, если меньше } //если равно то делаем проверку по след. параметру if ((obj1.TexGray) && (!obj2.TexGray)) { return true; //немедленый выход, если больше } if ((!obj1.TexGray) && (obj2.TexGray)) { return false; //немедленый выход, если меньше } //если равно то делаем проверку по след. параметру // Возвращаем результат сравнения размеров int width1 = obj1.TexWidth; int height1 = obj1.TexHeight; int width2 = obj2.TexWidth; int height2 = obj2.TexHeight; // Хотябы один размер был больше if ( ((width1 > width2) && (width1 > height2)) || ((height1 > width2) && (height1 > height2)) ) return true; //немедленый выход, если больше //и т.д. return false; };

0

ну, он предложил сделать многоэтажный if
который будет пропорционален этой конструкции

короче говоря, из-за этого if'а ты её не сможешь расширять, если вдруг тебе понадобится не пять полей а пятьсот - можешь забыть

я писал нечто подобное когда нужно было проводить такие сортировки, у меня была функция сортировки, но она знала откуда и докуда сортировать, а ей передавался указатель на свапер, который знал какие поля менять местами
и функция подсчёта полей, которая принимала указатель на функцию для определения одинаковости полей, которая могла посчитать эти границы

в итоге там расширение свелось к тому, чтобы продлить цикл сортирования, написать функцию сравнения для определения одинаковости, и функцию перестановки для определённого поля
так можно было добавить любое поле

ну и переделать, когда бывает нужно переделать, тоже было легко и просто, потому что всё это было собрано по частям, отдельным и самостоятельным

Добавлено через 23 минуты 24 секунды
а, ну ясно, это я попутал насчёт многоэтажки
он юзает короче передачу двух объектов в функцию и сравнения каждого поля, так что насчёт расширяемости у него всё нормально

Добавлено через 2 часа 41 минуту 40 секунд
короче, суть в том чтобы сортировать колонки постепенно и отсортированное оставлять, а неотсортированное сортировать
и функция сортировки свой фокус перемещает за счёт маленьких функций, которые и определяют одна - где начинать сортировку и докуда проводить, а вторая - какие менять элементы, в какой колонке
ну, там задача была другая (не было чёткого формата, количество колонок могло меняться, очерёдность тоже - нужно было всё учесть заранее чтобы не переписывать десять раз)

0