Разбор QString

[trot]

не наблюдаю в RegExp последовательного разбора

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

[Igors]

Доделал, обновил описание (пост #1). Постарался максимально упростить использование (типа "проще = лучше"). Оптимизацию сделал но что достигнуто не проверял

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

Спасибо за объяснение принципов (я этого не знал). Поймите меня правильно, я на RegExp не нападаю. Вполне возможно для делов веба он очень крут - не мне судить. Но для тех разборок что мне нужны он не подходит, и теория и практика это подтверждают. Что значит "кавычки не имеют никакого отношения" (к балансу)? Куда я их дену если они есть, и я должен разобрать учитывая их? Чего я должен искать скобки (которые хз где) - мне нужно получать "теги" один за одним, а там уже смотреть

[alexis031182]

Тут возможно следует учитывать и саму реализацию парсинга, в нашем случае QRegExp. Скорее всего парсер парсеру рознь. Не факт конечно, но всё же.

А в вебе без регулярок сложно (я о PHP прежде всего, о других языках ничего не могу сказать). И не потому, что там нельзя устроить нечто подобное, что написал Игорь, просто работать это будет относительно медленно. Это на C/C++ можно использовать кучу различных вариантов, чтобы оптимизировать по скорости имеющуюся реализацию, а с пыхпыхом такое не прокатит. Да, есть там строковые функции, выполняющиеся быстрее регулярки, но буде что попадётся для парсинга посложнее, то вся эта альтернатива рассыпется, как карточный домик.

[alexis031182]

Вот результат ранее использовавшегося шаблона с новым кодом.

Код

C++ (Qt)
QString src="1,2,3,{4,5,6},7,8,9";
 
// заряжаем параметры разбора
CParseParam param(",", "");
 
// определяем что будет в качестве "цитат" (quote)
param.AddQuote(100, "{", "}");
 
QStringParser parser(src, param);
QStringRef ref;
for(int i = 0; i < 1000000; ++i) {
    while (parser.NextToken(ref, true)) {}
}
 

real   0m0.010s
user   0m0.008s
sys   0m0.000s
... и ...
real   0m0.009s
user   0m0.008s
sys   0m0.000s

Ранее было:
real   0m0.939s
user   0m0.928s
sys    0m0.004s

[vregess]

Хороший класс. Спасибо.

[Igors]

Спасибо за промер, был приятно удивлен. Все-таки "размер имеет значение" Можно еще ускорить. Сейчас quоtes и символы ищутся линейным перебором, это будет тормозить напр при 20 символах-токенах. Правильно использовать QHash или др ассоциативный контейнер. Ну то на будущее, текущая реализация "не позорная", и этого достаточно.

Понятно что скорость - одна сторона, часто не самая важная. Вот простой фрагмент разборки

...
 },
  "pvp":{
    "ratedBattlegrounds":{
      "personalRating":1141,
      "battlegrounds":[
        {
          "name":"Arathi Basin",
          "played":12,
          "won":9
        },
        {
          "name":"Warsong Gulch",
          "played":6,
          "won":2
        }
      ]
    },
    "arenaTeams":[
      {
        "name":"lkjnhgcx",
        "personalRating":480,
        "teamRating":1504,
        "size":"3v3"
      }
    ],
    "totalHonorableKills":10686
  }
}

Принцип простой: имя-значение, однако значение может быть разных типов, в том числе и массив. Часто лишь некоторые теги надо извлечь. Обычный размер такого файла 20-40k. Очевидно надо сначала выделить тег, затем парить его рекурсивно. Из этих соображений и написан предложенный парсер. А как это с точки зрения регулярных выражений (т.е. подходят ли они здесь) - этого я не знаю, хочу спросить у тех кто владеет техникой регулярок

Спасибо  

[kambala]

исходя из этого примера – неужели существующие JSON-парсеры работают медленее предложенной реализации?

[Igors]

исходя из этого примера – неужели существующие JSON-парсеры работают медленее предложенной реализации?

