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

[Олег М]

Цитата OpenGL @ 18.03.17, 09:21

Выделяется память, создаётся элемент в нужном месте, перемещаются или копируются элементы из старого массива, вызываются деструкторы, освобождается память. Как-то так.

Какой–то тяжеловатый реаллок получается. Неужели он так и работает? Я почему–то думал, что он просто бинарные данные копирует.

[D_KEY]

Цитата Олег М @ 19.03.17, 09:10

Цитата OpenGL @ 18.03.17, 09:21

Выделяется память, создаётся элемент в нужном месте, перемещаются или копируются элементы из старого массива, вызываются деструкторы, освобождается память. Как-то так.

Какой–то тяжеловатый реаллок получается. Неужели он так и работает? Я почему–то думал, что он просто бинарные данные копирует.

Как ты собрался копируя бинарные данные обеспечить корректность работы объектов?

Добавлено 19.03.17, 09:44
В случае, если у тебя noexcept конструкторы перемещения, то он сможет сделать перемещение, а не копирование.

[Qraizer]

Цитата JoeUser @ 19.03.17, 07:01

И, тем не менее, помогать компилятору помогать тебе контролировать тебе свои типы - нехорошая черта (типизированного) языка.

Скажем так: для чего применять этот принцип, это уже неважно. Вот такая строчка:

extern int static_check[(INT_MAX+INT_MIN == -1)*2-1];

вполне себе заменяет static_assert в младших Стандартах, но при этом объявления массивов с константным выражением в качестве его длины никакого отношения к контролю инвариантов не имеют.
SFINAE в первую очередь позволяет писать обобщённый код, как и перегрузка позволяет статические мультиметоды. Выкинь вон ту "SFINAE"-вую фичу из перегрузки, и она станет совершенно бесполезной вещью. Классы тоже предназначены для ООП, а используются для ООП дай бог чтоб в половине случаев.

[Олег М]

Цитата D_KEY @ 19.03.17, 09:41

Как ты собрался копируя бинарные данные обеспечить корректность работы объектов?

В большинстве случаев не вижу проблем

[D_KEY]

Цитата Олег М @ 19.03.17, 12:52

Цитата D_KEY @ 19.03.17, 09:41

Как ты собрался копируя бинарные данные обеспечить корректность работы объектов?

В большинстве случаев не вижу проблем

Как бы ты реализовал переаллокацию для вектора? Сделаешь побитовое копирование? И как ты будешь определять, сломаешь ли ты клиенту его объекты или нет?

Добавлено 19.03.17, 13:05
Да и вообще, побитово копировать объекты, для которых пользователь задал конструктор копирования/переноса как-то странно, тебе не кажется?

[Олег М]

Цитата D_KEY @ 19.03.17, 13:04

Как бы ты реализовал переаллокацию для вектора? Сделаешь побитовое копирование? И как ты будешь определять, сломаешь ли ты клиенту его объекты или нет?

Добавлено Вчера, 15:05
Да и вообще, побитово копировать объекты, для которых пользователь задал конструктор копирования/переноса как-то странно, тебе не кажется?

Ну да, с std::vector ситуация оказалась совсем тяжёлая, в gcc. При каждом выходе за capacity, он выделяет новый массив, с другим адресом, и переносит туда все объекты. Причём предпочтительно использует конструктор копирования.

Добавлено 20.03.17, 06:22
Почему, в общем-то понятно, но ни разу не радует

[applegame]

Цитата Олег М @ 20.03.17, 06:19

Ну да, с std::vector ситуация оказалась совсем тяжёлая, в gcc. При каждом выходе за capacity, он выделяет новый массив, с другим адресом, и переносит туда все объекты. Причём предпочтительно использует конструктор копирования.
Почему, в общем-то понятно, но ни разу не радует

А что есть мысли как сделать по-другому? Простой memcpy можно использовать для тривиальных POD-ов, и современные компиляторы достаточно умны, чтобы такие данные перебрасывать простым бинарным копированием.
И вообще это стандартная реализация и она отлично работает. Capacity при реаллокации рассчитывается с запасом, так что даже при непрерывном росте массива, количество реаллокаций будет расти логарифмически. А если заранее известен размер, то можно сразу удлинить массив до необходимого размера.

[Олег М]

Цитата applegame @ 20.03.17, 07:34

