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

_>Использование boost — это отличие новичка от профессионала.

Пять балов!

Все остальное не вижу смысла комментировать, поскольку ведется противопоставление Boost-а каким-то абстракным самописным велосипедам, о которых я вообще не говорил.

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

E>>У нас принята система, в которой использованные в проектах 3rd-party библиотеки размещаются в репозитории. Это дает возможность извлечь конкретную версию конкретного проекта с теми версиями сторонних библиотек, которые использовались на момент фиксации версии. А когда делаешь checkout какого-нибудь проекта, а он затем начинает тянуть за собой десятки мегабайт архивов, которые затем еще и долго и мучительно компилируются, то начинаешь ценить минимализм зависимостей.

_>Третьесторонние либы не поддарются версионному контролю.

Как раз хорошая ссылка о невозможном:

Я отказываюсь признавать слово "невозможно". Я не знаю никого, кто бы обладал такими глубокими познаниями, чтобы утверждать, что возможно, а что нет. Большой опыт, добротная техническая подготовка должны, по идее, расширять кругозор и ограничивать количество невозможностей и невероятностей. К большому сожалению, это не так. В большинстве случаев техническое образование и так называемый опыт служат лишь тому, чтобы продемонстрировать последствия ошибок и неудавшихся экспериментов. Вместо того чтобы извлекать пользу и учиться на совершенных ошибках, люди воспринимают их как непреодолимое препятствие к прогрессу. Если кто-то, мнящий себя большим авторитетом, категорично заявляет: "Это невозможно", — стройный хор бездумных последователей вторит ему: "Это невозможно".

Поддаются версионному контролю. А иногда даже приходится править ошибки самому и хранить исправленную версию до очередного релиза библиотеки.

_>При необходимости есть в интернете репозитории с необходимыми версиями. Для размещения либ достаточно файлового сервера, на котором с исходиниками можно и разместить откомпилированные lib файлы. А превращать хранилище исходных кодов в файловую помойку не вижу смысла.

Не вижу смысла делать какие-то инструменты для закачки tar.bz2 или других архивов из Интернета, или взятия файлов с файл-сервера, когда можно использовать механизм svn:externals:

ace_lib_distrib http://***/svn/ace/tags/distribs/5.6.5/ace_lib_distrib
oracle_oci      http://***/svn/otl_4/tags/oracle.instantclient-10.2.0.4.0
otl4            http://***/svn/otl_4/tags/4.0.173/dev/otl4
pcre            http://***/svn/regex/pcre/tags/mxx_ru/7.7/dev/pcre

_>Тогда уже туда надо запихнуть образы тестовых серверов на момент тестирования, базы данных от заказчиков с багами и кучу всякого мусора .

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

_>Boost — это почти стандарт. Много библиотек от туда попадут в следующий стандарт С++ и хотите вы этого или нет, но у всех разработчиков будет возможность его использовать в новых компиляторах за пару лет.

Это вовсе не повод бросаться использовать Boost сейчас. Особенно, если уже давно были найдены альтернативы Boost-овским библиотекам.

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

E>Поддаются версионному контролю. А иногда даже приходится править ошибки самому и хранить исправленную версию до очередного релиза библиотеки.
А почему бы этот багфикс сразу в буст не закоммитить?

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

E>>Поддаются версионному контролю. А иногда даже приходится править ошибки самому и хранить исправленную версию до очередного релиза библиотеки.
_>А почему бы этот багфикс сразу в буст не закоммитить?

Ё! Опять буст! И вне буста есть жизнь.

Есть библиотеки, которые распространяются в виде архивов (pcre, otl) у которых вообще нет публичных репозиториев. Единственный способ внесения изменений в них -- это оформление баг-репорта или передача патча разработчику. Есть библиотеки, у которых есть репозитории (ace), но доступ на запись в него имеет очень ограниченное количество commit-еров. В таких случаях опять же еднственным способом для обычного пользователя является баг-репорт с добавленным в него патчем.

