Как же, черт возьми, отсортировать этот список?

[GCU]

Я поясню свой выбор 8 (как наиболее близкий), хотя на мой взгляд там нужен dynamic_cast, a не typeid, и можно ограничиться параметризованным функтором / компаратором
Приоритет при сортировке на мой взгляд привязан к параметрам сортировки, и элементы об этом ничего знать не должны.
Это исключает варианты 1 — 6 (6 вообще костыльный с побочными эффектами)
Вариант 7 и 8 похожи, но смысла возиться со строками нет, тем более писать для этого методы элемента, по сути дублирование встроенного RTTI.
Вариант 9 на мой взгляд плохо расширяем из-за строгой типизации

[svr_91]

Варианты 4 и 5 как раз отвязывает элементы от деталей реализации сортировки

[GCU]

Они не привязаны к параметрам сортировки, поскольку она сама не параметризована, а жёстко задана в коде, нету «конфигурирования приоритетов извне» — приоритеты должны задаваться в рантайме, а не на этапе компиляции.
4й вариант где на 3 типа написано 9 функций сравнения плохо масштабируется при увеличении числа типов.
5й в принципе можно легко переделать и параметризовать, если очень надо без RTTI, то выбрал бы его.

[svr_91]

Иногда сортировка должна задаваться жестко в коде. То есть, пользователь извне ее менять не может, но по запросу например менеджера может быть нужно что-то быстро подтюнить

[izvolov]

https://en.cppreference.com/w/cpp/filesystem/directory_iterator
https://en.cppreference.com/w/cpp/filesystem/directory_entry
https://en.cppreference.com/w/cpp/filesystem/path
+
нужный компаратор над ними.

[svr_91]

Классы файлов, каталогов и т.д. не обязательно должны быть из стандартной библиотеки. В моем случае задача была даже не в классах и каталогах. Там были другие сущности. Файлы и каталоги я выбрал как наглядный всем понятный пример

[mafia8]

//$dirs
//$files
if($config['mix']) {
  $mix=array_megre($dirs, $files);
  sort($mix);
}else{
  sort($dirs);
  sort($files);
}

[svr_91]

Тогда получается, что только ради целей сортировки нужно таскать список каталогов и файлов раздельно

[a1ex322]

Будет перерасход по памяти?

[svr_91]

Нет, непонятно как это обыграть в плане архитектуры. Куда деть эти dirs, files? Завернуть в структуру? А если нам нужно сделать общее действие над всеми элементами (например, найти по какому-нибудь шаблону), то искать сначала в одном, а потом в другом?

[a1ex322]

тогда наследование выглядит как оверхед. Типичная задача на сортировку подразумевает массив элементов одного типа с разными свойствами, никакой магии.

[Static_electro]

Первый вариант с приоритетом в виде инта, только вместо int — enum.

[svr_91]

Хороший вариант, как развитие первого варианта. Можно enum вынести в файл, принадлежашей сортировке и тогда уйдет проблема «поиска всех наследников», нужно будет только заглянуть в файл, где описаны все enum-ы. Но минус — структуры зависят от сортировки

[Static_electro]

Что значит "структуры зависят от сортировки"? В смысле, я не понял, что имеется в виду. Можете перефразировать?

[svr_91]

Ну это значит, что в структурах есть поле priority, которое нужно только для сортировки. Хотя сортировка — не обязательно задача именно этих структур.

В статье про это написано

Может например быть такая ситуация, что классы File, Folder вам даны извне и вы ничего не можете с ними сделать (добавить доп поле например)

[Duny]

Оператор dynamic_cast имеет существенные накладные расходы. При сортировке его лучше избегать.

[Antervis]

вот если использовать именно список, то отсортировать надо лишь единожды, далее можно перетасовывать его при смене типа сортировки за O(N).