Здравствуйте, OCTAGRAM, Вы писали:
OCT>Во–первых, молотом .NET являются функциональные языки, а вовсе не OCT>Delphi/C++/и т. д. OCT>Противопоставление с C++ и др. — это маркетинговый OCT>ход. Любой лиспер поинтересовался бы, зачем, когда есть сборка мусора, OCT>стековая архитектура? Стек ведь нужен, чтоб с него память эффективно OCT>выделять, простым инкрементом (декрементом на Intel) указателя. В .NET OCT>такой источник памяти уже есть — это куча, зачем тогда стек оставили? OCT>Неоправданная недогрузка мощностей. Но лисперов мало, в целом никто и OCT>ухом не повёл, что стековая архитектура при сборке мусора — это смешно.
stack нужен для value-типов, между прочим.
В Lisp`е нет value-типов, поэтому и надобности в стеке там тоже нет.
Здравствуйте, OCTAGRAM, Вы писали:
>> 5) Программисты дельфи. это самое мрачное. был грешок, работал долгое >> время на поддержке дельфевых прилад. начальнег (мегакрутой спец по >> дельфи и прикладной области), как то с трепетом мне показал >> единственный! юнит, который он сделал, оформив его для повторного >> использования. в юните была одна функция, разбивавшая строку по табам >> вроде. в коде этой функции раз пять в разных местах было сравнение с >> явно прописанной константой символа таб. на мое замечание, почему бы это >> значение не вынести в аргументы и получить более универсальную функцию, >> этот чел сказал — хм, интересная мысль.
OCT>Ну он был не так уж не прав: OCT>http://www.wilshipley.com/blog/2005/02/free-programming-tips-are-worth-every.html OCT>Free Programming Tips are Worth Every Penny
Неплохо описана идея, стоящая за TDD. Другое дело, что неправильно это рассматривать в отрыве от задачи, стоявшей перед разработчиком.
M>>Может, все же почитаешь про наследование, а?
H>Я не первый день живу и прекрасно в этом разбираюсь. К слову, наследование в вопросе "COM не COM" ни при чем совершенно.
Ниже
M>>INonCOMInterface наследуется от IUnknown. Более того (или, вернее, поэтому), INonCOMInterface может быть приведено к IUnknown. Более того, наследование от IUnknown означает, что для INonCOMInterface автоматически становятся доступны три базовых COM-метода: AddRef, Release и QueryInterface (потому что они реализованы в IUnknown)
H>Интерфейс есть декларация. Интерфейс ничего не реализует. Получение IUnknown от INonCOMInterface не делает последний COM'ом. Рассматривать несколько методов INonCOMInterface в отрыве от всего интерфейса -- идеологически неверно, ибо интерфейс есть единица неделимая. Какими словами это еще объяснять
Объясни следующее:
1. Чем отличаются две следующие строчки:
class MyClass : TObject
class MyClass : IUnknown
В первом случае MyClass наследуется от TObject. Во втором?
Если во втором — это тоже наследование, то:
— если родитель является TObject, является ли наследник TObject?
— если родитель является COM-объектом, является ли наследник COM-объектом?
Ключевое слово Interface является всего лишь способом получить множественное наследование от абстрактных классов.
When implementing an interface, you must implementQueryInterface, _AddRef and _Release standard interface methods, unless you base your class on one that already has these implemented, such as TInterfacedObject.
При реализации интерфейсы вы обязаны реализовать стандартные методы QueryInterface, _AddRef and _Release, если ваш класс не будет создан на основе класса, который их уже реализует (примером такого класса может служить TInterfacedObject)
Здравствуйте, _d_m_, Вы писали:
I>>Ну как сказать... а если вместо := да заставят писать assign
___>Если бы у бабушки был х.. она была бы дедушкой.
Типа пошутил?
I>>Вспомни фортрановские LE, GE и как то там LT, кажется.... Как по мне , то гораздо проще <=, >=, <
___>Это ты к чему вообще?
К тому, что синтаксис должен быть, по возможности, немногословным. И одним из недостатков Delphi (сугубо с моей точки зрения) как раз и есть все эти "приколы" типа :=, begin/end, procedure....
Здравствуйте, kuj, Вы писали:
I>>Что значит корректо? Для коннекции в одном случае корректно с ролбэком, а в другом с коммитом
kuj>Не путаешь с транзакцией?
Не путаю. Технически транзакция висит на коннекции
Здравствуйте, Mr.Cat, Вы писали:
MC>Предполагается, что Dispose технически корректно освобождает ресурсы.
Вот как-то не складывается у меня с этим. Не спорю, скорее по незнанию\отсутствию опыта. Но я бы хотел сазать, что, например в С++ такие вещи идеологически чище. Чего стоят деструкторы в шарпе — читаешь документацию и сразу выпить хочется
Если технически корректных способов несколько (как в случае с транзакциями) — то а)Чтобы узнать, что именно выполняет Dispose, читайте документацию к конкретному классу, либо эксперементируйте б)Всегда освобождайте такой ресурс явно (т.е. в случае транзакции делайте явный commit/rollback).
Здравствуйте, Mr.Cat, Вы писали:
MC>В .NET ресурсы, для которых важна детерминированность времени освобождения (файлы, соединения) оборачиваются в объекты, реализующие интерфейс IDisposable (это даже можно считать паттерном). По команде Dispose() объект сразу освобождает ресурс, после чего переходит в состояние Disposed ("я ресурсом уже не владею") и спокойно себе дожидается, пока его соберет GC и освободит все оставшиеся ресурсы (память, в частности).
O! Коннекцией я уже не владею, но на сервере она висит и дожидается когда ее GC грохнет. Кузяво это. Или я неправ?
Здравствуйте, kuj, Вы писали:
kuj>Если ты не понимаешь разницы между памятью и другими ресурсами системы, то это лишь квалифицирует тебя как непрофессионала.
А тебеб не кажется, что для задач не класса 24х7 проблема утечки памяти вообще преувеличена? И уж тем более он менее важна, чем проблема некорректного освобождения других ресурсов. Так что hattab во многом прав. А учитывая, что на шарпе пишут не только профессионалы понимающие разницу межде памятью и файлом последствия неправильного освобождения ресурсов могут быть очень разрушительными
M>>Может, все же почитаешь про наследование, а?
H>Я не первый день живу и прекрасно в этом разбираюсь. К слову, наследование в вопросе "COM не COM" ни при чем совершенно.
Ниже
M>>INonCOMInterface наследуется от IUnknown. Более того (или, вернее, поэтому), INonCOMInterface может быть приведено к IUnknown. Более того, наследование от IUnknown означает, что для INonCOMInterface автоматически становятся доступны три базовых COM-метода: AddRef, Release и QueryInterface (потому что они реализованы в IUnknown)
H>Интерфейс есть декларация. Интерфейс ничего не реализует. Получение IUnknown от INonCOMInterface не делает последний COM'ом. Рассматривать несколько методов INonCOMInterface в отрыве от всего интерфейса -- идеологически неверно, ибо интерфейс есть единица неделимая. Какими словами это еще объяснять
Объясни следующее:
1. Чем отличаются две следующие строчки:
class MyClass : TObject
class MyClass : IUnknown
В первом случае MyClass наследуется от TObject. Во втором?
Если во втором — это тоже наследование, то:
— если родитель является TObject, является ли наследник TObject?
— если родитель является COM-объектом, является ли наследник COM-объектом?
Ключевое слово Interface является всего лишь способом получить множественное наследование от абстрактных классов.
When implementing an interface, you must implementQueryInterface, _AddRef and _Release standard interface methods, unless you base your class on one that already has these implemented, such as TInterfacedObject.
При реализации интерфейсы вы обязаны реализовать стандартные методы QueryInterface, _AddRef and _Release, если ваш класс не будет создан на основе класса, который их уже реализует (примером такого класса может служить TInterfacedObject)
gandjustas пишет: > А вопросы быстродействия и эффективного рахода памяти?
А этим уже должен заниматься оптимизатор.
> Тем более на уровне машинного кода стек есть, зачем пытаться скрыть этот > факт?
А управление памятью .NET не скрывает? А ведь оно тоже есть на машинном
уровне.
kuj пишет: > Кстати, в Delphi в свое время сильно раздражал "не целостный" интерфейс, > где каждое окно само по себе. Но это так — дело вкуса.
Да, без Expose это не удобно
lifrsdn пишет: > Здравствуйте, goto, Вы писали: > > G>Здравствуйте, Niemand, Вы писали: > > N>>4. "Закон один для всех". В делфи часто встречаются исключения. > Например writeln — чуть ли не единственная функция, куда можно передать > переменное к-во параметров. А вот простым смертным — низза. Похожая > ситуация с массивами. > > G>Занудствую . writeln — не ф-я, а оператор языка с переменным числом > операндов (по кр. мере в "чистом" Паскале). Ну и разбирается там все на > этапе компиляции, а не в ран-тайме. > > Продолжим занудствовать. Как с помощью этого оператора языка (очень > похожего на функцию ) можно единообразно вывести в файл, в память, в > отладочный вывод, в консоль, в сокет, в что-то только что придуманное? В > С++ это можно сделать, что дописывая варианты printf, что наследуя > ostream. Все операции будут единоообразны. Да 1 и та же функция это > может делать.
Вообще, в Borland оставлены ниточки, чтобы инициализировать "File"
своими методами Read/Write/Flush/Close. Но на практике работают чаще с
TStream, просто используют функции–форматтеры.
WriteLn применительно к Borland — это рудимент. Выкинуть они его не
могут, но и язык не подстраивают, чтобы можно было свою магию
компилятора творить.
Здравствуйте, iyura, Вы писали:
kuj>>Если ты не понимаешь разницы между памятью и другими ресурсами системы, то это лишь квалифицирует тебя как непрофессионала.
I>А тебеб не кажется, что для задач не класса 24х7 проблема утечки памяти вообще преувеличена? И уж тем более он менее важна, чем проблема некорректного освобождения других ресурсов. Так что hattab во многом прав. А учитывая, что на шарпе пишут не только профессионалы понимающие разницу межде памятью и файлом последствия неправильного освобождения ресурсов могут быть очень разрушительными
Ты расскажи это тем, у кого проект "встает" из-за трудноуловимых утечек на недели, если не месяцы. При чем это не плод моего воображения, а вполне реальный факт из моей практики... Правда, случившийся не со мной лично, а в соседнем отделе, которые занимались разработкой на Delphi (год этак 2001-2002).
Niemand пишет: > 4. "Закон один для всех". В делфи часто встречаются исключения. Например > writeln — чуть ли не единственная функция, куда можно передать > переменное к-во параметров. А вот простым смертным — низза.
Чисто для полноты:
Можно:
а) функцию с varargs; напрямую объявить нельзя, но можно объявить такой
тип, объявить функцию (без varargs; но с cdecl, и сделать небезопасное
приведение типа. Ну и с помощью других хаков это реализовать уже.
Возможно, получится экспортировать функцию, а потом импортировать её же,
но уже с varargs;. Я пробовал только первый вариант, да и функция там
была на асме.
Будет такая же поддержка varargs, как и в C, без знания кол–ва и типов
аргументов.
б) Можно устроить свою реализацию IDispatch для OLEVariant и чего–то ещё
для просто Variant. Я работал только с OLEVariant. Несложный объект,
печатает все вызовы, с которыми к нему обращаются.
Есть знание кол–ва и типов аргументов, но это всегда будет выглядеть как
вызов метода, а не отдельная процедура. В with использовать OLEVariant и
Variant нельзя. По понятным соображениям.
Но обычно всё же array of const делают.
--
ISO/IEC 8652:1995/Amd 1:2007
Здравствуйте, iyura, Вы писали:
MC>>В .NET ресурсы, для которых важна детерминированность времени освобождения (файлы, соединения) оборачиваются в объекты, реализующие интерфейс IDisposable (это даже можно считать паттерном). По команде Dispose() объект сразу освобождает ресурс, после чего переходит в состояние Disposed ("я ресурсом уже не владею") и спокойно себе дожидается, пока его соберет GC и освободит все оставшиеся ресурсы (память, в частности).
I>O! Коннекцией я уже не владею, но на сервере она висит и дожидается когда ее GC грохнет. Кузяво это. Или я неправ?
Стандартная практика использования IDbConnection в .NET — in-place. То есть по принципу открываем, выполнеяем CRUD операцию(и), закрываем (возвращаем в пул подключений). Даже если забыть закрыть, объект подключения почти тут же станет кандидатом на сборку, так как выйдет за scope. Аналогично с файлами.
При чем в отличии от Delphi все проще и читабельней благодаря оператору using — отпадает необходимость явно делать try finally.
Здравствуйте, kuj, Вы писали:
MC>>>В .NET ресурсы, для которых важна детерминированность времени освобождения (файлы, соединения) оборачиваются в объекты, реализующие интерфейс IDisposable (это даже можно считать паттерном). По команде Dispose() объект сразу освобождает ресурс, после чего переходит в состояние Disposed ("я ресурсом уже не владею") и спокойно себе дожидается, пока его соберет GC и освободит все оставшиеся ресурсы (память, в частности).
I>>O! Коннекцией я уже не владею, но на сервере она висит и дожидается когда ее GC грохнет. Кузяво это. Или я неправ?
kuj>Стандартная практика использования IDbConnection в .NET — in-place. То есть по принципу открываем, выполнеяем CRUD операцию(и), закрываем (возвращаем в пул подключений). Даже если забыть закрыть, объект подключения почти тут же станет кандидатом на сборку, так как выйдет за scope. Аналогично с файлами.
kuj>При чем в отличии от Delphi все проще и читабельней благодаря оператору using — отпадает необходимость явно делать try finally.
Забыл упомянуть, что для доступа к БД фактически повсеместно используются O/RM, которые сами заботятся о подключениях. Единственное, где надо помнить о using — для TransactionScope`ов.
Здравствуйте, iyura, Вы писали:
I>>>Что значит корректо? Для коннекции в одном случае корректно с ролбэком, а в другом с коммитом
kuj>>Не путаешь с транзакцией?
I>Не путаю. Технически транзакция висит на коннекции
Тем не менее, не следует ассоциировать закрытие коннэкшн с логикой коммит/роллбэк транзакции. Когда требуется эта логика, то следует явно управлять транзакцией.
Здравствуйте, kuj, Вы писали: kuj>Здравствуйте, ironwit, Вы писали: kuj>>>Мне нужно нажать только =, в то время как тебе в Delphi — зажать shift, нажать 6, отжать shift, нажать = и это для, пожалуй, наиболее используемого оператора... I>>shift+Ж в англ раскладке? : kuj>Почему я должен помнить какая у меня там активная раскладка, если все что мне нужно, это ввести оператор присваивания?
Ну как дети, ей богу... Почему вообще нужно что-то там помнить, если компьютер и так все должен сам знать?
Здравствуйте, iyura, Вы писали:
MC>>Предполагается, что Dispose технически корректно освобождает ресурсы.
I>Вот как-то не складывается у меня с этим. Не спорю, скорее по незнанию\отсутствию опыта. Но я бы хотел сазать, что, например в С++ такие вещи идеологически чище. Чего стоят деструкторы в шарпе — читаешь документацию и сразу выпить хочется
Явное использование деструкторов в управляемой среде в 95% случаев моветон.
, и сделать небезопасное 
