Развейте мои сомнения: упростится ли программирование при переходе от C к C++?

Цитата Flex Ferrum @ 20.03.17, 13:07

Ваш JavaScript - тоже та ещё травка.

Это ты его в прежние времена еще не застал

Цитата Flex Ferrum @ 20.03.17, 13:04

В С++ есть отличный способ указать компилятору и библиотеке на то, что структуру можно безопасно копипастить из одного куска памяти в другой. Это сделать такую структуру POD-структурой. И этим способом можно (и нужно) пользоваться для всех "частных случаев". В остальных случаях - copy/move-конструкторы. И это правильно.

А std::string можно так пометить, или типа того?

Цитата Олег М @ 20.03.17, 13:12

А std::string можно так пометить, или типа того?

Нет, конечно. И копипастить его нельзя.

Цитата Flex Ferrum @ 20.03.17, 13:14

И копипастить его нельзя

Почему?

Цитата Олег М @ 20.03.17, 13:15

Почему?

Потому что он не POD тип.

Добавлено 20.03.17, 13:17
Простая структура данных

Цитата Олег М @ 20.03.17, 13:15

Почему?

Потому. Если у типа есть нетривиальные конструкторы копии/перемещения, а также нетривиальный деструктор, то значит, что такое "особое поведение" было необходимо разработчику типа. Что ты будешь делать со "старой" копией объекта после копипаста? Откуда знаешь, что копипаст для внутренней структуры объекта вообще допустим и объект такой копипаст переживёт? Если хочется безопасного перемещения содержимого от одного объекта к другому - есть move-операции. Если хочется ходить по минному полю UB - ну да, можно попробовать копипастить.

Цитата Flex Ferrum @ 20.03.17, 13:20

Потому. Если у типа есть нетривиальные конструкторы копии/перемещения, а также нетривиальный деструктор, то значит, что такое "особое поведение" было необходимо разработчику типа. Что ты будешь делать со "старой" копией объекта после копипаста?

Ты переводишь в общий случай. В данный момент это возможно или нет?
Для старой памяти – просто сделать free и все

Добавлено 20.03.17, 13:27

Цитата KILLER @ 20.03.17, 13:17

Потому что он не POD тип.

Сразу вспомнился фильм "Люди в черном"

Цитата Олег М @ 20.03.17, 13:23

Ты переводишь в общий случай. В данный момент это возможно или нет?

Нет, потому что класс std::string не является тривиальным.

По идее если бы можно было указать компилятору, что можно переместить объект с помощью memmove и забыть старый объект без вызова деструктора, то это вполне могло бы ускорить некоторые операции (в частности, расширение вектора для таких объектов). И строки, вектора и какие-нибудь stl контейнеры вполне такими объектами являются.

Цитата OpenGL @ 20.03.17, 13:34

По идее если бы можно было указать компилятору, что можно переместить объект с помощью memmove и забыть старый объект без вызова деструктора, то это вполне мого бы ускорить некоторые операции (в частности, расширение вектора для таких объектов). И строки, вектора и какие-нибудь stl контейнеры вполне такими объектами являются.

Компилятор это и сам определить может: http://en.cppreference.com/w/cpp/types/is_trivially_copyable

Цитата Flex Ferrum @ 20.03.17, 13:38

Компилятор это и сам определить может: http://en.cppreference.com/w/cpp/types/is_trivially_copyable

Это не то Допустим, есть строка. Внутри у неё есть указатель на её начало и длина. Если мы выполняем std::move для неё, то мы в новой строке задаём поля из старой, а в старой их обнуляем. Но в этом случае деструктор старой строки уже ничего не будет делать, а новая является, фактически, её побитовой копией. Соответственно, вместо явного вызова std::move и декструктора старого объекта тут достаточно будет простого memmove с забыванием старого.

Добавлено 20.03.17, 13:49
В частности, все примеры по твоей ссылке являются такими вот is_opengl_movable

Цитата OpenGL @ 20.03.17, 13:46

Это не то Допустим, есть строка. Внутри у неё есть указатель на её начало и длина. Если мы выполняем std::move для неё, то мы в новой строке задаём поля из старой, а в старой их обнуляем. Но в этом случае деструктор старой строки уже ничего не будет делать, а новая является, фактически, её побитовой копией. Соответственно, вместо явного вызова std::move и декструктора старого объекта тут достаточно будет простого memmove с забыванием старого.

Я вот об этом же и пытаюсь сказать.
К тому же realloc, по-любому должен быстрее отрабатывать и экономичнее, когда можно просто увеличить размер блока

Цитата OpenGL @ 20.03.17, 13:46

Если мы выполняем std::move для неё, то мы в новой строке задаём поля из старой, а в старой их обнуляем. Но в этом случае деструктор старой строки уже ничего не будет делать, а новая является, фактически, её побитовой копией.

Ниче не понял. Ну обнулил ты, память от этого не удалится ведь? В итоге ты просто обнулил указатель в старой строке, но от этого ведь память не очистится автоматически. В итоге ты получил утечку памяти. Или я не так понял?
Плюс чтоб в новую строку переместить старую с помощью memmove, для нее, для новой нужно выделить память, кто это сделает?

Сообщение отредактировано: KILLER - 20.03.17, 14:30

Цитата KILLER @ 20.03.17, 14:29

Ниче не понял. Ну обнулил ты, память от этого не удалится ведь? В итоге ты просто обнулил указатель в старой строке, но от этого ведь память не очистится автоматически. В итоге ты получил утечку памяти. Или я не так понял?

Грубая схема:

Выделил память #1, при помощи malloc
Вызвал для неё конструктор
Выделил память #2, malloc
Сделал memcpy из #1 в #2
Сделал free для #1
.....
Вызвал деструктор для #2
Сделал free для #2

Цитата Олег М @ 20.03.17, 14:36

Грубая схема:

Выделил память #1, при помощи malloc
Вызвал для неё конструктор
Выделил память #2, malloc
Сделал memcpy из #1 в #2
Сделал free для #1
.....
Вызвал деструктор для #2
Сделал free для #2

Ну а сейчас не так разве все работает? Я как понял вы обсуждаете как НЕ POD скопировать или переместить в другое место с помощью memcpy/memmove ?