skeptik_ пишет:
>
> Z>Многие не используют Буст потому что они понимают, /что чтоб юзать
> Буст нужен очень неплохой уровень знания языки и теории/ *у всех
> программистов в компании*, что очень редко достижимо. Нафиг-нафиг.
> Для чего? Чтобы lexical_cast или shared_ptr заюзать?
Удивлен? Но да.

eao197 пишет:
>
> _>А почему бы этот багфикс сразу в буст не закоммитить?
>
> Ё! Опять буст! И вне буста есть жизнь.
>
> Есть библиотеки, которые распространяются в виде архивов (pcre, otl) у
> которых вообще нет публичных репозиториев. Единственный способ внесения
> изменений в них -- это оформление баг-репорта или передача патча
> разработчику. Есть библиотеки, у которых есть репозитории (ace), но
> доступ на запись в него имеет очень ограниченное количество commit-еров.
> В таких случаях опять же еднственным способом для обычного пользователя
> является баг-репорт с добавленным в него патчем.
Т.е. вы сами себе придумываете проблемы, а потом долго и (без)успешно с
ними боретесь?
Мне кажется, что твое отношение к бусту сродни тому, какое отношение у
тупоконечнеков было к яйцу.

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

E>Не вижу смысла делать какие-то инструменты для закачки tar.bz2 или других архивов из Интернета, или взятия файлов с файл-сервера, когда можно использовать механизм svn:externals:

Не все используют SVN для разработки, и не все библиотеки используют SVN для разработки.

E>Это вовсе не повод бросаться использовать Boost сейчас. Особенно, если уже давно были найдены альтернативы Boost-овским библиотекам.

Коней на переправе не меняют, это верно, но если нужна какая-то новая библиотека, по-моему, есть смысл поискать в первую очередь в Boost, а потом уже и в других местах. Логистические проблемы Boost мне не представляются сколько-нибудь значимыми.

RO>Коней на переправе не меняют, это верно, но если нужна какая-то новая библиотека, по-моему, есть смысл поискать в первую очередь в Boost, а потом уже и в других местах. Логистические проблемы Boost мне не представляются сколько-нибудь значимыми.

Посмотрел boost regex и в ужасе перешел на TRE.

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

Прекрасный ответ.

Добавлю еще, что использование boost в компании (или на проекте) предусматривает общий высокий уровень владения C++. Не несколько гуру (или фанатов), а именно большинство.
Иначе время на разработку только увеличится.

Так что, пока boost не вошел в стандарт, пока не появилась критическая масса программистов (скажем, процентов 80), владеющих boost — использовать boost на проектах не только не выгодно, но и опасно.

Заявления типа:
— там где я, там и boost
— считаю своим долгом первым делом поставить boost
— не представляю себе машины разработчика без boost
являются или фанатичными или следующими моде или просто глупыми.

И почему идет противопоставление — "использовать boost" или "изобретать велосипед" (далее древние шутки про квадратные колеса)?
Другие варианты тоже есть.

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

N>Тут вот ради забавы, спросил некоторых товарищей по разным конторам, boost используете?
N>ответ у всех — нет

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

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

E>>Не вижу смысла делать какие-то инструменты для закачки tar.bz2 или других архивов из Интернета, или взятия файлов с файл-сервера, когда можно использовать механизм svn:externals:

RO>Не все используют SVN для разработки,

Я всего лишь рассказываю о том, что используется у нас. И о том, почему 3rd-party библиотеки у нас лежат в репозиториях.

RO>и не все библиотеки используют SVN для разработки.

А это ты расскажи тому орлу, кто советует при нахождении бага в сторонней библиотеке сразу же править баг в репозитории этой библиотеки.

E>>Это вовсе не повод бросаться использовать Boost сейчас. Особенно, если уже давно были найдены альтернативы Boost-овским библиотекам.

