@Akella


За код в базе я бы программистов четвертовал.  

Что скрипты для дельфи есть -- это, конечно, зашибись, но вот цены по 180 евро -- это как-то дофига. Дешёвая либа стОит ощутимо меньше, но и языки у неё свои, велосипедные. Для дотнета языков в 10 раз больше, и все бесплатные.

Раз уж ты помянул эти либы, мне стало интересно: если в скрипте создать класс, то как к нему обращаться из дельфи? Я почитал примеры, и там только вызов глобальной функции нашёл. Причём синтаксис такой, что убиться можно.



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

И возвращаясь к Simple.Data. Ты не понял. Классы ORM вообще не создаются. Попробуй в дельфи повторить следующую процедуру:

1. Создаёшь приложение
2. Пишешь код: Database.Open().Users.FindByEmail(email) (строку подключения -- любо сюда, либо в конфиг; по вкусу)
3. Компилируешь
4. Кладёшь рядом базу
5. Запускаешь
6. Ты получил объект юзера со всеми полями из БД


Забавная штуковина. Правда, судя по статье, ограничений у неё чуть менее, чем дофига. И если посмотреть код, то понятно, что это proof-of-concept, а не реально работающий код.


Да ладно. Самый мощный LO/OO поливают фекалиями за то, что ничего не умеет и не поддерживает нормально мелкомягкие форматы, а ты какой-то левый офис подсовываешь. Ясно же, что он никому не нужен. Он даже ODF не поддерживает -- о чём вообще можно говорить?

@Beltar


Сборка мусора происходит в отдельном потоке. Если у тебя не выделение гигабайтов в секунду, то сборщик ты работой не заспамишь.

@Alexeis


Стек -- это стек. Не нужно стеком обзывать всё, что быстро работает.


Сборка второго поколения не так уж редко происходит.


Списки большого размера (>85K что ли) идут в LOH, у них другая судьба.


По моим ощущениям разницы практически никакой. Учитывая древность обеих библиотек, все подводные камни гуглятся за 5 секунд.

Ну и построение продаж на прежних покупателях -- это провал по определению. Без притока новых овчинка не стоит выделки.

Там подсчет ссылок.



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

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



Свободных блоков?



А у VCL.NET как будто нет своих тонкостей и подводных камней, плюс весьма неудобное требование тащить с собой .NET, для справки, у меня анлимит на 128 кБит/с появился только весной 2008-го и необходимость качнуть помимо проги еще и несколько десятков метров редистрибутива я бы не оценил. Да и структура компонентных классов там ЕМНИП другая.

Это сообщение отредактировал(а) Beltar - 4.5.2013, 20:41

  Я называю стеком не из-за скорости работы, а из-за принципа работы. Вот скажи, когда для временных переменных выделяется память в стеке, то сдвигается указатель стека. GC делает аналогичную операцию. После прохода по нулевому поколению, что происходит с памятью? Не возвращается ли указатель на первоначальную позицию? Это не стек в прямом смысле, поскольку элементы не уничтожаются в порядке обратном добавлению, но в целом это больше походит на стек чем на кучу. 
   Если ты хочешь сравнивать 2 способа управления памятью, то приходиться приходить к аналогиям, чтобы оценить эффективность. 


  В первый раз слышу чтобы память под элементы списка выделялась одним блоком. Список структура, которая производит операцию вставки элемента за константное время и индексацию за линейное. Из этого определения следует что список состоит из большого количества элементов, каждый из которых может быть небольшим, но при числе элементов 10-100к общая память всех элементов будет уже существенной. Поскольку связь корневым элементом есть только у перового (последнего) элемента списка, то чтобы проверить нужно ли удалять 5396й элемент по идее нужно перебрать 5395 элементов. В таких схемах может спасти только маленький сегмент нулевого поколения ну или специальная стратегия.


Судя по всему ты в своей жизни ничего сложнее Hello World не писал. Когда у человека заканчиваются аргументы, то он начинает переходить на личности и давить авторитетом. Засчитываю слив и техническое поражение. 

@Alexeis

Все три поколения сборщика мусора дотнета -- это самые настоящие кучи. Дефрагментация происходит не при каждой сборке мусора. Это было бы бесполезным оверхедом, потому что операция относительно дорогая. Поэтому выделение областей памяти может происходить не только "сверху". И удаление тоже происходит в любой точке. Это верно для любого поколения. Архитектурно поколения ничем особо не отличаются, вроде. Они различаются только взаимной логикой: что куда перемещается и где остаётся. А как память выделяется, как упаковывается, как освобождается -- механизмы одни и те же.

Стек -- это LIFO. У кучи нулевого поколения никакого LIFO нет и в помине, если только переменные не создавать один раз и больше никогда не уничтожать.


Под списком я имел в виду дотнетовый List<T>, который вопреки всей логике -- аналог vector<T> (связанный список называется LinkedList<T>). Сколько программировал -- связанный список ни разу не понадобился, но это уже другая история.


Слив не засчитывается при взаимном оскорблении.  