Ну вот и эрудиты подоспели Понятно что если есть формат - есть и парсеры для него, и, наверное, можно "найти и прикрутить". Только вот всегда ли стоит это делать? Тащить буст (или др), чего-то "собирать", перегонять данные, продираться через кучу template - и в конце-концов полагаться на то что "кто-то умный это сделал, значит должно работать". Иногда это неизбежно, но я стараюсь этого по возможности избегать и никогда не понимал испытывающих зверячий кайф от процедуры "прикрутки" . Не проще ли, используя скромный базовый механизм выделения тегов, накрутить остальное по месту (максимум час) - и все дела?

Однако вернемся к регуляркам. Ссылаясь на др парсер - мы ведь тем самым признаем что регулярки здесь неуместны, не так ли?

[alexis031182]

Ну вот и эрудиты подоспели

Непонятна причина сарказма. Данные в листинге названы своим именем.

Понятно что если есть формат - есть и парсеры для него, и, наверное, можно "найти и прикрутить". Только вот всегда ли стоит это делать?

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

Тащить буст (или др), чего-то "собирать", перегонять данные, продираться через кучу template - и в конце-концов полагаться на то что "кто-то умный это сделал, значит должно работать".

На бусте свет клином не сошёлся. Тот же json настолько популярен, что количество вариантов парсеров под него, если и не неимоверно, то где-то рядом точно.

Иногда это неизбежно...

Лучше сказать: "часто это неизбежно, и это хорошо".

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

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

Не проще ли, используя скромный базовый механизм выделения тегов, накрутить остальное по месту (максимум час) - и все дела?

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

Однако вернемся к регуляркам. Ссылаясь на др парсер - мы ведь тем самым признаем что регулярки здесь неуместны, не так ли?

Непонятно, к чему такой стиль выбран. Он ведь к холивару приведёт. Лучше рубаните с плеча.

З.Ы. Лично я не любитель регулярок, они всегда мне представлялись слишком тяжёлыми, т.к. уж больно широка вариация. Всегда предпочитал использовать специализированные парсеры.

[kambala]

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

насчёт изобретения велосипедов – мне как раз больше по душе использовать существующие гарантированно работающие решения (повторное использование кода как-никак) нежели писать что-то с нуля. конечно, если какую-то функцию можно быстро набросать в несколько [десятков] строк, то тащить левых библиотек не нужно, но если что-то довольно специфическое, то не вижу смысла сидеть и делать «сизифов труд». аргументы типа «буду знать как оно работает, а не просто доверять какому-то дяде», «получение опыта» уже высказывались неоднократно в разных темах, но далеко не всегда нужно знать внутреннее устройство кода чтобы им пользоваться (инкапсуляция и всё такое).

[Igors]

Понятно что если есть формат - есть и парсеры для него, и, наверное, можно "найти и прикрутить". Только вот всегда ли стоит это делать?

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

Мой личный опыт не подтверждает "редкости исключений". Ну вот напр форматик

PathAlignLookAhead 0.033
PathAlignMaxLookSteps 10
PathAlignReliableDist 0.001
IKInitialState 0
SubPatchLevel 0 0
APSDisplay
{ APS
  Version 1
  Method 0
  { VParm
    { ObjectLevel
      0
      { VariantParameter
        3
        0
        { ParameterValue
          0
          0
        }
      }
    }
    { PolygonLevel
      0
      { VariantParameter
        3
        0
        { ParameterValue
          3
          0
        }
      }
    }
    { PolygonPixelSize
      0
      { VariantParameter
        3
        0
        { ParameterValue
          256
          0
        }
      }
    }
  }
}

Конечно нельзя утверждать типа "ну такой парсер Вы точно не найдете!" - но может быть и нет, или ему нельзя верить. И тогда Вы оказываетесь в не очень выгодной ситуации - не хватает велосипеда!

насчёт изобретения велосипедов – мне как раз больше по душе использовать существующие гарантированно работающие решения ..

Это нормально, просто "количество энергии" у (любого) человека ограничено. Чем большим кол-вом тулзов Вы овладеваете - тем меньше места для своих мыслей. И вот когда его остается совсем ноль.. ну надеюсь Вам это не грозит 

[alexis031182]