А что есть мысли как сделать по-другому? Простой memcpy можно использовать для тривиальных POD-ов, и современные компиляторы достаточно умны, чтобы такие данные перебрасывать простым бинарным копированием.
И вообще это стандартная реализация и она отлично работает. Capacity при реаллокации рассчитывается с запасом, так что даже при непрерывном росте массива, количество реаллокаций будет расти логарифмически. А если заранее известен размер, то можно сразу удлинить массив до необходимого размера.

Мысль такая - многие классы можно переносить при помощи простого memcpy, ничего это этого не изменится. Соответственно, память под массив можно смело выделять при помощи realloc.

[D_KEY]

Цитата Олег М @ 20.03.17, 07:42

Мысль такая - многие классы можно переносить при помощи простого memcpy, ничего это этого не изменится.

А многие нельзя переносить. Как определить, когда можно, а когда нет?
Задавать политику переноса/копирования извне?

Добавлено 20.03.17, 08:43

Цитата Олег М @ 20.03.17, 07:42

Соответственно, память под массив можно смело выделять при помощи realloc.

Тут нужно измерять, стоит ли оно того. Вполне может оказаться, что реальный прирост производительности невелик.

Добавлено 20.03.17, 08:46

Цитата Олег М @ 20.03.17, 06:19

При каждом выходе за capacity, он выделяет новый массив, с другим адресом, и переносит туда все объекты.

Да, но capasity увеличивается не на один элемент

Цитата

Причём предпочтительно использует конструктор копирования.

Хм. Должен вызывать перемещение, если это возможно (т.е. если у элемента noexcept конструктор перемещения).

[Олег М]

Цитата D_KEY @ 20.03.17, 08:42

А многие нельзя переносить. Как определить, когда можно, а когда нет?
Задавать политику переноса/копирования извне?

Никак не определять. Использовать в частных случаях

Цитата D_KEY @ 20.03.17, 08:42

Тут нужно измерять, стоит ли оно того. Вполне может оказаться, что реальный прирост производительности невелик.

Выглядит так, что если для массива std::string не будут каждый вызываться конструкторы копирования, то работать должно быстрее.
std::vector и базовые типы, похоже по-одному копирует

Добавлено 20.03.17, 08:49

Цитата D_KEY @ 20.03.17, 08:42

Хм. Должен вызывать перемещение, если это возможно (т.е. если у элемента noexcept конструктор перемещения).

Быстрее было бы вызвать конструктор по-умолчанию, потом move-конструктор. Но нет, вызывается конструктор копирования.

[Flex Ferrum]

Цитата Олег М @ 20.03.17, 08:48

Выглядит так, что если для массива std::string не будут каждый вызываться конструкторы копирования, то работать должно быстрее.
std::vector и базовые типы, похоже по-одному копирует

Ты всерьёз считаешь, что std::string можно копировать побитово? Нет, серьёзно?

[D_KEY]

Цитата Олег М @ 20.03.17, 08:48

Цитата D_KEY @ 20.03.17, 08:42

Хм. Должен вызывать перемещение, если это возможно (т.е. если у элемента noexcept конструктор перемещения).

Быстрее было бы вызвать конструктор по-умолчанию, потом move-конструктор.

Зачем конструктор по умолчанию вызывать?

Цитата

Но нет, вызывается конструктор копирования.

Или ты не так используешь или баг в компиляторе.

Сообщение отредактировано: D_KEY - 20.03.17, 08:54

[Flex Ferrum]

Цитата Олег М @ 20.03.17, 08:48

Быстрее было бы вызвать конструктор по-умолчанию, потом move-конструктор. Но нет, вызывается конструктор копирования.

Ни разу не быстрее. Конструктор по-умолчанию инициализирует поля дефолтными значениями (или тем, что задал программист). А конструктор перемещения - сразу тем, что было в "старом" объекте. В итоге - вместо двух инициализаций - одна. Почувствуй разницу.

[D_KEY]

http://ideone.com/KY478v

[Олег М]

Цитата Flex Ferrum @ 20.03.17, 08:54

Ни разу не быстрее. Конструктор по-умолчанию инициализирует поля дефолтными значениями (или тем, что задал программист). А конструктор перемещения - сразу тем, что было в "старом" объекте. В итоге - вместо двух инициализаций - одна. Почувствуй разницу.

Против копирования, думаю, разница будет ощутимая

Добавлено 20.03.17, 09:00

Цитата D_KEY @ 20.03.17, 08:59

http://ideone.com/KY478v

Какой компилятор?

Сообщение отредактировано: Олег М - 20.03.17, 09:00