Здравствуйте, OCTAGRAM, Вы писали:

>> А вопросы быстродействия и эффективного рахода памяти?
OCT>А этим уже должен заниматься оптимизатор.
Так он и занимается этим. Если бы не было стека, а была только куча, то какая бы тут могла быть оптимизация?

Здравствуйте, Mamut, Вы писали:

M>1. Чем отличаются две следующие строчки:
M>

M>class MyClass : TObject

M>class MyClass : IUnknown
M>

M>В первом случае MyClass наследуется от TObject. Во втором?
M>Если во втором — это тоже наследование, то:
M>- если родитель является TObject, является ли наследник TObject?
M>- если родитель является COM-объектом, является ли наследник COM-объектом?

Все верно только следует понимать, что интерфейс может быть унаследован только интерфейсом, а класс реализует (implement) интерфейс. Но это так.. вопрос терминологии.

Здравствуйте, FractalizeR, Вы писали:

FR>Здравствуйте, kuj, Вы писали:
kuj>>Здравствуйте, ironwit, Вы писали:
kuj>>>>Мне нужно нажать только =, в то время как тебе в Delphi — зажать shift, нажать 6, отжать shift, нажать = и это для, пожалуй, наиболее используемого оператора...
I>>>shift+Ж в англ раскладке? :
kuj>>Почему я должен помнить какая у меня там активная раскладка, если все что мне нужно, это ввести оператор присваивания?

FR>Ну как дети, ей богу... Почему вообще нужно что-то там помнить, если компьютер и так все должен сам знать?

Что именно компьютер должен знать? ^= упс...

M>>1. Чем отличаются две следующие строчки:
M>>

M>>class MyClass : TObject

M>>class MyClass : IUnknown
M>>

M>>В первом случае MyClass наследуется от TObject. Во втором?
M>>Если во втором — это тоже наследование, то:
M>>- если родитель является TObject, является ли наследник TObject?
M>>- если родитель является COM-объектом, является ли наследник COM-объектом?

kuj>Все верно только следует понимать, что интерфейс может быть унаследован только интерфейсом, а класс реализует (implement) интерфейс. Но это так.. вопрос терминологии.


ну это да. В дельфи интерфейсами банальные абстрактные классы обозваны

hattab пишет:
> У Delphi 2006 офигительно быстрый менеджер памяти.

Я помню, один раз хорошо сэкономил своей команде время на кодинг,
дописав type String = String[255] в начале, без этого не проходило по
времени. А время в разы отличается, как ни крути.

--
ISO/IEC 8652:1995/Amd 1:2007

kuj пишет:
> Здравствуйте, OCTAGRAM, Вы писали:
>
>> > А вопросы быстродействия и эффективного рахода памяти?
> OCT>А этим уже должен заниматься оптимизатор.
> Так он и занимается этим. Если бы не было стека, а была только куча, то
> какая бы тут могла быть оптимизация?
На уровне семантики был бы спагетти стек, расположенный на куче. А при
исполнении был бы уже двойной стек+куча или что там оптимизатор придумает.

--
ISO/IEC 8652:1995/Amd 1:2007

hattab пишет:
> OCT>Delphi 2007?
>
> C 2005.

> OCT>тоже 2007? в 2006 не помню такого
>
> С 2005

А это точно не .NET всё?

--
ISO/IEC 8652:1995/Amd 1:2007

_d_m_ пишет:
> А теперь ты смотри: у нас есть сначала компилятор в байт код, у него
> есть времени столько, сколько понадобиться, никакаких ограничений не
> накладывается, чтобы произвести оптимизированный байт код. А потом этот
> код берет жит компилер и оптимизирует под конкретные: процессор/много
> процессоров/архитектуру (32/64)/ОС/объем ОЗУ. Хотя время на жит
> компиляцию конечно тратиться. Ну теперь яволь?
АФАИК профайлер+JIT оптимизация работают только на словах. Пока что это
успешно не применяется.

--
ISO/IEC 8652:1995/Amd 1:2007

Здравствуйте, kuj, Вы писали:

kuj>Ты расскажи это тем, у кого проект "встает" из-за трудноуловимых утечек на недели, если не месяцы. При чем это не плод моего воображения, а вполне реальный факт из моей практики... Правда, случившийся не со мной лично, а в соседнем отделе, которые занимались разработкой на Delphi (год этак 2001-2002).

Возможно. Но проекты встают не только из-за утечек памяти. Но еще раз повторюсь — в большинстве случаев ИМХО проблема утечки сильно преувеличена. Из своего немалого опыта работы на С++ могу сказать, что с утечками сталкивался редко, ну, а аот так, чтобы из-за утечки что-то рушилось.... не припомню.

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

Здравствуйте, OCTAGRAM, Вы писали:

OCT>АФАИК профайлер+JIT оптимизация работают только на словах. Пока что это
OCT>успешно не применяется.
Применяется в HotSpot JVM. Но пока очень робко и застенчиво..

