Здравствуйте, night beast, Вы писали:
E>>А во многих случаях не нужен std::string. Я подсмотрел хорошее решение в библиотеке PCRE -- там есть класс StringPiece, разработанный для C++ной обертки PCRE в Google. Я сделал из него для себя вариант. Он не такой функциональный, как Google-овский, зато у него есть шаблонные конструкторы специально для строковых литералов.
NB>не сочти за придирку, но строковые литералы с С++ передаются по ссылке: NB>
NB> template< size_t LEN >
NB> string_piece_t( const char(&ptr)[ LEN ] )
NB>
NB>хотя в данном случае сработает не-шаблонный конструктор...
Большое спасибо!
Постарался исправить и залил новую версию.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, jazzer, Вы писали:
J>Апачевская либа работает не очень? J>Что не так?
Копеировать тело можно и пореже.
E>>Ну, например, посмори на CString... J>Ну, у меня его под рукой нет, как ты понимаешь, но я помню, что там можно было строки изменять, в том числе и конкретные символы. J>Но поскольку ты под винду пишешь — так и быть, верю, хоть и странно
Есть специальные методы для модификации.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, minorlogic, Вы писали: M>Здравствуйте, eao197, Вы писали: M>Егор , учи матчасть. Объект передается по ссылке. икаких копирований нет .
Я тебе уже снюсь?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, night beast, Вы писали:
E>>Большое спасибо!
NB> ну это не ошибка была.
Как по мне, так это была большая ошибка. Т.к. шаблонные конструкторы не отрабатывали там, где должны были.
E>>Постарался исправить и залил новую версию.
NB>ну еще тебя потерраризирую NB>попробуй код NB>
NB>string_piece_t x (0);
NB>
Пока нечего не приходит в голову, как это обойти.
В принципе, такое поведение можно считать by design, так же, как это происходит в std::string.
Тем более, что вот в таком случае:
const char * p = 0;
string_piece_t x( p );
отрабатывает нормально.
Разве что добавить private конструктор string_piece_t(int).
NB>и еще вопрос, почему бы не сделать NB>
NB> static const int no_type = 0;
NB> static const int string_literal = 1;
NB> static const int null_terminated = 2;
NB> static const int std_basic_string = 3;
NB> static const int array_fragment = 4;
NB>
NB>enum'ом?
А разницы все равно большой нет. Тем более, что это все используется только в unit-тесте проверки string_piece_t.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
не знаю только, стоит ли овчинка выделки.
NB>>и еще вопрос, почему бы не сделать
NB>> static const int no_type = 0;
NB>> static const int string_literal = 1;
NB>> static const int null_terminated = 2;
NB>> static const int std_basic_string = 3;
NB>> static const int array_fragment = 4;
NB>>enum'ом?
E>А разницы все равно большой нет. Тем более, что это все используется только в unit-тесте проверки string_piece_t.
так бы в одну строчку влезло да и тип свой был бы...
ну а что до юнит тестов, то есть ли большая разница, пишешь ты юнит-тест или прикладную программу?
class string_piece_t {
private :
string_piece_t(int);
public : ...
};
Посольку этот конструктор будет задействоваться только для случая string_piece_t(0). А литерал 0, если не ошибаюсь, имеет тип int по умолчанию.
И лучше подобный конструктор объявлять в private секции, чтобы ошибку выдавал компилятор, а не линкер.
Disclaimer: все это я излагаю в предположении, что конструкция string_piece_t(0) является ошибочной по определению, и компилятор сразу должен указывать разработчику на это.
NB>>>и еще вопрос, почему бы не сделать NB>
NB>>> static const int no_type = 0;
NB>>> static const int string_literal = 1;
NB>>> static const int null_terminated = 2;
NB>>> static const int std_basic_string = 3;
NB>>> static const int array_fragment = 4;
NB>
NB>>>enum'ом?
E>>А разницы все равно большой нет. Тем более, что это все используется только в unit-тесте проверки string_piece_t.
NB>так бы в одну строчку влезло да и тип свой был бы...
Да я просто не большой любитель enum-ов в C++.
NB>ну а что до юнит тестов, то есть ли большая разница, пишешь ты юнит-тест или прикладную программу?
К unit-тестам я предъявляю гораздо более низкие требования, чем к прикладной программе. Так что разница, наверное, есть.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Посольку этот конструктор будет задействоваться только для случая string_piece_t(0). А литерал 0, если не ошибаюсь, имеет тип int по умолчанию.
E>И лучше подобный конструктор объявлять в private секции, чтобы ошибку выдавал компилятор, а не линкер.
E>Disclaimer: все это я излагаю в предположении, что конструкция string_piece_t(0) является ошибочной по определению, и компилятор сразу должен указывать разработчику на это.
я писал исходя из обратного предположения
у тебя же
char * x = 0;
string_piece_t y(x);
нормально работает? почему тогда string_piece_t (0) не должен работать?
можно было сделать его дефолтным конструктором.
Здравствуйте, night beast, Вы писали:
E>>Disclaimer: все это я излагаю в предположении, что конструкция string_piece_t(0) является ошибочной по определению, и компилятор сразу должен указывать разработчику на это.
NB>я писал исходя из обратного предположения NB>у тебя же NB>
NB>char * x = 0;
NB>string_piece_t y(x);
NB>
NB>нормально работает? почему тогда string_piece_t (0) не должен работать?
Из-за какой-то ошибки make_some_name может возвратить нулевой указатель, на этапе компиляции это отследить невозможно. Но string_piece_t при вызове f() не должен ломаться из-за этого. И эта ситуация сейчас в string_piece_t обрабатывается.
А вот когда разработчик в коде пишет явно string_piece_t(0), то здесь вообще не понятно, зачем это ему нужно, скорее всего это следствие ошибки разработчика. Пустой string_piece_t можно получить и существующим конструктором по умолчанию -- это будет явно выглядеть в коде как создание пустой строки. Поэтому и хочется поставить конструкцию string_piece_t(0) вне закона. А то сейчас можно написать std::string(0), но ничего хорошего из этого не получается.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, landerhigh, Вы писали:
L>>Здравствуйте, Erop, Вы писали:
L>>>>>>2. Неясно, что будет, если разделитель — запятая. E>>>>>Ошибка формата будет. Тоже вроде как ясно... L>>>>А если надо пофискить? K>нет трудностей добавить запятую, так же легко передалеть эту функцию в шаблон и автоматом добавить поддержку юникода. K>дургое дело, что фиксить как раз не надо, т.к. ипользовать запятую как разделитель — идиотизм.
Это кто сказал? В России если мне не изменяет память стандартный разделитель — это запятая. Кстати, знаю одну очень страшную историю из жизни когда одну очень очень дорогую (а может даже не очень) но шибко навороченную биллинговую систему продали в Испанию. А там — представьте себе — законный разделитель это запятая. Даже в текстовых файлов. Как пришлось попотеть разработчикам...
П.С.
А это знаменитый баг в Accesse — когда надо было ставить системный разделитель точку поскольку Access не умел обрабатывать друнгие разделители в своем SQL...
Меня это обсуждение заставило задуматься. До этого я неявно воспринимал буст как набор качественного и оптимизированного кода, который некие неведомые высококлассные программисты делают для всеобщего пользования. Неявно — потому что я просто не задумывался над этим, просто вот было такое убеждение и все. Да и не так много чего из буста я использую — только указатели. Хотя казалось бы именно опыт с указателями был весьма наглядным. Я впервые посмотрел их лет пять назад и их реализация тогда меня несколько удивила — в многопоточной версии на каждый указатель создавалась своя критическая секция, мне это показалось подозрительным, я отложил это дело и продолжал пользоваться хорошо знакомым велосипедом. В итоге проблему решили, но ведь действительно, получается, что буст — это просто свалка разнородного кода, который находится в разной степени зрелости :) Какие-то вещи доведены до ума, потому что они важны и нужны, какие-то доводятся, а какие-то так и остаются в зачаточном состоянии. Что-то вылизано, а что-то лежит, просто потому что это положили :) Т.е. нельзя что-то просто взять и пользоваться, нет уверенности в качестве — любую нужную функциональность надо тщательно смотреть изнутри. Вот об этом я как-то раньше не думал и спасибо автору исходного сообщения за то, что поднял эту тему :)
Здравствуйте, eao197, Вы писали:
E>С другой стороны, не все пишут код, который потом индусы будут саппортить
Пишут-то, может, и не все, а вот не будут ли его потом саппортить индусы...
J>>А насчет библиотек — ну вокруг чего-то ведь надо концентрировать усилия, иначе ведь зоопарк будет. J>>Посмотри сам — ведь каждая библиотека считает своим долгом предоставить свои строки, контейнеры и прочая.
E>А собственно, почему бы и нет? Пусть развиваются как хотят -- хорошие библиотеки, предоставляющие удобные интерфейсы и качественные реализации будут выживать.
Интерфейсы должны быть совместимыми (или должен быть простой путь их совмещения, типа специализации boost::range). А так — конечно, пусть что угодно будет.
E>Более качественный подход, на мой взгляд -- это дать библиотеке самостоятельно жить до тех пор, пока она не станет достаточно распространенной сама по себе. А уже потом принимать решение о ее "иконизации" (как это было в Java с Log4J).
Ты, возможно, этого не ожидал, но ты чуть ли не цитируешь основополагающий документ Буста (http://www.boost.org/users/proposal.pdf, 1998 год, его стоит целиком прочитать):
(из FAQ) Will the libraries become part of the next C++ Standard? No. But to the extent a library becomes
“existing practice”, the likelihood increases that someone might propose it for future standardization.
Здравствуйте, jazzer, Вы писали:
J>Ты, возможно, этого не ожидал, но ты чуть ли не цитируешь основополагающий документ Буста (http://www.boost.org/users/proposal.pdf, 1998 год, его стоит целиком прочитать): J>
J>(из FAQ)
J>Will the libraries become part of the next C++ Standard? No. But to the extent a library becomes
J>“existing practice”, the likelihood increases that someone might propose it for future standardization.
Ну если глянуть на ряд библиотек, которые были приняты в Boost 1.34 и 1.35, то многие из них стали широко распространенными и достаточно взрослыми до включения в Boost? Или часть из них специально писалась под Boost?
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>Ты, возможно, этого не ожидал, но ты чуть ли не цитируешь основополагающий документ Буста (http://www.boost.org/users/proposal.pdf, 1998 год, его стоит целиком прочитать): J>>
J>>(из FAQ)
J>>Will the libraries become part of the next C++ Standard? No. But to the extent a library becomes
J>>“existing practice”, the likelihood increases that someone might propose it for future standardization.
E>Ну если глянуть на ряд библиотек, которые были приняты в Boost 1.34 и 1.35, то многие из них стали широко распространенными и достаточно взрослыми до включения в Boost? Или часть из них специально писалась под Boost?
Причем тут включение в Буст, когда мы говорим о включении в Стандарт? Давай не перескакивать с одного на другое. А чтобы попасть в стандарт, библиотека должна стать распространенной, независимо от того, в бусте она или нет — вот что написано в приведенной цитате.
Буст предложен просто как центральный репозиторий библиотек, оформленных в едином стиле (дабы облегчить будущую стандартизацию, если таковая запланируется), отревьюенных живыми действующими программистами (это не закрытый клуб, любой (и ты!) может написать свое ревью на любую предложенную библиотеку, и его голос, за или против, будет зачтен), а не левыми теоретиками, как тут некоторые любят говорить про буст.
Просто возьмите и почитайте наугад несколько обсуждений предложенных библиотек — и сами в этом убедитесь.
Например, очень часто появляются ревью в стиле "очень хорошо, что предложена такая библиотека, потмоу что у нас на раобте есть точно такая же велосипедная, так вот она лучше потому-то и потому-то", и дальше начинается бурное обсуждение, с бенчмарками и прочим. И так просто абы что ты не в буст не просунешь. И по результатам ревью (независимо от того, положительное оно или отрицательное) обычно выкатывается длиннющий список претензий, которые надо пофиксить перед коммитом или повторным предложением (например, библиотека для логирования прошла уже два ревью и до сих пор не принята: http://thread.gmane.org/gmane.comp.lib.boost.announce/182).
E>Asio, Circular Buffer, Foreach, Fusion, GIL, Interprocess, Intrusive, MPI, Math/Special Functions, Math/Statistical Distributions, Statechart, System, Typeof, Xpressive
Смотри в раздел History соответствующих библиотек. Я не историк буста. Из того ,чтоя знаю — GIL писалась адобом для себя, MPI уже тыщу лет как есть, Foreach — это вообще велосипед, который почти у каждого есть, MultiIndex была популярной библиотекой, но придя в boost, проапгрейдилась настолько, что концов уже и не видно (и, к слову сказать, достойных альтернатив не видно).
Xpressive, Fusion писались сразу для boost, как устранение проблем и расширение Spirit и MPL соответственно.
В любом случае, отношения к стандартизации это не имеет.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Kluev, Вы писали:
K>>Здравствуйте, degor, Вы писали:
D>>>как можно всерьез обсуждать кусок кода, который даже собрать без геморроя нельзя? тем более такой кусок, который жрет числа вида -.A и не давится?
K>>Вполне можно. Ты же сам понимаешь, что велосипеды доделываются согласно потребностям, а этот код без проблем отпарзил гигабайты данных за несколько лет K>>и оттестирован на всех возможных use case в реальных условиях.
M>Ты просто не понимаешь разницу между велосипедом и индустриальной библиотекой. Многие другие , достаточно серьезно относятся к качеству используемых библиотек.
индустриальной я бы назвал zlib и аналогичные библиотеки хорошо сделанные и внутри и снаружи. пользоватся такими одно удовольствие. а буст — сборище велосипедов сомнительного качества.
Здравствуйте, jazzer, Вы писали:
J>Причем тут включение в Буст, когда мы говорим о включении в Стандарт? Давай не перескакивать с одного на другое. А чтобы попасть в стандарт, библиотека должна стать распространенной, независимо от того, в бусте она или нет — вот что написано в приведенной цитате.
Упс... Значит boost -- это такая песочница для библиотек, которые могут со временем войти в стандарт C++. И цель этого мероприятия -- собрать некую сборную солянку, в которой библиотеки будут развиваться до тех пор, пока не станут настолько продвинутыми и, не побоюсь этого слова, пропиареными, чтобы войти в очередной TRn и далее распространяться вместе с компиляторами C++. Т.е. конечная цель того, что какая-то библиотека предлагается в boost -- это включение данной библиотеки в Стандарт.
Признаю, у меня за последние годы сложилось о boost-е несколько другое впечатление. Поэтому я оценивал boost несколько по другим критериям, как оказалось -- зря. Спасибо
J>В любом случае, отношения к стандартизации это не имеет.
Да действительно.
Обидно другое. Вот, например, есть Ruby community. Люди в нем как-то не сильно обеспокоены тем, будет включена их библиотека в стандартную библиотеку Ruby или нет. Вместо этого они просто пишут библиотеки и приложения, создают Интернет-каталоги Ruby-проектов (RubyForge и RAA). Более того, создали удобную систему дистрибуции библиотек RubyGems. В результате для какой-нибудь предметной области можно найти несколько альтернативных библиотек, оценить их и легко подключить ту, что больше понравилась.
В Java, насколько я понимаю, тоже самое происходит после появления Maven2.
А вот в C++ -- наша цель Стандарт! При этом сейчас получается, что к какой-нибудь самописной библиотеке, у которой архив исходников на 100K, нужны еще несколько мегабайт OpenSSL, десяток(!) мегабайт ACE и еще двадцать(!) мегабайт Boost-а (ради boost::regex и boost::multi_index). Красотища-то кака!
Ладно, к boost-у все это не имеет отношения. Ведь C++ не выживет без Xpressive в одном из следующих стандартов!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Kluev, Вы писали:
K>индустриальной я бы назвал zlib и аналогичные библиотеки хорошо сделанные и внутри и снаружи. пользоватся такими одно удовольствие. а буст — сборище велосипедов сомнительного качества.
Ну постыдился бы говорить о качестве. После того как выложил свой код , в котором при БЕГЛОМ анализе (даже без тестов) обнаружены баги парсинга.
P.S. От того что ты большее число раз будешь опускать буст, его качество от этого не изменится.
Здравствуйте, Kluev, Вы писали:
K>индустриальной я бы назвал zlib и аналогичные библиотеки хорошо сделанные и внутри и снаружи. пользоватся такими одно удовольствие. а буст — сборище велосипедов сомнительного качества.
А мне всегда казалось, что zlib и похожие библиотеки насилуют мне мозг... Если бы они были написаны на С++ — были бы лучше и даже наверно эффективнее.
Здравствуйте, minorlogic, Вы писали:
M>Ну постыдился бы говорить о качестве. После того как выложил свой код , в котором при БЕГЛОМ анализе (даже без тестов) обнаружены баги парсинга.
IMHO, эти вопросы не связаны, но если таки связь пытаться найти, то твой аргумент имеет обраьную силу.
ДАЖЕ АВТОР ТАКОГО ОТСТОЙНОГО КОДА ВИДИТ УБОГОСТЬ КАЧЕСТВА БУСТа
M>P.S. От того что ты большее число раз будешь опускать буст, его качество от этого не изменится.
Увы, с ним вообще что не делай, не поможет. Насколько я понимаю нет никакого человека или института, который бы обеспечивал высокое качество включённых в буст библиотек...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
ну это не ошибка была.
