Здравствуйте, eao197, Вы писали:
E>Здравствуйте, minorlogic, Вы писали:
E>>>Ну да. Только тут сочетается два принципа, которые приводят меня в бешенство: "Есть только один правильный способ делать вещи" и "Кто не с нами, тот против нас".
M>>Я понимаю про какие ты принцыпы пишешь и откуда ты их взял.
E>"Есть только один правильный способ делать вещи" появился из: E>- фактов того, что в Boost-е реализуют по своему функциональность, уже существующую в других библиотеках. Например, asio и interprocess; E>- утверждений пользователей Boost-а о том, что Boost-овские библиотеки круче других (см. здесь
: "А TRE рядом с творением Мэддока даже рядом не стояло.").
Я юзал Boost.Regex. Это в большинстве случаев 1-2 строчки. Смотришь примеры, и сразу всё ясно. И почему собственно пишут заново? Потому что многие старые либы с современным С++ несовместимы. Попробуй заюзать например шаблоны в Qt...
Здравствуйте, eao197, Вы писали:
E>Все это наводит на мысль, что у некоторого количества людей складывается стереотип "Boost -- это хорошо и правильно. А вот не Boost -- это слабенькие спецы/старые пердуны и пр."
А меня вот не наводит. И еще если програмист на С++ не пользуется стандартной билиотекой по умолчанию, это уже наводит меня на определенные мысли. А если кричит что буст это отстой и при этом не строчки не зная и не понимая как это работает тогда да, это старые пердуны.
E>Я думаю, что если кто-то взялся за Boost, то ему уже не объяснить, зачем может потребоваться ACE.
Мне кажется это какиенить твои персональные заблуждения, похоже на борьбу с гипотетическим разработчиком. Если тебе знаком этот персонаж то постарайся не пеерносить на других его образ.
E>Ну кому-то же нужно повторять "Карфаген должен быть разрушен!". А то очень удобно считать, что Boost это классная и полезная штука.
А я именно так и считаю, что "Boost это классная и полезная штука." и мне это очень удобно.
E>Не обращая внимания на то, что определенное количество разработчиков видят в Boost-е недостатки. И на то, что могут быть другие пути развития C++ных библиотек и систем их распространения.
А это уже некий религиозный взгляд, и меньше всего так думают сами разработчики буста. Попробуй найди разработчика интенсивно пользующего буст и не видящего в нем недостатков (я не встречал).
Здравствуйте, minorlogic, Вы писали:
E>>Все это наводит на мысль, что у некоторого количества людей складывается стереотип "Boost -- это хорошо и правильно. А вот не Boost -- это слабенькие спецы/старые пердуны и пр."
M>А меня вот не наводит. И еще если програмист на С++ не пользуется стандартной билиотекой по умолчанию, это уже наводит меня на определенные мысли.
А вот пусть не наводит. Почему предположить, что программист не использует стандартную библиотеку C++ по объективным причинам сложнее, чем предположить, что это недоучка или старый пердун?
Вот, например, если кто-то предпочитает использовать функции open/read/write/lseek вместо std::fstream -- это показатель непрофессионализма? А если кто-то не использует std::map из-за высоких накладных расходов последнего -- это что?
M>А если кричит что буст это отстой и при этом не строчки не зная и не понимая как это работает тогда да, это старые пердуны.
А теперь давай вспомним, кто здесь кричал, что boost отстой? И ты уверен, что критики boost в данной ветке не способны понять, как им пользоваться и как он устроен? Мне кажется, ты здесь говоришь о каком-то гипотетическом разработчике.
E>>Ну кому-то же нужно повторять "Карфаген должен быть разрушен!". А то очень удобно считать, что Boost это классная и полезная штука.
M>А я именно так и считаю, что "Boost это классная и полезная штука." и мне это очень удобно.
Ну и хорошо. Но это не объясняет, почему пользователи Boost-а с таким апломбом зявляют "Я использую Boost". Вот ты можешь объяснить?
E>>Не обращая внимания на то, что определенное количество разработчиков видят в Boost-е недостатки. И на то, что могут быть другие пути развития C++ных библиотек и систем их распространения.
M>А это уже некий религиозный взгляд, и меньше всего так думают сами разработчики буста. Попробуй найди разработчика интенсивно пользующего буст и не видящего в нем недостатков (я не встречал).
Ты сейчас говоришь о недостатках в реализации каких-то библиотек. Я же говорю о недостатках Boost как некоего движения разработчиков. Одна большая "правильная" библиотека -- это то, что я не хочу видеть как будущее для C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Вот, например, если кто-то предпочитает использовать функции open/read/write/lseek вместо std::fstream -- это показатель непрофессионализма? А если кто-то не использует std::map из-за высоких накладных расходов последнего -- это что?
Ага. А взамен такой товарищ будет юзать самописный список с линейным поиском. Плавали, знаем.
Здравствуйте, eao197, Вы писали:
M>>А я именно так и считаю, что "Boost это классная и полезная штука." и мне это очень удобно.
E>Ну и хорошо. Но это не объясняет, почему пользователи Boost-а с таким апломбом зявляют "Я использую Boost". Вот ты можешь объяснить?
Объясняли вообще-то уже. А вот один противник тут крикнул -- "Некоторые либы в бусте — дерьмо!", но на конкретную просьбу назвать оные скромно удалился.
Здравствуйте, skeptik_, Вы писали:
M>>>А я именно так и считаю, что "Boost это классная и полезная штука." и мне это очень удобно.
E>>Ну и хорошо. Но это не объясняет, почему пользователи Boost-а с таким апломбом зявляют "Я использую Boost". Вот ты можешь объяснить?
_>Объясняли вообще-то уже.
Где?
_>А вот один противник тут крикнул -- "Некоторые либы в бусте — дерьмо!", но на конкретную просьбу назвать оные скромно удалился.
Ну я одну такую могу назвать: lexical_cast. Тормозная и ресурсоемкая штука. К тому же негибкая.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, skeptik_, Вы писали:
E>>Вот, например, если кто-то предпочитает использовать функции open/read/write/lseek вместо std::fstream -- это показатель непрофессионализма? А если кто-то не использует std::map из-за высоких накладных расходов последнего -- это что? _>Ага. А взамен такой товарищ будет юзать самописный список с линейным поиском.
Если человек может объяснить, почему std::map в его ситуации не подходит и какие именно накладные расходы ему мешают, то он вряд ли будет делать список с линейным поиском. Хотя, в некоторых случаях, линейный поиск по короткому вектору будет намного быстрее поиска в std::map-е.
_>Плавали, знаем.
Понятно. Попробуй устроится в контору с нормальным уровнем разработки на C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
_>>А вот один противник тут крикнул -- "Некоторые либы в бусте — дерьмо!", но на конкретную просьбу назвать оные скромно удалился.
E>Ну я одну такую могу назвать: lexical_cast. Тормозная и ресурсоемкая штука. К тому же негибкая.
Её тормознутость как раз от гибкости-то и происходит! Ибо она учтёт при конвертировании все пожелания твоей локали. Это надо понимать, решая, юзать её, или что-то другое. Впрочем в 90% случаев её скорости вполне достаточно. А если у тебя формат жёстко задан -- ясен пень, что специализированный парсер её обгонит. Короче, опять же слабое понимание возможностей и потребностей.
Здравствуйте, skeptik_, Вы писали:
_>>>А вот один противник тут крикнул -- "Некоторые либы в бусте — дерьмо!", но на конкретную просьбу назвать оные скромно удалился.
E>>Ну я одну такую могу назвать: lexical_cast. Тормозная и ресурсоемкая штука. К тому же негибкая.
_> Её тормознутость как раз от гибкости-то и происходит! Ибо она учтёт при конвертировании все пожелания твоей локали.
Если она такая гибкая, то как в вызове:
lexical_cast<std::string>(2048u)
получить шестнадцатиричное число с префиксом 0x?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, skeptik_, Вы писали:
E>>Понятно. Попробуй устроится в контору с нормальным уровнем разработки на C++.
_>Спасибо, я уж как-нибудь дальше фрилансером. И денег в три раза больше, и свободы.
Как, тебе хватает $100 в месяц?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А вот пусть не наводит. Почему предположить, что программист не использует стандартную библиотеку C++ по объективным причинам сложнее, чем предположить, что это недоучка или старый пердун?
Я полагаю что таких причин нет. По крайней мере если он знает STL и применяет другой , лучший подход , я буду только рад с ним порабоать. Если ж это просто голословное "тормозит", "жрет память", "не универсально", "сложно" и т.п. причем без цифр, то это недоучка или старый пердун.
E>Вот, например, если кто-то предпочитает использовать функции open/read/write/lseek вместо std::fstream -- это показатель непрофессионализма?
Функции работы с файламы не стоит мешать с потоками ввода вывода которые предоставляют унифицированный интерфейс ввода вывода, у них разный круг компетенции.
E>А если кто-то не использует std::map из-за высоких накладных расходов последнего -- это что?
Это голословное утверждение. Накладные расходы можно обсуждать только в приложении к решаемой задаче и альтернативными решениями. А вот использование std::map для ассоциативной связи по ключу это прямое и просто решение.
E>А теперь давай вспомним, кто здесь кричал, что boost отстой? И ты уверен, что критики boost в данной ветке не способны понять, как им пользоваться и как он устроен? Мне кажется, ты здесь говоришь о каком-то гипотетическом разработчике.
Хорошо , не будем рассматривать этого гип. разраба.
M>>А я именно так и считаю, что "Boost это классная и полезная штука." и мне это очень удобно.
E>Ну и хорошо. Но это не объясняет, почему пользователи Boost-а с таким апломбом зявляют "Я использую Boost". Вот ты можешь объяснить?
Ну извини , если тебе слышится апломб , тогда это не ко мне . скорее к психологу.
E>Ты сейчас говоришь о недостатках в реализации каких-то библиотек. Я же говорю о недостатках Boost как некоего движения разработчиков. Одна большая "правильная" библиотека -- это то, что я не хочу видеть как будущее для C++.
Я не пониамаю тебя. Буст стремится объеденить лучшее что есть в индустрии с оглядкой на принцыпы залорженные в C++ и его библиотеках. Если есть билиотека решающая поставленные задачи лучеш чем решение в бусте , я не вижу причин по которым бы эта библиотека не вытеснила бустовскую и не заняла ее место.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, skeptik_, Вы писали:
_>>>>А вот один противник тут крикнул -- "Некоторые либы в бусте — дерьмо!", но на конкретную просьбу назвать оные скромно удалился.
E>>>Ну я одну такую могу назвать: lexical_cast. Тормозная и ресурсоемкая штука. К тому же негибкая.
_>> Её тормознутость как раз от гибкости-то и происходит! Ибо она учтёт при конвертировании все пожелания твоей локали.
E>Если она такая гибкая, то как в вызове: E>
E>lexical_cast<std::string>(2048u)
E>
E>получить шестнадцатиричное число с префиксом 0x?
Тебе не кажется, что ты путаешь божий дар с яичницей? lexical_cast предназначен для простого преобразования из одного типа в другой. То, что ты хочешь, это — форматирование. Смотри boost::format например.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, skeptik_, Вы писали:
E>>>Понятно. Попробуй устроится в контору с нормальным уровнем разработки на C++.
_>>Спасибо, я уж как-нибудь дальше фрилансером. И денег в три раза больше, и свободы.
E>Как, тебе хватает $100 в месяц?
Здравствуйте, skeptik_, Вы писали:
E>>Если она такая гибкая, то как в вызове: E>>
E>>lexical_cast<std::string>(2048u)
E>>
E>>получить шестнадцатиричное число с префиксом 0x?
_>Тебе не кажется, что ты путаешь божий дар с яичницей? lexical_cast предназначен для простого преобразования из одного типа в другой.
Да, преобразование целого числа в строку с шестнадцатиричным представлением -- это охринительно сложная операция.
_> То, что ты хочешь, это — форматирование. Смотри boost::format например.
Понятно, т.е. вместо кода:
int result = do_something();
if( result )
throw some_exception( "do_something failed with result: " + slexcast( result, hex_0x ) );
мне нужно будет делать что-то вроде:
int result = do_something();
if( result )
throw some_exception( "do_something failed with result: " +
(format( "0x%x" ) % result).str() );
Зато, блин, буст. Не какой-нибудь свой велосипед.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Понятно, т.е. вместо кода: E>
E>int result = do_something();
E>if( result )
E> throw some_exception( "do_something failed with result: " + slexcast( result, hex_0x ) );
E>
E>мне нужно будет делать что-то вроде: E>
E>int result = do_something();
E>if( result )
E> throw some_exception( "do_something failed with result: " +
E> (format( "0x%x" ) % result).str() );
E>
Формировать строку сообщения об ошибке в throw — не лучший способ. Во-первых, там лучше особо сложных вещей не делать, дабы не кинуть новое исключение; во-вторых: желаю массу удовольствий при интернационализации программы. В-третьих, если slexcast столь хороша -- предложи её в буст. В-четвертых, я особой разницы между этими двумя вариантами не вижу.
Здравствуйте, minorlogic, Вы писали:
E>>А вот пусть не наводит. Почему предположить, что программист не использует стандартную библиотеку C++ по объективным причинам сложнее, чем предположить, что это недоучка или старый пердун?
M>Я полагаю что таких причин нет.
Тем не менее, таких причин может быть предостаточно. Например, стоит только отказаться от использования исключений и запретить оператору new выбрасывать исключения. Как тогда будут вести себя стандартные контейнеры и строки?
E>>А если кто-то не использует std::map из-за высоких накладных расходов последнего -- это что?
M>Это голословное утверждение. Накладные расходы можно обсуждать только в приложении к решаемой задаче и альтернативными решениями. А вот использование std::map для ассоциативной связи по ключу это прямое и просто решение.
Не голословное. В STL-ях, насколько мне известно, std::map реализуется через деревья (вроде как самая распространенная реализация -- это красно-черные деревья). Новые элементы дерева выделяются через new. Это может оказывать следующие негативные эфекты:
1. При небольшом размере контейнера (скажем 20-100 элементов) и небольших размерах элементов (вроде нескольких int-ов) обычный вектор с тупым линейным поиком и перемещением элементов при вставке/удалении будет эффективнее, т.к. эти операции все равно будут дешевле, чем new/delete (особенно в многопоточной программе с очень дорогими new/delete). А если добавить еще и двоичный поиск...
2. В долгоживущем map-е узлы дерева запросто могут оказаться на разных страницах памяти. И при поиске элемента возможны промахи мимо кэша, когда очередной страницы с единственным элементом дерева нет в кэше. А на современных процесорах промах мимо кэша обходится очень дорого.
Так что в ряде случаев более эффективными, чем std::map будут простые вектора, хэш-таблицы или деревья на основе B+ деревьев.
M>Ну извини , если тебе слышится апломб , тогда это не ко мне . скорее к психологу.
Ну извини, если тебе слышится в моих словах фанатичное неприятие boost-а. Тогда это не ко мне...
M>Я не пониамаю тебя. Буст стремится объеденить лучшее что есть в индустрии с оглядкой на принцыпы залорженные в C++ и его библиотеках. Если есть билиотека решающая поставленные задачи лучеш чем решение в бусте , я не вижу причин по которым бы эта библиотека не вытеснила бустовскую и не заняла ее место.
Поскольку в параллельных мирах эти же вопросы решают совсем по другому. В Ruby есть RubyGems, в Java есть Maven2. Селекция библиотек производится путем естественного отбора. Пользователи сами делают что-то де-факто стандартом предпочитая один RubyGem другому.
Мне подобная схема более симпатична и близка, чем монолитный Boost с редкими релизами и процедурами review.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, skeptik_, Вы писали:
E>>>>Понятно. Попробуй устроится в контору с нормальным уровнем разработки на C++.
_>>>Спасибо, я уж как-нибудь дальше фрилансером. И денег в три раза больше, и свободы.
E>>Как, тебе хватает $100 в месяц?
_>Мне хватает 70 евро в час.
Где же ты таких лохов находишь?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, skeptik_, Вы писали:
E>>>>>Понятно. Попробуй устроится в контору с нормальным уровнем разработки на C++.
_>>>>Спасибо, я уж как-нибудь дальше фрилансером. И денег в три раза больше, и свободы.
E>>>Как, тебе хватает $100 в месяц?
_>>Мне хватает 70 евро в час.
E>Где же ты таких лохов находишь?
Ась? Стандартная ставка для специалиста с уровнем выше среднего вообще-то...
Здравствуйте, skeptik_, Вы писали:
E>>>>Как, тебе хватает $100 в месяц?
_>>>Мне хватает 70 евро в час.
E>>Где же ты таких лохов находишь?
_>Ась? Стандартная ставка для специалиста с уровнем выше среднего вообще-то...
Так тож для специалистов. Да еще уровнем выше среднего...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Её тормознутость как раз от гибкости-то и происходит! Ибо она учтёт при конвертировании все пожелания твоей локали. Это надо понимать, решая, юзать её, или что-то другое. Впрочем в 90% случаев её скорости вполне достаточно. А если у тебя формат жёстко задан -- ясен пень, что специализированный парсер её обгонит. Короче, опять же слабое понимание возможностей и потребностей.
