Походил тут по собеседованиям, почти везде НЕ используют boost.
В прошлом проекте (на работе) я насильно привил boost и вроде никто не жаловался, в своих же проектах без boost никуда.
Либе уже 1.50 скоро исполниться, а аргумент у всех один и тот же... "Если програмер который писал на boost уйдет в отпуск или уволится этот код будет сложно поддерживать другому програмеру".
А на вопрос ну так что лучше писать свои велосипеды а потом там ловить баги, отвечают как то невнятно.
В одной конторе спросили: "А если у вас забрать boost вы сможете писать код?", блин странные вопросы люди задают.

Я вот реально не понимаю, квалификации кадров не хватает что бы почитать документацию, которая кстати довольно хорошая, или просто лень?

Причин много, наиболее популярные:

— Недостаточно квалифицированные сотрудники / большая часть сотрудников, которые не то, что в boost, но и в STL разобраться не могут
— Старый код, который уже вовсю использует свои велосипеды (собственные векторы, списки, парсинг параметров, чтение конфигурационных файлов и т.д.). Добавлять туда boost уже просто не хочется — зачем что-то менять, если оно итак работает?
— Руководство не видит явных плюсов в случае использования boost и считает, что это нужно лишь для красоты кода
— В команде есть программист, мнение которого все очень уважают, и который говорит "boost не нужен — написан криво, интерфейс ужасный, напишем свой!"
— В случае старта нового проекта — "Зачем, если до этого и без него прекрасно обходились"?
— "Ещё чего, решили тут новомодные штуки добавлять! Пишем на ANSI C!"

N>Походил тут по собеседованиям, почти везде НЕ используют boost.

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

1) Boost неоднороден по качеству, некоторые либы блестящи, некоторые без ужаса смотреть сложно
2) Boost не создает видимость цельного продукта, как например Qt, нет единого стиля и видения
3) Boost был крайне монолитен. Попытка заюзать класс Date (не помню, давно было) привела к 20Mb зависимостей и резкому увеличению времени компилляции
4) Boost тормознуто компилится, вот с Qt в этом плане лучше
5) Boost страдает переусложнизмом и синдромом читателей книги Александреску. давайте сделаем так, чтобы никто понять не мог чего мы ваще написали. Давайте сдесь забахаем паттерны и побольше
6) Злоупотребление шаблонами. Qt использует шаблоны где требуется. Boost использует шаблоны везде.
7) Boost не создает желания использовать его в проектах когда фреймворк не навязывается. Не цепляет

N>Я вот реально не понимаю, квалификации кадров не хватает что бы почитать документацию, которая кстати довольно хорошая, или просто лень?
потому что boost содержит невероятное количество костылей для того чтобы собираться хотя бы на паре-тройке более-менее распространенных компиляторов c++
поищи например сколько там BOOST_WORKAROUND в исходниках. Крайний раз когда я смотрел было 540 файлов, бгг

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

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

N>Я вот реально не понимаю, квалификации кадров не хватает что бы почитать документацию, которая кстати довольно хорошая, или просто лень?

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

for ( size_t i=0;i<Arr.Size; i++ )
  Делать что-то();

Пишут вызовы библиотек думая что там нет никаких циклов и вообще они быстро работают.

Ну исключение конечно составляет GUI и особенно в свете переносимости.

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

PMT>Причин много, наиболее популярные:

PMT>- Недостаточно квалифицированные сотрудники / большая часть сотрудников, которые не то, что в boost, но и в STL разобраться не могут
PMT>- Старый код, который уже вовсю использует свои велосипеды (собственные векторы, списки, парсинг параметров, чтение конфигурационных файлов и т.д.). Добавлять туда boost уже просто не хочется — зачем что-то менять, если оно итак работает?
PMT>- Руководство не видит явных плюсов в случае использования boost и считает, что это нужно лишь для красоты кода
PMT>- В команде есть программист, мнение которого все очень уважают, и который говорит "boost не нужен — написан криво, интерфейс ужасный, напишем свой!"
PMT>- В случае старта нового проекта — "Зачем, если до этого и без него прекрасно обходились"?
PMT>- "Ещё чего, решили тут новомодные штуки добавлять! Пишем на ANSI C!"

