Когда выделять память

вот завис в моём понимании этот пункт:

Сообщение от oleg-m1973 в случае динамического выделения памяти. Без которого ты вряд ли сделаешь что-то полезное.

в той же ветке - были даны пояснения

Сообщение от oleg-m1973 В стеке ты не можешь свободно создавать/удалять объекты. Только добавлять в голову и удалять оттуда же. В куче же ты можешь это делать в любой последовательности.

...
когда выделять поток - в принципе поняла,
когда выделять класс - в принципе поняла (чтобы разорвать зависимости)
КОГДА выделять память?.. - всё-таки ещё не всегда очень хочется её выделять, чтобы потом удалять... но даже не в этом суть... а смысл первой цитаты?
поделитесь please опытом кто-нибудь - когда вы выбираете создать объект на стеке, а когда вы выбираете создать объект в куче?. - какие есть предпосылки для вашего выбора?
не хочу потом всё переделывать - а мне всё равно кажется, что на стеке всегда быстрее, а когда и почему лучше куча не знаю... а то ведь могу написать что попало...
логично, что на стеке - определена последрвательность, но ведь при обращении к разным объектам проблем вроде не бывает... имхо... и понятно, что через стек идут параметры функций - так что получается, всё остальное, т.е. вообще всё лучше располагать в куче?
какую проблему можно получить, если всё располагать на стеке? и в каком случае вообще app не запуститься при таком подходе (есть ли такая опасность)?.. есть ли какие-то критерии "must do"? и никак иначе

0

Сообщение от JeyCi а вот как не потерять custom_deleter, оформленный указателем на функцию в shared_ptr - чего не знаю, того не знаю пока... ?

Там ты его никак не потеряешь.

0

Сообщение от JeyCi Unless you need to be able to change the deleter at runtime, I would strongly recommend using a custom deleter type. For example, if use a function pointer for your deleter, sizeof(unique_ptr<T, fptr>) == 2 * sizeof(T*). In other words, half of the bytes of the unique_ptr object are wasted.

