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

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

M>>А меня вот не наводит. И еще если програмист на С++ не пользуется стандартной билиотекой по умолчанию, это уже наводит меня на определенные мысли.
CC>Интересно. А что ты скажешь если программист не пользуется стандартной билиотекой по умолчанию, но при этом хорошо ее знает и имеет серьезный опыт ее применения?
Unreal.

M>>А если кричит что буст это отстой и при этом не строчки не зная и не понимая как это работает
CC>Аналогично. Если от буста отказались после длительного применения?
Пример можешь привести? Нет?

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

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

M>>А меня вот не наводит. И еще если програмист на С++ не пользуется стандартной билиотекой по умолчанию, это уже наводит меня на определенные мысли.
CC>Интересно. А что ты скажешь если программист не пользуется стандартной билиотекой по умолчанию, но при этом хорошо ее знает и имеет серьезный опыт ее применения?

Не забывай что у кода есть очень важный фактор "сопровождаемость". Даже представить себе не могу как некий функциональный аналог STL может дать не худшую сопровождаемость или компенсировать потерю оной какими либо преимуществами. Очень хочу увидеть пример, и надеюсь не очередной велосипед с кривыми колесами и отсутствием покрытия тестами и документации.

M>>А если кричит что буст это отстой и при этом не строчки не зная и не понимая как это работает
CC>Аналогично. Если от буста отказались после длительного применения?

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



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

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

M>>>А меня вот не наводит. И еще если програмист на С++ не пользуется стандартной билиотекой по умолчанию, это уже наводит меня на определенные мысли.
CC>>Интересно. А что ты скажешь если программист не пользуется стандартной билиотекой по умолчанию, но при этом хорошо ее знает и имеет серьезный опыт ее применения?

M>Не забывай что у кода есть очень важный фактор "сопровождаемость". Даже представить себе не могу как некий функциональный аналог STL может дать не худшую сопровождаемость или компенсировать потерю оной какими либо преимуществами.

Qt, MFC, wxWidgets. Ранее на них можно было программировать вообще без использования STL. На Qt, насколько я понимаю, это можно продолжать делать и сейчас (там собственные строки, контейнеры, файлы и пр.) Причем, если Qt3 еще была исключительно Desktop-ориентированной библиотекой, то Qt4 уже разделена на Core и GUI части, так что на Qt4 уже можно server-side делать.

M> Очень хочу увидеть пример, и надеюсь не очередной велосипед с кривыми колесами и отсутствием покрытия тестами и документации.

Закрадываются у меня смутные сомнения, что это камешек в мой огород.

M>>>А если кричит что буст это отстой и при этом не строчки не зная и не понимая как это работает
CC>>Аналогично. Если от буста отказались после длительного применения?

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

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

Boost.Regex vs PCRE vs Greta vs TRE vs POSIX
Boost.Serialization vs s11n.net
Boost.Random vs Agner Random Library
Boost.SmartPtr vs ACE vs Qt vs Loki vs STLSoft vs Poco vs еще много чего.
Boost.Filesystem vs ACE vs STLSoft vs Qt vs wxWidgets vs Poco vs еще много чего.
Boost.Interprocess vs ACE vs Qt vs Poco
Boost.Asio vs ACE vs Qt vs Poco

(disclaimer: в возможностях каких-то библиотек я могу ошибаться).

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

M>>Не забывай что у кода есть очень важный фактор "сопровождаемость". Даже представить себе не могу как некий функциональный аналог STL может дать не худшую сопровождаемость или компенсировать потерю оной какими либо преимуществами.

E>Qt, MFC, wxWidgets. Ранее на них можно было программировать вообще без использования STL. На Qt, насколько я понимаю, это можно продолжать делать и сейчас (там собственные строки, контейнеры, файлы и пр.) Причем, если Qt3 еще была исключительно Desktop-ориентированной библиотекой, то Qt4 уже разделена на Core и GUI части, так что на Qt4 уже можно server-side делать.

В данном случае я бы дал оценку , что использование сторонней библиотеки "Qt, MFC, wxWidgets" не дает преимуществ которые бы компенсировали падение сопровождаемости. Готов рассмотреть сценарий конда в группе на большинстве проектов используется Qt и всем разработчикам необходимы навыки работы с ней (поэтому порог вхождения есть только у новичков и то полюбому).

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

E>Boost.Regex vs PCRE vs Greta vs TRE vs POSIX
E>Boost.Serialization vs s11n.net
E>Boost.Random vs Agner Random Library
E>Boost.SmartPtr vs ACE vs Qt vs Loki vs STLSoft vs Poco vs еще много чего.
E>Boost.Filesystem vs ACE vs STLSoft vs Qt vs wxWidgets vs Poco vs еще много чего.
E>Boost.Interprocess vs ACE vs Qt vs Poco
E>Boost.Asio vs ACE vs Qt vs Poco

E>(disclaimer: в возможностях каких-то библиотек я могу ошибаться).

Насколько я помню , к примеру , ACE достоаточно серьезно рассматривался как кандидат в буст. Почему его не включили а начали писать Boost.Asio(мегасырой продукт) я не знаю. Уверен что причины были и их можно найти в мейл листе.

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

M>В данном случае я бы дал оценку , что использование сторонней библиотеки "Qt, MFC, wxWidgets" не дает преимуществ которые бы компенсировали падение сопровождаемости.

Вообще-то сам тезис о том, что при использовании, например, Qt произойдет падение сопровождаемости по сравнению с использованием STL нуждается в доказательстве.

Более того, лично на придерживаюсь противоположной точки зрения. Скажем, при разработке GUI приложения использование только Qt-шных средств (включая строки и контейнеры) упростит приложение, т.к. средства Qt изначально увязаны друг с другом, а поддержка STL в Qt является опциональной. Для примера можно взять одновременное использование std::string и QString: необходимость преобразования данных между типами, что выливается в лишний (по сути, мусорный) код и снижение производительности.

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

E>>Boost.Regex vs PCRE vs Greta vs TRE vs POSIX
E>>Boost.Serialization vs s11n.net
E>>Boost.Random vs Agner Random Library
E>>Boost.SmartPtr vs ACE vs Qt vs Loki vs STLSoft vs Poco vs еще много чего.
E>>Boost.Filesystem vs ACE vs STLSoft vs Qt vs wxWidgets vs Poco vs еще много чего.
E>>Boost.Interprocess vs ACE vs Qt vs Poco
E>>Boost.Asio vs ACE vs Qt vs Poco

E>>(disclaimer: в возможностях каких-то библиотек я могу ошибаться).

M>Насколько я помню , к примеру , ACE достоаточно серьезно рассматривался как кандидат в буст. Почему его не включили а начали писать Boost.Asio(мегасырой продукт) я не знаю. Уверен что причины были и их можно найти в мейл листе.

Удивлен тем, что были вообще какие-то планы по включению ACE в Boost. Имхо, это два совершенно разных мира со своими целями и подходами к разработке, у них даже системы сборки принципиально отличаются. Примечательна ремарка товарища, который делал презентацию ASIO на BoostConf'07:

BoostCon, Day 3
...and hear this gem from Jeff as he compares ASIO to the popular ACE library: “ACE is an open source project, so you’re free to download it, look at the source code, and be horrified.”

Вряд ли boost-оводам будет интересно использовать ACE. Зато вот что их явно возбуждает (цитата оттуда же):

The morning ends with a flurry of excitement from the audience about building a library of network protocols on top of ASIO and Boost.Spirit, an effort apparently already underway.

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

Я, например, знаю одну Boost-овскую библиотеку, аналога которой больше не встречал -- MultiIndex.

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

E>Вообще-то сам тезис о том, что при использовании, например, Qt произойдет падение сопровождаемости по сравнению с использованием STL нуждается в доказательстве.

Я высказываю свою оценку а не пытаюсь доказать что либо.

E>Более того, лично на придерживаюсь противоположной точки зрения. Скажем, при разработке GUI приложения использование только Qt-шных средств (включая строки и контейнеры) упростит приложение, т.к. средства Qt изначально увязаны друг с другом, а поддержка STL в Qt является опциональной. Для примера можно взять одновременное использование std::string и QString: необходимость преобразования данных между типами, что выливается в лишний (по сути, мусорный) код и снижение производительности.

Вполне обоснованно. Но в описанном случае есть достаточно серьезные причины использовать QString вместо std::string. Хотя и в этом сценарии модель данных лучше реализовать без участия QString.


E>Да ладно, фиг с ним, с ACE. У многих существуют достаточно обоснованные претензии к качеству реализации ACE. Но вот что по поводу других альтернатив библиотекам Boost-а, которые были упомянуты мной выше?

К сожелению не могу прокоментировать сотояние и сравнительный анализ этих библиотек. Я с ними не работал и не проводил оценку и историю использования. Из библиотек которые я примерно представляю себе плюсы и минусы это GIL.

E>Я, например, знаю одну Boost-овскую библиотеку, аналога которой больше не встречал -- MultiIndex.

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

M>>>А меня вот не наводит. И еще если програмист на С++ не пользуется стандартной билиотекой по умолчанию, это уже наводит меня на определенные мысли.
CC>>Интересно. А что ты скажешь если программист не пользуется стандартной билиотекой по умолчанию, но при этом хорошо ее знает и имеет серьезный опыт ее применения?
_>Unreal.
Отнюдь.

M>>>А если кричит что буст это отстой и при этом не строчки не зная и не понимая как это работает
CC>>Аналогично. Если от буста отказались после длительного применения?
_>Пример можешь привести? Нет?
Приезжай — покажу, тыкая пальцем.

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

M>>>А меня вот не наводит. И еще если програмист на С++ не пользуется стандартной билиотекой по умолчанию, это уже наводит меня на определенные мысли.
CC>>Интересно. А что ты скажешь если программист не пользуется стандартной билиотекой по умолчанию, но при этом хорошо ее знает и имеет серьезный опыт ее применения?
M>Не забывай что у кода есть очень важный фактор "сопровождаемость". Даже представить себе не могу как некий функциональный аналог STL может дать не худшую сопровождаемость или компенсировать потерю оной какими либо преимуществами.
Может. С чего ты взял что если аналог то сразу не сопровождаем? Или априори считается что STL и Boost пишутся некими суперпрограммистами из космоса которые больше нигде не водятся?
Чем так сложен тот же STL, чего не может написать команда проф. программистов? Неужели так сложно написать map на B+ tree? Или deque с бОльшим чем в стандартном STL размером блока?

M> Очень хочу увидеть пример
Из жизни — не могу. Будет расценено как нарушение NDA.

M> и надеюсь не очередной велосипед с кривыми колесами и отсутствием покрытия тестами и документации.
Юниттесты имелись. Я кстати к тому же dincumware юниттестов еще не видел никогда. Баги — видел.

M>>>А если кричит что буст это отстой и при этом не строчки не зная и не понимая как это работает
CC>>Аналогично. Если от буста отказались после длительного применения?
M>Пожалуй тут я могу конструктивно пообщаться , в бусте довольно широкий спектр разнообразных библиотек.
У нас отказались после того, как обновление буста, которое требовалось для LUAbind сломало остальной рабочий код до состояния компилится без ошибок но падает в рантайме. Версий уже не вспомню.

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

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

E>>Qt, MFC, wxWidgets. Ранее на них можно было программировать вообще без использования STL. На Qt, насколько я понимаю, это можно продолжать делать и сейчас (там собственные строки, контейнеры, файлы и пр.) Причем, если Qt3 еще была исключительно Desktop-ориентированной библиотекой, то Qt4 уже разделена на Core и GUI части, так что на Qt4 уже можно server-side делать.

M>В данном случае я бы дал оценку , что использование сторонней библиотеки "Qt, MFC, wxWidgets" не дает преимуществ которые бы компенсировали падение сопровождаемости.
Я бы еще поспорил касательно падения сопровождаемости. Сильно уж критерий "сопровождаемость" расплывчатый.
У того же STL кучка реализаций, которые между собой имеют различие в скорости работы.

M>Уверен что причины были и их можно найти в мейл листе.
NIH?

Использовалась. Потом отказались. Ибо тормоза. Сначала профайлер показал, что прога умирает в boost::any, после замены на boost:variant стало полегче, а с велосипедом (типа COleVariant) всё просто залетало.

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

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

Почему конфузит?
Инерция очень велика, буст по сравнению с историей С++ — вещь очень новая, и есть море софта, написаного в совершенно допотопном стиле.
Тут стандарт 98-го еще не прижился, а ведь 10 лет уже прошло.
Не говоря уже о STL.
А ты — буст.

N>А у других как?

У нас софт новый пишется, так что буст в полный рост, включая MPL.

В соседних проектах, где много старого кода, буст используется ограниченно, обычно на уровне shared_ptr.
Тем не менее, на фирме он официально разрешен к использованию и админы создают и поддерживают соответствующие rpm-ки.

You will always get what you always got
  If you always do  what you always did

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

L>О каком результате речь? Разве японцы хоть сколь-нибуть заметны в IT?

Ruby

PS. Русские в IT как-то тоже не столь заметны, как можно было бы подумать почитав RSDN.

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

L>>О каком результате речь? Разве японцы хоть сколь-нибуть заметны в IT?

I>Ruby

И все?

I>PS. Русские в IT как-то тоже не столь заметны, как можно было бы подумать почитав RSDN.

А с этим разве кто-то спорит?

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

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

L>>>О каком результате речь? Разве японцы хоть сколь-нибуть заметны в IT?

I>>Ruby

L>И все?

А как же CD-ROM? Это такой вклад в IT, что Ruby с ним и рядом не валялся.

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

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

То есть использование boost отличает новичка от профессионала?

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

L>>И все?

E>А как же CD-ROM? Это такой вклад в IT, что Ruby с ним и рядом не валялся.

Ну да, ну да. CD-ROM они изобрели исключительно потому что классы не использовали

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

I>То есть использование boost отличает новичка от профессионала?

Конечно. Буст — относительно новая штука, его больше новички знают.

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

RO>>1. #include <boost/next_prior.hpp>
RO>>2. template <class FI> FI next(FI fi) { return ++fi; }

E>std::advance?

Тогда будешь писать 3 строки вместо одной:

#include <iterator>
#include <boost/next_prior.hpp>

template <class FI> FI next(FI fi) { return ++fi; }

void f(char*);

void g(char* p)
{
    f(next(p));

    f(boost::next(p));

    char* q = p;
    std::advance(q, 1);
    f(q);
}