Поскольку строка str находится в состоянии совместного использования, принцип COW заставляет операцию str[0] создать копию общего буфера, чтобы перейти в состояние владения
Автор пишет, что принцип COW заставляет операцию чтения создать буфер.
Почему вы считаете, что операция чтения должна создать копию буфера? )
Я спрашиваю почему операция чтения должна создавать копию? Почему принцип COW заставляет операцию чтения создавать копию? Принцип, понимаете? Не реализация в статье, а принцип. Так написал автор статьи.
И вот ваш комментарий.
Потому что эта операция может использоваться не только для чтения:
Причем тут это? Как это относится к тому что я спрашиваю? Вы ушли не туда. Это просто медицинский факт. Вы цепляетесь за дальнейшую фразу про перегрузку, тогда как именно ваш комментарий уводит разговор в "нитуда". Я надеюсь так вам станет яснее, почему вы не правы.
Вы опять про реализацию, когда говорите слово "аналог". А я вам про концепцию. А именно не создавать лишний раз копию. В паре string+string_view - это делается через использование string_view. В COW это встроенно by-design.
Но вы почему-то вместо этого начали рассказывать, что запись от чтения можно отличить перегрузкой, что чушь.
Вы мне приписали свою интерпретацию. Вот это точно чушь.
Объясняю, когда я говорил о перегрузке, я говорил что это разные подходы, разные перегруженные операторы в разных реализациях. Вы же обсуждали конкретную реализацию COW из статьи. Тогда как я имел ввиду , почему реализация сделана так, что чтение вызывает COW. Так что вам бы уточняющие вопросы научиться задавать, а не додумывать.
Я не написал const char. Я процитировал код из статьи.
Прочитайте еще раз всю ветку.
Я спросил почему чтение вызывает COW? Вы привели пример с записью. Я спросил причем тут запись, если вопрос про чтение и привел код из статьи. Вы вообще куда то в сторону ушли.
P.S.: Если вы имеете ввиду конкретную реализацию из статьи, то мне понятна ваша позиция. Я вопрос задавал, имея ввиду, зачем вообще так сделано.
Давайте я расскажу. Пока COW-строка одна владеет ресурсом, она не отличается от std::string; Когда на один ресурс ссылается несколько COW-строк они являются std::string_view. Когда происходит сам COW процесс, идет ветвление. Строка получившая уникальность становится по сути std::string, остальные остаются std::string_view над прошлой строкой.
Как я уже сказал, концептуально они (COW и пара string+string_view) одно и тоже. Отличие в реализации.
Это не то же самое с точки зрения внутренней реализации. Но то же самое, с точки зрения абстрактных строк. COW логически содержит в себе одновременно и string и string_vew как концепции.
привели к проблемам, которые не смогли решить
Т.е. в юнити не смогли решить. Верно? Вы же пишите так, как будто сама концепция "больна". Поправьте если это не так.
cow это тоже самое, что пара std::string+string_view.
Проблемы есть и там и там, думать и понимать надо и там и там. А отклонили скорее всего, я предполагаю, изза легаси, а не по причине проблем cow. Какой смысл переделывать string на cow, если проще ввести string_view.
Я к тому, что cow ни хуже ни лучше. Это тоже самое, но с другой стороны. А проблемы и косяки и там и там. Тут вопрос удобства применения в конкретном случае. Вы же утверждаете, как я понял, что cow это плохо, а пара string+string_view хорошо. И я для себя хотел бы увидеть подтверждения этому тезису.
Извините за назойливость, но я не вижу проблем в архитектуре COW. Так же я не вижу бага.
1. Заводим строку 1 2. Берем указатель 3. Заводим внутри скопа вторую 4. Если меняем вторую, то это ее указатель станет другим а не первой 5. Читаем из первой 6. Выводим указатель первой, все хорошо, указатель не менялся
Где тут потенциальный баг изза архитектуры COW? Я вот этот момент хочу понять.
P.S.: Если мы получим указатель на строку из std::string, потом поменяем std::string, то будет ровно такая же ошибка, как в примере, что я писал вам в комментарии выше.
Поскольку строка str находится в состоянии совместного использования, принцип COW заставляет операцию str[0] создать копию общего буфера, чтобы перейти в состояние владения
Почему вы считаете, что операция чтения должна создать копию буфера? )
А как вы подходите к ситуации, когда вам нужно создать математические алгоритмы, которые вы еще не делали, но можете сделать, и вам уже нужно оценить сроки и стоимость?
В цитате он буквально пишет про принцип COW. А не про реализацию COW в юинити. И мой вопрос об этом. Внимательно прочитайте.
Автор пишет, что принцип COW заставляет операцию чтения создать буфер.
Я спрашиваю почему операция чтения должна создавать копию? Почему принцип COW заставляет операцию чтения создавать копию? Принцип, понимаете? Не реализация в статье, а принцип. Так написал автор статьи.
И вот ваш комментарий.
Причем тут это? Как это относится к тому что я спрашиваю? Вы ушли не туда. Это просто медицинский факт. Вы цепляетесь за дальнейшую фразу про перегрузку, тогда как именно ваш комментарий уводит разговор в "нитуда". Я надеюсь так вам станет яснее, почему вы не правы.
Вы опять про реализацию, когда говорите слово "аналог". А я вам про концепцию. А именно не создавать лишний раз копию.
В паре string+string_view - это делается через использование string_view. В COW это встроенно by-design.
Вы мне приписали свою интерпретацию. Вот это точно чушь.
Объясняю, когда я говорил о перегрузке, я говорил что это разные подходы, разные перегруженные операторы в разных реализациях. Вы же обсуждали конкретную реализацию COW из статьи. Тогда как я имел ввиду , почему реализация сделана так, что чтение вызывает COW. Так что вам бы уточняющие вопросы научиться задавать, а не додумывать.
Я согласен с тем, что неполно сформулировал мысль. И, конечно, изза этого смысл комментария становится неверным, да.
Мой основной поинт, что в COW-строках нет проблем, а есть проблемы в конкретно этой реализации.
Делать через функу, а не оператор. Т.к. сам по себе в общем виде символ - это не char. У нас же есть к примеру, UTF-8.
Я вам говорю не про std::string, а про пару string+string_view. И без деталей реализации.
Я не написал const char. Я процитировал код из статьи.
Прочитайте еще раз всю ветку.
Я спросил почему чтение вызывает COW?
Вы привели пример с записью.
Я спросил причем тут запись, если вопрос про чтение и привел код из статьи.
Вы вообще куда то в сторону ушли.
P.S.: Если вы имеете ввиду конкретную реализацию из статьи, то мне понятна ваша позиция. Я вопрос задавал, имея ввиду, зачем вообще так сделано.
Так а зачем делать
char& operator[]?Это как раз тот метод, который не надо делать в COW строках.
Давайте я расскажу.
Пока COW-строка одна владеет ресурсом, она не отличается от std::string;
Когда на один ресурс ссылается несколько COW-строк они являются std::string_view. Когда происходит сам COW процесс, идет ветвление. Строка получившая уникальность становится по сути std::string, остальные остаются std::string_view над прошлой строкой.
Как я уже сказал, концептуально они (COW и пара string+string_view) одно и тоже. Отличие в реализации.
Это не то же самое с точки зрения внутренней реализации. Но то же самое, с точки зрения абстрактных строк. COW логически содержит в себе одновременно и string и string_vew как концепции.
Т.е. в юнити не смогли решить. Верно? Вы же пишите так, как будто сама концепция "больна". Поправьте если это не так.
Уверены?
const char first_char = str[0];А зачем вы так делаете? Почему нету const char operator[]?
Тут проблема архитектуры реализации COW в юинити, а не самого COW.
cow это тоже самое, что пара std::string+string_view.
Проблемы есть и там и там, думать и понимать надо и там и там. А отклонили скорее всего, я предполагаю, изза легаси, а не по причине проблем cow. Какой смысл переделывать string на cow, если проще ввести string_view.
Я к тому, что cow ни хуже ни лучше. Это тоже самое, но с другой стороны. А проблемы и косяки и там и там. Тут вопрос удобства применения в конкретном случае. Вы же утверждаете, как я понял, что cow это плохо, а пара string+string_view хорошо. И я для себя хотел бы увидеть подтверждения этому тезису.
Извините за назойливость, но я не вижу проблем в архитектуре COW. Так же я не вижу бага.
1. Заводим строку 1
2. Берем указатель
3. Заводим внутри скопа вторую
4. Если меняем вторую, то это ее указатель станет другим а не первой
5. Читаем из первой
6. Выводим указатель первой, все хорошо, указатель не менялся
Где тут потенциальный баг изза архитектуры COW? Я вот этот момент хочу понять.
P.S.: Если мы получим указатель на строку из std::string, потом поменяем std::string, то будет ровно такая же ошибка, как в примере, что я писал вам в комментарии выше.
Но это очень странная конструкция:
1. Берем указатель на строку
2. Меняем строку
3. Работаем с указателем на строку
Это точно проблема архитектуры, а не программиста?
Но в примере она используется для чтения (это разные перегруженные операторы). И вопрос остается открытым. )
Почему вы считаете, что операция чтения должна создать копию буфера? )
А как вы подходите к ситуации, когда вам нужно создать математические алгоритмы, которые вы еще не делали, но можете сделать, и вам уже нужно оценить сроки и стоимость?
вот текстом )
https://chatgpt.com/share/cd8342d9-df30-47df-ac5a-a41dfc611704
Я не спорю, а объясняю вам ваши когнитивные искажения. Удачи.