@Alexeis


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


boost? http://www.boost.org/users/history/old_versions.html -- умный указатель появился в 1999-м, 14 лет назад. STL -- это, конечно, наше всё, но писать на плюсах, не пользуясь boost -- это странно. (И boost -- это не совсем "сторонняя" библиотека, в ней обкатываются новые фичи для стандарта.)


Ну то есть его нет. Можно было труп не выкапывать.  

@Beltar


Нет другого уровня. Берёшь любую БД -- и все классы, свойства, связи (если в базе оно есть) магически доступны у тебя в коде.

Традиционный подход -- дублирование кода в SQL и в коде/конфигах (ORM). Есть подход с генерацией кода по конфигам. Есть подход с генерацией базы по коду (не знаю, есть ли такое для дельфи). Здесь предполагается наличие БД (SQL, конфиги, код и прочее ненужны; БД во время компиляции ненужна).

  Я думаю, что главной причиной стало как раз это. Но не в том смысле что лень писать, а в смысле, что когда лезут глубоко в позднее связывание со всякими абстрактными фабриками, когда объект становиться разделяемым, тем более если между программами или даже машинами, то уже не уследишь, когда он перестает быть нужным и как уже 100 раз говорили подсчет ссылок не спасает.
  Но мне нравиться и сам подход линейной обработки. Т.е. выделение происходит мгновенно, а освобождение ведется последовательных блоков, что позволяет устранить фрагментацию памяти. ПО с менеджером кучи, после недели непрерывной работы заметно замедлиться за счет кучи дыр и с этим ничего не поделать в связи с запретом на перемещение участков памяти. ПО на сборщике мусора будет работать сколь угодно долго не теряя в производительности. При правильной настройке сборщик должен работать быстрее. Возьмем, к примеру, простой объект типа строки созданный в подпрограмме. Элемент является корневым и не имеет никаких связей, следовательно обход графа связей будет тривиальным и область будет сразу помечена как свободная. Т.е. мы не затратили времени ни на выделение памяти ни на освобождение. В то время как эта же операция в куче потребовала бы обход списка блоков с поиском подходящего по размеру. Однако, в сложных случаях типа деревьев, кольцевых списков так прекрасно все работать не будет. Но зато после перового обхода все данные переместятся в другой блок, в котором их уже трогать не будут. По сути к объектам применяется своего рода статистический анализ и упорядочивание по времени жизни. Т.е. в некотором роде машина сама делает выбор за программиста где оптимальнее располагать данные в куче или стеке. Первоначально берется оптимистичный вариант стека. Теперь подумаем как действует программист на С++ . Если он не знает времени жизни объекта, то он почти наверняка создаст его в куче, потому что иначе объект уничтожится по выходу из блока, что недопустимо, а GC может себе позволить создать любой объект стеке, поскольку при необходимости он его может переместить на следующий уровень (аналог кучи). 
  Отсюда следует, что программист на С++ при написании качественного ПО со слабыми связями будет вынужден всегда действовать из пессимистических стратегий выделения памяти, тогда как GC может реализовать оптимистическую. Если GC не угадал с размещением, то он как бы устраняет ошибку, но только тех объектов, где он ошибся, С++ программист сразу же тратит время на размещение в куче. 
  Если рассмотреть случай, когда ПО очень редко создает и удаляет объекты, то преимущество GC еще более возрастает, потому что сборка мусора не будет производиться совсем, а выделение мгновенное.
  В худшем же случае он GC будет работать в несколько раз медленнее кучи, т.е. не возникнет существенных проблем.

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

  Они просто создают объект в стеке безо всяких new  . 

  Я предлагаю использовать это только в тех самых не более 5% случаев когда скорость выделения памяти действительно имеет значение. 

 Ты удивишься, но есть еще много людей, которые даже STL не используют, не то что boost . Но не в том дело. Пока что единственный компилятор, который поставляет с собой буст в комплекте это C++ Builder как ни странно  . С++ это не только Windows и Linux. Кое где даже исключения не работают, а ты говоришь boost. boost это библиотечка для рафинированных мальчиков, которые сидят в тепленьких офисах и рисуют кнопочки под окошки. Как ты на своем бусте заведешь потоки если у тебя ваще нет операционной системы? 
  

  Херсе батенька, вы зажрались. Если .NET2.0 закапывать, то Delphi с С++ нужно было закапать еще 10 лет назад. 