Добавлю.

Бывает пишут на более высокоуровневых языках чем C++ большую часть системы, а C++ только в определенных местах (где тормозит, где либа хорошая есть и т.д.). Boost во многом добавляет фичи, которые есть в стандартной библиотеке основного языка, в C++. Сама же библиотека boost в стандарт не входит — это ещё одна из причин.
Плюс есть люди, которые считают, что исключения — зло. Исключения активно используются в бусте.
То же самое с шаблонами (лучше макросы ).

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

Вот у меня проект работает на 32 процессорном сервере. Вы когда-нибудь видели 32 процессорную машину нагруженную хотя-бы наполовину? При писании на голом С/С++ время разработки увеличивается до 5-10 раз. оптимизация зачастую наносит куда больше вреда, чем пользы.

"Медленный код" — это любимая фраза преждевременных оптимизаторов. Мне плевать на "медленный" код, Time-To-Market куда важнее.

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

N>Походил тут по собеседованиям, почти везде НЕ используют boost.
когда буст станет стандартом, как stl, тогда его и использовать везде будут и проверять знания на собеседованиях. А пока что он ничем не лучше существующих внутри компании библиотек, даже наоборот. Существующие либы учитывают множество нюансов конкретного продукта, на выявление и исправление которых потрачено прилично человеко\часов. Простая замена на буст повлечет за собой кроме призрачного будущего удобства трату минимум тех-же самых человеко\часов на рефикс этих проблем. Зачем это нужно? В подавляющем большинстве проектов незачем. А там где нужно — используют.

ps: желание сразу применить буст при приходе на работу — это синдром фатального недостатка

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

N>>Походил тут по собеседованиям, почти везде НЕ используют boost.

H>Boost противоречив и неоднозначен.
H>Попробую высказать свое скромное мнение, оно может отличаться от мнения редакции
Ну я согласен на 90% просто дам комментарий.
На мой взгляд, буст очень похож на плюсы. Он громоздкий, не слишком удобный, требуют кучу часов на освоение, но когда ты освоился, ты можешь очень быстро делать кучу вещей, которые с никаким другим инструментом делать не сможешь. К бусту рано или поздно приходит любой плюсовик, но остаются немногие. Кто остается, то сначала начинает читать, потом может переписать часть библиотеки под свою задачу, если потребуется. Может служить косвенным признаком квалификации программиста. С другой стороны, есть проблема, что многие очень любят переписывать буст для своих конкретных нужд при первой же ситуации, когда они чего-то в кодн не понимают(я в свое время под себя архив переписал, для меня получилось лучше и менее тормознуто и без стлных хидеров в заголовках ), но тут надо просто себя сдерживать. Хотя я работал на одну контору, ведущий программист в которой переписал половину буста и вся контора этим гордилась. Потом программиста не стало, что сейчас с ними не знаю.


H>1) Boost неоднороден по качеству, некоторые либы блестящи, некоторые без ужаса смотреть сложно
Кстати, да. Но это начинаешь понимать с некоторого своего уровня, фанаты буста чаще либо обожествляют его
H>2) Boost не создает видимость цельного продукта, как например Qt, нет единого стиля и видения
Да нет, бустовый стиль достаточно
H>3) Boost был крайне монолитен. Попытка заюзать класс Date (не помню, давно было) привела к 20Mb зависимостей и резкому увеличению времени компилляции
Да все нужные вещи в хидерах, если видишь цпп, то класс чаще всего какашка.
H>4) Boost тормознуто компилится, вот с Qt в этом плане лучше
Весь буст тормознуто конечно, но зачем он весь нужен? Кутя тормознуто работает, во всяком случае работала пару лет назад.
H>5) Boost страдает переусложнизмом и синдромом читателей книги Александреску. давайте сделаем так, чтобы никто понять не мог чего мы ваще написали. Давайте сдесь забахаем паттерны и побольше
Нет, просто стараются дать как можно более гибкое решение. Переусложнизма там особого нет. В некоторых частях есть долбодятлизм, когда автор не умеет использовать подходы, которые использует, но типа хочет всем показать какой он крутой. Но таких мест очень мало.
H>6) Злоупотребление шаблонами. Qt использует шаблоны где требуется. Boost использует шаблоны везде.
H>7) Boost не создает желания использовать его в проектах когда фреймворк не навязывается. Не цепляет
Спорно когда к нему привыкаешь без него дико неудобно. Также как и QT С другой стороны, к нему очень быстро привыкаешь и жить без него сложно. Я помню, как один мой сотрудник пытался протащить буст для компиляции под устройство. Так-то он нормальный парень, а тут что-то страшно ему без буста стало.

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

N>Походил тут по собеседованиям, почти везде НЕ используют boost.

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

Например в boost::serialization некоторые синглтоны реализованы как статические объекты. Обычно это разумный подход, но если сериализация одинаковых типов делается и в экзешнике, и в статической библиотеке то могут возникнуть трудности. Эту багу можно забороть, но возникнут сложности в других случаях (AFAIR с динамической библиотекой). Так что универсального решения нет, поэтому авторы библиотеки вынуждены выбирать какой-то один вариант, который устраивает большинство, но конечно не всех.
Повторю ещё раз — если в конторе запрещают использовать буст вообще, то это очень дурной знак.

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

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

H>Вот у меня проект работает на 32 процессорном сервере. Вы когда-нибудь видели 32 процессорную машину нагруженную хотя-бы наполовину? При писании на голом С/С++ время разработки увеличивается до 5-10 раз. оптимизация зачастую наносит куда больше вреда, чем пользы.

Вы знаете я вот тоже как раз высокопроизводительными штуками занимаюсь. И давно уже — больше 10 лет точно. И вот сравнительно недавно пришел к выводу, что крайне ... еще раз крайне мало задач поддается качественному распараллеливанию. В среднем в лучшем случае удается получить выигрыш в 20-30%. Но процессора при этом загруженны на 100%. Скажете значит плохо распараллеливали, да плохо то такие современные алгоритмы. Видел много решений где делается распараллеливание ради самого только распараллеливания.

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

Поэтому сразу говорю, это вот такое мое вымученное за годы мнение. Так что спорить не буду.

H>"Медленный код" — это любимая фраза преждевременных оптимизаторов. Мне плевать на "медленный" код, Time-To-Market куда важнее.

Возможно. Но задача не всегда так стоит. А часто стоит так что надо либо оптимально либо ни как не надо.

JM>Вы знаете я вот тоже как раз высокопроизводительными штуками занимаюсь. И давно уже — больше 10 лет точно. И вот сравнительно недавно пришел к выводу, что крайне ... еще раз крайне мало задач поддается качественному распараллеливанию. В среднем в лучшем случае удается получить выигрыш в 20-30%. Но процессора при этом загруженны на 100%. Скажете значит плохо распараллеливали, да плохо то такие современные алгоритмы. Видел много решений где делается распараллеливание ради самого только распараллеливания.

Выдача HTTP ответов поддается распараллеливанию очень хорошо. Hi-Load services как раз неплохо параллеляться по причине независимости входящих запросов. Ну да, мьютексы и локи, долгое ожидание на локах — но это неизбежность на многопроцессорных системах.

H>>5) Boost страдает переусложнизмом и синдромом читателей книги Александреску. давайте сделаем так, чтобы никто понять не мог чего мы ваще написали. Давайте сдесь забахаем паттерны и побольше
D>Нет, просто стараются дать как можно более гибкое решение. Переусложнизма там особого нет. В некоторых частях есть долбодятлизм, когда автор не умеет использовать подходы, которые использует, но типа хочет всем показать какой он крутой. Но таких мест очень мало.

Сравним код:

Node.js — 8 строк

var net = require('net');

var server = net.createServer(function (socket) {
  socket.write('Echo server\r\n');
  socket.pipe(socket);
});

server.listen(1337, '127.0.0.1');

