Я вас расстрою, но я нашел игровой движок для Делфи игровой движок нашел. http://www.afterwarp.net/

Тоже уже празднуешь?    

@Zloxa


Десктоп (кассовый терминал, энтерпрайзный "бэк-офис"), веб (крупный сайт, мелкие сайтики, мелкая игрушка), немного всякого хакерства-крякерства-ковырятельства, в прошлом плагинчики для тотала и прочие мелкие поделки, последнее время пытаюсь проникнуть в десктоповые шаровары и гейм-дев (от деталей воздержусь, потому как не люблю делить шкуру неубитого медведя). В гейм-деве -- и алгебра, и дискретка, и алгоритмика, и прочий матан. В десктопе -- сложный UI, сложная предметная область, многопоточность, постоянные изменения, тучи рефакторинга, взаимодействие по сетке с сервером и сервисами, по разным интерфейсам с железками, написание кастомного движка автотестов, оптимизации (кассовые терминалы довольно урезанные по железу), интеграция со скриптовыми языками, кодогенерация... куча всего разного. В вебе я похапэшу, верстаю -- тут ничего особо примечательного (подумываю о более адекватном ASP.NET MVC, но пока это только мысли; похапэ "наелся").

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

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

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

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

Про пользу грамотного ООП, юнит-тестов, систем контроля версий, скриптовых языков не надо доказывать никому -- оно и так ясно любому здравомыслящему человку. Но Белтар даже здесь влезает со своим веским словом, что всё это магия и шаманство. И ведь не троллит, а реально так думает.

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

@Beltar


На этом офигительном движке написаны прогрессивные, сложные, популярные игры: point-and-click игрушка с графикой средней флешки, полтора пазла и платформер с графикой, которую в приличных местах не упомянешь. Круто, чо.

И что-то на сайте движка с сентября нет обновлений, а в сорцах с тех пор аж три коммита: два багфикса и создание бранча. Пациент скорее мёртв, чем жив.

с точки зрения плюсов на дельфи нельзя написать SomeClass someObj, можно только SomeClass* someObj. А то, что частота ошибок при таком подходе возрастает многократно - это да, тебе уже не раз об этом говорили.А - вот к чему было провозглашение смерти плюсов. Теперь то дельфи уж точно станет основным инструментом для разработки игр.   
Судя по всему - это очередная объектная модель. Они видать их на каждый чих пихают. Неудивительно - паскаль никогда не славился хорошей архитектурой, и пытался замаскировать это т.н "строгостью", которая на дале ничего кроме запутывания в стенах текста не означала.

  Частота ошибок на С++ при таком подходе многократно возрастает, особенно если смешивать оба подхода, передавать куда нить указатели на стековые объекты или разрушать их не своевременно, копировать их без конструктора копирования, чтобы увеличить время жизни.
  Не путайте хер с пальцем. Когда объект всегда создан в куче, то с ним очень просто и однозначно работать. При правильном подходе, путешествует по коду лишь COM интерфейс, а он реализован как автоматический объект, который сам уничтожиться когда никому не станет нужным. Если COM интерфейс не используется, то используется стратегия владельца. Владелец чистит все объекты которыми владеет перед уничтожением. Объекты созданные в куче в большинстве случаев не требуют копирования, поэтому исчезает еще одно место для частых ошибок С++ - неправильный конструктор копирования. Объекты все имеют таблицу VMT и виртуальный деструктор, поэтому корректное уничтожение через указатель на любой базовый класс гарантировано безопасно. Да и вообще, если объект передали во владение, то не нужно думать его уничтожать и нужно ли вообще. Вопрос всегда решается однозначно, что нужно и дается всегда одним способом. Кроме того, если говорить о достаточно больших объектах, то и в С++ их создают в куче, для того чтобы избежать длительной операции копирования в контейнерах. И еще в Delphi отсутствует конструктор копирования объекта по умолчанию, что опять же избавляет от ошибок, когда объект начинает разрастаться и копирование перестает быть тривиальным. 
  А вот необходимость в простых стековых объектах закрывается рекордами, аналогами структур, только в отличии от С++ из record полноценного объекта не сделать, зато можно копировать его сколько угодно раз и вызывать методы, в том числе и статические.

Ага, а на дельфи остается на прежнем высоком уровне.
Когда объект создан на стеке с ним ещё проще и "однозначнее" работать.
о - как просто и однозначно. А weak ref оно умеет? А что если мне не нужен счётчик ссылок? А если у меня обслуживающий класс, реализующий специфическую функциональность - для него тоже интерфейс писать? Реализация интерфейса предпологает использование виртуальнах методов? Т.е если я хочу автоматического управления - мне нужны виртуальные методы? Было бы бредово.
А что если мне не нужен vmt? К тому же речь о том что корректного уничтожения может и не быть.
Как уже писали выше - далеко не всё и не вегда так однозначно.
копирование больших объектов может понадобиться только в ситуации когда такой объект меняет владельца. Что бы избежать копирования, объект не обязательно распологать в куче. см. move semantics.
Необходимость в стековых объектов в дельфи никуда не пропадает. У вас в представлении всегда два крайних случая - большие объекты и структуры данных. На деле это никогда не так. Большую часть объектов составляют какраз средняки - не просто данные(а объекты), но и не огромные коллекции.

@Bother


Я тут гуглил... В дельфи ВСЕ интерфейсы наследуются от IInterface IUnknown. Счётчик есть при использовании ЛЮБОГО интерфейса. Какая к чёрту экономия на VMT, есть такое пропихивается.

"Weak ref" будет, если параллельно со ссылкой на интерфейс использовать ссылку на реализацию. Но в документации чёрным по белому написано: "Если вы так будете делать, всё кончится плохо".

Так оно и без документации ясно что плохо. Потому и спрашиваю - можно ли сделать по человечески? 
Видимо нет. И эти люди ругают ГЦ...   

Мощей.



Допусти Злохе неясно, или вернее не столь очевидно. Диего, который много кодит, тоже. До тебя так и не доходит, что вот есть фича, само по себе ее наличие это скорее хорошо, чем плохо, особенно если необязательно ее юзать, но вот юзать-то как раз и необязательно. Ну и в итоге будет, что Delphi потребности подавляющего большинства программистов удовлетворяет. Кого не удовлетворяет тот уходит. А от ваших детских комплексов, что ой, на ней только студенты пишут, которые еще на плюсы\жабу\шарп\... перешли ("если пишешь ты на Си, будь хоть трижды ламер...") она хуже не станет.



По определению интерфейсов, хотя их кто-то юзает, кто-то нет.



В 158-ой+1 раз повторяю, для этого есть структуры. Сколько пишу, постоянно надо заводить локальные ссылки на объекты, передавать объекты по ссылке, но может 2 или 3 раза надо было скопировать содержимое одного TSrings в другой. Так для чего вынуждать меня явно работать с указателем, провоцируя ошибки, что здесь чего-то не поставил, там не поставил?



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



А ведь если подумать, то 99% создаваемых и уничтожаемых объектов хранятся как раз в разного рода List'ах, которым можно дать право владения, т. е. после команды Delete объект будет автоматом освобожден, причем освобожден немедленно, а не когда-то там, что упрощает освобожение дефицитных ресурсов, которые может продолжать удерживать ожидающий смерти через GC объект.



Что это такое, и почему с этим носятся в плюсах дельфину вообще не понять. Впрочем и неудивительно, у дельфина для мелочевки есть идеально работающие структуры, а для копирования объектов посложнее есть метод TPersistent.Assign.
Википедия приводит такой пример:



Который приводит к Segmentation Fault просто потому что в плюсах массив и указатель не отличимы. Эта же проблема является причиной уязвимостей из-за переполнения. Т. е. сетевое ПО, написанное на плюсах, можно считать дефектным по умолчанию. Знаете, но с точки зрения дельфина такое вот ручное управление памятью натуральный закат солнца вручную. И понтоваться умными указателями тут, то же самое, что владельцу ржавой шестерки понтоваться новой магнитолой перед владельцем новенькой "Тойоты".



На мой взгляд поддержку object из языка можно убирать, тем более что там вроде что-то в компиляторе сломали. Добавить записям примитивное наследование, которое есть у object и перевод старого ПО с object'ами в новые версии будет происходить тривиальной заменой object на record.

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

Добавлено через 3 минуты и 58 секунд

В Делфи как всегда какие-то свои определения.

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

Пофикшено.

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

Снова пофикшено.

Повторяю в милионный раз - это не одно и то же.
Кто вообще заикается про копирование? Оно не нужно при работе с объектом на стеке, обычно он предаётся по ссылке(не путать с указателем).Работа с указателем здесь ничем не отличается от дельфовой работы с объектами. Ошибки те же.
достаточно заменить сишный массив на vector / array. Плюсовый стиль сильно отличается от сишного.
Дефектными по умолчанию можно считать дельфистов. Покажи мне работу с сырыми массивами в boost/Qt. Один asio надёжней чем миллион дельфей. Так дельфисты только и делают что вручную управляют памятью.Если плюсы это ржавая шестёрка - то дельфи трёхколёсный велосипед. 

Это сообщение отредактировал(а) Bother - 1.5.2013, 17:31

@Beltar


По определению COM-интерфейсов операционной системы Windows. К интерфейсам во всём остальном мире это отношения не имеет.


В плюсах есть следующие типы, работающие с полиморфизм включения:
1. указатели;
2. указатели на константы;
3. константные указатели;
4. константные указатели на константы;
5. ссылки;
6. ссылки на константы.

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


Вообще-то ты уже сделал все выводы, когда в первый раз упомянул. И потом тоже.


Ты правда думаешь, что кому-нибудь будет не лень в 50-й раз рассказывать тебе про RAII? Берёшь на измор?


Ты ожидаешь проверки аргументов и индексов от минималистичного примера? Юзай STL и будет тебе счастье с валидацией индексов.

Добавлено через 10 минут и 3 секунды
@Beltar


Вот этот момент особенно забавен.

Ты: В дельфах есть "обджекты", древние как окаменелое г#вно мамонтов, нафиг никому не нужны. Выпилить бы их нафиг.
Оппонент: Да, лишняя вещь, всё усложняет только, нафиг её.
Ты: Да как ты смеешь!!! Да это ж! Да я-то ж тебя! Да на куски порву!!!!!! Ты ничего не понимаешь в дельфи!!!!!!!!!!!!!!!111111адынадын

Или с делфийскими(паскалевскими) же указателями.

Опять мне приписывают, что я не говорил. Хотя выпилить действительно можно, потому что дубляж функций происходит.



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



Сразу видно, что не работал.



Заменяй. Если обернуть гниль в обертку, она так и останется гнилью. Отсюда и GC, потому что народ наелся управлением памятью, причем наелся не в Delphi, где ничего сложнее вызова Free без необходимости делать не приходится.



А что мне реально даст RAII, кроме, по меньше мере, сомнительной провокации создавать сервисные классы в стеке? И почему твой любимый шарп вдруг использует дельфовый подход?

@Beltar


Ты так и не привёл ни одного примера преимущества работы с памятью в дельфи.

А что не в дельфи наелись -- ну так ведь:




Это из того же разряда, что и вопрос, почему под винду так вирусов много. Да потому что самая популярная ось. Тж. см. картинку выше.


Потому что главный по языку один и тот же?