Ламерские вопросы к уважаемым коллегам, особливо к тем кто часто рекомендует воспользоваться мощью этой прекрасной библиотеки
1. вы используете эту библиотеку в ваших проектах? ( проекты хелоу уорд и все что не продается и не сопровождается хотя бы 2-3 программистами в течение хотя бы 2-3 лет -- это проект для дома для души, для шаравар ...etc, в лучшем случае это "крутая" дипломная работа — пятак обеспечен и так, за крутизну — никто не ничего поймет, а выдать себя в незнании буста никто не решиться)
2. Для тех кто реально использует эту библитеку (см п.1)-
— вопрос: что именно вы используете? парсите строку при помощи буста, потому что это модно? или вы собрали свой язык и прикрутили его к соей программе, или это что-то другое. Поделитесь, пожалуйста, своим опытом — очень интересно. Собственно, ЭТО ГЛАВНЫЙ ВОПРОС — ответье на него, не посылаете на бам
3. Я понимаю, что это "язык будующего", а я в теориях слаб.
— вопрос: увеличит ли скорость и качество разработки программого обеспечения если освоить эту новую технологию ( я это вот к чему — многие на РСДНе уже утверждают что де-юре буст будет включен в стандарт С++, а следовательно его нужно знать сегодня)
17.10.04 22:19: Перенесено модератором из 'Средства разработки' — Павел Кузнецов
Здравствуйте, peterbes, Вы писали:
P>1. вы используете эту библиотеку в ваших проектах?
Используем в крупном проекте.
P>2. Для тех кто реально использует эту библитеку (см п.1)- P> — вопрос: что именно вы используете? парсите строку при помощи буста, потому что это модно? или вы собрали свой язык и прикрутили его к соей программе, или это что-то P> другое. Поделитесь, пожалуйста, своим опытом — очень интересно. Собственно, ЭТО ГЛАВНЫЙ ВОПРОС — ответье на него, не посылаете на бам
Используем:
boost::bind — очень удобно, но в исходниках этой библиотеки чёрт ногу сломит.
boost::mpl — для любителей метапрограммирования, хотя если её неумеренно использовать, то можно нарваться на неприятности
Ещё мне нравится boost::iterator — очень удобно, хотя в проекте пока не используем.
Не используем:
boost::spirit лучше не использовать, повсюду в инете пишут, что с ним много проблем.
boost::signal — пробовали использовать, но потом отказались и написали свой велосипед, который хоть и не крутой, но, в отличие от boost::singal, нормально едет.
boost::smart_ptr — лично мне больше нравятся умные указатели от Александреску.
Создаётся впечатление (и не только у меня), что в boost некоторые вещи, которые можно сделать просто и понятно, делают слишком сложно. Частично это происходит из-за поддержки большого количества компиляторов. В связи с этим можно посмотреть TTL, где некоторые аналогичные концепции реализуются просто, но только для VC 7.1 и GCC.
Здравствуйте, peterbes, Вы писали:
P>2. Для тех кто реально использует эту библитеку (см п.1)- P> — вопрос: что именно вы используете? парсите строку при помощи буста, потому что это модно? или вы собрали свой язык и прикрутили его к соей программе, или это что-то другое. Поделитесь, пожалуйста, своим опытом — очень интересно. Собственно, ЭТО ГЛАВНЫЙ ВОПРОС — ответье на него, не посылаете на бам
Буст -- очень полезная и удобная библиотека, к тому же очень большая, всего не использую, но вот что сразу подошло и вообще суперудобно: shared_ptr -- смарт-поинтер, с его помощью удобно указатели на что-то в стандартных контейнерах хранить; function и bind -- мощнейшие вещи, чтобы раз и навсегда забыть о сложностях с адаптированием функций для колбэков и стандратных алгоритмов.
Здравствуйте, What, Вы писали:
W>boost::spirit лучше не использовать, повсюду в инете пишут, что с ним много проблем.
spirit нечто среднее по возможностям между регулярными выражениями и нормальными синтаксическими анализаторами
типа YACC и ANTLR.Минусы —
1.нет диагностики время разбора из-за backtraking становится слишком большим
2.сложность реализации (ну не сложная эта штука LL(inf) )
3.низкая скорость компиляции (до 30 сек на С-grammar (bison менее 1 сек) )
4.плохая поддержка компиляторов в последний версии
5.большой размер exe
6.невнятные сообщения о ошибках (error in boost::spirit<... 150 kByte...> )
Даже какой-то конкурирующий проект появился-hapy
The Hapy library would not exist if Spirit would generate correct parsers by default, had data-push parsing interface, could recognize valid message prefixes, and would not take unreasonable amount of compilation time and/or bleeding-edge C++ compilers. While the last flaw is likely to disappear according to Moore's law, key Spirit design choices would keep it inappropriate for parsing communication protocol messages, one of the primary use cases for the Hapy library.
Вообщем для фанатов метапрограммирования готовых ЛЮБУЮ задачу писать на С++.
И для которых код содержащий менее 30% слов template -вообще не С++.
Здравствуйте, peterbes, Вы писали:
P>Ламерские вопросы к уважаемым коллегам, особливо к тем кто часто рекомендует воспользоваться мощью этой прекрасной библиотеки
P>1. вы используете эту библиотеку в ваших проектах? ( проекты хелоу уорд и все что не продается и не сопровождается хотя бы 2-3 программистами в течение хотя бы 2-3 лет -- это проект для дома для души, для шаравар ...etc, в лучшем случае это "крутая" дипломная работа — пятак обеспечен и так, за крутизну — никто не ничего поймет, а выдать себя в незнании буста никто не решиться)
Используем в коммерческих продуктах.
P>2. Для тех кто реально использует эту библитеку (см п.1)- P> — вопрос: что именно вы используете? парсите строку при помощи буста, потому что это модно? или вы собрали свой язык и прикрутили его к соей программе, или это что-то другое. Поделитесь, пожалуйста, своим опытом — очень интересно. Собственно, ЭТО ГЛАВНЫЙ ВОПРОС — ответье на него, не посылаете на бам
Очень интенсивно используются shared_ptr/scoped_ptr.
Немного function/bind/mem_fn.
Остальное используется эпизодически.
P>3. Я понимаю, что это "язык будующего", а я в теориях слаб. P> — вопрос: увеличит ли скорость и качество разработки программого обеспечения если освоить эту новую технологию ( я это вот к чему — многие на РСДНе уже утверждают что де-юре буст будет включен в стандарт С++, а следовательно его нужно знать сегодня)
Так вот ты какая, серебрянная пуля!
shared_ptr позволяет сделать из C++ практически джаву. Хорошо это или плохо — мнения разделяются, но ошибок со сложными структурами и выделением/освобождением памяти становится на порядок меньше.
Здравствуйте, RealSonic, Вы писали:
RS>Здравствуйте, What, Вы писали:
W>>Не используем: W>>boost::spirit лучше не использовать, повсюду в инете пишут, что с ним много проблем.
RS>Не подскажете, чем можно заменить spirit? Кроме HAPY?
Здравствуйте, peterbes, Вы писали:
P>3. Я понимаю, что это "язык будующего", а я в теориях слаб. P> — вопрос: увеличит ли скорость и качество разработки программого обеспечения если освоить эту новую технологию ( я это вот к чему — многие на РСДНе уже утверждают что де-юре буст будет включен в стандарт С++, а следовательно его нужно знать сегодня)
boost уже сегодня устанавливается на линуксах вместе с g++. Я недавно хотел автоматический указатель. Сначала пришла мысль: auto_ptr. А потом: зачем маяться, когда boost::smart_ptr под рукой? Другой случай. Нужны мне были генератор случайных чисел. И что вы думаете? Конечно, опять-же boost. Вообщем, когда boost доступен безо всяких лишних телодвижений, много старых методов и подходов уже просто отходят на второй план, а потом и вовсе забываются.
Re: офтопик про буст
От:
Аноним
Дата:
20.10.04 20:29
Оценка:
Здравствуйте, peterbes, Вы писали:
P>Ламерские вопросы к уважаемым коллегам, особливо к тем кто часто рекомендует воспользоваться мощью этой прекрасной библиотеки
P>1. вы используете эту библиотеку в ваших проектах? ( проекты хелоу уорд и все что не продается и не сопровождается хотя бы 2-3 программистами в течение хотя бы 2-3 лет -- это проект для дома для души, для шаравар ...etc, в лучшем случае это "крутая" дипломная работа — пятак обеспечен и так, за крутизну — никто не ничего поймет, а выдать себя в незнании буста никто не решиться)
P>2. Для тех кто реально использует эту библитеку (см п.1)- P> — вопрос: что именно вы используете? парсите строку при помощи буста, потому что это модно? или вы собрали свой язык и прикрутили его к соей программе, или это что-то другое. Поделитесь, пожалуйста, своим опытом — очень интересно. Собственно, ЭТО ГЛАВНЫЙ ВОПРОС — ответье на него, не посылаете на бам
P>3. Я понимаю, что это "язык будующего", а я в теориях слаб. P> — вопрос: увеличит ли скорость и качество разработки программого обеспечения если освоить эту новую технологию ( я это вот к чему — многие на РСДНе уже утверждают что де-юре буст будет включен в стандарт С++, а следовательно его нужно знать сегодня)
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, peterbes, Вы писали:
P>>Ламерские вопросы к уважаемым коллегам, особливо к тем кто часто рекомендует воспользоваться мощью этой прекрасной библиотеки
P>>1. вы используете эту библиотеку в ваших проектах? ( проекты хелоу уорд и все что не продается и не сопровождается хотя бы 2-3 программистами в течение хотя бы 2-3 лет -- это проект для дома для души, для шаравар ...etc, в лучшем случае это "крутая" дипломная работа — пятак обеспечен и так, за крутизну — никто не ничего поймет, а выдать себя в незнании буста никто не решиться)
P>>2. Для тех кто реально использует эту библитеку (см п.1)- P>> — вопрос: что именно вы используете? парсите строку при помощи буста, потому что это модно? или вы собрали свой язык и прикрутили его к соей программе, или это что-то другое. Поделитесь, пожалуйста, своим опытом — очень интересно. Собственно, ЭТО ГЛАВНЫЙ ВОПРОС — ответье на него, не посылаете на бам
P>>3. Я понимаю, что это "язык будующего", а я в теориях слаб. P>> — вопрос: увеличит ли скорость и качество разработки программого обеспечения если освоить эту новую технологию ( я это вот к чему — многие на РСДНе уже утверждают что де-юре буст будет включен в стандарт С++, а следовательно его нужно знать сегодня)
Здравствуйте, peterbes, Вы писали:
P> — вопрос: увеличит ли скорость и качество разработки программого обеспечения если освоить эту новую технологию ( я это вот к чему — многие на РСДНе уже утверждают что де-юре буст будет включен в стандарт С++, а следовательно его нужно знать сегодня)
Ага, сильно увеличит, если ты в чужом проекте это увидел, а тебе это, причем наполовину рабочее, поднять надо
Здравствуйте, alexkro, Вы писали:
A>Другой случай. Нужны мне были генератор случайных чисел. И что вы думаете? Конечно, опять-же boost. Вообщем, когда boost доступен безо всяких лишних телодвижений, много старых методов и подходов уже просто отходят на второй план, а потом и вовсе забываются.
просто интересно чем это старый добрый rand() то не угодил?
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, alexkro, Вы писали:
A>>Другой случай. Нужны мне были генератор случайных чисел. И что вы думаете? Конечно, опять-же boost. Вообщем, когда boost доступен безо всяких лишних телодвижений, много старых методов и подходов уже просто отходят на второй план, а потом и вовсе забываются.
CS>просто интересно чем это старый добрый rand() то не угодил?
Because I can! В данном случае rand() и boost/random — это всего лишь два разных библиотечных решения, и у rand() просто нет никакого приемущества перед boost/random. Что для использования rand() нужно меньше помнить, что можно просто написать код? Нет, мне и в том и в другом случае нужно смотреть документацию. rand() легче использовать, меньше кода писать? Нет, примерно столько-же. Кстати, для rand() мне пришлось бы отдельную функцию писать, или класс функтор, чтобы получить генератор в определенном диапазоне. rand() требует меньше телодвижений при компиляции и линковке? Опять-же нет, boost не требует никаких дополнительных телодвижений на моей системе. "А почему не rand()? А зачем?" — вот мой ответ.
Здравствуйте, alexeiz, Вы писали:
A>Because I can! В данном случае rand() и boost/random — это всего лишь два разных библиотечных решения, и у rand() просто нет никакого приемущества перед boost/random. Что для использования rand() нужно меньше помнить, что можно просто написать код? Нет, мне и в том и в другом случае нужно смотреть документацию. rand() легче использовать, меньше кода писать? Нет, примерно столько-же. Кстати, для rand() мне пришлось бы отдельную функцию писать, или класс функтор, чтобы получить генератор в определенном диапазоне. rand() требует меньше телодвижений при компиляции и линковке? Опять-же нет, boost не требует никаких дополнительных телодвижений на моей системе. "А почему не rand()? А зачем?" — вот мой ответ.
В своем проекте, на выходе которого имеется чистый исполняемый бинарник — пожалуйста, хоть черта лысого можно прикрутить. Но использовать boost/random там, где это критично с точки зрения использования исходников и другими людьми, и только лишь потому что "а вот" — это большая глупость, и я бы сказал, самодурство. Нафига лишние зависимости, если без каких либо усилий можно обойтись без них?
Другое дело, что boost/random может быть в чем-то лучше rand(). Это уже мотивация. А "просто так, Because I can" — это дурь.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, alexeiz, Вы писали:
A>>Because I can! В данном случае rand() и boost/random — это всего лишь два разных библиотечных решения, и у rand() просто нет никакого приемущества перед boost/random. Что для использования rand() нужно меньше помнить, что можно просто написать код? Нет, мне и в том и в другом случае нужно смотреть документацию. rand() легче использовать, меньше кода писать? Нет, примерно столько-же. Кстати, для rand() мне пришлось бы отдельную функцию писать, или класс функтор, чтобы получить генератор в определенном диапазоне. rand() требует меньше телодвижений при компиляции и линковке? Опять-же нет, boost не требует никаких дополнительных телодвижений на моей системе. "А почему не rand()? А зачем?" — вот мой ответ.
MS>В своем проекте, на выходе которого имеется чистый исполняемый бинарник — пожалуйста, хоть черта лысого можно прикрутить.
В том и дело, что черта нужно еще прикручивать. А boost он и так прикручен, использование его ничем не отличается от использования стандартной библиотеки C++ или C в моем случае.
>Но использовать boost/random там, где это критично с точки зрения использования исходников и другими людьми, и только лишь потому что "а вот" — это большая глупость, и я бы сказал, самодурство. Нафига лишние зависимости, если без каких либо усилий можно обойтись без них?
MS>Другое дело, что boost/random может быть в чем-то лучше rand(). Это уже мотивация. А "просто так, Because I can" — это дурь.
А допустим уже есть зависимость от boost. Тогда что скажешь? Все равно rand?
Здравствуйте, alexeiz, Вы писали:
CS>>просто интересно чем это старый добрый rand() то не угодил?
A>Because I can! ...
Хм... я например могу побыстрому соорудить скажем нечто с соплом Лаваля на конце.
Но это не повод вствавлять это изделие со всеми причтитающимися деталями в calculator.exe.
"Умерщвление пернатыхъ методомъ стрельбы по онымъ главным калибромъ Флота Его Императорского Величеситва дредноута 'Императрица Мария'"
П-р-р-р-актик.
WinAmp, now playing:
"Sir Occam is sharpening his Razor"
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, alexeiz, Вы писали:
CS>>>просто интересно чем это старый добрый rand() то не угодил?
A>>Because I can! ...
CS>Хм... я например могу побыстрому соорудить скажем нечто с соплом Лаваля на конце.
Это от того, что ты считаешь boost неимоверно продвинутой библиотекой, нечто непонятное и недоступное нормальным людям.
CS>Но это не повод вствавлять это изделие со всеми причтитающимися деталями в calculator.exe.
CS>"Умерщвление пернатыхъ методомъ стрельбы по онымъ главным калибромъ Флота Его Императорского Величеситва дредноута 'Императрица Мария'"
CS>П-р-р-р-актик.
Здравствуйте, alexeiz, Вы писали:
MS>>Другое дело, что boost/random может быть в чем-то лучше rand(). Это уже мотивация. А "просто так, Because I can" — это дурь.
A>А допустим уже есть зависимость от boost. Тогда что скажешь? Все равно rand?
А это уже "будем посмотреть". Если, к примеру, мне не требуется ничего кроме функциональности rand(), то именно его я задействую. Так компилируется быстрее
Я сотрудничаю с Эриком Джонсом, приятелем Дейва Абрахамса, и как-то спросил его, почему они используют SWIG а не boost/python для взаимодействия между Питоном и C++. Причнины следующие:
1. Низкая надежность, слишком много проблем с разными компиляторами и платформами.
2. Монстрообразность получаемого кода. Можно, конечно, "доработать напильником", но это требует слишком больших усилий.
3. Время компиляции находится далего за предемами допустимого.
Основной принцип грамотного инженерного подхода — "без фанатизма". В бусте очень много ненужного мусора. Ну вот зачем в кватернионе код сериализации в ASCII? Причем, он весьма узкоспециализирован, следовательно, практически бесполезен. Но при этом тянет за собой тонну зависимостей, только лишь для того, что кому-то зачем-то надо реализовать потоковые оператоты. Все это для меня и для 99% других людей — мусор. И так практически во всем бусте. Слишком много "фанатизма". Слишком.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, alexeiz, Вы писали:
MS>>>Другое дело, что boost/random может быть в чем-то лучше rand(). Это уже мотивация. А "просто так, Because I can" — это дурь.
A>>А допустим уже есть зависимость от boost. Тогда что скажешь? Все равно rand?
MS>А это уже "будем посмотреть". Если, к примеру, мне не требуется ничего кроме функциональности rand(), то именно его я задействую. Так компилируется быстрее
Ничего, кроме генерирования чисел в диапазоне 0..MAX_RAND? Сколько я помню, мне всегда дополнительный класс писать приходилось для работы с rand.
MS>Я сотрудничаю с Эриком Джонсом, приятелем Дейва Абрахамса, и как-то спросил его, почему они используют SWIG а не boost/python для взаимодействия между Питоном и C++. Причнины следующие: MS>1. Низкая надежность, слишком много проблем с разными компиляторами и платформами. MS>2. Монстрообразность получаемого кода. Можно, конечно, "доработать напильником", но это требует слишком больших усилий. MS>3. Время компиляции находится далего за предемами допустимого.
Многим этот boost/python нафиг не сдался. Что этим ты хотел сказать: либо всё из boost'а, либо ничего?
MS>Основной принцип грамотного инженерного подхода — "без фанатизма". В бусте очень много ненужного мусора. Ну вот зачем в кватернионе код сериализации в ASCII? Причем, он весьма узкоспециализирован, следовательно, практически бесполезен. Но при этом тянет за собой тонну зависимостей, только лишь для того, что кому-то зачем-то надо реализовать потоковые оператоты. Все это для меня и для 99% других людей — мусор. И так практически во всем бусте. Слишком много "фанатизма". Слишком.
Не нравится кватерион, не используй его. Никаких зависимостей не внесешь. Согласен, что в boost'е есть и неудачный код. Но это не значит, что нужно игнорировать и очень качественный код из boost'а. Это всего лишь еще одно проявление фанатизма.
Здравствуйте, McSeem2, Вы писали:
MS>Я сотрудничаю с Эриком Джонсом, приятелем Дейва Абрахамса, и как-то спросил его, почему они используют SWIG а не boost/python для взаимодействия между Питоном и C++. Причнины следующие: MS>1. Низкая надежность, слишком много проблем с разными компиляторами и платформами. MS>2. Монстрообразность получаемого кода. Можно, конечно, "доработать напильником", но это требует слишком больших усилий. MS>3. Время компиляции находится далего за предемами допустимого.
Самое главное он забыл, SWIG это практически средство автоматического создания кода, и пользоватся им на порядок проще чем boost/python, так что сравнение тут совершенно некорректно.
Здравствуйте, FR, Вы писали:
FR>Самое главное он забыл, SWIG это практически средство автоматического создания кода, и пользоватся им на порядок проще чем boost/python, так что сравнение тут совершенно некорректно.
В том то и дело, что SWIG их по неким причинам не вполне устраивает и они попытались переключиться на direct use boost/python. Все там вроде бы хорошо и не так уж и сложно, но вот компиляция...
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, alexeiz, Вы писали:
MS>>А это уже "будем посмотреть". Если, к примеру, мне не требуется ничего кроме функциональности rand(), то именно его я задействую. Так компилируется быстрее
A>Ничего, кроме генерирования чисел в диапазоне 0..MAX_RAND? Сколько я помню, мне всегда дополнительный класс писать приходилось для работы с rand.
Это зачем? rand() % 100 сгенерирует 0...99. Зачем для этого класс писать?! Если качество случайных чисел не критично, этого вполне достаточно.
A>Многим этот boost/python нафиг не сдался. Что этим ты хотел сказать: либо всё из boost'а, либо ничего?
Нет, просто как пример. К сожалению, он довольно типичен для буста.
A>Не нравится кватерион, не используй его. Никаких зависимостей не внесешь. Согласен, что в boost'е есть и неудачный код. Но это не значит, что нужно игнорировать и очень качественный код из boost'а. Это всего лишь еще одно проявление фанатизма.
В том-то и дело, что в остальном бустовский кватернион вполне хорош. Я его и взял, отпилив ненужные куски (благо лицензия позволяет). Там же ничего, кроме <math.h> не нужно! Но такой подход неправилен по жизни. А обилие изначальных зависимостей приводило к проблемам на некоторых платформах.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, alexeiz, Вы писали:
CS>>Хм... я например могу побыстрому соорудить скажем нечто с соплом Лаваля на конце.
A>Это от того, что ты считаешь boost неимоверно продвинутой библиотекой, нечто непонятное и недоступное нормальным людям.
Что заставило тебя сделать такой вывод?
"Советское фирменное сопло" достаточно простая штука если у тебя есть время, потребность, а самое главное желание приглядеться. То же и про буст.
Не у всех просто есть эта роскошь — время.
Буст это процесуализм — программирование ради программирования.
Что в общем-то не есть плохо.
Но я лично например считаю что эту бы силу ("boost" as verb) приложить бы к делу создания самого языка
а не изобретение зубодробительных попыток обойти ограничения оного.
Ну что стоит ввести конструкцию is_pod_type со товарищи на уровне препроцессора?
Или ту же условную инстанциацию шаблонов?
boost::mpl это ж синтаксический дизастер какой-то.
Сколько раз уже говорили — это место человеческого тела только для output.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, alexeiz, Вы писали:
CS>>>Хм... я например могу побыстрому соорудить скажем нечто с соплом Лаваля на конце.
A>>Это от того, что ты считаешь boost неимоверно продвинутой библиотекой, нечто непонятное и недоступное нормальным людям.
CS>Что заставило тебя сделать такой вывод? CS>"Советское фирменное сопло" достаточно простая штука если у тебя есть время, потребность, а самое главное желание приглядеться. То же и про буст. CS>Не у всех просто есть эта роскошь — время. CS>Буст это процесуализм — программирование ради программирования. CS>Что в общем-то не есть плохо.
Не согласен. Boost предлагает конкретные решения для конкретных проблем. "Программирование ради программирования" — это абсолютно не обосновано. Реальные решения проходят обкатку через boost. Ты хоть бы поинтересовался какие библиотеки из boost'а войдут в следующий стандарт. Ни одна другая библиотека общего назначения не может этим похвастаться.
Другое дело если эти проблемы от тебя далеки. Тогда да, кажется, что они там лабудой занимаются.
Теперь о расточении времени. Если человек может себе позволить написать свой собственный shared_ptr или какой-нибудь array, когда тоже самое есть либо в стандарте, либо в boost'е, то о какой экономии времени идет речь? Экономия времени достигается, когда ты можешь использовать солидные существующие наработки, а не изобретать велосипед самостоятельно.
CS>Но я лично например считаю что эту бы силу ("boost" as verb) приложить бы к делу создания самого языка CS>а не изобретение зубодробительных попыток обойти ограничения оного.
CS>Ну что стоит ввести конструкцию is_pod_type со товарищи на уровне препроцессора?
см. type_traits<> в tr1.
CS>Или ту же условную инстанциацию шаблонов?
Контрибьюторы boost'а являются очень активными членами комитета по стандартизации. Это просто невозможно не заметить, если ты интересуешься развитием C++.
CS>boost::mpl это ж синтаксический дизастер какой-то.
Как сказать. Ты можешь предложить более элегантное решение?
CS>Сколько раз уже говорили — это место человеческого тела только для output.
Здравствуйте, alexeiz, Вы писали:
A>Теперь о расточении времени. Если человек может себе позволить написать свой собственный shared_ptr или какой-нибудь array, когда тоже самое есть либо в стандарте, либо в boost'е, то о какой экономии времени идет речь? Экономия времени достигается, когда ты можешь использовать солидные существующие наработки, а не изобретать велосипед самостоятельно.
Чего там такого сложного в shared_ptr или array, чтобы не написать их самому? Очень часто это вполне оправдано. Зависимость от чужого кода, это знаете ли, тяжелая штука, а иногда — и весьма болезненная. Но с другой стороны, от зависимостей никуда не денешься. В конце концов я и сам создаю зависимости и "подсаживаю на иглу".
Я нисколько не агитирую против Буста. Наоборот! Используйте на здоровье, как можно больше и шире. Но сам я — человек консервативный и пока что не тороплюсь. Пусть устаканится хорошенько.
A>Контрибьюторы boost'а являются очень активными членами комитета по стандартизации. Это просто невозможно не заметить, если ты интересуешься развитием C++.
Вот в этом и заключается основная ценность Буста. Хорошо бы усилиями комитета и бустовцев заставить лодырей из MS довести до ума ихний компилятор, а не заниматься всякой мертворожденной отсебятиной типа MC++.
CS>>boost::mpl это ж синтаксический дизастер какой-то.
A>Как сказать. Ты можешь предложить более элегантное решение?
Я могу. Надо направлять больше усилий на доработку самого языка C++. Но это нелегко, однако. Искренне надеюсь, что через Буст мало-помалу C++ будет развиваться.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, ssm, Вы писали:
ssm>VC7.1 довольно далеко ушел от своих уродливых старших братцев, чего тебе в нем нехватает?
На самом деле, не очень. Шаблоны он до сих пор толком не компилирует вплоть до момента инстанциации. Они теперь только третуют писать typename там где это необходимо (хоть и на том спасибо), но это требование, на самом деле, искусственное.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, alexeiz, Вы писали:
A>Не согласен. Boost предлагает конкретные решения для конкретных проблем. "Программирование ради программирования" — это абсолютно не обосновано. Реальные решения проходят обкатку через boost. Ты хоть бы поинтересовался какие библиотеки из boost'а войдут в следующий стандарт. Ни одна другая библиотека общего назначения не может этим похвастаться.
По теме данной дискуccии я посмотрел random generators в boost.
В частности normal distribution. Генерация оного сделана неэффективно.
Вывод: я не могу слепо взять boost как есть.
A>Теперь о расточении времени. Если человек может себе позволить написать свой собственный shared_ptr или какой-нибудь array, когда тоже самое есть либо в стандарте, либо в boost'е, то о какой экономии времени идет речь? Экономия времени достигается, когда ты можешь использовать солидные существующие наработки, а не изобретать велосипед самостоятельно.
Пример из жизни: Есть модуль котрый создает array. Этот array проходит по цепочке вызовов функций и попадает в конце концов в некую коллекцию которая его хранит.
Пришел к тому что мне нужно написать нечто типа метода transfer
void array::transfer(array& src)
{ this->data = src.data; src.data = 0; this->allocated_size = src.allocated_size; src.allocated_size = 0;
...
}
мне проще написать такой метод за 15 минут (вместе с анализом семантики move)
чем лепить workarounds c использованием std::vector
A>см. type_traits<> в tr1.
Сомнения меня берут что это надо делать через шаблоны вообще.
атомарная конструкция вида has_trivial_default_constructor( typename ) в том числе
позволяет использовать оную и в #if.
CS>>Или ту же условную инстанциацию шаблонов?
A>Контрибьюторы boost'а являются очень активными членами комитета по стандартизации. Это просто невозможно не заметить, если ты интересуешься развитием C++.
Даже встречался лично с некоторыми.
CS>>boost::mpl это ж синтаксический дизастер какой-то.
A>Как сказать. Ты можешь предложить более элегантное решение?
Да. Привести в порядок систему #define со товарищи
Вместо вот этой вот красоты:
template< typename T >
struct can_be_on_stack
: mpl::bool_c< (sizeof(T) <= sizeof(double)) >
{
};
// use 'if_' to choose where to store 'T' membertemplate< typename T >
struct lightweight
: private mpl::if_<
can_be_on_stack<T>
, stack_holder<T>
, heap_holder<T>
>::type
{
// ...
};
Это ж каким надо быть Александреску чтобы считать struct булевой переменной.
И самое главное что как бы народ то привыкает. Это ж хуже Visual Basic, мля!
Я бы предлжил нечто типа
#function bool can_be_on_stack(typename T)
return (sizeof(T) <= sizeof(double));
#end function
#function typename optimal_holder(typename T)
return can_be_on_stack(T)? stack_holder<T>:heap_holder<T>;
#end function
template< typename T >
struct lightweight : private optimal_holder(T)
как бы оно честнее и очевиднее получается, нет?
Имхо в тридцать раз проще написать к компилятору интерпертатор типизированных meta функций
чем имплементировать синтасические тонкости вложенных шаблонов.
А если проще — значит надежнее и значит с большей вероятностью разные компиляторы будут одинаково интерпретировать базовые констукции.
В плохих компиляторах виноваты и разработчики стандартов и разработчики компиляторов в равной степени.
CS>Это ж каким надо быть Александреску чтобы считать struct булевой переменной. CS>И самое главное что как бы народ то привыкает.
просто надо привыкнуть
изначально все эти конструкции из mpl смотрятся очень дико, но после прочтения доки в течении часа и часа на игру с mpl::bool, mpl::if, mpl::enable_if и т.д. они начинают нравится , и не кажутся уже монстрами.
CS> Это ж хуже Visual Basic, мля!
не хуже, а страшней просто.
Здравствуйте, ssm, Вы писали:
ssm>Здравствуйте, c-smile, Вы писали:
ssm>просто надо привыкнут ...изначально все эти конструкции из mpl смотрятся очень дико ... они начинают нравится.
Здравствуйте, peterbes, Вы писали:
P>1. вы используете эту библиотеку в ваших проектах?
Да, в крупных проектах.
P>2. Для тех кто реально использует эту библитеку (см п.1)- P> — вопрос: что именно вы используете?
array, bind, conversion, crc, enable_if, format, function, lambda, mpl, preprocessor, random, regex, smart_ptr, spirit, tuple, variant
random — потому что не вижу смысла в реализации на коленке стандартного mt19937 и пр., а они нужны
P>3. Я понимаю, что это "язык будующего", а я в теориях слаб. P> — вопрос: увеличит ли скорость и качество разработки программого обеспечения если освоить эту новую технологию
Увеличит. Но серебряной пули нет
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, ssm, Вы писали:
ssm>>VC7.1 довольно далеко ушел от своих уродливых старших братцев, чего тебе в нем нехватает?
MS>На самом деле, не очень. Шаблоны он до сих пор толком не компилирует вплоть до момента инстанциации.
так это же требование стандарта С++, или я чего-то не понимаю?
в 7.1 впервые появилась поддержка частичной параметризации шаблонов ...
Здравствуйте, ruslan_abdikeev, Вы писали:
_>Здравствуйте, peterbes, Вы писали:
P>>1. вы используете эту библиотеку в ваших проектах? _>Да, в крупных проектах.
P>>2. Для тех кто реально использует эту библитеку (см п.1)- P>> — вопрос: что именно вы используете? _>array, bind, conversion, crc, enable_if, format, function, lambda, mpl, preprocessor, random, regex, smart_ptr, spirit, tuple, variant
Плюс type_traits (без коментариев), operators (не фанат я писать вручную операторы >, >=, <= для каждого типа), format (хоть и тяжелый, но безопасный по сравнению с printf), filesystem (виндовые и стандартные операции с файлами меня раздражают), thread (иногда), utility (STATIC_ASSERT и т.п.).
У меня принцип простой, использую сначала то что уже есть, если не подходит стараюсь не рать на весь RSDN что бюст и эстиэл отстой, но просто пытаюсь сделать то что мне подходит с похожим интерфейсом (по возможности конечно), что бы хотя бы тот кто будет дальше поддерживать этот проект понимал о чем речь.
Здравствуйте, c-smile, Вы писали:
CS>просто интересно чем это старый добрый rand() то не угодил?
Boost же, вроде, позволяет задавать различные распределения вероятностей. rand() — это равномерное распределение, а если нужно, например, максвелловское?
Здравствуйте, peterbes, Вы писали:
P>Ламерские вопросы к уважаемым коллегам, особливо к тем кто часто рекомендует воспользоваться мощью этой прекрасной библиотеки
P>1. вы используете эту библиотеку в ваших проектах? ( проекты хелоу уорд и все что не продается и не сопровождается хотя бы 2-3 программистами в течение хотя бы 2-3 лет -- это проект для дома для души, для шаравар ...etc, в лучшем случае это "крутая" дипломная работа — пятак обеспечен и так, за крутизну — никто не ничего поймет, а выдать себя в незнании буста никто не решиться)
Используется в коммерческом проекте
P>2. Для тех кто реально использует эту библитеку (см п.1)- P> — вопрос: что именно вы используете? парсите строку при помощи буста, потому что это модно? или вы собрали свой язык и прикрутили его к соей программе, или это что-то другое. Поделитесь, пожалуйста, своим опытом — очень интересно. Собственно, ЭТО ГЛАВНЫЙ ВОПРОС — ответье на него, не посылаете на бам
Использую:
1) boost::regex
2) boost::shared_ptr/scoped_ptr etc.
P>3. Я понимаю, что это "язык будующего", а я в теориях слаб. P> — вопрос: увеличит ли скорость и качество разработки программого обеспечения если освоить эту новую технологию ( я это вот к чему — многие на РСДНе уже утверждают что де-юре буст будет включен в стандарт С++, а следовательно его нужно знать сегодня)
Re[2]: офтопик про буст
От:
Аноним
Дата:
19.04.06 09:30
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, peterbes, Вы писали:
P>> — вопрос: увеличит ли скорость и качество разработки программого обеспечения если освоить эту новую технологию ( я это вот к чему — многие на РСДНе уже утверждают что де-юре буст будет включен в стандарт С++, а следовательно его нужно знать сегодня)
А>Ага, сильно увеличит, если ты в чужом проекте это увидел, а тебе это, причем наполовину рабочее, поднять надо
Молоток не виноват в том, что он оказался в кривых руках.
Я тебе и без буста смогу такое наваять, что и в жизни не поднять
Здравствуйте, c-smile, Вы писали:
CS>По теме данной дискуccии я посмотрел random generators в boost. CS>В частности normal distribution. Генерация оного сделана неэффективно. CS>Вывод: я не могу слепо взять boost как есть.
Так напиши об этом авторам random.
Или прямо в бустовский mailing list, чтобы народ поучаствовал в обсуждении.
Буст же открыт, да и у тебя у самого личные связи есть.
В чем проблема- сделать буст лучше, чтобы им действительно пользовались все без сомнений?
You will always get what you always got
If you always do what you always did
Re[12]: офтопик про буст
От:
Аноним
Дата:
19.04.06 17:19
Оценка:
Здравствуйте, Vark, Вы писали:
V>Здравствуйте, McSeem2, Вы писали:
MS>>Здравствуйте, ssm, Вы писали:
ssm>>>VC7.1 довольно далеко ушел от своих уродливых старших братцев, чего тебе в нем нехватает?
MS>>На самом деле, не очень. Шаблоны он до сих пор толком не компилирует вплоть до момента инстанциации.
V>так это же требование стандарта С++, или я чего-то не понимаю?
Не понимаешь, про двухфазный поиск имен когда-нибудь слышал?
V>в 7.1 впервые появилась поддержка частичной параметризации шаблонов ...
, но после прочтения доки в течении часа 
и часа на игру с mpl::bool, mpl::if, mpl::enable_if и т.д. 
они начинают нравится 
, и не кажутся уже монстрами. 
