Баг компилятора при параметре шаблона = void* - страница 17

 

А пирамидального кода сторонников случайно не было? Если что, я буду первым.)))))


 
Ilya Malev:

А пирамидального кода сторонников случайно не было? Если что, я буду первым.)))))


Это можно отнести к лагерю сторонников горизонтального кода.

 
Dmitry Fedoseev:

Это можно отнести к лагерю сторонников горизонтального кода.

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

 
Ilya Malev:

А пирамидального кода сторонников случайно не было? Если что, я буду первым.)))))


Это - обфускация.

 
Stanislav Korotky:

Это - обфускация.

Да уж, до тебя мне далековато. Есть, так сказать, к чему стремиться ))

 
pavlick_:

В общем да, можно и так.

Если без обвёртки - то не удаляется,  с обвёрткой - удаляется, всё кристально ясно.

ЗЫ: но если бы я делал, то делал максимально схоже со стандартной плюсовой библиотекой (имена, поведение и т.д.), поэтому для меня выбора нет. Зачем плодить ещё одну спецификацию, когда всё уже написано?

- Создавать автоматические структуры в рамках динамического ООП - это нонсенс

- Динамические структуры должны быть разделены на создаваемые под конкретный процесс (типа запроса на выборке) или как выборка из существующего набора элементов (а могут быть и смешанные типы)

- Я пока вижу выход в учете числа "своих" ссылок на объект, для этого совсем не обязательно создавать на него обертки (на самом деле не представляю, как это решит задачу), но придется дублировать механизм указателей, уже существующих в мкл, добавив к ним свои методы, как минимум включающие счетчик ссылок (это обсуждалось в приведенной Вами статьи с хабра кстати, правда я как раз пару дней назад её читал, когда искал решение насчет указателей и понял, что сам уже пришел к тому же решению).

- Попробую все это реализовать, если получится что-нибудь стоящее, по-любому опубликую на форуме и/или в кодобазе :)

 
Ilya Malev:

- Создавать автоматические структуры в рамках динамического ООП - это нонсенс

- Динамические структуры должны быть разделены на создаваемые под конкретный процесс (типа запроса на выборке) или как выборка из существующего набора элементов (а могут быть и смешанные типы)

- Я пока вижу выход в учете числа "своих" ссылок на объект, для этого совсем не обязательно создавать на него обертки (на самом деле не представляю, как это решит задачу), но придется дублировать механизм указателей, уже существующих в мкл, добавив к ним свои методы, как минимум включающие счетчик ссылок (это обсуждалось в приведенной Вами статьи с хабра кстати, правда я как раз пару дней назад её читал, когда искал решение насчет указателей и понял, что сам уже пришел к тому же решению).

- Попробую все это реализовать, если получится что-нибудь стоящее, по-любому опубликую на форуме и/или в кодобазе :)

Очень интересно. Устал от пи@#унов. 

 
Или лучше не надо. Ничего публиковать...
 
Ilya Malev:

Ну так никто же не запрещает передавать доп опцию при создании массива - нужно удалять элементы при его удалении или нет, и сделать её по умолчанию включенной или выключенной (на свой вкус). А то ведь так не угадаешь, нужно удалять или нет.))

Вот написали вы такой массив и в итоге получите сюрприз: как запретить копирующий operator=() и копирующий конструктор (по-умолчание его и так нет в мкл) в массиве указателей, которые требуют удаления? Тут станет ясно, что параметр через конструктор - барахло. Возникнет у вас две идеи:

1. передать через параметры шаблоны тип с удалённым оператором и сделать его членом класса (а это лишние расходы ресурсов).

2. передавать указатель в обёртке :) (да, да - та самая чёртова обёртка).

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

Вообще плюсовая библиотека - это шедевр, если думаете, что напишите лучше, то скорее всего ошибаетесь.

 
pavlick_:

0. Вот написали вы такой массив и в итоге получите сюрприз: как запретить копирующий operator=() и копирующий конструктор (по-умолчание его и так нет в мкл) в массиве указателей, которые требуют удаления? Тут станет ясно, что параметр через конструктор - барахло. Возникнет у вас две идеи:

1. передать через параметры шаблоны тип с удалённым оператором и сделать его членом класса (а это лишние расходы ресурсов).

2. передавать указатель в обёртке :) (да, да - та самая чёртова обёртка).

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

Вообще плюсовая библиотека - это шедевр, если думаете, что напишите лучше, то скорее всего ошибаетесь.

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

0. Я же сказал, что передаются динамические уже созданные объекты. Это либо созданные специально под выборку объекты (их потом нужно удалять), либо ссылки на объекты, которые используются но не удаляются. За создание объект списка не отвечает. только за адресацию, доступ и хранение пока это необходимо. 

1. ...

2. ...

3...

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

Причина обращения: