string и startsWith

[thechicho]

//\s — это любой пустой символ, а не только пробел
какая разница. код выполнит свою задачу. если в строке будет "любой пустой символ", а его там не будет, то регулярка меняется так

Код:

str.replace(QRegExp(" .+$"), "");

учитывая, что вы тоже явно ищите пробел

Код:

int spacePos = s.indexOf(" ");

но если вам не нравятся регулярки или вы просто не умеете их готовить, то

Код:

s = s.left(s.indexOf(" "));

[Igors]

Очередное передергивание и вырывание слов из контекста. Это фраза относилась к фанатичной и бесполезной оптимизации.

Ни к какой фанатичной оптимизации я не призывл. Да, QString довольно жирный/затратный класс, и да, переливание из одного строчника в другой и обратно не есть грамотно. Последнее вообще применимо к любым строковым типам. Что не так, что не нравится?

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

Звучит как "ах ты, гад, велосипедишь!" Откуда такая злобв к велику? Ну не увидел этой вещички в бусте, ну сделал свою - почему это преступление? Почему я был обязан непременно найти и воспользоваться, почему Вы считаете это "делом чести", "показателем класса"? Это же чущь собачья  

В своем велике по меньшей мере вреда никакого. Беда совсем в другом - если человек пользует инструмент не умея сделать свой велик. Напр полезно сначала сделать свой "массив переменной длины", а уж потом юзать std::vector. Тогда будет "в жилу". Но подавляющее большинство считает себя умнее - и сразу начинает с вектора. В результате очень часто выбор этого контейнера неудачен. Использование готового хорошо при наличии своего опыта, иначе результат обратный.

[thechicho]

Spark, ну Igors вам популярно намекнул, что надо начинать с частностей, а потом переходить к целому, выражаясь вашим языком.

//Если провести черту там где она проведена в споре, то я на стороне добра и зла
привет Швейцария

//есть такое качество как упертость (поперечность)
есть и упоротость

[thechicho]

А разве я говорил что QString - "плохой" класс, позорно медленный

Да, QString довольно жирный/затратный класс

В своем велике по меньшей мере вреда никакого. Беда совсем в другом - если человек пользует инструмент не умея сделать свой велик

Звучит как "ах ты, гад, не велосипедишь!"  Откуда такая злобв к готовым инструментам?

//В результате очень часто выбор этого контейнера неудачен. Использование готового хорошо при наличии своего опыта, иначе результат обратный.
код отработает на 20 микросекунд медленнее?)

[xokc]

код отработает на 20 микросекунд медленнее?)

Какое пренебрежение к микросекундам. А если именно этих микросекунд и недостаточно?
Я к тому, что выбор реализации надо бы привязывать не к любви (или не любви) к велосипедам, а к требованиям ТЗ.

[thechicho]

//этих микросекунд и недостаточно
для чего?

нет требований и тз. есть задача, которую надо решить.
в контексте задачи ТС видно, что не имеет значения отработает код 1 микросекунду или 20.
вообще не понятно, почему он решил работать с qt, учитывая что в коде std::string.
но раз он здесь, то исходя из контекста форума, было предложено решение с использованием qt, котороше пришлось не по душе Igors, о чем он популярно намекнул

Ну Вы же сами понимаете - это халтура. Давайте перельем строку из одного представления в другое, где есть удобные утилиты, а потом обратно. Да, делов неск секунд, но ведь платим оптимальностью. Вот кто-то ускорит Ваш код раз так в 20 и скажет типа "там какой-то лошара писал, с пых-пых наверно". И, поверьте, будет неприятно.

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

Вы можете использовать советы выше или написать свои утилиты - прекрасная возможность потренироваться в языке. Если опыта пока мало, то последний вариант заметно лучше

[Old]

Откуда такая злобв к велику? Ну не увидел этой вещички в бусте, ну сделал свою - почему это преступление? Почему я был обязан непременно найти и воспользоваться, почему Вы считаете это "делом чести", "показателем класса"? Это же чущь собачья  

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

Ну не увидел этой вещички в бусте

Вы просто не знали, что уже есть готовое. Можно было просто сказать: "Я не знал". В этом нет ничего дурного, н овы начали придумывать какие-то нелепые причины. именно это всех и забавляет.

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

Вот-вот. Загляните к себе в исходники и ужаснетесь.

[Spark]

Spark, ну Igors вам популярно намекнул, что надо начинать с частностей, а потом переходить к целому, выражаясь вашим

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

Ну Вы же сами понимаете - это халтура. Давайте перельем строку из одного представления в другое, где есть удобные утилиты, а потом обратно. Да, делов неск секунд, но ведь платим оптимальностью. Вот кто-то ускорит Ваш код раз так в 20 и скажет типа "там какой-то лошара писал, с пых-пых наверно". И, поверьте, будет неприятно.

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

[Spark]

нет требований и тз. есть задача, которую надо решить.
в контексте задачи ТС видно, что не имеет значения отработает код 1 микросекунду или 20.
вообще не понятно, почему он решил работать с qt, учитывая что в коде std::string.

Вроде как пояснял. Объект трасплантации межплатформенный и делался с использованием Qt. Я правлю нужный мне модуль. Поэтому частные задачи вытекают не из моих соображений, а то, что диктуют условия. Изменить весь код я не смогу как бы я не старался. Программа слишком сложна для меня, с моим скромным опытом. Мне бы научиться в интерфейс вносить нужные мне изменения и доделать свой модуль (пожалуй он уникален в своем роде).

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

[xokc]

//этих микросекунд и недостаточно
для чего?

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

в контексте задачи ТС видно, что не имеет значения отработает код 1 микросекунду или 20.

1. Я где-то говорил про то, что это нужно ТС?
2. Мне лично - не видно. Я не знаю зачем ТС смешивать строки разных типов. Может он управляет сложными технологическими процессами с критическим временем доступа или, например, этот участок кода выполняется миллион раз.
3. Задача ТС вполне успешно решена много страниц назад, а весь дальнейший флейм давно уже никаким боком к проблемам ТС не относится.

[Igors]

Вы просто не знали, что уже есть готовое. Можно было просто сказать: "Я не знал". В этом нет ничего дурного, н овы начали придумывать какие-то нелепые причины

Конечно не знал, и никаких причин не выдумывал. Просто от того что я написал это сам - мне аедь хуже не стало  

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

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

[Spark]

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

Второе. Не миллион конечно, но с 1000 вполне может быть.

[Old]

Конечно не знал, и никаких причин не выдумывал. Просто от того что я написал это сам - мне аедь хуже не стало  

Смотрим развитие событий... ТС нужны регулярные выражения. Вы готовы исправить ваше решение для этого? Минут же за 10-15. Нет?
Ваше решение продержалось недолго, и полетело в мусор. А мы спешим или к boost или Qt. Все мы поехали дальше, машем вам рукой....

[Igors]

Второе. Не миллион конечно, но с 1000 вполне может быть.

Да дело даже не в скорости (или не только в ней). В рамках модуля (или по крайней мере файла) строковый тип должен быть однообразным. Перекачивая туда-сюда Вы как бы заявляете "ну я совсем уже бедный и больной, не бейте" - такой подход, мягко говоря, "несолидный"  

[thechicho]

//В рамках модуля (или по крайней мере файла) строковый тип должен быть однообразным.
ТС адаптирует код под свои нужды. следуя вашей логике, ему либо нужно переписать чужой код средствами qt, либо писать стандартными средствами языка. второй вариант для ТС оказался затруднительным, а решение нужно сейчас.

Оптимизировать можно будет потом. Важно довести саму идею до ума.