Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.116.35.5] |
|
Страницы: (32) « Первая ... 29 30 [31] 32 ( Перейти к последнему сообщению ) |
Сообщ.
#451
,
|
|
|
Нет не так, там ещё + конструктор по-умолчанию, move-конструктор и деструктор Цитата KILLER @ Я как понял вы обсуждаете как НЕ POD скопировать или переместить в другое место с помощью memcpy/memmove ? Как выделять память в массиве при помощи realloc |
Сообщ.
#452
,
|
|
|
Цитата Олег М @ Нет не так, там ещё + конструктор по-умолчанию, move-конструктор и деструктор + еще конструктор копирования и операторы копирования и перемещения. И в итоге все эти конструкторы работают по твоей схеме. Деструктор вызывается автоматически уничтожает память, конструкторы копирования/перемещения вызываются соответственно пир копировании/перемещении объектов. Если тупо в конструкторах и деструкторах написать то, что ты в своей схеме написал, то при обычной операции присваивание получим ровно такую схему, которую ты описал. Разве нет? Добавлено Цитата Олег М @ Как выделять память в массиве при помощи realloc Хм, а я думал OpenGL на пост FlexFerrum отвечал |
Сообщ.
#453
,
|
|
|
Цитата Олег М @ Нет не так, там ещё + конструктор по-умолчанию, move-конструктор и деструктор Ты уж определись: либо move-конструктор, либо конструктор по-умолчанию + move/copy-оператор =. Ибо при использовании move-конструктора умолчательная инициализация объекта-приёмника не требуется. Цитата KILLER @ И в итоге все эти конструкторы работают по твоей схеме. Ему хочется bulk-операций. Типа сразу взял, скопировал (то есть, эммм, смувал) один кусок памяти с кучей объектов в другой, а исходный при этом дропнул. Добавлено Цитата Олег М @ Как выделять память в массиве при помощи realloc Нету в stl-аллокаторах операции realloc. |
Сообщ.
#454
,
|
|
|
Цитата Flex Ferrum @ Ему хочется bulk-операций. Типа сразу взял, скопировал (то есть, эммм, смувал) один кусок памяти с кучей объектов в другой, а исходный при этом дропнул. И этого тоже. Хотя realloc хочется больше. |
Сообщ.
#455
,
|
|
|
Цитата Олег М @ И этого тоже. Хотя realloc хочется больше. Так realloc - это и есть bluk-операция "три в одном" - выделяет новую память, копирует в неё старую и старую удаляет. Или не выделяет/освобождает, а добавляет к старой кусок новой памяти, если есть возможность. Но это - C-style. |
Сообщ.
#456
,
|
|
|
Цитата Flex Ferrum @ Или не выделяет/освобождает, а добавляет к старой кусок новой памяти, если есть возможность. Но это - C-style. Здесь вроде вопрос и был - взять хорошие вещи из Си и использовать их в С++ |
Сообщ.
#457
,
|
|
|
Цитата Олег М @ Цитата Flex Ferrum @ Или не выделяет/освобождает, а добавляет к старой кусок новой памяти, если есть возможность. Но это - C-style. Здесь вроде вопрос и был - взять хорошие вещи из Си и использовать их в С++ В данном случае это - неподходящая вещь для "импорта". В C++ и так достаточно error-prone-механизмов. Зачем увеличивать их количество? |
Сообщ.
#458
,
|
|
|
Цитата Олег М @ Конкретно realoc() перенести в какой-нибудь operator renew() нельзя. Ровно по той причине, почему в Плюсах вообще появились new/delete на замену malloc()/free(). В C всё было тривиально, в Плюсах в общем случае всё нетривиально. Массив некоего размера по определению имеет объекты по всем валидным индексам, чего невозможно добиться, не сконструировав каждый их них. И как бы и ладно, проблемы с производительностью не такой уж серьёзный аргумент. Беда же в том, что управление памятью и управление объектами, занимающими эту память – это две абсолютно разные задачи. Попробуйте себе представить перегрузку renew, например, и поймёте, почему в процессе становления C++98 далеко не сразу у delete[] пропал аргумент между []. Здесь вроде вопрос и был - взять хорошие вещи из Си и использовать их в С++ |
Сообщ.
#459
,
|
|
|
Цитата Flex Ferrum @ В C++ и так достаточно error-prone-механизмов. Зачем увеличивать их количество? Почему бы и нет? Выгода вполне ощутима, недостатки весьма условны. Большинство сишников (которых я встречал), за это и не любят С++, что думают, что кровь-из-носу, а надо использовать std::string вместо const char *, vector, вместо массива и т.д. и т.п. Подозреваю, сейчас читают этот форум и думают - какое ж гавно этот с++, даже realloc нельзя использоовать. |
Сообщ.
#460
,
|
|
|
Цитата Олег М @ Цитата Flex Ferrum @ В C++ и так достаточно error-prone-механизмов. Зачем увеличивать их количество? Почему бы и нет? Выгода вполне ощутима, недостатки весьма условны. Большинство сишников (которых я встречал), за это и не любят С++, что думают, что кровь-из-носу, а надо использовать std::string вместо const char *, vector, вместо массива и т.д. и т.п. Подозреваю, сейчас читают этот форум и думают - какое ж гавно этот с++, даже realloc нельзя использоовать. Потому что язык должен помогать писать хорошие (качественные) программы, и мешать писать плохие, а не провоцировать писать с ошибками. В конце концов, если хочется такого рода оптимизациями - можно посмотреть в сторону пастерна flyweight. Ибо бенефиты от предлагаемых трюков могут вполне обернуться выходными с отладчиком просто из-за того, что сменилась версия какой-нибудь библиотеки или, банально, режим сборки/опции компиляции. Вот кому оно надо? |
Сообщ.
#461
,
|
|
|
Цитата Flex Ferrum @ Потому что язык должен помогать писать хорошие (качественные) программы, и мешать писать плохие, Тут наверное лучше сказать - не должен мешать писать хорошие программы. А то помогать и мешать любой вонючий скрипт неплохо умеет. |
Сообщ.
#462
,
|
|
|
[OFF]Всю тему засрали пустопорожним трёпом на своим птичьем языком [/OFF]
|
Сообщ.
#463
,
|
|
|
Цитата Исмаил Прокопенко @ Всю тему засрали пустопорожним трёпом на своим птичьем языком Почему пустопорожним? Как раз по теме. |
Сообщ.
#464
,
|
|
|
Цитата Олег М @ Как раз по теме. Вы видимо название темы не читали |
Сообщ.
#465
,
|
|
|
Цитата Исмаил Прокопенко @ Ну сортир для того и создан, чтобы в него срать. Всю тему засрали пустопорожним трёпом на своим птичьем языком |