@Zloxa


Да. Сравни:

или вообще

с общей формой

или частной


Если переменных несколько, то всё вообще весело:

в самом простом случае превращается в

а в общем случае это вообще


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

Примечания.
1. Зачем проверка на null? В using можно использовать любой метод, а не только конструктор, и этот метод имет право возвращать null. Например, переменная bar в примере выше может быть внутри блока using равна null, если создана через фабричный метод, потому что используется как аргумент.
2. Зачем каст к IDisposable? Интерфейс IDisposable может быть реализован явно (explicit implementation). Практикуется редко и вообще не рекомендуется, но встречается.
3. Зачем две переменных оборачивать в разные try? Только такая запись гарантирует правильное освобождение ресурсов.

Динамическая типизация в delphi делается не через Variant.
http://ru.wikipedia.org/wiki/%D0%94%D0%B8%...%86%D0%B8%D1%8F

Тут все дело в том, что в шарпе до появления динамических типов не поддерживалось позднее связывание, поэтому у некоторых сложилось впечатление, что это чуть ли не главное преимущество динамических типов. В бейсике позднее связывание для типа Object поддерживалось всегда, это было реализовано на уровне компилятора и для введения такой фичи никакие динамические типы не нужны. На самом деле это не главное. Динамические типы могут быть разными, сам фреймворк поставляет класс с динамическим поведением, под названием ExpandoObject. Такому объекту, например, можно налету добавить отсутствующее свойство, просто присвоив этому свойству значение и далее можно будет к этому свойству обращаться так же, как любому другому. Но и это еще не все. Самое интересное то, что можно создавать собственные динамические объекты и определять их динамическое поведение. В таких объектах можно обращаться к несуществующим свойствам, вызывать несуществующие методы и т. д., при этом как будет реагировать на это объект можно определить, переопределив методы доступа к членам. Покажу простой пример.Здесь создан динамический объект, который регистрирует обращения к собственным свойствам и добавляет имена этих свойств текстовому свойству expr, при этом эти свойства всегда возвращают сам объект, но уже измененный. Дальше мы создаем экземпляр класса и вызываем у него последовательно несуществующие свойства 
На консоль выводим значение свойства expr и получаем выводСпросишь для чего это нужно? Ну, например можно не просто фиксировать имена вызываемых свойств, а строить из последовательности вывода деревья выражений и дальше делать с ними все, что в голову взбредет. Или, к примеру, есть возможность создать универсальный прокси-класс, который будет работать с разными типами объектов, переадресуя им вызовы и выполняя какую-то дополнительную работу. Вообще тут возможности ограничены только твоей фантазией.

@Beltar


Да что у тебя за детский максимализм... Причин не одна, а куча. Да, наличие консолей -- это тоже причина.

На иксбоксе, кстати, дотнет вполне себе живёт.


Да кому они к чертям нужны? Тем фанатикам, которые меряют, у кого 101 FPS, а у кого 102?

Ты только задумайся: двойные видеокарты. Это не ускорение железа, это выбивание производительности грубой силой. Платя в два раза больше, ты будешь иметь прирост 40% в лучшем случае. Это совсем не аналог обычного "топового" железа десятилетней давности -- цена совсем другая. Цену GeForce 690 посмотри -- это цена стандартного хорошего компа.


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


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


У каждого языка есть фанатики, готовые писать на любимом языке в ущерб всему остальному. Их наличие не доказывает пригодности выбранных ими средств для общих масс.


Это показатель того, что результат стоит того, чтобы за него платить.


Твои личные знакомые -- это настолько репрезентативная выборка, что просто офигеть.  

Зайди на любой программистский сайт без специализации на конкретном языке -- дельфи там если и будет, то на отшибе.


Зачем -- взаимодействие с языками с динамической типизацией. http://en.wikipedia.org/wiki/Comparison_of...namic_languages
Вон, в дельфи LLVM появляется, а там много языков поддерживается. Упрётся ведь в это.


Ты очень интересно разделил плюсы и дельфи -- при том, что по безопасности они примерно в одной весовой категории (арифметика указателей, ручное управление памятью). С преимуществами плюсов всё понятно (RAII, умные указатели и т.п.), хоть ты в них и не веришь. Из преимуществ дельфи в безопасности ты пока смог назвать только то, что ты можешь забыть написать * и вместо передачи по указателю передашь по значению. Аргумент, что работа с Foo и Foo* имеет различный синтаксис, ты проигнорировал, то есть аргумент можно считать нивелированным. Что дальше? Где достоинства дельфи по части запретов на простреливание ноги?

Это сообщение отредактировал(а) Athari - 3.5.2013, 16:36

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


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

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

  Тебя не поймешь, то куча это плохо, потому что медленно, сейчас говоришь, что хотя и медленно, но нифига не критично. Если не критично, значит оправданно, что делфи объекты хранить в куче. На самом деле есть целый слой приложений, которые включают в себя работу с Базами данных или же ведут другую активную работу со строками. Помниться я в свое время делал разбор XML файлов на железке, так вот оптимизация оператора new на самодельный стек дала ускорение в несколько раз. 
  Наверное не все знают, что формы в делфи сериализуются в текстовой форме. Процесс создание формы происходит не так как в QT при помощи сгенерированного кода, а путем разбора XML-подобного текстового файла. 
  На сегодняшний день прикладные программы часто обмениваются по сети некоторой объектной информацией и по большей части это текстовая форма в том или ином виде. И это не говоря о всякого рода отчетах, логах и т.д. Не зря же изобрели GC . Если б все было так хорошо, то не потребовалась бы такая оптимизация. Сборщик мусора не только упрощает работу с памятью, но и оптимизирует процесс выделения и освобождения памяти.

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

@Alexeis


Мои тезисы размазаны по всему топику ровным слоем. Собираю в одном месте:

1. Работа с памятью критична для очень малого числа приложений. Обычно на неё уходит не больше 5%.
2. Работа с кучей медленнее, чем со стеком, если создание и копирование объектов дешёвое.
3. Скорость работы new/delete и GC сопоставима по скорости. GC сам по себе медленнее, но выравнивается за счёт особенностей (асинхронность, дефрагментация и прочие).
4. Дельфи не имеет выделения в стеке, поэтому, когда работа с памятью критична, оптимизировать сложнее.
5. Дельфи не имеет RAII, умных указателей и прочих фич для ручного управления памятью, поэтому оное сложнее, чем в плюсах.
6. Дельфи не имеет сборки мусора, поэтому автоматическое управление памятью сложнее, чем в дотнете.

В целом допускаю, что:
1. Дельфи имеет более оптимизированный менеджер памяти для работы с кучей. (Хотя было бы интересно увидеть реальные числа.)
2. Дельфовые ссылки синтаксически приятнее, чем указатели в плюсах (меньше символов), и мощнее, чем ссылки в плюсах (неконстантны). В шарпе ссылки такие же.

(Белтар, пишу не для тебя. Не надо по новому кругу.)


Если не изменяет память, в бинарниках всё-таки бинарные данные. Что формы в тексте хранятся -- это скорее из-за VCS, diff и прочих инструментов, которые обычно ориентированы на текст.

@Zloxa
@diadiavova



Зачем абстрактные примеры? Вот: https://github.com/markrendle/Simple.Data -- ORM с нулём вспомогательного кода. Все "классы" возникают прямо из БД. Магия dynamic в чистом виде.

в XE4 уже есть и сборщик мусора, и подсчет ссылок 

http://www.gunsmoker.ru/2013/05/modern-delphi.html - статья по изменениям в Delphi (архитектура, строки, ARC, кросс-платформа, устаревающие конструкции), основана на White Paper от Марко Канту. 

  Что ты понимаешь под не имеет выделения в стеке? Массив или строку вполне можно создать в стеке. И даже массив записей. Если очень заморачиватся можно переопределить виртуальную статическую функцию класса выделяющую память и выделять память в своем стеке(но это уже из разряда сложных оптимизаций). 


Это С++ не имеет умных указателей. Они реализуются классами, а делфи как раз имеет 3 встроенных типа умных указателей. Нет автоматического вызова деструкторов для объектов это да.


  Это доступно только в версии Delphi.NET и Delphi Prism. Тут просто 2 варианта. Или иметь возможность работать с памятью при нативной компиляции или вкусняжки дотнета в полном объеме. 


В любом случае даже если в ресурсах они пожимаются бинарно для экономии памяти, то потом все равно разворачиваются в текст, иначе не будет работать RTTI . Если сильно нужно, могу покапать, находил функции для конвертации между представлениями. 

@Akella


Офигеть. Нормальная статья по новой дельфи. Я уж начал сомневаться, что такие существуют.


Интересный пунктик...


Белтар, у строк в дельфи до сих пор преимущество над строками в плюсах?  


Вкратце: ссылки считаются для строк, вариантов, динамических массивов и интерфейсов. В список добавляются объекты, если используется новый компилятор под ARM. Но им никто не пользуется, так как на дельфи под iOS писать невозможно (как только выходишь за рамки hello world -- начинается северный пушной зверёк). То есть можно считать, что счётчика ссылок для объектов нет. Возможно, будет позже, когда LLVM перетащат на остальные платформы. Да и реализация ARC далека от идеала: циклические ссылки не разруливаются. Для избавления от этой проблемы предлагается костыль в виде повсеместного использования атрибута weak (хотя что это атрибут, а не отдельный тип -- это хорошо, синтаксически не так ужасно). И меня сильно смущает, что счётчик используется всегда, то есть нет выбора -- по сути, такой же насильственный прикол, как и с IUnknown во всех интерфейсах. Засорение всего кода ифдефами вида "{$IFDEF AUTOREFCOUNT}", как предлагается в статье -- это вообще печаль, то есть рассчитывать, что все ринутся писать кросс-платформенный код было бы верхом наивности.

Ждать надо. Пока слишком рано говорить о нормальной реализации сборки мусора.

@Alexeis


Выделение экземпляров классов.


По-моему, ты что-то путаешь. Массив записей выделится одним куском, но в куче. Динамический -- точно. Вот запись создастся в стеке.


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


Давай определимся: мы оцениваем реальные возможности языков, а не возможности максимально урезанных языков. В плюсах не встраивают фичи, которые можно вынести в стандартную библиотеку. И эта стандартная библиотека -- неотъемлемая часть языка. Дельфи более монолитна.

Итак. В плюсах умные указатели есть. В дельфи умные указатели реализованы для интерфейсов и нескольких конкретных типов, для экземпляров обычных классов таковых не существует (ARM не в счёт).


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

Что такое Delphi.NET? А то по религиозным выкрикам Белтара я пришёл к выводу, что это неверная платформа, которая делает неверный код.  В Delphi.NET используется тот же язык, те же библиотеки? В чём суть?


Функции для конвертации видел. Но у меня сильные сомнения, что они вызываются при чтении бинарных данных из ресурсов. Кто в здравом уме и трезвой памяти будет гонять картинки bin->hex->bin?

Полный аналог Си





Специально, чтобы знать сколько места выделять есть еще такая функция 
class function InstanceSize: Longint; inline;

А вот и реальный пример переопределения


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


Ну в STL это сравнительно недавно появилось. У меня еще сохранился самописный код Shared_Ptr, который я выискивал на просторах инета. Я до сих пор пишу на VS2005 . Там такого нет. Мы же не рассматриваем в качестве возможностей С++ классы написанные сторонними разработчиками. 


  Это язык на платформе .NET2.0 Имел максимальную совместимость с Delphi for Win32.


  Ща полезу покапаю.

Да, по крайней мере в версии XE2 хотя и есть все эти функции, но они вероятно вызываются всякого рода редакторами, не формой. Форма работает с бинарным форматом, хотя там равно в этом формате название всех полей и их типы хранятся строково, для загрузки через RTTI. Бинарно только значения хранятся. 

Универсальный прокси-класс это конечно здорово, но чем-то это все начинает напоминать COM.



Обычно означает, что вся кухня просто вынесена куда-то на другой уровень.

2 Alexeis:

Можешь, как самый технически подкованный объяснить подробнее?
Вот нам надо как-то размещать объекты не обязательно в куче, просто в памяти. Проблемы 3: сделать побыстрее и может происходить фрагментация памяти, их надо как-то удалять. Как именно GC может помочь по каждому из этих пунктов, а то пока неясно, не для того же чтобы delete не писать его придумали. У Атари это плохо получается.

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


А все, отныне именуем ее "кислород" ибо от Delphi там ничего нет, чисто Паскаль для .NET.



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



Это VCL реализованная на .NET Паскале, абсурдность такого в свете существования WinForms думаю объяснять не надо. Не удивительно, что она быстро издохла, попутно показав, что никаких причин дельфину переходить на .NET не имеется. Не путать с Delphi Prism.



Насколько я понимаю сишники должны аналогичную операцию переопределения new и delete делать влегкую от рождения.