По поводу объектов на стеке, ну вот есть они в плюсах, но что-то сами наСИльники далеко не всегда положительно оценивают такую практику, да и если подумать, чем объект в стеке отличается от структуры в стеке? Доступена сразу же, никаких конструкторов\деструкторов помрет так же при выходе. Иногда бывает нужно какую-то функциональность в процедурке получить. Например, файл прочитать. Я извиняюсь спросить, а кто мешает создать глобально один экземпляр нужного класса, который и будет обеспечивать нужную услугу, когда она нужна. Или будем при каждом вызове процедурки его заново создавать и убивать? А еще в других местах, где такая же функциональность понадобилась. Нахрена? Нет, может там нужно один раз при запуске чего-то выполнить, но ради этого проектировать язык так, чтобы сэкономить десяток тактов процессора 1 раз?   

Что еще остается? Умные указатели из плюсов? В Delphi сейчас реализуются на основе структур, интерфейсов и дженериков. Ключевой элемент именно дженерики, а не пресловутые, неотличимые от структур объекты в стеке.

В общем очередной гнилой наезд от человека, который не знает не то, что Delphi, а вообще программирования. И хоть сколько языков такой изучит все равно в упор не будет видеть очевидного.

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

Ключевое отличие - тебе не нужно писать то же самое дважды. Иногда это просто нереально(пришлось бы реализовывать функционал сторонних библиотек). Так что объекты полностью отличаются от структур - это другая плоскость.
Все твои функции будут работать с одним файлом? Для остальных объектов это не менее тупо.
Причём здесь такты? Создание и удаление объектов - наиболее частая операция в ООП. То, что дельфи заставляет мучиться с каждым объектом - явно говорит о непродуманной архитектуре.Код в студию. Сути это не изменит, просто хочу посмотреть не слишком ли уродливо.   
Ты так и не реализовал то, что я просил. Так что не нужно тут пустозвонить и уводить разговор в сторону. Про мои навыки можешь и не заикаться - вылези для начала из песочницы.

Откуда такие дровишки? Вполне себе используют и часто. Тот же RAII например, хотя он не про производительность.


Опять же RAII. Конструктор захватывает ресурс, деструктор — освобождает. В C# для подобного пришлось специальное ключевое слов ввести. Теперь и в жабу добавили расширение try.


В чем его «ключевость»?


Ололо, покажи мне в делфи естественное сопоставление с образцом (pattern matching).

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

Вот это и можно назвать ООП в действии, мозг покалечен и человек неклассово мыслить не может.



Еще раз, для альтернативно одаренных.
Мне нужно прочитать что-то из файла, у меня есть для этого класс TFile с методом Read(FileName;Buffer). Я создаю этот класс и читаю. Дальше мне, возможно, понадобится еще что-то прочитать\записать и забыть. Зачем я в этом случае должен уничтожать этот экземпляр, чтобы потом только создавать его заново, как дурак? Если же мне это считывание понадобилось разово, то тогда расходы на создание и уничтожение одного экземпляра становятся равны нулю.

Так для чего мне нужно создание в стеке? Серьезные объекты там не создашь по определению, они, как правило, нужны глобально. Мелочевка же представима структурами. Ну или object'ами, у них наследование есть примитивное. Проблема существует только в воспаленных мозгах фанатов плюсов и иных языков, исключающих неклассове мышление.



Нагуглишь.

@Beltar


STL -- это не "аж", а часть стандарта плюсов. Но ни STL, ни boost, ни .NET Framework дельфи даже в эротических снах не снились. Ты мне уже демонстрировал свой велосипед для рекурсивного прохождения по директории -- спасибо, поржал.

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


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


Когда ты сказал: "Скриптовые языки не нужны" -- я выпал в осадок.
Когда ты сказал: "Системы контроля версий не нужны" -- я офигел.
Когда ты сказал: "Юнит-тесты не нужны" -- я ох##л.
Теперь ты говоришь: "ООП не нужен" -- я не нахожу слов, чтобы выразить глубину моего удивления.

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


Ты бы ещё в тетрисе квадратики оптимизировал. Юниты в RTS -- это не то, где возникают проблемы с памятью.


Вот ты снова и вернулся к фрагментации. 


Обратим внимание, что на месте старого массива останется дырка в памяти. И опять фрагментация. Ну и сам "стек свободных ячеек" у тебя будет постоянно меняться в размерах -- снова привет фрагментации.


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


Тащемта, параметризованные классы в плюсах тоже на стеке умеют создаваться, как и обычные классы. Неясно, к чему столько эмоций.

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


"Есть всё"? Лол. Я же при первом появлении здесь перечислил всё, чего в дельфи нет. Давай, раскрой нам глаза, перечисли всё это в дельфи, но с другими -- естественными! -- названиями.

@Bother


Оно бесполезно чуть менее, чем полностью. Если Белтар не поленится пример привести, то мы поржём. 

Фрагментация в пределах моего пула абсолютно пофигу, т. к. я всегда нахожу свободное место, причем очень быстро. При этом используя заполнение равномерными элементами я использую память лучше. Грубо говоря, если есть дырка, то ее размер совпадает с тем, что я собираюсь в нее засунуть. Т. е. фрагментация на пуле лишь увеличивает цикл его перебора, но никак не количество данных, которые я могу туда запихнуть.

@Beltar


Укажи на конкретные ошибки.


А-а-а... То есть ООП -- это не только бесполезно, но и вообще вредно? Мы уж как-нибудь глобальными переменными и глобальными процедурочками, ага?


Ты б ещё сишников фашистами назвал -- вообще замечательно было бы.  


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

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

И ты упустил из вида главную проблему, ради которой вообще вспоминались деструкторы объектов в стеке. Вот есть у тебя глобальная переменная -- как ты будешь вызывать метод закрытия файла? Сам, всегда, вручную. Можешь забыть. А деструктор -- не забывает.

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


И-и-и... всё остальное было проигнорировано. Мне ждать ответа, или уже усё? Где мои объекты разных размеров?

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



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



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

@Beltar


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


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


Где тут эта картинка была... Ах да, вот:



Задумайся. Ты предложил разделять между потоками право на открытие любого файла. Из соображений экономии памяти. На 16 байт. С взаимной блокировкой.

Да вы упороты.

Всё я представляю. Представляю и более прямую архитектуру, в отличии от тебя.
Не о каком ООП здесь речи не было - только о реюзабильности классов. В дельфи такого нет, и не один "дельфин в здравом уме" при всём желании это не исправит.Как мило - дельфинчик пытается решить одну проблему, при этом создаёт себе горстку новых. Итак по порядку: засорение глобальной области видимости, проблемы с асинхронностью, и самое главное - при вызове функции ты не можешь знать изменит ли она состояния объекта. Т.е ты должен будешь открыть файл, поработать с ним, закрыть, и только после этого пользоваться другими функциями. К тому же у объекта есть и другие состояния, которые придётся обнулять перед использованием(формат ввода чисел в С++, например). И всё ради чего? Не контролировать время жизни объекта вручную? Так тебе по любому придётся контролировать открытие/закрытие файла вручную - RAII то нет. Хочешь, не хочешь - а жонглировать объектами в куче, "как дурак", тебе придётся. Ничего не мешает создавать "серъёзные объекты" на стеке. Переписывать мелочёвку - вперёд и с песней, дельфины любят писать много лишнего кода. Проблема к классам не относится - всё упирается в типичное использование объектов вроде локального размещения и агрегации. Это базовые операции, а дельфи не имеет адекватных механизмов для автоматического управления временем жизни таких объектов(только неадекватные, вроде полного переписывания под "записи").
Нагуглил только пародию на кастрированный shared_ptr. Причём это не умный указатель, т.к не реализует семантику указателя.

Это сообщение отредактировал(а) Bother - 28.4.2013, 07:42

А обосновать свои слова ты опять не в состоянии?

Добавлено через 7 минут и 56 секунд

Судя по всему его структура будет включать в себя все возможные характеристики юнитов. Ниче так оптимизация =) Особенно для стратегий, где игрок сам может конструировать юниты, типа Earth 2160.

Собрались могильщики уже в который раз. Но никак не получатся похоронить Delphi   

Он давно похоронен, просто пытаемся угомонить некрофилов   

У похороненых продуктов новые версии не выходят. Ребят, а почему бы вам не пойти на форумы по VB 6, или FoxPro и не пообъяснять там, что пользующиеся этими инструментами некрофилы.



А я почему-то введя в гугл "Delphi умные указатели" сразу попал на запись семинара, где такая техника демонстрируется.



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

Да, персонально для Атари, как можно пул с разноразмерными объектами отсечь от всех остальных, я тебе показал, дальше задача принципиально не отличается уже от работы GC по уплотнению, разница лишь в том, что при отсеченном пуле достаточно проверить контекст, что GC тоже делает. Ты об этом прекрасно знаешь, только выделываешься. Если честно, то твоя вредность уже начинает раздражать. Будто комплекс неполноценности у тебя, и тебе так надо самоутверждаться.