[C++?] Серьезный вопрос.

>Не нижний уровень инициирует удаление.

На верхнем уровне политика аллокирования памяти в данном конкретном контексте выполнения ни о чем не говорит. Поэтому надо делать на нижнем.

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

>Только верхний уровень знает, когда объект больше не нужен.

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

>Нижний уровень может принимать решения только о том, когда отдавать память системе.

В RT аллокируется фиксированное количество и не отдается.

http://translate.google.ru/translate_t?prev=hp&hl=ru&js=y&text=%D...

:-D

> Сделать виртуальный деутруктор? Тогда придется все наследовать от одного корня.

если нам надо в при освобождении области пула вызывать деструкторы всего, что там хранится, то можно применить стандатный прием оборачивания любого T в Boxed<T> -- при этом конечно все Boxed<T> однокоренные и имеют вирт. деструктор, однако Т однокоренными быть вовсе не обязаны

удивительно, как *часто* это мне приходится на ЛОРе повторять

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

ну и где проблемы?

З.Ы. вообще у меня создается впечатление, что ты пересказываешь случаи, в которых действительно создаются проблемы, *не до конца*, и результате должного эффекта нет, а есть только очевидные решения совсем-не-проблем

>вообще у меня создается впечатление, что ты пересказываешь случаи, в которых действительно создаются проблемы, *не до конца*

Ну, знаешь ли, оппоненты желают *знать* конкретный тип аллокированного объекта чтобы явно вызвать деструктор и даже заявляют что тип всегда один и mutually-exclusive ситуаций когда аллокировано либо одно либо другое никогда не бывает. И при этом хотять использовать ООП-функционал типа множественного виртуального наследования и виртуальных функций который наоборот предназначен для того чтобы *не знать* конкретный тип. Я не понимаю как можно одновременно *знать* и *не знать* какой-либо факт и поэтому не представляю о чем можно дальше говорить.

> и поэтому не представляю о чем можно дальше говорить.

я, ты знаешь, тоже :-)

задачу "вызвать деструкторы неоднокоренных объектов, хранящихся в пуле", насколько я могу судить, боксинг решает

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

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

Вот ты тугой. Третий раз тебе говорю, пулу не надо знать тип объекта. Так-же как не знает о типе объекта free.

Юзается это примерно так (очень упрощённый и некрасивый вариант, только чтоб ты понял идею):

Pool<Node,100500> pool;
//...
const size_t nodes_count = 123;
node nodes[count];
for(size_t i=0;i<count;++i)
{
node * = pool.malloc();
new (node) Node(hello::world, "!", 42, i);
nodes[i] = node;
}
//...
for(size_t i=0;i<count;++i)
{
nodes[i].~Node();
pool.free(nodes[i]);
}

это он понимает.

ему не ясно, как положить в *один и тот же пул* int, std::string и my::Clazz

>ему не ясно, как положить в *один и тот же пул* int, std::string и my::Clazz

Если они сильно разных размеров и живут не по принципу FIFO - то может и не надо?

>LIFO

самопочин. Впрочем с FIFO тоже можно что-то придумать.

> ему не ясно, как положить в *один и тот же пул* int, std::string и my::Clazz

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

>Ему не ясно, что это никому не нужно (и это противоречит самой идее быстрого, простого и предсказуемого пула - тому, что все объекты имеют один размер).

Мне не ясно зачем нужен полиморфизм (ты же писал о множественном виртуальном наследовании объекта в пуле), если все объекты одинакового типа.

> ты же писал о множественном виртуальном наследовании объекта в пуле

Это было сказано к тому, что хранение объекта в пуле не мешает использовать все возможности Си++.

> если все объекты одинакового типа.

В одном пуле - одинакового. Но ты можешь сделать столько пулов, сколько захочешь.

>> ты же писал о множественном виртуальном наследовании объекта в пуле

>Это было сказано к тому, что хранение объекта в пуле не мешает использовать все возможности Си++.

Если я знаю конкретный тип объекта, то полиморфизм уже в пролете. Какие еще возможности есть?

>> если все объекты одинакового типа.

>В одном пуле - одинакового. Но ты можешь сделать столько пулов, сколько захочешь.

А потом пыжиться чтобы влезть в проектный предел на потребление ОЗУ. Это напоминет выпас древнего проекта на Турбо-Паскакале где все массивы были распиханы по фиксированным адресам и пасущий мужик их всех знал наизусть. При том чта за 30 лет написано туча диссертаций по управлению памятью и в RT-среде в том числе.

>> Это было сказано к тому, что хранение объекта в пуле не мешает использовать все возможности Си++.

> Если я знаю конкретный тип объекта, то полиморфизм уже в пролете.

"Израиль Абрамович, когда вы говорите, такое впечатление, что вы бредите" (с)

>> В одном пуле - одинакового. Но ты можешь сделать столько пулов, сколько захочешь.

> А потом пыжиться чтобы влезть в проектный предел на потребление ОЗУ.

Доо. Расскажи мне о возможных проблемах.

> то напоминет выпас древнего проекта на Турбо-Паскакале где все массивы были распиханы по фиксированным адресам

You see people. Dead people.

>> Если я знаю конкретный тип объекта, то полиморфизм уже в пролете.

>"Израиль Абрамович, когда вы говорите, такое впечатление, что вы бредите" (с)

Доо. А мне этот процесс напоминает железные аргументы которые тонут в плюсофильском бреде и виляниях как в желе.

>> А потом пыжиться чтобы влезть в проектный предел на потребление ОЗУ.

>Доо. Расскажи мне о возможных проблемах.

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

>>> Если я знаю конкретный тип объекта, то полиморфизм уже в пролете.

>>"Израиль Абрамович, когда вы говорите, такое впечатление, что вы бредите" (с)

> Доо. А мне этот процесс напоминает железные аргументы

Которые понятны одному тебе :D

> Я могу и на Си и на Асме написать, и даже посчитать цену каждой операции в тактах если надо.

Афигеть.

> Только пользы от плюсов тут - ноль

Для тебя.

>Если я знаю конкретный тип объекта, то полиморфизм уже в пролете.

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

Абсурд, ты зашкаливаешь.

>> Доо. А мне этот процесс напоминает железные аргументы

>Которые понятны одному тебе :D

Не факт, не факт. Я сегодня почитал пару тредов в Usenet и нашел там мысли относитено С++ такие как будто написал их я - о выворачивании плюсами естественных познавательных/когнитивных процессов головного мозга наизнанку, например. Я об этом писал независимо в *этом* треде на примере RTTI - решение которое должно быть в конце прототипирования требуется в начале. Так что одни и те же мысли приходят в голову одновременно и независимо как минимум нескольким людям.

>> Которые понятны одному тебе :D

> Не факт, не факт.Я сегодня почитал пару тредов в Usenet

Аааа держите меня трое!!!!11 Причем треды в Usenet к "полиморфности" и пулам?

> о выворачивании плюсами естественных познавательных/когнитивных процессов головного мозга наизнанку

Какой полет мысли... %)

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

Это не делает их истиной.

Я подозреваю в тебе тяжелое отравление Си++-хайпом. Реклама оказалась лживой, и ты, полностью в духе своего ника, возненавидел язык, а не рекламщиков. "Это печально" (c)

>Я подозреваю в тебе тяжелое отравление Си++-хайпом. Реклама оказалась лживой, и ты, полностью в духе своего ника, возненавидел язык, а не рекламщиков.

Какая нафиг реклама? С++ возник снизу, а не сверху. Рекламировали в основном фреймворки на базе С++ типа ActiveX, Жаву и С#. Надо сказать что жэо все очень неплохие технологии, только в ActiveX доставали тонны бойлерплейта которого было невозможно более-менее приемлемо обернуть [sic] гибкими средствами плюсового метапрограммирования. В ActiveX надо *знать* как устроены эти темплейты, но *делать вид* что ты этого не знаешь, чтобы пытаться писать более-менее прозрачный код. Видимо это глубоко укореняется и убежденные писатели на С++ через некоторое время приобретают умение *знать* и *не знать* одновременно.

>> ему не ясно, как положить в *один и тот же пул* int, std::string и my::Clazz

> Если они сильно разных размеров и живут не по принципу FIFO - то может и не надо?

да, они сильно разных размеров, они живут по FIFO -- в общем, это аналог стэка

и это надо

> Видимо это глубоко укореняется и убежденные писатели на С++ через некоторое время приобретают умение *знать* и *не знать* одновременно.

хватит ерунду нести с закосом под философа

пиши прототип класса

> В одном пуле - одинакового. Но ты можешь сделать столько пулов, сколько захочешь.

И тут вполне возможно реализация одного FIFO пула с объектами разного размера будет быстрее, не говоря уже об экономии памяти.

И на плюсах это делается в полпинка.

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

> Надо сказать что жэо все очень неплохие технологии, только в ActiveX доставали тонны бойлерплейта которого было невозможно более-менее приемлемо обернуть [sic] гибкими средствами плюсового метапрограммирования.

