"Отставание" Qt от Cxx

[Azazello]

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

О чем Вы - не знаю, а я да, об этом. Неперемещаемые данные (указатели на которые хранятся в др классах) неизбежны, и это ситуация типовая. QList решает эту проблему - и это хорошо

Кхе. Извиняюсь, если не корректно выразился.
Смысл моего посыла был таков: когда вы работаете с большим массивом данных, указатель на конкретный элемент не имеет значение.
Я понимаю, что: не говори мне как делать, и я не скажу тебе куда идти.
А почему? (не имеет значение указатель). Когда идет работа с большим массивом данных, встают другие проблемы (производительности) и такие мелочи, как  потеря указателя теряет свою актуальность и её обходят. Но почему вот вам нужен один указатель на один элемент среди миллионов.

[Igors]

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

Пример из моей практики. Вот 3D модель имеет вертексы и фейсы. Ну разумеется они хранятся в векторах, эти данные могут быть сколь угодно велики. Пусть немногие но есть фичи которые используют индексы вертексов (напр skin или morph) или фейсов (напр фейс материал). Если "топология" изменилась (произошла вставка/удаление) то либо "ой" - ссылающийся стал невалидным, либо городить немалый remap (тот еще гемор). Поэтому "размер имеет значение". Но даже несмотря на это используются вектора, др контейнеры обойдутся слишком дорого.

Но вот хранить сами модели в векторе и бегать потом с индексами - это уже полная глупость. Хотя их тоже может быть достаточно много. Вот Вам простой пример перемещаемых/неперемещаемых данных.

[Azazello]

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

Пример из моей практики. Вот 3D модель имеет вертексы и фейсы. Ну разумеется они хранятся в векторах, эти данные могут быть сколь угодно велики. Пусть немногие но есть фичи которые используют индексы вертексов (напр skin или morph) или фейсов (напр фейс материал). Если "топология" изменилась (произошла вставка/удаление) то либо "ой" - ссылающийся стал невалидным, либо городить немалый remap (тот еще гемор). Поэтому "размер имеет значение". Но даже несмотря на это используются вектора, др контейнеры обойдутся слишком дорого.

Но вот хранить сами модели в векторе и бегать потом с индексами - это уже полная глупость. Хотя их тоже может быть достаточно много. Вот Вам простой пример перемещаемых/неперемещаемых данных.

Умываю руки, вы отличный пример мне привели. Я понимаю его интуативно, в практической плоскости я с графикой не сталкивался.
Больше с статическими данными, хоть и постоянно изменяющимися, но пакетно.
НО! На то и она говорилка, чтобы каждый осмысливал другие стороны аспектов.

[qate]

В продолжении про контейнеры - почему простое добавление QMap<QString, QString> в класс увеличивает итоговый размер на ~17кб ?

[Igors]

Но std::string круче, когда нужна производительность - есть поддержка малых строк.

В qt6 будет SSO. Так-то негоже ломать совместимость каждые полгода, а SSO требует нарушения BC. Почему в Qt5 не добавили, отдельный вопрос, но патч уже вроде бы тогда был.

А что такое SSO? (вику глядел но там явно не то). Спасибо

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

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

[ViTech]

В qt6 будет SSO.

А короткие строки там до какой длины планируются?

[Авварон]

В qt6 будет SSO.

А короткие строки там до какой длины планируются?

Сколько влезет:) афаик, 4 указателя делить на 16 бит минус сколько-то инфо под флаг «ссо или нет», возможно минус 1 указатель (пока размер)

[ViTech]

Сколько влезет:) афаик, 4 указателя делить на 16 бит минус сколько-то инфо под флаг «ссо или нет», возможно минус 1 указатель (пока размер)

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

[Azazello]

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

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

Я понял, вы решили добавить "перчика".

А с чего бы это мне не нужны малые строки, если я пишу парсер. Вот уж извините, производительность парсера это как раз и его фишка. Так что не могу жить без малых строк - и все тут! Тем более, никто их к модным фишкам не приписывает, т.к. особо и не знают. Да и не видно эту моду. Ну как можно показать код и сказать - тут у меня модные короткие строки. А тебе так хрясь по башке: ТЫ КАК std::string то назвал!

И мода в программировании на с++....... Ну это что-то из рода фантастики. На чистом си можно быть модным чуваком сколь угодно времени. Но не представляю программиста, которые не знает хотя бы о существовании фишек своего языка.

Какая мода. Написать и забыть - вот моя мода.

А вы такой - мув? Да вы че, салабоны, а ну копировать! Лямбды им б..... подавай.
Да и какой к черту мув это фишка. Обычный COW с обменом, просто рассказанный всем так, чтобы вообще никто ничего не понял и думали что это магия.
 
И про крутые фишки: да их столько крутых, что никто на C++ за ними не гонится, просто изучать приходиться, что, конечно, свойственно женщинам.

[Igors]

А с чего бы это мне не нужны малые строки, если я пишу парсер.

Так "если" или "пишу"? В этом все дело 

Вот уж извините, производительность парсера это как раз и его фишка. Так что не могу жить без малых строк - и все тут!

Думаю малые строки никак не связаны с производительностью парсера. Конечно каких-то компиляторов я не писал, но распарсить тестовик раз в 1-2 года приходится. И этого опыта достаточно чтобы утверждать - парсер не должен создавать новых строк вообще. Ни больших, ни малых. Он должен оперировать только со ссылками на (неизменную) исходную строку/текст.

И мода в программировании на с++....... Ну это что-то из рода фантастики.