Тут написано о том, что при использовании указателя на функцию в качестве Deleter`а приведет к тому, что половина размера вашего unique_ptr будет использована под хранение этого указателя на функцию. Ни о какой "потере" тут речь не идет. И я бы не назвал это неприятностями. Просто это нерационально и все.

0

Сообщение от Avazart в Ultimate++ не получится создавать элементы управления динамически?

я не думаю, что это запрет на использование контейнеров STD в U++ и управлять ими соответствующе... хотя догма U++ "всё завёрнуто в wrappers, что избавляет от беспокойств о памяти" мне импонирует... может, действительно, в std то и не особо завёрнуто всё, а я перепутала с upp... хотя миксовать namespases - не очень comme il faut, мне кажется...
спасибо, что навели резкость в моём сопротивлении использовать динамическую память!
===
Добавлено через 1 минуту

Сообщение от DrOffset Ни о какой "потере" тут речь не идет.

Сообщение от DrOffset half of the bytes of the unique_ptr object are wasted.

а мне подумалось то, что выделила...

0

Сообщение от JeyCi а мне подумалось то, что выделила...

Я так и подумал. Поэтому написал. Но это дословный перевод. Тут имеется в виду, что память будет потрачена впустую (естественно - это образно говоря, потому что указатель хранится же не просто так, он нужен для вызова в деструкторе).

1

Сообщение от JeyCi я не думаю, что это запрет на использование контейнеров STD в U++ и управлять ими соответствующе... хотя догма U++ "всё завёрнуто в wrappers, что избавляет от беспокойств о памяти" мне импонирует... может, действительно, в std то и не особо завёрнуто всё, а я перепутала с upp... хотя миксовать namespases - не очень comme il faut, мне кажется... спасибо, что навели резкость в моём сопротивлении использовать динамическую память!

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

0

Сообщение от JeyCi вот вы и ответили на ваше непонимание, зачем мне это пока сильно не надо

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

Сообщение от JeyCi когда вы выбираете создать объект на стеке, а когда вы выбираете создать объект в куче?. - какие есть предпосылки для вашего выбора?

не имеет отношения к контейнерам ни STL ни вариантам co-STL типа NTL. Дело даже не в том что co-STL - не всегда, прям уж, ко-эстэыль. А в том, что они выделяют в куче, а не на стеке и не могут присутствовать в аргументации поставленного в теме вопроса.
То есть, дело не в том, что ваши реквайрменты к инвайрменту слабы. У вас проблемы с инвайрсментом самих реквайрментов.

0

Сообщение от Avazart Я имел ввиду взять и создать по нажатию кнопки пользователем заданное им количество к примеру кнопок.

тут не только в кнопках дело, а в том, что сами контейнеры ими позиционируются, как NTL в противовес STD-контейнерам...
да и сами указатели у них зашиты... но запрета на использование указателя и динамическое выделение памяти вроде нет - пример new*vec и пример на наследование и ещё полиморфизм тех же контролов - они сами уже наследуют от Ctrl - у которого есть виртуальный деструктор...
поэтому, если например вектор контролов запихнуть в One, который выполняя функции unique_ptr также расширен для того, чтобы быть контейнером (судя по их докам) - то должен сработать по логике этот виртуальный деструктор при выходе из scope'a... имхо
вобщем, надо просто не сопротивляться этой их догме, а воспользоваться имеющимися классами...
p.s.
как и в STD:
от класса можно наследовать, если в нём заложен виртуальный деструктор... но таких вроде немного в std, не знаю есть ли

0

От контейнером STL можно наследоваться, никто не запрещает НО всегда стоит брать в расчет что у них нет виртуального деструктора.

Добавлено через 58 секунд

Сообщение от JeyCi тут не только в кнопках дело, а в том, что сами контейнеры ими позиционируются, как NTL в противовес STD-контейнерам...

Дело в том что как тут без дин. выделения памяти если кол-во не известно заранее?

0

Сообщение от Avazart как тут без дин. выделения памяти если кол-во не известно заранее?

я в их библиотеку не лазила, но, наверно, Add и Add - может сам плюсует size?... ведь сами пишут вариант (по лнку выше)
Добавлено через 1 час 43 минуты
здесь

Q: I am getting compiler errors such as: function 'void *operator new(size_t)' already has a body A: U++ implements its own heap for performance reasons. It should work fine unless your code tries to overload new/delete too

так что, Avazart, я думаю вы правильно мне напомнили об этом нюансе (NTL) U++...

Сообщение от Avazart Дело в том что как тут без дин. выделения памяти если кол-во не известно заранее?

в общем, логично циклом через arrA.Add(new B);, взяв введённое куда-либо число ... - пример отсюда - в том числе о нормальном наследовании...
чисто динамически вряд ли - всё надо оборачивать/оборачивается в свои обёртки, имеющиеся в U++... имхо

0

Сообщение от JeyCi U++ implements its own heap for performance reasons.

Вам как бе и в STL-контейнерах никто не мешает навелосипедить собственный аллокатор. Причем, без проблем с перегрузкой operator new. Нужно ли это делать - вопрос другой. Кто вам сказал что перформанс вашего велосипеда обязательно будет лучше стандартного варианта? И, кстати говоря, какой ценой будет достигнут выигрыш в скорости? К примеру, buddy allocation гарантировано работает за логарифмическое время, но практически гарантировано выбрасывает этак половину памяти на ветер. Алгоритм выделяет память только степенями двойки и крутитесь как хотите.

0

Сообщение от JeyCi мне напомнили об этом нюансе (NTL)

Кстати что за NTL ?

0

Сообщение от Avazart что за NTL ?

Overview of U++ containers - NTL
NTL - STL Comparison
NTL and standard library

0

NTL was created to solve following problems we used to encounter when using STL: Copy-constructible requirements STL requires the elements stored in containers to meet the requirements of copy-constructible and assignable types. This causes two problems: Elements that do not satisfy these requirements cannot be directly stored in STL containers. For many types of elements, including STL containers themselves, copy-constructor and assign operator is a very expensive operation, that is why often they cannot be stored in STL containers effectively. NTL addresses this problem by introducing Vector and Array flavors of containers.

Ну это все вроде давно устарело.

В Qt к примеру тоже свои контейнеры есть, которые как бы были призваны решать проблему с копированиями.

0

NTL (Non standard Template Library) - containers library - U++ Technologies

Unlike STL, which has single copy-constructible and assignable requirement for whole library, NTL makes requirements on per container and even per method basis. This way NTL allows direct storing of any type of elements.

... сравнение скорости NTL и STD (выигрыш 1-го), также примеры Qt и U++ кода - тоже есть на их сайте...
выбор - лишь вопрос предпочтений и личного комфорта

0

Сообщение от JeyCi Overview of U++ containers - NTL

"Each single NTL container template that can store more than one element has random access".
Хм... И как вы представляете себе реализацию random access применительно к содержимому map? Ну, то есть, понятно как - формальная поддержка конструкций вида iterator[100500], при фактическом линейном поиске элемента по индексу. Только что-то это попахивает намеренным введением в заблуждение, путем значимых умолчаний.

1

Сообщение от Renji И как вы представляете себе реализацию random access применительно к содержимому map?

мне не надо их представлять - это уж точно не моя задача... а задача разработчиков этого фреймворка

Сообщение от Renji Ну, то есть, понятно как - формальная поддержка конструкций вида iterator[100500]

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

0

Ну с Qt я видел сравнение, довольно надуманно и притянуто.

0

Сообщение от JeyCi мне не надо их представлять - это уж точно не моя задача... а задача разработчиков этого фреймворка

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

Сообщение от JeyCi странно, что вы представляете то, с чем, видимо, даже не знакомились...

О, я то как раз знакомился и с алгоритмами по которым работают эти контейнеры, и требованиями к random access iterator. Реализовать доступ по индексу за константное время можно ровно в одном случае - если элементы/указатели на них будут лежать в непрерывном массиве. Но при использовании такого массива, у вас добавление элементов в контейнер будет иметь линейную сложность. С другой стороны, формально в требованиях к random access iterator и не написано что там не может быть линейной сложности доступа. А то что для нормальных людей линейная сложность - антоним random access, это уже мелочи жизни эффективного менеджера.

UPD А нет, вру - на cppreference.com для LegacyRandomAccessIterator таки заявлена константная сложность инкремента. Так что даже трюк с "мы же обещали только поддержку квадратных скобок" не прокатит.

1

Сообщение от Renji И как вы представляете себе реализацию random access применительно к содержимому map?

Сообщение от на-на Упала мапа, -Упала на пол! И ветром мапу, -Мапу унесло)

Сообщение от Renji А то что для нормальных людей линейная сложность - антоним random access, это уже мелочи жизни эффективного менеджера. UPD А нет, вру - на cppreference.com для LegacyRandomAccessIterator таки заявлена константная сложность инкремента. Так что даже трюк с "мы же обещали только поддержку квадратных скобок" не прокатит.

Ну мы же все знаем что и доступ константен! Вот этого раpве мало:

Сообщение от http://www.cplusplus.com/reference/iterator/RandomAccessIterator/ Random-access iterators are iterators that can be used to access elements at an arbitrary offset position relative to the element they point to, offering the same functionality as pointers. Random-access iterators are the most complete iterators in terms of functionality. All pointer types are also valid random-access iterators.

?
Оно конечно скромно и непрямо, но сказано, тем не менее, - лицом чёрен и прекрасен!
Аки указатель, то есть. А указатель - меч в деснице разящей ногу! Постоянно постоянен в своём постоянстве.

0

0