Здравствуйте, eao197, Вы писали:
E>Вообще-то std::pair<const char*, const char*> -- это вовсе не аналог string_piece. Так как в случае string_piece прокатывают вот такие вещи:
и что? или кроме этих вот вещей, ничего не нужно больше? или, если не нужно, проблема написать функцию типа make_string_piece, или написать ровно три конструктора, один оператор вывода в поток и один оператор преобразования в std::string?
Ну еще, конечно, можно предоставить begin/end/size и тайпдефы. Все. (А можно и их не предоставлять, если пользуешься boost::range — надо будет просто написать соответствующие специализации)
Но самая главная проблема этого класса — его взаимоотношения с хозяином и возможность того, что он его переживет и будет смотреть в никуда (а если строка с счетчиком, то ведь надо его тоже апдейтить...).
и, раз уж на то пошло, где твое предложение в комитет по стандартизации по включению соответствующей байды в стандартную библиотеку?
Я, на всякий случай, напомню, что народ в комитете не за деньги напрягается, там такие же люди, как и вы.
Вон, посмотрите на немерлистов: нету чего-то в языке или библиотеке — пишут и отправляют разработчикам языка, и в результате имеют тот язык, который хотят, с теми библиотеками, которые хотят.
А в С++ только сидят и ноют, что ж, мол, такие плохие все в комитете, палец о палец не ударят.
А не было бы Степанова — так вообще никакой библиотеки стандартной не было бы, так бы и сидели в зоопарке.
Вон товарищи из буста работают — вот их контейнеры и появляются в стандарте.
А Александреску, скажем, повозмущался, что, мол, как это так, почему мой супер-смарт-поинтер не включили в стандарт, а у него так вежливо поинтересовались: "А где предложение-то, с номерами параграфов, где чего и как менять, и т.д? Или ты ждешь, что его кто-то за тебя напишет?" (На самом деле, конечно, было не совсем так, просто как иллюстрация)
Хочешь, чтобы что-то было в С++, и не видишь соответствующего предложения на их сайте?
Так напиши сам, потрать время и силы, предложи, убеди всех, что это действительно позарез нужно — и все будет, и все тебе спасибо скажут.
А так я могу тебе твою же претензию и развернуть: "Имярек, а почему это до сих пор этого нет в Стандарте?! Что за лень и халатность? Ты что, совсем не думаешь о простых разработчиках, которые страдают без этой фичи?"
Здравствуйте, Erop, Вы писали:
J>>Гораздо конструктивнее и полезнее для сообщества, чем тупо материться на форуме. E>Ну вот Клюев опубликовал сорцы парсера. И что мы видим? Пишут про ревью и goto...
Там уже пару багов нашли. Я бы искать не стал, ибо оно того не стоит.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, eao197, Вы писали:
J>А в С++ только сидят и ноют, что ж, мол, такие плохие все в комитете, палец о палец не ударят. J>А не было бы Степанова — так вообще никакой библиотеки стандартной не было бы, так бы и сидели в зоопарке.
Лучше старый добрый зоопарк зоопарк чем степановский цирк и бустовское шоу нарциссо.
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, eao197, Вы писали:
J>>А в С++ только сидят и ноют, что ж, мол, такие плохие все в комитете, палец о палец не ударят. J>>А не было бы Степанова — так вообще никакой библиотеки стандартной не было бы, так бы и сидели в зоопарке.
K>Лучше старый добрый зоопарк зоопарк чем степановский цирк и бустовское шоу нарциссо.
да ты мастер ярлыки клеить
ну либо тебе не приходилось проходить через ад сопряжения двух разных библиотек с несовместимыми интерфейсами, занимающихся одним и тем же — ну что ж, могу только позавидовать.
Здравствуйте, jazzer, Вы писали:
E>>Вообще-то std::pair<const char*, const char*> -- это вовсе не аналог string_piece. Так как в случае string_piece прокатывают вот такие вещи:
J>и что? или кроме этих вот вещей, ничего не нужно больше? или, если не нужно, проблема написать функцию типа make_string_piece, или написать ровно три конструктора, один оператор вывода в поток и один оператор преобразования в std::string?
Ровно три конструктора в каком классе нужно написать?
J>Но самая главная проблема этого класса — его взаимоотношения с хозяином и возможность того, что он его переживет и будет смотреть в никуда (а если строка с счетчиком, то ведь надо его тоже апдейтить...).
Поскольку этот класс всего-лишь обертка над char *, то и гарантии он дает точно такие же, как char *.
J>Сорри за эмоциональность, накипело.
Я просто спросил, почему, если аналоги string_piece есть у многих разработчиков, самого string_piece нет. Может этот вопрос уже широко обсуждался где-нибудь, а я, как обычно, не знаю
Что до развития C++... У меня нет желания развивать сам язык или его стандартную библиотеку. Делать что-нибудь на C++ -- это да, это можно (хотя и желания гораздо меньше, чем было раньше). Вот этим и занимаюсь по мере сил, это мне интересно. А языком пусть занимаются те, кому это интересно. Таких и без меня не мало.
Только вот сама тенденция концентрировать усилия вокруг комитета или буста -- это, имхо, не правильно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ровно три конструктора в каком классе нужно написать?
в string_piece, вестимо
J>>Но самая главная проблема этого класса — его взаимоотношения с хозяином и возможность того, что он его переживет и будет смотреть в никуда (а если строка с счетчиком, то ведь надо его тоже апдейтить...).
E>Поскольку этот класс всего-лишь обертка над char *, то и гарантии он дает точно такие же, как char *.
Ага, скажи это индусам, которые будут твой код саппортить.
Для них если класс — значит, можно безопасно использовать как угодно.
Столько раз уже сталкивался
J>>Сорри за эмоциональность, накипело.
E>Я просто спросил, почему, если аналоги string_piece есть у многих разработчиков, самого string_piece нет. Может этот вопрос уже широко обсуждался где-нибудь, а я, как обычно, не знаю
Ну если просто спросил...
E>Только вот сама тенденция концентрировать усилия вокруг комитета или буста -- это, имхо, не правильно.
Ну а вот вокруг чего надо концентрировать усилия по изменению С++, если не вокруг комитета С++?
А насчет библиотек — ну вокруг чего-то ведь надо концентрировать усилия, иначе ведь зоопарк будет.
Посмотри сам — ведь каждая библиотека считает своим долгом предоставить свои строки, контейнеры и прочая.
Слава богу, что появился STL с его стандартизированным интерфейсом для контейнеров/итераторов/алгоритмов: теперь достаточно всем этим контейнерам предоставить begin/end, чтобы все заработало (а с boost::range ты и сам можешь написать соответствующие специализации, и все автоматом заработает). А ведь раньше — это просто ад был, я прошел через это пару раз, больше не хочу ну просто вот совсем.
Так что стандарт на интерфейс и жесткое код ревью на следование этим интерфейсам — это я оцениваю очень высоко, и только буст этим всерьез занимается (еще adobe, но он в результате сабмитит все в тот же boost).
Здравствуйте, jazzer, Вы писали:
E>>Например то, что неконстантный operator[] позволяет модифицировать строку... J>и что, поэтому в апачевской либе его нет?
Приходится извращаться
Да и работает не очень.
J>или его нет в каких-то еще строковых либах? J>
Ну, например, посмори на CString...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, jazzer, Вы писали:
E>>Поскольку этот класс всего-лишь обертка над char *, то и гарантии он дает точно такие же, как char *.
J>Ага, скажи это индусам, которые будут твой код саппортить. J>Для них если класс — значит, можно безопасно использовать как угодно. J>Столько раз уже сталкивался
Ну против лома нет приема.
С другой стороны, не все пишут код, который потом индусы будут саппортить
J>>>Сорри за эмоциональность, накипело.
E>>Я просто спросил, почему, если аналоги string_piece есть у многих разработчиков, самого string_piece нет. Может этот вопрос уже широко обсуждался где-нибудь, а я, как обычно, не знаю
J>Ну если просто спросил...
Просто спросил
J>А насчет библиотек — ну вокруг чего-то ведь надо концентрировать усилия, иначе ведь зоопарк будет. J>Посмотри сам — ведь каждая библиотека считает своим долгом предоставить свои строки, контейнеры и прочая.
А собственно, почему бы и нет? Пусть развиваются как хотят -- хорошие библиотеки, предоставляющие удобные интерфейсы и качественные реализации будут выживать.
Происходит же сейчас то же самое в области IPC -- есть ACE, есть Poco, есть boost::asio. Криптография -- OpenSSL, Crypto++, CryptLib, Botan. XML -- то же самое.
Конечно, есть базовые вещи, вроде basic_string или контейнеры. Но их не так уж и много. Пусть они хоть комитетом разрабатывается, хоть еще кем-то, тем же boost-ом.
Гораздо хуже, когда какая-то одна библиотека пытается стать пупом земли и центром мира. Вот есть у меня сомнения в том, что в стандартной библиотеки должны быть вещи типа boost::spirit или boost::program_option. Это просто собирательство в одну корзину всего, что кто-то счел достаточно хорошим для публикации.
Более качественный подход, на мой взгляд -- это дать библиотеке самостоятельно жить до тех пор, пока она не станет достаточно распространенной сама по себе. А уже потом принимать решение о ее "иконизации" (как это было в Java с Log4J).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
E>>>Например то, что неконстантный operator[] позволяет модифицировать строку... J>>и что, поэтому в апачевской либе его нет? E>Приходится извращаться
не сомневаюсь E>Да и работает не очень.
Апачевская либа работает не очень?
Что не так?
J>>или его нет в каких-то еще строковых либах? J>> E>Ну, например, посмори на CString...
Ну, у меня его под рукой нет, как ты понимаешь, но я помню, что там можно было строки изменять, в том числе и конкретные символы.
Но поскольку ты под винду пишешь — так и быть, верю, хоть и странно
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, minorlogic, Вы писали:
M>>Для ОСОБО внимательных я привел 2 имплементации одна принимает std::string другая указатель на строку и ее длина char* size. K>"123" ты передаешь как раз в функцию со string. но это мелочи.
Я не буду давать экскурс в С++ но кратко , стринг создается перед выполнением функции.
M>>Если знаешь как передать std::string без его создания , поделись плз.
поскипанны рассуждения не по теме.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, minorlogic, Вы писали:
M>>Для ОСОБО внимательных я привел 2 имплементации одна принимает std::string другая указатель на строку и ее длина char* size.
E>Но при этом имея две реализации, вы передали строковый литерал туда, где ожидается std::string. E>Если есть API, который принимает const std::string &, а при использовании ему подсовывают const char * (в виде таких вот литералов), то расходы на конструирование и уничтожение std::string-ов могут принимать очень серьезные размеры.
Ок , поменяй пример на std::string s("123"); и передавай s в качестве параметра, стало легче?
M>>Если знаешь как передать std::string без его создания , поделись плз.
E>А во многих случаях не нужен std::string. Я подсмотрел хорошее решение в библиотеке PCRE -- там есть класс StringPiece, разработанный для C++ной обертки PCRE в Google. Я сделал из него для себя вариант. Он не такой функциональный, как Google-овский, зато у него есть шаблонные конструкторы специально для строковых литералов.
Передавай ты что хочешь , какое это отношение к моему примеру имеет?
E>В некоторых случаях у меня замена const std::string & на const string_piece_t & ускоряло код в два раза.
Это достаточно ОЧЕВИДНАЯ техническая деталь , что при парсинге большого ква данных , токенайзер возвращает пару итераторов или итератор или размер , мы счас будем обсуждать технологии парсинга ? Там давно ми без меня много написанно , и поверь , никто там не копирует подстроку для обработки.
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, minorlogic, Вы писали:
M>>Здравствуйте, Kluev, Вы писали:
M>>В конструкторе stringstream и strstream может вызываться динамическое создание обектов , но это уже на совести разработчиков STL имплементации.
K>ну вот, опять мальчик виноват. и как прикажете програмисту работать с библиотекой с непредсказуемой реализацией?
Даю гениальную рекомендацию, попробуйте не работать с STL и Boost? или вас ктонить принуждает ? тогда это вопрос не этого форума.
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, degor, Вы писали:
D>>как можно всерьез обсуждать кусок кода, который даже собрать без геморроя нельзя? тем более такой кусок, который жрет числа вида -.A и не давится?
K>Вполне можно. Ты же сам понимаешь, что велосипеды доделываются согласно потребностям, а этот код без проблем отпарзил гигабайты данных за несколько лет K>и оттестирован на всех возможных use case в реальных условиях.
Ты просто не понимаешь разницу между велосипедом и индустриальной библиотекой. Многие другие , достаточно серьезно относятся к качеству используемых библиотек.
Здравствуйте, minorlogic, Вы писали:
E>>Если есть API, который принимает const std::string &, а при использовании ему подсовывают const char * (в виде таких вот литералов), то расходы на конструирование и уничтожение std::string-ов могут принимать очень серьезные размеры.
M>Ок , поменяй пример на std::string s("123"); и передавай s в качестве параметра, стало легче?
А что, так лишнее выделение памяти внутри std::string куда-то исчезло?
M>Это достаточно ОЧЕВИДНАЯ техническая деталь , что при парсинге большого ква данных , токенайзер возвращает пару итераторов или итератор или размер , мы счас будем обсуждать технологии парсинга ? Там давно ми без меня много написанно , и поверь , никто там не копирует подстроку для обработки.
В идеальном мире идеальные программисты пишут идеальные программы. Остается только позавидовать тому, что вы находитесь в том идеальном мире, а я -- нет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, minorlogic, Вы писали:
E>>А что, так лишнее выделение памяти внутри std::string куда-то исчезло?
M>Егор , учи матчасть. Объект передается по ссылке. икаких копирований нет .
Это не Егор, это Евгений
Чтобы передать объект по ссылке, его сначала нужно создать. Вот при создании new и вызовется.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, minorlogic, Вы писали:
E>>>А что, так лишнее выделение памяти внутри std::string куда-то исчезло?
M>>Егор , учи матчасть. Объект передается по ссылке. икаких копирований нет .
E>Это не Егор, это Евгений E>Чтобы передать объект по ссылке, его сначала нужно создать. Вот при создании new и вызовется.
Прошу прощения.
Объект создается вне функции парсинга строки. Я декларировал только парсинг. Очевидно что объект необходимо создать и он алоцирует динамически память под строку(by design).
K>Это все хорошо пока снаружи нет ссылок на person. а если они потребуются, то указатели использовать, нельзя индексы тоже могуть "уплыть". Единственый гарантированный способ достучатся до person — уникальный id и поиск по всему вектору при каждом обращении. K>Имхо такая схема настолько неудобна, что не стоит того выигрыша в производительности который она даст (если этот выигрыш кончано find не сожрет).
* list, vector в данной ситуации имеют общую проблему, но даже в этом случае список всё равно будет работать медленнее из-за непоследовательного чтения памяти (кэш процессора).
* нужен быстрый поиск по id? используйте map<id, ...> для больших массивов
Здравствуйте, jazzer, Вы писали:
J>Хочешь, чтобы что-то было в С++, и не видишь соответствующего предложения на их сайте? J>Так напиши сам, потрать время и силы, предложи, убеди всех, что это действительно позарез нужно — и все будет, и все тебе спасибо скажут.
Я не верю, что идея string_piece не обсуждалась.
J>А так я могу тебе твою же претензию и развернуть: "Имярек, а почему это до сих пор этого нет в Стандарте?! Что за лень и халатность? Ты что, совсем не думаешь о простых разработчиках, которые страдают без этой фичи?"
IMHO стандарт С++ давно уже перестал быть поддерживаем. А STL утратил цельность при попадании в стандарт. Соответсвенно что делать -- не понятно. Если кто-то умеет править стандарт, то он может попробовать написать предложение по непротиворечивому внесению string_piece.
Я, например, не возьмусь...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Kluev, Вы писали:
K>>Здравствуйте, minorlogic, Вы писали:
M>>>Здравствуйте, Kluev, Вы писали:
M>>>В конструкторе stringstream и strstream может вызываться динамическое создание обектов , но это уже на совести разработчиков STL имплементации.
K>>ну вот, опять мальчик виноват. и как прикажете програмисту работать с библиотекой с непредсказуемой реализацией?
M>Даю гениальную рекомендацию, попробуйте не работать с STL и Boost? или вас ктонить принуждает ? тогда это вопрос не этого форума.
Дык варианты то остались — платные проприетарные библиотеки. Всегда легче погнать на опен сорс — что там что то реализовано "криво" и нетак. Чем купить — это насчёт буста.
Насчёт STL — чем стандарт С++ неугодил ? Никто не сомневается в проффесионализме (чесно не ехидничаю), но вот я как то больше склонен со Страуструпом согласиться.
А вобще раз boost это напрочь кривая штука , а STL мракобесье может посоветуете Free Open Source библиотеку чтоб портировалась на Win\All Unix ? с удовольствием буду её юзать.
с удовольствием буду её юзать.