Мой личный опыт не подтверждает "редкости исключений". Ну вот напр форматик
...

Велосипед рождает необходимость строительства велосипедов.

Конечно нельзя утверждать типа "ну такой парсер Вы точно не найдете!" - но может быть и нет, или ему нельзя верить. И тогда Вы оказываетесь в не очень выгодной ситуации - не хватает велосипеда!

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

Это нормально, просто "количество энергии" у (любого) человека ограничено. Чем большим кол-вом тулзов Вы овладеваете - тем меньше места для своих мыслей. И вот когда его остается совсем ноль.. ну надеюсь Вам это не грозит 

Но можно тогда вообще не изучать чужих тулзов. Тогда места для собственных мыслей будет хоть отбавляй. Мне кажется что-то не слишком верно в Вашей позиции. С точки зрения практичности, лучше использовать существующее решение. Если же условия задачи ставят необходимость модернизации того, что получилось, то можно заняться переработкой каких-то частей кода на предмет эффективности. А может быть код пишется по велению души, так сказать, хобби, тогда конечно сам Бог велел докопаться до сути.

[Igors]

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

Так там еще 4-5 "под-форматов" (версии) и даже доки нормальной нет (так, "упоминания" в SDK). Но люди этим пользуются, и соответственно возникает необходимость конвертации. Так что, мне сказать "это гнусный нестандартный формат, разбирайтесь сами с этим калом"? Не могу, это работа а не хобби.

Вообще с данными 3D это ситуация типовая: велосипед на велосипеде, стандартов нет. Вот у Qt что-то есть (Qt3D ? - не в курсе) было бы интересно узнать как они хранят данные 3D модели. Подозреваю вряд ли там милый xml, вполне вероятно - тоже велосипед.

Но можно тогда вообще не изучать чужих тулзов. Тогда места для собственных мыслей будет хоть отбавляй. Мне кажется что-то не слишком верно в Вашей позиции. С точки зрения практичности, лучше использовать существующее решение.

А откуда такая безмятежная уверенность что таковое всегда есть и/или обойдется дешевле? Вы прекрасно понимаете что я говорю о "золотой середине". Палка перегнута явно в др сторону - бестолковое хватание и заучивание всего подряд - к месту и не к месту.

[Bepec]

Истина познаётся в споре. А выбор между своим велосипедом и чужим решением - сравнением

PS эт уже каждый решает для себя, что выбрать. Споры тут неуместны.

[alexis031182]

Так там еще 4-5 "под-форматов" (версии) и даже доки нормальной нет (так, "упоминания" в SDK). Но люди этим пользуются, и соответственно возникает необходимость конвертации.

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

Так что, мне сказать "это гнусный нестандартный формат, разбирайтесь сами с этим калом"? Не могу, это работа а не хобби.

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

Вообще с данными 3D это ситуация типовая: велосипед на велосипеде, стандартов нет. Вот у Qt что-то есть (Qt3D ? - не в курсе) было бы интересно узнать как они хранят данные 3D модели. Подозреваю вряд ли там милый xml, вполне вероятно - тоже велосипед.

Не в курсе. Но наверняка есть общепризнанные форматы гигантов в этой индустрии, например того же Autodesk. Много свободных приложений для работы с 3D. Я не думаю, что ситуация прямо настолько плачевна.

А откуда такая безмятежная уверенность что таковое всегда есть и/или обойдется дешевле? Вы прекрасно понимаете что я говорю о "золотой середине". Палка перегнута явно в др сторону - бестолковое хватание и заучивание всего подряд - к месту и не к месту.

Одна крайность спешит навстречу другой. Баланс энергий, если угодно. Конечно мы оба понимаем, что решение принимается индивидуально в каждом конкретном случае. Просто Вы категорично обозначили вариант как единственно верное решение:

Это нормально, просто "количество энергии" у (любого) человека ограничено. Чем большим кол-вом тулзов Вы овладеваете - тем меньше места для своих мыслей. И вот когда его остается совсем ноль...

Оно и родило такой адекват. Не мною, так кем-нибудь другим был бы обозначен ответ.