Здравствуйте, kuj, Вы писали:

kuj>>Стандартная практика использования IDbConnection в .NET — in-place. То есть по принципу открываем, выполнеяем CRUD операцию(и), закрываем (возвращаем в пул подключений). Даже если забыть закрыть, объект подключения почти тут же станет кандидатом на сборку, так как выйдет за scope. Аналогично с файлами.

Мы ведь говорим о "не совсем правильном" стиле программирования. Ясен пень, что если все делать аккуратно, то и проблем не будет. Но степень аккуратности зависит не от наличия управляемой среды, а от наличия мозгов. Я, собственно, об этом

kuj>>При чем в отличии от Delphi все проще и читабельней благодаря оператору using — отпадает необходимость явно делать try finally.

А вот как себя поведет

try
{
    using(obj )
    {
        если тут облом с obj
    }
}
catch(...........)
{
   тут хочу рассказать об обломе с obj
}

kuj>Забыл упомянуть, что для доступа к БД фактически повсеместно используются O/RM, которые сами заботятся о подключениях. Единственное, где надо помнить о using — для TransactionScope`ов.

Весьма спорно.

Здравствуйте, kuj, Вы писали:

kuj>Тем не менее, не следует ассоциировать закрытие коннэкшн с логикой коммит/роллбэк транзакции. Когда требуется эта логика, то следует явно управлять транзакцией.

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

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, iyura, Вы писали:

MC>>>Предполагается, что Dispose технически корректно освобождает ресурсы.

I>>Вот как-то не складывается у меня с этим. Не спорю, скорее по незнанию\отсутствию опыта. Но я бы хотел сазать, что, например в С++ такие вещи идеологически чище. Чего стоят деструкторы в шарпе — читаешь документацию и сразу выпить хочется

kuj>Явное использование деструкторов в управляемой среде в 95% случаев моветон.

Вот и я о том же. А ведь деструктор это

— централизованное место, где происходит разрушение объекта ( не будем вдаваться в рантайм и тонкости компиляторов)
— четкие правила, когда деструктор вызывается.

Как сладствие — более четкое управление ресурсами

Здравствуйте, OCTAGRAM, Вы писали:

OCT>gandjustas пишет:
>> А вопросы быстродействия и эффективного рахода памяти?
OCT>А этим уже должен заниматься оптимизатор.

>> Тем более на уровне машинного кода стек есть, зачем пытаться скрыть этот
>> факт?
OCT>А управление памятью .NET не скрывает? А ведь оно тоже есть на машинном
OCT>уровне.
Ничего не путаешь?

Здравствуйте, iyura, Вы писали:
I>А тебеб не кажется, что для задач не класса 24х7 проблема утечки памяти вообще преувеличена?

А Вы считаете, что .NET не предназначен для разработки систем 24х7?

Здравствуйте, iyura, Вы писали:

I>А вот как себя поведет
I>

I>try
I>{
I>    using(obj )
I>    {
I>        если тут облом с obj
I>    }
I>}
I>catch(...........)
I>{
I>   тут хочу рассказать об обломе с obj
I>}
I>

Надо проверить, но скорее всего Вы попадете в catch с obj в состоянии Disposed (если, конечно, эксепшн не в Dispose вылетел).

Здравствуйте, iyura, Вы писали:
I>O! Коннекцией я уже не владею, но на сервере она висит и дожидается когда ее GC грохнет. Кузяво это. Или я неправ?

Нет. Предполагается, что Dispose корректно закроет соединение.

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, iyura, Вы писали:
I>>А тебеб не кажется, что для задач не класса 24х7 проблема утечки памяти вообще преувеличена?

MC>А Вы считаете, что .NET не предназначен для разработки систем 24х7?

Нет, я этого не говорил. Я считаю, что для таких систем и проектирования и кодирование и тестирование должно быть на порядок качественнее. А это уже никакого отношения с .Net/Java/Delphi/C++.... не имеет

koandrew пишет:
> Цифр у меня нет и не будет, ибо нет дельфей. Но в отличие от некоторых у
> меня есть логика, которая подсказывает мне, что инлайнинг коротких
> функций даст прирост производительности, особенно если эти короткие
> ф-ции вызываются часто...
Но не в этом случае. IntfClear вызывает другой метод, IUnknown._Release.
IUnknown._Release при этом может быть заглушкой, вызывающей настоящую
реализацию _Release. Эта реализация, в свою очередь, уменьшает счётчик
ссылок, и, если он 0, то вызывает свой финализатор. Который, в свою
очередь...

Инлайн IntfClear глобально ничего не решает.

--
ISO/IEC 8652:1995/Amd 1:2007

gandjustas пишет:
> В C# подобный код утечек не вызовет.
В C# подобный код не напишешь

--
ISO/IEC 8652:1995/Amd 1:2007