RO>Коней на переправе не меняют, это верно, но если нужна какая-то новая библиотека, по-моему, есть смысл поискать в первую очередь в Boost, а потом уже и в других местах.

Подобный подход и есть свидетельство религиозного ослепления. Искать нужно сразу несколько альтернативных библиотек и сравнивать их достоинства и недостатки более-менее объективно. И только при прочих равных вариант из Boost-а может для кого-то быть предпочтительным именно из-за Boost-а.

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

V>Мне кажется, что твое отношение к бусту сродни тому, какое отношение у
V>тупоконечнеков было к яйцу.

У меня спокойное отношение к бусту -- на данный момент мне из него ничего не нужно. А вот отношение к оголтелым бустоманам такое же, как у атеиста к религиозным фанатиками.

И таки мне интересно -- если я, не будучи контрибутором в буст, нахожу в одной из библиотек буста баг, как мне закомитить исправление в репозиторий буста?

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

E>У нас принята система, в которой использованные в проектах 3rd-party библиотеки размещаются в репозитории. Это дает возможность извлечь конкретную версию конкретного проекта с теми версиями сторонних библиотек, которые использовались на момент фиксации версии. А когда делаешь checkout какого-нибудь проекта, а он затем начинает тянуть за собой десятки мегабайт архивов, которые затем еще и долго и мучительно компилируются, то начинаешь ценить минимализм зависимостей.

Почему бы просто не держать актуальный HOWTO Prepare Build Environment в проекте или в вики? Вроде ничего сложного нет, скачайте буст с 192.168.1.1/files/boost-1.34.tar.bz2, распакуйте, добавьте в environment variable INCLUDE (или что то подобное) и всё. У тех, кто с проектом работает, всё давно настроено, те, кто пришёл недавно, потратят некоторое время, но это ведь происходит достаточно редко. Если надо пропатчить — держать .patch-файлы где-нибудь, патч это одна команда. Можно даже скрипты написать, если сильно хочется автоматизировать. Как ни крути, я считаю, что система контроля версий нужна только для контроля версий.

А смысла выдирать куски из буста я вообще не понимаю. Он же компилируется именно теми кусками, которые используются в проекте, ни больше ни меньше.

Кстати я не знаю, для С++ нет аналога maven? Там эти проблемы как раз неплохо решены.

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

RO>>по-моему, есть смысл поискать в первую очередь в Boost, а потом уже и в других местах.

E>Подобный подход и есть свидетельство религиозного ослепления. Искать нужно сразу несколько альтернативных библиотек и сравнивать их достоинства и недостатки более-менее объективно. И только при прочих равных вариант из Boost-а может для кого-то быть предпочтительным именно из-за Boost-а.

Библиотеки Boost хорошо документированы, хорошо поддерживаются, единообразны, с простой лицензией. Если в Boost есть что-нибудь, что подходит по всем параметрам, зачем искать дальше?

vsb>А смысла выдирать куски из буста я вообще не понимаю. Он же компилируется именно теми кусками, которые используются в проекте, ни больше ни меньше.

Смысл в том, что любой человек взяв сорцы из репозитария должен собрать аппликейшен без проблем. А теперь рассмотрим пример, что репозитарий в США на весьма нагруженном серваке, каналы связи не так быстры как хотелось-бы. Сколько времени займет чекаут проекта с такими зависимостями?

У меня папка Work занимает примерно пять гигов — в разных проектах разные версии бустов, вхворков, кути и прочих монстроидальных либ. Причем часто приложение — тупое окошко и два диалога на одной платформе. Появление очередной мелкой китайской утилиты с очередной версией буста меня совсем не радует.

Буст уродлив прежде всего своей монолитностью. Проще скопировать 100Mb кода чем разбираться в зависимостях

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

N>Тут вот ради забавы, спросил некоторых товарищей по разным конторам, boost используете?
N>ответ у всех — нет
N>Немного конфузит.
N>А у других как?

