Qraizer
Advanced Member | Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору akaGM Цитата: вот если бы я был чиста программистом... | Дык я ж и не агитирую. Почти. Ты выразил свою обеспокоенность необходимостью заняться шаблонами, а я тебя успокаиваю, мол, нет так страшен чёрт... Ну ещё заинтересовываю по мелочи. Цитата: кстати, вот что действительно интересно, так это то, чем приходится расплачиваться за такую гибкость? просто страшно смотреть на такой код, неуж там вообще без внутренних вызовов обходится? | Если ты о метапрограмминге, то расплачиваться приходится исключительно объёмом исходных тестов. Сам посуди, если всё вычисляется на стадии компиляции, какие могут быть вызовы в рун-тайм? Уже всё посчитано и вставлено в код как непосредственные значения. Это, кстати, и тебе тоже полответа, BrdGuest. Что касается многократных вызовов коротеньких функций, которыми зачастую пестрит шаблонный код, то даже весьма посредственный по нынешним меркам оптимизатор такие функции встраивает на ура и сводит их параметры. Так что легко можно уведить, как с пяточек-другой функций, вызывающих одна другую, компилятся в несколько ассеблерных инструкций. Если же об обобщённости вообще, то есть такой нюанс. Чуток разные шаблонные параметры, например указатели на разные типы, влекут генерацию почти близнецов. Но с этим либо ничего не поделаешь, либо можно обойти. Ничего не поделаешь, если, например, они только с виду близнецы, а на самом деле разница в какой-нибудь адресной арифметике из-за разного размера типов сделает их не совсем похожими. Но с другой стороны, для разных типов ты всё равно бы перегрузил функции, так что то на то и вышло бы. А так за тебя это сделал компилятор. Либо ты мог бы обойти это сведением к одному типу, например, базовому классу с заюзыванием полиморфизма, или же к void* в случае простых типов. Однако при этом ты и потерял бы: в первом случае - ты не можешь использовать отличительные характеристики каждого производного класса (а они ведь могут иметь возможности, дополнительные к возможностям базового класса) и невозможность встраивать вызовы виртуальных методов, т.к. все они вызываются косвенно, а это можеть серьёзно сказаться на производительности; во втором случае - потенциальной небезопастностью нетипизированных указателей, т.к. фактически типизация оказыватся отключённой, из-за чего все ошибки "адресной", к примеру, арифметики будут исключительно на твоей совести, и компилятор тут тебе ничем не поможет. Аналогичным образом можно постипуть и в шаблонах. Только для второго случая типизированность не выключится, в крайнем случае будет упрятана в приватный или защищённый интерфейс шаблонного класса, а значит ограничена в своём влиянии на остальной код и следовательно лучше контролируется и проще отлаживается. В первом случае - есть такой термин "статический" полиморфизм, и он обходится без виртуальных методов и не ограничивает интерфейс никакими особыми рамками. Так что по-любому получаешь преимущества. За соответствующую плату, но если попытаешься обойтись без шаблонов - получишь либо примерно то же самое, только бОльшими усилиями, либо выиграешь в частных случаях, но это скорее ксего не окупится при повторном и тем более многократном использовании того, что написал. Ещё не заинтересовался? Впрочем, боюсь, наоборот получилось... BrdGuest, полответа я уже дал. Конечно, я не упомянул, что этот алгоритм должен оперировать константными сущностями, чтобы он мог был реализован в метавиде. Впрочем, это не должно удивлять: раз алгоритм исполняет сам компилятор, то когда он сгенерит код, этот алгоритм исполнять будет уже некому. Тем не менее, действительно на этапе компиляции выполнить можно произвольный алгоритм. На самом деле, это функциональная полнота оказалась неожиданностью даже для самого комитета по стандартизации. Он её специально не планировал включать в язык. Если бы планировал, я думаю, её бы сделали более удобной . Только насколько это нужно? Метапрограмминг - это побочный эффект возможностей шаблонов, и компиляторы просто не рассчитаны на такой режим экплуатации. Во- первых, у них есть понятие лимитов, например, количество вложенных инстанцирований шаблонов или длина декорированного идентификатора. При неслабом метаалгоритме подобные лимиты легко перешагнуть. Во-вторых, компилируют они значительно медленнее, чем потом процессор исполняет. Может оказаться, что проще считать константы в рун-тайм, чем ожидать окончания компиляции. Правило избегания преждевременной оптимизации никто не отменял. Не зря же распространена практика совмещения в приложении компилируемых языков со скриптовыми, где скорость не нужна, зато сервис скриптов рулит. Быстрее бывает написать скрипт, чем класс на плюсах, а то, что исполняться потом будет медленнее в разы не суть важно. Ну вот, скажешь счас, завёл тут, а сам на попятную. Не, просто то была реклама, а это действительность . В твоём случае не думаю, что стОит это метаалгоритмом оформлять. Хотя бы по той причине, что тебя вполне может выручить простой вызов setlocale(".OCP"), или std::locale("Russian_Russia.OCP") в паре c std::basic_ios<>::imbue(), или std::codecvt_byname<>("Russian_Russia.OCP"). И будет это, во-первых, приятнее в использвании, во-вторых, гораздо обобщённее, т.к. любые языки, из числа поддерживаемых ОС, уже готовы к использованию, и в-третьих, потратишь знаково меньше времени. Можно метаалгоритм написать, но тогда тебе его нужно будет писать самому и для каждого языка. Ибо STL вот с BOOST-ом придумали, а метабиблиотеку ещё нет. Потери на разработку метаалгорима ты вряд ли окупишь повышением производительности твоего приложения. И самое главное, строки ты аргуметами шаблонов использовать не можешь. Ибо массив символов - это тип, который нельзя использовать как аргумент шаблона. Вернее можно, но ты передашь адрес первого элемента, а не весь массив. Поэтому доступ к элементам массива придётся осуществлять неконстантной операцией разыменования указателя, которая не может быть выполнена в компил-тайм. Так что придётся изобретать заменитель для строки, например, в виде List-подобного списка типов. P.S. Ну всё. Точно наоборот получилось...
---------- Одни с годами умнеют, другие становятся старше. |
| Всего записей: 613 | Зарегистр. 08-08-2006 | Отправлено: 19:25 26-12-2007 | Исправлено: Qraizer, 19:32 26-12-2007 |
|