C++ негодования тред - std::string

Копирование. Сейчас пока так и делаю

Без копирования - только пилить свое (пока). Вариантов - тысячи, некоторые уже предложили.

А откуда у тебя большой char *? Используй сразу std::string. В Си-функции можно передавать &str[0] теперь безопасно. В C++11 std::string обязан хранить память линейно. В крайнем случае используй std::pair<std::unique_ptr<char[]>, size_t sz>.

Инициализироваться из char * без копирования - плохая идея для класса в духе std::string.

А откуда у тебя большой char *?

Из mmap(..., fd, ...)

Как я понял, причина в итератора. Реализовать их сложнее?

А как ты это реализуешь? Там есть такое требование:

std::string test("test");
std::string zero_cost_copy(test); // Данные не дублируются (копируются), а разделяются с первой строкой.
auto iter = zero_cost_copy.begin(); // Сохраняем итератор.
zero_cost_copy[1] = 'o'; // WTF?
*iter; // БДЫЩ!

А итератор взял и магически начал ссылаться на копию с изменениями

А почему бы благородному дону не бахнуть по файлу из numpy?

http://docs.scipy.org/doc/numpy/reference/generated/numpy.load.html пишуть, что он и mmap-ит, и dataview-ит, то, что доктор прописал.

А итератор взял и магически начал ссылаться на копию с изменениями

И тогда на лоре появится тема «хочу зеро-кост итераторы». Ну и подозреваю (искать лень), что текущий стандарт это запрещает тем или иным образом.

о, нифига себе, специалист в треде, всем слушать и выполнять!

std::string уже давно умеет в CoW. Move-семантика, опять же. Ну, или шабонами, епта.

const string&

QString

В треде есть мнение что уже разумел ибо не по стандарту и стреляет в ногу

Что пишешь хоть, что так принципиальна скорость копирования строки?

В итоге мы или копируем и «нарушаем стандарт» или отказывается от COW.

В итоге для этого итератор должен стать сложным и фактически хранить ссылку на std::string, и выполнять operator[]. Стоит ли оно того, не знаю.

СУБД для учебных целей

Так всё же, как передать в std::string const char* без копирования?

Или, правильнее, const std::string.

В Си-функции можно передавать &str[0] теперь безопасно. В C++11 std::string обязан хранить память линейно

технически, оно всегда и было безопасно. ты видел хоть одну версию STL, в которой был нелинейный буфер в std::string?

Можно посмотреть на boost::interprocess::basic_string Или где он там. В общем, на бустовую реализацию строк в разделяемой памяти.

Нет, не видел. Но стандарт этого не требовал(можно было юзать std::vector<char>).

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

Я понял почему такая фича в std::string «не нужна»

И почему же? (я не троллю, правда интересно услышать соображения на тему, а тред читать лень)

У нас говнокода в проекте полно, но чтобы в std::string лазили таким образом ни разу не видел. Как такое вообще может пройти ревью?

Как такое вообще может пройти ревью?

а какая объективная причина может помешать этому пройти ревью, кроме нарушения пункта стандарта, который не встречается в природе?

(тем более, что выше заметили, что в новом стандарте все чики-пуки)

Просто потому что string владеет буфером внутри и освобождает память потом.

Ну допустим мы введем галочку «dont_delete». Ок, хоть и уродство. А что будет когда мы будем записывать? COW? Хотел бы я посмотреть на лицо программиста, когда при изменении символа в строке приложение упадет по нехватке памяти.

Не делать COW и прописывать насквозь в изначальный буфер? Нужно будет поддерживать одновременно такие string_view, в которые read only и никогда не пишут, и такие какие могут. Слишком много вопросов. А сейчас например string фантастически дуракоустойчив

спасибо за поддержку.

код под NDA?

можешь потом показать готовый код класса для твоего велосипеда?

(чтобы мы его коллективно скопипастали)

Саму строку что-ли, или весь велик? Не, это домашняя штука, может когда-то и выброшу. Но реально проект учебный

строку и пример использования. А то срач на две страницы, а что в конце получилось, чем сердце успокоилось - непонятно)

Я ее в последнюю очередь буду пилить, почти все готовое напишу на обычных строках, а потом заменю в узких местах. Как там говорилось о преждевременной эякуляции? Premature optimization is a root of all evil

