тут дело в том что, если в конструкторе 1 параметр — все ок. у нас есть 2 перегрузки: const & и &&
а теперь представим что параметров стало 5, необходимое количество перегрузок станет 32, чтоб учесть все варианты вызова
для этого и была придумана шаблонная форма
то есть мы определяем одну шаблонную функцию и внутри нее при помощи forvard&move правильно обрабатываем каждый параметр
они еще обещали добавить шаблон который в компайлтайме подскажет как был передан параметр в конкретном вызове
GetTickCount очень неточная функция с очень большим оверхедом, для более точных замеров нужно использовать QueryPerformanceCounter/QueryPerformanceFrequency, либо считать такты по rdtsc. перед началом замеров нужно привязать поток к конкретному ядру.
я не моделер, но допустим в максе примитивные действия типа подвигать, повернуть, растянуть объект находятся методом тыка, особенно в последних версиях.
подвигать точки и плоскости объектов задача чуть сложнее но метод тыка и тут все еще работает.
в блендере это не очень тривиальные действия, не знаю как в последнем но в версии 2.3* это нужно было делать при помощи жестов мыши, по крайней мере я определил это методом тыка, но объект разместить там где мне нужно так и не смог.
у вашего скрипта есть проблема, она заключается в том, что файлы нужно конвертить вручную, что не очень удобно, особенно если весь остальной процесс сборки идет из батч файла.
у нас был скрипт который брал список файлов из командной строки макса, то есть конвертацию можно было проводить в автоматическом режиме.
в «Эффективном использовании STL» Мейерса есть метод как заменить map на vector.
другой вериант, это если у нас в мапе бывает немного разновидностей значений, допустим 10 из 100 (примерно, хотя на практике значения бывают больше допустим 50000 из 100000), то не нужно заводить мап чтоб их хранить и пытаться экономить на этом память, можно завести массив на все 100 элементов, и пометить есть ли он в наличии. на маленьких кусках данных это часто даже выгоднее чем заводить мап, хотя бы с точки зрения количества аллокаций, особенно если есть вероятность что в наборе появятся все варианты.
допустим в играх часто не меняется набор файлов, но при этом не менее часто нужно хранить какие-то ресурсы которые из этих файлов выгружаются. одно из решений к которому придет любой школьник, это map<filename,ressource>. более красивым решением может быть нумерация всех файлов на этапе компиляции, и использование vector<ressource> и vector<filename>, во втором мы ищем id по имени (можно при желании отсортировать и использовать бинарный поиск), в первом за O(1) получаем ресурс по ID, такой способ позволяет отказаться от указателей на ресурсы, что даст более гибкие методы управления ими (время доступа по идентификатору O(1), часто идентификатор может иметь меньший размер чем указатель, хотя это уже спички).
но если посмотреть еще, то можно заметить что vector<filename> нам не очень нужен, так как обычно имена файлов получают из других файлов либо файлов конфигураций, где какой нибудь скрипт их может заменить на ID еще в компайл тайме (в смысле на стадии сборки ресурсов), что позволит выкинуть строки и мапы вообще, получив возможность более гибко менеджить ресурсы, но ценой добавления стадии сборки ресурсов и отсутствия возможности добавлять новые файлы в уже готовую игру (немного усложняет патчинг и увеличивает размер патча, нужно это или нет уже другой вопрос).
вот так вот серия небольших размышлений которая занимает считанные дни позволяет увидеть совсем другую систему ресурсов в игре, сэкономив недели в конце проекта.
очень многие неправильно понимают смысл этой фразы, и считают что оптимизировать нужно в конце то что тормозит.
не потраченный час на этапе проектирования, превращается в потраченный день перед релизом (это касается не только оптимизации).
я уже пользовался, отличная вещь. но интернет в Украине еще не достаточно силен, да и ближайшие сервера в западной Европе — но в принципе играбельно. для нее нужен 10мб/с инет, в случае меньшей скорости, просто ухудшится качество картинки.
сама приставка имеет размеры айфона.
я думаю направление очень перспективное и проблема пиратства не стоит так остро.
а теперь представим что параметров стало 5, необходимое количество перегрузок станет 32, чтоб учесть все варианты вызова
для этого и была придумана шаблонная форма
то есть мы определяем одну шаблонную функцию и внутри нее при помощи forvard&move правильно обрабатываем каждый параметр
они еще обещали добавить шаблон который в компайлтайме подскажет как был передан параметр в конкретном вызове
T move_if_rr( T&& val )
{
return std::move(val);
}
template<typename T>
const T& move_if_rr( const T& val )
{
return val;
}
предпросмотр тоже не работает
тег
не работает
templateT move_if_rr( T&& val )
{
return std::move(val);
}
templateconst T& move_if_rr( const T& val )
{
return val;
}
templateT move_if_rr( T&& val )
{
return std::move(val);
}
templateconst T& move_if_rr( const T& val )
{
return val;
}
но я не уверен
в С++11 nullptr должно решать такие конфликты, поэтому 0 это инт а nullptr это NULL
а Clang вроде еще не поддерживает С++11
подвигать точки и плоскости объектов задача чуть сложнее но метод тыка и тут все еще работает.
в блендере это не очень тривиальные действия, не знаю как в последнем но в версии 2.3* это нужно было делать при помощи жестов мыши, по крайней мере я определил это методом тыка, но объект разместить там где мне нужно так и не смог.
у нас был скрипт который брал список файлов из командной строки макса, то есть конвертацию можно было проводить в автоматическом режиме.
другой вериант, это если у нас в мапе бывает немного разновидностей значений, допустим 10 из 100 (примерно, хотя на практике значения бывают больше допустим 50000 из 100000), то не нужно заводить мап чтоб их хранить и пытаться экономить на этом память, можно завести массив на все 100 элементов, и пометить есть ли он в наличии. на маленьких кусках данных это часто даже выгоднее чем заводить мап, хотя бы с точки зрения количества аллокаций, особенно если есть вероятность что в наборе появятся все варианты.
допустим в играх часто не меняется набор файлов, но при этом не менее часто нужно хранить какие-то ресурсы которые из этих файлов выгружаются. одно из решений к которому придет любой школьник, это map<filename,ressource>. более красивым решением может быть нумерация всех файлов на этапе компиляции, и использование vector<ressource> и vector<filename>, во втором мы ищем id по имени (можно при желании отсортировать и использовать бинарный поиск), в первом за O(1) получаем ресурс по ID, такой способ позволяет отказаться от указателей на ресурсы, что даст более гибкие методы управления ими (время доступа по идентификатору O(1), часто идентификатор может иметь меньший размер чем указатель, хотя это уже спички).
но если посмотреть еще, то можно заметить что vector<filename> нам не очень нужен, так как обычно имена файлов получают из других файлов либо файлов конфигураций, где какой нибудь скрипт их может заменить на ID еще в компайл тайме (в смысле на стадии сборки ресурсов), что позволит выкинуть строки и мапы вообще, получив возможность более гибко менеджить ресурсы, но ценой добавления стадии сборки ресурсов и отсутствия возможности добавлять новые файлы в уже готовую игру (немного усложняет патчинг и увеличивает размер патча, нужно это или нет уже другой вопрос).
вот так вот серия небольших размышлений которая занимает считанные дни позволяет увидеть совсем другую систему ресурсов в игре, сэкономив недели в конце проекта.
не потраченный час на этапе проектирования, превращается в потраченный день перед релизом (это касается не только оптимизации).
сама приставка имеет размеры айфона.
я думаю направление очень перспективное и проблема пиратства не стоит так остро.