Да неужели? Посмотрите с каким вожделением лепится что-то типа std::bind, forward, decltype и.т.п. (в том числе и на этом форуме). Текст без этого не катит - ну это же просто "С с классами". А когда разберешься со всеми этими прибамбасами - выясняется что "содержательная часть" близка к нулю Человека можно понять - он ведь "выучил", значит "надо применить" (не зря же учил). Но объективно это пижонство чистой воды

[Old]

Да неужели? Посмотрите с каким вожделением лепится что-то типа std::bind, forward, decltype и.т.п. (в том числе и на этом форуме). Текст без этого не катит - ну это же просто "С с классами". А когда разберешься со всеми этими прибамбасами - выясняется что "содержательная часть" близка к нулю

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

Человека можно понять - он ведь "выучил", значит "надо применить" (не зря же учил). Но объективно это пижонство чистой воды

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

[Azazello]

Так "если" или "пишу"? В этом все дело  

А с чего бы это мне не нужны малые строки, если я пишу парсер.
Аааа. Вы хотите из меня Маяковского сделать.
Да пожайлуста: Строки малые нужны - парсер я пишу!

Вот уж извините, производительность парсера это как раз и его фишка. Так что не могу жить без малых строк - и все тут!
Думаю малые строки никак не связаны с производительностью парсера. Конечно каких-то компиляторов я не писал, но распарсить тестовик раз в 1-2 года приходится. И этого опыта достаточно чтобы утверждать - парсер не должен создавать новых строк вообще. Ни больших, ни малых. Он должен оперировать только со ссылками на (неизменную) исходную строку/текст.

Ну, буду отвечать в вашем стиле. Думаете или знаете?
Парсер не создает новых строк только в одном случае - если вы пишите самостоятельную работу ну или там банер погодки распарсиваете (на плюсах?).
Да хотя бы ключевые слова там хранятся. Или другой вариант, компилируете вы программуленку, тут у вас куча ошибок, вы файл закрыли в иде и О ЧУДО, все ошибки исчезли..... Не, внутри много оптимизаций со stringView. Но вот в чем засада. Да даже Токен с короткой строкой, короче (по ресурсам), чем токен с позицией и длиной строки да и ещё и с самим указателем на исходник строки да ещё и с контролем что исходник строки жив.

Да неужели? Посмотрите с каким вожделением лепится что-то типа std::bind, forward, decltype и.т.п. (в том числе и на этом форуме). Текст без этого не катит - ну это же просто "С с классами". А когда разберешься со всеми этими прибамбасами - выясняется что "содержательная часть" близка к нулю Человека можно понять - он ведь "выучил", значит "надо применить" (не зря же учил). Но объективно это пижонство чистой воды

Ну вот я не представляю эту ситуацию. Сидит чел, кодит. И вы подсматриваете за ним. И тут видите вожделение на его лице. Глядь в экран, а он, в этот момент набирает std::bind, forward, и, что хуже - decltype! (хотя по мне самый противный std::bind).

Ну чтож. Пусть мы с вами не правы и никогда не сойдёмся.
Что делаем - отрываем исходники stl  - и понимаем, писали его одни вожделенцы!

От подонки. Ещё и в комитете сидят. Гнобят память дедов наших! А не, стоп. Просто гнобят дедов. Тоже не то. Во! Гнобят нас.

Не, мысль можно вашу понять.
Ну вот не знаю я ваш std::bind. Да, могу написать, поковырявшись, но так лениво, вот смотрите, я уже алгоритм набросал рабочий, пока вы там биндингом с форвардингом занимались. А у вас что? Вот оно, работает! Но отставание все же будет расти, и в какой то момент времени, если не набить руку с этой всей трахамурдией, вы начнете много времени тратить "не на то". Я вот тоже никогда (и сейчас тоже) не мог запомнить синтаксис указателя на функцию (чтобы самому накалякать). В конце концов с этим смирился и подсматриваю его в инете. Но уж если у меня таких вещей будет половина.....

Ну и ещё + использование новомодних плюшек сразу: Вы на них руку набиваете и знаете уже. Если же просто понял и не набил руку, приходится все заново проходить и код уже не "вылетает из под пальцев" и не так быстро воспринимается.

[Авварон]

От подонки. Ещё и в комитете сидят. Гнобят память дедов наших! А не, стоп. Просто гнобят дедов. Тоже не то. Во! Гнобят нас.

Диды на фортране писали! Помню, в 45м под берлином...

В конце концов с этим смирился и подсматриваю его в инете

Вариант с тайпдефом\использованием на месте я тоже не могу запомнить, но можно подложить соломки

Код:

using Foo = void (*)(int);
Foo bar = baz;
bar(42);

[Авварон]

Сколько влезет:) афаик, 4 указателя делить на 16 бит минус сколько-то инфо под флаг «ссо или нет», возможно минус 1 указатель (пока размер)

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

Я пошерстил рассылку и уже не так уверен, что SSO гарантированно будет.
В любом случае, они где-то писали, что "640к хватит всем", т.е. большинство строк таки влезут.
Энивей, если SSO будет в QString, то и в батарей (или точнее 8битную строку, вроде бы хотят отпилить батарей отдельно) должны завести, а там можно будет юзать 8битную кодировку.
Но там столько планов, что хз, когда и что из этого они сделают в итоге.

[ViTech]

Энивей, если SSO будет в QString, то и в батарей (или точнее 8битную строку, вроде бы хотят отпилить батарей отдельно) должны завести, а там можно будет юзать 8битную кодировку.

А эта 8-ми битная строка не будет той же std::string, только в профиль? В std строк полно, выше писали, что в бусте алгоритмов для строк наделали, в ICU вроде наработок хватает. Пора бы уже унифицировать это зоопарк, а не ещё зверушек плодить .