Раздувание кода шаблона c неупорядоченной картой

так как меня специально попросили прокомментировать, я буду, хотя я не уверен, что мне есть что добавить, чем уже было сказано. (извини, мне потребовалось 8 дней, чтобы добраться сюда)

я реализовал идиому тонкого шаблона раньше, для некоторых контейнеров, а именно vector, deque и list. В настоящее время я не реализовал его для любого контейнера в libc++. И я никогда не использовал его для неупорядоченных контейнеров.

он экономит на размере кода. Это также добавляет сложности, много больше, чем ссылка на ссылку wikibooks. Можно также сделать это не только для указателей. Вы можете сделать это для всех скаляров, которые имеют одинаковый размер. Например, почему существуют разные экземпляры для int и unsigned? Даже ptrdiff_t может храниться в том же экземпляре, что и T*. В конце концов, это всего лишь мешок на дне. Но очень сложно получить шаблоны членов, которые принимают ряд итераторов правильно при воспроизведении этих трюков.

там есть недостатки, хотя (помимо сложности реализации). Он не играет почти так же хорошо с отладчиком. По крайней мере, это значительно затрудняет отладчику отображение внутренностей контейнера. И хотя экономия размера кода может быть значительной, я бы не стал называть экономию размера кода драматической. Особенно по сравнению с памятью, необходимой для хранения фотографий, анимаций, аудиоклипов, карт улиц, лет электронной почты со всеми вложениями из вашего лучшие друзья и семья, и т. д. Т. е. оптимизация размера кода is важно. Но вы должны учитывать, что во многих приложениях сегодня (даже на встроенных устройствах), если вы сократите размер кода наполовину, вы можете сократить размер приложения на 5% (статистика, по общему признанию, вытащена из воздуха).

моя текущая позиция заключается в том, что эта конкретная оптимизация лучше всего оплачивается и реализуется в компоновщике, а не в контейнере шаблонов. Хотя я знаю, что это нелегко реализовать в linker я слышал об успешных реализациях.

это, как говорится, я все еще пытаюсь сделать оптимизацию размера кода в шаблонах. Например, в вспомогательных структурах libc++, таких как __hash_map_node_destructor шаблонизированы как можно меньше параметров, поэтому, если какой-либо из их кода будет изложен, более вероятно, что один экземпляр помощника может служить более одного экземпляра unordered_map. Этот метод является дружественным к отладчику, и не так сложно получить право. И даже может иметь некоторые положительные побочные эффекты для клиента при применении к итераторам (N2980).

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