Бага в плюсах ?

[Qraizer]

Очевидно же, что функция предназначена для работы со строками в форматах, где строки окавычиваются, а кавычки в качестве обычных элементов, а не ограничителей строки, обрабатываются, также, как и в Плюсах. Ровно это она и делает. Без этого формировать или парсить такие значения на Плюсах неудобно, придётся самому корёжить строку со встроенными " при выводе и парсить при чтении. Причём регулярками это хрен так легко сделаешь, т.к. нужно учитывать \ перед ", которые будут не ", и ещё \ перед \, которые не будут \, так что даже банальным циклом не так просто заморочиться. Если б дело было просто в расстановке/удалении кавычек по краям, вопроса б не было.

[Wound]

Цитата macomics @ 24.05.23, 13:59

Вы не заметили, что я убрал XML.

Заметил вообще то, но ты упор сделал на чтении текстовых файлов, а не на CSV, XML - вполне себе текстовый файл.

Цитата kopilov @ 24.05.23, 13:56

Не вижу, откуда взялся "\"A\\\"\""

Так функция же добавила.

Добавлено 24.05.23, 15:34

Цитата Qraizer @ 24.05.23, 15:29

Очевидно же, что функция предназначена для работы со строками в форматах, где строки окавычиваются, а кавычки в качестве обычных элементов, а не ограничителей строки, обрабатываются, также, как и в Плюсах. Ровно это она и делает. Без этого формировать или парсить такие значения на Плюсах неудобно, придётся самому корёжить строку со встроенными " при выводе и парсить при чтении.

Я уже понял что она делает. Она какую то узконаправленную задачу решает, которая нужна макомиксу для чтения CSV файлов, и похоже что все. А еще кто то ее в линуксах юзает. Зато про экранировать строку - разрабы стандарта похоже не слышали. Зачем делать такую сложную функцию? Не проще ли сделать 2 - одна для экранирования, вторая для того чтоб кавычить?

Сообщение отредактировано: Wound - 24.05.23, 15:34

[Qraizer]

P.S. У меня вот шелезяка выдаёт в RS-232 строку приглашения с версией, которую надо парсить, чтоб убедиться, что шелезяка работает. Причём ещё шелезяки разных ревизий отличаются этими строками. Сделал .ini, в котором расписал все возможные строки и соответствующие им версии. И всё бы ничего, если б в этих строках не могли встречаться спец.символы, те же \n или \t, например. Так что пришлось руками хреначить целую единицу трансляции, чтоб забрать строки из .ini в формате строковых литералов Плюсов и представить их в качестве корректного символьного массива. На вскидку: \n, \r, \a, \b, \f, \t, \v, \', \", \?, \\ – лепота; \xHH, \OOO – м-м-м как интересно; а самый смак \uXXXX, \UXXXXXXXX. Вот от какого манипулятора я бы не отказался. Особенно от двух последних, ибо кастить юникоды через локали то ещё удовольствие

Добавлено 24.05.23, 15:44

Цитата Wound @ 24.05.23, 15:31

Не проще ли сделать 2 - одна для экранирования, вторая для того чтоб кавычить?

Не проще. Что делать со строкой

Бегемот сказал "бла-бла-бла" и выпрыгнул на ходу, а водитель подумал "идиот"

при окавычивании, ещё понятно, а что делать с

"Бегемот сказал "бла-бла-бла" и выпрыгнул на ходу, а водитель подумал \"идиот\"

при чтении, вообще не понятно. Примерно так же поступили с operator new и operator delete в своё время. Они сразу делают две вещи: и управляют памятью, и создают/разрушают объекты конструкторами/деструкторами. Несмотря на то, что управление памятью и создание/уничтожение объектов – это две совершенно разные задачи, выполняются они всегда вместе, во избежание.

Добавлено 24.05.23, 15:45
P.S. Кавычки в примерах расставлены именно так, как я хотел.

Добавлено 24.05.23, 15:56
Ты, Wound, наверное, никогда не сталкивался с необходимостью квалифицировать свои инструменты на отказоустойчивость и достигать 100% структурного покрытия блоков, операторов, решений и условий для этого. Работать в идеальном или хотя бы в адекватно себя ведущем исполнительном окружении всегда хочется, но нельзя, приходится предусматривать возможность мульёна разных багов со стороны, которую ты не контролируешь. Так что тебе на вход может прилететь невесть что и как оформленное, и вон те примеры, наполовину такие, а на другую половину недосякие, вполне будут реальны, если не решать обе задачи std::quoted одновременно. А оно надо кому?

Сообщение отредактировано: Qraizer - 24.05.23, 15:57

[Wound]

Цитата Qraizer @ 24.05.23, 15:37

Не проще.

Очень странно. Функция ведет себя как то иначе при разных условиях или что?

Цитата Qraizer @ 24.05.23, 15:37

при окавычивании, ещё понятно, а что делать с

Ровно то же, что делает эта функция - экранировать и окавычить. Не понимаю смысла вопросов.

Я тебе пишу - берем эту функцию и делим на 2 функции. Ты спрашиваешь - и что делать вот с такой строкой. Ну как что? Если раньше ты вызывал 1 функцию, то теперь одну передашь в другую делов то.

А вот встречный вопрос, что делать если мне надо просто экранировать символы в строке? Вот что мне делать? Писать свой велосипед? Т.е. какую то шнягу они в стандарт затащили, а то что вылезает везде где пользователь что то вводит, пароль например со спец символами - они сделать не додумались. Ну супер.

[Qraizer]

Цитата Wound @ 24.05.23, 16:04

Я тебе пишу - берем эту функцию и делим на 2 функции. Ты спрашиваешь - и что делать вот с такой строкой. Ну как что? Если раньше ты вызывал 1 функцию, то теперь одну передашь в другую делов то.

Хм. А вот вызвал я окавычивание, а экранирование не стал. особенно. Если там изначально баг с расстановкой кавычек. На, разгребай при чтении:

"Бегемот сказал "бла-бла-бла" и выпрыгнул на ходу, а водитель подумал «идиот"

Добавь туда для гарантии EOLолов или наоборот убери, если они там есть:

<pr>"Бегемот сказал "бла-бла-бла" и выпры
гнул на ходу, а водитель подумал «идиот"</pr>

Добавлено 24.05.23, 18:49
Не забывай, ты разговариваешь, с профессиональным верификатором

Добавлено 24.05.23, 18:51

Цитата Wound @ 24.05.23, 16:04

А вот встречный вопрос, что делать если мне надо просто экранировать символы в строке? Вот что мне делать? Писать свой велосипед?

На все случаи жизни библиотек не напасёшься. Зато есть универсальные, которые позволяют тебе нахреначить любую грамматику, какую захочешь. Придумывай формат или бери имеющийся готовый, описывай её в каком-нибудь boost::spirit, и радуйся на здоровье.

Так-то я не спорю, что фича малость сахарная. С другой стороны тогда это был бы не легковесный IO-манипулятор, тогда как просили как раз о нём.

Сообщение отредактировано: Qraizer - 24.05.23, 18:52

[Wound]

Цитата Qraizer @ 24.05.23, 18:48

Хм. А вот вызвал я окавычивание, а экранирование не стал. особенно. Если там изначально баг с расстановкой кавычек.

Это вопросы из серии если бы, да кабы. Вон тебя не смущает всякие функции std::remove_if ? Иди удали элемент. Да фиг там, сидишь и думаешь - а че случилось, вроде хотел удалить, а ничего не произошло. А тут еще какой то std::erase Надо вызвать. Вот жеж. И никого это не смущает, еще и за фичу выдавать будете. Че не сделать нормальный remove_if, который именно что удаляет, а не занимается фигней?
Вот так и тут. Забыл экранирование вызвать? Ну значит оно тебе и не нужно было. Попробуй невалидный итератор передать в функцию remove_if - будет тоже самое что и в твоем случае. А вообще даже если у тебя там баг с расстановкой кавычек, эта функция тебе еще две добавит и все. Она судя по всему именно так и работает.