Значит недостаточно гибкие. А действительно гибкие средства типа концептов Страуструп и К. ввести бояцца, ибо такие как ты не поймут.

>> В одном пуле - одинакового. Но ты можешь сделать столько пулов, сколько захочешь.

> И тут вполне возможно реализация одного FIFO пула с объектами разного размера будет быстрее

Афигеть. За счет чего?

> не говоря уже об экономии памяти.

Да неужели? Может, оно и фрагментацию уменьшит?

скорость безвариантно просядет, наверно раза в 2 (см. тесты фибоначчи, кажется у КРоН73, где объекты размещались в пуле)

другое дело, что ЕМНИП время (де)аллокации можно сделать ограниченным константой

> Афигеть. За счет чего?

за счет FIFO

> Да неужели? Может, оно и фрагментацию уменьшит?

и это тоже

____________________________________

FIFO, понятное дело, годится не всегда, но когда оно годится, то сильно полезно. Если так случилось, что ФИФО нас устраивает, то с целью экономии времени и памяти туда надо пихать объекты разного размера и типов. (Речь можно повести о том, как в циклоновский регион запихнуть не POD-объекты, а объекты с деструктором)

>> Афигеть. За счет чего?

> за счет FIFO

Краткий, точный и исчерпывающий ответ. Браво.

>> Да неужели? Может, оно и фрагментацию уменьшит?

>и это тоже

Браво еще раз.

>А действительно гибкие средства типа концептов Страуструп и К. ввести бояцца, ибо такие как ты не поймут.

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

>> за счет FIFO

>Краткий, точный и исчерпывающий ответ. Браво.

Капитан вынужден заметить, что фифошному и лифошнму пулам для выделения памяти достаточно сделать pointer+=sizeof(newobj); а для освобождения pointer-=sizeof(newobj)

>а не добавлять в них возможности

Лично я считаю, что возможность объявить шаблон свободного перегруженного арифметического оператора для целочисленных (например) типов не трогая все остальные типы - новая и весьма полезная.

> Концепты были призваны ограничивать темплейты, накладывая обязательство соответствия контракту у параметрических типов, а не добавлять в них возможности. По крайней мере Александреску это видел так - описать в темплейте то чего с ним делать дельзя.

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

> Капитан вынужден заметить, что фифошному и лифошнму пулам для выделения памяти достаточно сделать pointer+=sizeof(newobj); а для освобождения pointer-=sizeof(newobj)

И каким образом это пул? Это стек/очередь. Они по условию задачи не подходят.

Кстати, у обычного пула (списка квантов) время выделения/удаления тоже фиксированное, так что никакого выигрыша по скорости [LF]IFO не дают.

> В ActiveX надо *знать* как устроены эти темплейты, но *делать вид* что ты этого не знаешь, чтобы пытаться писать более-менее прозрачный код.

Например, нужно знать, как устроена vtbl, но делать вид, что ты этого не знаешь :-)

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

В случае допустим контейнеров я м.б. и согласен с таким подходом -- мы используем свое знание для того, чтобы вспомнить, что эта операция будет О(N), а эта О(1), и не используем для другого.

А вот в случае vtbl -- не согласен. vtbl должна реализовываться таким же классом, как std::bla_bla_bla

А что там с актив-иксом?

> И каким образом это пул? Это стек/очередь. Они по условию задачи не подходят.

У нас условие задачи не описано явно.

Я занимался тем, что расшифровывал притензии Абсурда (mark & release), и насколько к этому применимо слово "pool" -- это второй вопрос.

оно чем-то похоже на пул, если мы не используем повторно место, освободившееся от отдельного объекта (а только от releas-а после mark-a)

> Кстати, у обычного пула (списка квантов) время выделения/удаления тоже фиксированное, так что никакого выигрыша по скорости [LF]IFO не дают.

у ФИФО локальность памяти думаю получше будет, не?

и вообще мне кажется mark это аналог открыть регион, release -- закрыть регион cyclone

> у ФИФО локальность памяти думаю получше будет, не?

Локальность при размещении-освобождении - да, лучше. Но кого это интересует? Ровно никого. Вся остальная локальность от реализации аллокатора не зависит вообще.

>И каким образом это пул? Это стек/очередь. Они по условию задачи не подходят

Это такой особый пул. Под особые условия задачи.

>Кстати, у обычного пула (списка квантов) время выделения/удаления тоже фиксированное,

Угу, но существенное время инициализации, и выделение всётаки дольше, чем один +=. Что использовать - от задачи зависит, конечно.