Вообще-то: Premature ejaculation is a root of all evil.
Да и в целом такие треды показывают больше некомпетентность постующий, чем раскрывают истинные решения. Ви батенька-таки провокатор.

Это тоже был вопрос :)

Оно не умеет дешево создаться на основе существующего char* без копирования.

А что из std::string тебе нужно вызывать, что оно настолько кошерно и нет аналога для char*, что так обеспокоен стоимостью копирования?

А у нас в Development новый stevejobs...

Ну допустим мы введем галочку «dont_delete». Ок, хоть и уродство. А что будет когда мы будем записывать? COW? Хотел бы я посмотреть на лицо программиста, когда при изменении символа в строке приложение упадет по нехватке памяти.

До недавнего времени std::string() поддерживал CoW опционально по стандарту и gcc даже его реализует. Запретили CoW только в c++11. Лишнее выделение памяти не аргумент для плюсовой программы, т.к. они могут случаться (и случаются на практике) постоянно явно или неявно.

Я верю в разные теории заговора, чо не так? У меня к джобсу пометка стоит «шапка из фольги», особенно больше ничем не примечателен

Запретили CoW только в c++11. Лишнее выделение памяти не аргумент для плюсовой программы, т.к. они могут случаться (и случаются на практике) постоянно явно или неявно.

Здесь дело не в лишнем выделении памяти, хотя это тоже аргумент. Для контейнеров декларируются сложности алгоритмов и CoW их нарушает. К примеру operator[] должен отрабатывать за константное время O(1), в случае CoW он может привести к разделению памяти и сложность будет O(n). CoW пытается усидеть на всех стульях, и сохранить семантику и чтобы работало быстренько. Хорошо сделали, что запретили. Хотите CoW - сделайте себе typedef std::shared_ptr<std::string> MyCowString.

Две копейки. Идея mmap текстового файла правильная. Претензии к std::string по поводу работы на существующем буфере справедливы. Задача решается реализацией аллокатора, который ничего не аллоцирует и не удаляет. Пользоваться после этого только константными строками.

Правильный аргумент

typedef std::shared_ptr<std::string> MyCowString

А вот это толстота

Задача решается реализацией аллокатора, который ничего не аллоцирует и не удаляет. Пользоваться после этого только константными строками.

Костыли. Реализация «StringRef» - единственное некостыльное решение.

Тот который из LLVM? Почему ксати? Какие плюсы и минусы?

Для контейнеров декларируются сложности алгоритмов и CoW их нарушает. К примеру operator[] должен отрабатывать за константное время O(1), в случае CoW он может привести к разделению памяти и сложность будет O(n).

Ничего он не нарушает. В стандарте, где он разрешён, нет таких требований к оператору [] у строки. Чукчи не дураки. В общем, запретили это немного из других соображений, хотя связанных с [].

Хотите CoW - сделайте себе typedef std::shared_ptr<std::string> MyCowString.

Это же нифига не CoW

Это же нифига не CoW

А, ну да, точно. Что там у нас в C++11 за CoW smart pointer или самодельный писать?

Тебе надо std::string_view: http://isocpp.org/blog/2013/09/new-paper-n3762-string-view-a-non-owning-refer...

То, что ты хочешь, в С делается передачей в функцию указателя (на произвольное место в буфере), в С++ — итераторов.

в общем случае вообще не обещает, что это будет непрерывный буфер.

В новом стандарте уже обещает для char и wchar_t

А, ну да, точно. Что там у нас в C++11 за CoW smart pointer или самодельный писать?

Очевидно, ничего. Generic CoW сделать нельзя.

Тот который из LLVM? Почему ксати? Какие плюсы и минусы?

Нет, любой. В случае NIH - реализация от Bicycle Corp.

Определенно, С++ это диверсия против здравого смысла.

2014 год, лор 2 дня мусолит как лучше сделать обертку над куском памяти.

Итераторы(!), буст(!), новый стандарт(!).

Да какой-нибудь сисадмин с месячными курсами по С, <string.h> и valgrind'ом наперевес уже решал бы задачу (а возможно уже бы и и решил) а не Проектировал Абстракции

Удачи ТСу, конечно

Ты даже не понял, что обсуждается.