__>Пока что придирки к CNameIdHolder. __>Вы действительно считаете что такая специализация выглядит красиво ? __>Лучше уж сделать собственный велосипед на макросах, чем городить это все, вдобавок код у вас не расширяем, т.е. если я захочу, чтобы было не 7, а 8 параметров то мне надо очень много дописывать.
Параметров и так 8, а CNameIdHolder и не должен быть расширяем — расширяем CNameId, именно его и надо менять, если надо более длинное имя. Специализация вполне красивая, хотя и не маленькая (впрочем, можно и без нее, но так экономится размер бинарника), и макрос тут тоже лучше, чем набор отдельных классов — "не плодите сущности без необходимости", их уже и так много
Имхо, главная проблема не в этом, а в том, как удобнее пользовать основные макросы, где требуется переменное число параметров + как красивее определять макросы для различного числа параметров функций.
А вообще, откровенно говоря, мне не понятна логика комитета, который не предусмотрел специализацию строковыми литералами.
Здравствуйте, Andrew S, Вы писали:
__>>Пока что придирки к CNameIdHolder. __>>Вы действительно считаете что такая специализация выглядит красиво ? __>>Лучше уж сделать собственный велосипед на макросах, чем городить это все, вдобавок код у вас не расширяем, т.е. если я захочу, чтобы было не 7, а 8 параметров то мне надо очень много дописывать.
AS>Параметров и так 8, а CNameIdHolder и не должен быть расширяем — расширяем CNameId, именно его и надо менять, если надо более длинное имя. Специализация вполне красивая, хотя и не маленькая (впрочем, можно и без нее, но так экономится размер бинарника), и макрос тут тоже лучше, чем набор отдельных классов — "не плодите сущности без необходимости", их уже и так много AS>Имхо, главная проблема не в этом, а в том, как удобнее пользовать основные макросы, где требуется переменное число параметров + как красивее определять макросы для различного числа параметров функций.
Зато в моем варианте не требуется переписывать для каждой специализации код.
AS>А вообще, откровенно говоря, мне не понятна логика комитета, который не предусмотрел специализацию строковыми литералами.
Потому что массивом нельзя специализировать шаблон, а строки это массив символов.
Видимо реализация этого довольно сложна.
__>Зато в моем варианте не требуется переписывать для каждой специализации код.
Ваш вариант вообще работать не будет, он определяет массив из 8-ми TCHAR Забудьте про эту мысль, она плохая, уверяю вас, вы РОВНЫМ счетом ничего не съэкономите, а наоборот.
AS>>А вообще, откровенно говоря, мне не понятна логика комитета, который не предусмотрел специализацию строковыми литералами. __>Потому что массивом нельзя специализировать шаблон, а строки это массив символов. __>Видимо реализация этого довольно сложна.
Здравствуйте, Andrew S, Вы писали:
__>>Зато в моем варианте не требуется переписывать для каждой специализации код.
AS>Ваш вариант вообще работать не будет, он определяет массив из 8-ми TCHAR Забудьте про эту мысль, она плохая, уверяю вас, вы РОВНЫМ счетом ничего не съэкономите, а наоборот.
AS>>>А вообще, откровенно говоря, мне не понятна логика комитета, который не предусмотрел специализацию строковыми литералами. __>>Потому что массивом нельзя специализировать шаблон, а строки это массив символов. __>>Видимо реализация этого довольно сложна.
AS>Как раз массивом специализировать шаблон можно.
AS>А вот сроковым литералом, который имеет internal linkage и тип const TCHAR[] — нельзя.
Потому что это внешняя линковка, а все что внутреняя нельзя использовать.
__>>И не будет проблем с разложением DWORD.
AS>Проблем и так нет, это вы их придумали А запись имени получится в 2.5 раза длиннее и еще непонятнее.
Я люблю придумывать проблемы и героически их решать
AS>>А вот сроковым литералом, который имеет internal linkage и тип const TCHAR[] — нельзя. __>Потому что это внешняя линковка, а все что внутреняя нельзя использовать.
Это все понятно.
__>Зато можно сделать такое :
В VC6 — нельзя. Можно только без спецификатора const. __>
Будут проблемы другого плана — в каждом модуле линковки будет своя таблица (поскольку специализации, в данном случае адреса массивов), будут различаться. А нам то нужно как раз обратно — обеспечить кросс-модульность.
__>Или может лучше сделать через Traits ?
__>
Аналогичная проблема, только, за исключением того, что придется делать трейты для всех функций, библиотеку и т.п. что используются в программе, выносить их в отдельный заголовочный файл, а это убивает изначальную гибкость конструкции.
Что делает CNameIdHolder ?
Создает строку из нескольких двойных слов, вместо этого можно использовать обычные символы, и тогда не нужен будет макрос FLATTEN_STR, зато писать надо немного утомительно :
А в С++ так всегда — когда кажется, что проблем нет, то это только кажется.
__>А теперь сначала все
__>Что делает CNameIdHolder ? __>Создает строку из нескольких двойных слов, вместо этого можно использовать обычные символы, и тогда не нужен будет макрос FLATTEN_STR, зато писать надо немного утомительно :
Нет, он статически инициализирует массив _подходящей_ длины. В вашем случае вам придется делать 32 специализации, иначе получите большой оверхед по длине массива. да и запись каждого символа по-отдельности это совсем некрасиво.
Здравствуйте, Andrew S, Вы писали:
__>>Проблемы одни
AS>А в С++ так всегда — когда кажется, что проблем нет, то это только кажется.
__>>А теперь сначала все
__>>Что делает CNameIdHolder ? __>>Создает строку из нескольких двойных слов, вместо этого можно использовать обычные символы, и тогда не нужен будет макрос FLATTEN_STR, зато писать надо немного утомительно :
AS>Нет, он статически инициализирует массив _подходящей_ длины. В вашем случае вам придется делать 32 специализации, иначе получите большой оверхед по длине массива.
Оверхед, да будет, но не настолько большой.
Допустип ограничимся 32 символами, на 100 классов будет максимальный оверхед в 32*100 = 3,2кБ, я не думаю что для программы, размер которой несколько сот кБ это критично. AS>да и запись каждого символа по-отдельности это совсем некрасиво.
А в оригинале разве не так ?
В крайнем случае сделаем макросы аналоги в boost-е и воспользуемся ими
__>Допустип ограничимся 32 символами, на 100 классов будет максимальный оверхед в 32*100 = 3,2кБ, я не думаю что для программы, размер которой несколько сот кБ это критично.
Может и не критично, но тогда в чем смысл всей этой городни с синглтонами и т.п. Если есть возможность делать оптимальнее при разработке библиотеки — это надо сделать.
AS>>да и запись каждого символа по-отдельности это совсем некрасиво. __>А в оригинале разве не так ?
Нет, не так Некрасиво — да, но все-таки не по-одному, а пачками по четыре Хотя, конечно, уродство все это
__>В крайнем случае сделаем макросы аналоги в boost-е и воспользуемся ими
Мне — почти никак, он на VC6 компилится не будет, как я понял — там у вас частичная специализация?
В любом случае, это почти ничего не меняет, ну, кроме конечно размеров исходников, тем более, как я говорил, мне мысль использовать односимвольные числовые литералы почему то не нравится, хотя начиналось все именно так.
На самом деле, наверное, лучше подумать над более глобальной проблемой — как удобнее сделать макросы
USE_MODULE_BEGIN и DECLARE_FUN_P1 в части задания имени. То, что есть сейчас, явно неудобно...
Здравствуйте, Andrew S, Вы писали:
__>>Как вам такой вариант :
AS>[skipped]
AS>Мне — почти никак, он на VC6 компилится не будет, как я понял — там у вас частичная специализация?
Забыл про VC6
А чем вам оверхед мешает ?
Зато все строки будут одинаковой длинны AS>В любом случае, это почти ничего не меняет, ну, кроме конечно размеров исходников, тем более, как я говорил, мне мысль использовать односимвольные числовые литералы почему то не нравится, хотя начиналось все именно так.
Односимвольные литералы лучше, так как позволяют избежать проблемы вроде этой :
CModule<'some','tex','t'>
Мне кажется что стоит сделать какой-нибудь класс для преобразования строки в односимвольные литералы, и тогда проблем не будет.
template<TCHAR c0,TCHAR c1, ... >
struct CNameID
{...};
template<typename T,TCHAR str[]>
class str_to_char
{
typedef T<str[0],str[1],...> type; // как правильно не знаю :xz:
};
Надеюсь идея ясна.
AS>На самом деле, наверное, лучше подумать над более глобальной проблемой — как удобнее сделать макросы AS>USE_MODULE_BEGIN и DECLARE_FUN_P1 в части задания имени. То, что есть сейчас, явно неудобно...
Если решить проблемы выше то это отпадет само собой.
Ну, и подумайте, что вы предлагаете Хинт — при инстанцировании класса CNameID параметрами должны быть символьные литералы (то бишь константы).
AS>>На самом деле, наверное, лучше подумать над более глобальной проблемой — как удобнее сделать макросы AS>>USE_MODULE_BEGIN и DECLARE_FUN_P1 в части задания имени. То, что есть сейчас, явно неудобно... __>Если решить проблемы выше то это отпадет само собой.
Да, если решить проблемы Я (и не только я) пробовал, не получилось. Точнее, получилось то, что получилось.
Здравствуйте, Andrew S, Вы писали:
__>>Мне кажется что стоит сделать какой-нибудь класс для преобразования строки в односимвольные литералы, и тогда проблем не будет.
__>>
__>>Надеюсь идея ясна.
AS>Ну, и подумайте, что вы предлагаете Хинт — при инстанцировании класса CNameID параметрами должны быть символьные литералы (то бишь константы).
Инстанирование будет литералами, а извне это будет в виде массива.
AS>>>На самом деле, наверное, лучше подумать над более глобальной проблемой — как удобнее сделать макросы AS>>>USE_MODULE_BEGIN и DECLARE_FUN_P1 в части задания имени. То, что есть сейчас, явно неудобно... __>>Если решить проблемы выше то это отпадет само собой.
AS>Да, если решить проблемы Я (и не только я) пробовал, не получилось. Точнее, получилось то, что получилось.
Как только доберусь нормально до компьютера попробую что-нибудь сотворить
AS>>Ну, и подумайте, что вы предлагаете Хинт — при инстанцировании класса CNameID параметрами должны быть символьные литералы (то бишь константы). __>Инстанирование будет литералами, а извне это будет в виде массива.
Не получится. Надо инстанцировать константами, а вы предлагаете инстанцировать фактически содержимым ячеек памяти, что на этапе компиляции компилеру не известно (ведь темплайт в данном случае инстанцируется адресом, к сожалению, а не содержимым).
AS>>>>На самом деле, наверное, лучше подумать над более глобальной проблемой — как удобнее сделать макросы AS>>>>USE_MODULE_BEGIN и DECLARE_FUN_P1 в части задания имени. То, что есть сейчас, явно неудобно... __>>>Если решить проблемы выше то это отпадет само собой.
AS>>Да, если решить проблемы Я (и не только я) пробовал, не получилось. Точнее, получилось то, что получилось. __>Как только доберусь нормально до компьютера попробую что-нибудь сотворить
Здравствуйте, Andrew S, Вы писали:
AS>>>Ну, и подумайте, что вы предлагаете Хинт — при инстанцировании класса CNameID параметрами должны быть символьные литералы (то бишь константы). __>>Инстанирование будет литералами, а извне это будет в виде массива.
AS>Не получится. Надо инстанцировать константами, а вы предлагаете инстанцировать фактически содержимым ячеек памяти, что на этапе компиляции компилеру не известно (ведь темплайт в данном случае инстанцируется адресом, к сожалению, а не содержимым).
Вы меня не так поняли
Ну ладно это не важно, я попробую переработать это для совместимости с VC 6 и выложу на форум.
Главное ведь результат
AS>>>>>На самом деле, наверное, лучше подумать над более глобальной проблемой — как удобнее сделать макросы AS>>>>>USE_MODULE_BEGIN и DECLARE_FUN_P1 в части задания имени. То, что есть сейчас, явно неудобно... __>>>>Если решить проблемы выше то это отпадет само собой.
AS>>>Да, если решить проблемы Я (и не только я) пробовал, не получилось. Точнее, получилось то, что получилось. __>>Как только доберусь нормально до компьютера попробую что-нибудь сотворить
Большое спасибо _nn_ за проявленную инициативу, в связи с чем выкладываю обновление до v 1.03
Специализация выполнена на макросах, максимальная длина строки увеличена до 64 символов, можно без особых изменений в коде и больше.
На макросы определения функций терпения не хватило, а common вариант не придумался — если есть мысли, будет интересно выслушать.
И, как обычно — если есть какие предложения (ну, кроме использования буста, тут это как из пушки по воробьям) — u are welcome.
Здравствуйте, Andrew S, Вы писали:
AS>Большое спасибо _nn_ за проявленную инициативу, в связи с чем выкладываю обновление до v 1.03 AS>Специализация выполнена на макросах, максимальная длина строки увеличена до 64 символов, можно без особых изменений в коде и больше. AS>На макросы определения функций терпения не хватило, а common вариант не придумался — если есть мысли, будет интересно выслушать.
Есть идея, но она мне кажется неосуществима.
Что-то такое :
FunProxyThrowPolicy использует тоже CString, однако он выкидывает это как исключение.
Поэтому пользователю придется заботиться об уничтожении выделенной памяти или же сделать обертку для этого.