Ты в cpp.sh код покажи, Так чтобы он компилировался и работал только. А то он пока не на что неспособен, а ты выглядишь как неудачник наложивший в штаны.
Ламерок опять продемонстрировал свою никчёмность. Одни сливы, никаких внятных аргументов — «не способен» — почему? На основании чего я «выгляжу как неудачник»? На эти вопросы нет ответов, да и не будет.
А судя по тому, что днище даже мою ошибку не заметило — ну дело такое. https://godbolt.org/g/pgLZR3
Так в твоём же примере выше было что написано? //значение указателя.
И? У тебя-то не используется значение указателя — значение используется для копирования памяти.
Строка пишется в char[], читается из char[] — указатель там форфан и ничего не делает. У меня же функция возвращает именно значение.
Получается от своих слов отказываешься? Ох и балаболка XD
От каких слова я отказываюсь? Поподробней.
В целом потуги амёбки ясны — пытается что-то там мне балаболить, ловить, сама понимает что это бесполезно, но на что-то надеется.
Всё началось с десятках разных предметов — разрослось до пары десятков, но в конечном итоге всё слилось к нулю, ибо по каждому балаболка обделалась. А дальше пошел игнор, «школьник» и прочее.
Ну по тебе заметно, школьничек.
Когда ответить нечего и обделался — жуй. Ты бы хоть попытался ответить за свою брехню, на которой тебя поймали.
XD Ох знатно я поржал, спасибо, сохраню для памяти.
Ну что я могу сказать — для обделавшегося постоянное заострении внимания на том, что от кого-то воняет — типичная потуга.
Ох бедные люди что с тобой общаются, хотя с тобой наверно никто и не общается.
Те, кто обладают хоть каким-то развитием могут.
Ну или в реале ты более сдержан или давно бы отхватил.
От кого?
По факту получается, что ты не объяснил по какой причине raii не состоятельно, лишь утверждал что то-то то-то сделано для raii, а raii не состоятельно, балабол? балабол. Слив засчитан.
Совсем балаболка сломалась. Ну ничего — бывает. Там было все объяснено — я могу повторять это бесконечно и ты будешь врать, врать, в надежде, что мне когда-то надоест(хотя нет — достаточно хомячкам тыкать -1 и через неделю будет 1 пост в неделю, чего собственно слившиеся и добиваются).
Наследование памяти вы не показали, а то что по ideone феерично, спасибо буду как анекдот показывать.
Показал. Хотя опять же — ситуация аналогичной той, что выше. Если тебе нечего возразить — этого уже достаточно для определения тебя как слившегося. С таким же успехом я могу говорить «показал» — дальше что?
Простите, а значение указателя где хранится? Не в памяти ли? XD
Причём тут где хранится — хранится представление значение и там всё это описано. Как ламерок слился с «в указатели» на «в памяти», ну бывает.
Мда, значение указателя хранится в памяти которое выделенно под переменную которая является указателем, собсно мой код в эту память и пишет, по факту получается что строка хранится в указателе.
Нет, ламерюжка. Память не обладает формой. Переменная — это форма. Память хранит представление перменной. Твой код пишет в память, но не в указатель. По факту получается, что строка хранится в памяти. В указатель пишется значение.
А ваш пример про мочу необычайно ржачный. Можете побольше подобного написать? Очень прошу.
Кстати приведите пожалусто пример использования вашего кода с переводом строки в указатель, а то он отказался компилится
Мои примеры иллитны и идеальны. В любом случае что бы ты не пытался из себя строить перед пацанами — сильнейший уже определился.
Ну что я могу сказать — ламерок, который не знает ни языка о котором кукарекает, ни разбирается в том самом программировании о котором кукарекал(вернее обвинял меня). Если ты настолько тупой, что не можешь собрать хелворд — ну дак это твои проблемы.
Так мы смотрим объективно или субъективно? Вы то пока не сказали по какой причине raii не состоятельно.
Я написал причины — игноришь я могу начать не позволять тебе этого делать. Хочешь чтобы я продолжил с тобою играть — веди себя вменяемо.
Ну и да причём тут вера? По факту все используют, а значит фича востребованна.
Вера тут притом, что принятие аргумента «все не могут ошибаться» — есть вера, т.к. в ином случае это не аргумент.
По факту маршрутка то же востребована, только это не значит, что это вменяемое средство передвижения. Ширпотреб и дерьмо всегда востребованы — только из этого ничего не следует, ну кроме того факта, что дерьмо востребовано.
Не состоятельной она была бы если бы её никто не использовал, как например старый auto.
О боже, что же вы все такие тупые. У неё нет альтернативы — естественно её используют. Толку говорить о каком-то выборе, если выбора нет? В крестах изначально раии-контейнеры определялись как полноценные, поэтому не вводили никаких не-раишных контейнеров — сейчас введением вменяемых «контейнеров» она косвенно согласились с неполноценностью раии. Но у ламерков уже есть оправдание — string_view — это для тех, кто не осилил мув-семантику. Уровень некомпетентности рядового крестового балабола меня просто поражает.
Пример с авто — пример банальной жертвы левого звона — авто — это значение по умолчанию, естественно его никто не использовал не потому, что оно «не популярно, не нужно» — оно не имеет смысла. Авто просто наследие си, в котором авто то же наследие.
Не понял эту фразу, перефразируйте пожалуйста. И подробней распишите в чём конкретно raii не состоятельно.
Пошли сливы. Не понял — идиот. Нашел ошибку в моей формулировке, либо можешь доказать, что не понял не по причине своей некомпетентности, а из-за меня? Валяй. Но хоть и поплыл — я пожалею убого и объясню.
Изначально контекст был «не забыть об оптимизации», далее автор коммента продолжил его «стл оптимизированная — ко-ко-ко». И в этом контексте все утверждения озвучивались. Сейчас ты, как и любой ламерок, пытаешься съехать на «автоматическое управление ресурсами удобно для низкоквалифицированной силы, либо для быстрой разработки дерьма», но контекст был не в этом. Давай ещё проще, контекст был в ориентации на ТТХ конечного продукта, а не на простоту разработки, её дешевизну, доступность кадров и прочее.
При этом говорилось о строках как примере той структуры, где раии не состоятельна и объяснялось почему.
Простите, но у вас там чушь была про наследование памяти.
Опять ты, амёбка, мне пытаешься врать и юлить. Если там чушь — докажи и покажи где, а так своим высером ты можешь только подтереться.
Так что ответа вы так и не дали, по крайней мере я его там не нашёл, перефразируйте.
Опять же — вранье. Не дал — докажи, не нашел — докажи, что его нет. Нахрен ты мне врёшь? Повторюсь ещё раз — если ты не разбираешься в теме — зачем ты споришь?
Меня не волнуют твои взывания к ООП и прочим мантрам, заклинаниям. Я тебе описал альтернативную концепцию, которая оптимальней и проще.
Есть что возразить — валяй, а нет зачем ты мне пишешь «твоя альтернативная концепция не соответствует моей концепции» — естественно, на то она и альтернативная.
XDDD Да действительно, и пофиг что всё классы стл написаны в ООП стиле, они неправильные, потому что всё должны писать только в моём правильном стиле XD отлично
Опять эти глупые потуги. Ты реально думаешь, что ссылаясь на свои обезьяньи поверья ты сможешь меня поймать? Читая мне мантру про ООП — думаешь, если она в твоём стаде популярно — её не покрыть? Такая глупая и наивная балаболка.
Я уже говорил — твои потуги могут производить(хотя куда там производить — ретранслировать) логику уровня «насекомое» и в стае подобных тебе ты можешь крыть других насекомых, но проблема в том, что как бы ты не пытался меня двигать — это невозможно по определению.
Давай я тебе покажу почему твои потуги тщетны.Изначально нигде не говорилось о том, что что-то должно быть ООП(ну в твоём понимании его — ты ведь не объяснишь почему моя концепция не ООП, но это такое). Говорилось о разработки на результирующие качество кода с т.з. ТТХ. Далее утверждалось, что текущие стл итак максимально «быстр», но я объяснил и показал почему это не так. Из этого косвенно следует, что стл максимально быстр для той концепции, которую он реализует, а значит сама концепция является не годно в контексте «оптимизации».
Поэтому никакие потуги тебя не спасут, в любом случае ты сольёшься.
, на этом в принципе можно разговор и окончить, но вы слишком забавны так что продолжим.
На этом, если я тебя спрошу «на чём» — ты обделаешься, поэтому что-то кукарекать не советую. Да и куда тебе продолжать, ты уже понимаешь что попытка твоя провалилась.
Приведите пожалуйста пример наследования памяти в С++, ну или в любом другом языке, мне прям интересно.
О боже, днище. Почему ты такое глупое — тебе уже показали. Структуры обладают своей памятью, т.е. любое определение чего-то в структуре использует память структуры.
http://ideone.com/MBD86P
Собери(попытайся) вменямым компилятором это сам — так помойка на ideone не может в мой код.
эм… где же? string это контейнер и предназначен для полноценной работы со строками, sring_view это посетитель предназначен исключительно для просмотра содержимого и то с довольно строгими ограничениями.
Интерфейс просмотра содержимого — это указатель. Брехня номер один.
Далее, sring_view — это такое же представление си-строки, как и string с той разницей, что sring_view не владеет этой самой си-строкой(т.е. данными).
Общее у них только возможность просмотра. Концептуально, они разные.
Общее у них всё. Может const string и string — то же концептуально разные? Обладает теми же ограничениями, что и sring_view. В целом ты забрехался.
В конечном итоге выходит так, что string интерфейс с владением, как и все «контейнеры» в стл. Владение им нужно только для раии.
Все интерфейсы для просмотра(те же итераторы) имеют доступ на модификацию — т.е. модификация того, чем владеет контейнер может происходить вне его интерфейса.
sring_view вписывается сюда полностью, но ro он только по причине того, что у пацанов случилось раии.
ох знатно бомбануло.
Если ты думаешь, что у меня бомбануло — это твоя проблема. Мой обычный стиль куда более агрессивен чем то, что ты видел. А то, что я тебя жалею и даю возможность юлить, а так же веду дискуссии с тем, кто не обладает нужно квалификации для их ведения — это не является моей обязанностью, а является жестом доброй воли.
Чем конкретно моё решение отличается от вашего? Кроме того что оно компайлтайм и с проверками?
Я тебе уже объяснил. Прочитай в словаре значения слова «значение» и научись отличать содержимое от пространства. В содержимом — это в содержимом, а в пространстве — это в пространстве. Я тебе уже приводил пример с мочёй и банкой — способен думать — думай, а не способен — нахрен я тебе распинаюсь? Я там выше это то же разобрал.
Ты должен уже научится понимать что такое структура и объект. А далее тебе будет понятно — где хранится строка — правильно в памяти объекта.
Структура — это пространство в той банке. Банка саморасширяется. Добавляя туда 8кубиков мочи — ты расширил банку — она(её объём) стала 8кубиков. Моча — это значение пространства в банке. Моча — указатель. В указателе — значит в моче.
Далее всё просто — это пространство можно использовать под 8печенек, но они будут в пространстве банки, т.е. в банки, т.е. в структуре/юнионе, а не в заполнителе(значении) — моче. Понимаешь?
Там написано, что в один момент времени может быть активно только одно поле — у тебя активно 2.
А ну раз некст ген то ок, мужики то не знали XD
Потуги ламерков меня не волнуют — есть что возразить — пытайся.
О да ООП оказывается завязано на работе с аллокаторами, прикольно.
Да, завязано. Хотя мне уже надоела что-то пытаться объяснить ламеркам. Принцип ООП — это построение конечных объектов из набора объектов. И аллокатор это такая же часть объекта, как и не аллокатор.
А то что stl контейнерам можно указывать свои аллокаторы вы походу не в курсе?
О боже, убогое днище. Зачем ты мне это пишешь? Я где-то разве писал, что нельзя? Я там писал про интансы аллокатора, хотя опять же — сходи в словарь я не обязан каждый раз ламерку что-то объяснять.
In a union, at most one of the non-static data members can be active at any time, that is, the value of at
most one of the non-static data members can be stored in a union at any time.
Кстати я подумал подумал, и концепция которую вы описывает довольно сильно напоминает обычный процедурный стиль, там как раз данные отдельно, интерфейс отдельно.
Эта концепция напоминает любой стиль, просто вы этого не понимаете. Просто вам встретились знакомые ключевые слова из представления функций/классов.
Алгоритмы — это операции над данными, при этом данные представляются в виде обобщенного инстерфейса доступа(который данными не владает).
Итераторы — интерфейсы доступа. string_view — интерфейс доступа. Адаптеры — интерфейсы поступа. И «контейнеры» должны быть интерфейсами доступа.
Но с этим проблема — универсального представления данных нет и нам надо было бы городить 10разных хранилищ данных. По этой причине и родился этот больной симбиоз.
А это данные отдельно — это некстген, авось когда-то в крестах до этого допрут, как допёрли до string_view — хотя это и заняло 20лет. И получается — у тебя множество аллокаторов — нужна строка с кешом? Взял буфер с кешом, указал размер кеша — вкатил его в строку — идельно. Далее авось осилятся инстансы аллокатора. Это ООП, а то что у тебя — кастыли
Практически все классы все фрэймворки, api используют raii так что вполне очевидно что утверждать о не состоятельности raii глупо.
Во-первых, уже после 5-го класса дети не верят в аргумент «все не могут ошибаться». Зачем ты мне его выкатываешь?
Во-вторых, говорилось о нестоятельности раии в контексте строк, копирования и прочего в контексте производительности. Что там у тебя и как используется — меня мало волнует.
, а что контекст как-то меняет то факт что вы связываете оператор копирования и raii? По моему нет, так что я жду ответа.
Ответ был, но опять пошли потуги врать.
Не верно — строка является интерфейсом к данным. Когда мы копируем интерфейс — мы копируем интерфейс. Даже если применить твоё понимание — нам нужна в строке идентичная информация, а не сам факт копирования.
И далее по тексту всё разжевано.
Вы вообще не понимаете концепцию ООП где пользователь оперирует объектами, а не отдельно памятью отдельно интерфейсом.
Меня не волнуют твои взывания к ООП и прочим мантрам, заклинаниям. Я тебе описал альтернативную концепцию, которая оптимальней и проще. Есть что возразить — валяй, а нет зачем ты мне пишешь «твоя альтернативная концепция не соответствует моей концепции» — естественно, на то она и альтернативная.
Объект это совокупность данных и интерфейса по работе с этими данными, это единое целое.
Подожди, а string_view — это не объект? Зачем его впилили? Наверное за тем, что аришная строка показала свою полную несостоятельность?
Копия объекта это копия как интерфейса так и данных.
Копия интерфейса — это копия интефрейса. Копия данных — это копия данных. Почему вдруг у тебя интерфейсы-итераторы не владеют объектами, стримы не владеют объектами — как же так?
Это типичные дыры в представлении, но ты как рядовой верующий это пытаешься как-то оправдать. У нас есть объект — это данные(в данном случае строка) + интерфейс доступа к ним и операции над ними. Но ведь суть stl — это разделение данных и операций. У нас есть итераторы, которые такие же интерфейсы в данным. У нас есть алгоритмы, которые так же интерфейсы к операциям над даннымы и у нас есть строка, которая то же интерфейс к данным.
Получается, что строка по логике вещей должна быть чем-то навроде итератора в к данным и такое понятие есть в стл — адаптер. Но опять же из-за того, что раии пришлось кастылять смесь адаптеров и данных.
В концепции ООП у пользователя вообще не должно быть прямого доступа к данным, о каком разделе интерфейса и памяти ту вообще может идти речь?
Меня не волнуют эти потуги и эти заклинания. Я не собирают ограничивать себя чьими-либо догмами и прочем. Но опять же, даже тут ты сбрехал и наврал.
Тебе никто не заставляет давать прямой доступ к данным — у тебя есть объект membuf, либо ещё что-то и на него уже натягиваются всякие интерфейсы. Нужна строка? Вот тебе строка. Нужна раишная строка? Вот тебе строка раиишная. Такой подход сейчас в тех же указателях — есть память, а указатель с владенеим и без. Тут то же самое.
WAT?! Что я бред, о каком языке вы вообще говорите?
В логике си и С++. Любая «память» является не-копируемой. Память сама по себе, кроме случаев, когда она является частью объекта(массивы в тех же структурах). Но опять же — они не копируемые — копируемые сами объекты.
А в часть самой строки почему она не может?
Потому что другой функционал, другие требования, другое предназначение. Потому это и является совершенно другим инструментом.
Слив засчитан. Предназначение идентично. Является частью одной библиотеки, но интегрирован только в одну строну — string_view — интегрирует в обе. Твоя вера и оправдания смешны.
И какой же там другой функционал, какие такие другие требование, какое-такое предназначение? Отвечай, а не балаболь.
Один и тот же кусок памяти под разные переменные.
И опять пошли сливы. Опять пошел юлёж. Ты мне в указателе покажи, а не в том же куске памяти. И да, это уб, но ты продолжнай игнорить.
Ок если вы не умеете union то вот альтернатива http://cpp.sh/6pyld
Опять же где тут «в указателе» — я не вижу. Ладно, давай специально для ламерков я поясню.
Вот в указателе, а то, что у тебя «не в указателе».
Смотрите пример выше, уже без юниона
О боже, почитай в словаре значение слова «значение», а потом научись отличать «в жопе» и «вместо жопы"/«по месту жопы». Давай ещё раз ссанина может быть в банке, вместо воды, но никак не в вводе. Ты вылили воду из банки — налил ссанину и говоришь — «ну вот ссанина в воде» — нет, ссанина не вводе — она вместо воды.
Естественно, ведь ты не слился — просто невозможно вести, но почему — ты никогда не скажешь. На какой вопрос я не ответитл — не скажешь. Почему простыни не относятся к обсуждаемому вопросы — не скажешь. Пытался, да, ты пытался юлить и ловить, но как оказалось рыбка пыталась ловить рыбака — бывает.
Вы действительно думаете, что вы видите там что-то, что не вижу я?
Попытки с «указателем» — являются такими же манипуляциями и враньём, ибо говорилось «в указателе», но потом понятие поменялось и стало «в массиве в юнионе», что можно трактовать как «вместо указателя», но никак не в. При этом трактовать это ошибкой в формулировке не получится, что «копируется как число» — т.е. подразумевалось именно представление строки в числе(указателе).
Далее, опять же — все как-то забыли про «копируется как число», чего нигде нет.
В конечном итоге буфер замещает некоторые поля(копасити + хвост в гцц, а в шланге все 3поля), копирование происходит так же.
При этом ещё не следует забывать, что это пессимизация того же доступа по индексу, доступа вообще, но это такое. В гцц кстати об этом подумали, а шланг — такой шланг.
Я не утверждал, что вам нельзя говорить, я сказал что так говорить глупо. Л — логика
Но не сказал почему( и проигнорировал этот вопрос) — вывод — балабол.
Вот ту объясните пожалуйста как вы связали копирование и raii?
Во-первых дёрганье из контекста. Во-вторых — что же ты спастил одно, а не спастил другое? Ладно, ты вроде вменяемый и реально тут не понимаешь, а не юлишь как твои собратья.
Например string является абстракцией над строкой (ваш кэп) следовательно, когда мы копируем строку мы хотим скопировать именно строку а не указатель на неё.
Не верно — строка является интерфейсом к данным. Когда мы копируем интерфейс — мы копируем интерфейс. Даже если применить твоё понимание — нам нужна в строке идентичная информация, а не сам факт копирования.
Указатель — это интерфейс. Строка — это интерфейс. А данные — это данные. От копии строки нам надо только то, чтобы мы могли получить те данные, что хранились там до копирования.
Т.е. строки не обязательно должны чем-то владеть, они могут владеть одним и тем же(тот же ков).
Далее, во вменямых концепциях интерфейс доступа к данным и сами данные разделены. Они разделены на уровне си, который есть основа крестов. Есть данные — это массивы, хип и прочее, а есть объекты — это структуры, базовые типы и прочее. По этой причине данные в си/крестах не-копируемые, объекты и базовые типы копируемые. Память копируется отдельными средствами.
В логике языка, если объект не наследует память — он ею не владеет. При этом по логике здравой интерфейс доступа никакого отношения к тому, к чему у него есть и владеть этим чем-то не должен. В реальности же строки и владеет только интерфейсом, поэтому всё владение памятью — это заморочки раии. Т.е. риии не даёт взять кусок строки, не даёт сделать копию интерфейса — копия интерфейса делается через кастыль «мув-семантику». В крестах через 20лет до этого допрёли — молодцы, только это ничего не меняет.
И вменяемая концепция выглядит так: есть память, а есть интерфейс. Интерфейс отдельно — память отдельно. Это даёт возможность без убогих кастылей использовать разную память, что сейчас невозможно. Интерфейс копируется как интерфейс. Память копируется как память. Хочешь копию строки? Создай копию памяти и отдай её интерфейсу.
И это абсолютно логично, т.к. в подавляющем большинстве нам нужна копия интерфейса.
В конечном итоге что мы имеем — невозможность сделать копию интерфейса — это проблема крестовой строки, которая вызвана раии(т.к. она должна им владеть) — для этого собственно и сделали интерфейс без владения. Из этого всего следует, что копирование только интерфейса не теребует никакой мув-семантики, а все «оптимизации» которые принесла мув-семантика являются ничем иным, как костылём для копирования интерфейса.
эм… берёте инструмент и обвиняете его что он не выполняет функции другого инструмента? Отлично.
О боже — это не другой инструмент — это часть strings library, такая же, как и сам класс string. А в часть самой строки почему она не может?
А возвращать «другой инструмент» она может? А брать часть себя она может?
Я там не вижу чтобы что-то хранилось в «указателе».
Значит вы не знаете С++, рас не понимаете как работает union
О боже, и как же работает юнион? И да, причём тут юнион, если ты хранишь в указателе? Дак и храни в указателе, а не в юнионе.
Замените 8 на sizeof(char*) и не будет никого ub.
Я не придираюсь к херне. Будет — в юнионе.
Вы написали что это невозможно я привёл вам контр пример, а то что вы привели gcc stl так реализаций то много, вы уверенны что все пишут только так?
Говорилось именно про шланг и гцц. Опять же — враньё, вернее попытка игнорировать факт «копируется как число», вот шланг:
Потуги с «указателем» — являются такими же манипуляциями и враньём, ибо говорилось «в указателе», но потом понятие поменялось и стало «в массиве в юнионе», что можно трактовать как «вместо указателя».
По поводу как хранится — в шланге там паскаль строка поверх всех полей, а в гцц я уже говорил.
Еще раз. Какое именно использование glibc внутри STL вы имели ввиду, когда говорили «не более, чем генерик-интерфейсом к glibc»?
Опять попёрло враньё. Я жду либо ответа на:
Это не важно, ибо в основном посте говорилось о строках и стримах, автор того поста отвечал говоря об стл — есть претензии — выкатывайте их ему, а не мне. Я интерпретирую стл как libc++ — претензии не ко мне.
Изначальный посыл был:
Со временем C++ превратился из «быстрого» языка в «функциональный», и о производительности забыли. Сейчас уже ни для кого не секрет, что некоторые компоненты C++, например, библиотека iostream и строки, в силу своей природы не могут работать быстро; кроме того, отсутствуют некоторые основные возможности вроде управления передачей данных по сети и совсем уж базовые функции, например, простейшая процедура разбиения строк.
Ответ на это был на «о производительности забыли»:
Наверное, поэтому весь STL заоптимизирован по самые гланды, чтобы при каждом удобном случае вызвать наиболее эффективную операцию.
При этом нигде в изначально посте об STL(как только о контейнерах) не говорилось, а примеры были из не из аlgorithms/сontainers library, а из strings/io, но автор изначального комментария начал говорит об стл. На основании этого я могу обобщить stl по любой из списках библиотек, а не только аlgorithms/сontainers.
В предыдущем своем посте вы сказали, что это относилось только к строкам и стримам.
Не говорил. Я сказал:
Далее, я отвечал на «оптимизированный по гланды стл», а то, что ты описываешь не является оптимизированной частью стл.
Т.е. утверждая это я под этим имел ввиду только ОПТИМИЗИРОВАННУЮ часть стл, в которую аlgorithms/сontainers не входят(а их части являются такой же обёрткой, ну которые реально оптимизированы). Я это спокойно могу вывести и у тебя не найдётся ничего, чем ты сможешь мне возразить. Поэтому я не советую играться со мною, пытаться меня поймать — это глупая и непосильная задача для текущих моих оппонентов.
Теперь опять появилось «речь шла обо всем».
Враньё. Я такого не говорил.
Было сказано, что в посте в целом речь шла обо всём и в частности об аlgorithms/сontainers library. Ты спастил кусок и пытается врать, игнорируя сей факт.
Вы путаетесь в показаниях.
Так мило. И в чём же конкретно.
Ну вот, оказалось, что «строки являются оберткой над glibc» превращается в «операции конверсии строк в числа являются обертками над glibc».
Где же тут ТОЛЬКО «операции конверсии строк в числа»? Я жажду их увидеть.
Далее, разносить так разносить:
Стандарт определяет strings library как:
This Clause describes components for manipulating sequences of any non-array POD (3.9) type
Где компоненты есть:
The following subclauses describe a character traits class, a string class, and null-terminated sequence
utilities
В которых null-terminated-операции есть либц, string class есть обёртка над character traits, а character traits я уже выкатил.
Ну здравствуйте, капитан очевидность.
Хорошо, ладно — оставим балабольства и сливы выше. Значит всё обёртки, но при этом «STL» оптимизирована? Либо оптимизирована либц? Надо уж определиться в показаниях.
И сразу все высказывание теряет значимость, потому что очевидно всем и ни на что не влияет.
Попытки юлить такие пытки. Я уже не раз говорил подобным тебе, играться в следователей, ловить, иметь возможность что-то противопоставить — это всё работает только в вашем окружении, т.к. вы собираетесь +-1% от среднего уровня развития сообщества и вам начинает казаться, что вы действительно что-то можете — это не так. Глупо искать брешь в моей логике т.к. она совершенно иного уровня. Вместо пустых попыток ко вранью лучше бы попытался провести внятный анализ моего поста и оспорить его. Я даже тебе растолкую много непонятных слов/кода и понятий.
Хотя потом тебя точно так же будут минусовать, но за всё надо платить.
Скучно. Качество аудитории активных спорщиков тут действительно никакое. Зря я решил что-то написать.
Как это мило, люблю враньё. Меня всегда это удивляет — с чего вы решили, что те, кто не следует вашей линии партии чего-то там не понимают, либо ещё что-то? Может это вы чего-то не понимаете?
сказать что raii не состоятельно, это очень глупо.
Почему же? Т.е. мне говорить нельзя, а вам можно? Л — логика.
Вы похоже не понимаете разницу между копированием и передачей владения.
И действительно:
Почему в С++ вообще существует разница между копирование объекта и полей? Правильно — причина в самом С++, а вернее в raii. Т.е. перемещение является кастылём для raii, но никак не какой-либо оптимизацией.
Да и сам новый тип ссылок решает 2проблемы — отсутствие возможности передать r-value по не константной ссылки, а так же новая перегрузка операторов/конструкторов. Всё это нужно из-за всяких раишных понятий владения.
Строка не умеет в сишную строку 0_о простите а string().c_str() для чего?
О боже, ну если не понимаете о чём речь — зачем лезть? Речь идёт о том, что строка должна владеть строкой, т.е. строка не может содержать в себе си-строку, только её копию. Это исходит и из контекста string_view, и из «часть строки» — хотя зачем я это пишу.
Вы точно про С++ говорите?
Я уже выше отвечал на этот вопрос, но похоже вам нужно только болтать.
Я там не вижу чтобы что-то хранилось в «указателе». По ссылке уб. Про реальные имплементации стл я уже писал:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/basic_string.h#L120
Что мы видим. 3 оратора друг за дружкой слились, по-теме ничего предоставить не могут — одни переходы на личности, пакостят минусами, объективно слабы в той теме, о которой пытаются рассуждать. Чего вы пытаетесь добиться? Хотя я понял — тактика типичная для барьбы с более сильными регистрантами — минусовать в тёмную для того, чтобы оппонент вынужден был ретироваться, если не хочет остаться без рейтинга этого ресурса(или что там у вас). Не работает.
>>Ага, отлично, значит речь шла о строках и стримах.
Враньё. Речь шла обо всём, а тот факт, что я обобщил stl до всей libc++ — это не моё допущение, а автора комментария.
>>Во-первых, что же там такое в этих строках libstdc++ используется из glibc, что вы их называете «не более, чем генерик-интерфейсом к glibc»?
Строка определяется операциями, из которых все(которые пахнут оптимизацией) являются обёртками над string/mem/io из либц.
Во-вторых, вместо того, чтобы просто дать конкретный ответ вроде
Нет, в прочем игнор показателен. Я объяснил почему и от чего взялись стримы/строки в стл — вы это написали автору оригинального коммента? Ведь нет?
вы выкатили какую-то просто невероятную простыню из потока сознания про какую-то генеральную линию партии. За это и минусы.
Как же я люблю это враньё. Я там выкатил не только изобличение вашей мотивации, но и по теме стл — т.е. контейнеров и алгоритмов. Это было проигнорировано, чего и следовало ожидать — т.к. коммент написан был не с целью разобраться/объяснить etc, а с целью поймать, что явно не удалось. И не удастся по банальным причинам объективной силы.
Оценить моё понимание темы можно по моим постам — этого достаточно. Усомнившийся может поспорить. Аргументацией вида «выкатывание знамений» я не занимаюсь.
Нет, мне ставят минусы не поэтому. Я не написал ни единого лозунга. Ваше восприятие показывается обратное, ведь именно у вас идёт отторжение всего, что не соотносится с линией партии. Никто так и не смог внятно ответить без вранья, передёргивания — почему? Выиграть и поймать того, кто говорил лозунгами проще простого, но где всё это? Почему все попытки автора поста не увенчались успехом и он попросту слился? И как раз-таки это прямой показатель того, кто говорит лозунгами и поверьями, а кто воспринимает мир реально.
По поводу лозунгов — ты мои мне не предоставишь — я даже спрашивать не буду, а вот лозунги моего оппонента я представлю: «Не осилил» — типичное оправдание и аргумент против любого несогласного с линией партии. «Всё оптимизировано — всё идеально» — такой же типичный лозунг, который оправдывает любые претензии к качеству кода у популярных. Это два основных посыла.
А дальше пошли банальные мифы: «мув-семантика для оптимизации» — при этом утверждающий это не понимает зачем она нужна и почему, т.е. просто ретранслирует рядовые поверья. «в указателе строка лежит, а копировать её не так» — при этом утверждающий ничего не представляет о том, о чём говорит и просто ретранслирует тот звон, который он где-то услышал. «сопрограммы» — при этом утверждающий ничего в них не понимает, не понимает почему и зачем они нужны и что пытаются сделать те, кто их вводит и зачем. «шаблоны для быстроты», но опять же когда дело доходит до реальности — все почему-то сливаются.
Утверждающий попытался защитить миф про мув-семантику — не смог. Попытался защитить свой звон — не смог.
Ну зачем же так откровенно врать.
Основная часть STL — это стандартные контейнеры и алгоритмы.
Это не важно, ибо в основном посте говорилось о строках и стримах, автор того поста отвечал говоря об стл — есть претензии — выкатывайте их ему, а не мне. Я интерпретирую стл как libc++ — претензии не ко мне.
Я там так же описывал и контейнеры(алгоритмы и описывать не стоит — их реализация во всех стл никакая) вместе с тем почему это так. Я описал фатальный недостаток всего стл — никакой аллокатор. Фатальный недостаток вектора — отсутствие реаллока. Фатальный недостаток всех спископодобных структур(это списки, деревья) — это опять же убогий аллокатор. Фатальный недостаток хешмапа — это невероятный оверхед по памяти.
Так же у всего стл есть фатальный недостаток — это метадизайн + обобщенные реализации. Я рассказывал почему они не состоятельны на примере попыток его оптимизации, а все эти попытки были ни что иное — как выпиливание любого обобщения.
Так же я пояснил и по поводу интерфейса приведя в пример мертворожденный valarray. Любые оптимизации интерфейса и структур данных, унификации алгоритмов над ними не приживаются в «современном С++», ибо оптимизация там не нужна — все о ней кричат, но не более того.
О каком использовании glibc в них вы вообще говорите?
Повторюсь ещё раз, в статье говорилось об строках/стримах все претензии к автору поста на который я отвечал. Далее, я отвечал на «оптимизированный по гланды стл», а то, что ты описываешь не является оптимизированной частью стл. Ну и даже про неё я написал, а все твои придирки не более, чем враньё и попытки поймать меня, что является заведомо тщетным.
А причём тут fread? Автор намекает всё правильно, т.к. стримы — это форматированный ввод/вывод, а не аналог фриду. При этом они должены быть быстрее фрида. Да и с чего вдруг именно фрид? Фрид точно так же в силу своей природы быстро работать не может.
Сливает фриду. Цифры ммап смотреть не имеет смысла, ибо бенчмарк упирается в убогую реализацию doSomeComputation(). В реальности же ммап быстрее на порядок.
Рекомендую ознакомиться с концепцией обобщённого программирования.
Ответ на:
Во всём остальном, что не является интерфейсом в glibc — никакими оптимизациями и не пахнет, ибо они попросту невозможны.
Т.к. никаких опровержений моих слов не последовало — я вынужден констатировать слив.
Не понял.
Зачем вообще нужен нестандартный конструктор копирования для того же вектора(любого контейнера)? Правильно — для раии.
Что?! Где?! Когда?!
В строках. Раиишная строка не может в си-строку, не может в подстроку. string_view — пример вменяемой строки, которую не смогли сделать раиишной и не вводили 20лет только из-за раии.
Это так же отвечает на все твои вопросы связанные с мув-семантикой. Почему у string_view её нет? Правильно — она нахрен не нужна, ибо не раии.
Исходники стандартной библиотеки, которые поствляются с гэцэцэ и шлангом, открыты для чтения круглосуточно.
Милости просим.
Ну из этого ничего, кроме «слышу звон, да не знаю где он» вывести нельзя.
Давай сравним твои попытки это описать:
В современных реализациях стандартной библиотеки короткие строки хранятся прямо внутри указателя. То есть память не выделяется в куче, а скопировать такую строку — всё равно, что скопировать целое число.
И реальность:
Вместо(поверх) капасити + локальный кеш. Скопировать такую строку всё равно, что скопировать строку.
На остальное, как я понял — тебе ответить нечем? Я даже не удивлён.
Сразу забылось и раии и все остальное, ну бывает.
Ламерок опять продемонстрировал свою никчёмность. Одни сливы, никаких внятных аргументов — «не способен» — почему? На основании чего я «выгляжу как неудачник»? На эти вопросы нет ответов, да и не будет.
А судя по тому, что днище даже мою ошибку не заметило — ну дело такое. https://godbolt.org/g/pgLZR3
И? У тебя-то не используется значение указателя — значение используется для копирования памяти.
Строка пишется в char[], читается из char[] — указатель там форфан и ничего не делает. У меня же функция возвращает именно значение.
От каких слова я отказываюсь? Поподробней.
В целом потуги амёбки ясны — пытается что-то там мне балаболить, ловить, сама понимает что это бесполезно, но на что-то надеется.
Всё началось с десятках разных предметов — разрослось до пары десятков, но в конечном итоге всё слилось к нулю, ибо по каждому балаболка обделалась. А дальше пошел игнор, «школьник» и прочее.
Когда ответить нечего и обделался — жуй. Ты бы хоть попытался ответить за свою брехню, на которой тебя поймали.
Ну что я могу сказать — для обделавшегося постоянное заострении внимания на том, что от кого-то воняет — типичная потуга.
Те, кто обладают хоть каким-то развитием могут.
От кого?
Совсем балаболка сломалась. Ну ничего — бывает. Там было все объяснено — я могу повторять это бесконечно и ты будешь врать, врать, в надежде, что мне когда-то надоест(хотя нет — достаточно хомячкам тыкать -1 и через неделю будет 1 пост в неделю, чего собственно слившиеся и добиваются).
Показал. Хотя опять же — ситуация аналогичной той, что выше. Если тебе нечего возразить — этого уже достаточно для определения тебя как слившегося. С таким же успехом я могу говорить «показал» — дальше что?
Причём тут где хранится — хранится представление значение и там всё это описано. Как ламерок слился с «в указатели» на «в памяти», ну бывает.
Нет, ламерюжка. Память не обладает формой. Переменная — это форма. Память хранит представление перменной. Твой код пишет в память, но не в указатель. По факту получается, что строка хранится в памяти. В указатель пишется значение.
Мои примеры иллитны и идеальны. В любом случае что бы ты не пытался из себя строить перед пацанами — сильнейший уже определился.
Ну что я могу сказать — ламерок, который не знает ни языка о котором кукарекает, ни разбирается в том самом программировании о котором кукарекал(вернее обвинял меня). Если ты настолько тупой, что не можешь собрать хелворд — ну дак это твои проблемы.
«научителамеркавкод»_to_pointer (); — вот так.
http://cpp.sh/9pd4
Я написал причины — игноришь я могу начать не позволять тебе этого делать. Хочешь чтобы я продолжил с тобою играть — веди себя вменяемо.
Вера тут притом, что принятие аргумента «все не могут ошибаться» — есть вера, т.к. в ином случае это не аргумент.
По факту маршрутка то же востребована, только это не значит, что это вменяемое средство передвижения. Ширпотреб и дерьмо всегда востребованы — только из этого ничего не следует, ну кроме того факта, что дерьмо востребовано.
О боже, что же вы все такие тупые. У неё нет альтернативы — естественно её используют. Толку говорить о каком-то выборе, если выбора нет? В крестах изначально раии-контейнеры определялись как полноценные, поэтому не вводили никаких не-раишных контейнеров — сейчас введением вменяемых «контейнеров» она косвенно согласились с неполноценностью раии. Но у ламерков уже есть оправдание — string_view — это для тех, кто не осилил мув-семантику. Уровень некомпетентности рядового крестового балабола меня просто поражает.
Пример с авто — пример банальной жертвы левого звона — авто — это значение по умолчанию, естественно его никто не использовал не потому, что оно «не популярно, не нужно» — оно не имеет смысла. Авто просто наследие си, в котором авто то же наследие.
Пошли сливы. Не понял — идиот. Нашел ошибку в моей формулировке, либо можешь доказать, что не понял не по причине своей некомпетентности, а из-за меня? Валяй. Но хоть и поплыл — я пожалею убого и объясню.
Изначально контекст был «не забыть об оптимизации», далее автор коммента продолжил его «стл оптимизированная — ко-ко-ко». И в этом контексте все утверждения озвучивались. Сейчас ты, как и любой ламерок, пытаешься съехать на «автоматическое управление ресурсами удобно для низкоквалифицированной силы, либо для быстрой разработки дерьма», но контекст был не в этом. Давай ещё проще, контекст был в ориентации на ТТХ конечного продукта, а не на простоту разработки, её дешевизну, доступность кадров и прочее.
При этом говорилось о строках как примере той структуры, где раии не состоятельна и объяснялось почему.
Опять ты, амёбка, мне пытаешься врать и юлить. Если там чушь — докажи и покажи где, а так своим высером ты можешь только подтереться.
Опять же — вранье. Не дал — докажи, не нашел — докажи, что его нет. Нахрен ты мне врёшь? Повторюсь ещё раз — если ты не разбираешься в теме — зачем ты споришь?
Меня не волнуют твои взывания к ООП и прочим мантрам, заклинаниям. Я тебе описал альтернативную концепцию, которая оптимальней и проще.
Есть что возразить — валяй, а нет зачем ты мне пишешь «твоя альтернативная концепция не соответствует моей концепции» — естественно, на то она и альтернативная.
Опять эти глупые потуги. Ты реально думаешь, что ссылаясь на свои обезьяньи поверья ты сможешь меня поймать? Читая мне мантру про ООП — думаешь, если она в твоём стаде популярно — её не покрыть? Такая глупая и наивная балаболка.
Я уже говорил — твои потуги могут производить(хотя куда там производить — ретранслировать) логику уровня «насекомое» и в стае подобных тебе ты можешь крыть других насекомых, но проблема в том, что как бы ты не пытался меня двигать — это невозможно по определению.
Давай я тебе покажу почему твои потуги тщетны.Изначально нигде не говорилось о том, что что-то должно быть ООП(ну в твоём понимании его — ты ведь не объяснишь почему моя концепция не ООП, но это такое). Говорилось о разработки на результирующие качество кода с т.з. ТТХ. Далее утверждалось, что текущие стл итак максимально «быстр», но я объяснил и показал почему это не так. Из этого косвенно следует, что стл максимально быстр для той концепции, которую он реализует, а значит сама концепция является не годно в контексте «оптимизации».
Поэтому никакие потуги тебя не спасут, в любом случае ты сольёшься.
На этом, если я тебя спрошу «на чём» — ты обделаешься, поэтому что-то кукарекать не советую. Да и куда тебе продолжать, ты уже понимаешь что попытка твоя провалилась.
О боже, днище. Почему ты такое глупое — тебе уже показали. Структуры обладают своей памятью, т.е. любое определение чего-то в структуре использует память структуры.
http://ideone.com/MBD86P
Собери(попытайся) вменямым компилятором это сам — так помойка на ideone не может в мой код.
Интерфейс просмотра содержимого — это указатель. Брехня номер один.
Далее, sring_view — это такое же представление си-строки, как и string с той разницей, что sring_view не владеет этой самой си-строкой(т.е. данными).
Общее у них всё. Может const string и string — то же концептуально разные? Обладает теми же ограничениями, что и sring_view. В целом ты забрехался.
В конечном итоге выходит так, что string интерфейс с владением, как и все «контейнеры» в стл. Владение им нужно только для раии.
Все интерфейсы для просмотра(те же итераторы) имеют доступ на модификацию — т.е. модификация того, чем владеет контейнер может происходить вне его интерфейса.
sring_view вписывается сюда полностью, но ro он только по причине того, что у пацанов случилось раии.
Если ты думаешь, что у меня бомбануло — это твоя проблема. Мой обычный стиль куда более агрессивен чем то, что ты видел. А то, что я тебя жалею и даю возможность юлить, а так же веду дискуссии с тем, кто не обладает нужно квалификации для их ведения — это не является моей обязанностью, а является жестом доброй воли.
Я тебе уже объяснил. Прочитай в словаре значения слова «значение» и научись отличать содержимое от пространства. В содержимом — это в содержимом, а в пространстве — это в пространстве. Я тебе уже приводил пример с мочёй и банкой — способен думать — думай, а не способен — нахрен я тебе распинаюсь? Я там выше это то же разобрал.
Ты должен уже научится понимать что такое структура и объект. А далее тебе будет понятно — где хранится строка — правильно в памяти объекта.
Структура — это пространство в той банке. Банка саморасширяется. Добавляя туда 8кубиков мочи — ты расширил банку — она(её объём) стала 8кубиков. Моча — это значение пространства в банке. Моча — указатель. В указателе — значит в моче.
Далее всё просто — это пространство можно использовать под 8печенек, но они будут в пространстве банки, т.е. в банки, т.е. в структуре/юнионе, а не в заполнителе(значении) — моче. Понимаешь?
Там написано, что в один момент времени может быть активно только одно поле — у тебя активно 2.
Потуги ламерков меня не волнуют — есть что возразить — пытайся.
Да, завязано. Хотя мне уже надоела что-то пытаться объяснить ламеркам. Принцип ООП — это построение конечных объектов из набора объектов. И аллокатор это такая же часть объекта, как и не аллокатор.
О боже, убогое днище. Зачем ты мне это пишешь? Я где-то разве писал, что нельзя? Я там писал про интансы аллокатора, хотя опять же — сходи в словарь я не обязан каждый раз ламерку что-то объяснять.
Эта концепция напоминает любой стиль, просто вы этого не понимаете. Просто вам встретились знакомые ключевые слова из представления функций/классов.
Алгоритмы — это операции над данными, при этом данные представляются в виде обобщенного инстерфейса доступа(который данными не владает).
Итераторы — интерфейсы доступа. string_view — интерфейс доступа. Адаптеры — интерфейсы поступа. И «контейнеры» должны быть интерфейсами доступа.
Но с этим проблема — универсального представления данных нет и нам надо было бы городить 10разных хранилищ данных. По этой причине и родился этот больной симбиоз.
А это данные отдельно — это некстген, авось когда-то в крестах до этого допрут, как допёрли до string_view — хотя это и заняло 20лет. И получается — у тебя множество аллокаторов — нужна строка с кешом? Взял буфер с кешом, указал размер кеша — вкатил его в строку — идельно. Далее авось осилятся инстансы аллокатора. Это ООП, а то что у тебя — кастыли
Во-первых, уже после 5-го класса дети не верят в аргумент «все не могут ошибаться». Зачем ты мне его выкатываешь?
Во-вторых, говорилось о нестоятельности раии в контексте строк, копирования и прочего в контексте производительности. Что там у тебя и как используется — меня мало волнует.
Ответ был, но опять пошли потуги врать.
И далее по тексту всё разжевано.
Меня не волнуют твои взывания к ООП и прочим мантрам, заклинаниям. Я тебе описал альтернативную концепцию, которая оптимальней и проще. Есть что возразить — валяй, а нет зачем ты мне пишешь «твоя альтернативная концепция не соответствует моей концепции» — естественно, на то она и альтернативная.
Подожди, а string_view — это не объект? Зачем его впилили? Наверное за тем, что аришная строка показала свою полную несостоятельность?
Копия интерфейса — это копия интефрейса. Копия данных — это копия данных. Почему вдруг у тебя интерфейсы-итераторы не владеют объектами, стримы не владеют объектами — как же так?
Это типичные дыры в представлении, но ты как рядовой верующий это пытаешься как-то оправдать. У нас есть объект — это данные(в данном случае строка) + интерфейс доступа к ним и операции над ними. Но ведь суть stl — это разделение данных и операций. У нас есть итераторы, которые такие же интерфейсы в данным. У нас есть алгоритмы, которые так же интерфейсы к операциям над даннымы и у нас есть строка, которая то же интерфейс к данным.
Получается, что строка по логике вещей должна быть чем-то навроде итератора в к данным и такое понятие есть в стл — адаптер. Но опять же из-за того, что раии пришлось кастылять смесь адаптеров и данных.
Меня не волнуют эти потуги и эти заклинания. Я не собирают ограничивать себя чьими-либо догмами и прочем. Но опять же, даже тут ты сбрехал и наврал.
Тебе никто не заставляет давать прямой доступ к данным — у тебя есть объект membuf, либо ещё что-то и на него уже натягиваются всякие интерфейсы. Нужна строка? Вот тебе строка. Нужна раишная строка? Вот тебе строка раиишная. Такой подход сейчас в тех же указателях — есть память, а указатель с владенеим и без. Тут то же самое.
В логике си и С++. Любая «память» является не-копируемой. Память сама по себе, кроме случаев, когда она является частью объекта(массивы в тех же структурах). Но опять же — они не копируемые — копируемые сами объекты.
А в часть самой строки почему она не может?
Слив засчитан. Предназначение идентично. Является частью одной библиотеки, но интегрирован только в одну строну — string_view — интегрирует в обе. Твоя вера и оправдания смешны.
И какой же там другой функционал, какие такие другие требование, какое-такое предназначение? Отвечай, а не балаболь.
И опять пошли сливы. Опять пошел юлёж. Ты мне в указателе покажи, а не в том же куске памяти. И да, это уб, но ты продолжнай игнорить.
Опять же где тут «в указателе» — я не вижу. Ладно, давай специально для ламерков я поясню.
Вот в указателе, а то, что у тебя «не в указателе».
О боже, почитай в словаре значение слова «значение», а потом научись отличать «в жопе» и «вместо жопы"/«по месту жопы». Давай ещё раз ссанина может быть в банке, вместо воды, но никак не в вводе. Ты вылили воду из банки — налил ссанину и говоришь — «ну вот ссанина в воде» — нет, ссанина не вводе — она вместо воды.
Попытки с «указателем» — являются такими же манипуляциями и враньём, ибо говорилось «в указателе», но потом понятие поменялось и стало «в массиве в юнионе», что можно трактовать как «вместо указателя», но никак не в. При этом трактовать это ошибкой в формулировке не получится, что «копируется как число» — т.е. подразумевалось именно представление строки в числе(указателе).
Далее, опять же — все как-то забыли про «копируется как число», чего нигде нет.
В конечном итоге буфер замещает некоторые поля(копасити + хвост в гцц, а в шланге все 3поля), копирование происходит так же.
При этом ещё не следует забывать, что это пессимизация того же доступа по индексу, доступа вообще, но это такое. В гцц кстати об этом подумали, а шланг — такой шланг.
Но не сказал почему( и проигнорировал этот вопрос) — вывод — балабол.
Во-первых дёрганье из контекста. Во-вторых — что же ты спастил одно, а не спастил другое? Ладно, ты вроде вменяемый и реально тут не понимаешь, а не юлишь как твои собратья.
Не верно — строка является интерфейсом к данным. Когда мы копируем интерфейс — мы копируем интерфейс. Даже если применить твоё понимание — нам нужна в строке идентичная информация, а не сам факт копирования.
Указатель — это интерфейс. Строка — это интерфейс. А данные — это данные. От копии строки нам надо только то, чтобы мы могли получить те данные, что хранились там до копирования.
Т.е. строки не обязательно должны чем-то владеть, они могут владеть одним и тем же(тот же ков).
Далее, во вменямых концепциях интерфейс доступа к данным и сами данные разделены. Они разделены на уровне си, который есть основа крестов. Есть данные — это массивы, хип и прочее, а есть объекты — это структуры, базовые типы и прочее. По этой причине данные в си/крестах не-копируемые, объекты и базовые типы копируемые. Память копируется отдельными средствами.
В логике языка, если объект не наследует память — он ею не владеет. При этом по логике здравой интерфейс доступа никакого отношения к тому, к чему у него есть и владеть этим чем-то не должен. В реальности же строки и владеет только интерфейсом, поэтому всё владение памятью — это заморочки раии. Т.е. риии не даёт взять кусок строки, не даёт сделать копию интерфейса — копия интерфейса делается через кастыль «мув-семантику». В крестах через 20лет до этого допрёли — молодцы, только это ничего не меняет.
И вменяемая концепция выглядит так: есть память, а есть интерфейс. Интерфейс отдельно — память отдельно. Это даёт возможность без убогих кастылей использовать разную память, что сейчас невозможно. Интерфейс копируется как интерфейс. Память копируется как память. Хочешь копию строки? Создай копию памяти и отдай её интерфейсу.
И это абсолютно логично, т.к. в подавляющем большинстве нам нужна копия интерфейса.
В конечном итоге что мы имеем — невозможность сделать копию интерфейса — это проблема крестовой строки, которая вызвана раии(т.к. она должна им владеть) — для этого собственно и сделали интерфейс без владения. Из этого всего следует, что копирование только интерфейса не теребует никакой мув-семантики, а все «оптимизации» которые принесла мув-семантика являются ничем иным, как костылём для копирования интерфейса.
О боже — это не другой инструмент — это часть strings library, такая же, как и сам класс string. А в часть самой строки почему она не может?
А возвращать «другой инструмент» она может? А брать часть себя она может?
Я там не вижу чтобы что-то хранилось в «указателе».
О боже, и как же работает юнион? И да, причём тут юнион, если ты хранишь в указателе? Дак и храни в указателе, а не в юнионе.
Я не придираюсь к херне. Будет — в юнионе.
Говорилось именно про шланг и гцц. Опять же — враньё, вернее попытка игнорировать факт «копируется как число», вот шланг:
const_pointer __get_short_pointer() const _NOEXCEPT
{return pointer_traits<const_pointer>::pointer_to(__r_.first().__s.__data_[0]);}
В гцц анологично. Копируется как строка.
Потуги с «указателем» — являются такими же манипуляциями и враньём, ибо говорилось «в указателе», но потом понятие поменялось и стало «в массиве в юнионе», что можно трактовать как «вместо указателя».
По поводу как хранится — в шланге там паскаль строка поверх всех полей, а в гцц я уже говорил.
Опять попёрло враньё. Я жду либо ответа на:
Изначальный посыл был:
Ответ на это был на «о производительности забыли»:
При этом нигде в изначально посте об STL(как только о контейнерах) не говорилось, а примеры были из не из аlgorithms/сontainers library, а из strings/io, но автор изначального комментария начал говорит об стл. На основании этого я могу обобщить stl по любой из списках библиотек, а не только аlgorithms/сontainers.
Не говорил. Я сказал:
Т.е. утверждая это я под этим имел ввиду только ОПТИМИЗИРОВАННУЮ часть стл, в которую аlgorithms/сontainers не входят(а их части являются такой же обёрткой, ну которые реально оптимизированы). Я это спокойно могу вывести и у тебя не найдётся ничего, чем ты сможешь мне возразить. Поэтому я не советую играться со мною, пытаться меня поймать — это глупая и непосильная задача для текущих моих оппонентов.
Враньё. Я такого не говорил.
Было сказано, что в посте в целом речь шла обо всём и в частности об аlgorithms/сontainers library. Ты спастил кусок и пытается врать, игнорируя сей факт.
Так мило. И в чём же конкретно.
Враньё.
Где же тут «операции конверсии строк в числа»? Я жажду их увидеть.
Где же тут ТОЛЬКО «операции конверсии строк в числа»? Я жажду их увидеть.
Далее, разносить так разносить:
Стандарт определяет strings library как:
Где компоненты есть:
В которых null-terminated-операции есть либц, string class есть обёртка над character traits, а character traits я уже выкатил.
Хорошо, ладно — оставим балабольства и сливы выше. Значит всё обёртки, но при этом «STL» оптимизирована? Либо оптимизирована либц? Надо уж определиться в показаниях.
Попытки юлить такие пытки. Я уже не раз говорил подобным тебе, играться в следователей, ловить, иметь возможность что-то противопоставить — это всё работает только в вашем окружении, т.к. вы собираетесь +-1% от среднего уровня развития сообщества и вам начинает казаться, что вы действительно что-то можете — это не так. Глупо искать брешь в моей логике т.к. она совершенно иного уровня. Вместо пустых попыток ко вранью лучше бы попытался провести внятный анализ моего поста и оспорить его. Я даже тебе растолкую много непонятных слов/кода и понятий.
Хотя потом тебя точно так же будут минусовать, но за всё надо платить.
Скучно. Качество аудитории активных спорщиков тут действительно никакое. Зря я решил что-то написать.
Почему же? Т.е. мне говорить нельзя, а вам можно? Л — логика.
И действительно:
О боже, ну если не понимаете о чём речь — зачем лезть? Речь идёт о том, что строка должна владеть строкой, т.е. строка не может содержать в себе си-строку, только её копию. Это исходит и из контекста string_view, и из «часть строки» — хотя зачем я это пишу.
Я уже выше отвечал на этот вопрос, но похоже вам нужно только болтать.
Я там не вижу чтобы что-то хранилось в «указателе». По ссылке уб. Про реальные имплементации стл я уже писал:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/basic_string.h#L120
Все операции идентичны и копирование то же.
Враньё. Речь шла обо всём, а тот факт, что я обобщил stl до всей libc++ — это не моё допущение, а автора комментария.
>>Во-первых, что же там такое в этих строках libstdc++ используется из glibc, что вы их называете «не более, чем генерик-интерфейсом к glibc»?
Строка определяется операциями, из которых все(которые пахнут оптимизацией) являются обёртками над string/mem/io из либц.
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/char_traits.h#L231
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/basic_string.h#L5409
Нет, в прочем игнор показателен. Я объяснил почему и от чего взялись стримы/строки в стл — вы это написали автору оригинального коммента? Ведь нет?
Как же я люблю это враньё. Я там выкатил не только изобличение вашей мотивации, но и по теме стл — т.е. контейнеров и алгоритмов. Это было проигнорировано, чего и следовало ожидать — т.к. коммент написан был не с целью разобраться/объяснить etc, а с целью поймать, что явно не удалось. И не удастся по банальным причинам объективной силы.
По поводу лозунгов — ты мои мне не предоставишь — я даже спрашивать не буду, а вот лозунги моего оппонента я представлю: «Не осилил» — типичное оправдание и аргумент против любого несогласного с линией партии. «Всё оптимизировано — всё идеально» — такой же типичный лозунг, который оправдывает любые претензии к качеству кода у популярных. Это два основных посыла.
А дальше пошли банальные мифы: «мув-семантика для оптимизации» — при этом утверждающий это не понимает зачем она нужна и почему, т.е. просто ретранслирует рядовые поверья. «в указателе строка лежит, а копировать её не так» — при этом утверждающий ничего не представляет о том, о чём говорит и просто ретранслирует тот звон, который он где-то услышал. «сопрограммы» — при этом утверждающий ничего в них не понимает, не понимает почему и зачем они нужны и что пытаются сделать те, кто их вводит и зачем. «шаблоны для быстроты», но опять же когда дело доходит до реальности — все почему-то сливаются.
Утверждающий попытался защитить миф про мув-семантику — не смог. Попытался защитить свой звон — не смог.
Ну зачем же так откровенно врать.
Это не важно, ибо в основном посте говорилось о строках и стримах, автор того поста отвечал говоря об стл — есть претензии — выкатывайте их ему, а не мне. Я интерпретирую стл как libc++ — претензии не ко мне.
Я там так же описывал и контейнеры(алгоритмы и описывать не стоит — их реализация во всех стл никакая) вместе с тем почему это так. Я описал фатальный недостаток всего стл — никакой аллокатор. Фатальный недостаток вектора — отсутствие реаллока. Фатальный недостаток всех спископодобных структур(это списки, деревья) — это опять же убогий аллокатор. Фатальный недостаток хешмапа — это невероятный оверхед по памяти.
Так же у всего стл есть фатальный недостаток — это метадизайн + обобщенные реализации. Я рассказывал почему они не состоятельны на примере попыток его оптимизации, а все эти попытки были ни что иное — как выпиливание любого обобщения.
Так же я пояснил и по поводу интерфейса приведя в пример мертворожденный valarray. Любые оптимизации интерфейса и структур данных, унификации алгоритмов над ними не приживаются в «современном С++», ибо оптимизация там не нужна — все о ней кричат, но не более того.
Повторюсь ещё раз, в статье говорилось об строках/стримах все претензии к автору поста на который я отвечал. Далее, я отвечал на «оптимизированный по гланды стл», а то, что ты описываешь не является оптимизированной частью стл. Ну и даже про неё я написал, а все твои придирки не более, чем враньё и попытки поймать меня, что является заведомо тщетным.
-std=gnu++1z -march=native -O3 $ ./clang3.8 fread 91.3046 91.3087 fread w sbuffer 90.9951 91.1043 fread w lbuffer 91.3046 91.2016 read2 69.7235 69.6309 mmap 149.131 149.874 fancy mmap 149.964 149.343 mmap (shared) 149.964 149.843 fancy mmap (shared) 149.964 149.951 Cpp 95.1899 95.3484 $ ./clang3.8 //-stdlib=libc++ fread 90.3823 90.274 fread w sbuffer 90.3823 90.5862 fread w lbuffer 90.3823 90.4556 read2 67.1089 67.0633 mmap 148.307 148.442 fancy mmap 149.131 148.514 mmap (shared) 148.307 148.627 fancy mmap (shared) 149.131 148.941 Cpp 11.0741 11.069 $ ./gcc61 fread 139.086 138.678 fread w sbuffer 136.957 137.351 fread w lbuffer 137.659 137.376 read2 70.0876 70.2154 mmap 163.68 163.623 fancy mmap 163.68 163.275 mmap (shared) 162.688 162.45 fancy mmap (shared) 161.708 162.297 Cpp 100.162 100.115Сливает фриду. Цифры ммап смотреть не имеет смысла, ибо бенчмарк упирается в убогую реализацию doSomeComputation(). В реальности же ммап быстрее на порядок.
Ответ на:
Т.к. никаких опровержений моих слов не последовало — я вынужден констатировать слив.
Зачем вообще нужен нестандартный конструктор копирования для того же вектора(любого контейнера)? Правильно — для раии.
В строках. Раиишная строка не может в си-строку, не может в подстроку. string_view — пример вменяемой строки, которую не смогли сделать раиишной и не вводили 20лет только из-за раии.
Это так же отвечает на все твои вопросы связанные с мув-семантикой. Почему у string_view её нет? Правильно — она нахрен не нужна, ибо не раии.
Ну из этого ничего, кроме «слышу звон, да не знаю где он» вывести нельзя.
Давай сравним твои попытки это описать:
И реальность:
Вместо(поверх) капасити + локальный кеш. Скопировать такую строку всё равно, что скопировать строку.
На остальное, как я понял — тебе ответить нечем? Я даже не удивлён.