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

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

Ну а сейчас не так разве все работает?

Нет не так, там ещё + конструктор по-умолчанию, move-конструктор и деструктор

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

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

Как выделять память в массиве при помощи realloc

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

Нет не так, там ещё + конструктор по-умолчанию, move-конструктор и деструктор

+ еще конструктор копирования и операторы копирования и перемещения.
И в итоге все эти конструкторы работают по твоей схеме. Деструктор вызывается автоматически уничтожает память, конструкторы копирования/перемещения вызываются соответственно пир копировании/перемещении объектов. Если тупо в конструкторах и деструкторах написать то, что ты в своей схеме написал, то при обычной операции присваивание получим ровно такую схему, которую ты описал. Разве нет?

Добавлено 20.03.17, 15:02

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

Как выделять память в массиве при помощи realloc

Хм, а я думал OpenGL на пост FlexFerrum отвечал

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

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

Нет не так, там ещё + конструктор по-умолчанию, move-конструктор и деструктор

Ты уж определись: либо move-конструктор, либо конструктор по-умолчанию + move/copy-оператор =. Ибо при использовании move-конструктора умолчательная инициализация объекта-приёмника не требуется.

Цитата KILLER @ 20.03.17, 15:00

И в итоге все эти конструкторы работают по твоей схеме.

Ему хочется bulk-операций. Типа сразу взял, скопировал (то есть, эммм, смувал) один кусок памяти с кучей объектов в другой, а исходный при этом дропнул.

Добавлено 20.03.17, 15:24

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

Как выделять память в массиве при помощи realloc

Нету в stl-аллокаторах операции realloc.

Цитата Flex Ferrum @ 20.03.17, 15:23

Ему хочется bulk-операций. Типа сразу взял, скопировал (то есть, эммм, смувал) один кусок памяти с кучей объектов в другой, а исходный при этом дропнул.

И этого тоже. Хотя realloc хочется больше.

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

И этого тоже. Хотя realloc хочется больше.

Так realloc - это и есть bluk-операция "три в одном" - выделяет новую память, копирует в неё старую и старую удаляет. Или не выделяет/освобождает, а добавляет к старой кусок новой памяти, если есть возможность. Но это - C-style.

Цитата Flex Ferrum @ 20.03.17, 15:40

Или не выделяет/освобождает, а добавляет к старой кусок новой памяти, если есть возможность. Но это - C-style.

Здесь вроде вопрос и был - взять хорошие вещи из Си и использовать их в С++

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

Цитата Flex Ferrum @ 20.03.17, 15:40

Или не выделяет/освобождает, а добавляет к старой кусок новой памяти, если есть возможность. Но это - C-style.

Здесь вроде вопрос и был - взять хорошие вещи из Си и использовать их в С++

В данном случае это - неподходящая вещь для "импорта". В C++ и так достаточно error-prone-механизмов. Зачем увеличивать их количество?

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

Здесь вроде вопрос и был - взять хорошие вещи из Си и использовать их в С++

Конкретно realoc() перенести в какой-нибудь operator renew() нельзя. Ровно по той причине, почему в Плюсах вообще появились new/delete на замену malloc()/free(). В C всё было тривиально, в Плюсах в общем случае всё нетривиально. Массив некоего размера по определению имеет объекты по всем валидным индексам, чего невозможно добиться, не сконструировав каждый их них. И как бы и ладно, проблемы с производительностью не такой уж серьёзный аргумент. Беда же в том, что управление памятью и управление объектами, занимающими эту память – это две абсолютно разные задачи. Попробуйте себе представить перегрузку renew, например, и поймёте, почему в процессе становления C++98 далеко не сразу у delete[] пропал аргумент между [].

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

В C++ и так достаточно error-prone-механизмов. Зачем увеличивать их количество?

Почему бы и нет? Выгода вполне ощутима, недостатки весьма условны.
Большинство сишников (которых я встречал), за это и не любят С++, что думают, что кровь-из-носу, а надо использовать std::string вместо const char *, vector, вместо массива и т.д. и т.п.
Подозреваю, сейчас читают этот форум и думают - какое ж гавно этот с++, даже realloc нельзя использоовать.

Цитата Олег М @ 20.03.17, 17:01

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

В C++ и так достаточно error-prone-механизмов. Зачем увеличивать их количество?

Почему бы и нет? Выгода вполне ощутима, недостатки весьма условны.
Большинство сишников (которых я встречал), за это и не любят С++, что думают, что кровь-из-носу, а надо использовать std::string вместо const char *, vector, вместо массива и т.д. и т.п.
Подозреваю, сейчас читают этот форум и думают - какое ж гавно этот с++, даже realloc нельзя использоовать.

Потому что язык должен помогать писать хорошие (качественные) программы, и мешать писать плохие, а не провоцировать писать с ошибками. В конце концов, если хочется такого рода оптимизациями - можно посмотреть в сторону пастерна flyweight. Ибо бенефиты от предлагаемых трюков могут вполне обернуться выходными с отладчиком просто из-за того, что сменилась версия какой-нибудь библиотеки или, банально, режим сборки/опции компиляции. Вот кому оно надо?

Цитата Flex Ferrum @ 20.03.17, 17:09

Потому что язык должен помогать писать хорошие (качественные) программы, и мешать писать плохие,

Тут наверное лучше сказать - не должен мешать писать хорошие программы.
А то помогать и мешать любой вонючий скрипт неплохо умеет.

[OFF]Всю тему засрали пустопорожним трёпом на своим птичьем языком [/OFF]

Цитата Исмаил Прокопенко @ 21.03.17, 18:36

Всю тему засрали пустопорожним трёпом на своим птичьем языком

Почему пустопорожним? Как раз по теме.

Цитата Олег М @ 21.03.17, 18:41

Как раз по теме.

Вы видимо название темы не читали

Цитата Исмаил Прокопенко @ 21.03.17, 18:36

Всю тему засрали пустопорожним трёпом на своим птичьем языком

Ну сортир для того и создан, чтобы в него срать.