Вот решил упорядочить свои часто используемые исходники под Win в виде библиотеки. Наткнулся на вопрос, на который пока не нашел ответа: собрать просто все это в виде исходников или сделать из них lib?

Lib:
[+] легкость подключения (включаем .h, который тянет за собой нужный lib через pragma)/
[-] как подумаю, сколько версий lib надо (x86/x64, release/debug, MT/MTD), да еще возможные зависимости от WINVER ... бр...

Исходники:
[+] Никаких неудобств с версиями Lib и WINVER
[-] Каждый раз подключать .cpp в проект руками

А кто как делает?

Здравствуйте, <Аноним>, Вы писали:

А>Вот решил упорядочить свои часто используемые исходники под Win в виде библиотеки. Наткнулся на вопрос, на который пока не нашел ответа: собрать просто все это в виде исходников или сделать из них lib?

У меня все такое собрано в lib.

А>Lib:
А>[+] легкость подключения (включаем .h, который тянет за собой нужный lib через pragma)/
удобно, ага
А>[-] как подумаю, сколько версий lib надо (x86/x64, release/debug, MT/MTD), да еще возможные зависимости от WINVER ... бр...
У меня с этим проще: 3 версии, с разными именами результирующих lib, нужная через ifdef в .h подключается прагмой. Вообще разные версии в VC6/2003 делаются очень просто, так что не особо понятно в чем именно геморрой?
WINVER у меня WinXP/2003 минимум.
Версии только Release, ReleaseNoP4 (AMD compartible — просто юзаю ICC, и в этой версии отключены специфические для P4 SSE3 оптимизации) и Debug
Мне хватает.

А>Исходники:
А>[+] Никаких неудобств с версиями Lib и WINVER
Сомнительные неудобства
А>[-] Каждый раз подключать .cpp в проект руками
Меня такое уже давно забодало и в результате пришел к lib варианту

Здравствуйте, Аноним, Вы писали:

А>Lib:
[-] шаблоны без препроцессинга не подключить (CString, TypeTraits и т.д.)

А>Исходники:
А>[-] Каждый раз подключать .cpp в проект руками
Можно сделать один Library.cpp и туда заинклудить все cpp.

otdelny .lib proect kotory podkluchaetsya v workspace'y pri neobhodimosty. Nuzhnie WINVER, output library, compiler keys etc peredautsya cherez environment variables. *.dsw workspace'ov otrkivaetsya cherez .cmd v kotorom predvaritelno ustanavlivautsa vse nuzhnie env variables.

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

V>Здравствуйте, Аноним, Вы писали:

А>>Lib:
V>[-] шаблоны без препроцессинга не подключить (CString, TypeTraits и т.д.)
У меня шаблоны вынесены в .h которые подключаются из главного .h либы.

А>>Исходники:
А>>[-] Каждый раз подключать .cpp в проект руками
V>Можно сделать один Library.cpp и туда заинклудить все cpp.
Бррр!

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

А>>>Lib:
V>>[-] шаблоны без препроцессинга не подключить (CString, TypeTraits и т.д.)
CC>У меня шаблоны вынесены в .h которые подключаются из главного .h либы.
А можно и в либу, если знать как

А>>>Исходники:
А>>>[-] Каждый раз подключать .cpp в проект руками
V>>Можно сделать один Library.cpp и туда заинклудить все cpp.
CC>Бррр!
Ну.. решение всёже Ж)

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

V>>>[-] шаблоны без препроцессинга не подключить (CString, TypeTraits и т.д.)
CC>>У меня шаблоны вынесены в .h которые подключаются из главного .h либы.
V>А можно и в либу, если знать как
Мда, ну и как же например шаблон smart pointer-а запихать в lib без потери функциональности?

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

V>>>>[-] шаблоны без препроцессинга не подключить (CString, TypeTraits и т.д.)
CC>>>У меня шаблоны вынесены в .h которые подключаются из главного .h либы.
V>>А можно и в либу, если знать как
CC>Мда, ну и как же например шаблон smart pointer-а запихать в lib без потери функциональности?
А не все ли равно где живет шаблон: в либе или исходниках?

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

LM>А не все ли равно где живет шаблон: в либе или исходниках?
Мне вообще то интересно как это вообще возможно.

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

