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

ST>Вот и получается, что во второй половине первого десятилетия 21-го века начинается проект на С.
ST>А вы буст, буст

а у нас разрешенно писать на C и только на vs6 + sp5 (пять а не последний шестой, попытки перейти на vs2005 были, закончились неудачно)
компания не самая последняя в своей области

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

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

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

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

Про свежие версии я не говорил. Несложно зафиксировать версии библиотек, и хранить их на интранетовском сервере (можно даже зафиксировать версии компиляторов, хотя это уже перебор, имхо).

Просто есть управление исходным кодом проекта, а есть управление зависимостями проекта. Совмещать их вместе видимо можно, но что то во мне протестует против этого. Странно, что для С++ нет аналога maven, по-мне удобнейшая концепция. Возможно потому, что в С++ не очень принято реиспользование кода, в каждой более-менее крупной библиотеке свои строки с векторами и смартпоинтерами, и проблема того, что библиотека зависит ещё от десятка других, всплывает нечасто.

ST>Недавно столкнулся с забугорной конторой, которая начала около года назад новый проект, так вот, вся бизнес-логика там на С, и никто не собирается на С++ переходить, не говоря уже за boost. Причем, самое интересное, что контора занимается коммуникациями, именно тем, чем занимается AT&T, т.е. той категорией проектов, ради которых разрабатывался язык его создателем.


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

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

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

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

Я считаю, что нормальный ход в этом случае — сообщить разработчикам, а пока хранить патч к бусту в репозитории. Патч, а не целиком буст, поскольку при новой версии библиотеки будет очень сложно понять, где именно жучок засел.
Поэтому компиляция с бустом сводится к:
1. Скачать оригинальный буст из инета или файлового сервера.
2. Применить патч
3. Откомпилировать либ файлы (На крайняк можно сделать так, что бы их брать с файлового сервера, но разработчики при этом будут ограничены в исправлении и отладке буста).

Это можно сделать в скрипте вида make_boost.bat, который разработчик запускает и через пару минут имеет рабочий буст.
Впрочем, это применимо к любой другой библиотеки.

Я не являюсь фанатиком буста, я — прагматик. Если буст упрощает написание кода — то пожалуйста, если это всего лишь мелкие улучшения или неоправданная сложность — то нафиг надо.
Так, у меня есть код функции с использованием STL в одну строчку. Ее можно заменить на код из буста, но от этого проще он не станет и не будет занимать ноль строчек
С другой стороны я раньше думал, что boost::mpl — для извращенцев, пока не понадобилось подменить тип в зависимости от другого типа. В итоге масштабное изменение в иерархии классов заменилось написанием трех строчек крайне понятного кода.

Буст действительно не применим во всех ситуациях, но и говорить бусту — никогда в жизни, думаю, тоже не стоит.

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

H>Некоторые библиотеки буст — редкостное дерьмо.
Пример можно? Насколько я понимаю, Вы настолько круты, что одной левой напишете лучше? И это будет работать на десятке компиляторов? Вас как зовут? Саттер или Мейерс?

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

vsb>Кстати я не знаю, для С++ нет аналога maven? Там эти проблемы как раз неплохо решены.
Не знаю, какие возможности тебе нужны, но Boost.Build неплох. Основан на Perforce Jam.

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

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

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

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

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

Можно быстро написать скрипт, который будет делать это одной командой.

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

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

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

В Boost библиотеки принимаются после peer review. Ты же согласишься, что это подразумевает хоть какой-то минимальный уровень качества? По крайней мере, там не найдешь недоразумений вроде «Reason

Автор: Roman Odaisky
Дата: 05.06.08

».

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

1. #include <boost/next_prior.hpp>
2. template <class FI> FI next(FI fi) { return ++fi; }
3. Найти и подключить стороннюю библиотеку.

Какой вариант предпочел бы ты?

Или я хочу что-нибудь покрупнее. Например, хочу библиотеку для работы с непересекающимися множествами (это которые disjoint-set). В Boost она есть (а еще где-нибудь?). Чем плохо, если я посмотрю на нее в первую очередь? Т. е., я пойду на www.boost.org/doc/libs, если я найду там то, что нужно, если найденное удовлетворит меня по скорости, ресурсоемкости и прочим параметрам, то возьму и поставлю. Что здесь не так?

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

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

