Здравствуйте, Erop, Вы писали:
E>IMHO, эти вопросы не связаны, но если таки связь пытаться найти, то твой аргумент имеет обраьную силу. E>ДАЖЕ АВТОР ТАКОГО ОТСТОЙНОГО КОДА ВИДИТ УБОГОСТЬ КАЧЕСТВА БУСТа
Или наоборот — автор такого отстойного кода берется оценивать качество буста
но это все офтопик
На всякий случай извиняюсь перед Клюевым, ему наверняка неприятна эта тема
Здравствуйте, minorlogic, Вы писали:
M>Мне кажется у тебя технические вопросы переходят в разрад религиозных. M>"противники" STL, boost, и итераторов звучит как противники ложек и вилок или китайских палочек.
У тебя -- да
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Erop, Вы писали:
E>>IMHO, эти вопросы не связаны, но если таки связь пытаться найти, то твой аргумент имеет обраьную силу. E>>ДАЖЕ АВТОР ТАКОГО ОТСТОЙНОГО КОДА ВИДИТ УБОГОСТЬ КАЧЕСТВА БУСТа J>Или наоборот — автор такого отстойного кода берется оценивать качество буста J>но это все офтопик
это все не обьективные критерии. в сухом остатке мы имеем:
велосипед:
+ эффективная реализация
— тестировался не во всех use case, в некоторых случая работает неправильно.
boost:
— неэфективная реализация
+ тестирован во всех use case
велосипед при этом вполне можно довести до ума дополнительным теститрованием и незначительными изменениями.
код из boost можно только переписать с нуля, т.к. это не код даже, а обертка вокруг iostream.
Здравствуйте, Kluev, Вы писали:
K>это все не обьективные критерии. в сухом остатке мы имеем:
K>велосипед: K>+ эффективная реализация K>- тестировался не во всех use case, в некоторых случая работает неправильно.
K>boost: K>- неэфективная реализация K>+ тестирован во всех use case
K>велосипед при этом вполне можно довести до ума дополнительным теститрованием и незначительными изменениями. K>код из boost можно только переписать с нуля, т.к. это не код даже, а обертка вокруг iostream.
и? какой вывод? boost::lexical_cast не для мест, где важна скорость? Так это и так было всем известно.
И в таких местах оттестированность, простота и ясность кода важнее.
А для тех мест, где критична производительность, все равно все будут писать свои велосипеды, потому что в каждом случае нужно будет что-то свое, всегда будут какие-то особенности (которые можно (и нужно!) использовать в целях оптимизации). И эти велосипеды, как в твоем случае, будут оттестированы только в тех конкретных случаях, для которых они написаны.
Вроде, очевидные вещи говорю, и сомневаюсь, что ты сам это все не можешь сказать.
Another aspect was that OTL is still a one-man project. I was hoping that by now (it's 2008!) the C++ standardization committee would have come up with a decent standard for a C++ database access library (hopefully something stream based), and I'd have joined a larger team of architects and developers working on that task. The C++ standardization effort is represented by the "boost(.org) crowd" for the most part. The boost people, instead of making any progress, just bitch and moan that "database people" don't know enough about how C++ is supposed to be used, at least OTL is not up to their high standards, it's just a hack.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Another aspect was that OTL is still a one-man project. I was hoping that by now (it's 2008!) the C++ standardization committee would have come up with a decent standard for a C++ database access library (hopefully something stream based), and I'd have joined a larger team of architects and developers working on that task. The C++ standardization effort is represented by the "boost(.org) crowd" for the most part. The boost people, instead of making any progress, just bitch and moan that "database people" don't know enough about how C++ is supposed to be used, at least OTL is not up to their high standards, it's just a hack.
Этому "камешку" определенно не хватает ссылок на соответствующие высказывания "boost people".
Быстрый поиск "OTL" по мейл-листу ничего подобного не показал (я намеренно выбрал только сообщения от людей, которые имеют вес в бусте (и нашел только одного — Джеффа Гарланда, одного из модераторов мейл-листа), хотя, напоминаю, буст — это open source, так что предлагать библиотеки и писать отзывы может каждый, и таких отзывов там очень много): http://article.gmane.org/gmane.comp.lib.boost.devel/80291/match=otl http://article.gmane.org/gmane.comp.lib.boost.devel/111888/match=otl
I'd really like to somehow see the authors of DTL, OTL, etc come together and work on a boost proposal. Each of these libraries in my view brings something to the table -- including baggage. If we could get all the experts pulling together I'm sure they would produce something great for the larger C++ community in fairly short order.
несколько противоречит высказыванию Сергея, не находишь?
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>Ждем ссылку, которая подтвердит слова Сергея.
E>Этой ссылки может не быть, если подобная оценка была получена Сергеем в частной переписке или личной беседе.
т.е. ты считаешь, что в бусте такие вот страшные двуличные интриганы сидят, которые во всеуслышание заявляют, что OTL — хорошая библиотека и было бы клево, если бы ее автор с другими сделал "золотой стандарт", а в частной переписке его гнобят?
Здравствуйте, jazzer, Вы писали:
E>>Этой ссылки может не быть, если подобная оценка была получена Сергеем в частной переписке или личной беседе.
J>т.е. ты считаешь, что в бусте такие вот страшные двуличные интриганы сидят, которые во всеуслышание заявляют, что OTL — хорошая библиотека и было бы клево, если бы ее автор с другими сделал "золотой стандарт", а в частной переписке его гнобят?
Я думаю, что было как-то так: кто-то из boost-оводов в личной беседе с Кучиным высказался в том духе, что было бы хорошо иметь стандартную библиотеку для C++. С идеями, в том числе, из OTL. Но сама OTL не потянет на роль такой библиотеке, т.к. представляет из себя набор хаков, и не соответствует требованиям, предъявляемым boost-ом к своим библиотекам.
И я не вижу здесь противоречий: boost-оводы хотят, чтобы Кучин занялся разработкой стандартной библиотеки для C++, но им не нравится реализация OTL (о последнем и говорит Кучин).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
E>>>Этой ссылки может не быть, если подобная оценка была получена Сергеем в частной переписке или личной беседе.
J>>т.е. ты считаешь, что в бусте такие вот страшные двуличные интриганы сидят, которые во всеуслышание заявляют, что OTL — хорошая библиотека и было бы клево, если бы ее автор с другими сделал "золотой стандарт", а в частной переписке его гнобят?
E>Я думаю, что было как-то так: кто-то из boost-оводов в личной беседе с Кучиным высказался в том духе, что было бы хорошо иметь стандартную библиотеку для C++. С идеями, в том числе, из OTL. Но сама OTL не потянет на роль такой библиотеке, т.к. представляет из себя набор хаков, и не соответствует требованиям, предъявляемым boost-ом к своим библиотекам.
Если у тебя есть контакт с Сергеем, можешь спросить его об этом? А то что мы гадаем на кофейной гуще...
E>И я не вижу здесь противоречий: boost-оводы хотят, чтобы Кучин занялся разработкой стандартной библиотеки для C++, но им не нравится реализация OTL (о последнем и говорит Кучин).
не Кучин, а Кучин сотоварищи, т.е. разработчики других библиотек.
Так как, очевидно, они на этом собаку съели (Кучин сотоварищи, а не бустоводы).
Поэтому бустоводы хотят, чтобы они все "сели за стол переговоров" (в общем мейллисте), обсудили честно все достоинства и недостатки каждой из библиотек (а их там полтора десятка), вместе сформулировали бы требования и вместе написали бы библиотеку, которая утрет нос всяким LINQ и станет стандартом де-факто для общения на C++ с любыми базами данных, заслужив себе всемирный почет и уважуху. Никто лучше авторов заслуженных библиотек (включая OTL) этого не сделает.
Имхо, Гарланд сказал ровно эти слова, и про качество конкретно OTL он ничего отрицательного не говорил (по крайней мере, цитаты не видно).
Но, естественно, прежде чем включить ее в буст, нужно сначала доказать, что она лучше всех остальных (т.е. по крайней мере умеет все то, что умеет остальные, либо делает оправданный выбор, если удовлетворить всем целям одновременно невозможно) и, естественно, нужно ее привести в соответствие с бустовскими стандартами (которые совсем не драконовские, см. здесь: http://www.boost.org/development/requirements.html).
И, ксатти, насчет доказательства лучшести — тут совсем не будут играть роли личные пристрастия бустоводов, просто как только библиотека будет выложена на ревью, люди, пользующие другие библиотеки (которые им, понятное дело, нравятся), скажут, что они голосуют против, пока предложенная библиотека не будет уметь все то же, что умеет та, которой они сейчас пользуются (вполне логичное требование, иначе зачем переходить, правильно?)
Ну и, естественно, это будет совсем нелегко, но Сергей почему-то не говорит о том, что у него просто нет времени и сил на прохождение полномасштабного ревью (что совершенно понятно и, к сожалению, является причиной стагнации многих библиотек), как о причине того, что OTL не предложена в буст, а говорит о том, что его обидели.
Но без ревью нельзя, иначе это будет не boost (a collection of peer-reviewed libraries), а просто очередной зоопарк типа sourceforge — так у нас sourceforge уже есть, зачем их одинаковые плодить...
Здравствуйте, jazzer, Вы писали:
J>Если у тебя есть контакт с Сергеем, можешь спросить его об этом? А то что мы гадаем на кофейной гуще...
Я ему написал на gmail, но ответа пока нет. Может google мои письма в спам заносит, такое временами случается с буржуинскими почтовиками -- письма из .ru домена в спам автоматом направляют
J>Поэтому бустоводы хотят, чтобы они все "сели за стол переговоров" (в общем мейллисте), обсудили честно все достоинства и недостатки каждой из библиотек (а их там полтора десятка), вместе сформулировали бы требования и вместе написали бы библиотеку, которая утрет нос всяким LINQ и станет стандартом де-факто для общения на C++ с любыми базами данных, заслужив себе всемирный почет и уважуху. Никто лучше авторов заслуженных библиотек (включая OTL) этого не сделает.
Я не верю с то, что коллегиально можно делать такие вещи. Самые хорошие разработки (тот же STL) начинаются с идей конкретных людей и желания их воплотить. Ты сам можешь увидеть это на примере ряда бустовских библиотек, в частности, Boost.Regex.
Но тут проблема в том, что разработчики двух действительно живущих и развивающихся библиотек для работы с РСУБД из C++ (SOCI и OTL) уже воплотили свое видение того, как нужно работать с БД. И у них совершенно разные подходы. Я не верю в то, что дизайнеры SOCI и OTL смогут совместно родить какой-нибудь жизнеспособный стандарт для C++. Тем более сделать это дистанционно общаясь друг с другом через mailing-list.
Так что, когда речь заходит о более-менее прикладных областях, у Boost-а небольшой выбор: либо ждать, пока кто-нибудь решиться родить библиотеку специально для Boost-а (как это было с Boost.Asio), либо адаптировать одну из существующих библиотек, а их не так уж и много.
J>Но без ревью нельзя, иначе это будет не boost (a collection of peer-reviewed libraries), а просто очередной зоопарк типа sourceforge — так у нас sourceforge уже есть, зачем их одинаковые плодить...
Теперь я еще лучше стал понимать, что мне не нравится в Boost-е: они замахнулись на создание "единственно-правильного" зоопарка. Мол мы сейчас отберем библиотеки, они войдут в стандарт языка и будет всем счастье.
Это еще может прокатывать для универсальных вещей, вроде Boost.Bind и Boost.Regex. Но когда речь заходит о более серьезных предметных областях (таких как Asio, доступ к БД, XML, SOAP и пр.) не правильно, имхо, вообще пытаться создавать стандарты. Поскольку:
— стандарт должен быть статичен. А это значит, что стандартная библиотека не будет успевать за изменениями окружающего мира. Например, сделают версию Boost.DB -- а из нее стандартную в каком-нибудь tr2. А потом выяснится, что РСУБД поумнели, пологовно стали объектно-реляционными, добавили специализированные (может быть даже стандартизированные на таком же уровне как SQL) средства для работы с географическими и/или историческими данными. Стандартная библиотека в принципе не сможет меняться с необходимой скоростью. Тогда как независимо существующие библиотеки смогут делать это все;
— стандарт оставляет место для откровенно провальных реализаций. Тот же STL из каробки в VC++ сливает в некоторых случаях STL из gcc. Получается, что если хочешь иметь эффективный STL везде, то таскай с собой STLPort. А раз так, то не суть важно, что STLPort реализует стандартный STL, все равно программа зависит от конкретной библиотеки (особенно, если еще и задействовать hash_map-ы, которых нет в STL вообще). Точно так же можно иметь быструю программу, использующую std::tr2::db под Unix-ом, которая начнет тормозить под VC++ из-за того, что у VC++ своя реализация std::tr2::db.
— стандарт будет душить конкуренцию. Сейчас есть ряд библиотек, конкурирующих между собой (для IPC это, например, ACE, Poco, Boost). И это хорошо, так как происходит не только взаимное проникновение идей, но и предложение каждой из них каких-то своих уникальных идей. Например, у ACE есть Procator-ы и TimerQueue, которых нет у конкурентов.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
J>>Если у тебя есть контакт с Сергеем, можешь спросить его об этом? А то что мы гадаем на кофейной гуще...
E>Я ему написал на gmail, но ответа пока нет. Может google мои письма в спам заносит, такое временами случается с буржуинскими почтовиками -- письма из .ru домена в спам автоматом направляют
у меня у самого ящик на gmail, все письма из зоны ru без проблем доходят.
Ну, может, он нечасто его проверяет, или вообще занят сейцчас на работе...
E>Я не верю с то, что коллегиально можно делать такие вещи. Самые хорошие разработки (тот же STL) начинаются с идей конкретных людей и желания их воплотить. Ты сам можешь увидеть это на примере ряда бустовских библиотек, в частности, Boost.Regex. E>Но тут проблема в том, что разработчики двух действительно живущих и развивающихся библиотек для работы с РСУБД из C++ (SOCI и OTL) уже воплотили свое видение того, как нужно работать с БД. И у них совершенно разные подходы. Я не верю в то, что дизайнеры SOCI и OTL смогут совместно родить какой-нибудь жизнеспособный стандарт для C++. Тем более сделать это дистанционно общаясь друг с другом через mailing-list.
На примере буста — Boost.Fusion, Boost.MPL делали несколько человек, и обсуждение было именно в мейл-листах. Так что нет ничего невозможного.
Наверняка есть и другие "многоавторные" библиотеки, нет времени смотреть сейчас.
E>Так что, когда речь заходит о более-менее прикладных областях, у Boost-а небольшой выбор: либо ждать, пока кто-нибудь решиться родить библиотеку специально для Boost-а (как это было с Boost.Asio), либо адаптировать одну из существующих библиотек, а их не так уж и много.
и? у кого-то больший выбор?
J>>Но без ревью нельзя, иначе это будет не boost (a collection of peer-reviewed libraries), а просто очередной зоопарк типа sourceforge — так у нас sourceforge уже есть, зачем их одинаковые плодить...
E>Теперь я еще лучше стал понимать, что мне не нравится в Boost-е: они замахнулись на создание "единственно-правильного" зоопарка. Мол мы сейчас отберем библиотеки, они войдут в стандарт языка и будет всем счастье.
Ну то есть ты в принципе против стандартной библиотеки как таковой, независимо от того, кем и как она делается
Я тебе этот вопрос уже задавал в прошлой нашей дискуссии, но ты на него тогда не ответил, сейчас, похоже, наконец отвечаешь
E>— стандарт должен быть статичен.
Версии стандата никуда не делись. И deprecation тоже никуда не делась, можешь посмотреть в текущем драфте, сколько уехало туда.
E>— стандарт оставляет место для откровенно провальных реализаций.
И что?
Он и для откровенно провальных реализаций компиляторов оставляет место, вспомни борландовские и сановские компиляторы. Это вообще не в компетенции стандарта. И не зависит от стандарта вообще, скажем, в мире дофига отстойных читалок и нечитабельных файлов XML — так что, в этом стандарт XML виноват? Или там дофига отстойных COM-объектов. Или там дофига браузеров — так что, в качестве плохих браузеров виноват стандарт HTML, который описывает, как страничка должна рендериться? Стандарт С++ — это то же, что и стандарт HTML: описан интерфейс и обязательные правила (в случае стандартной библиотеки — асимптотическая сложность алгоритмов), а в их рамках — вертись как хочешь.
E>— стандарт будет душить конкуренцию.
Почему-то наличие в стандарте std::auto_ptr не задушило Boost.SmartPtr, std::map — Boost.MultiIndex, std::list — Boost.Intrusive, std::string — Boost.StringAlgo, std::iostream — Boost.Iostream, а std::bind1st сотоварищи — Boost.Bind и Boost.Lambda (список можно дальше продолжать). Более того, Boost.Bind теперь в стандарте, а std::bind1st — deprecated. А Boost.Lambda — не в стандарте, и опять же не видно, чтоб Boost.Bind и Boost.Lambda сильно между собой дрались, наоборот, они взаимно обогащаются, например, Boost.Bind с версии 1.33 стал поддерживать операторы (то, что изначально было в Boost.Lambda), так что можно в простых случаях обойтись простым байндом (который поддерживается практически всеми существующими компиляторами) там, где раньше нельзя было и приходилось юзать тяжелую лямбду или писать свой функтор.
А еще ближе пример — Клюев и Егор, которых существующий уже 10 лет STL не душит никак — они сидят себе на своих библиотеках (конкурирующих с STL) и дальше будут сидеть.
Да и в Java, например, был стандартный JDBC — и ничего, Hibernate не задушился от этого, вполне себе цветет и пахнет.
Так что не надо сгущать краски и наделять стандарт сверхъестественными полицейскими способностями.
Здравствуйте, jazzer, Вы писали:
E>>Так что, когда речь заходит о более-менее прикладных областях, у Boost-а небольшой выбор: либо ждать, пока кто-нибудь решиться родить библиотеку специально для Boost-а (как это было с Boost.Asio), либо адаптировать одну из существующих библиотек, а их не так уж и много.
J>и? у кого-то больший выбор?
Имхо, это вообще не правильный подход -- делать что-то для Boost-а для того, чтобы затем это попало в стандарт. Но, см. ниже.
J>Ну то есть ты в принципе против стандартной библиотеки как таковой, независимо от того, кем и как она делается
К стандартам у меня настороженное отношение. В особенности, из-за ODMG-93. Да и сейчас SQL хорошим примером является
J>Я тебе этот вопрос уже задавал в прошлой нашей дискуссии, но ты на него тогда не ответил, сейчас, похоже, наконец отвечаешь
Я так отвечу: после стольких лет существования откровенно маленькой стандартной библиотеки C++ делать попытку создать большую новую стандартную библиотеку для C++ не разумно. На мой взгляд, более разумный путь в том что-бы:
— обновлять стандартную библиотеку некоторыми общеупотребительными компонентами (вроде того, как это сделано в std::tr1, разве что без regex). Делать это нужно периодически с относительно малым периодом (1.5-2 года);
— строить и развивать систему, позволяющуюю подключать в C++ проекты разные библиотеки. Для того, чтобы не было таких монстров, как 10-мегабайтный ACE, 20-мегабайтный Boost, 10-мегабайтный ICU и т.д. Скажем, если мне нужен boost::move и boost::string_algo, я должен подключить именно их (+необходимые им зависимости). Для того, чтобы подобная система работала нужны какие-то унифицированные системы сборки и системы управления пакетами, средства адаптации под особенности платформы (то бишь autoconf must die! ).
Такая организация мне больше нравится, чем концентрация усилий части C++ников вокруг Boost-а. При том, что есть часть C++ников, которая не может использовать существующий Boost по ряду объективных и субъективных причин.
Надеюсь, что я ответил на твой вопрос. Если нет -- то спрашивай еще, я с удовольствием отвечу.
E>>— стандарт должен быть статичен. J>Версии стандата никуда не делись. И deprecation тоже никуда не делась, можешь посмотреть в текущем драфте, сколько уехало туда.
Стандарт в принципе не способен развиваться быстрее, чем отдельная библиотека, которую каждый день терзают заинтересованные пользователи.
E>>— стандарт оставляет место для откровенно провальных реализаций. J>И что? J>Он и для откровенно провальных реализаций компиляторов оставляет место, вспомни борландовские и сановские компиляторы. Это вообще не в компетенции стандарта.
Тем не менее, смотри что получается: сейчас люди создают работающие библиотеки, которые тестируются в составе Boost-а. У них нормальная реализация, которая постоянно шлифуется. Затем она попадает в стандарт. Какой-нибудь MS делает ее свою реализацию. В чем смысл создания других реализаций?
А если все используют одни и те же исходники, то в чем смысл стандартизации вообще?
E>>— стандарт будет душить конкуренцию. J>Почему-то наличие в стандарте std::auto_ptr не задушило Boost.SmartPtr,
Я, например, про Boost.SmartPtr не знал. Или под этим shared_ptr скрывается?
J> std::map — Boost.MultiIndex, std::list — Boost.Intrusive, std::string — Boost.StringAlgo
Имхо, это вообще не конкуренты. Конкурент std::map-а -- это, например, ACE_Map_Manager.
J>А еще ближе пример — Клюев и Егор, которых существующий уже 10 лет STL не душит никак — они сидят себе на своих библиотеках (конкурирующих с STL) и дальше будут сидеть.
STL вообще достаточно специфичен -- та его часть, которая касается контейнеров, вообще не имеет себе равных, имхо. Это именно то, что нужно было для C++. Но, с другой стороны, std::string и iostream далеко не самые удачные примеры. И более удобный класс строк, например, не помешал бы. Да только где он?
J>Да и в Java, например, был стандартный JDBC — и ничего, Hibernate не задушился от этого, вполне себе цветет и пахнет.
Имхо, JDBC и Hibernate на разных полюсах находятся.
J>Так что не надо сгущать краски и наделять стандарт сверхъестественными полицейскими способностями.
Я всего лишь выражаю свои опасения, что для ряда предметных областей наличие стандарта не даст ничего хорошего. К БД это в частности и относится.
Ну не будет у C++ таких средств, чтобы сделать конкурента JDBC, не говоря уж о LINQ. А делать для стандарта что-нибудь лишь бы для стандарта так же не очень правильно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>- строить и развивать систему, позволяющуюю подключать в C++ проекты разные библиотеки. Для того, чтобы не было таких монстров, как 10-мегабайтный ACE, 20-мегабайтный Boost, 10-мегабайтный ICU и т.д. Скажем, если мне нужен boost::move и boost::string_algo, я должен подключить именно их (+необходимые им зависимости). Для того, чтобы подобная система работала нужны какие-то унифицированные системы сборки и системы управления пакетами, средства адаптации под особенности платформы (то бишь autoconf must die! ).
Здравствуйте, Mamut, Вы писали:
E>>- строить и развивать систему, позволяющуюю подключать в C++ проекты разные библиотеки. Для того, чтобы не было таких монстров, как 10-мегабайтный ACE, 20-мегабайтный Boost, 10-мегабайтный ICU и т.д. Скажем, если мне нужен boost::move и boost::string_algo, я должен подключить именно их (+необходимые им зависимости). Для того, чтобы подобная система работала нужны какие-то унифицированные системы сборки и системы управления пакетами, средства адаптации под особенности платформы (то бишь autoconf must die! ).
M>Perl CPAN/Ruby Gems но для С++?
Именно!
M>Было бы здорово
Ну вот, а я уж начал думать, что никому кроме меня это не нужно
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
M>>Было бы здорово
E>Ну вот, а я уж начал думать, что никому кроме меня это не нужно
Многие просто не знают/не догадываются, что это такое и насколько это удобно. Интересно, что даже PHP Обзавелся таким механизмом Установка нового расширения в РНР выполняется так:
Здравствуйте, Mamut, Вы писали:
E>>Ну вот, а я уж начал думать, что никому кроме меня это не нужно
M>Многие просто не знают/не догадываются, что это такое и насколько это удобно.
Мне кажется, что здесь не все так просто. Дело в том, что как я смог понять, далеко не все программисты заняты разработкой кроссплатформенных проектов. Многим просто не нужно выходить за рамки VC++ или Linux/BSD. Поэтому те, кто сидят под VC++ хотят иметь в сторонних библиотеках sln-файлы и все. А unix-оиды хотят пользоваться своими родными системами управления пакетами (apt, rpm, portage, pkgsrc и пр.)
Начал отвечать с конца, а уже вечер пятницы, так что отправляю то, что есть, на первую половину отвечу позже
E>Тем не менее, смотри что получается: сейчас люди создают работающие библиотеки, которые тестируются в составе Boost-а. У них нормальная реализация, которая постоянно шлифуется. Затем она попадает в стандарт. Какой-нибудь MS делает ее свою реализацию. В чем смысл создания других реализаций?
E>А если все используют одни и те же исходники, то в чем смысл стандартизации вообще?
Ну вот апач делает свою реализацию, которая, с одной стороны, поддерживает стандарт, а с другой — явно специфицирует определенные вещи, необходимые для них.
Суть в том, что, взяв любую реализацию STL (если в ней нет багов, естественно), ты получишь все гарантии, которые есть в стандарте, и твоя программа, написанная по правилам стандарта, будет работать без проблем. Но если ты берешь конкретную реализацию, ты в дополнение к требованиям стандарта получаешь еще и обещания этой конкретной реализации (типа многопоточности, или распараллеливания, или строки со счетчиками ссылок).
E>>>— стандарт будет душить конкуренцию.
J>>Почему-то наличие в стандарте std::auto_ptr не задушило Boost.SmartPtr, E>Я, например, про Boost.SmartPtr не знал. Или под этим shared_ptr скрывается?
И shared_ptr, и unique_ptr, и intrusive_ptr — это коллекция умных указателей. И наверняка она продолжит развиваться, добавится какой-нть linked_ptr...
J>> std::map — Boost.MultiIndex, std::list — Boost.Intrusive, std::string — Boost.StringAlgo E>Имхо, это вообще не конкуренты. Конкурент std::map-а -- это, например, ACE_Map_Manager.
Ну почему же не конкуренты. Мульти-индекс вполне можно сделать на нескольких мапах, геморно, правда, но можно.
А мульти-индекс с одним уникальным упорядоченным индексом — это std::map и есть (только лучше)
J>>А еще ближе пример — Клюев и Егор, которых существующий уже 10 лет STL не душит никак — они сидят себе на своих библиотеках (конкурирующих с STL) и дальше будут сидеть.
E>STL вообще достаточно специфичен -- та его часть, которая касается контейнеров, вообще не имеет себе равных, имхо. Это именно то, что нужно было для C++. Но, с другой стороны, std::string и iostream далеко не самые удачные примеры. И более удобный класс строк, например, не помешал бы. Да только где он?
Так может, он и не нужен?
Та эволюция, которую я наблюдаю, сводится к тому, чтобы предоставить 1) разнообразные контейнеры для разных вариантов использования, и 2) разнообразные алгоритмы для работы с этими контейнерами. Т.е. контейнер, параметризованный char/wchar_t, и представляет собой строку, а алгоритмы, соответственно, будут осуществлять необходимые операции, типа поиска по регэкспам, выделение подстрок и т.п.
А один класс, который бы включал в себя все на свете, не особо и нужен получается.
В любом случае, как видишь, никакой конкуренции стандарт не душит, по крайней мере, я не вижу ясного подтвержения этому душению.
J>>Так что не надо сгущать краски и наделять стандарт сверхъестественными полицейскими способностями.
E>Я всего лишь выражаю свои опасения, что для ряда предметных областей наличие стандарта не даст ничего хорошего. К БД это в частности и относится. E>Ну не будет у C++ таких средств, чтобы сделать конкурента JDBC, не говоря уж о LINQ. А делать для стандарта что-нибудь лишь бы для стандарта так же не очень правильно.
Почему же не даст? Вот есть стандарт SQL, который поддерживают все существующие СУБД. Что может быть плохого в том, чтобы иметь библиотеку, которая подерживает этот стандарт? Чтобы ты мог писать код, который не зависит от того, к какой СУБД ты подключился, пока тебе не понадобится специфика конкретной СУБД?
Здравствуйте, jazzer, Вы писали:
J>Почему же не даст? Вот есть стандарт SQL, который поддерживают все существующие СУБД. Что может быть плохого в том, чтобы иметь библиотеку, которая подерживает этот стандарт? Чтобы ты мог писать код, который не зависит от того, к какой СУБД ты подключился, пока тебе не понадобится специфика конкретной СУБД?
Мне редко приходится работать с SQL, но когда приходится, то выясняется, что такой вещи, как "стандартный SQL" нет. Для эффективной работы с конкретной СУБД требуется использовать конкретные диалекты конкретной СУБД. Например, сейчас мне приходится поддерживать код для MSSQL и Oracle, так там разные SQL-и для всего: и для схемы данных (определение полей автоинкремента и индексов), и для select-ов, и для delete.
Возвращаясь к OTL -- как раз ее достоинство в том, что она не прячет деталей работы с конкретными СУБД.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, jazzer, Вы писали:
J>Ну вот апач делает свою реализацию, которая, с одной стороны, поддерживает стандарт, а с другой — явно специфицирует определенные вещи, необходимые для них. J>Суть в том, что, взяв любую реализацию STL (если в ней нет багов, естественно), ты получишь все гарантии, которые есть в стандарте, и твоя программа, написанная по правилам стандарта, будет работать без проблем. Но если ты берешь конкретную реализацию, ты в дополнение к требованиям стандарта получаешь еще и обещания этой конкретной реализации (типа многопоточности, или распараллеливания, или строки со счетчиками ссылок).
Так вот меня это все и вводит в ступор: вот есть стандарт, хочешь писать переносимо, то придерживайся стандарта. При этом при переходе с компилятора на компилятор ты можешь как выиграть в производительности, так и проиграть.
Если же нужно что-то не стандартное, то приложение завязывается на конкретную реализацию STL (будь то STLPort или Apache) и все -- стандарт нафиг.
При этом STLPort будет крутить STL в свою сторону, а Apache в свою.
Я еще могу понять, что когда STL появился и писался стандарт, еще не было такой широкой практики OpenSource проектов. Поэтому возникло несколько реализаций STL от разных производителей. Но сейчас то в чем смысл стандартизации части Boost-а?
Ну вот есть, скажем, Boost.Regex. Какой смысл делать несколько его реализаций под эгидой стандарта? Не лучше ли развивать Boost.Regex дальше. Что бы не было одного де-юре стандарта и нескольких де-факто реализаций со своими тараканами. Была бы одна реализация, которая и явилась бы де-юре и де-факто стандартом Boost.Regex.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