Аналог на Boost ASIO — 137 строк

//
// async_tcp_echo_server.cpp
// ~~~~~~~~~~~~~~~~~~~~~~~~~
//
// Copyright (c) 2003-2012 Christopher M. Kohlhoff (chris at kohlhoff dot com)
//
// Distributed under the Boost Software License, Version 1.0. (See accompanying
// file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
//

#include <cstdlib>
#include <iostream>
#include <boost/bind.hpp>
#include <boost/asio.hpp>

using boost::asio::ip::tcp;

class session
{
public:
  session(boost::asio::io_service& io_service)
    : socket_(io_service)
  {
  }

  tcp::socket& socket()
  {
    return socket_;
  }

  void start()
  {
    socket_.async_read_some(boost::asio::buffer(data_, max_length),
        boost::bind(&session::handle_read, this,
          boost::asio::placeholders::error,
          boost::asio::placeholders::bytes_transferred));
  }

private:
  void handle_read(const boost::system::error_code& error,
      size_t bytes_transferred)
  {
    if (!error)
    {
      boost::asio::async_write(socket_,
          boost::asio::buffer(data_, bytes_transferred),
          boost::bind(&session::handle_write, this,
            boost::asio::placeholders::error));
    }
    else
    {
      delete this;
    }
  }

  void handle_write(const boost::system::error_code& error)
  {
    if (!error)
    {
      socket_.async_read_some(boost::asio::buffer(data_, max_length),
          boost::bind(&session::handle_read, this,
            boost::asio::placeholders::error,
            boost::asio::placeholders::bytes_transferred));
    }
    else
    {
      delete this;
    }
  }

  tcp::socket socket_;
  enum { max_length = 1024 };
  char data_[max_length];
};

class server
{
public:
  server(boost::asio::io_service& io_service, short port)
    : io_service_(io_service),
      acceptor_(io_service, tcp::endpoint(tcp::v4(), port))
  {
    start_accept();
  }

private:
  void start_accept()
  {
    session* new_session = new session(io_service_);
    acceptor_.async_accept(new_session->socket(),
        boost::bind(&server::handle_accept, this, new_session,
          boost::asio::placeholders::error));
  }

  void handle_accept(session* new_session,
      const boost::system::error_code& error)
  {
    if (!error)
    {
      new_session->start();
    }
    else
    {
      delete new_session;
    }

    start_accept();
  }

  boost::asio::io_service& io_service_;
  tcp::acceptor acceptor_;
};

int main(int argc, char* argv[])
{
  try
  {
    if (argc != 2)
    {
      std::cerr << "Usage: async_tcp_echo_server <port>\n";
      return 1;
    }

    boost::asio::io_service io_service;

    using namespace std; // For atoi.
    server s(io_service, atoi(argv[1]));

    io_service.run();
  }
  catch (std::exception& e)
  {
    std::cerr << "Exception: " << e.what() << "\n";
  }

  return 0;
}

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

D>На мой взгляд, буст очень похож на плюсы. Он громоздкий, не слишком удобный, требуют кучу часов на освоение, но когда ты освоился, ты можешь очень быстро делать кучу вещей, которые с никаким другим инструментом делать не сможешь. К бусту рано или поздно приходит любой плюсовик, но остаются немногие. Кто остается, то сначала начинает читать, потом может переписать часть библиотеки под свою задачу, если потребуется. Может служить косвенным признаком квалификации программиста. С другой стороны, есть проблема, что многие очень любят переписывать буст для своих конкретных нужд при первой же ситуации, когда они чего-то в кодн не понимают(я в свое время под себя архив переписал, для меня получилось лучше и менее тормознуто и без стлных хидеров в заголовках ), но тут надо просто себя сдерживать. Хотя я работал на одну контору, ведущий программист в которой переписал половину буста и вся контора этим гордилась. Потом программиста не стало, что сейчас с ними не знаю.

Странно. Ведь все эти миллионы шаблонов сделаны для того, чтобы нужные классы можно было адаптировать под свою задачу. Неужели это всё впустую? Или требует настолько большой квалификации, что многим проще переписать, чем разобраться?

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

vsb>Странно. Ведь все эти миллионы шаблонов сделаны для того, чтобы нужные классы можно было адаптировать под свою задачу. Неужели это всё впустую? Или требует настолько большой квалификации, что многим проще переписать, чем разобраться?

!!!! Как это требует настолько большой квалификации чтобы разобраться, то есть если квалификация низкая то придется переписать!

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

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

D>>На мой взгляд, буст очень похож на плюсы. Он громоздкий, не слишком удобный, требуют кучу часов на освоение, но когда ты освоился, ты можешь очень быстро делать кучу вещей, которые с никаким другим инструментом делать не сможешь. К бусту рано или поздно приходит любой плюсовик, но остаются немногие. Кто остается, то сначала начинает читать, потом может переписать часть библиотеки под свою задачу, если потребуется. Может служить косвенным признаком квалификации программиста. С другой стороны, есть проблема, что многие очень любят переписывать буст для своих конкретных нужд при первой же ситуации, когда они чего-то в кодн не понимают(я в свое время под себя архив переписал, для меня получилось лучше и менее тормознуто и без стлных хидеров в заголовках ), но тут надо просто себя сдерживать. Хотя я работал на одну контору, ведущий программист в которой переписал половину буста и вся контора этим гордилась. Потом программиста не стало, что сейчас с ними не знаю.

vsb>Странно. Ведь все эти миллионы шаблонов сделаны для того, чтобы нужные классы можно было адаптировать под свою задачу. Неужели это всё впустую? Или требует настолько большой квалификации, что многим проще переписать, чем разобраться?
1) Смочь написать что-то наподобие буста и в том же стиле многим кажется крутым.
2) Буст писали не боги, где-то есть явные косяки (та же сериализация).

KP>Но, тут есть одно но. В ряде проектов, которые, к примеру, потом надо будет собрать под экзотическую железяку, использовать BOOST просто нельзя.
Экзотические это какие? Если есть компилятор С++ совместимый, то почему нет? Под тот же arm всё работает. Да чего уж там под древний как г. мамонта "Эльбрус 90 микро" и то работает. А на сертификацию отправляется исходный код продукта со всеми зависимостями.

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


N>>Я вот реально не понимаю, квалификации кадров не хватает что бы почитать документацию, которая кстати довольно хорошая, или просто лень?
R>потому что boost содержит невероятное количество костылей для того чтобы собираться хотя бы на паре-тройке более-менее распространенных компиляторов c++

Ну да, это ж не библиотека на 3kb кода, это большой сборник библиотек, кончено же там будут воркэраунды для компиляторов и не потому что boost кривой а потому что компиляторы разные. У меня boost собирается на win/osx/ios и пока особых проблем не было. Но свою задачу ускорение разработки он выполняет.

R>поищи например сколько там BOOST_WORKAROUND в исходниках. Крайний раз когда я смотрел было 540 файлов, бгг

Вам бы стало легче если бы там не было ни одного workaround и вместо этого boost собирался только конкретным компилятором только под конкретную платформу. Наверно аргументом тогда было бы — он enviroument специальный требует, зачем мне холодильник если я не курю.

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

N>Походил тут по собеседованиям, почти везде НЕ используют boost.
N>В прошлом проекте (на работе) я насильно привил boost и вроде никто не жаловался, в своих же проектах без boost никуда.
N>Либе уже 1.50 скоро исполниться, а аргумент у всех один и тот же... "Если програмер который писал на boost уйдет в отпуск или уволится этот код будет сложно поддерживать другому програмеру".
N>А на вопрос ну так что лучше писать свои велосипеды а потом там ловить баги, отвечают как то невнятно.
N>В одной конторе спросили: "А если у вас забрать boost вы сможете писать код?", блин странные вопросы люди задают.

N>Я вот реально не понимаю, квалификации кадров не хватает что бы почитать документацию, которая кстати довольно хорошая, или просто лень?

А что за конторы? Если пишут кросплатформенные продукты на С++, то подозрительно. Если это сопровождение 1С, то закономерно.