_>Если баг не будет пофиксен в репозитории, то вы фактически создаете форк для буста, а поддерживать его — отдельная кошмарная история.
_>К тому же буст перешел на ускоренный выпуск версий, и за год будет выпущено несколько версий.

Я здесь с нормальными людьми разговариваю или где? Во-первых, какой буст? Я говорил про сторонние библиотеки вообще. Во-вторых, у любого программного проекта есть установленная процедура информирования и исправления багов: как правило -- это баг-репорт, после которого проходит некоторое время (зависит от вменяемости разработчика и живости проекта) и исправления выкладываются либо в публичном репозитории в стабильной ветке, либо в виде патчей, либо в виде свежих дистрибутивов/архивов. В любом случае -- это время. А что в это время делать мне? Я могу либо исправить в своем репозитории, а затем перейти на новую версию библиотеки, либо использовать патчи, а потом перейти на новую версию. Исправление в репозитории проще и надежнее, т.к. не нужно возюкаться со скриптами наката патчей после checkout-ов и update-ов.

_>Я не являюсь фанатиком буста, я — прагматик.

Ахринеть просто: "Использование boost — это отличие новичка от профессионала." Прагматичный подход до мозга костей.

_>Буст действительно не применим во всех ситуациях, но и говорить бусту — никогда в жизни, думаю, тоже не стоит.

Найдите здест того, что сказал бусту "никогда в жизни".

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

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

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

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

Не соглашусь. Последние несколько результатов peer review, которые я читал, говорили о том, что даже для принятых в Boost-библиотек было получено не более 10-20 откликов пользователей. И было еще несколько библиотек, которые не прошли peer review, потому что откликов было еще меньше.

Тем не менее, хотелось бы услышать ответ по поводу таких качеств, как скорость и ресурсоемкость.

RO>Например, я хочу какую-нибудь маленькую функцию, которая будет возвращать итератор, следующий за данным. У меня есть три варианта:

RO>1. #include <boost/next_prior.hpp>
RO>2. template <class FI> FI next(FI fi) { return ++fi; }
RO>3. Найти и подключить стороннюю библиотеку.

RO>Какой вариант предпочел бы ты?

std::advance?

Аналогично, мне нужны средства для работы с сокетами и разделяемой паматью. Первый вариант на рассмотрении -- Boost?
Если нужна криптография -- Boost?
Если нужна работа с XML -- Boost?
Если нужна работа с HTTP -- Boost?
Если нужна работа с матрицами -- Boost?
Если нужен GUI -- Boost?
Если нужна работа с БД -- Boost?
Если нужна сериализация -- опять Boost?

RO>Или я хочу что-нибудь покрупнее. Например, хочу библиотеку для работы с непересекающимися множествами (это которые disjoint-set). В Boost она есть (а еще где-нибудь?). Чем плохо, если я посмотрю на нее в первую очередь? Т. е., я пойду на www.boost.org/doc/libs, если я найду там то, что нужно, если найденное удовлетворит меня по скорости, ресурсоемкости и прочим параметрам, то возьму и поставлю. Что здесь не так?

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

Тут на форуме длинные ветки по поводу STL есть , а вы буст буст ...

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

Сложно что ли посмотреть, что там есть?

E>Аналогично, мне нужны средства для работы с сокетами и разделяемой паматью. Первый вариант на рассмотрении -- Boost?
Да.

E>Если нужна криптография -- Boost?
Нет.

E>Если нужна работа с XML -- Boost?
Нет.

E>Если нужна работа с HTTP -- Boost?
Пока нет.

E>Если нужна работа с матрицами -- Boost?
Да.

E>Если нужен GUI -- Boost?
Пока нет.

E>Если нужна работа с БД -- Boost?
Нет.

E>Если нужна сериализация -- опять Boost?
Да.

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

O>>По поводу нас: думаю многие не используют Буст просто потому, что он им кажется тяжелым (слабенькие спецы).
S>Я слышал что в Японии не рекомендуют использовать классы, т.к. они усложняют код.

Правильно делают. 90% не умеют пользоваться этим инструментом внятно. А 95% — шаблонами. Так что на промышленном уровне вполне внятное ограничение. Результаты налицо.

еще:
1) когда я первый раз заюзал буст — был приятненько удивлен. В каждом проекте нужно писать веловипеды. Удивлен был тем насколько много велосипедов уже реализовано в Библиотеке. Свои Надстройки над Бустом делать легко.