У нас используется smart pointers, regex, function, bind, crc, tuple мож еще че-то
А вообще, зависит от конторы и людей.
Мне было просто добавить использование boost в проект, на котором работает несколько человек. Инертность команды нулевая. Посмотрели, во, классная штука, которая способна нам помочь. Давай использовать. Но в крупных проектах на это может накладывать отпечаток инерционность, как проекта (что реже) так и команды (это чаще).

Недавно столкнулся с забугорной конторой, которая начала около года назад новый проект, так вот, вся бизнес-логика там на С, и никто не собирается на С++ переходить, не говоря уже за boost. Причем, самое интересное, что контора занимается коммуникациями, именно тем, чем занимается AT&T, т.е. той категорией проектов, ради которых разрабатывался язык его создателем.
Причем была попытка убедить тамошних гуру о переходе на С++ (в некоторых кусках проекта), ничего не вышло. Ответ как всегда прост, зачем что-то менять, если и так мы двигаемся вперед, используя С? К сожалению есть и объективные причины, по которым переход на новый язык/библиотеку в крупноп проекте довольно сложен, ведь преимущества от перехода на что-то новое, пусть и лучшее требует время, и первый блин будет комом. Т.е. выгода будет, но не завтра, а, скорее, после завтра. А этого, как раз никому и не нужно...
Причем сами же плюются на сложность сопровождения и эволюции. Там куча goto (даже в макросах есть goto "моя метка"), и функции на несколько ТЫСЯЧ строк!!! Модель освобождения ресурсов типа кто-нить должен освободить (память выделена в одной функции освобождается в ПЯТИ различных местах, в зависимости от успешности выполнения последующих функций) и т.д.
Складывается впечатление, что одни зарубежные авторы пишут книги для постсоветского пространства, т.к. тамошние "спецы" эти книги просто не читают.
Вот и получается, что во второй половине первого десятилетия 21-го века начинается проект на С.
А вы буст, буст

RO>Библиотеки Boost хорошо документированы, хорошо поддерживаются, единообразны, с простой лицензией. Если в Boost есть что-нибудь, что подходит по всем параметрам, зачем искать дальше?

Это мантра-заклинание?
Некоторые библиотеки буст — редкостное дерьмо.
Затем что часто есть на порядок более простые и качественные решения

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

RO>Библиотеки Boost хорошо документированы, хорошо поддерживаются, единообразны, с простой лицензией. Если в Boost есть что-нибудь, что подходит по всем параметрам, зачем искать дальше?

Скорость? Ресурсоемкость? Распространенность? Возраст? Количество пользователей/успешных внедрений?

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

vsb>Почему бы просто не держать актуальный HOWTO Prepare Build Environment в проекте или в вики?

Почему бы просто не давать программистам возможноть получить готовый build environment одной командной?

vsb>Вроде ничего сложного нет, скачайте буст с 192.168.1.1/files/boost-1.34.tar.bz2, распакуйте, добавьте в environment variable INCLUDE (или что то подобное) и всё. У тех, кто с проектом работает, всё давно настроено, те, кто пришёл недавно, потратят некоторое время, но это ведь происходит достаточно редко. Если надо пропатчить — держать .patch-файлы где-нибудь, патч это одна команда. Можно даже скрипты написать, если сильно хочется автоматизировать.

В идеальном мире идеальные программисты пишут идеальные программы и идеальную документацию к ним.

vsb>Как ни крути, я считаю, что система контроля версий нужна только для контроля версий.

Вам этого никто не запрещает.

vsb>А смысла выдирать куски из буста я вообще не понимаю.

А я не понимаю смысла выкачивания 25Mb tar.bz2 для возможности использования boost::shared_ptr и boost::bind.

vsb>Кстати я не знаю, для С++ нет аналога maven?

Нет.

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

vsb>>Как ни крути, я считаю, что система контроля версий нужна только для контроля версий.

ты не сталкивался с тем, что прикладнина неправильно работает с более свежей версией той же библиотеки?