Здравствуйте, PM, Вы писали:
PM>Здравствуйте, Sm0ke, Вы писали:
S>>В варианте мне не хватает способа обратиться к значению без проверок. S>>get<some_type>(var) делает проверку и кидает исключение в случае чего. S>>Нужен ещё get_unsafe<>() хз как его лучше назвать. На случай когда я точно знаю что за тип хранится в варике.
PM>Вообще-то есть https://en.cppreference.com/w/cpp/utility/variant/get_if
If pv is not a null pointer and pv->index() == I
Следовательно оно внутри проверяет состояние. Это оверхед, когда index уже известен.
upd: Да он ещё и указатель проверяет ...
Здравствуйте, Sm0ke, Вы писали:
S>Есть же std::span
Не всем ещё доступен C++20.
S>В варианте мне не хватает способа обратиться к значению без проверок.
Согласен, но для меня это проблемы не составляет.
S>get<some_type>(var) делает проверку и кидает исключение в случае чего. S>Нужен ещё get_unsafe<>() хз как его лучше назвать. На случай когда я точно знаю что за тип хранится в варике.
Добавить get<T>() как член класса.
Здравствуйте, T4r4sB, Вы писали:
BFE>> В основном в векторах лежат smart_ptr'ы и unique_ptr'ы, а их тоже нельзя, согласно стандарту и согласно логике, побитово копировать. TB>Их тоже можно, никаких проблем.
Раз есть приватная часть класса, то, если мне не изменяет память, согласно стандарту — нельзя.
BFE>>вот тут пример кода похожего на настоящий. Я не помню зачем тогда он мне понадобился и — да, пришлось прописать конструкторы. TB>Мув-конструктор?
Здравствуйте, B0FEE664, Вы писали:
BFE>Раз есть приватная часть класса, то, если мне не изменяет память, согласно стандарту — нельзя.
Я не про "по стандарту", а "по факту". Любой реально полезный класс по факту можно. Кроме тех, где есть указатель на буфер, хранящийся внутри него же, и такие классы обычно вообще запрещают перемещать.
BFE>Да. А что?
Ну, крайне редкий случай, я считаю, который очень легко обходится.
Здравствуйте, T4r4sB, Вы писали:
BFE>>Раз есть приватная часть класса, то, если мне не изменяет память, согласно стандарту — нельзя. TB>Я не про "по стандарту", а "по факту". Любой реально полезный класс по факту можно. Кроме тех, где есть указатель на буфер, хранящийся внутри него же, и такие классы обычно вообще запрещают перемещать.
"По факту" массивы (контейнеры) вообще не нужны, достаточно массивов указателей. Но тогда это не C++.
BFE>>Да. А что? TB>Ну, крайне редкий случай, я считаю, который очень легко обходится.
Нет, крайне редкий случай, это когда объект хранит в себе все указатели на себя и меняет их при своём перемещении.
Здравствуйте, T4r4sB, Вы писали:
BFE>>"По факту" массивы (контейнеры) вообще не нужны, достаточно массивов указателей. Но тогда это не C++. TB>Это вообще к чему?
К тому, что в С++ один объект может указывать внутрь другого объекта. Если бы было иначе, то можно было бы очень сильно поменять работу с указателями, но это был бы уже не C++.
BFE>>Нет, крайне редкий случай, это когда объект хранит в себе все указатели на себя и меняет их при своём перемещении. TB>Да. Поэтому вектор может тупо побитово копировать содержимое в resize, не нужна эта вся пляска с мув-конструкторами.
Нет, редкие ситуации тоже должны нормально отрабатывать.
А если вам не надо как в векторе, то напишите свой контейнер — никто не запрещает же.
Здравствуйте, B0FEE664, Вы писали:
BFE>К тому, что в С++ один объект может указывать внутрь другого объекта.
Это не проблема. Юники, строки, вектора — указывают, и что? Их спокойно можно побитово копировать внутре vector::resize
А если ты имеешь ссылки на элемент вектора в каком-то левом объекте — то ну ты сам понимаешь же что так нельзя?
BFE>Если бы было иначе, то можно было бы очень сильно поменять работу с указателями, но это был бы уже не C++.
Да, это был бы более быстрый и оптимальный язык, который бы мог юник в регистре передавать. Но С++ же снова "не платит за то чего не использует".
BFE>Нет, редкие ситуации тоже должны нормально отрабатывать. BFE>А если вам не надо как в векторе, то напишите свой контейнер — никто не запрещает же.
Это редкие ситуации мне и большинству коллег не встречались никогда.
Здравствуйте, T4r4sB, Вы писали:
BFE>>К тому, что в С++ один объект может указывать внутрь другого объекта. TB>Это не проблема. Юники, строки, вектора — указывают, и что? Их спокойно можно побитово копировать внутре vector::resize TB>А если ты имеешь ссылки на элемент вектора в каком-то левом объекте — то ну ты сам понимаешь же что так нельзя?
Почему в "левом" объекте? Вот итератор по вектору — объект совсем не левый, но он после resize станет невалидным. Можно ли написать итератор, что останется валидным после resize? Это запросто, но такой итератор будет медленнее.
BFE>>Если бы было иначе, то можно было бы очень сильно поменять работу с указателями, но это был бы уже не C++. TB>Да, это был бы более быстрый и оптимальный язык, который бы мог юник в регистре передавать. Но С++ же снова "не платит за то чего не использует".
Если бы нельзя было указывать внутрь объекта, то язык был бы медленнее, так как нельзя было бы написать быстрые итераторы.
BFE>>Нет, редкие ситуации тоже должны нормально отрабатывать. BFE>>А если вам не надо как в векторе, то напишите свой контейнер — никто не запрещает же. TB>Это редкие ситуации мне и большинству коллег не встречались никогда.
Да ладно! Никогда не хранили дерево в векторе?
Здравствуйте, B0FEE664, Вы писали:
BFE>Почему в "левом" объекте? Вот итератор по вектору — объект совсем не левый, но он после resize станет невалидным. Можно ли написать итератор, что останется валидным после resize? Это запросто, но такой итератор будет медленнее.
Ну значит не надо использовать такой итератор, а это к чему?
BFE>Если бы нельзя было указывать внутрь объекта, то язык был бы медленнее, так как нельзя было бы написать быстрые итераторы.
Чего? Я вообще не понял, ты про что? Как "ссылки внутрь объекта" мешают побитово копировать объект в vector::resize, при условии, что правила использования итераторов и ссылок такие же, как сейчас?
BFE>Да ладно! Никогда не хранили дерево в векторе?
Не хранил, но даже если б и хранил, то какая разница? Ты будешь называть новые названия стандартных классов? Их все можно побитово копировать, старайся дальше. Ну кроме изначально немувабельных.
Здравствуйте, T4r4sB, Вы писали:
TB> Как "ссылки внутрь объекта" мешают побитово копировать объект в vector::resize, при условии, что правила использования итераторов и ссылок такие же, как сейчас?
Мешают потерей общности: либо вектор не универсальный, либо итераторы медленные.
BFE>>Да ладно! Никогда не хранили дерево в векторе? TB>Не хранил, но даже если б и хранил, то какая разница?
Не у всех сложных задач есть простые решения. Если вы не сталкивались с некоторыми типами задач, то это не значит. что другие с ними не сталкивались.
TB>Ты будешь называть новые названия стандартных классов? Их все можно побитово копировать, старайся дальше. Ну кроме изначально немувабельных.
Я встречал программистов, которые не используют шаблоны, и таких программистов, которые не могут понять косвенной адресации, есть такие программисты, что не понимают концепцию виртуального метода, а есть такие, что не используют итераторов. И всё это программисты, которые годами работают на С++ и успешно решают поставленные перед ними задачи. Существуют такие, что даже не могут освоить C++, Torvalds Linux тому пример.
Во многом поэтому все стандартные объекты проектируются структурно простыми. Изначально вектор (как и строка) не обязаны были лежать в памяти одним куском, поэтому можно было написать вектор с быстрым добавлением и удалением элементов, так как не надо было перемещать все эти элементы при вставке нового, но под давлением всей этой массы вектор хранящий непрерывный кусок памяти был стандартизирован столь нелепым способом. (А ведь можно было добавить, скажем, метод align(), но...) И вы мне предлагаете вот из этого набора элементарных структур назвать такие, что нельзя скопировать побитно? Серьёзно? Повторюсь: если вам не надо как в векторе, то напишите свой контейнер — никто не запрещает же. Только вот не надо упрощать то, что и так уже простое.
Здравствуйте, B0FEE664, Вы писали:
BFE>Мешают потерей общности: либо вектор не универсальный, либо итераторы медленные.
Вектор не универсален, да.
А причём тут побитовое копирование объектов?
BFE>>>Да ладно! Никогда не хранили дерево в векторе? TB>>Не хранил, но даже если б и хранил, то какая разница? BFE>Не у всех сложных задач есть простые решения. Если вы не сталкивались с некоторыми типами задач, то это не значит. что другие с ними не сталкивались.
Не уходи от ответа, про какие проблемы побитового копирования дерева ты мне пытаешься рассказать?
BFE>Бла-бла-бла
К чему это всё? О_о
BFE> И вы мне предлагаете вот из этого набора элементарных структур назвать такие, что нельзя скопировать побитно?
Да, я это и пытаюсь от тебя добиться. Какие же? Кроме изначально принципиально неперемещаемых.
Назови такие. Без лирических отступлений, мне это нафиг не надо.
Нет таких в стандартных.
Вектор просто переусложнён на пустом месте.
А глупые крестовики продолжают верить, что они не платят за то, чего не используют)
Здравствуйте, Максим, Вы писали:
М>Можно в теории проверять во время компиляции есть ли у оператора перемещения директива noexcept и если есть, то делать move, а иначе копировать. Но выглядит как-то сложновато.
Здравствуйте, T4r4sB, Вы писали:
TB>Самое дикое, что для всех когда-либо реально используемых мной классов достаточно тупо побитового копирования с удалением старого блока без вызова деструкторов. С++ переусложняет ситуацию на ровном месте
Ты предлагаешь этот подход использовать только при реаллокации вектора, или в принципе, везде, где по идее должна выполняться операция перемещения?
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, T4r4sB, Вы писали:
TB>Ты реально таким штукам прописываешь мув-конструктор и потом хранишь их в векторе без посредников? Или просто стараешься не гонять по памяти? Типа хранить в юнике на крайнях и всё такое.
Какая разница, что он реально прописывает. Ссылки и указатели в объектах, направленные внутрь самих себя, не запрещены и время от времени попадаются в коде, плохо это или хорошо. Ты предлагаешь запретить эту возможность, или что?
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
R>Ты предлагаешь этот подход использовать только при реаллокации вектора, или в принципе, везде, где по идее должна выполняться операция перемещения?
Везде, где можно гарантировать, что старый объект не будет доступен.
Здравствуйте, rg45, Вы писали:
R>Какая разница, что он реально прописывает. Ссылки и указатели в объектах, направленные внутрь самих себя, не запрещены и время от времени попадаются в коде, плохо это или хорошо. Ты предлагаешь запретить эту возможность, или что?
Я предлагаю запретить эту возможность в перемещаемых объектах. Мне вот ни разу не понадобилась за всё время. Если у меня и делается самоссылка, то объект сидит в юнике или шареде.
Здравствуйте, T4r4sB, Вы писали:
TB>Я предлагаю запретить эту возможность в перемещаемых объектах. Мне вот ни разу не понадобилась за всё время. Если у меня и делается самоссылка, то объект сидит в юнике или шареде.
Как должен/может выглядеть этот запрет? Прямо в стандарте языка это прописать?
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, T4r4sB, Вы писали:
TB>Везде, где можно гарантировать, что старый объект не будет доступен.
А как это можно гарантировать? Как минимум, он всегда будет доступен для разработчика, который выполняет операцию перемещения и для того, кто будет этот код сопровождать.
И второй вопрос: а что с текущей концепцией перемещения — перемещающие конструкторы, операторы присваивания, rvalue ссылки и пр. — что-то из этого остается или все упраздняется?
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
R>Как должен/может выглядеть этот запрет? Прямо в стандарте языка это прописать?
Сказать, что если объект имеет право быть перемещён при возврате из функции или при реаллокации вектора. И если объект содержит ссылки на себя, то это УБ.
