Простой разбор текста

[Igors]

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

Но это лично моё ИМХО)) Прошу по голове сильно не бить)

Ладно, сильно не буду 
Давайте называть вещи своими именами. Если мы хотим сачкануть - это нормально, во многих (очень многих) случаях разумно отпихнуться тем что предложил Пантер. Ничего плохого в этом нет, но не надо прикрывать ограниченность решения  громкими словами, "изяществом", "простотой", "логичностью" и.т.п. - если мы предлагаем дешевое но ограниченное решение - надо честно сказать об этом пользователю. Короче - врать не надо 

1.7 Gb данных на три вектора.. Если прикинуть: int =4 байт, 1Gb = 10^9 байт, три вектора, то по

Не путайте "размер тестового файла на диске" и "размер данных в памяти"

Стоит ли так "выжимать" если можно пойти на компромисс? Вопрос сложный. По поводу того же файла пользователь написал (вольный перевод мой)

- предыдущий импорт занимался этим файлом более 5 часов. Ваш вариант - 9 минут

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

[GreatSnake]

Давайте называть вещи своими именами.

Дык ёлы-палы...
Если бы ты сразу пояснил насчёт размера входных данных, я уверен, тебе бы про Qt никто бы и не заикнулся.
Ведь каждому понятно, что любой тулкит - это универсальный комбайн, который абсолютно не предусмотрен для таких задач.

предыдущий импорт занимался этим файлом более 5 часов. Ваш вариант - 9 минут

Мде, слов нет. Писаки, однако...

[Igors]

Дык ёлы-палы...
Если бы ты сразу пояснил насчёт размера входных данных, я уверен, тебе бы про Qt никто бы и не заикнулся.

Я этого не понимаю. Нормальные файлы - 100-200Мб (в среднем), бывают намного меньше, но бывают и намного больше. Достойно поддержать очень большие файлы - конечно престижно/лестно, но это часть задачи. Почему надо это специально оговаривать? 

[GreatSnake]

Я этого не понимаю. Нормальные файлы - 100-200Мб (в среднем), бывают намного меньше, но бывают и намного больше. Достойно поддержать очень большие файлы - конечно престижно/лестно, но это часть задачи. Почему надо это специально оговаривать?

Имхо, для текстовых файлов такой размер скорее исключение, чем правило.

[m_ax]

Igors, не обижайтесь, но мне просто интересно: Неужели есть такая жёсткая необходимость держать в памяти такие громадные объёмы?
Просто не представляю ситуации, где это действительно так необходимо.
Моё бы железо, при виде такого.. даже не знаю что и сказало бы))

[Igors]

Igors, не обижайтесь, но мне просто интересно: Неужели есть такая жёсткая необходимость держать в памяти такие громадные объёмы?
Просто не представляю ситуации, где это действительно так необходимо.
Моё бы железо, при виде такого.. даже не знаю что и сказало бы))

Ну пользователь - он понимает по-своему. Было ему обещано 150 Tb адресного  пр-ва? Было. Купил он памяти 8/16 Gb - честно купил (это кстати не так уж недорого). Ну вот мне и приходится отвечать почему небольшой (по его понятиям) объем (та всего-то 2-3 Gb) вызывает такие проблемы 
Господи, та всего-то неск. десятков (рельефных) лестниц и этажей (архитектурная сцена) - да о чем тут говорить? 

В конце-концов чем отличается профессиональный софт от "философии GNU" и "нашей малышь" - да очень немногим - тем что он честно "держит нагрузку" а если не может - сообщает

[Пантер]

Igors, ты слишком толстый тролль. Был конкретный вопрос, был конкретный ответ. Ты в первом посте ничего не говорил о производительности. Еще очень давно было сказано "Преждевременная оптимизация есть корень всех зол". Если тебе нужно "современное решение", то чем тебя не устраивает мой ответ? Если ты хочешь производительности, то какого ты вообще поднял этот вопрос??? Хочешь, чтобы все было супер-пупер - пиши на асме.

[Igors]

Igors, ты слишком толстый тролль. Был конкретный вопрос, был конкретный ответ. Ты в первом посте ничего не говорил о производительности. Еще очень давно было сказано "Преждевременная оптимизация есть корень всех зол". Если тебе нужно "современное решение", то чем тебя не устраивает мой ответ? Если ты хочешь производительности, то какого ты вообще поднял этот вопрос??? Хочешь, чтобы все было супер-пупер - пиши на асме.

- мой вес 100кг, я не считаю себя ни толстым, ни троллем 

- по поводу Вашей цитаты о преждевременной оптимизации в библии (единственная книга которую я читал) сказано примерно так

К сожалению многие восприняли это высказывание слишком буквально

- я не хочу "супер", хочу просто "нормально". Вот Вы лихо применили split - раз, 3 новых элемента QString распределились, потом удалились. Всего для 1 скромной строки десятки malloc/delete. Это что, по уму? Нет. это издевательство над машиной. Почему такая халтура считается нормой (мол, мне о скорости ничего не говорили)? Разбор текстовика - задача очень популярная, всем так или иначе ей заниматься приходилось, почему не может быть нормальных тулзов?

Хмм.. недавно boost пришлось поставить (впечатление очень хорошее), пошукаю там

[brankovic]

Хмм.. недавно boost пришлось поставить (впечатление очень хорошее), пошукаю там

спирит это мелко. И всё равно тормозить будет, уверен почти. Вам надо бизон. Годами люди писали оптимальные парсеры на бизоне, в том числе в VLSI, где файлы исчислялись гигабайтами уже лет 8 назад. Прямо в гугле набирайте bison tutorial.

[GreatSnake]

GNU bison = yacc

[lit-uriy]

>>Можно обойтись без сплита используя токо QRegExp, но они работают только с QString
>>и к тому же я не знаю насколько быстро

Ну да, с какой стати "регвыры" стали быстро работать? они скорость обработки в 10-ки раз снижают.

[Igors]

Прямо в гугле набирайте bison tutorial.

Намек понял, спасибо