@Alexeis


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

Да и кнопочки под окошечки -- это уже некоторое время не задача плюсов. Если в наследство что-то досталось -- да. А новый корпоративный софт на плюсах писать особо не рвутся, вроде.


Я опросик на хабре недавно создавал: .NET Framework: Какую версию вы используете? Народ даже 1.0 использовать умудряется.  

Но в случае Delphi.NET проблема не в дотнете, а в дельфи. Дотнетовая дельфи никому нафиг не нужна. Она ж не труЪ. И это официально мёртвый продукт, сейчас на нём даже фанатики писать ничего не будут. В общем, приводить это нечто как пример "а вот дельфи умеет" считаю неуместным.

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


Интересно ты поколения в стек и кучу превратил...

Какое «такое»?


К сожалению тебе это вообще не свойственно.

Ну для Delphi есть fastscript и paxCompiler. 
Те же скриптовые языки, код который компилируется и выполняется "не лету" во время исполнения аппликации (run-time). Где ты будешь хранить код - твоё дело, хоть в базе.

Не факт. Частенько перед произведением каких бы то ни было действий, необходимо убедиться, что все необходимые ресурсы доступны.


Ну так, что тут удивительного?

Variant Invoke and RTTI
http://alex.ciobanu.org/?p=478

Вот офисный пакет Kingsoft Office на delphi написан
http://www.ksoffice.net/

здесь список софта, а ниже список компаний, активно использующих delphi
http://delphi.wikia.com/wiki/Good_Quality_...ilt_With_Delphi

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



Например? Меня больше интересует стабильность производительности, а обход нескольких сотен мегабатов памяти с десятками тысяч ссылок ничего хорошего в этом плане не обещает.



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



Причем тут тру/не тру, просто нет смысла делать VCL поверх библиотеки, которая делает то же самое.



В рекламных проспектах уже бог знает с каких времен пишут что-то вроде:



Не то же самое?

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

То-то Бельтар расстроится: столько сил потратил на то, чтобы доказать, что ГЦ - кака, а тут эта кака в его любимую дельфу проникла  

Ты хотел сказать ActiveX? Ну да, там похожий прием используется, но тут дело не в том, что динамические типы для таких задач предназначены, я просто упомянул, что на них это легко реализовать. Да и не только это. Вот еще пример с флюентом. В википедии есть пример реализации на разных языках, можешь посмотреть
http://ru.wikipedia.org/wiki/Fluent_interface
Между тем простейший пример с динамической оболочкой будет выглядеть так

Дальше создаем класс для тестирования
Запускаем слудующий кодИ получаем выходные данныеПричем заметь, это будет работать для всех типов и любых свойств, достаточно вызвать метод set<ИмяСвойства> и передать ему значение. Таких примеров много можно привести.

  Пытался в свое время выудить. Там десяток включений всяких + куча дефайнов. Это всю кухню разрулить немалых сил будет стоить. 


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


  После прохода 0го поколения его стек ведь очищается. Да и удаляешь ты все блоки одновременно, фактически переносишь только то, что нужно, остальное скорее всего будет занулятся. Ну делфи к этому не привыкать. Для каждого объекта созданного в куче память предварительно зануляется. + Расходы не обход графа. У меня вызывает сомнения только работа со списками большого размера. Там же ссылки только друг на друга. А вот на счет сотен мегабайт, я думаю что это вопрос настройки GC . Если стек нулевого поколения будет занимать 1-3 Мб, то сотни мегабайт будут по мере поступления переноситься в 1е поколение. Т.е. затраты будут сравнимы с кучей. 
  

VCL.NET это не тоже самое что Windows Forms . Возьмешься написать проект на 50-100 тыс строк кода на Windows Forms учитывая, что ты его не изучал толком и не знаешь подводных камней? Или все таки предпочтешь знакомый VCL в котором добавился GC, проверка границ массивов и т.д. ? Когда у тебя исключение переполнения возникает в момент его возникновения, а не в произвольном месте кода ты обращаешься по неверному адресу.  

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

Для использования shared_ptr достаточно указать компилеру к boost. 
судя по всему ты его в глаза не видел.