LM>>А не все ли равно где живет шаблон: в либе или исходниках?
CC>Мне вообще то интересно как это вообще возможно.
Шаблон в h-файле, h-файл — в проекте. Проект — либа.

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

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

LM>>>А не все ли равно где живет шаблон: в либе или исходниках?
CC>>Мне вообще то интересно как это вообще возможно.
LM>Шаблон в h-файле, h-файл — в проекте. Проект — либа.
Тьфу блин, я то думал что на выходе только .lib и в .lib файл каким то чудом запхан шаблон.
Речь то шла о:

CC>>У меня шаблоны вынесены в .h которые подключаются из главного .h либы.
V>А можно и в либу, если знать как

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

LM>>>А не все ли равно где живет шаблон: в либе или исходниках?
CC>>Мне вообще то интересно как это вообще возможно.
LM>Шаблон в h-файле, h-файл — в проекте. Проект — либа.
Не совсем точно.
В h-файл не обезательно пихать реализацию шаблона. Достаточно токо определение интерфейса.
А в либу можно скомпоновать скока хочешь инстанций:

//Library.cpp
#include "Library.h"
template class MYSUPERTEMPLATE<int>;
template class MYSUPERTEMPLATE<long>;
template class MYSUPERTEMPLATE<float>;
//и т.д.

а далше подключать этот интерфейс шаблона и юзаешь:

#include "Library_processed.h"

void main() {
  MYSUPERTEMPLATE<int> a;
  MYSUPERTEMPLATE<long> b;
  MYSUPERTEMPLATE<float> c;
}

Но это частный случай.
Также есть ограничения, к примеру, определение вложенных шаблонов-методов, наскока мне известно в MSVC, нужно писать на месте:

template<class T>
class MYSUPERTEMPLATE {
  MYSUPERTEMPLATE(); //определён вне тела шаблона
  template<class T_>
  MYSUPERTEMPLATE(const T_&) {
    //blabla
  }
};

Но в общем случае, это зависит от компилятора.

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

CC>У меня все такое собрано в lib.

А как решаются проблемы версий либы и их поддержки в разных проектах?

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

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

CC>>У меня все такое собрано в lib.

G6>А как решаются проблемы версий либы и их поддержки в разных проектах?
В 99% случаев изменения в либе касаются только расширения функциональности либо добавления новой.
Если используемая функциональность меняется (что бывает довольно редко) то проекты в которых она используется просто пересобираются с расчетом на новую либу. В либу попадают только stable версии алгоритмов. Обкатка их идет в виде сурса в том проекте для которого они были написаны, и только после того как сурс полностью отлажен — включается в либу.
Кроме того, существует проект для тестов, который включает в себя тесты почти всего функционала либы и прогоняется при любом ее изменении.

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

CC>>>Мне вообще то интересно как это вообще возможно.
LM>>Шаблон в h-файле, h-файл — в проекте. Проект — либа.
V>Не совсем точно.
V>В h-файл не обезательно пихать реализацию шаблона. Достаточно токо определение интерфейса.
V>А в либу можно скомпоновать скока хочешь инстанций:
V>

V>//Library.cpp
V>#include "Library.h"
V>template class MYSUPERTEMPLATE<int>;
V>template class MYSUPERTEMPLATE<long>;
V>template class MYSUPERTEMPLATE<float>;
V>//и т.д.
V>

Нет. Такой вариант это костыль. А если мне надо MYSUPERTEMPLATE<MySuperPuperClass> и MySuperPuperClass объявлен в проекте к которому подключается либа? Как мне инстанциировать такой шаблон если в .h только интерфейс и ни строчки имплементации?

V>Но в общем случае, это зависит от компилятора.
В общем случае — нафиг нафиг такой геморрой...

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

CC>Нет. Такой вариант это костыль. А если мне надо MYSUPERTEMPLATE<MySuperPuperClass> и MySuperPuperClass объявлен в проекте к которому подключается либа? Как мне инстанциировать такой шаблон если в .h только интерфейс и ни строчки имплементации?
Можно бы было это сделать через какуюнить утилитку перегенерации исходников (препроцессинг), т.е. подставляешь ей каталог с шаблонами и каталог с кодом использующим эти шаблоны, а она сама ищет зависимости и генерирует всё что нужно в виде новых исходников или ещё как..