2) Код написанный с использованием буста очень читабелен и компактен. Иногда даже в "священных" спорах C++ vs C# по поводу скорости разработки я утверждаю что если использовать Буст — скорость разработки и отладки на С++ резко возрастает. Думаю это тоже веский аргумент в пользу использования Буста.

прочитав Александреску , решил что неплохо бы еще и ее поюзать. как по мне — весчььь!!!

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

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

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

M>Используем. Легкие вещи (только шаблоны в хидерах) везде, тяжелые (требующие отдельной компиляции бустовских либ) в своих внутренних тулзах.

Аналогично: shared_ptr/array, lexical_cast, tokenizer, string algo, spirit, uBLAS, tuple и т.п.
Требующие компиляции типа filesystem не используем, как правило.

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

E>Тем не менее, хотелось бы услышать ответ по поводу таких качеств, как скорость и ресурсоемкость.

По-разному, как и везде. boost::implicit_cast работает быстро и ресурсов требует мало :-)

RO>>Например, я хочу какую-нибудь маленькую функцию, которая будет возвращать итератор, следующий за данным. У меня есть три варианта:
RO>>1. #include <boost/next_prior.hpp>
RO>>2. template <class FI> FI next(FI fi) { return ++fi; }
RO>>3. Найти и подключить стороннюю библиотеку.
RO>>Какой вариант предпочел бы ты?
E>std::advance?
Он ссылку принимает.

E>Аналогично, мне нужны средства для работы с сокетами и разделяемой паматью. Первый вариант на рассмотрении -- Boost?
E>Если нужна {криптография,сериализация,работа с {XML,HTTP,матрицами,БД}} -- Boost?

Ну да. Увидев, что части требуемого там нет, я пойду за нею в гугл.

RO>>Или я хочу что-нибудь покрупнее. Например, хочу библиотеку для работы с непересекающимися множествами (это которые disjoint-set). В Boost она есть (а еще где-нибудь?). Чем плохо, если я посмотрю на нее в первую очередь? Т. е., я пойду на www.boost.org/doc/libs, если я найду там то, что нужно, если найденное удовлетворит меня по скорости, ресурсоемкости и прочим параметрам, то возьму и поставлю. Что здесь не так?

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

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

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

RO>>>Например, я хочу какую-нибудь маленькую функцию, которая будет возвращать итератор, следующий за данным. У меня есть три варианта:
RO>>>1. #include <boost/next_prior.hpp>
RO>>>2. template <class FI> FI next(FI fi) { return ++fi; }
RO>>>3. Найти и подключить стороннюю библиотеку.
RO>>>Какой вариант предпочел бы ты?
E>>std::advance?
RO>Он ссылку принимает.

Ох ё! Теперь сразу становится понятно, для чего мне нужно добавлять в свой проект зависимость на 25Mb. Только для того, чтобы не писать самому функцию next() или (что, вероятно, совсем плохо) n = c; ++n;

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

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

RO>В любом случае, перед тобой будет выбор из нескольких вариантов, которые нужно будет испытать.

Передо мной да -- будет выбор. Поскольку я сначала соберу список претендентов, а затем буду их оценивать.

RO>Я только и предлагаю начать с Boost, если он там представлен.

Похоже, что мне нужно надеятся, чтобы и ты, и skeptik_, и другие любители Boost-а поступали так и дальше.

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

_>>Использование boost — это отличие новичка от профессионала.
E>Все остальное не вижу смысла комментировать, поскольку ведется противопоставление Boost-а каким-то абстракным самописным велосипедам, о которых я вообще не говорил.

Наблюдал не раз следующий путь становления:

1) Не знает ни о STL ни о Boost
2) Узнает о STL и кидается все писать с максимальным использованием STL везде где ни попадя.
3) Получает кадавров с трехэтажными шаблонами в которых сам часто путается — какой же тут функтор вызывается из этого трехэтажного бинда? Фанатизм начинает остывать.
4) Понимает что STL не панацея и умеренно использует его только там, где надо.
5) Узнает о Boost и повизгивая от восторга кидается применять все что только можно везде где только можно.
6) Получает жутких монстров с еще более запутанной структурой, с regex на каждый чих и компилящихся часами — фанатизм быстро проходит.
7) Понимает что и Boost не идеален и начинает использовать только то, что реально необходимо и только там где надо.
8) Пишет свои алгоритмы, которых нет в STL\Boost либо готовые версии которых не устраивают по каким либо причинам.