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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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