Цитата Qraizer @ 24.05.23, 18:48

Добавь туда для гарантии EOLолов или наоборот убери, если они там есть

Я вообще не понимаю сути вопроса. Да понапихай туда всего чего надо и не надо, еще и бинарных нечитаемых символов напихай. И чего? Функция все что делает - это экранирует уже существующие кавычки и другие знаки + всегда, хоть у тебя там в начале уже 100 кавычек - она добавит еще по одной ковычке - спереди и сзади. Какой в этом толк то? Вы мне рассказываете вам в линуксе с этим удобно или CSV парсить? Лол. Так в чем вопрос - смотрите еще раз: Берем эту функцию, делим ее на две, одна экранирует, вторая окавычивает. И все. В итоге теперь это все можно использовать еще и для экранирования !!!
Но нет же. Надо обязательно создать какую то узконаправленную функцию, которая нужна трем с половиной челам, и то в теории. На практике они скорее ее не юзали эту функцию никогда в жизни, и скорее всего узнали о ней либо только сейчас, либо где то как то краем уха слышали.

Цитата Qraizer @ 24.05.23, 18:48

На все случаи жизни библиотек не напасёшься. Зато есть универсальные, которые позволяют тебе нахреначить любую грамматику, какую захочешь. Придумывай формат или бери имеющийся готовый, описывай её в каком-нибудь boost::spirit, и радуйся на здоровье.

Зачем мне Boost ? У меня резко нарисовался баг в мелкой тулзе, в пароль передали спецсимволы типа кавычки, и сервак не распарсил это. Нужно было просто экранировать строку.


И никто из вас так и не написал, как же мне экранировать строку? В общем то я уже сделал задачу, просто интересно от местных услышать. А то всякие байки о том, какая эта функция важная из за того что помимо того что экранирует еще и кавычит, рассказываете.

Сообщение отредактировано: Wound - 24.05.23, 19:40

[macomics]

Цитата Wound @ 24.05.23, 19:37

И никто из вас так и не написал, как же мне экранировать строку?

Перечитайте свой первый пост. Вы там ни о чем таком не просили. Писали, что баг нашли...

Скрытый текст

Если надо избавиться от кавычек, тогда что мешает сделать так

#include <iostream>
#include <iomanip>
#include <sstream>
 
void default_delimiter() {
  const std::string in = "std::quoted() quotes this string and embedded \"quotes\" too";
  std::stringstream ss;
  ss << std::quoted(in);
  std::string out;
  ss >> std::quoted(out);
 
  std::cout << "Default delimiter case:\n"
               "read in     [" << in << "]\n"
               "stored as   [" << ss.str().substr(1,ss.str().size() - 2) << "]\n"
               "written out [" << out << "]\n\n";
}
 
void custom_delimiter() {
  const char delim {'$'};
  const char escape {'%'};
 
  const std::string in = "std::quoted() quotes this string and embedded $quotes$ $too";
  std::stringstream ss;
  ss << std::quoted(in, delim, escape);
  std::string out;
  ss >> std::quoted(out, delim, escape);
 
  std::cout << "Custom delimiter case:\n"
               "read in     [" << in << "]\n"
               "stored as   [" << ss.str().substr(1,ss.str().size()-2) << "]\n"
               "written out [" << out << "]\n\n";
}
 
int main() {
  default_delimiter();
  custom_delimiter();
}

Default delimiter case:
read in     [std::quoted() quotes this string and embedded "quotes" too]
stored as   [std::quoted() quotes this string and embedded \"quotes\" too]
written out [std::quoted() quotes this string and embedded "quotes" too]
 
Custom delimiter case:
read in     [std::quoted() quotes this string and embedded $quotes$ $too]
stored as   [std::quoted() quotes this string and embedded %$quotes%$ %$too]
written out [std::quoted() quotes this string and embedded $quotes$ $too]

Сообщение отредактировано: macomics - 24.05.23, 21:58

[Qraizer]

Цитата Wound @ 24.05.23, 19:37

Че не сделать нормальный remove_if, который именно что удаляет, а не занимается фигней?

Потому что алгоритм ничего не знает о контейнерах, итераторы которого ему переданы в обработку. К тому же не факт, что я захочу их удалить из контейнера, а не, скажем, передать в очередной алгоритм. Другое дело, если б он назывался erase_if(), но ведь он remove_if(), а значит не уничтожает, а убирает за пределы диапазона, определяемого итераторами.
Впрочем, тут это оффтоп. Так-то всё достаточно подробно объяснено в соответствующей литературе.

Цитата Wound @ 24.05.23, 19:37

Но нет же. Надо обязательно создать какую то узконаправленную функцию, которая нужна трем с половиной челам, и то в теории.

Ну вот с чего ты взял, что всё не с точностью до наоборот, и это ты входишь в число 3,5 человек, а? Просили сделать простой манипулятор, чтобы строки можно было просто форматировать под протоколы, которые требуют заключать их в кавычки. Если б дело было в простых

auto toOutput = [](const std::string& str){ return '"' + myString + '"'; };
auto fromInput= [](const std::string& str){ return str.substr(str.start_with('"'), str.length() - str.end_with('"') - str.start_with('"')); };

то вопрос вообще бы не стоял. Но ведь надо ж ещё поискать " внутри, чтобы они не воспринимались как ограничители. Но это только в том случае, если перед " нет \, тогда это уже не ограничитель. Но только в том случае, если перед \ нет ещё одного \, тогда это всё-таки ограничитель. И про триграф ??/ ещё не забыть.

Цитата Wound @ 24.05.23, 19:37

У меня резко нарисовался баг в мелкой тулзе, в пароль передали спецсимволы типа кавычки, и сервак не распарсил это. Нужно было просто экранировать строку.


И никто из вас так и не написал, как же мне экранировать строку?

Ябеспонятия, что тебе было надо. И даже сейчас тоже беспонятия, что ты понимаешь под понятием экранирования. Что там надо твоему серверу, мне неведомо. Возможно у вас плохой сервер, выкинете его на свалку и возьмите хороший.
Как по мне, мне нужен манипулятор, который полностью хендлит любые ESC, как вон я выше описывал.

Сообщение отредактировано: Qraizer - 25.05.23, 01:20

[Wound]

Цитата macomics @ 24.05.23, 20:45

Вы там ни о чем таком не просили.

Там не писал, а дальше написал. И да, цель не в том чтобы написать это в принципе, потому что я не умею. Я и сам могу написать, цель в том, что б сделать это лаконично и по феншуюю. Другими словами - если что то подобное для этого уже есть в STL, а ты напишешь свой велосипед - то это уже будет не круто, конечно если ты не обоснуешь что твой велосипед круче, чем то, что уже например есть.

Добавлено 25.05.23, 04:42

Цитата Qraizer @ 25.05.23, 01:15

Другое дело, если б он назывался erase_if(), но ведь он remove_if(), а значит не уничтожает, а убирает за пределы диапазона, определяемого итераторами.

первый - стереть_если, второй удалить_если. Что первый, что второй по своему смыслу предпоалагет как раз уничтожение элементов, а не убирание за пределы диапазона. Имена функций вводят в ступор новичков - это факт, их названия попросту не отражают то что они делают.

Цитата Qraizer @ 25.05.23, 01:15

Ну вот с чего ты взял, что всё не с точностью до наоборот, и это ты входишь в число 3,5 человек, а?

Из простой логики, если есть два действия, одно сложное(составное), а второй простое, и сложное включает в себя простое, то значит простое по определению будет использоваться чаще, чем сложное. Хотя бы потому, что сложное включает простое. И даже если все будут использовать только лишь сложное, то простое в этом случае будет использоваться не меньше сложного по количеству раз.

Цитата Qraizer @ 25.05.23, 01:15

Как по мне, мне нужен манипулятор, который полностью хендлит любые ESC, как вон я выше описывал.

Я ж выше написал. Ты давно регился на ресурсах? Там в паролях предлагается юзать спецсимволы - ",/,|,\,! ну типа этих. Очевидно что некоторые из них, если их не экранировать - будут создавать ошибки. В командной строке, передаче по сети в различных текстовых форматах и т.д.

Как по мне, своей фразой "мне нужен манипулятор", ты уже намекаешь на какую то портянку кода. Для какой то тривиильной задачи, которая встречается очень часто. При наличии у тебя функции похожей которая делает то что надо, плюс еще пихает что то левое правда.

Писать класс, для того чтоб в одном месте его вызвать - как по мне уже слишком . Че реплейсом не сделать? Хотя есть и без манипуляторов решения.

Сообщение отредактировано: Wound - 25.05.23, 06:19

[Wound]

Ну и плюс ко всему, плюсы изначально делались так, что в них есть кирпичи, а ты из них что то строишь и это было круто. Нужен тебе кирпич в форме буквы Г, ты взял три кирпича, слепил из них букву Г, и вуаля. А с новыми стандартами - в язык начали тащить всякую чушь, в погоне за всякими новомодными языками. И вместо того чтоб следовать принципу - ты дай кирпичь, а уж букву Г я и сам слеплю, решили пойти по тупому пути. И добавлять уже целые алгоритмы, которые объединяются и представляют из себя нечто очень узконаправленное. При этом по отдельности - эти алгоритмы не реализованы. И в итоге получается ситуация, букву П слепили и засунули в библиотеку из 5 кирпичей, а букву Г не додумались. В итоге получается черти что и с боку бантик. Вы или тогда уже как в тех языках, за которыми вы гонитесь, вводите все подряд, либо делайте кирпичи, а уж пользователь сам разберется какую фигуру ему из них сложить надо. Потому что все это вызывает массу вопросов.

Добавлено 25.05.23, 07:18

Цитата macomics @ 24.05.23, 20:45

Если надо избавиться от кавычек, тогда что мешает сделать так

Мешает то, что это костыль, причем жесткий.

Добавлено 25.05.23, 07:21
Ну и в третий раз спрошу - будут примеры того, как по феншую экранировать символы в строке, в плюсах? Если что, один из вариантов решения я уже запилил, но он больше похож на то, как стрельба из пушки по воробьям. Но в принципе че делать, если комитетчики не могут базовые алгоритмы в язык ввести, зато всякую чушь тащут.

Сообщение отредактировано: Wound - 25.05.23, 07:21

[D_KEY]

Цитата Wound @ 24.05.23, 12:22

Мне надо строку заэкранировать и послать в JSON, начал гуглить что есть в плюсах, нашел эту функцию std::quoted, вроде она делает то, что надо, но добавляет в начало и конец строки - кавычки. Теперь от них избавляться надо по тупому

Можешь чуть подробнее рассказать? Зачем избавляться от кавычек, если в json строковые объекты тоже в кавычках задаются?

Добавлено 25.05.23, 08:20
Или ты весь json сразу через это гоняешь?

[Wound]

Цитата D_KEY @ 25.05.23, 08:15

Можешь чуть подробнее рассказать? Зачем избавляться от кавычек, если в json строковые объекты тоже в кавычках задаются?

Попробуй выполнить следующий код:

#include <iostream>
 
int main()
{
    std::string user = "Admin";
    std::string password = "P@$$w0rd\"!!1";
    
    std::string jsonRequest = "{\"Username\":\"" + user + "\",\"Password\":\"" + password + "\"}";
    
    std::cout << jsonRequest << std::endl;
}

Получишь строку со следующим содержимым

{"Username":"Admin","Password":"P@$$w0rd"!!1"}

Потом, ну если уж совсем наглядно, скопируй выходную эту строку, и подставь ее аргументом в POST запрос например CURL тулзы. Скорее всего ты получишь ошибку, что то типа:

Цитата

HTTP/1.1 400 Bad Request
...


{"errors":{"Password":["After parsing a value an unexpected character was encountered: 7. Path 'Password', line 1, position 53."]},"type":"https://tools.ietf.org/html/rfc7231#section...quot;:"One or more validation errors occurred.","status":400...

Для того, чтоб кавычка в поле Password была законной, ее нужно экранировать для формата JSON(и не только для него, в линуксе например в командной строке наблюдаются глюки, когда вводишь ! знак в строке запроса, в качестве пароля, сносит башню и bash уже не отображает нормально историю запроса, скорее всего это как то связано с неэкранированием символа, ну короче ноги растут от туда).

А чтоб запрос был правильным, надо строку с паролем(да и с юзером тоже) экранировать, чтоб запрос выглядел вот так:

{"Username":"Admin","Password":"P@$$w0rd\"!!1"}

Добавлено 25.05.23, 08:51

Цитата D_KEY @ 25.05.23, 08:15

Или ты весь json сразу через это гоняешь?

Поле Password и User только экранировать надо. Зачем же весь json ? ты как с CURL'ом не работал что ле? Или с другой тулзой, где надо данные в json формате гонять ?

Добавлено 25.05.23, 08:56

Цитата D_KEY @ 25.05.23, 08:15

Зачем избавляться от кавычек, если в json строковые объекты тоже в кавычках задаются?

В том и дело, что в JSON, они либо все экранируются слешами, либо только строки в кавычках. А тут что внутри - экранирует, при этом по краям добавляет кавычки, не экранированные. Т.е. получаешь строку
"P@$$w0rd\"!!1" с неэкранированными кавычками.

Сообщение отредактировано: Wound - 25.05.23, 09:02

[kopilov]

Цитата Wound @ 25.05.23, 08:50

Поле Password и User только экранировать надо

Именно. И граничные кавычки тоже доверить системному экранированию, а не самостоятельно вставлять.
Причём для названий атрибутов это тоже работает.
Попробуй выполнить следующий код:

#include <iostream>
#include <iomanip>
int main() {
    std::string user = "Admin";
    std::string password = "P@$$w0rd\"!!1";
    std::stringstream jsonRequest;
    jsonRequest << "{" << std::quoted("Username") << ":" << std::quoted(user) << "," << std::quoted("Password") << ":" << std::quoted(password) << "}";
 
    std::cout << jsonRequest.str() << std::endl;
}

Добавлено 25.05.23, 09:14
Как ты сам сказал, «или либа, или кирпичи». Если доверяешь либе экранирование — доверяй до конца

[D_KEY]

Wound, так зачем ты кавычки сам добавляешь при формировании json? std::quoted их уже добавила.

Добавлено 25.05.23, 10:05

Цитата Wound @ 25.05.23, 08:50

В том и дело, что в JSON, они либо все экранируются слешами, либо только строки в кавычках. А тут что внутри - экранирует, при этом по краям добавляет кавычки, не экранированные. Т.е. получаешь строку
"P@$$w0rd\"!!1" с неэкранированными кавычками.

Так и в json нужны кавычки обрамляющие у строкового значения.
Как ты формируешь json? Если через какую-то библиотеку, то она сама должна экранировать все, если сам, то просто не добавляй свои кавычки, делай через std::quoted.

Сообщение отредактировано: D_KEY - 25.05.23, 10:07

[Wound]

Цитата D_KEY @ 25.05.23, 10:02

Wound, так зачем ты кавычки сам добавляешь при формировании json? std::quoted их уже добавила.

Это не я. Оно так было. И было там без экранирования, это же пример.

Добавлено 25.05.23, 12:25

Цитата kopilov @ 25.05.23, 09:08

Именно. И граничные кавычки тоже доверить системному экранированию, а не самостоятельно вставлять.

Так в том и дело что граничные кавычки не экранируются, а просто вставляются, безусловно. О чем и речь.