1000 - 10000 ключей - не те объемы, на которых нужна оптимизация словаря - все там будет быстро.
А для реально больших количеств ключей используются базы данных
Зависит от предметной области, которая тестируется.
У меня в игре например дофига формул со степенями и потенциальными выходами за пределы интов. Математика ой как нужна чтобы это проверить
Вам ограбили квартиру. Злоумышленники легко проникли в дом, потому что не работало ЗПУ в подъезде. ЖЕС виноват в том что вас ограбили? Их даже на суд не вызовут.
У вас сильно простые примеры.
Если это где то внутри сложной формулы - то лучше явно задать тип, чтобы вызывался соответствующий оператор.
А если еще и перегрузка операторов используется - то вообще без вариантов.
В общем тут дело не в эстетике, а в логике кода. Т.е. есть ситуации когда НУЖНО задавать явно
Ищите конвертеры. X точно поддерживался когда то 3dмаксом через плагин. 3ds вообще звучит как нативный. Возможно нужно в максе делать эксопрт, а не open
База данных - это хранилище информации. Фото и видео - информация. Значит можно. Если база не умеет работать с бинарными данными - переводите в base64 и храните как строку.
Но - нужно очень понимать, зачем вы это делаете (в принципе касается любого вопроса). Точно тут будет профит от базы данных? Или лучше хранить в БД только пути к файлам?
Любой файл можно переименовать в txt и он откроется, более того - в нем вполне может быть vk или vc. У вас сильно много неизвестных.
Хотя бы понятно где файл +- лежал? Может все таки есть более точная информация?
Пока выглядит как то, что вам надо просто искать все файлы, в которых есть vk или vc, и потом поочередно их открывать и смотреть
Судя по вот этому объяснению - Create резервирует, но не ограничивает длину массива. Т.е. у вас будет аллокация на Create, а потом на Rent при превышении размера. Если Rent запросит меньше чем было на Create - аллокации не будет. По похожему принципу List capasity работает