А вообще, в чём-то Bother прав. Я бы не взял на работу плюсовика, который не пользуется boost из-за того, что он не поставляется со средой разработки восьмилетней давности. Плюсовик обязан знать STL и boost. Это как писать на C#, но не слышать про .NET, или как писать на дельфи, но не слышать про VCL.

  Он не поставляется ни с какой средой кроме билдера, поэтому не может считаться частью языка. Так что считай С++11 это первое где официально появились умные указатели. И посчитай какой процент компиляторов поддерживет С++11.


  А с чего вы взяли вообще, что я не пользуюсь boost в VS2005? Такой информации я ни где не предоставлял. Я сказал, что VS2005 и даже VS2008 не поддерживают  С++11. Даже VS2010 не полностью. Напротив, я буст собственноручно настраивал и компилировал под версию VS2005 . У меня используется много разных библиотек, но они не являются частью С++ . Но VS2005 это далеко не худший компилятор С++ (напротив отличный компилятор на мой взгляд). Посмотрите перечень поддерживаемых компиляторов. Там наберется горстка компиляторов для десктопов. Любой компилятор С++ обязан поддерживать STL в полном объеме согласно стандарту под который он писался. Но любой компилятор НИ РАЗУ НЕ ОБЯЗАН поддерживать boost. И множество компиляторов С++ не поддерживается boost-м и могут использоваться лишь частично с непредсказуемыми последствиями.
  На делфи есть куча библиотек, которые стали дефакто стандартными у программистов, но когда мы обсуждаем возможности языка мы не обсуждаем библиотеки, которыми пользуются большинство дельфистов. Есть определенная граница. Если мы говорим, что С++ до 11й версии не знал, что такое потоки в принципе, то мы не можем говорить, что на самом деле потоки были, просто они были в бусте. Это почти тоже самое, что сказать потоки в С++ были, потому, что я имел возможность использовать их под Windows на библиотеке boost . 
  До версии Delphi XE2 fastreport -ы использовались дефакто как библиотека для генерации отчетов. Но лишь в версии XE2 она стала поставляться и можно говорить, что в делфи появилась встроенная возможность генерации отчетов по скриптовому шаблону и появилась возможность исполнять скрипты (fastscript) и обмениваться данными между скриптами и программой. Я же не говорю, что библиотеке fastreport уже 10 лет, значит делфи уже 10 лет поддерживает все эти возможности. 

Насчет буста та же педивикия пишет:



А вообще неплохо бы завести в Delphi аналог, STL я так понимаю, хотя бы частично VCL поддерживается.

@Alexeis

Я не собираюсь разводить демагогию на тему "включено/не включено". Буст -- де-факто стандарт для разработки на плюсах. Можно, например, пройтись по вакансиям на каком-нибудь сайте -- если нужен плюсовый разраб, то в требованиях почти наверянка будет буст.


Какие ещё "непредсказуемые последствия"? В бусте испокон веков были конфиги под разные компиляторы. Все популярные компиляторы определяются по дефайнам, даже в конфиг лезть не надо. Буст автоматически сконфигурируется на использование максимального числа фич, доступных с используемым компилятором.


Бредовый подход. Любой язык не стоит выеденного яйца без библиотек. В споре в этом топике меня всегда интересовали реальные возможности разработки, а не версии "из коробки" с одной стороны или фантазии на тему "а вот если" -- с другой. Вон, в пользу дельфей упоминали всякие FastMM, paxCompiler и прочие -- это всё тоже "из коробки" что ли?

@Beltar


Исправлено:

Некоторые программисты[кто?] считают его стандартом де-факто и необходимым дополнением к STL. Другие,[кто?] напротив, избегают всякого использования библиотеки в проектах, опасаясь введения излишней зависимости в проект и считая, что использование этих библиотек слишком повышают требования к знанию программистом C++, так как некоторые части Boost являются весьма сложными.[источник?]

Русская педивикия такая русская. Срам.

Учитывая древность - один из худших.
Ага, для десктопов. Один гцц только чего стоит.Это касается только некоторых фич, которые теперь обязаны поддерживаться компиляторами(type_traits, например). Смарт поинтеры к этому не относятся.
Насколько я знаю, у дельфи вообще нет ни стандарта, ни спецификации. Это значит мы вообще не должны говорить о существовании дельфи как языка? А судить о возможностях по поставляемым с иде(или компилятором) библиотекам - чушь полная. Тем более что дельфи ты оцениваешь по самой продвинутой иде, а для плюсов предлагаешь руководствоваться худшими.


Это сообщение отредактировал(а) Bother - 5.5.2013, 08:57

FastMM, начиная с 2006-го года, да.

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


А зачем для Delphi стандарт(ы)?
У Delphi одна среда разработки. Delphi - это один язык программирования. Разработкой Delphi занимается и занималась одна компания.
Другое дело, что разных паскалей, бейсиков несколько. Для C++ есть разные компиляторы и среды разработки (IDE). Поэтому в таких случаях лучше будет, если будут приняты некие "правила". Я так думаю.

Ну вот есть у плюсов стандарты, а сколько компиляторов их полностью реализуют?

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

Т. е. если помрет MS, то любой ее проект из VS можно будет продолжать в чем-то другом? Самому-то не смешно? У Delphi и то есть шанс переноса на Lazarus.

@Beltar


Во-первых, МС не помрёт. Во-вторых, проект без проблем можно будет продолжить. Достаточно в MSBuild перевести стрелки, и проект будет собираться другими инструментами. Там конструктор, а не монолит. Если что-то отмирает, то заменяется.

Вот дельфи -- монолит. Компилятор один на весь мир. И даже не бесплатный.

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