Здравствуйте, VladD2, Вы писали:

V>>То есть, таким образом, мы получили статический контроль типизации нетипизированной динамически загружаемой библиотеки.

VD>Это, я извинясь, хрень полная, а не шаблон в библиотеке. Что и следовало доказать. В то же время дженерики лежат себе в библоиотеках и даже описания текстового не просят. Потому как проектировались в рассчете на это.

Чтобы использовать extern "C" функцию, определенную в dll, тоже нужно текстовое объявление. И это не мешает их широкому использованию.

VladD2,

> ПК> Влад, не смешно. Перечитай предлагавшиеся варианты (выше по ветке). Т.к. generics ограничены возможностями работы через интерфейсы, то можно вынести соответствующие non-generic функции, работающие через ссылки и указатели на интерфейсы, в DLL. Что конкретно не будет работать?

> Ничего не будет работать. Положить полноценный шаблон в длл невозможно. А дженерик раз плюнуть.

Полноценный, естественно, не получится. А неполноценный, типа generics, как уже показали — легко Наличие переходников в заголовках не считается, если ты предлагаешь не считать количество делегатов для передачи операторов в generics: баш на баш, так сказать

Здравствуйте, Костя Ещенко, Вы писали:

КЕ>Чтобы использовать extern "C" функцию, определенную в dll, тоже нужно текстовое объявление. И это не мешает их широкому использованию.

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>VladD2,

>> ПК> Влад, не смешно. Перечитай предлагавшиеся варианты (выше по ветке). Т.к. generics ограничены возможностями работы через интерфейсы, то можно вынести соответствующие non-generic функции, работающие через ссылки и указатели на интерфейсы, в DLL. Что конкретно не будет работать?

>> Ничего не будет работать. Положить полноценный шаблон в длл невозможно. А дженерик раз плюнуть.

ПК>Полноценный, естественно, не получится. А неполноценный, типа generics, как уже показали — легко

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

ПК> Наличие переходников в заголовках не считается, если ты предлагаешь не считать количество делегатов для передачи операторов в generics: баш на баш, так сказать

Короче, как только тебе удастся запихнуть в ДЛЛ скажем std::vector<>, то можно будет продолжить — это спор. А до тех пор он несколько не сотоятелен.

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>_FRED_,

ПК>Извиняюсь, что посреди большой философии с такими частностями. Тем не менее...

Эээ. Такую тему пропустил....

>> Читал, что экспорт шаблонов ещё не сделан.

ПК>Сделан в EDG. Сравнительно давно доступен в Comeau.

>> Нужен? "Необходим!" ответят, я думаю, многие.

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

Нет реальная польза не в этом. См. ниже. При перекомпиляции, кстати, не так всё гладко. Но даже если бы не было никаких приемуществ для компиляции, всё равно экспорт нужен.

> Имхо, намного полезнее введение модулей, чему, впрочем, экспорт шаблонов, вроде, не мешает.

Абсолютно. Экспорт шаблонов требует рассмотрения исходных файлов за пределами единицы трансляции (в её привычном понимании). В каком-то смысле экспорт форсирует переход к модульной компиляции в C++. Это одна из причин, по которой экспорт отвергается многими производителями компиляторов. Не расчитаны они на модульный подход. Даёшь им единицу трансляции в один файл и всё тут.

ПК>Хотя, согласен, практического опыта использования экспорта шаблонов пока наработано немного, может оказаться, что какие-то дополнительные бонусы еще не найдены.

А как насчёт сокрытия реализации? Не надоели вещи типа namespace details?

// without export
// .h
namespace __details  // ugly implementation
{
    template <typename T> bar(T t) {…}
}

// beautiful interface
template <typename T> foo(T t)
{
    bar(t);
}

// with export
// .hpp
export template <typename T> foo(T);

// .cpp
// ugly stuff goes here. inside the anonymous namespace!
namespace
{
    template <typename T> bar(T t) {…}
}

template <typename T> foo(T t)
{
    bar(t);
}

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

<rant>А опыт не накоплен, потому что кому-то даже лень разжиться Comeau C++ за $20!</rant>

alexeiz,

> В каком-то смысле экспорт форсирует переход к модульной компиляции в C++.

Скорее, к компиляции всей программы...

> ПК>Хотя, согласен, практического опыта использования экспорта шаблонов пока наработано немного, может оказаться, что какие-то дополнительные бонусы еще не найдены.
>
> А как насчёт сокрытия реализации? Не надоели вещи типа namespace details?

Да, этот момент присутствует, но не в той мере, как ожидалось до реализации и практического опыта. Даже при экспорте вполне могут "подхватываться" функции из других единиц трансляции, в т.ч. и из анонимных namespace, из-за ADL.

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>alexeiz,

>> ПК>Хотя, согласен, практического опыта использования экспорта шаблонов пока наработано немного, может оказаться, что какие-то дополнительные бонусы еще не найдены.
>>
>> А как насчёт сокрытия реализации? Не надоели вещи типа namespace details?

ПК>Да, этот момент присутствует, но не в той мере, как ожидалось до реализации и практического опыта.

Ожидалось, что с экспортом шаблонов будет как в Си — изменил один файл реализации, перекомпилировал только его. Не тут-то было.

Я не понимаю, про какой практический опыт ты говоришь. Его просто не существует. Про практический опыт должен говорить Plauger, так как только у него есть библиотека использующая export. Остальные это дело игнорируют, а Plauger молчит как рыба.

>Даже при экспорте вполне могут "подхватываться" функции из других единиц трансляции, в т.ч. и из анонимных namespace, из-за ADL.

То что ты говоришь, касается раздельной компиляции. По причине подхватывания невозможно перекомпилировать только одну единицу трансляции. Я же говорю про разделение интерфейса и реализации на уровне исходных файлов. Мне не так важно будет ли перекомпилирован один файл или несколько. Мне важно, чтобы можно было иметь "чистые" header файлы описывающие только интерфейс библиотеки доступный извне. Я хочу запихать все эти namespace details в далёкое тёмное место. Однако, при современном состоянии дел с шаблонами это невозможно. Экспорт как раз и решает эту проблему.

ПК>В этом смысе настоящая модульная компиляция, имхо, была бы намного лучшим решением, чем экспорт шаблонов.

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

Кстати про модульную компиляцию. Какие нибудь предложения в С++ коммитет на этот счёт есть? Где нибудь можно посмотреть?

alexeiz,

>> Даже при экспорте вполне могут "подхватываться" функции из других единиц трансляции, в т.ч. и из анонимных namespace, из-за ADL.

> То что ты говоришь, касается раздельной компиляции. По причине подхватывания невозможно перекомпилировать только одну единицу трансляции. Я же говорю про разделение интерфейса и реализации на уровне исходных файлов. Мне не так важно будет ли перекомпилирован один файл или несколько. Мне важно, чтобы можно было иметь "чистые" header файлы описывающие только интерфейс библиотеки доступный извне. Я хочу запихать все эти namespace details в далёкое тёмное место. Однако, при современном состоянии дел с шаблонами это невозможно. Экспорт как раз и решает эту проблему.

В общем случае не решает, т.к. файлы с namespace details "вдруг" могут сослаться из далекого темного места на функции в твоих файлах реализации, даже если непосредственно их не включают. Соответственно, той степени изоляции между интерфейсами и реализацией, как в других местах в C++, не получается.

> ПК>В этом смысе настоящая модульная компиляция, имхо, была бы намного лучшим решением, чем экспорт шаблонов.
>
> Как я понял, это ортогональные вещи. Если есть модульная компиляция, то экспорт должен реализоваваться на ура, так как он в этом случае будет представлять только синтаксическую конструкцию, не приводящюю к изменению процесса компиляции.

Не факт. При модульной компиляции семантика может отличаться от того, что получилось в случае экспорта.

> Кстати про модульную компиляцию. Какие нибудь предложения в С++ коммитет на этот счёт есть? Где нибудь можно посмотреть?

Daveed Vandevoorde. Modules in C++ (Revision 1)
http://open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>alexeiz,

>>> Даже при экспорте вполне могут "подхватываться" функции из других единиц трансляции, в т.ч. и из анонимных namespace, из-за ADL.

>> То что ты говоришь, касается раздельной компиляции. По причине подхватывания невозможно перекомпилировать только одну единицу трансляции. Я же говорю про разделение интерфейса и реализации на уровне исходных файлов. Мне не так важно будет ли перекомпилирован один файл или несколько. Мне важно, чтобы можно было иметь "чистые" header файлы описывающие только интерфейс библиотеки доступный извне. Я хочу запихать все эти namespace details в далёкое тёмное место. Однако, при современном состоянии дел с шаблонами это невозможно. Экспорт как раз и решает эту проблему.

ПК>В общем случае не решает, т.к. файлы с namespace details "вдруг" могут сослаться из далекого темного места на функции в твоих файлах реализации, даже если непосредственно их не включают. Соответственно, той степени изоляции между интерфейсами и реализацией, как в других местах в C++, не получается.

Это-то понятно. Но мой аргумент в том, что этой степени изоляции и не нужно. Достаточно "визуальной" изоляции. Т.е. я декларирую интерфейс шаблона в .h файле, а реализацию в .cpp. И выглядит это почти так же как и со всем остальным (нешаблонным) кодом.

>> ПК>В этом смысе настоящая модульная компиляция, имхо, была бы намного лучшим решением, чем экспорт шаблонов.
>>
>> Как я понял, это ортогональные вещи. Если есть модульная компиляция, то экспорт должен реализоваваться на ура, так как он в этом случае будет представлять только синтаксическую конструкцию, не приводящюю к изменению процесса компиляции.

ПК>Не факт. При модульной компиляции семантика может отличаться от того, что получилось в случае экспорта.

>> Кстати про модульную компиляцию. Какие нибудь предложения в С++ коммитет на этот счёт есть? Где нибудь можно посмотреть?

ПК>Daveed Vandevoorde. Modules in C++ (Revision 1)
ПК>http://open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf

Не очень впечатлило. Ну да это только первый вариант. Есть сомнительные вещи такие как вложенные модули или включение одного модуля в другой. Какие-то модульные атрибуты предлагаются. А вот разделение областей видимости (private поля вообще из модуля никак не видно) — это хорошо. Но вообщем тяжеловато. Надеюсь, это эвалюционирует в более стройную и простую концепцию.