Постоянно читая RSDN имел возможность неоднократно убедиться что большинство участников сильно не любят Delphi. Уж очень стало интересно, а за что собственно?
Сам я от большого программинга уже отошел, хотя по прежнему могу считать себя профессионалом Delphi и ASM. И у меня приактически никогда не возникало проблем из-за каких-то ограничений языка. Я с уверенностью могу сказать, что могу написать на нем абсолютно все что угодно в рамках имеющихся API и математических моделей. При этом практически никогда не приходится изобретать велосипедов и извращаться чтобы обойти ограничения языка или стандартных библиотек. В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин?
Во время пика своей популярности Delphi занимал ту нишу, которыю ныне занимают управляемые языки программирования. Выходит что позиционирование у него верное, неужели всм оказалась так нужна эта управляемость кода? Кстати, сборка мусора для некоторых типов данных (строки и динамические массивы) у Delphi была уже тогда.
Или может вам не нравиься Pascal? Но из других ваших сообщений явно следует что синтаксис -- это вторичное, да и наездов на него я вроде как не видел...
Просветите плиз вашу точку зрения, только объективно. Сетования на многомилионную армию малограмотных формоклепальщиков не принимаются, это не есть свойство языка или среды разработки.
Здравствуйте, misha_irpen, Вы писали:
_>Постоянно читая RSDN имел возможность неоднократно убедиться что большинство участников сильно не любят Delphi. Уж очень стало интересно, а за что собственно?
_>Сам я от большого программинга уже отошел, хотя по прежнему могу считать себя профессионалом Delphi и ASM. И у меня приактически никогда не возникало проблем из-за каких-то ограничений языка. Я с уверенностью могу сказать, что могу написать на нем абсолютно все что угодно в рамках имеющихся API и математических моделей. При этом практически никогда не приходится изобретать велосипедов и извращаться чтобы обойти ограничения языка или стандартных библиотек. В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин?
_>Во время пика своей популярности Delphi занимал ту нишу, которыю ныне занимают управляемые языки программирования. Выходит что позиционирование у него верное, неужели всм оказалась так нужна эта управляемость кода? Кстати, сборка мусора для некоторых типов данных (строки и динамические массивы) у Delphi была уже тогда.
_>Или может вам не нравиься Pascal? Но из других ваших сообщений явно следует что синтаксис -- это вторичное, да и наездов на него я вроде как не видел...
_>Просветите плиз вашу точку зрения, только объективно. Сетования на многомилионную армию малограмотных формоклепальщиков не принимаются, это не есть свойство языка или среды разработки.
Ну лично мне не нравится глючность IDE. 5-я вроде как самая стабильная была...
Здравствуйте, misha_irpen, Вы писали:
_>Постоянно читая RSDN имел возможность неоднократно убедиться что большинство участников сильно не любят Delphi. Уж очень стало интересно, а за что собственно?
Не знаю как другим, но мне не нравится:
1.
Здравствуйте, misha_irpen, Вы писали:
_>Сам я от большого программинга уже отошел, хотя по прежнему могу считать себя профессионалом Delphi и ASM. И у меня приактически никогда не возникало проблем из-за каких-то ограничений языка. Я с уверенностью могу сказать, что могу написать на нем абсолютно все что угодно в рамках имеющихся API и математических моделей. При этом практически никогда не приходится изобретать велосипедов и извращаться чтобы обойти ограничения языка или стандартных библиотек.
На делфи, как и на асме можно сделать все. Ибо и тот и другой полны по тьюрингу. Остальные языки также полны по тьюрингу.
_>В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин?
Автоматическая сборка мусора.
_>Во время пика своей популярности Delphi занимал ту нишу, которыю ныне занимают управляемые языки программирования. Выходит что позиционирование у него верное, неужели всм оказалась так нужна эта управляемость кода?
Просто Delphi был единственным инструментом ПРОСТОЙ визуальной разработки. То есть не требовались знания C\C++ и WinAPI, чтобы сделать более-менее рабочее приложение.
_>Кстати, сборка мусора для некоторых типов данных (строки и динамические массивы) у Delphi была уже тогда.
Это не преимущество, а попытка скрыть недостатки.
_>Или может вам не нравиься Pascal? Но из других ваших сообщений явно следует что синтаксис -- это вторичное, да и наездов на него я вроде как не видел...
Да, синтаксис паскаля многословный очень. Особенно бесило Procedure и Function. Это все при том, что почти не было поддержки со cтороны IDE.
_>Просветите плиз вашу точку зрения, только объективно. Сетования на многомилионную армию малограмотных формоклепальщиков не принимаются, это не есть свойство языка или среды разработки.
Недостатки
1)ссылочная обьектная модель в отсутствии сборщика мусора. надо явно вызывать Free для каждого объекта, что многие забывают. В С++ с этим проще, визуально несложно проверить парность new и delete. В деляфх гораздо сложнее из-за синтаксиса вызова конструктора. В С# вообще такой проблемы нет.
2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля)
3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля)
4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля)
5)Ужасная работа с указателями. (наследие паскаля)
6)Невнятная библиотека ввода-вывода (на самом деле несколько возможностей осуществлять IO, несовместимых междц собой).
7)Практически полное отсутствие контейнерной библиотеки
8)Большенство классов являются неочень качественными обертками над WinAPI.
9)Исполняемые файлы получаются очень тяжеловесными.
1. Автоматического вызова деструктров. Обязательности вызовов конструкторов.
2. Шаблонов. И после них весь хвост в виде контейнеров, алгоритмов...
3. Давно не писал на дельфи, но оптимизатор у ранних версий был несравним с intel c++. Не знаю как сейчас.
Что хотелось бы иметь:
1. Объявление переменных в месте использования. Не критично, но ползти в var неприятно.
2. Переопределяемых операторов. Часто сложная математика выглядит с ними привычнее.
3. Вынесу отдельно — возможности построения типов с поведением, как у стандартных.
4. Препроцессор. Да его ругают, но лучше иметь возможность его использовать.
_>Во время пика своей популярности Delphi занимал ту нишу, которыю ныне занимают управляемые языки программирования. Выходит что позиционирование у него верное, неужели всм оказалась так нужна эта управляемость кода? Кстати, сборка мусора для некоторых типов данных (строки и динамические массивы) у Delphi была уже тогда.
Во время пика Дельфи был и правда на высоте. Просто потом он сильно протормозил и выскочили Microsoft с .NET (в нише виндовых приложений). Ну а про веб я вообще молчу...
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, vitaly_spb, Вы писали:
_>Во время пика Дельфи был и правда на высоте. Просто потом он сильно протормозил и выскочили Microsoft с .NET (в нише виндовых приложений). Ну а про веб я вообще молчу...
Ну если учесть что Delphi и C# создал один человек, то закат делфи — вещь совсем неудивительная
Здравствуйте, misha_irpen, Вы писали:
_>Во время пика своей популярности Delphi занимал ту нишу, которыю ныне занимают управляемые языки программирования.
Это далеко не так. Точнее только от части так.
_>Выходит что позиционирование у него верное, неужели всм оказалась так нужна эта управляемость кода? Кстати, сборка мусора для некоторых типов данных (строки и динамические массивы) у Delphi была уже тогда.
Делфи — низкоуровневый довольно примитивный императивный язык. Это не значит, что были задачи в его нише, которые нельзя было решить, но их решение было куда более сложным.
Нелюбовь к Делфи в первую очередь была обусловлена низким порогом вхождения. Я имею в виду, что было написано очень много низкокачественного кода. Масса любителей покидать компонентики на формочку, прописать пару обработчиков событий и гордо выпятить грудь мол — вот смотри какой я классный БЛОКНОТ написал!
Про ляпы и опусы типа возможности создать абстрактный тип данных я лучше вообще промолчу.
Здравствуйте, gandjustas, Вы писали:
G>Недостатки G>1)ссылочная обьектная модель в отсутствии сборщика мусора. надо явно вызывать Free для каждого объекта, что многие забывают. В С++ с этим проще, визуально несложно проверить парность new и delete. В деляфх гораздо сложнее из-за синтаксиса вызова конструктора. В С# вообще такой проблемы нет.
В C++ проще/лучше благодаря повсеместному использованию smart pointer`ов.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, gandjustas, Вы писали:
G>>Недостатки G>>1)ссылочная обьектная модель в отсутствии сборщика мусора. надо явно вызывать Free для каждого объекта, что многие забывают. В С++ с этим проще, визуально несложно проверить парность new и delete. В деляфх гораздо сложнее из-за синтаксиса вызова конструктора. В С# вообще такой проблемы нет.
kuj>В C++ проще/лучше благодаря повсеместному использованию smart pointer`ов.
Да даже не в этом дело. В C++ можно вернуть из метода экземпляр класса. В делфи нельзя. Ибо экземпляр — это ссылка, для которой явно надо вызвать Free.
kuj>Нелюбовь к Делфи в первую очередь была обусловлена низким порогом вхождения. Я имею в виду, что было написано очень много низкокачественного кода. Масса любителей покидать компонентики на формочку, прописать пару обработчиков событий и гордо выпятить грудь мол — вот смотри какой я классный БЛОКНОТ написал!
Это правда, кода много, а качества мало. MS Framework в этом смысле отличное решение, но на написание такого монстра очень много ресурсов надо было выложить, на что Борланд не хватило бы просто...
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, kuj, Вы писали:
kuj>Нелюбовь к Делфи в первую очередь была обусловлена низким порогом вхождения. Я имею в виду, что было написано очень много низкокачественного кода. Масса любителей покидать компонентики на формочку, прописать пару обработчиков событий и гордо выпятить грудь мол — вот смотри какой я классный БЛОКНОТ написал!
По своему опыту скажу, что низкокачественного кода было написано дохрена и больше, чем высококачественного, не зависимо от платформы.
Здравствуйте, int64, Вы писали:
I>По своему опыту скажу, что низкокачественного кода было написано дохрена и больше, чем высококачественного, не зависимо от платформы.
Во всех программах на делфи, которые я видел, были утечки памяти. Для Java и .NET такого быть не может
Здравствуйте, gandjustas, Вы писали:
G>Да даже не в этом дело. В C++ можно вернуть из метода экземпляр класса. В делфи нельзя. Ибо экземпляр — это ссылка, для которой явно надо вызвать Free.
Почему нельзя, можно конечно.
function TSameObject.CreateStringList: TStringList;
begin
Result := TStringList.Create;
end;
Здравствуйте, gandjustas, Вы писали:
G>Недостатки G>1)ссылочная обьектная модель в отсутствии сборщика мусора. надо явно вызывать Free для каждого объекта, что многие забывают. В С++ с этим проще, визуально несложно проверить парность new и delete. В деляфх гораздо сложнее из-за синтаксиса вызова конструктора. В С# вообще такой проблемы нет.
знаешь, нормальный дельфист сразу видет парные Create/Free. Приемущество c++ в том, что в нем объекты на стеке могут распологаться..
G>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля)
интерфейсы есть уже лет 10, наверно...
G>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля) G>4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля)
хм. ранние — это какие?? такое ощущение, что ты знаешь только о delphi1
G>5)Ужасная работа с указателями. (наследие паскаля)
Что значит "ужасная" ??? Или строгая типизация тя не устраивает???
G>6)Невнятная библиотека ввода-вывода (на самом деле несколько возможностей осуществлять IO, несовместимых междц собой).
то есть в с++ — только один способ ввода/вывода??
G>7)Практически полное отсутствие контейнерной библиотеки G>8)Большенство классов являются неочень качественными обертками над WinAPI.
в чем конкретно некачественность?? ТОка не надо описывать конкретные глюки отдельных компонентов, такие вещи есть в любой библиотреке классов. В чем некачественность на уровне Classes.pas/Controls.pas/Forms.pas ??
G>9)Исполняемые файлы получаются очень тяжеловесными.
Хм. Ну давай я статически слинкую mfc exe'шник и сбилжу пустую форму на дельфи с ран-тайм пакетамм — и скажу MSVC — генериит очень тяжеловесные экзешники.
G>Я могу продолжить, но думаю этого хватит.
В принципе этого хватит. Уже видно, что все твои знания о дельфи почерпнуты из холли-варов на рсдн..
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, int64, Вы писали:
I>>По своему опыту скажу, что низкокачественного кода было написано дохрена и больше, чем высококачественного, не зависимо от платформы.
G>Во всех программах на делфи, которые я видел, были утечки памяти. Для Java и .NET такого быть не может
хм. прочем тут дельфи? Утечки памяти были, есть и будут во всех языках без GC
G>>Во всех программах на делфи, которые я видел, были утечки памяти. Для Java и .NET такого быть не может
J>хм. прочем тут дельфи? Утечки памяти были, есть и будут во всех языках без GC
Если в программе вместо буков вопросительные знаки — значит она написана на Дельфи.
Не нравится Дельфи из за типично чрезвычайно низкого качества написанных на ней программ. Троечники собирают на этом небезопасном языке свои компоненты из компонентов написанных другими троечники, а конечные программы являются результатом нескольких итераций этого процесса.
Здравствуйте, serg baburin, Вы писали:
SB>Здравствуйте, misha_irpen, Вы писали:
_>>Постоянно читая RSDN имел возможность неоднократно убедиться что большинство участников сильно не любят Delphi. Уж очень стало интересно, а за что собственно? SB>Не знаю как другим, но мне не нравится: SB>1. SB>
SB>:=
SB>
А по моему, так все правильно. По идее семантика оператора сравнения должна отличаться от оператора присваивания.
SB>2. SB>
SB>begin
SB>end
SB>
Ну да, несколько громоздко. Особено для тех, кто избалован С-подобным синтаксисом.
Здравствуйте, gandjustas, Вы писали:
_>>В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин? G>Автоматическая сборка мусора.
И неконтролируемая... Из-за которой, порой, возникают прелесные фризы на ровном месте.
G>Просто Delphi был единственным инструментом ПРОСТОЙ визуальной разработки. То есть не требовались знания C\C++ и WinAPI, чтобы сделать более-менее рабочее приложение.
Далеко не единственным (были уже и Симантеки с их визуальщиной). Он планировался (изначально), как VB-killer. Но концептуально несравнимо выше.
_>>Кстати, сборка мусора для некоторых типов данных (строки и динамические массивы) у Delphi была уже тогда. G>Это не преимущество, а попытка скрыть недостатки.
Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток? Я еще добавлю, что Delphi и за интерфейсами сама следит.
G>Да, синтаксис паскаля многословный очень. Особенно бесило Procedure и Function. Это все при том, что почти не было поддержки со cтороны IDE.
Чет я не понял... Чего тебе IDE должна поддерживать в процедуре или функции?
G>1)ссылочная обьектная модель в отсутствии сборщика мусора. надо явно вызывать Free для каждого объекта, что многие забывают. В С++ с этим проще, визуально несложно проверить парность new и delete. В деляфх гораздо сложнее из-за синтаксиса вызова конструктора. В С# вообще такой проблемы нет.
Уж и не знаю кому сложнее, но старому Паскалисту сильно проще чем в C++
G>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля)
Интерфейсы есть с очень древней (3/4) версии. А в шарпе делегирование оных есть уже?
G>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля)
Дженерики есть в 2007 под .Net. В 2008 обещают и для нативного кода.
G>4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля)
Перегрузка функций/методов есть с 4 версии. Операторы можно перегружать уже с 2005 (для классов только под .Net, для натива можно перегружать для advanced records (class-like)). А с 2006 есть еще и перегружаемые свойства-массивы. Можно еще добавить class/record хелперы.
G>5)Ужасная работа с указателями. (наследие паскаля)
Конкретика? Типизация указателей имеется со времен... очень давно в общем имеется. Адресная арифметика на уровне. Чего не нравится?
G>6)Невнятная библиотека ввода-вывода (на самом деле несколько возможностей осуществлять IO, несовместимых междц собой).
Чудесная библиотека ввода/вывода (позволяющая при умении заворачивать интереснейшие вещи без участия низкоуровневых API).
G>7)Практически полное отсутствие контейнерной библиотеки
Списки (различные), стеки, очереди, бит-контейнеры, ассоциативные массивы. Мало?
G>8)Большенство классов являются неочень качественными обертками над WinAPI.
Мы сегодня что-нибудь конкретное услышим уже?
G>9)Исполняемые файлы получаются очень тяжеловесными.
Скомпиль с пакетами в Delphi, или в статике с MFC (или присовокупи .Net FW, JVM). Потом сравнивай.
G>Я могу продолжить, но думаю этого хватит.
И вправду можешь не продолжать... Ты явно не в теме (ну, или сильно субъективен, что аж перекашивает).
Здравствуйте, Don Reba, Вы писали:
DR>Не нравится Дельфи из за типично чрезвычайно низкого качества написанных на ней программ.
А мне не нравится краска в балончиках, из-за типично чрезвычайно низкого качества художественных и даже литературных произведений воспроизводимых при участии оной на стенах и заборах.
Здравствуйте, hattab, Вы писали:
H>А мне не нравится краска в балончиках, из-за типично чрезвычайно низкого качества художественных и даже литературных произведений воспроизводимых при участии оной на стенах и заборах.
Правильные балончики для заборов проверяют орфографию.
Паскаль был придуман как учебный язык для изучения основ программирования. Прежде всего из-за этого он приобрел популярность, и его уже потом Борланд (собственно и выросший, насколько помню, на Турбо Паскале) стал его развивать как промышленный. На Дельфи не работал, но в свое время мне Турбо Паскаль не нравился своей эклектичностью: на язык, изначально придуманный только для обучения, не для разработки, стали искуственно навешивать необходимую функциональность и модные фичи. Но это все эмоции. Понятно, что на Паскале можно писать.
Раньше на Паскаль смотрели без уважения и нехорошо из-за нестандартности, отсутствия кроссплатформенности и вообще минимальной переносимости. Для меня лично, например, программирование на Паскале только из-за этого вообще не имело смысла. Я подозреваю, что в "серьезных местах" для разработки "серьезных приложений" Дельфи используют очень редко.
И ведь среда по подходу не хакерская ни разу. Формочки там всякие, драг-н-дропы. Несерьезно .
Не знаю как сейчас, но на Дельфи еще недавно учили толпы студентов и школьников (а какая альтернатива? Бэйсик?). Учили очень часто низкокачественно. Одно время действительно гуляло большое количество "крутых программистов на Дельфи", которые веселили искушенную публику разными штуками, и кодом. По личным ощущениям массово стали нормально учить программированию только последние несколько лет, и в серьезных местах преподают уже не Дельфи (если что, поправьте, пож-та, кто ближе к образованию).
Кто знаком с "рынком" Дельфи-программистов в СНГ и в мире? Я не в курсе, а было бы интересно узнать.
misha_irpen пишет: > Сам я от большого программинга уже отошел, хотя по прежнему могу считать > себя профессионалом Delphi и ASM. И у меня приактически никогда не > возникало проблем из-за каких-то ограничений языка. Я с уверенностью > могу сказать, что могу написать на нем абсолютно все что угодно в рамках > имеющихся API и математических моделей.
Прям как я.
> Просветите плиз вашу точку зрения, только объективно.
1) Плохо стандартизованный. Паскаль и C++ в этом плане похожи. У обоих
формально есть свои стандарты, и не какие–нибудь ECMA, а самые что ни на
есть ISO, но практически есть один–два забугорных компилятора, полностью
реализующих эти стандарты, но о них не каждый слышал, и ими практически
никто не пользуется. Вместо этого пользуются расширенными подмножествами
(эвфемизм для "вольными интерпретациями") стандарта. Для C++
единственный мне известный — это Comeau, для Pascal, пожалуй, gpc, хотя
не уверен. И у Comeau, и у gpc очень мало пользователей по сравнению с
другими "реализациями".
2) Чего не хватает:
шаблоны/дженерики; -- no comments
иерархическое пространство имён; -- тоже не хватает
объявление по месту; -- declare-begin-end — это удобно
автоматическая финализация;
-- я дублировал иерархию классов иерахией интерфейсов, не айс
нисходящие замыкания; -- вроде такого:
procedure Some_Outer_Procedure(...) is
...
Var1 : ...;
Var2 : ...;
Var3 : ...;
begin
-- some code
declare
Var4 : ...;
Var5 : ...;
procedure Enum_Windows_Proc(hwnd : in Handle_Wnd) is
begin
-- some processing here using any of Var1-5
end Enum_Windows_Proc;
begin
Enum_Windows(Enum_Windows_Proc'Access);
end;
-- some code
end Some_Outer_Procedure;
-- notice lParam stripped from both Enum_Windows invokation and
-- Enum_Windows_Proc prototype. lParam is used internally to pass the
-- stack frame pointer or what else is needed to invoke a closure.
Приведённый пример на Delphi сейчас можно реализовать через for-in-do,
но замыкания не ограничиваются перечислением. К тому же, for-in-do
требует генератора, т. е. чтоб перечислитель был вызываемым, а не
вызывающим.
Нисходящее замыкание — это более общий вариант указателя на процедуру. В
Delphi указатель на процедуру может быть расширен до указателя на метод,
а замыкание ещё более общий вариант. У нисходящего замыкания время жизни
меньше, но возможности больше. http://groups.google.com/group/borland.public.delphi.nativeapi.win32/browse_thread/thread/7fe4286d0b8598bb/6a2daa5eaee295e9
агрегаты для массивов, записей и объектов; -- мелочь, а приятно
не объявлять переменную для for; -- и так понятно, какого она типа
встроенная многозадачность; -- актуально
смещение компоненты в записи, не кратное байту;
-- например, для работы с 15 и 16битными bitmap пригодилось бы
битовые массивы размером более, чем 256 битов;
размеры, не определённые на этапе компиляции;
-- на самом деле, редко, когда заранее известно, сколько потребуется
места для данных; использовать буфер статического размера — опуститься
до уровня C, использовать динамический — overhead при
выделении/освобождении; в C99 (?9 лет назад) эта константность в разных
местах была убрана
3) не к самому Delphi, но в сравнении с Free Pascal
Эти реализации разъезжаются. Free Pascal реализует фичи раньше, но в
стиле C++. Borland реализует аналогичную фичу обычно позже, FPC уже
догнал и перегнал Delphi. Но при этом Borland делает вид, что FPC нет, и
реализует фичу в стиле Delphi.NET. Вот так, например, произошло с
перегрузкой операторов. Чтобы написать математику с перегрузкой
операторов переносимо, придётся знать и ту, и другую реализацию. Чем
дальше в лес, тем больше дров. В 2008 появятся дженерики, а в FPC они
уже есть.
4) что не так именно в Delphi
Delphi сильно заточен под платформу. И это не просто зависимость на
уровне библиотек. Платформа определяла появление и реализацию фич. Вот
взять те же интерфейсы, это ведь не просто интерфейсы, это интерфейсы
COM. Причём, автоматическое уничтожение в интерфейсах есть, а в классах
нет. И если класс реализует COM интерфейс, то работать с ним надо уже
через этот интерфейс, потому что иначе можно пожать утечки памяти. В
нормальных языках классы и интерфейсы не отличаются друг от друга
настолько. WideString. Своим появлением обязан всё тому же COMу. И
именно поэтому AnsiString со счётчиком ссылок, а WideString — без. Ещё
одна привязка к платформе — это "message WM_XXX;" в методе. Страшно
неприятный момент выкинутая поддержка COFF. Она была давно, но её
выкинули (по политическим соображениям, как я понял), а вы теперь
крутитесь как знаете.
5) мораль
Всё из перечисленного сделано как надо в Аде (кроме замыканий — они
есть, но там обёртки для API ещё нужно написать). И, собственно, зуб мой
на Delphi в том, что при всей его лоскутности, нецелостности, отсталости
и т. д. он перекрывает популярность, которую бы могла иметь Ада.
Перекрывает поток энтузиастов. Знай каждый паскалист Аду, было бы
столько библиотек, столько книжек и других ресурсов для Паскаля? FPC
вообще бы не состоялся за ненадобностью. Delphi — это как собака на сене
(на программистах, то есть)
Чем по сути занимаются разработчики Delphi и FPC? Они реализуют фичи,
которые давно были в Аде. Вот та же перегрузка операторов в Delphi
появилась только в 2006й версии. В Аде она была в 83ей. Шаблонов в
Delphi на данный момент нет. Опять же, в 83ей уже такой функционал был.
В Delphi недревовидное пространство имён, как в 83й Аде. В .NET
по–другому, но Delphi.NET — это отдельный разговор. Delphi по многим
пунктам отстаёт лет на 10-15 (справедливости ради отмечу, что интерфейсы
появились в Аде только в 2005й версии, но до этого их можно было
заменять mix-in'ами). Отставание будет только нарастать. Потому что
контора в первую очередь занимается GUI, в чём они преуспели, это факт.
Вирт от Паскаля отказался. Он исправил свои ошибки и воплотил свои
замыслы в Модуле и Обероне. Помимо школы Вирта, есть Ада. От Паскаля
отказались все, кто мог. Паскаль не умирает только из–за Borland. Есть
FPC, но он ИМХО индуцирован Delphi, без Delphi был бы только GPC.
Весьма активно работал в этой среде лет 5 назад (когда не было .NET, который свёл к нулю полезность этой среды). Что не нравилось:
1. Многа букв — ну это момент очень субъективный.
2. Слишком умный, часто не по делу, компилер. Когда использовал DirectX в дельфи — глюков получал из-за этой "умности" море — дико бесило
3. Серьёзные проблемы с юникодом в VCL
4. Поддержка готовых решений — в подавляющем большинстве случаев ужас — куда непонятных компонент, неясно откуда взятых и непонятно как работающих (а местами и не работающих ). Сама IDE подталкивает в такому использованию — edit28'ов повидал немало.
5. Отсутствие в винде рантайма для дельфей — в итоге гигантские модули.
6. Несовместимость разных версий IDE
7. Слишком строгая типизация — арифметика указателей очень быстро превращается в нечитаемую кашу из PDWORD(DWORD()). Особенно доставало опять же при работе с DX.
8. Необъяснимые проблемы при работе с Direct3D — непонятные ошибки, вылезающие в случайных местах. Гугл на них находил только аналогичные моему вопросы в основном без ответов
Чего хорошего можно написать такими неприличными символами?
:=
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>2) Чего не хватает: OCT>иерархическое пространство имён; -- тоже не хватает
Nested types появились в 2005/6. Или речь о другом?
OCT>объявление по месту; -- declare-begin-end — это удобно
Shift+Ctrl+V (Refactoring: Declare Variable). Не замена, но кого напрягает...
OCT>автоматическая финализация;
Есть, для управляемых типов.
OCT>встроенная многозадачность; -- актуально
Обещают в 2009. Не думаю, что сделают как в Ada, но чего-то сделать обещают.
OCT>битовые массивы размером более, чем 256 битов;
TBits.
OCT>размеры, не определённые на этапе компиляции; OCT>-- на самом деле, редко, когда заранее известно, сколько потребуется OCT>места для данных; использовать буфер статического размера — опуститься OCT>до уровня C, использовать динамический — overhead при OCT>выделении/освобождении; в C99 (?9 лет назад) эта константность в разных OCT>местах была убрана
Кроме статики и динамики какие еще варианты? А вообще Array Of xxxx.
OCT>3) не к самому Delphi, но в сравнении с Free Pascal OCT>Эти реализации разъезжаются. Free Pascal реализует фичи раньше, но в OCT>стиле C++. Borland реализует аналогичную фичу обычно позже, FPC уже OCT>догнал и перегнал Delphi. Но при этом Borland делает вид, что FPC нет, и OCT>реализует фичу в стиле Delphi.NET. Вот так, например, произошло с OCT>перегрузкой операторов. Чтобы написать математику с перегрузкой OCT>операторов переносимо, придётся знать и ту, и другую реализацию. Чем OCT>дальше в лес, тем больше дров. В 2008 появятся дженерики, а в FPC они OCT>уже есть.
В Delphi уже есть Nested types, а у FPC даже в планах нет Вроде и нормальный вариант-диспатчинг появился только-только... И вообще, с чего CodeGear должен ориентироваться на FPC, когда их уличали неоднократно (с горячими разборками в блогах) в прямом копировании кода VCL (читай в плагиате).
OCT>Delphi сильно заточен под платформу. И это не просто зависимость на OCT>уровне библиотек. Платформа определяла появление и реализацию фич. Вот OCT>взять те же интерфейсы, это ведь не просто интерфейсы, это интерфейсы OCT>COM.
Интерфейсы в Delphi появились имено благодаря COM, но это не COM интерфейсы
OCT>Причём, автоматическое уничтожение в интерфейсах есть, а в классах OCT>нет. И если класс реализует COM интерфейс, то работать с ним надо уже OCT>через этот интерфейс, потому что иначе можно пожать утечки памяти.
Это не совсем так TComponent -- являет собой пример класса имеющего интерфейсы, но требующего ручной сборки мусора. Это не минус и не плюс, это фича для тех кому нужно.
OCT>В нормальных языках классы и интерфейсы не отличаются друг от друга OCT>настолько.
И что же в этом хорошего?
OCT> WideString. Своим появлением обязан всё тому же COMу. И OCT>именно поэтому AnsiString со счётчиком ссылок, а WideString — без.
Так и есть. В 2008 обещают новый тип строк, что-то вроде UnicodeString.
OCT>Ещё одна привязка к платформе — это "message WM_XXX;" в методе.
Это чудесная вещь! Появилась благодаря Win API, но никакой привязки к платформе тут нет, ибо чудесно работало и в Kylix
OCT>Всё из перечисленного сделано как надо в Аде (кроме замыканий — они OCT>есть, но там обёртки для API ещё нужно написать). И, собственно, зуб мой OCT>на Delphi в том, что при всей его лоскутности, нецелостности, отсталости OCT>и т. д. он перекрывает популярность, которую бы могла иметь Ада. OCT>Перекрывает поток энтузиастов. Знай каждый паскалист Аду, было бы OCT>столько библиотек, столько книжек и других ресурсов для Паскаля? FPC OCT>вообще бы не состоялся за ненадобностью. Delphi — это как собака на сене OCT>(на программистах, то есть)
Я тоже полюбил Ada после прочтения RM95
OCT>Отставание будет только нарастать. Потому что OCT>контора в первую очередь занимается GUI, в чём они преуспели, это факт.
Справедливости ради, сейчас CodeGear взялась за язык (что еще развивать в GUI под нативом). Правят древние баги, добавляют языковые фичи. Роадмап у них, в принципе, интересный. В анкете интересовались вопросами кросплатформенности (Linux/MacOS)...
Здравствуйте, koandrew, Вы писали:
K>2. Слишком умный, часто не по делу, компилер. Когда использовал DirectX в дельфи — глюков получал из-за этой "умности" море — дико бесило
Он умный все же чаще по делу...
K>3. Серьёзные проблемы с юникодом в VCL
TNTControls не решает проблем?
K>4. Поддержка готовых решений — в подавляющем большинстве случаев ужас — куда непонятных компонент, неясно откуда взятых и непонятно как работающих (а местами и не работающих ). Сама IDE подталкивает в такому использованию — edit28'ов повидал немало.
IDE ни к чему не подталкивает. На начальном этапе, да, можно писать очень криво. Если это вошло в систему, ну... ССЗБ.
K>5. Отсутствие в винде рантайма для дельфей — в итоге гигантские модули.
Да, Майкрософт отказала влючать пакеты Borland'а в Windows. Политика.
K>6. Несовместимость разных версий IDE
А зачем мне совместимость IDE? Чего там совмещать?
K>7. Слишком строгая типизация — арифметика указателей очень быстро превращается в нечитаемую кашу из PDWORD(DWORD()). Особенно доставало опять же при работе с DX.
И кошек вы вероятно тоже не любите... Нет никакой проблемы с указателями -- можно использовать так, как только заблагороссудится. Можно типизированно, можно без типизации. Готовить нужно уметь
K>8. Необъяснимые проблемы при работе с Direct3D — непонятные ошибки, вылезающие в случайных местах. Гугл на них находил только аналогичные моему вопросы в основном без ответов
Я бы мог поставить диагноз... Но обижать не хочется
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, gandjustas, Вы писали:
G>>Да даже не в этом дело. В C++ можно вернуть из метода экземпляр класса. В делфи нельзя. Ибо экземпляр — это ссылка, для которой явно надо вызвать Free.
J>Почему нельзя, можно конечно. J>
J>function TSameObject.CreateStringList: TStringList;
J>begin
J> Result := TStringList.Create;
J>end;
J>
Не смеши меня.
на C++
A f()
{
return A();
}
...
{
A x = f();
}//Здесь вызвовется деструктор ч
На Delphi
function TSameObject.CreateStringList: TStringList;
begin
Result := TStringList.Create;
end;
...
var x:TStringList;
begin
x:=SameObject.CreateStringList;
end; //А тут ничего не вызовется, получим утечку памяти
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, gandjustas, Вы писали:
G>>Недостатки G>>1)ссылочная обьектная модель в отсутствии сборщика мусора. надо явно вызывать Free для каждого объекта, что многие забывают. В С++ с этим проще, визуально несложно проверить парность new и delete. В деляфх гораздо сложнее из-за синтаксиса вызова конструктора. В С# вообще такой проблемы нет.
J>знаешь, нормальный дельфист сразу видет парные Create/Free. Приемущество c++ в том, что в нем объекты на стеке могут распологаться..
Конструкторы могут называтся как угодно. Банальным Ctrl+F уже не найдешь.
G>>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля) J>интерфейсы есть уже лет 10, наверно...
Да уж, только то COM-интерфейсы
G>>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля) G>>4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля) J>хм. ранние — это какие?? такое ощущение, что ты знаешь только о delphi1
Я работал на делфях версий 2-7.
Перегрузка функций появилась в delphi 5 кажись, перегрузка операторов не было и в delphi 7
G>>5)Ужасная работа с указателями. (наследие паскаля) J>Что значит "ужасная" ??? Или строгая типизация тя не устраивает???
Отсутствие операций инкремента и декремента, а также невозможно указать типа указателя в месте использования.
G>>6)Невнятная библиотека ввода-вывода (на самом деле несколько возможностей осуществлять IO, несовместимых междц собой). J>то есть в с++ — только один способ ввода/вывода??
Я всегда пользовался iostream и мне хватало.
G>>7)Практически полное отсутствие контейнерной библиотеки G>>8)Большенство классов являются неочень качественными обертками над WinAPI. J>в чем конкретно некачественность?? ТОка не надо описывать конкретные глюки отдельных компонентов, такие вещи есть в любой библиотреке классов. В
чем некачественность на уровне Classes.pas/Controls.pas/Forms.pas ??
Класс TThread. 1)Не позволяет узнать завершился ли поток — надо использовать WinAPI. 2)Непонятен в использовании (из-за наследования), на первой работе неделю ловили баг из-за неправильного использования Thread. Человек банально скопировал код из примера и сам чего-то дописал. 3)Потоки есть — а примитивов синхронизации в VCL нет, приходится снова юзать WinAPI
G>>9)Исполняемые файлы получаются очень тяжеловесными. J>Хм. Ну давай я статически слинкую mfc exe'шник и сбилжу пустую форму на дельфи с ран-тайм пакетамм — и скажу MSVC — генериит очень тяжеловесные экзешники.
А почему Borland C++ Builder собирает exeшники в 3-4 раза меньшие по объему?
G>>Я могу продолжить, но думаю этого хватит. J>В принципе этого хватит. Уже видно, что все твои знания о дельфи почерпнуты из холли-варов на рсдн..
Делфи с 7 класса школы изучал и 2 года работал.
Здравствуйте, gandjustas, Вы писали:
G>Недостатки G>1)ссылочная обьектная модель в отсутствии сборщика мусора. надо явно вызывать Free для каждого объекта, что многие забывают. В С++ с этим проще, визуально несложно проверить парность new и delete. В деляфх гораздо сложнее из-за синтаксиса вызова конструктора. В С# вообще такой проблемы нет.
Не совсем верно. Сборка мусора была — Free можно было забыть вызвать.
А ссылочная объектная модель — что в этом плохого?
G>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля)
Зато были делегаты (нет необходимости в интерфейсах), виртуальные конструкторы (вроде, сам уже плохо помню) и еще много чего.
G>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля)
Шаблон — это скорее развитый препроцессор. Препроцессор отношения к языку не имеет (что мне мешает взять и мои исходники на дельфях обработать препроцессором того же gcc?).
G>4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля)
Ну отсутствие перегрузки функций я по ходу и не застал, а вот с операторами не очень понятно надо ли оно — ручной парсинг такого кода крайне сложен (т.е. сложно въехать в чужой проект).
G>5)Ужасная работа с указателями. (наследие паскаля)
Спорный вопрос. Нормально работалось (ну требовалось иногда явное приведение типов, но это, ИМХО, только читабельность повышало.
G>6)Невнятная библиотека ввода-вывода (на самом деле несколько возможностей осуществлять IO, несовместимых между собой).
Ну по сравнению с каким-нибудь char *, CString и std::string — это еще было не так все плохо
G>7)Практически полное отсутствие контейнерной библиотеки
G>8)Большенство классов являются неочень качественными обертками над WinAPI.
G>9)Исполняемые файлы получаются очень тяжеловесными.
Зато самодостаточными (за редким исключением).
Кстати, возможность собрать более легкий файл, но с зависимостями тоже была
G>>>5)Ужасная работа с указателями. (наследие паскаля) J>>Что значит "ужасная" ??? Или строгая типизация тя не устраивает??? G>Отсутствие операций инкремента и декремента, а также невозможно указать типа указателя в месте использования.
Подробнее? Все было...
G>>>6)Невнятная библиотека ввода-вывода (на самом деле несколько возможностей осуществлять IO, несовместимых междц собой). J>>то есть в с++ — только один способ ввода/вывода?? G>Я всегда пользовался iostream и мне хватало.
Я всегда пользовался read/write и мне хватало
G>>>9)Исполняемые файлы получаются очень тяжеловесными. J>>Хм. Ну давай я статически слинкую mfc exe'шник и сбилжу пустую форму на дельфи с ран-тайм пакетамм — и скажу MSVC — генериит очень тяжеловесные экзешники. G>А почему Borland C++ Builder собирает exeшники в 3-4 раза меньшие по объему?
А ты его запусти на другой машине — быстро поймешь
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
_>>>В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин? G>>Автоматическая сборка мусора. H>И неконтролируемая... Из-за которой, порой, возникают прелесные фризы на ровном месте.
За год работы на .NET ни одного случая не видел, вам видимо везет.
_>>>Кстати, сборка мусора для некоторых типов данных (строки и динамические массивы) у Delphi была уже тогда. G>>Это не преимущество, а попытка скрыть недостатки. H>Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток? Я еще добавлю, что Delphi и за интерфейсами сама следит.
А как еще можно было сделать динамические строки и массивы, но не нагружать программиста вызовами Free?
В C++ автоматически вызывается деструктор по выходу из scope.
За интерфейсам следит не делфи, за интерфейсам следит комилятор, фактически вставляя вызов Release для интерфейса, что может потянуть кучу необъяснимых глюков. Да и разная семантика работы с классами, реазиующими интрфейсы и нереалзующими их — тоже немалый недостаток.
G>>Да, синтаксис паскаля многословный очень. Особенно бесило Procedure и Function. Это все при том, что почти не было поддержки со cтороны IDE. H>Чет я не понял... Чего тебе IDE должна поддерживать в процедуре или функции?
Delphi 7 нажимаешь ctrl+space begin, end, procedure, function он и не думает завершать.
G>>1)ссылочная обьектная модель в отсутствии сборщика мусора. надо явно вызывать Free для каждого объекта, что многие забывают. В С++ с этим проще, визуально несложно проверить парность new и delete. В деляфх гораздо сложнее из-за синтаксиса вызова конструктора. В С# вообще такой проблемы нет. H>Уж и не знаю кому сложнее, но старому Паскалисту сильно проще чем в C++
Ну смотри пример выше. сылочная объектная модель без GC вносит ограничения, которые невозможно обойти.
Хотя я не сомневаюсь что старому паскалисту делфи гораздо легче чем С++.
В приниче этим и объясняется распространение делфи в России (на западе такого не было), в школах и вузах традиционно учат паскалю.
G>>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля) H>Интерфейсы есть с очень древней (3/4) версии. А в шарпе делегирование оных есть уже?
COM — нитерфейсы. К ООП они вообще мало отношения имеют. Делегирование интерфейсов в шарпе нет по тойже причине. Если поковыряться с интеропом, то возможно что-то подобное есть и на .NET. Но мне не доводилось таким заниматься.
G>>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля) H>Дженерики есть в 2007 под .Net. В 2008 обещают и для нативного кода.
Мда... Это на фоне того, что появилось в C# 3.0 в 2007 году. Делфи тут оооочень сильно отстает.
G>>4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля) H>Перегрузка функций/методов есть с 4 версии. Операторы можно перегружать уже с 2005 (для классов только под .Net, для натива можно перегружать для advanced records (class-like)). А с 2006 есть еще и перегружаемые свойства-массивы. Можно еще добавить class/record хелперы.
А с какого года это есть в C++? Тут очевидно стремление delphi догнать С#
G>>5)Ужасная работа с указателями. (наследие паскаля) H>Конкретика? Типизация указателей имеется со времен... очень давно в общем имеется. Адресная арифметика на уровне. Чего не нравится?
то что надо явно объявлять тип указателя и отсутствие инкремента\декремента
G>>6)Невнятная библиотека ввода-вывода (на самом деле несколько возможностей осуществлять IO, несовместимых междц собой). H>Чудесная библиотека ввода/вывода (позволяющая при умении заворачивать интереснейшие вещи без участия низкоуровневых API).
Пример в студию.
G>>7)Практически полное отсутствие контейнерной библиотеки H>Списки (различные), стеки, очереди, бит-контейнеры, ассоциативные массивы. Мало?
Это оно когда появилось? Случаем не в Delphi.NET ?
H>И вправду можешь не продолжать... Ты явно не в теме (ну, или сильно субъективен, что аж перекашивает).
Я на Delphi писал большую часть моей программистской жизни.
А вы на C# попробуйте пописать, сразу поймете.
Здравствуйте, misha_irpen, Вы писали:
_>Я с уверенностью могу сказать, что могу написать на нем абсолютно все что угодно в рамках имеющихся API и математических моделей. При этом практически никогда не приходится изобретать велосипедов и извращаться чтобы обойти ограничения языка или стандартных библиотек. В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин?
По мне так сишарпы — это дальнейшее развитие тех же идей. Пока я 5 лет на дельфях программировал, тоже казалось, что все задачи можно решить и всё замечательно. Вопрос в том, насколько эффективно это можно сделать. Например, рассмотрим обобщённый алгоритм сортировки. Чтобы сделать его обобщённым в Delphi, ему нужно передовать указатель на функцию сравнения. А в C++, благодаря наличию шаблонов, функция сравнения может быть inline'ом вкомпилирована в саму сортировку. Если речь идёт о сортировке обычных чисел, то это даёт прирост производительности в несколько раз, т.к. простое сравнение чисел в несколько раз быстрее вызова функции с передачей параметров и последующего возврата из неё.
Также C++ даёт возможность размещать классы не только в куче, но и в стеке и в глобальной памяти. Деструкторы объектов вызываются автоматически, даже в случае исключения. Это позволяет эффективно управлять временем жизни объектов в большинстве случаев обходясь без ручного выделения/освобождения, да плюс ещё заворачивания в try/finally блок. Ну и т.д.
Здравствуйте, lifrsdn, Вы писали:
L>Что хотелось бы иметь:
L>1. Объявление переменных в месте использования. Не критично, но ползти в var неприятно.
На вкус и цвет — когда в одном месте, оно читабельнее. L>2. Переопределяемых операторов. Часто сложная математика выглядит с ними привычнее. Читать потом тяжко...
CString str;
...
(char *)str //вот и пойми, что это перегруженный оператор на самом деле :xz:
L>3. Вынесу отдельно — возможности построения типов с поведением, как у стандартных.
А подробнее? Вроде все строилось как надо...
L>4. Препроцессор. Да его ругают, но лучше иметь возможность его использовать.
Используй внешний (и отлаживаться проще).
J>хм. прочем тут дельфи? Утечки памяти были, есть и будут во всех языках без GC
GC в Дельфи был. И очень неплохой — они использовали собственный менеджер памяти (из-за этого программа на дельфи кушала память большими кусками, по 10 Мб, если мне не изменяет память).
Здравствуйте, Don Reba, Вы писали:
DR>Если в программе вместо буков вопросительные знаки — значит она написана на Дельфи.
DR>Не нравится Дельфи из за типично чрезвычайно низкого качества написанных на ней программ. Троечники собирают на этом небезопасном языке свои компоненты из компонентов написанных другими троечники, а конечные программы являются результатом нескольких итераций этого процесса.
Что-то мне подсказывает, что еще пара лет и так же начнут хаять .Net с C#...
Здравствуйте, goto, Вы писали:
G>Паскаль был придуман как учебный язык для изучения основ программирования. Прежде всего из-за этого он приобрел популярность, и его уже потом Борланд (собственно и выросший, насколько помню, на Турбо Паскале) стал его развивать как промышленный. На Дельфи не работал, но в свое время мне Турбо Паскаль не нравился своей эклектичностью: на язык, изначально придуманный только для обучения, не для разработки, стали искуственно навешивать необходимую функциональность и модные фичи. Но это все эмоции. Понятно, что на Паскале можно писать.
Ну, во-первых, тот же питон тоже был придуман для обучения, как и scheme — но это им не мешает занимать свою нишу (в случае с питоном очень даже неплохую).
Во-вторых, одного взгляда на C++ должно хватать, чтобы понимать какими агли хаками шел переход от C до C++ (есть где-то в недрах gcc C++ препроцессор — т.е. преобразование программы на C++ в программу на C — все конструкции С++ раскрываются как макросы).
G>Раньше на Паскаль смотрели без уважения и нехорошо из-за нестандартности, отсутствия кроссплатформенности и вообще минимальной переносимости.
Тут о сих пор народ мало волнует переносимость, а уж лет 10 назад (в России в крайнем случае).
G>И ведь среда по подходу не хакерская ни разу. Формочки там всякие, драг-н-дропы. Несерьезно .
Ну как раз всяких примеров сниферов и тому подобных шутк на дельфях хватало. Опять же — make в комплекте шел — пиши все в шелле, никто не мешает.
Здравствуйте, DOOM, Вы писали:
DOO>Во-вторых, одного взгляда на C++ должно хватать, чтобы понимать какими агли хаками шел переход от C до C++ (есть где-то в недрах gcc C++ препроцессор — т.е. преобразование программы на C++ в программу на C — все конструкции С++ раскрываются как макросы).
Это неверно. GCC транслирует программу на С++ в общее представление (в GIMPLE, а потом в RTL). Чистый С идёт точно по такому же пути.
В очень ранних версиях (типа 1.x) — может и по другому было.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, DOOM, Вы писали:
DOO>>Во-вторых, одного взгляда на C++ должно хватать, чтобы понимать какими агли хаками шел переход от C до C++ (есть где-то в недрах gcc C++ препроцессор — т.е. преобразование программы на C++ в программу на C — все конструкции С++ раскрываются как макросы). C>Это неверно. GCC транслирует программу на С++ в общее представление (в GIMPLE, а потом в RTL). Чистый С идёт точно по такому же пути.
Я имел ввиду, что не сам gcc — как компилятор C++ так делает, а была какая-то отдельная программка (я ее ни разу не смотрел в работе), которая именно переводила C++ в С путем препроцессинга. Вроде она до сих пор имеется в пакете gcc — надо бы поискать.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Jack128, Вы писали:
J>>Здравствуйте, gandjustas, Вы писали:
J>>знаешь, нормальный дельфист сразу видет парные Create/Free. Приемущество c++ в том, что в нем объекты на стеке могут распологаться.. G>Конструкторы могут называтся как угодно. Банальным Ctrl+F уже не найдешь.
Не понял, ты не знаешь как называется конструктор в твоем(или чужом) классе??
G>>>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля) J>>интерфейсы есть уже лет 10, наверно... G>Да уж, только то COM-интерфейсы
в дельфи самостоятельная реализация интерфейсов, никак на ком не завязаная на ком. Другое дело, что она СОВМЕСТИМА с ком, но это только плюс ей.
G>>>4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля) J>>хм. ранние — это какие?? такое ощущение, что ты знаешь только о delphi1 G>Я работал на делфях версий 2-7. G>Перегрузка функций появилась в delphi 5 кажись, перегрузка операторов не было и в delphi 7
Ну вот я и говорю delphi5 вышла в конце 90х, несли мне не изменяет память. А перегрузка операторов — да, была только для вариантов.
G>>>5)Ужасная работа с указателями. (наследие паскаля) J>>Что значит "ужасная" ??? Или строгая типизация тя не устраивает??? G>Отсутствие операций инкремента и декремента, а также невозможно указать типа указателя в месте использования.
var
D: ^Double;
P: Pointer;
begin
Inc(D, 10); // инкремент
PInteger(P)^ := 10; // явное указание типа указателя..
end;
G>Класс TThread. 1)Не позволяет узнать завершился ли поток — надо использовать WinAPI.
Чесно говоря никогда не было узнавать завершился ли поток, обычно требует подождать пока поток завершиться. Но в любом случае — уверен, что в стандартные либы с++ тоже далеко не полностью покрывают функционал WinAPI.. Собственно это и не требуется..
G>2)Непонятен в использовании (из-за наследования), на первой работе неделю ловили баг из-за неправильного использования Thread. Человек банально скопировал код из примера и сам чего-то дописал.
Знаешь, если человек не в состоянии перекрыть абстрактный метод, то не понятно, как он вообще работает программистом?? А "чего-то" дописать, чтоб после этого ничего не работало — и я могу
G>3)Потоки есть — а примитивов синхронизации в VCL нет, приходится снова юзать WinAPI
SyncObjs.pas ???
G>>>9)Исполняемые файлы получаются очень тяжеловесными. J>>Хм. Ну давай я статически слинкую mfc exe'шник и сбилжу пустую форму на дельфи с ран-тайм пакетами — и скажу MSVC — генерирует очень тяжеловесные экзешники. G>А почему Borland C++ Builder собирает exeшники в 3-4 раза меньшие по объему?
Насколько я помню билдер по умолчанию динамически линкует библиотеки, а дельфи — статически..
Здравствуйте, gandjustas, Вы писали:
H>>И неконтролируемая... Из-за которой, порой, возникают прелесные фризы на ровном месте. G>За год работы на .NET ни одного случая не видел, вам видимо везет.
Видимо. И не только мне. На форумах обсуждалось неоднократно с последующими советами понавставлять по коду GC.Collect
H>>Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток? Я еще добавлю, что Delphi и за интерфейсами сама следит. G>А как еще можно было сделать динамические строки и массивы, но не нагружать программиста вызовами Free?
Ну так это же плюс. Чего ты его охаял?
G>В C++ автоматически вызывается деструктор по выходу из scope. G>За интерфейсам следит не делфи, за интерфейсам следит комилятор, фактически вставляя вызов Release для интерфейса, что может потянуть кучу необъяснимых глюков. Да и разная семантика работы с классами, реазиующими интрфейсы и нереалзующими их — тоже немалый недостаток.
Под Delphi я и имел ввиду компилятор (а что же еще-то может за этим следить...). Семантика для работы с интерфейсными классами и с обычными может быть одинаковой (см. TComponent). Но все это тонкости дающие большую гибкость. И необъяснимые глюки это может вызвать только там, где программист работает сам незная с чем (или не до конца понимая механизм).
H>>Чет я не понял... Чего тебе IDE должна поддерживать в процедуре или функции? G>Delphi 7 нажимаешь ctrl+space begin, end, procedure, function он и не думает завершать.
2005/6 имеют Code Templates. Штука очень приятная и расширяемая.
H>>Уж и не знаю кому сложнее, но старому Паскалисту сильно проще чем в C++ G>Ну смотри пример выше. сылочная объектная модель без GC вносит ограничения, которые невозможно обойти. G>Хотя я не сомневаюсь что старому паскалисту делфи гораздо легче чем С++.
Это с возвратом созданного объекта чтоль? Ну и в чем проблема? Вот GetMem/VirtualAlloc тоже сырую память отдают и ее возвращать нужно. Не смущает? На самом деле ни какой проблемы в этом нет, объекты, как правило создаются для хранения в каких-либо коллекциях/списках и прочих. И уж точно нет ни какого напряга дернуть Free. Придирки, и не более того.
H>>Интерфейсы есть с очень древней (3/4) версии. А в шарпе делегирование оных есть уже? G>COM — нитерфейсы. К ООП они вообще мало отношения имеют. Делегирование интерфейсов в шарпе нет по тойже причине. Если поковыряться с интеропом, то возможно что-то подобное есть и на .NET. Но мне не доводилось таким заниматься.
Что значит COM-интерфейсы? Бинарно совместимы -- да. И что? К ООП имееют прямое отношение: тут и инкапсуляция и полиморфизм. А делегирование позволяет сэкономить массу времени при кодировани и кстати, увеличивает полиморфизм.
H>>Дженерики есть в 2007 под .Net. В 2008 обещают и для нативного кода. G>Мда... Это на фоне того, что появилось в C# 3.0 в 2007 году. Делфи тут оооочень сильно отстает.
Уж не про LINQ ли ты говоришь Ну в 2008 или 2009 обещают анонимные методы добавить еще.
G>>>4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля) H>>Перегрузка функций/методов есть с 4 версии. Операторы можно перегружать уже с 2005 (для классов только под .Net, для натива можно перегружать для advanced records (class-like)). А с 2006 есть еще и перегружаемые свойства-массивы. Можно еще добавить class/record хелперы. G>А с какого года это есть в C++? Тут очевидно стремление delphi догнать С#
Какая разница кто-кого догоняет или откуда заимствуются те или иные фичи? Ты тут о минусах говорил, я же тебе на плюсы указываю.
G>>>5)Ужасная работа с указателями. (наследие паскаля) H>>Конкретика? Типизация указателей имеется со времен... очень давно в общем имеется. Адресная арифметика на уровне. Чего не нравится? G>то что надо явно объявлять тип указателя и отсутствие инкремента\декремента
Работать можно и с нетипизированными. Инкремент/декремент работает на типизированных, что очень правильно.
H>>Чудесная библиотека ввода/вывода (позволяющая при умении заворачивать интереснейшие вещи без участия низкоуровневых API). G>Пример в студию.
Ну я код постить не собираюсь, в гугле найдешь если интересно. Я наводку дам. В паскале есть чудесная функция Write/WriteLn реализовать которую средствами самого языка невозможно (не прибегая к константным массивам, что все равно не является полноценным решением), но использовать которую очень удобно. Можно легким движением руки превратить ее в приличный логгер перенаправив вывод (да не просто перенаправить, а целый обвяз создать) куда угодно. Делается это именно благодаря библиотечному устройству и без каких либо низкоуровневых API.
H>>Списки (различные), стеки, очереди, бит-контейнеры, ассоциативные массивы. Мало? G>Это оно когда появилось? Случаем не в Delphi.NET ?
В нативной 2006 точно есть. Может и в 2005 было, я не помню.
H>>И вправду можешь не продолжать... Ты явно не в теме (ну, или сильно субъективен, что аж перекашивает). G>Я на Delphi писал большую часть моей программистской жизни. G>А вы на C# попробуйте пописать, сразу поймете.
Я скорее на Ada пересяду, чем на C#
G>Вообще я заметил что субъективизмом страдают те, кто пишет на Delphi и других языков и технологий не знает. G>Прочитайте http://www.rsdn.ru/article/nemerle/Amplifier.xml
Здравствуйте, gandjustas, Вы писали:
G>>>5)Ужасная работа с указателями. (наследие паскаля) H>>Конкретика? Типизация указателей имеется со времен... очень давно в общем имеется. Адресная арифметика на уровне. Чего не нравится? G>то что надо явно объявлять тип указателя и отсутствие инкремента\декремента
Что я никогда не понимал в наездах на Delphi, так это про ужасные указатели. Откуда отсутствие инкремента\декремента?
var
P: ^LongInt;
..
Inc(P);
..
Какие проблемы и как делать инкремент\декремент без объявления типа указателя (фактически задавая размер памяти, адресуемой указателем)?
В Delphi нет пост/прекрементов, но это не напрягает и имхо это вообще наследие архитектуры PDP-11, где пост/прекременты поддерживались на уровне системы команд процессора.
Единственное чего не хватает — нельзя написать
var
P: ^LongInt;
..
I:= P[J];
..
В текущей версии такое возможно только с PChar, но обещают в это году разрешить делать это с любым указателем.
---
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true
<skip> G>И ведь среда по подходу не хакерская ни разу. Формочки там всякие, драг-н-дропы. Несерьезно .
Как так не хакерская? Некоторые особо одаренные люди пишут на дельфях не только драйвера уровня ядра для виндовс ХР, но и вирусы различные(viruslist посмотрите, пример — Trojan-PSW.Win32.Lmir.a). Правда, для этого приходится выкорчевывать различные vcl и rtl библиотеки.
Здравствуйте, DOOM, Вы писали:
J>>хм. прочем тут дельфи? Утечки памяти были, есть и будут во всех языках без GC
DOO>GC в Дельфи был. И очень неплохой — они использовали собственный менеджер памяти (из-за этого программа на дельфи кушала память большими кусками, по 10 Мб, если мне не изменяет память).
Это не GC в полном понимании слова. Редкая гадость, надо признать.
Здравствуйте, DOOM, Вы писали:
L>>Что хотелось бы иметь:
L>>1. Объявление переменных в месте использования. Не критично, но ползти в var неприятно. DOO>На вкус и цвет — когда в одном месте, оно читабельнее.
L>>2. Переопределяемых операторов. Часто сложная математика выглядит с ними привычнее. DOO> Читать потом тяжко... DOO>
DOO>CString str;
DOO>...
DOO>(char *)str //вот и пойми, что это перегруженный оператор на самом деле :xz:
DOO>
На счет перегрузки операторов соглашусь: в общем случае перегрузка операторов — зло, но во всяческих фреймворках и узкоспециализированных библиотеках (в основном математического направления) они весьма и весьма полезны.
Здравствуйте, gandjustas, Вы писали:
I>>По своему опыту скажу, что низкокачественного кода было написано дохрена и больше, чем высококачественного, не зависимо от платформы.
G>Во всех программах на делфи, которые я видел, были утечки памяти. Для Java и .NET такого быть не может
Здравствуйте, DOOM, Вы писали:
DR>>Не нравится Дельфи из за типично чрезвычайно низкого качества написанных на ней программ. Троечники собирают на этом небезопасном языке свои компоненты из компонентов написанных другими троечники, а конечные программы являются результатом нескольких итераций этого процесса.
DOO>Что-то мне подсказывает, что еще пара лет и так же начнут хаять .Net с C#...
Сомневаюсь сильно. Java вон куда старше .NET и ничего — живет и здравствует.
Пока .NET развивается в правильном направлении.
Обещают в следующем фреймворке DI стандартны. Это скорее хорошо, чем плохо, учитывая, что сейчас только ленивый не изобретает свой IoC/DI... Хотелось бы только верить, что он будет как минимум на уровне Castle Windsor.
Интересно будет посмотреть на Microsoft`овский DLR (Dynamic Language Runtime). Признаю, что питаю слабость к Ruby — полагаю большие надежды на IronRuby.
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, gandjustas, Вы писали:
J>Не понял, ты не знаешь как называется конструктор в твоем(или чужом) классе??
В том классе, который не я написал — не знаю. Мне много раз приходилось править код написанный до меня.
J>Ну вот я и говорю delphi5 вышла в конце 90х, несли мне не изменяет память. А перегрузка операторов — да, была только для вариантов.
Я больше всего работал в Delphi7 — большенитсво впечатлений оттуда.
J>var J> D: ^Double; J> P: Pointer; J>begin J> Inc(D, 10); // инкремент
J> PInteger(P)^ := 10; // явное указание типа указателя.. J>end;
А вы на C++ писали? Похоже вы не знаете о применении автоинкремента.
G>>Класс TThread. 1)Не позволяет узнать завершился ли поток — надо использовать WinAPI. J>Чесно говоря никогда не было узнавать завершился ли поток, обычно требует подождать пока поток завершиться. Но в любом случае — уверен, что в стандартные либы с++ тоже далеко не полностью покрывают функционал WinAPI.. Собственно это и не требуется..
Если вам не требуется, то не значит что другим не требуется.
G>>2)Непонятен в использовании (из-за наследования), на первой работе неделю ловили баг из-за неправильного использования Thread. Человек банально скопировал код из примера и сам чего-то дописал. J>Знаешь, если человек не в состоянии перекрыть абстрактный метод, то не понятно, как он вообще работает программистом?? А "чего-то" дописать, чтоб после этого ничего не работало — и я могу
А я в C# не могу так написать.
J>Насколько я помню билдер по умолчанию динамически линкует библиотеки, а дельфи — статически..
Я сравнивал при статической линковке.
Здравствуйте, _d_m_, Вы писали:
_>>>Постоянно читая RSDN имел возможность неоднократно убедиться что большинство участников сильно не любят Delphi. Уж очень стало интересно, а за что собственно? SB>>Не знаю как другим, но мне не нравится: SB>>1. SB>>
SB>>:=
SB>>
___>А по моему, так все правильно. По идее семантика оператора сравнения должна отличаться от оператора присваивания.
Наверно речь о том, что не удобно печатать := каждый раз. Все-таки оператор присваивания встречается на много чаще, чем оператор сравнения.
G>>>5)Ужасная работа с указателями. (наследие паскаля) J>>Что значит "ужасная" ??? Или строгая типизация тя не устраивает???
G>Отсутствие операций инкремента и декремента,
Здравствуйте, gandjustas, Вы писали:
G>На Delphi G>
G>function TSameObject.CreateStringList: TStringList;
G>begin
G> Result := TStringList.Create;
G>end;
G>...
G>var x:TStringList;
G>begin
G> x:=SameObject.CreateStringList;
G>end; //А тут ничего не вызовется, получим утечку памяти
G>
С тем же успехом можно сказать, что и в C++ нельзя позвращать ссылку, т.к. ее нужно будет освобождать.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>Видимо. И не только мне. На форумах обсуждалось неоднократно с последующими советами понавставлять по коду GC.Collect
Мда... Перечитайте лучше форумы.
H>>>Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток? Я еще добавлю, что Delphi и за интерфейсами сама следит. G>>А как еще можно было сделать динамические строки и массивы, но не нагружать программиста вызовами Free? H>Ну так это же плюс. Чего ты его охаял?
Это не плюс, это необходимость. Плюс был бы если бы можно было врубать GC для всех объектов.
H>Под Delphi я и имел ввиду компилятор (а что же еще-то может за этим следить...).
В .NET следит рантайм.
H>Семантика для работы с интерфейсными классами и с обычными может быть одинаковой (см. TComponent). Но все это тонкости дающие большую гибкость. И необъяснимые глюки это может вызвать только там, где программист работает сам незная с чем (или не до конца понимая механизм).
В C# люди работают, не зная с чем, и баги не возникают почему-то.
H>2005/6 имеют Code Templates. Штука очень приятная и расширяемая.
Мда... в 2005 году уже студия 2005 есть.
H>Это с возвратом созданного объекта чтоль? Ну и в чем проблема? Вот GetMem/VirtualAlloc тоже сырую память отдают и ее возвращать нужно. Не смущает? На самом деле ни какой проблемы в этом нет, объекты, как правило создаются для хранения в каких-либо коллекциях/списках и прочих. И уж точно нет ни какого напряга дернуть Free. Придирки, и не более того.
Я ловил сотни ошибоки из-затого что люди забывали/не_знали_что_надо вызывать Free. В Управляемых средах вообще таких проблем нет. Придирки вполе по делу. Вы просто не понимаете, потому что не работали с этим.
H>Уж не про LINQ ли ты говоришь Ну в 2008 или 2009 обещают анонимные методы добавить еще.
В 2009 уже C# 4.0 будет. Так что делфи все равно отстает.
H>Какая разница кто-кого догоняет или откуда заимствуются те или иные фичи? Ты тут о минусах говорил, я же тебе на плюсы указываю.
Эти плюсы не перекрывают минусы. А в других языках и платформах минусов поменьше.
H>Ну я код постить не собираюсь, в гугле найдешь если интересно. Я наводку дам. В паскале есть чудесная функция Write/WriteLn реализовать которую средствами самого языка невозможно (не прибегая к константным массивам, что все равно не является полноценным решением), но использовать которую очень удобно. Можно легким движением руки превратить ее в приличный логгер перенаправив вывод (да не просто перенаправить, а целый обвяз создать) куда угодно. Делается это именно благодаря библиотечному устройству и без каких либо низкоуровневых API.
Мда... Посмотри функционал iostream в C++, TextWriter в .NET (в Java есть аналогичные классы) — побогаче будет.
Типы text, file of ... — вообще ужас. Поганейшее наследие паскаля.
Если вы не знаете других способов, то это на значит что delphi в чем-то удобен.
H>В нативной 2006 точно есть. Может и в 2005 было, я не помню.
Смешно даже. STL для C++ сущесвует гораздо раньше, в .NET изначально было (c 2001 года), в Java еще раньше.
Delphi тут сильно отстает.
H>Я скорее на Ada пересяду, чем на C#
Удачи.
H>Заметь, не я тут на языки наезжал не имея представления о текущем положении дел.
Вы сначала изучите текущее положение дел не только в Delphi, тогда поговорим.
С момента появления C# 2.0 делфи в положении догоняющего, и вероятнее всего это исправить не удастся.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
G>>На Delphi G>>
G>>function TSameObject.CreateStringList: TStringList;
G>>begin
G>> Result := TStringList.Create;
G>>end;
G>>...
G>>var x:TStringList;
G>>begin
G>> x:=SameObject.CreateStringList;
G>>end; //А тут ничего не вызовется, получим утечку памяти
G>>
L>С тем же успехом можно сказать, что и в C++ нельзя позвращать ссылку, т.к. ее нужно будет освобождать.
В C++ можно вернуть объект (не ссылку), в делфяф такое нельзя сделать в принципе
Здравствуйте, hattab, Вы писали:
_>>>В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин? G>>Автоматическая сборка мусора.
H>И неконтролируемая... Из-за которой, порой, возникают прелесные фризы на ровном месте.
Не может быть никаких фризов. Сборщик муссора ведь не в главном потоке приложения выполняется.
_>>>Кстати, сборка мусора для некоторых типов данных (строки и динамические массивы) у Delphi была уже тогда. G>>Это не преимущество, а попытка скрыть недостатки.
H>Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток?
В общем случае это таки недостаток. Особенно, когда нет в наличии generic smart pointer`ов (прерогатива C++).
G>>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля)
H>Интерфейсы есть с очень древней (3/4) версии. А в шарпе делегирование оных есть уже?
В C# есть полноценные делегаты, а в C# 3.0 есть полноценные lambda-выражения.
Без полноценного DI в Delphi толку от интерфейсов куда как меньше.
G>>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля)
H>Дженерики есть в 2007 под .Net.
Думаю тут речь не шла о .NET Delphi. Иначе спор деградировал бы до: какой язык — Delphi.Net или X лучше.
Я бы привел в качестве примера Boo (python синтаксис, с расширяемой compiler pipe).
Здравствуйте, gandjustas, Вы писали:
G>>>Отсутствие операций инкремента и декремента,
kuj>>Это ВЕСЬМА спорный аргумент.
G>Знаю, но некоторые выражения на С++ с использованием автоинкремента очень громоздко выразить без него.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, _d_m_, Вы писали:
_>>>>Постоянно читая RSDN имел возможность неоднократно убедиться что большинство участников сильно не любят Delphi. Уж очень стало интересно, а за что собственно? SB>>>Не знаю как другим, но мне не нравится: SB>>>1. SB>>>
SB>>>:=
SB>>>
___>>А по моему, так все правильно. По идее семантика оператора сравнения должна отличаться от оператора присваивания.
kuj>Наверно речь о том, что не удобно печатать := каждый раз. Все-таки оператор присваивания встречается на много чаще, чем оператор сравнения.
Здравствуйте, kuj, Вы писали:
G>>Знаю, но некоторые выражения на С++ с использованием автоинкремента очень громоздко выразить без него. kuj>Ну это скорее камень в огород C++
С одной стороны да, с другой стороны показывает мощьность этих операторов.
В любом случае возможность есть, а использовать её неикто не заствляет.
Здравствуйте, gandjustas, Вы писали:
L>>С тем же успехом можно сказать, что и в C++ нельзя позвращать ссылку, т.к. ее нужно будет освобождать. G>В C++ можно вернуть объект (не ссылку), в делфяф такое нельзя сделать в принципе
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, DOOM, Вы писали:
DR>>>Не нравится Дельфи из за типично чрезвычайно низкого качества написанных на ней программ. Троечники собирают на этом небезопасном языке свои компоненты из компонентов написанных другими троечники, а конечные программы являются результатом нескольких итераций этого процесса.
DOO>>Что-то мне подсказывает, что еще пара лет и так же начнут хаять .Net с C#...
kuj>Сомневаюсь сильно. Java вон куда старше .NET и ничего — живет и здравствует.
Вопрос распространенности — когда Java появится на парах по информатике в вузах с непрограммистскими специальностями, тогда и ее начнут хаять.
У связки .Net и C# есть все шансы там появится (сейчас, наверное, там все еще дельфи живет).
Здравствуйте, swame, Вы писали:
S>Здравствуйте, kuj, Вы писали:
kuj>>Здравствуйте, _d_m_, Вы писали:
_>>>>>Постоянно читая RSDN имел возможность неоднократно убедиться что большинство участников сильно не любят Delphi. Уж очень стало интересно, а за что собственно? SB>>>>Не знаю как другим, но мне не нравится: SB>>>>1. SB>>>>
SB>>>>:=
SB>>>>
___>>>А по моему, так все правильно. По идее семантика оператора сравнения должна отличаться от оператора присваивания.
kuj>>Наверно речь о том, что не удобно печатать := каждый раз. Все-таки оператор присваивания встречается на много чаще, чем оператор сравнения.
S>write-only код ?
Ну что вы как дети. := и =, а также = и == имеют значение только для обучения. Причем ооочень начального (школьного). Человек на первом курсе вуза вполне может понять различия.
У учитывая то что все современные компиляторы C++ выдают варнинг на выражение if(a = 1) совершать такие ошибки гораздо сложнее.
Здравствуйте, hattab, Вы писали:
H>>>И неконтролируемая... Из-за которой, порой, возникают прелесные фризы на ровном месте. G>>За год работы на .NET ни одного случая не видел, вам видимо везет.
H>Видимо. И не только мне. На форумах обсуждалось неоднократно с последующими советами понавставлять по коду GC.Collect
Ссылки в студию.
G>>Ну смотри пример выше. сылочная объектная модель без GC вносит ограничения, которые невозможно обойти. G>>Хотя я не сомневаюсь что старому паскалисту делфи гораздо легче чем С++.
H>Это с возвратом созданного объекта чтоль? Ну и в чем проблема? Вот GetMem/VirtualAlloc тоже сырую память отдают и ее возвращать нужно. Не смущает? На самом деле ни какой проблемы в этом нет, объекты, как правило создаются для хранения в каких-либо коллекциях/списках и прочих. И уж точно нет ни какого напряга дернуть Free. Придирки, и не более того.
Ты забываешь о человеческом факторе.
G>>Мда... Это на фоне того, что появилось в C# 3.0 в 2007 году. Делфи тут оооочень сильно отстает.
H>Уж не про LINQ ли ты говоришь Ну в 2008 или 2009 обещают анонимные методы добавить еще.
Lambda, linq, implicitly typed variables (я, правда, несколько негативно к идеи применения var отношусь, но это тема для отдельного разговора), extension methods, annonymous types, auto properties, type inference, object и collection initializers...
H>Ну я код постить не собираюсь, в гугле найдешь если интересно. Я наводку дам. В паскале есть чудесная функция Write/WriteLn реализовать которую средствами самого языка невозможно (не прибегая к константным массивам, что все равно не является полноценным решением), но использовать которую очень удобно. Можно легким движением руки превратить ее в приличный логгер перенаправив вывод (да не просто перенаправить, а целый обвяз создать) куда угодно. Делается это именно благодаря библиотечному устройству и без каких либо низкоуровневых API.
H>>>Списки (различные), стеки, очереди, бит-контейнеры, ассоциативные массивы. Мало? G>>Это оно когда появилось? Случаем не в Delphi.NET ? H>В нативной 2006 точно есть. Может и в 2005 было, я не помню.
Только без generic`ов ОЙ как плохо.
H>>>И вправду можешь не продолжать... Ты явно не в теме (ну, или сильно субъективен, что аж перекашивает). G>>Я на Delphi писал большую часть моей программистской жизни. G>>А вы на C# попробуйте пописать, сразу поймете.
H>Я скорее на Ada пересяду, чем на C#
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, goto, Вы писали:
G>>Паскаль был придуман как учебный язык для изучения основ программирования. Прежде всего из-за этого он приобрел популярность, и его уже потом Борланд (собственно и выросший, насколько помню, на Турбо Паскале) стал его развивать как промышленный. На Дельфи не работал, но в свое время мне Турбо Паскаль не нравился своей эклектичностью: на язык, изначально придуманный только для обучения, не для разработки, стали искуственно навешивать необходимую функциональность и модные фичи. Но это все эмоции. Понятно, что на Паскале можно писать.
DOO>Ну, во-первых, тот же питон тоже был придуман для обучения, как и scheme — но это им не мешает занимать свою нишу (в случае с питоном очень даже неплохую).
И шо? И у Дельфи есть ниша. Я не эксперт, но пока понимаю так. Если у Питона, ниша "смысловая" — получился объективно хороший язык для скриптов, то популярность Дельфи проистекает из других вещей, прежде всего из низкого порога вхождения при разработке UI-приложений + из того, что Дельфям просто обильно и безальтернативно учат в ВУЗах и техникумах.
DOO>Во-вторых, одного взгляда на C++ должно хватать, чтобы понимать какими агли хаками шел переход от C до C++ (есть где-то в недрах gcc C++ препроцессор — т.е. преобразование программы на C++ в программу на C — все конструкции С++ раскрываются как макросы).
Язык и реализация его компилятора — разные вещи. Сам по себе С++ не предполагает, что его компилятор должен быть устроен именно таким образом.
Насчет данного агли хака не в курсе. На писюках, насколько помню, С++ появился в реализации Борланд. Компилятор требовал аж 2 мега памяти (много по тем временам). Так что с новым языком было трудно "побаловаться", плавного перехода не было.
G>>Раньше на Паскаль смотрели без уважения и нехорошо из-за нестандартности, отсутствия кроссплатформенности и вообще минимальной переносимости. DOO>Тут о сих пор народ мало волнует переносимость, а уж лет 10 назад (в России в крайнем случае).
Раньше это было как раз актуальней, т.к. существовал большой парк мэйнфреймов со своими ОС, более разнообразных рабочих станция (не только под Юниксами), на писюках попадались другие системы, например, OS/2. По-моему, это сейчас проблема переносимости не так остра. Прежле всего, разнообразие систем уменьшилось, + какая-никакая стандартизация со временем принесла плоды.
G>>И ведь среда по подходу не хакерская ни разу. Формочки там всякие, драг-н-дропы. Несерьезно . DOO>Ну как раз всяких примеров сниферов и тому подобных шутк на дельфях хватало. Опять же — make в комплекте шел — пиши все в шелле, никто не мешает.
Здравствуйте, swame, Вы писали:
kuj>>Наверно речь о том, что не удобно печатать := каждый раз. Все-таки оператор присваивания встречается на много чаще, чем оператор сравнения.
S>write-only код ?
А если еще учесть, что за 10 лет школы человек привыкает, что "=" означает сравнение, то для оператора присваивания ему логично увидеть новое обозначение, а для сравнения оставить прежнее
Тут можно возразить, что есть еще кое-где оператор тождественного сравнения: "===" — и в таком случае логичнее обозначать просто сравнение "==" (ну чтобы они похожи были), но такого оператора нет в C++
А вообще даешь привычные математические обозначения:
← — присвоение
≡ — тождественное равенство
≠ — не равно
≈ — сравнение чисел с плавающей точкой
Здравствуйте, gandjustas, Вы писали:
H>>Это с возвратом созданного объекта чтоль? Ну и в чем проблема? Вот GetMem/VirtualAlloc тоже сырую память отдают и ее возвращать нужно. Не смущает? На самом деле ни какой проблемы в этом нет, объекты, как правило создаются для хранения в каких-либо коллекциях/списках и прочих. И уж точно нет ни какого напряга дернуть Free. Придирки, и не более того. G>Я ловил сотни ошибоки из-затого что люди забывали/не_знали_что_надо вызывать Free. В Управляемых средах вообще таких проблем нет. Придирки вполе по делу. Вы просто не понимаете, потому что не работали с этим.
В управляемых средах забывают делать Dispose. GC не всесилен — такие ресурсы как File или DbConnection, например, приходится высвобождать явно, реализуя IDisposable.
Здравствуйте, goto, Вы писали:
G>Здравствуйте, DOOM, Вы писали:
DOO>>Здравствуйте, goto, Вы писали:
G>>>Паскаль был придуман как учебный язык для изучения основ программирования. Прежде всего из-за этого он приобрел популярность, и его уже потом Борланд (собственно и выросший, насколько помню, на Турбо Паскале) стал его развивать как промышленный. На Дельфи не работал, но в свое время мне Турбо Паскаль не нравился своей эклектичностью: на язык, изначально придуманный только для обучения, не для разработки, стали искуственно навешивать необходимую функциональность и модные фичи. Но это все эмоции. Понятно, что на Паскале можно писать.
DOO>>Ну, во-первых, тот же питон тоже был придуман для обучения, как и scheme — но это им не мешает занимать свою нишу (в случае с питоном очень даже неплохую).
G>Если у Питона, ниша "смысловая" — получился объективно хороший язык для скриптов
Я думаю, тут куча народу бы стала спорить — кто там и для каких скриптов хорош (по-любому, нашлись бы противники питоновской фичи по смешиванию оформления кода и задания границ синтаксических конструкций)
Можно ведь сказать, что "Delphi — объективно хороший язык/IDE для создания настольных приложений" Вот только ни фига это не будет объективно
DOO>>Во-вторых, одного взгляда на C++ должно хватать, чтобы понимать какими агли хаками шел переход от C до C++ (есть где-то в недрах gcc C++ препроцессор — т.е. преобразование программы на C++ в программу на C — все конструкции С++ раскрываются как макросы).
G>Язык и реализация его компилятора — разные вещи.
Бесспорно, просто это демонстрация — C++ разрабатывался именно, как надстройка над C, который, по-любому, когда-то был не более, чем набор удачных макросов для какого-нибудь ассемблера (вон я в универе делал из NASM'а эдакий Basic ). Вот все это и тянется в финальном языке.
G>>>Раньше на Паскаль смотрели без уважения и нехорошо из-за нестандартности, отсутствия кроссплатформенности и вообще минимальной переносимости. DOO>>Тут о сих пор народ мало волнует переносимость, а уж лет 10 назад (в России в крайнем случае).
G>Раньше это было как раз актуальней, т.к. существовал большой парк мэйнфреймов со своими ОС, более разнообразных рабочих станция (не только под Юниксами), на писюках попадались другие системы, например, OS/2. По-моему, это сейчас проблема переносимости не так остра. Прежле всего, разнообразие систем уменьшилось, + какая-никакая стандартизация со временем принесла плоды.
Ну сколько процентов программистов 10 лет назад в России писали программы для мэйнфреймов? Еще лучше вопрос — сколько мэйнфреймов было в России 10 лет назад
Здравствуйте, wallaby, Вы писали:
W>Какие проблемы и как делать инкремент\декремент без объявления типа указателя (фактически задавая размер памяти, адресуемой указателем)? W>В Delphi нет пост/прекрементов, но это не напрягает и имхо это вообще наследие архитектуры PDP-11, где пост/прекременты поддерживались на уровне системы команд процессора.
G>>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля)
DOO>Зато были делегаты (нет необходимости в интерфейсах), виртуальные конструкторы (вроде, сам уже плохо помню) и еще много чего.
С какой радости делегаты отменяют необходимость в интерфейсах???
G>>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля) DOO>Шаблон — это скорее развитый препроцессор. Препроцессор отношения к языку не имеет (что мне мешает взять и мои исходники на дельфях обработать препроцессором того же gcc?).
Здравствуйте, DOOM, Вы писали:
C>>Это неверно. GCC транслирует программу на С++ в общее представление (в GIMPLE, а потом в RTL). Чистый С идёт точно по такому же пути. DOO>Я имел ввиду, что не сам gcc — как компилятор C++ так делает, а была какая-то отдельная программка (я ее ни разу не смотрел в работе), которая именно переводила C++ в С путем препроцессинга. Вроде она до сих пор имеется в пакете gcc — надо бы поискать.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, wallaby, Вы писали:
W>>Какие проблемы и как делать инкремент\декремент без объявления типа указателя (фактически задавая размер памяти, адресуемой указателем)? W>>В Delphi нет пост/прекрементов, но это не напрягает и имхо это вообще наследие архитектуры PDP-11, где пост/прекременты поддерживались на уровне системы команд процессора.
kuj>
kuj>int x = 3;
kuj>x += x++;
kuj>
kuj>Вопрос: чему равен x?
Еще хороший вопрос:
$a[$i++]=$i
Ну или даже круче:
$a[$i++]=$i VS $a[$i++]=$i+0
Ой, сейчас разойдусь... Perl cо своим криптосинтаксисом тут всех уделает
Здравствуйте, DOOM, Вы писали:
C>>Это неверно. GCC транслирует программу на С++ в общее представление (в GIMPLE, а потом в RTL). Чистый С идёт точно по такому же пути. DOO>Я имел ввиду, что не сам gcc — как компилятор C++ так делает, а была какая-то отдельная программка (я ее ни разу не смотрел в работе), которая именно переводила C++ в С путем препроцессинга. Вроде она до сих пор имеется в пакете gcc — надо бы поискать.
Да, была — сfront (на ней ещё куча компиляторов было основано). Но С++98 уже не осиливала.
Здравствуйте, goto, Вы писали:
G>Не знаю как сейчас, но на Дельфи еще недавно учили толпы студентов и школьников (а какая альтернатива? Бэйсик?). Учили очень часто низкокачественно. Одно время действительно гуляло большое количество "крутых программистов на Дельфи", которые веселили искушенную публику разными штуками, и кодом. По личным ощущениям массово стали нормально учить программированию только последние несколько лет, и в серьезных местах преподают уже не Дельфи (если что, поправьте, пож-та, кто ближе к образованию).
Делфи все еще даже в ВУЗах на программистских специальностях преподают.
Программы в ВУЗах очень инертны — они никак не поспевают за стремительным развитием IT.
Вместо Delphi пора преподавать .NET технологии.
Вместо Prolog — Erlang.
и т.д.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>Короче := и = — исключительно дело вкуса.
DOO>А если еще учесть, что за 10 лет школы человек привыкает, что "=" означает сравнение, то для оператора присваивания ему логично увидеть новое обозначение, а для сравнения оставить прежнее DOO>Тут можно возразить, что есть еще кое-где оператор тождественного сравнения: "===" — и в таком случае логичнее обозначать просто сравнение "==" (ну чтобы они похожи были), но такого оператора нет в C++ DOO>А вообще даешь привычные математические обозначения: DOO>← — присвоение DOO>≡ — тождественное равенство DOO>≠ — не равно DOO>≈ — сравнение чисел с плавающей точкой DOO>
А зачем вообще приносить в программирование математическую запись? Бредовая изначально идея.
Здравствуйте, goto, Вы писали:
DOO>>Ну, во-первых, тот же питон тоже был придуман для обучения, как и scheme — но это им не мешает занимать свою нишу (в случае с питоном очень даже неплохую).
G>И шо? И у Дельфи есть ниша.
Была. Уже нету. Занята .Net
Legacy-код остался конечно — с этим ничего не поделаешь.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, DOOM, Вы писали:
G>>>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля)
DOO>>Зато были делегаты (нет необходимости в интерфейсах), виртуальные конструкторы (вроде, сам уже плохо помню) и еще много чего.
kuj>С какой радости делегаты отменяют необходимость в интерфейсах???
Подход в проектировании — дельфист делал объект, многие методы которого определял в рантайме — таким образом из одного класса получались объекты с различным поведением. С++'ник делал базовый объект + объекты-интерфейсы (соответственно абстрактные), в которых уже (статично) определялось конкретное поведение объекта. Т.е. тут однозначно делегаты удобнее и дают большую гибкость, хотя ярые C++'ники такой вариант вообще понять не могли — для них изменение поведения объекта в рантайме было чем-то из ряда вон выходящим.
Disclaimer: описанный подход C++'ника не мой. Это из моих древних споров с одногруппником в универе (он был ярый C++'ник, да и на самом деле профессионал своего дела), спор был на тему, если не ошибаюсь, а на кой ляд вообще нужно множественное наследование...
P.S. К Disclaimer'у — сам я ни с C++, ни с дельфи не имел дела уже много лет, просто этот спор разбудил древние инстинкты Это я заранее к тому, что могу что-то уже не знать в новейших достижениях ООП или банально что-то забыть.
G>>>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля) DOO>>Шаблон — это скорее развитый препроцессор. Препроцессор отношения к языку не имеет (что мне мешает взять и мои исходники на дельфях обработать препроцессором того же gcc?).
kuj>Ой ли?
А что нет что ли? Ноги-то откуда растут? Понятно, что со временем это обрастало фичами, появилась обратная связь с компилятором и т.п. Но идея абсолютно "макросной" природы — готов поспорить, что изначально это и реализовывалось исключительно препроцессором.
Здравствуйте, DOOM, Вы писали:
W>>>Какие проблемы и как делать инкремент\декремент без объявления типа указателя (фактически задавая размер памяти, адресуемой указателем)? W>>>В Delphi нет пост/прекрементов, но это не напрягает и имхо это вообще наследие архитектуры PDP-11, где пост/прекременты поддерживались на уровне системы команд процессора.
kuj>>
kuj>>int x = 3;
kuj>>x += x++;
kuj>>
kuj>>Вопрос: чему равен x?
DOO>Ой, сейчас разойдусь... Perl cо своим криптосинтаксисом тут всех уделает
Я о том, что пост и пре инкременты и декременты к сожалению в ряде случаев понижают читабельность кода.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, kuj, Вы писали:
kuj>>
kuj>>int x = 3;
kuj>>x += x++;
kuj>>
kuj>>Вопрос: чему равен x?
G>И часто такой код в проектах видели?
Не часто. Точнее совсем не видел. К счастью, не доводится работать с кодом индусов...
G>Вообще-то никто не сомневается что C++ занимает первое место по чису Undefined behavior, но разве кто-то заставляет так писать?
G>Раньше это было как раз актуальней, т.к. существовал большой парк мэйнфреймов со своими ОС, более разнообразных рабочих станция (не только под Юниксами), на писюках попадались другие системы, например, OS/2. По-моему, это сейчас проблема переносимости не так остра. Прежле всего, разнообразие систем уменьшилось, + какая-никакая стандартизация со временем принесла плоды.
Вот скажи мне как программист программисту: какая процессорная архитектура и операционная система нынче самые распространённые. После ответов на эти вопросы ты определённо пересмотришь своё мнение.
Здравствуйте, DOOM, Вы писали:
G>>>>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля)
DOO>>>Зато были делегаты (нет необходимости в интерфейсах), виртуальные конструкторы (вроде, сам уже плохо помню) и еще много чего.
kuj>>С какой радости делегаты отменяют необходимость в интерфейсах???
DOO>Подход в проектировании — дельфист делал объект, многие методы которого определял в рантайме — таким образом из одного класса получались объекты с различным поведением. С++'ник делал базовый объект + объекты-интерфейсы (соответственно абстрактные), в которых уже (статично) определялось конкретное поведение объекта. Т.е. тут однозначно делегаты удобнее и дают большую гибкость, хотя ярые C++'ники такой вариант вообще понять не могли — для них изменение поведения объекта в рантайме было чем-то из ряда вон выходящим.
Э-э, батенька, ты явно путаешься в понятиях.
Во-первых, делегаты прекрасно реализуются в C++ в виде указателей на функцию.
Во-вторых, интерфейсы нужны для понижения взаимозависимостей от фактической реализации.
Благодаря DI мой ClassA зависит только от IInterfaceB, который реализуется классами ClassB1, ClassB2 и ClassB3. В любой момент времени я могу открыть конфигурацию IoC и сменить байндинг с ClassB1, например, на ClassB2, совсем не затрагивая при этом ClassA. Да, в Delphi и C++ для этого используется паттерн фабрика, НО появляется зависимость ClassA, от фабрики! Вот такие пироги с капустой...
Ну конечно и плюшки типа interceptors благодаря IoC/DI контейнеру конечно тоже имеют большое значение в ряде случаев.
DOO>Disclaimer: описанный подход C++'ника не мой. Это из моих древних споров с одногруппником в универе (он был ярый C++'ник, да и на самом деле профессионал своего дела), спор был на тему, если не ошибаюсь, а на кой ляд вообще нужно множественное наследование...
В .Net от множественного наследования сразу отказались.
G>>>>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля) DOO>>>Шаблон — это скорее развитый препроцессор. Препроцессор отношения к языку не имеет (что мне мешает взять и мои исходники на дельфях обработать препроцессором того же gcc?). kuj>>Ой ли? DOO>А что нет что ли? Ноги-то откуда растут? Понятно, что со временем это обрастало фичами, появилась обратная связь с компилятором и т.п. Но идея абсолютно "макросной" природы — готов поспорить, что изначально это и реализовывалось исключительно препроцессором.
Ну почитай про то, как реализованы generics в .Net Узнаешь много нового
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>Короче := и = — исключительно дело вкуса.
DOO>А если еще учесть, что за 10 лет школы человек привыкает, что "=" означает сравнение, то для оператора присваивания ему логично увидеть новое обозначение,
Всегда в школе считал, что "=" это равно, а значение присвоить или сравнение имеет исключительно в зависимости от контекста. При чем в львином ряде случаев = означает таки присвоить.
x+1 = y
y = 5
-----
x = 4
Угу?
DOO>а для сравнения оставить прежнее
Мне нужно нажать только =, в то время как тебе в Delphi — зажать shift, нажать 6, отжать shift, нажать = и это для, пожалуй, наиболее используемого оператора...
Здравствуйте, iiice, Вы писали:
I> I>Вот скажи мне как программист программисту: какая процессорная архитектура и операционная система нынче самые распространённые. После ответов на эти вопросы ты определённо пересмотришь своё мнение.
Если говорить абстрактно, то не знаю, ибо есть мобилы, интеллектуальные пылесосы и крылатые ракеты. Лично на моем огороде все пожрал жук писюк.
Здравствуйте, DOOM, Вы писали:
DOO>← — присвоение
См. например Haskell Вполне себе поддерживает Unicode символы в исходном коде в таком качестве. Более того — деструктивное присваивание суть ересь и ее использование должно быть ограничено минимумом. Так что <- или ← — в самый раз. А := лишено смысловой нагрузки.
Здравствуйте, DOOM, Вы писали:
DOO>Я думаю, тут куча народу бы стала спорить — кто там и для каких скриптов хорош (по-любому, нашлись бы противники питоновской фичи по смешиванию оформления кода и задания границ синтаксических конструкций) DOO>Можно ведь сказать, что "Delphi — объективно хороший язык/IDE для создания настольных приложений" Вот только ни фига это не будет объективно
Споров про плохость и хорошесть я и пытаюсь избежать. Объективных высказываний тоже .
DOO>>>Во-вторых, одного взгляда на C++ должно хватать, чтобы понимать какими агли хаками шел переход от C до C++ (есть где-то в недрах gcc C++ препроцессор — т.е. преобразование программы на C++ в программу на C — все конструкции С++ раскрываются как макросы).
G>>Язык и реализация его компилятора — разные вещи. DOO>Бесспорно, просто это демонстрация — C++ разрабатывался именно, как надстройка над C, который, по-любому, когда-то был не более, чем набор удачных макросов для какого-нибудь ассемблера (вон я в универе делал из NASM'а эдакий Basic ). Вот все это и тянется в финальном языке.
Да вроде как С++ придумывался как отдельный язык по подходу. Видимо синтаксис C хорошо ложится на большинство программистских мозгов, вот и был взят. На той же Java и C# С и С++ тоже повалялись.
... DOO>Ну сколько процентов программистов 10 лет назад в России писали программы для мэйнфреймов? Еще лучше вопрос — сколько мэйнфреймов было в России 10 лет назад
Сей ужас был в основном пораньше, > 10 лет назад. Из-за этого, в частности, многие вещи, совершенно не вычислительные, когда-то даже писали на FORTRAN IV, это был едва ли не единственный общий знаменатель. Потом им стал С. Сужу по своим давним похождениям в нескольких конторах. Временами мне приходилось писать одновременно под 3 платформы, а я не столь уж древен. А под 2 так можно сказать часто: на писюке отлаживаешь алгоритмы (удобная IDE), а потом на Юниксе уже "внедряешь".
Здравствуйте, gandjustas, Вы писали:
H>>Видимо. И не только мне. На форумах обсуждалось неоднократно с последующими советами понавставлять по коду GC.Collect G>Мда... Перечитайте лучше форумы.
Мне-то это зачем? У меня таких проблем нет и небыло никогда...
G>>>А как еще можно было сделать динамические строки и массивы, но не нагружать программиста вызовами Free? H>>Ну так это же плюс. Чего ты его охаял? G>Это не плюс, это необходимость. Плюс был бы если бы можно было врубать GC для всех объектов.
Для тебя это плюс? Для меня нет. Ну и? У кого больше?
H>>Под Delphi я и имел ввиду компилятор (а что же еще-то может за этим следить...). G>В .NET следит рантайм.
Мы не о .Net тут говорим, если я не ошибаюсь.
H>>Семантика для работы с интерфейсными классами и с обычными может быть одинаковой (см. TComponent). Но все это тонкости дающие большую гибкость. И необъяснимые глюки это может вызвать только там, где программист работает сам незная с чем (или не до конца понимая механизм). G>В C# люди работают, не зная с чем, и баги не возникают почему-то.
уморил.
H>>2005/6 имеют Code Templates. Штука очень приятная и расширяемая. G>Мда... в 2005 году уже студия 2005 есть.
Ты сравнивай тогда первую версию Delphi...
Придирки, и не более того. G>Я ловил сотни ошибоки из-затого что люди забывали/не_знали_что_надо вызывать Free. В Управляемых средах вообще таких проблем нет. Придирки вполе по делу. Вы просто не понимаете, потому что не работали с этим.
Если люди чего-то там не знали/забывали, это характеризует только их, но не инструмент. Если выражаться простым языком: не можешь срать -- не мучай жопу. В управляемых средах, таки, есть место ручной очистке (пусть даже семантически скрываемой) для объектов владеющих ресурсами. Что начнется, когда человек, который работает не зная с чем (с твоих же слов), будет следовать навязываемой идеологии...
H>>Какая разница кто-кого догоняет или откуда заимствуются те или иные фичи? Ты тут о минусах говорил, я же тебе на плюсы указываю. G>Эти плюсы не перекрывают минусы. А в других языках и платформах минусов поменьше.
В других платформах есть тормоза неизвестно откуда появляющиеся, но теория их существование отрицает
G>Мда... Посмотри функционал iostream в C++, TextWriter в .NET (в Java есть аналогичные классы) — побогаче будет. G>Типы text, file of ... — вообще ужас. Поганейшее наследие паскаля. G>Если вы не знаете других способов, то это на значит что delphi в чем-то удобен.
Дава,й в конкретику ударяйся уже. Демагогия запарила.
H>>В нативной 2006 точно есть. Может и в 2005 было, я не помню. G>Смешно даже. STL для C++ сущесвует гораздо раньше, в .NET изначально было (c 2001 года), в Java еще раньше. G>Delphi тут сильно отстает.
Мы тут, что С++ обсуждаем или Java? Ты сказал, что в Delphi чего-то нет. Я тебе говорю, что есть (может оно и в семерке уже было, я не помню).
Здравствуйте, kuj, Вы писали:
kuj>Всегда в школе считал, что "=" это равно, а значение присвоить или сравнение имеет исключительно в зависимости от контекста. При чем в львином ряде случаев = означает таки присвоить.
Кстати в SQL = означает как присваивание, так и сравнение. Так что спор ни о чем. Чисто дело вкуса.
Здравствуйте, goto, Вы писали:
G>>>И шо? И у Дельфи есть ниша.
kuj>>Была. Уже нету. Занята .Net
G>И хорошо, по-моему . Только образование обладает инетрностью, продолжают учить Дельфям. Масштабов и соотношений не знаю.
Это так к сожалению. Вообще любой программист в первую очередь должен уметь самообучаться. Преподаватели в ВУЗах редко когда имеют высокую квалификацию. Те, кто кроме преподавания занимаются еще и практическими вопросами на другом месте работы — редкость. Вот и учат по конспекту лекций, составленному хез в какие годы.
Базу конечно дадут, но без самообучения далеко с ней не уедешь.
Здравствуйте, gandjustas, Вы писали:
kuj>>Всегда в школе считал, что "=" это равно, а значение присвоить или сравнение имеет исключительно в зависимости от контекста. При чем в львином ряде случаев = означает таки присвоить. G>Кстати в SQL = означает как присваивание, так и сравнение. Так что спор ни о чем. Чисто дело вкуса.
А в PL/SQL присваивание — оператор :=
Сам по себе SQL имеет очень строгий синтаксис. Например, UPDATE table SET column = value — SET явно указывает, что в данном контексте = оператор присваивания, а в SELECT * FROM table WHERE column = value — WHERE явно указывает, что в данном контексте = оператор сравнения.
Здравствуйте, kuj, Вы писали:
H>>Видимо. И не только мне. На форумах обсуждалось неоднократно с последующими советами понавставлять по коду GC.Collect
kuj>Ссылки в студию.
Я их не коллекционирую. На хоботе было обсуждение написанного прокси у которого именно фризы и лезли после долгостояния Тут тоже где-то в веб-программировании было нечто подобное.
H>>Это с возвратом созданного объекта чтоль? Ну и в чем проблема? Вот GetMem/VirtualAlloc тоже сырую память отдают и ее возвращать нужно. Не смущает? На самом деле ни какой проблемы в этом нет, объекты, как правило создаются для хранения в каких-либо коллекциях/списках и прочих. И уж точно нет ни какого напряга дернуть Free. Придирки, и не более того.
kuj>Ты забываешь о человеческом факторе.
Человеческий фактор отмазка хорошая Кто-то заставляет работать с такими представителями рода человеческого? Delphi 2006 благодаря новому менеджеру памяти исправно сигналит обо всех утечках.
H>>Уж не про LINQ ли ты говоришь Ну в 2008 или 2009 обещают анонимные методы добавить еще.
kuj>Lambda, linq, implicitly typed variables (я, правда, несколько негативно к идеи применения var отношусь, но это тема для отдельного разговора), extension methods, annonymous types, auto properties, type inference, object и collection initializers...
И правда, тут об этом не стоит О Delphi таки говорим.
H>>>>Списки (различные), стеки, очереди, бит-контейнеры, ассоциативные массивы. Мало? G>>>Это оно когда появилось? Случаем не в Delphi.NET ? H>>В нативной 2006 точно есть. Может и в 2005 было, я не помню. kuj>Только без generic`ов ОЙ как плохо.
Не сильно, если честно Для Delphi 2006 есть неофициальный тул (по сути препроцессор) который реализует много чего: и дженерики, и case по строкам, и exit с возвратом результата. В общем кому нужно -- тот найдет.
Здравствуйте, kuj, Вы писали:
H>>И неконтролируемая... Из-за которой, порой, возникают прелесные фризы на ровном месте.
kuj>Не может быть никаких фризов. Сборщик муссора ведь не в главном потоке приложения выполняется.
Суслика видишь? Нет. А он есть (c) ДМБ. А сборщику не нужно лочить кучу, чтоб дефрагментацию делать? А процы уже у всех поголовно двух/четырех головые?
H>>Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток?
kuj>В общем случае это таки недостаток. Особенно, когда нет в наличии generic smart pointer`ов (прерогатива C++).
Так в чем недостаток-то?
kuj>Без полноценного DI в Delphi толку от интерфейсов куда как меньше.
Чего-то не улавливаю связи...
G>>>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля)
H>>Дженерики есть в 2007 под .Net.
kuj>Думаю тут речь не шла о .NET Delphi. Иначе спор деградировал бы до: какой язык — Delphi.Net или X лучше.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, hattab, Вы писали:
K>>>6. Несовместимость разных версий IDE
H>>А зачем мне совместимость IDE? Чего там совмещать?
L>Видимо имелось в виду то, что формат dfm-а время от времени перестает пониматься более новой версией IDE.
Если мне не изменяет память, это было один раз при смене формата .dfm. Так и то, в поставку была включена утиль для конвертирования.
Здравствуйте, Mamut, Вы писали:
H>>Мы тут, что С++ обсуждаем или Java? Ты сказал, что в Delphi чего-то нет. Я тебе говорю, что есть (может оно и в семерке уже было, я не помню).
M>И сколько 7-ка стоит?
Я не понял к чему вопрос... Вроде не продают ее уже.
Здравствуйте, Lloyd, Вы писали:
K>>>6. Несовместимость разных версий IDE
H>>А зачем мне совместимость IDE? Чего там совмещать?
L>Видимо имелось в виду то, что формат dfm-а время от времени перестает пониматься более новой версией IDE.
Microsoft движется (хоть и медленно) в правильном направлении со своим Visual Studio — начиная с VS 2005 все файлы проектов C# и VB это не что иное, как xml-скрипт msbuild. Солюшен VS 2005 можно собрать без самого VS 2005 — просто вызвав msbuild <name>.sln, где msbuild идет в поставке с .NET Framework, начиная с .NET 2.0.
Msbuild сам по себе фактически полный аналог (функционально) nAnt`у. Позволяет писать фактически какой угодно сложности сценарии по сборке, тестированию и deploying`у.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Видимо. И не только мне. На форумах обсуждалось неоднократно с последующими советами понавставлять по коду GC.Collect G>>Мда... Перечитайте лучше форумы. H>Мне-то это зачем? У меня таких проблем нет и небыло никогда...
Это еще раз показывает что вы кроме делфи ничего толком не знаете.
G>>>>А как еще можно было сделать динамические строки и массивы, но не нагружать программиста вызовами Free? H>>>Ну так это же плюс. Чего ты его охаял? G>>Это не плюс, это необходимость. Плюс был бы если бы можно было врубать GC для всех объектов. H>Для тебя это плюс? Для меня нет.
А зря
H>>>Под Delphi я и имел ввиду компилятор (а что же еще-то может за этим следить...). G>>В .NET следит рантайм. H>Мы не о .Net тут говорим, если я не ошибаюсь.
Мы тут сравниваем Delphi с другими языками и платформами. Достоинства и недостатки видны только в сравнении с другими
H>>>Семантика для работы с интерфейсными классами и с обычными может быть одинаковой (см. TComponent). Но все это тонкости дающие большую гибкость. И необъяснимые глюки это может вызвать только там, где программист работает сам незная с чем (или не до конца понимая механизм). G>>В C# люди работают, не зная с чем, и баги не возникают почему-то. H> уморил.
Может тебе и смешно, а я уже успел почуствовать насколько меньше люди ошибатся с использованием C# и Java, по сравнению с темже Delphi
Причем среднее всермя обучения C# гораздо меньше чем для Delphi
G>>Я ловил сотни ошибоки из-затого что люди забывали/не_знали_что_надо вызывать Free. В Управляемых средах вообще таких проблем нет. Придирки вполе по делу. Вы просто не понимаете, потому что не работали с этим. H>Если люди чего-то там не знали/забывали, это характеризует только их, но не инструмент. Если выражаться простым языком: не можешь срать -- не мучай жопу. В управляемых средах, таки, есть место ручной очистке (пусть даже семантически скрываемой) для объектов владеющих ресурсами. Что начнется, когда человек, который работает не зная с чем (с твоих же слов), будет следовать навязываемой идеологии...
Какой-то бред, в чем смысл вашего высказывания?
H>>>Какая разница кто-кого догоняет или откуда заимствуются те или иные фичи? Ты тут о минусах говорил, я же тебе на плюсы указываю. G>>Эти плюсы не перекрывают минусы. А в других языках и платформах минусов поменьше. H>В других платформах есть тормоза неизвестно откуда появляющиеся, но теория их существование отрицает
Что дороже покупка в два раза более мощногокомпьютера или в два раза больше времени работы программиста?
H>Мы тут, что С++ обсуждаем или Java? Ты сказал, что в Delphi чего-то нет. Я тебе говорю, что есть (может оно и в семерке уже было, я не помню).
Перечитай первые посты. Идет сравнение Delphi c другими популярными сейчас языками и платформами.
Если вам так нарвится делфи, то откройте ветк в которой опишите чем вам так нравится программировать на Delphi. Желательно в КУ.
ЗЫ Можем вспонить web. какие у делфи возможности создания web-приложений? Правильно — никаких!!!! Это удар ниже пояса.
Здравствуйте, kuj, Вы писали:
kuj>Microsoft движется (хоть и медленно) в правильном направлении со своим Visual Studio — начиная с VS 2005 все файлы проектов C# и VB это не что иное, как xml-скрипт msbuild. Солюшен VS 2005 можно собрать без самого VS 2005 — просто вызвав msbuild <name>.sln, где msbuild идет в поставке с .NET Framework, начиная с .NET 2.0. kuj>Msbuild сам по себе фактически полный аналог (функционально) nAnt`у. Позволяет писать фактически какой угодно сложности сценарии по сборке, тестированию и deploying`у.
Здравствуйте, kuj, Вы писали:
DOO>>Ой, сейчас разойдусь... Perl cо своим криптосинтаксисом тут всех уделает
kuj>Я о том, что пост и пре инкременты и декременты к сожалению в ряде случаев понижают читабельность кода.
Согласен. Более того, в приведенном мною примере для перла C++'ник получит неожиданный для него результат — вот это грабли, дак грабли.
Здравствуйте, kuj, Вы писали:
kuj>Ну почитай про то, как реализованы generics в .Net Узнаешь много нового
В .Net не понимаю почти ничего — я тут про С++ только рассуждаю.
Почитаю я только после того, как закончу Windows Internals, Windows для профессионалов, MS SQL Server 2005 справочник администратора, Защищенный код. И то, если сюда не включится что-нибудь новенькое
Здравствуйте, goto, Вы писали:
G>Да вроде как С++ придумывался как отдельный язык по подходу. Видимо синтаксис C хорошо ложится на большинство программистских мозгов, вот и был взят.
Да при чем тут конкретно синтаксис — libc осталась. Появились char * vs std::string. Много еще таких несоответствий — если уж придумывали как отдельный язык, то и надо было делать отдельным языком, а поддержку C вынести в опциональную библиотеку, например.
Здравствуйте, hattab, Вы писали:
H>>>И неконтролируемая... Из-за которой, порой, возникают прелесные фризы на ровном месте.
kuj>>Не может быть никаких фризов. Сборщик муссора ведь не в главном потоке приложения выполняется.
H>Суслика видишь? Нет. А он есть (c) ДМБ. А сборщику не нужно лочить кучу, чтоб дефрагментацию делать? А процы уже у всех поголовно двух/четырех головые?
То, чего пользователь не видит для него не существует. Это только то, что имеет значение.
Что до процессоров — наши .NET 2.0 и 3.5 сборки крутятся на довольно старых компьютерах. На производительность и тем более фризы никто пока не жаловался.
Вот, кстати, почитай http://msdn.microsoft.com/en-us/library/ms973837.aspx#dotnetgcbasics_topic4
H>>>Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток?
kuj>>В общем случае это таки недостаток. Особенно, когда нет в наличии generic smart pointer`ов (прерогатива C++).
H>Так в чем недостаток-то?
В том, что GC один на всех. Если один процесс пнет его — очисти кучу в то время, как другой процесс нагружает его alloc`ами, то что произойдет? GC сам должен регулировать этот процесс, чтоб для пользователя он был абсолютно незаметным.
kuj>>Без полноценного DI в Delphi толку от интерфейсов куда как меньше.
H>Чего-то не улавливаю связи...
Я писал где-то в этом топике. Вся сила интерфейсов раскрывается при наличии полноценного DI/IoC контейнера.
Здравствуйте, Mamut, Вы писали:
H>>Мы тут, что С++ обсуждаем или Java? Ты сказал, что в Delphi чего-то нет. Я тебе говорю, что есть (может оно и в семерке уже было, я не помню).
M>И сколько 7-ка стоит?
Ну это удар ниже пояса... Готов поспорить, что несмотря на приличную популярность Дельфи в 90-ые, продаж по России почти не было
Здравствуйте, gandjustas, Вы писали:
H>>>>Видимо. И не только мне. На форумах обсуждалось неоднократно с последующими советами понавставлять по коду GC.Collect G>>>Мда... Перечитайте лучше форумы. H>>Мне-то это зачем? У меня таких проблем нет и небыло никогда... G>Это еще раз показывает что вы кроме делфи ничего толком не знаете.
Ты обо мне поговорить хочешь?
H>>>>Под Delphi я и имел ввиду компилятор (а что же еще-то может за этим следить...). G>>>В .NET следит рантайм. H>>Мы не о .Net тут говорим, если я не ошибаюсь. G>Мы тут сравниваем Delphi с другими языками и платформами. Достоинства и недостатки видны только в сравнении с другими
Ты нить теряешь...
H>>>>Семантика для работы с интерфейсными классами и с обычными может быть одинаковой (см. TComponent). Но все это тонкости дающие большую гибкость. И необъяснимые глюки это может вызвать только там, где программист работает сам незная с чем (или не до конца понимая механизм). G>>>В C# люди работают, не зная с чем, и баги не возникают почему-то. H>> уморил. G>Может тебе и смешно, а я уже успел почуствовать насколько меньше люди ошибатся с использованием C# и Java, по сравнению с темже Delphi G>Причем среднее всермя обучения C# гораздо меньше чем для Delphi
Да-да. Я это уже слышал и не раз. За короткий срок невозможно научиться грамотно программировать на чем-бы то нибыло. Я соглашусь, что двоечнику после Delphi-AccessViolation'ов будет легче под .Net/Java. Однако создавать качественного продукта он не сможет. Пердульки бухгалтерские его удел. Максимум.
G>>>Я ловил сотни ошибоки из-затого что люди забывали/не_знали_что_надо вызывать Free. В Управляемых средах вообще таких проблем нет. Придирки вполе по делу. Вы просто не понимаете, потому что не работали с этим. H>>Если люди чего-то там не знали/забывали, это характеризует только их, но не инструмент. Если выражаться простым языком: не можешь срать -- не мучай жопу. В управляемых средах, таки, есть место ручной очистке (пусть даже семантически скрываемой) для объектов владеющих ресурсами. Что начнется, когда человек, который работает не зная с чем (с твоих же слов), будет следовать навязываемой идеологии... G>Какой-то бред, в чем смысл вашего высказывания?
Ты теряешь не только нить...
H>>>>Какая разница кто-кого догоняет или откуда заимствуются те или иные фичи? Ты тут о минусах говорил, я же тебе на плюсы указываю. G>>>Эти плюсы не перекрывают минусы. А в других языках и платформах минусов поменьше. H>>В других платформах есть тормоза неизвестно откуда появляющиеся, но теория их существование отрицает G>Что дороже покупка в два раза более мощногокомпьютера или в два раза больше времени работы программиста?
Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем.
H>>Мы тут, что С++ обсуждаем или Java? Ты сказал, что в Delphi чего-то нет. Я тебе говорю, что есть (может оно и в семерке уже было, я не помню). G>Перечитай первые посты. Идет сравнение Delphi c другими популярными сейчас языками и платформами.
Уж не знаю, как ты, а я твои безосновательные выпады парирую.
G>Если вам так нарвится делфи, то откройте ветк в которой опишите чем вам так нравится программировать на Delphi. Желательно в КУ.
Мне оно надо? У меня фетиша-то нету, в отличии от...
G>ЗЫ Можем вспонить web. какие у делфи возможности создания web-приложений? Правильно — никаких!!!! Это удар ниже пояса.
Хотя Delphi и не среда для веб-разработчика, но имеется WebSnap, Intraweb, WebServices. Ты некомпетентен.
Здравствуйте, Mamut, Вы писали:
M>>>И сколько 7-ка стоит?
H>>Я не понял к чему вопрос... Вроде не продают ее уже.
M>Я о том, что очень мелкие изменения/добавления/исправления оказываются в сильно разных версиях. Так никаких денего не напасешься
Так ведь можно не покупать все время Enterprise. Потом цена апдейта не сильно большая, насколько я помню. И уж разумеется никто не станет покупать новую версию из-за наличия контейнерной библы. С пятерки на шестерку поползли по причине ее кросплатформенной составляющей и веб-сервисов. На семерку... Не помню нафига поползли Но вообще ты прав, деньги они любят и маркетинг дурацкий был все последние годы.
Здравствуйте, kuj, Вы писали:
W>>В Delphi нет пост/прекрементов, но это не напрягает и имхо это вообще наследие архитектуры PDP-11, где пост/прекременты поддерживались на уровне системы команд процессора.
kuj>
kuj>int x = 3;
kuj>x += x++;
kuj>
kuj>Вопрос: чему равен x?
Не так интересно что получится, сколько отвечает ли стандарт языка на этот вопрос? Кстати, если склероз не изменяет в ассемблере PDP-11 таких двусмысленностей не было, были "приёмчики" типа
CMP -(SP),-(SP)
Вопрос: что делает эта инструкция?
[Самым эффективным образом резервирует в стеке 4 байта ]
---
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true
Здравствуйте, goto, Вы писали:
G>Если говорить абстрактно, то не знаю, ибо есть мобилы, интеллектуальные пылесосы и крылатые ракеты. Лично на моем огороде все пожрал жук писюк.
Здравствуйте, hattab, Вы писали:
H>Да-да. Я это уже слышал и не раз. За короткий срок невозможно научиться грамотно программировать на чем-бы то нибыло. Я соглашусь, что двоечнику после Delphi-AccessViolation'ов будет легче под .Net/Java. Однако создавать качественного продукта он не сможет. Пердульки бухгалтерские его удел. Максимум.
Что в твоем понимании качественный продукт?
Я видел бухгалтерскую программу на C#, клон программы на Delphi. На шарпе она быстрее работала, была более стабильна и стоила в 2 раза дешевле.
H>Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем.
Ты не путай, для коробочного продукта примерные параметры по быстродействию известны заранее и продукт не выпустят если не программа не пройдет по этим параметрам. Для ПО, разрабатываемого на заказ бывает выгоднее поменять железо, чем оплачивать работу десятка программистов.
Тем боее саме серьезные потери производительности происходят в основном не по вине платформы, а вследствие неправльного выблора/реализации алгоритмов.
H>Хотя Delphi и не среда для веб-разработчика, но имеется WebSnap, Intraweb, WebServices. Ты некомпетентен.
Ну напиши с помощью этого всего веб-страницу, которя выводи текущее время.
Здравствуйте, misha_irpen, Вы писали:
_>Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин? ... неужели всм оказалась так нужна эта управляемость кода?
1)Внимание, сейчас скажу пошлость Кроссплатформенность на уровне "дистрибутива". Конечно, с определенными оговорками и ограниченими, но она есть. В качестве примера гляньте antlr, flex sdk. Как итог — не надо компилить "продукт" под все возможные платформы.
PS: Я не дурак и понимаю, что в реальности не все так просто.
2)Рефлекшн — полезная штука как ни крути. Кстати, думаю, во многом благодаря оному Java и .NET неплохо чувствуют себя в сфере веб-программирования, в отличие от неуправляемых языков. Ну-ка как будет выглядеть шаблонизатор, навроде Velocity на неуправляемом языке? Это к вопросу о... _>...могу считать себя профессионалом Delphi и ASM. И у меня приактически никогда не возникало проблем из-за каких-то ограничений языка. Я с уверенностью могу сказать, что могу написать на нем абсолютно все что угодно в рамках имеющихся API и математических моделей.
Я не сомневаюсь, что это реализуемо, однако насколько это будет удобно?
3)Простите за тавтологию, "управляемость". Согласитесь, тоже хорошая такая задачка — организовать песочницу для неуправляемого кода. Собственно, там, где нужна песочница (например, в том, что сейчас модно называть rich internet application), и рулят управлемые платформы: flash/flex, silverlight, java.
Собственно, к чему я веду. Управляемость в целом ведет к расширению области применения языка/платформы — и это есть гут. То есть используя практически одну и ту же управляемую платформу, программист может и десктопные приложения разрабатывать, и RIA, и с вебом возиться. Ясно, что различия будут, но не такие большие, как если бы приходилось пользоваться просто различными инструментами. Итого девелоперу, освоившему "десктопный аспект" управляемой платформы, будет легче освоить, например, веб. Что в конечном счете расширяет круг его возможностей.
Ну а по остальной части вопроса... Мне уж и добавить к уже сказанному особо нечего.
Здравствуйте, kuj, Вы писали:
kuj>>>Не может быть никаких фризов. Сборщик муссора ведь не в главном потоке приложения выполняется.
H>>Суслика видишь? Нет. А он есть (c) ДМБ. А сборщику не нужно лочить кучу, чтоб дефрагментацию делать? А процы уже у всех поголовно двух/четырех головые?
kuj>То, чего пользователь не видит для него не существует. Это только то, что имеет значение.
Я в WindowsLiveWriter наблюдаю периодические фризы. Не стану утверждать, что это GC или JIT. Но они есть.
kuj>Что до процессоров — наши .NET 2.0 и 3.5 сборки крутятся на довольно старых компьютерах. На производительность и тем более фризы никто пока не жаловался.
kuj>Вот, кстати, почитай http://msdn.microsoft.com/en-us/library/ms973837.aspx#dotnetgcbasics_topic4
Я о работе сборщика читал У меня же предубеждения к .Net'у нет.
kuj>>>В общем случае это таки недостаток. Особенно, когда нет в наличии generic smart pointer`ов (прерогатива C++).
H>>Так в чем недостаток-то?
kuj>В том, что GC один на всех. Если один процесс пнет его — очисти кучу в то время, как другой процесс нагружает его alloc`ами, то что произойдет? GC сам должен регулировать этот процесс, чтоб для пользователя он был абсолютно незаметным.
Мы точно о Delphi говорим? Какие там разные процессы? Или ты про разные Delphi-процессы? Там же нет такого отдельного понятия, как GC в .Net/Java. Просто есть типы с управляемым временем жизни. Вышла переменная из области видимости -- компилер ее тут же зафиналил. Все просто и эффективно.
kuj>>>Без полноценного DI в Delphi толку от интерфейсов куда как меньше.
H>>Чего-то не улавливаю связи...
kuj>Я писал где-то в этом топике. Вся сила интерфейсов раскрывается при наличии полноценного DI/IoC контейнера.
Все это сильно зависит от способа применения и изобретательности
Здравствуйте, hattab, Вы писали:
H>>>Видимо. И не только мне. На форумах обсуждалось неоднократно с последующими советами понавставлять по коду GC.Collect
kuj>>Ссылки в студию.
H>Я их не коллекционирую. На хоботе было обсуждение написанного прокси у которого именно фризы и лезли после долгостояния Тут тоже где-то в веб-программировании было нечто подобное.
Называется: слышал звон, да не знаю где он?
H>>>Это с возвратом созданного объекта чтоль? Ну и в чем проблема? Вот GetMem/VirtualAlloc тоже сырую память отдают и ее возвращать нужно. Не смущает? На самом деле ни какой проблемы в этом нет, объекты, как правило создаются для хранения в каких-либо коллекциях/списках и прочих. И уж точно нет ни какого напряга дернуть Free. Придирки, и не более того.
kuj>>Ты забываешь о человеческом факторе.
H>Человеческий фактор отмазка хорошая Кто-то заставляет работать с такими представителями рода человеческого? Delphi 2006 благодаря новому менеджеру памяти исправно сигналит обо всех утечках.
Человеческий фактор это не отмазка, а основной мотивирующий момент при разработке языков программирования.
H>>>Уж не про LINQ ли ты говоришь Ну в 2008 или 2009 обещают анонимные методы добавить еще.
kuj>>Lambda, linq, implicitly typed variables (я, правда, несколько негативно к идеи применения var отношусь, но это тема для отдельного разговора), extension methods, annonymous types, auto properties, type inference, object и collection initializers...
H>И правда, тут об этом не стоит О Delphi таки говорим.
Все познается в сравнении.
H>>>>>Списки (различные), стеки, очереди, бит-контейнеры, ассоциативные массивы. Мало? G>>>>Это оно когда появилось? Случаем не в Delphi.NET ? H>>>В нативной 2006 точно есть. Может и в 2005 было, я не помню. kuj>>Только без generic`ов ОЙ как плохо.
H>Не сильно, если честно
H>Для Delphi 2006 есть неофициальный тул (по сути препроцессор) который реализует много чего: и дженерики, и case по строкам, и exit с возвратом результата. В общем кому нужно -- тот найдет.
MC>2)Рефлекшн — полезная штука как ни крути. Кстати, думаю, во многом благодаря оному Java и .NET неплохо чувствуют себя в сфере веб-программирования, в отличие от неуправляемых языков.
Рефлекшн в Дельфи всегда был
Здравствуйте, dcb-BanDos, Вы писали:
DB>а ты синтаксис видел?!
Нет, не видел. Писал десять лет, а синтаксиса как-то не разглядел
Все-таки я смотрю на синтаксис тоже много наездов. Но тут мои взгляды крайне противоположные. Мне очень не нравится write-only код всех сиподобнх языков, пусть он и дает большую гибкость, но цель не ИМХО оправдывеет средства.
Хоть ныне я уже не програмлю так много как раньше, тем не менее нахожусь в глухой оппозиции ко всему C-подомному и когда меня заставляют (люди или обстоятельства) писать на таком языке (чаще всего это PHP, JS и т.п. скрипты), то я становлюсь очень злой и использую все сишные синтаксические штучки-дрючки везде где это хоть малость оправдвно. Если конструкция типа a[i]+=(j=++i) сэкономит мне хоть одну строчку кода, то я использую ее без зазрений совести. Ибо нефиг. И пусть потом тот сишник, который будет этот код читать, прочувствует на собственной шкуре смысл поговорки "за что боролся, на то и напоролся".
Здравствуйте, Mamut, Вы писали:
M>Я о том, что очень мелкие изменения/добавления/исправления оказываются в сильно разных версиях. Так никаких денего не напасешься
На самом деле недорого. Регулярный Upgrade для версии Professional (а мне больше не надо) обходится где-то около 20000 рублей/год. Да и не обязательно его каждый год делать. Да и платишь не сам, а твой работодатель.
---
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true
Здравствуйте, gandjustas, Вы писали:
H>>Да-да. Я это уже слышал и не раз. За короткий срок невозможно научиться грамотно программировать на чем-бы то нибыло. Я соглашусь, что двоечнику после Delphi-AccessViolation'ов будет легче под .Net/Java. Однако создавать качественного продукта он не сможет. Пердульки бухгалтерские его удел. Максимум. G>Что в твоем понимании качественный продукт? G>Я видел бухгалтерскую программу на C#, клон программы на Delphi. На шарпе она быстрее работала, была более стабильна и стоила в 2 раза дешевле.
Я тоже могу рассказать, что видел Ты мне поверишь? Читать здесь
H>>Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем. G>Ты не путай, для коробочного продукта примерные параметры по быстродействию известны заранее и продукт не выпустят если не программа не пройдет по этим параметрам. Для ПО, разрабатываемого на заказ бывает выгоднее поменять железо, чем оплачивать работу десятка программистов. G>Тем боее саме серьезные потери производительности происходят в основном не по вине платформы, а вследствие неправльного выблора/реализации алгоритмов.
Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно)
H>>Хотя Delphi и не среда для веб-разработчика, но имеется WebSnap, Intraweb, WebServices. Ты некомпетентен. G>Ну напиши с помощью этого всего веб-страницу, которя выводи текущее время.
Ты знаешь, для меня веб-разработка, где-то очень далеко за горизонтом В демосах есть примеры реализации интернет магазинов/каталогов. Посмотри, если интересно. У Борланда QualityCentral работает на этом.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, Константин Б., Вы писали:
КБ>>Ну лично мне не нравится глючность IDE. 5-я вроде как самая стабильная была...
DOO>Если сравнивать Delphi 6 и VS 6, то Delphi явно и стабильнее и удобнее
Ну можно и похуже образец для сравнения найти Впрочем мне VS6 никогда не нравилась. Одно отсутствие ClearType'а чего стоит. Но даже в VS6 я не ловил Internal Compiler Error так часто как в дельфи. Ну и уж точно никогда не удавалось довести VS6 до такого состояния чтобы она падала при создании нового пустого проекта. Наверняка это исключительно мой личный опыт, но основания для неприязни у меня есть
Здравствуйте, kuj, Вы писали:
kuj>>>Ссылки в студию.
H>>Я их не коллекционирую. На хоботе было обсуждение написанного прокси у которого именно фризы и лезли после долгостояния Тут тоже где-то в веб-программировании было нечто подобное.
kuj>Называется: слышал звон, да не знаю где он?
А ты думал я сейчас побегу на хобот искать Я же не пытаюсь тебе чего-то доказать.
kuj>>>Ты забываешь о человеческом факторе.
H>>Человеческий фактор отмазка хорошая Кто-то заставляет работать с такими представителями рода человеческого? Delphi 2006 благодаря новому менеджеру памяти исправно сигналит обо всех утечках.
kuj>Человеческий фактор это не отмазка, а основной мотивирующий момент при разработке языков программирования.
Сильно спорный тезис. Скорее более проблемное ориентирование, нежели человеческий фактор. Для фактора всегда можно пропиарить идею гоблинов не следящих за ресурсами, назвать их недочеловеками и паства будет дружно кивать головкой. А можно и наоборот Как удобнее в данный момент.
H>>>>Уж не про LINQ ли ты говоришь Ну в 2008 или 2009 обещают анонимные методы добавить еще.
H>>И правда, тут об этом не стоит О Delphi таки говорим. kuj>Все познается в сравнении.
И чего теперь, роадмапами меряться?
H>>>>>>Списки (различные), стеки, очереди, бит-контейнеры, ассоциативные массивы. Мало? G>>>>>Это оно когда появилось? Случаем не в Delphi.NET ? H>>>>В нативной 2006 точно есть. Может и в 2005 было, я не помню. kuj>>>Только без generic`ов ОЙ как плохо.
H>>Не сильно, если честно kuj>
Ну, по личным ощущениям. Хотя мне идея дженериков нравится. Но есть идею которые нравятся больше
H>>Для Delphi 2006 есть неофициальный тул (по сути препроцессор) который реализует много чего: и дженерики, и case по строкам, и exit с возвратом результата. В общем кому нужно -- тот найдет.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Да-да. Я это уже слышал и не раз. За короткий срок невозможно научиться грамотно программировать на чем-бы то нибыло. Я соглашусь, что двоечнику после Delphi-AccessViolation'ов будет легче под .Net/Java. Однако создавать качественного продукта он не сможет. Пердульки бухгалтерские его удел. Максимум. G>>Что в твоем понимании качественный продукт? G>>Я видел бухгалтерскую программу на C#, клон программы на Delphi. На шарпе она быстрее работала, была более стабильна и стоила в 2 раза дешевле.
H>Я тоже могу рассказать, что видел Ты мне поверишь? Читать здесь
Неужто так все плохо у Делфи, что была надобность этот wiki писать?
H>>>Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем. G>>Ты не путай, для коробочного продукта примерные параметры по быстродействию известны заранее и продукт не выпустят если не программа не пройдет по этим параметрам. Для ПО, разрабатываемого на заказ бывает выгоднее поменять железо, чем оплачивать работу десятка программистов. G>>Тем боее саме серьезные потери производительности происходят в основном не по вине платформы, а вследствие неправльного выблора/реализации алгоритмов.
H>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно)
Это с какой это радости-то?
H>>>Хотя Delphi и не среда для веб-разработчика, но имеется WebSnap, Intraweb, WebServices. Ты некомпетентен. G>>Ну напиши с помощью этого всего веб-страницу, которя выводи текущее время.
H>Ты знаешь, для меня веб-разработка, где-то очень далеко за горизонтом В демосах есть примеры реализации интернет магазинов/каталогов. Посмотри, если интересно. У Борланда QualityCentral работает на этом.
Только все это прошлый век на фоне современных web-приложений .net и java.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, DOOM, Вы писали: DOO>>Рефлекшн в Дельфи всегда был
MC>Не знал . А пример можно?
Пример использования:
Begin
FReturnInfo.Handler := GeneralReturnHandler;
If (GetTypeData(AReturnInfo.ReturnType^).BaseType^ = TypeInfo(Boolean)) Or
(GetTypeData(AReturnInfo.ReturnType^).BaseType^ = TypeInfo(WordBool)) Or
(GetTypeData(AReturnInfo.ReturnType^).BaseType^ = TypeInfo(LongBool)) Then
FReturnInfo.Types := [xrtBoolean]
Else
FReturnInfo.Types := [xrtInt32];
End;
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, DOOM, Вы писали:
DOO>>Здравствуйте, Константин Б., Вы писали:
КБ>>>Ну лично мне не нравится глючность IDE. 5-я вроде как самая стабильная была...
DOO>>Если сравнивать Delphi 6 и VS 6, то Delphi явно и стабильнее и удобнее
КБ>Ну можно и похуже образец для сравнения найти
Ну они просто погодки, так сказать.
КБ>Но даже в VS6 я не ловил Internal Compiler Error так часто как в дельфи.
Ни разу не видел
КБ>Ну и уж точно никогда не удавалось довести VS6 до такого состояния чтобы она падала при создании нового пустого проекта.
Кривой компонент? А вообще, мне удавалось довести до такого состояния VS
Здравствуйте, hattab, Вы писали:
H>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно)
Хо-хо-хо. Сколько стоит экспресс версия Visual С#? Не поверишь — нисколько. А продуктивность программистов на шарпе гораздо выше, чем на делфях (сравниваю с 7 версией, но из написанного понятно что даже современные версии не догоняют).
Как раз языки и платформы имеет смысл сравнивать не в формате нравится\не нравится, а в количественном измерении: "стоимость" программистов, стоимость обучения программистов, среднее время разработки, средняя плотность багов.
H>Ты знаешь, для меня веб-разработка, где-то очень далеко за горизонтом
А зря. Дядька Фаулер еще в 2003 году сказал что если нет особых причин разрабатывать desktop клиент для корпоративного приложения, то лучше сразу заниматься веб-мордой. Web уже давно не только сайты знакомств и порнуха. Ты отстатешь от прогресса.
Здравствуйте, kuj, Вы писали:
H>>Я тоже могу рассказать, что видел Ты мне поверишь? Читать здесь
kuj>Неужто так все плохо у Делфи, что была надобность этот wiki писать?
Видимо для наезжающих Боюсь, для .Net такое еще очень нескоро появится
H>>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно)
kuj>Это с какой это радости-то?
Ну во прикинь на каких машинках захочет работать .Net FW 3.0, а 4.0? А потом захочет Висту. Ну дальше развивать не буду пожалуй
H>>Ты знаешь, для меня веб-разработка, где-то очень далеко за горизонтом В демосах есть примеры реализации интернет магазинов/каталогов. Посмотри, если интересно. У Борланда QualityCentral работает на этом.
kuj>Только все это прошлый век на фоне современных web-приложений .net и java.
SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java?
Здравствуйте, hattab, Вы писали: H>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java?
Речь не о SOAP-сервисах, а о создании веб-морд. Т.е. упрощенно — когда есть HTML-шаблоны и java/.net код, который на их основе хитро генерит динамические страницы. Ну, короче, как в php.
Здравствуйте, hattab, Вы писали:
H>>>Я их не коллекционирую. На хоботе было обсуждение написанного прокси у которого именно фризы и лезли после долгостояния Тут тоже где-то в веб-программировании было нечто подобное.
kuj>>Называется: слышал звон, да не знаю где он?
H>А ты думал я сейчас побегу на хобот искать Я же не пытаюсь тебе чего-то доказать.
Хотя это и повсеместная практика на КСВ, но все-таки это не хорошо кидаться безосновательными утверждениями...
kuj>>>>Ты забываешь о человеческом факторе.
H>>>Человеческий фактор отмазка хорошая Кто-то заставляет работать с такими представителями рода человеческого? Delphi 2006 благодаря новому менеджеру памяти исправно сигналит обо всех утечках.
kuj>>Человеческий фактор это не отмазка, а основной мотивирующий момент при разработке языков программирования.
H>Сильно спорный тезис.
Ты это серьезно?
H>>>>>Уж не про LINQ ли ты говоришь Ну в 2008 или 2009 обещают анонимные методы добавить еще.
H>>>И правда, тут об этом не стоит О Delphi таки говорим.
kuj>>Все познается в сравнении.
H>И чего теперь, роадмапами меряться?
При чем тут роадмапы?
В OP речь шла о сравнении Delphi с современными управляемыми средами типа Java и .Net
H>>>>>>>Списки (различные), стеки, очереди, бит-контейнеры, ассоциативные массивы. Мало? G>>>>>>Это оно когда появилось? Случаем не в Delphi.NET ? H>>>>>В нативной 2006 точно есть. Может и в 2005 было, я не помню. kuj>>>>Только без generic`ов ОЙ как плохо.
H>>>Не сильно, если честно kuj>> H>Ну, по личным ощущениям. Хотя мне идея дженериков нравится. Но есть идею которые нравятся больше
При чем тут идеи? Generics это вполне конкретный механизм, значительно повышающий читабельность и эффективность (производительность, качество) кода.
Поясняю: препроцессорная реализация это костыль. Имея generics на языковом уровне я получаю все плюшки статически типизированной среды разработки: intellisense, refactoring и прочее.
Пример:
Dictionary<string, string> d = new ...
d["key"] = "value";
Теперь, если бы я написал:
d["key 2"] = 1;
то среда разработки бы автоматически на лету "указала" ошибку в этой строке: мол, окстись мужик! ты не можешь присвоить значение типа int, так как ожидается значение типа string!
Здравствуйте, DOOM, Вы писали:
L>>1. Объявление переменных в месте использования. Не критично, но ползти в var неприятно. DOO>На вкус и цвет — когда в одном месте, оно читабельнее.
Чем читабельнее? Особенно, когда временных много.
L>>2. Переопределяемых операторов. Часто сложная математика выглядит с ними привычнее. DOO> Читать потом тяжко...
DOO>CString str;
DOO>...
DOO>(char *)str //вот и пойми, что это перегруженный оператор на самом деле :xz:
Во-первых, уж тогда static_cast<const char*>, а то Вы ещё и const снесли. Во-вторых — оно в каких случаях нужно-то?
L>>3. Вынесу отдельно — возможности построения типов с поведением, как у стандартных. DOO>А подробнее? Вроде все строилось как надо...
С большими числами, с особоточными числами, с тензорами формулы записывать не пробовали?
L>>4. Препроцессор. Да его ругают, но лучше иметь возможность его использовать. DOO>Используй внешний (и отлаживаться проще).
Так тут вопрос в том, что есть выбор.
Ну это, кстати, всё мелочи. По основным пунктам возражений что лучше нет?
Здравствуйте, hattab, Вы писали:
L>>Видимо имелось в виду то, что формат dfm-а время от времени перестает пониматься более новой версией IDE.
H>Если мне не изменяет память, это было один раз при смене формата .dfm. Так и то, в поставку была включена утиль для конвертирования.
Здравствуйте, kuj, Вы писали:
L>>Видимо имелось в виду то, что формат dfm-а время от времени перестает пониматься более новой версией IDE.
kuj>Microsoft движется (хоть и медленно) в правильном направлении со своим Visual Studio — начиная с VS 2005 все файлы проектов C# и VB это не что иное, как xml-скрипт msbuild. Солюшен VS 2005 можно собрать без самого VS 2005 — просто вызвав msbuild <name>.sln, где msbuild идет в поставке с .NET Framework, начиная с .NET 2.0. kuj>Msbuild сам по себе фактически полный аналог (функционально) nAnt`у. Позволяет писать фактически какой угодно сложности сценарии по сборке, тестированию и deploying`у.
Я очень рад, что ты это знаешь, но при чем тут это?
Здравствуйте, hattab, Вы писали:
H>Ну во прикинь на каких машинках захочет работать .Net FW 3.0, а 4.0? А потом захочет Висту. Ну дальше развивать не буду пожалуй
.NET Framework бесплатен, кто мешает положить вместе с дистрибутевом фреймворк?
H>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java?
Хуже. В WCF можно параметры сервиса (протоколы и пр.) поменять в конфиге, не трогая код.
Здравствуйте, hattab, Вы писали:
H>>>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно)
kuj>>Это с какой это радости-то?
H>Ну во прикинь на каких машинках захочет работать .Net FW 3.0, а 4.0? А потом захочет Висту. Ну дальше развивать не буду пожалуй
Ну захочет Висту и что? К тому времени XP давно уже не будет продаваться и скорее всего уже будет Windows 7...
.NET 2.0 работает себе на древней Windows 98, которой уже ОЙ как много лет...
К тому же все это копейки на фоне стоимости разработки и сопровождения.
Как в Delphi обстоят дела с unit test`ами? О каком scalability приложения может вообще идти речь, когда нет ни unit test`ов, ни DI/IoC?...
H>>>Ты знаешь, для меня веб-разработка, где-то очень далеко за горизонтом В демосах есть примеры реализации интернет магазинов/каталогов. Посмотри, если интересно. У Борланда QualityCentral работает на этом.
kuj>>Только все это прошлый век на фоне современных web-приложений .net и java.
H>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java?
Web-приложения это далеко не только SOAP и таки да — хуже, так как сложнее в разработке и сопровождении. По вышеозначенным причинам.
Здравствуйте, lifrsdn, Вы писали:
L>Здравствуйте, DOOM, Вы писали:
L>>>1. Объявление переменных в месте использования. Не критично, но ползти в var неприятно. DOO>>На вкус и цвет — когда в одном месте, оно читабельнее.
L>Чем читабельнее? Особенно, когда временных много.
Тем и читабельнее. Почему-то в исходники самбы, написанной на C я могу въехать за пару тройку часов, а в среднестатистическую C++'ную программу и за пару дней не въеду.
Временные переменные при этом есть везде — но вот возможность на каждый блок объявить свою, как ни странно, сильно захламляет код.
L>>>2. Переопределяемых операторов. Часто сложная математика выглядит с ними привычнее. DOO>> Читать потом тяжко... L>
DOO>>CString str;
DOO>>...
DOO>>(char *)str //вот и пойми, что это перегруженный оператор на самом деле :xz:
L>
L>Во-вторых — оно в каких случаях нужно-то?
Что конкретно? Понять, что это перегруженный оператор? Это нужно когда читаешь/модифицируешь чужой код.
L>>>3. Вынесу отдельно — возможности построения типов с поведением, как у стандартных. DOO>>А подробнее? Вроде все строилось как надо... L>С большими числами, с особоточными числами, с тензорами формулы записывать не пробовали?
А все понял, что имелось ввиду...
L>>>4. Препроцессор. Да его ругают, но лучше иметь возможность его использовать. DOO>>Используй внешний (и отлаживаться проще). L>Так тут вопрос в том, что есть выбор.
Дак тут замечание о том, что препроцессор к языку отношения не имеет (хотя к IDE имеет, не спорю).
L>Ну это, кстати, всё мелочи. По основным пунктам возражений что лучше нет?
А каким основным?
Про деструкторы? Что-то есть — я просто сейчас уже точно не смогу грамотно на эту тему поспорить.
Про обязательность вызова конструктора как-то не понял, что имелось ввиду.
Шаблоны — на вкус и цвет. Мне они как-то не нравились в свое время.
Про оптимизатор на уровне Intel C++ — ну и сколько процентов народу используют этот компилятор? А у остальных тоже не такие уж выдающиеся результаты по сравнению с ним.
Здравствуйте, DOOM, Вы писали:
TEO>>Кто-нибудь может то же самое написать для Delphi?
DOO>Еще раз: криптосинтаксис лучше всего развит в перле. Приведенное выше — детский лепет, по сравнению хотя бы с этим:
Здравствуйте, Mr.Cat, Вы писали:
MC>Не знал . А пример можно?
На всякий случай напомню, что автор Delphi (точнее, Object Pascal) перешел из инпрайз в майкрософт и последние много лет занимается разработкой языка C# и оказывает влияние на всю .Net платформу.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, goto, Вы писали:
G>Сей ужас был в основном пораньше, > 10 лет назад. Из-за этого, в частности, многие вещи, совершенно не вычислительные, когда-то даже писали на FORTRAN IV, это был едва ли не единственный общий знаменатель. Потом им стал С.
Там где я начинал трудовую деятельность мейнфрейм (IBM/360) сдали на металлолом около 15 лет назад. Кстати, в нём была куча драгметаллов, вырученных денег хватило на несколько самых современных по тем временам персоналок. А cофт (в основном Кобол, меньше — Фортрана и PL) переводили на FoxPro, когда я оттуда уволился.
---
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, hattab, Вы писали:
H>>Пример использования: H>>
H>> <skip>
H>>
MC>Ага, пасиб. А можно, например, зная имя класса, получить экземпляр этого класса? Как Class.forName() плюс Class.newInstance() в Java?
Можно. Для потомков TPersistent даже RTTI не требуется, это штатное поведение. Через RTTI тоже можно, с условием, что у класса будет виртуальный конструктор. Но даже и без этого условия можно, только будет сильно сложнее.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, hattab, Вы писали: H>>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java?
MC>Речь не о SOAP-сервисах, а о создании веб-морд. Т.е. упрощенно — когда есть HTML-шаблоны и java/.net код, который на их основе хитро генерит динамические страницы. Ну, короче, как в php.
WebSnap. Ребята, оно было еще в 6 версии. Intraweb еще круче
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, TheEvilOne, Вы писали:
TEO>>Кто-нибудь может то же самое написать для Delphi?
DOO>Еще раз: криптосинтаксис лучше всего развит в перле. Приведенное выше — детский лепет, по сравнению хотя бы с этим:
<skip>
Я против перла ничего не имею и не говорил. Только вот Вы забыли, откуда что взялось.
По поводу детского лепета — то же самое можно сказать и о приведенной Вами программе.
Здравствуйте, hattab, Вы писали:
kuj>>>>Не может быть никаких фризов. Сборщик муссора ведь не в главном потоке приложения выполняется.
H>>>Суслика видишь? Нет. А он есть (c) ДМБ. А сборщику не нужно лочить кучу, чтоб дефрагментацию делать? А процы уже у всех поголовно двух/четырех головые?
kuj>>То, чего пользователь не видит для него не существует. Это только то, что имеет значение.
H>Я в WindowsLiveWriter наблюдаю периодические фризы. Не стану утверждать, что это GC или JIT. Но они есть.
Я тебе как разработчик .Net с 99% вероятностью скажу, что фризы эти, если они и имеют место, не имеют отношения к GC.
kuj>>В том, что GC один на всех. Если один процесс пнет его — очисти кучу в то время, как другой процесс нагружает его alloc`ами, то что произойдет? GC сам должен регулировать этот процесс, чтоб для пользователя он был абсолютно незаметным.
H>Мы точно о Delphi говорим?
Конечно нет. В Delphi (не .NET) нет GC.
H>Какие там разные процессы? Или ты про разные Delphi-процессы? Там же нет такого отдельного понятия, как GC в .Net/Java. Просто есть типы с управляемым временем жизни. Вышла переменная из области видимости -- компилер ее тут же зафиналил. Все просто и эффективно.
Ты не путай GC и недо- smart pointers.
В C++, например, есть реализация smart pointers (в boost), базирующаяся на подсчете ссылок. Это куда эффективнее области видимости.
kuj>>>>Без полноценного DI в Delphi толку от интерфейсов куда как меньше.
H>>>Чего-то не улавливаю связи...
kuj>>Я писал где-то в этом топике. Вся сила интерфейсов раскрывается при наличии полноценного DI/IoC контейнера.
H>Все это сильно зависит от способа применения и изобретательности
Здравствуйте, TheEvilOne, Вы писали:
TEO>Здравствуйте, DOOM, Вы писали:
DOO>>Здравствуйте, TheEvilOne, Вы писали:
TEO>>>Кто-нибудь может то же самое написать для Delphi?
DOO>>Еще раз: криптосинтаксис лучше всего развит в перле. Приведенное выше — детский лепет, по сравнению хотя бы с этим: TEO><skip> TEO>Я против перла ничего не имею и не говорил. Только вот Вы забыли, откуда что взялось.
Откуда? Ларри Волл вообще-то лингвист, скорее всего именно поэтому перл такой "не такой".
TEO>По поводу детского лепета — то же самое можно сказать и о приведенной Вами программе.
Ну дак это был самый древний пример
Вот уже более прикольная штука:
L>>>>1. Объявление переменных в месте использования. Не критично, но ползти в var неприятно. DOO>>>На вкус и цвет — когда в одном месте, оно читабельнее.
L>>Чем читабельнее? Особенно, когда временных много. DOO>Тем и читабельнее. Почему-то в исходники самбы, написанной на C я могу въехать за пару тройку часов, а в среднестатистическую C++'ную программу и за пару дней не въеду.
Тогда уж сравнивай среднестатистическую C со среднестатистической C++... Хотя это из разряда сферических коней...
DOO>Временные переменные при этом есть везде — но вот возможность на каждый блок объявить свою, как ни странно, сильно захламляет код.
Не согласен.
DOO>Шаблоны — на вкус и цвет. Мне они как-то не нравились в свое время.
Здравствуйте, hattab, Вы писали:
MC>>Речь не о SOAP-сервисах, а о создании веб-морд. Т.е. упрощенно — когда есть HTML-шаблоны и java/.net код, который на их основе хитро генерит динамические страницы. Ну, короче, как в php.
H>WebSnap. Ребята, оно было еще в 6 версии. Intraweb еще круче
Хочу полноценный MVC с unit test`ами и расширяемым view-engine по типу Brail (из Castle Monorail)! Где?
Здравствуйте, Lloyd, Вы писали:
L>>>Видимо имелось в виду то, что формат dfm-а время от времени перестает пониматься более новой версией IDE.
kuj>>Microsoft движется (хоть и медленно) в правильном направлении со своим Visual Studio — начиная с VS 2005 все файлы проектов C# и VB это не что иное, как xml-скрипт msbuild. Солюшен VS 2005 можно собрать без самого VS 2005 — просто вызвав msbuild <name>.sln, где msbuild идет в поставке с .NET Framework, начиная с .NET 2.0. kuj>>Msbuild сам по себе фактически полный аналог (функционально) nAnt`у. Позволяет писать фактически какой угодно сложности сценарии по сборке, тестированию и deploying`у.
L>Я очень рад, что ты это знаешь, но при чем тут это?
Здравствуйте, kuj, Вы писали:
kuj>>>Называется: слышал звон, да не знаю где он?
H>>А ты думал я сейчас побегу на хобот искать Я же не пытаюсь тебе чего-то доказать.
kuj>Хотя это и повсеместная практика на КСВ, но все-таки это не хорошо кидаться безосновательными утверждениями...
Прикольная практика это ссылки просить по всякому поводу. Где же мне их помнить, истории уж полгода если не больше...
kuj>>>Человеческий фактор это не отмазка, а основной мотивирующий момент при разработке языков программирования.
H>>Сильно спорный тезис.
kuj>Ты это серьезно?
Я же упомянул о сигналящем менеджере. Что еще фактору нужно? Нужно в смирительную рубашку погрузить тело бренное, чтоб не дай бог глаз вилкой не выколол... Есть инструмент контроля. О чем тут спорить еще?
kuj>>>Все познается в сравнении.
H>>И чего теперь, роадмапами меряться?
kuj>При чем тут роадмапы? kuj>В OP речь шла о сравнении Delphi с современными управляемыми средами типа Java и .Net
Так ты перечислил что будет в C# 4.0. Вот когда оно будет, и когда в Delphi будет то о чем я тут говорил, тогда и можно мечами побряцать.
kuj>>>>>Только без generic`ов ОЙ как плохо.
H>>>>Не сильно, если честно kuj>>> H>>Ну, по личным ощущениям. Хотя мне идея дженериков нравится. Но есть идею которые нравятся больше
kuj>При чем тут идеи? Generics это вполне конкретный механизм, значительно повышающий читабельность и эффективность (производительность, качество) кода.
Есть другие идеи улыбающиеся мне сильнее чем дженерики и дающие не меньше пользы. Ну вот честно скажу, дженерики это хорошо и привлекательно. Но! Но, встроенный параллелизм мне улыбается больше. Параметрические итераторы мне улыбаются больше. Да много чего еще. Дженерики это не то из-за чего я бы ушел с языка.
kuj>Поясняю: препроцессорная реализация это костыль. Имея generics на языковом уровне я получаю все плюшки статически типизированной среды разработки: intellisense, refactoring и прочее.
Все это понятно и никто не оспаривает собственно идеи дженериков Чего на этом так заостряться? Будут они у нативных дельфистов во второй половине этого года
Здравствуйте, misha_irpen, Вы писали:
_>Все-таки я смотрю на синтаксис тоже много наездов. Но тут мои взгляды крайне противоположные. Мне очень не нравится write-only код всех сиподобнх языков, пусть он и дает большую гибкость, но цель не ИМХО оправдывеет средства.
_>Хоть ныне я уже не програмлю так много как раньше, тем не менее нахожусь в глухой оппозиции ко всему C-подомному и когда меня заставляют (люди или обстоятельства) писать на таком языке (чаще всего это PHP, JS и т.п. скрипты), то я становлюсь очень злой и использую все сишные синтаксические штучки-дрючки везде где это хоть малость оправдвно. Если конструкция типа a[i]+=(j=++i) сэкономит мне хоть одну строчку кода, то я использую ее без зазрений совести. Ибо нефиг. И пусть потом тот сишник, который будет этот код читать, прочувствует на собственной шкуре смысл поговорки "за что боролся, на то и напоролся".
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, goto, Вы писали:
G>>Да вроде как С++ придумывался как отдельный язык по подходу. Видимо синтаксис C хорошо ложится на большинство программистских мозгов, вот и был взят. DOO>Да при чем тут конкретно синтаксис — libc осталась. Появились char * vs std::string. Много еще таких несоответствий — если уж придумывали как отдельный язык, то и надо было делать отдельным языком, а поддержку C вынести в опциональную библиотеку, например.
Кризис мозга у обоих в чистом виде. Читайте оба — Википедиа — C++, особенно раздел "История". А вот потом уже делайте различные умозаключения, только, пожалуйста, исторически и логически правильные.
Здравствуйте, Mr.Cat, Вы писали:
MC>2)Рефлекшн — полезная штука как ни крути. Кстати, думаю, во многом благодаря оному Java и .NET неплохо чувствуют себя в сфере веб-программирования, в отличие от неуправляемых языков. Ну-ка как будет выглядеть шаблонизатор, навроде Velocity на неуправляемом языке? Это к вопросу о...
Velocity как-раз от управляемой среды толку мало, по-моему.
Сила рефлексии проявляется в первую очередь в различных O/RM, DI/IoC, unit тестах и т.п.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, hattab, Вы писали:
H>>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно) G>Хо-хо-хо. Сколько стоит экспресс версия Visual С#? Не поверишь — нисколько. А продуктивность программистов на шарпе гораздо выше, чем на делфях (сравниваю с 7 версией, но из написанного понятно что даже современные версии не догоняют). G>Как раз языки и платформы имеет смысл сравнивать не в формате нравится\не нравится, а в количественном измерении: "стоимость" программистов, стоимость обучения программистов, среднее время разработки, средняя плотность багов.
Ты знаешь, TurboDelphi Explorer так же абсолютно бесплатна. С полноценным гуй-дизайнером и новыми фичами среды. Pro версия стоила кажется, что-то около $400. Цен на 2007 к сожалению не знаю, но думаю там все в тех же рамках.
H>>Ты знаешь, для меня веб-разработка, где-то очень далеко за горизонтом G>А зря. Дядька Фаулер еще в 2003 году сказал что если нет особых причин разрабатывать desktop клиент для корпоративного приложения, то лучше сразу заниматься веб-мордой. Web уже давно не только сайты знакомств и порнуха. Ты отстатешь от прогресса.
Т.е. все не веб-девелоперы сидят в глубокой #опе прогресса... Я говорю, WebSnap был уже в 6 версии (ты говоришь сидел на 7 и не знаешь об этом?) И вообще, не сотвори себе кумира.
Здравствуйте, hattab, Вы писали:
H>>>Дженерики есть в 2007 под .Net. В 2008 обещают и для нативного кода. G>>Мда... Это на фоне того, что появилось в C# 3.0 в 2007 году. Делфи тут оооочень сильно отстает.
H>Уж не про LINQ ли ты говоришь Ну в 2008 или 2009 обещают анонимные методы добавить еще.
H>Заметь, не я тут на языки наезжал не имея представления о текущем положении дел.
немного улыбнуло ... ты в каком году живешь, раз у тебя это уже текущее состояние дел?
Здравствуйте, Sinclair, Вы писали:
MC>>Не знал . А пример можно? S>На всякий случай напомню, что автор Delphi (точнее, Object Pascal) перешел из инпрайз в майкрософт и последние много лет занимается разработкой языка C# и оказывает влияние на всю .Net платформу.
Здравствуйте, hattab, Вы писали:
H>>>Ты знаешь, для меня веб-разработка, где-то очень далеко за горизонтом G>>А зря. Дядька Фаулер еще в 2003 году сказал что если нет особых причин разрабатывать desktop клиент для корпоративного приложения, то лучше сразу заниматься веб-мордой. Web уже давно не только сайты знакомств и порнуха. Ты отстатешь от прогресса.
H>Т.е. все не веб-девелоперы сидят в глубокой #опе прогресса... Я говорю, WebSnap был уже в 6 версии (ты говоришь сидел на 7 и не знаешь об этом?) И вообще, не сотвори себе кумира.
Что на этом WebSnap`е хоть было написано? Урлы сайтов плиз.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, hattab, Вы писали:
H>>Ну во прикинь на каких машинках захочет работать .Net FW 3.0, а 4.0? А потом захочет Висту. Ну дальше развивать не буду пожалуй G>.NET Framework бесплатен, кто мешает положить вместе с дистрибутевом фреймворк?
Причем тут цена фреймвока? Слабают гуй на WPF и опа, попали на мощное видео или будут тормоза. Апгрейд. Захочет какая-то фенька хоститься под IISx.x, а IISx.x захочет Win2010 c Enterprise лицензией. Попали на апгрейд сервера. Ну в общем аналогии можно продолжать и продолжать. Майкрософт деньги вытягивать умеет.
H>>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java? G>Хуже. В WCF можно параметры сервиса (протоколы и пр.) поменять в конфиге, не трогая код.
Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы
Здравствуйте, misha_irpen, Вы писали:
_>Все-таки я смотрю на синтаксис тоже много наездов. Но тут мои взгляды крайне противоположные. Мне очень не нравится write-only код всех сиподобнх языков, пусть он и дает большую гибкость, но цель не ИМХО оправдывеет средства.
_>Хоть ныне я уже не програмлю так много как раньше, тем не менее нахожусь в глухой оппозиции ко всему C-подомному и когда меня заставляют (люди или обстоятельства) писать на таком языке (чаще всего это PHP, JS и т.п. скрипты), то я становлюсь очень злой и использую все сишные синтаксические штучки-дрючки везде где это хоть малость оправдвно. Если конструкция типа a[i]+=(j=++i) сэкономит мне хоть одну строчку кода, то я использую ее без зазрений совести. Ибо нефиг. И пусть потом тот сишник, который будет этот код читать, прочувствует на собственной шкуре смысл поговорки "за что боролся, на то и напоролся".
Конечно, про ROCS, видимо, ни Вы, ни Ваши "заказчики" и слыхом не слыхивали.
Поэтому вот и получается write-only код, который с большим успехом можно и на паскале наваять. Но все же многое зависит от степени знания языка у читающего код, так как есть люди, которые и такой код могут легко читать.
Здравствуйте, iiice, Вы писали:
DR>>Не нравится Дельфи из за типично чрезвычайно низкого качества написанных на ней программ.
I>Так и запишем: QIP и Total Commander — низкого качества.А мужики-то не знают
Это такое опровержение?
— в общем случае, справедливо X.
— неправда! Иногда не X!
Здравствуйте, hattab, Вы писали:
kuj>>>>Называется: слышал звон, да не знаю где он?
H>>>А ты думал я сейчас побегу на хобот искать Я же не пытаюсь тебе чего-то доказать.
kuj>>Хотя это и повсеместная практика на КСВ, но все-таки это не хорошо кидаться безосновательными утверждениями...
H>Прикольная практика это ссылки просить по всякому поводу. Где же мне их помнить, истории уж полгода если не больше...
А что прикажешь делать? Верить тебе на слово про звон?
kuj>>>>Человеческий фактор это не отмазка, а основной мотивирующий момент при разработке языков программирования.
H>>>Сильно спорный тезис.
kuj>>Ты это серьезно?
H>Я же упомянул о сигналящем менеджере. Что еще фактору нужно? Нужно в смирительную рубашку погрузить тело бренное, чтоб не дай бог глаз вилкой не выколол... Есть инструмент контроля. О чем тут спорить еще?
Ты хоть понял о чем речь? В человеческой натуре допускать ошибки. Задача современного языка программирования создать максимально гибкий и удобный инструмент с минимальной вероятностью допустить ошибку по вине данного человеческого фактора.
kuj>>>>Все познается в сравнении.
H>>>И чего теперь, роадмапами меряться?
kuj>>При чем тут роадмапы? kuj>>В OP речь шла о сравнении Delphi с современными управляемыми средами типа Java и .Net
H>Так ты перечислил что будет в C# 4.0. Вот когда оно будет, и когда в Delphi будет то о чем я тут говорил, тогда и можно мечами побряцать.
Да какая разница что будет? Да и откуда мне знать, если C# 3.0 вышел совсем не так давно.
Не надо сравнивать сферических коней.
H>>>Ну, по личным ощущениям. Хотя мне идея дженериков нравится. Но есть идею которые нравятся больше
kuj>>При чем тут идеи? Generics это вполне конкретный механизм, значительно повышающий читабельность и эффективность (производительность, качество) кода.
H>Есть другие идеи улыбающиеся мне сильнее чем дженерики и дающие не меньше пользы. Ну вот честно скажу, дженерики это хорошо и привлекательно.
Не понял при чем тут другие идеи, которые тебя привлекают больше? Мне вот игра в снукер нравится больше, чем яблоки и что?
H>Но! Но, встроенный параллелизм мне улыбается больше. Параметрические итераторы мне улыбаются больше. Да много чего еще. Дженерики это не то из-за чего я бы ушел с языка.
Мда.
kuj>>Поясняю: препроцессорная реализация это костыль. Имея generics на языковом уровне я получаю все плюшки статически типизированной среды разработки: intellisense, refactoring и прочее.
H>Все это понятно и никто не оспаривает собственно идеи дженериков Чего на этом так заостряться? Будут они у нативных дельфистов во второй половине этого года
Угу, в Вилариба еще моют, а в Вилабаджа уже празднуют.
Здравствуйте, kuj, Вы писали:
H>>Ну во прикинь на каких машинках захочет работать .Net FW 3.0, а 4.0? А потом захочет Висту. Ну дальше развивать не буду пожалуй
kuj>Ну захочет Висту и что? К тому времени XP давно уже не будет продаваться и скорее всего уже будет Windows 7...
Если так то ладно, а если нет?
kuj>.NET 2.0 работает себе на древней Windows 98, которой уже ОЙ как много лет...
kuj>К тому же все это копейки на фоне стоимости разработки и сопровождения.
У нас сервер аппликух работал в пилотном варианте на машинке 486DX2 с 12 метрами на борту + WinNT4.0 + MSSQL6.5. (5-8 клиентов. и это трехзвенка на MIDAS) И что?
kuj>Как в Delphi обстоят дела с unit test`ами? О каком scalability приложения может вообще идти речь, когда нет ни unit test`ов, ни DI/IoC?...
Юнит-тесты есть. С 2005 вроде. Устаревшая у тебя информация
H>>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java?
kuj>Web-приложения это далеко не только SOAP и таки да — хуже, так как сложнее в разработке и сопровождении. По вышеозначенным причинам.
Такие выводы интересные? Ты чтоль разработкой под Delphi занимался и веб сервисы писал, чтоб такое говорить? А если писал, давай по пунктам . Или ты снова про дженерики будешь говорить
Здравствуйте, hattab, Вы писали:
H>>>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java?
G>>Хуже. В WCF можно параметры сервиса (протоколы и пр.) поменять в конфиге, не трогая код.
H>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы
Здравствуйте, kuj, Вы писали:
I>>>Так и запишем: QIP и Total Commander — низкого качества.А мужики-то не знают CC>>Дык факт! :P
kuj>Забыли еще The Bat!
Вот бат как раз приятное исключение
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, DOOM, Вы писали:
DOO>Тем и читабельнее. Почему-то в исходники самбы, написанной на C я могу въехать за пару тройку часов, а в среднестатистическую C++'ную программу и за пару дней не въеду. DOO>Временные переменные при этом есть везде — но вот возможность на каждый блок объявить свою, как ни странно, сильно захламляет код.
Ой, то есть Вы ещё и помните, что вот эту временную переменную уже можно использовать заново, а вот эту не стоит?
L>>Во-вторых — оно в каких случаях нужно-то? DOO>Что конкретно? Понять, что это перегруженный оператор? Это нужно когда читаешь/модифицируешь чужой код.
Писать в каких слуаях это нужно: когда нужно явно вызывать неявное приведение типов?
L>>>>4. Препроцессор. Да его ругают, но лучше иметь возможность его использовать. DOO>>>Используй внешний (и отлаживаться проще). L>>Так тут вопрос в том, что есть выбор. DOO>Дак тут замечание о том, что препроцессор к языку отношения не имеет (хотя к IDE имеет, не спорю).
Ну вот сколько бы я не видел реализаций С++ везде был препроцессор. А в Дельфи?
DOO>А каким основным? DOO>Про деструкторы? Что-то есть — я просто сейчас уже точно не смогу грамотно на эту тему поспорить. DOO>Про обязательность вызова конструктора как-то не понял, что имелось ввиду.
Сразу про оба отвечу:
class ABigComplexData
{
public:
ABigComplexData(...){...};
~ABigComplexData(){...};
void Go(){...};
...
}
void use()
{
//тут с abcd ничего делать нельзя, его ещё нет
ABigComplexData abcd(...);
//тут он уже сконструирован
abcd.Go();
...
if(...)
return;//деструктор вызван автоматически
...
//тут тоже
}
На дельфи не писал очень давно, пишу по памяти, если что поправляйте.
class ABCD
begin
constructor Init();
destructor Done();
procedure Go();
...
end;
procedure Use
var abcd:ABCD;{уже написал и понял что так там тоже писать нельзя ;)}begin
abcd.Go; - кто мешает?
abcd.Init(...);
...
if(...)
exit;{Done кто вызывать будет?}
abcd.Done;//опять же ручками :(end;
DOO>Шаблоны — на вкус и цвет. Мне они как-то не нравились в свое время.
Ну хорошо, вопрос в лоб — нужен список элементов T, которые мы только что придумали. Аналог std::list<T> какой?
DOO>Про оптимизатор на уровне Intel C++ — ну и сколько процентов народу используют этот компилятор? А у остальных тоже не такие уж выдающиеся результаты по сравнению с ним.
А фокус в том, что он есть. И если нужно — можно использовать. А в дельфи — нужно, не нужно, а про качественную машинную оптимизацию можно забыть.
H>>>Ну во прикинь на каких машинках захочет работать .Net FW 3.0, а 4.0? А потом захочет Висту. Ну дальше развивать не буду пожалуй
kuj>>Ну захочет Висту и что? К тому времени XP давно уже не будет продаваться и скорее всего уже будет Windows 7...
H>Если так то ладно, а если нет?
А кабы, да кабы во рту вырасли грибы...
Неконструктивный спор получается.
kuj>>.NET 2.0 работает себе на древней Windows 98, которой уже ОЙ как много лет...
kuj>>К тому же все это копейки на фоне стоимости разработки и сопровождения.
H>У нас сервер аппликух работал в пилотном варианте на машинке 486DX2 с 12 метрами на борту + WinNT4.0 + MSSQL6.5. (5-8 клиентов. и это трехзвенка на MIDAS) И что?
Выложить пару штук зеленых на железку или выложить пару сотен штук зеленых на разработку и сопровождение... Вот тебе и что.
kuj>>Как в Delphi обстоят дела с unit test`ами? О каком scalability приложения может вообще идти речь, когда нет ни unit test`ов, ни DI/IoC?...
H>Юнит-тесты есть. С 2005 вроде. Устаревшая у тебя информация
Ок, согласен.
Но это только state-based тесты. Хочу interaction-based test.
Типа:
public interface IWithEvents
{
event EventHandler Blah;
void RaiseEvent();
}
[Test]
public void VerifyingThatEventWasAttached()
{
MockRepository mocks = new MockRepository();
IWithEvents events = (IWithEvents)mocks.CreateMock(typeof(IWithEvents));
events.Blah+=new EventHandler(events_Blah);
mocks.ReplayAll();
MethodThatSubscribeToEventBlah(events);
mocks.VerifyAll();
}
public void MethodThatSubscribeToEventBlah(IWithEvents events)
{
events.Blah+=new EventHandler(events_Blah);
}
H>>>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java?
kuj>>Web-приложения это далеко не только SOAP и таки да — хуже, так как сложнее в разработке и сопровождении. По вышеозначенным причинам.
H>Такие выводы интересные? Ты чтоль разработкой под Delphi занимался и веб сервисы писал, чтоб такое говорить? А если писал, давай по пунктам . Или ты снова про дженерики будешь говорить
Занимался. Буду говорить и про дженерики, и про O/RM, и про MVC, и про Unit tests, и про extension methods, и про многое другое.
Здравствуйте, kuj, Вы писали:
kuj>>>То, чего пользователь не видит для него не существует. Это только то, что имеет значение.
H>>Я в WindowsLiveWriter наблюдаю периодические фризы. Не стану утверждать, что это GC или JIT. Но они есть.
kuj>Я тебе как разработчик .Net с 99% вероятностью скажу, что фризы эти, если они и имеют место, не имеют отношения к GC.
Мне как пользователю этой пердульки мало интересно отчего она замерзает время от времени. Я виже результат. Мне если честно лень мониторить перфкоунтеры .Net GC, чтоб сказать точно.
kuj>>>В том, что GC один на всех. Если один процесс пнет его — очисти кучу в то время, как другой процесс нагружает его alloc`ами, то что произойдет? GC сам должен регулировать этот процесс, чтоб для пользователя он был абсолютно незаметным.
H>>Мы точно о Delphi говорим? kuj>Конечно нет. В Delphi (не .NET) нет GC.
В таком случае о каких процессах шла речь и что это за минусы тут приписали Delphi?
H>>Какие там разные процессы? Или ты про разные Delphi-процессы? Там же нет такого отдельного понятия, как GC в .Net/Java. Просто есть типы с управляемым временем жизни. Вышла переменная из области видимости -- компилер ее тут же зафиналил. Все просто и эффективно.
kuj>Ты не путай GC и недо- smart pointers. kuj>В C++, например, есть реализация smart pointers (в boost), базирующаяся на подсчете ссылок. Это куда эффективнее области видимости.
Я и не путаю. Я ясность внес. Ты сказал что типы с управляемым временм жизни в Delphi это ее минус. Я вот уже на протяжении больше половины топика пытаюсь из тебя истуну выудить -- почему?
kuj>>>>>Без полноценного DI в Delphi толку от интерфейсов куда как меньше.
H>>>>Чего-то не улавливаю связи...
kuj>>>Я писал где-то в этом топике. Вся сила интерфейсов раскрывается при наличии полноценного DI/IoC контейнера.
H>>Все это сильно зависит от способа применения и изобретательности
kuj>Не понял. Поясни.
Интерфейсы удобно рассматривать, как часть некого API. Отрыв от реализации и все такое. Зная, как они реализованы в Delphi, и в купе с агрегированием и делегированием можно получить приличные бенефиты используя эти знания. Блин, как я сегодня писать запарился...
Здравствуйте, hattab, Вы писали:
H>Причем тут цена фреймвока? Слабают гуй на WPF и опа, попали на мощное видео или будут тормоза. Апгрейд. Захочет какая-то фенька хоститься под IISx.x, а IISx.x захочет Win2010 c Enterprise лицензией. Попали на апгрейд сервера. Ну в общем аналогии можно продолжать и продолжать. Майкрософт деньги вытягивать умеет.
В общем случае — не воя головная боль. Если заказчик готов платить деньги, то делай на чем проще. Если продукт коробочный, то изначально известно на какую аудиторию расчитано и какие технологии будут задействованы.
Тем более WPF при простом рисовании окошек и двумерной графики практически не тормозит на современных компах.
H>>>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java? G>>Хуже. В WCF можно параметры сервиса (протоколы и пр.) поменять в конфиге, не трогая код. H>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы
Когда я аботал на делфях клиент умудрился поудалять ini файлы с настройками.
От пользователя-дурака никто не застрахован.
Здравствуйте, kuj, Вы писали:
kuj>.NET куда больше взяла из мира Java все-же.
А язык C# взял очень много от языка Delphi. А развитие языка C# оказывает влияние на всю платформу.
Здравствуйте, hattab, Вы писали:
kuj>>>>То, чего пользователь не видит для него не существует. Это только то, что имеет значение.
H>>>Я в WindowsLiveWriter наблюдаю периодические фризы. Не стану утверждать, что это GC или JIT. Но они есть.
kuj>>Я тебе как разработчик .Net с 99% вероятностью скажу, что фризы эти, если они и имеют место, не имеют отношения к GC.
H>Мне как пользователю этой пердульки мало интересно отчего она замерзает время от времени. Я виже результат. Мне если честно лень мониторить перфкоунтеры .Net GC, чтоб сказать точно.
Ну и при чем тут был наезд на .NET`овский GC? Ляпнул наобум? Или ты думаешь, что на Делфи нельзя написать так, чтоб не было фризов и прочих глюков? Ой-вэй...
kuj>>>>В том, что GC один на всех. Если один процесс пнет его — очисти кучу в то время, как другой процесс нагружает его alloc`ами, то что произойдет? GC сам должен регулировать этот процесс, чтоб для пользователя он был абсолютно незаметным.
H>>>Мы точно о Delphi говорим? kuj>>Конечно нет. В Delphi (не .NET) нет GC.
H>В таком случае о каких процессах шла речь и что это за минусы тут приписали Delphi?
Речь шла о том, что в Delphi нет ни полноценного GC, ни нормальной реализации smart pointer типа boost::auto_ptr<>.
H>>>Какие там разные процессы? Или ты про разные Delphi-процессы? Там же нет такого отдельного понятия, как GC в .Net/Java. Просто есть типы с управляемым временем жизни. Вышла переменная из области видимости -- компилер ее тут же зафиналил. Все просто и эффективно.
kuj>>Ты не путай GC и недо- smart pointers. kuj>>В C++, например, есть реализация smart pointers (в boost), базирующаяся на подсчете ссылок. Это куда эффективнее области видимости.
H>Я и не путаю. Я ясность внес. Ты сказал что типы с управляемым временм жизни в Delphi это ее минус. Я вот уже на протяжении больше половины топика пытаюсь из тебя истуну выудить -- почему?
Я такого не говорил. Давай не будем перекручивать слова, ага?
kuj>>>>Я писал где-то в этом топике. Вся сила интерфейсов раскрывается при наличии полноценного DI/IoC контейнера.
H>>>Все это сильно зависит от способа применения и изобретательности
kuj>>Не понял. Поясни.
H>Интерфейсы удобно рассматривать, как часть некого API. Отрыв от реализации и все такое. Зная, как они реализованы в Delphi, и в купе с агрегированием и делегированием можно получить приличные бенефиты используя эти знания. Блин, как я сегодня писать запарился...
В конечном итоге это костыль на фоне того, как применяются интерфейсе в управляемых средах типа .NET и Java
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, kuj, Вы писали:
I>>>>Так и запишем: QIP и Total Commander — низкого качества.А мужики-то не знают CC>>>Дык факт! :P
kuj>>Забыли еще The Bat! CC>Вот бат как раз приятное исключение
Здравствуйте, lifrsdn, Вы писали:
L>Здравствуйте, DOOM, Вы писали:
DOO>>Тем и читабельнее. Почему-то в исходники самбы, написанной на C я могу въехать за пару тройку часов, а в среднестатистическую C++'ную программу и за пару дней не въеду. DOO>>Временные переменные при этом есть везде — но вот возможность на каждый блок объявить свою, как ни странно, сильно захламляет код.
L>Ой, то есть Вы ещё и помните, что вот эту временную переменную уже можно использовать заново, а вот эту не стоит?
Не понял замечания. Когда переменную всегда надо объявлять в одном месте, то у тебя временные переменные будут универсальны — какой-нибудь tmp, который будет каждый раз использоваться. В случае, когда переменную можно объявить где угодно, сразу начинается злоупотребление (еще и с венгерской нотацией какой-нибудь для полного счастья).
L>>>Во-вторых — оно в каких случаях нужно-то? DOO>>Что конкретно? Понять, что это перегруженный оператор? Это нужно когда читаешь/модифицируешь чужой код.
L>Писать в каких слуаях это нужно: когда нужно явно вызывать неявное приведение типов?
Ты о чем? О том примере — это было так, что ввспомнилось из смутного прошлого. В общем и целом перегрузка операторов делает код write only.
P.S. А я еще и ООП в целом не люблю
L>Ну вот сколько бы я не видел реализаций С++ везде был препроцессор. А в Дельфи? А сколько реализаций Дельфи ты видел?
DOO>>А каким основным? DOO>>Про деструкторы? Что-то есть — я просто сейчас уже точно не смогу грамотно на эту тему поспорить. DOO>>Про обязательность вызова конструктора как-то не понял, что имелось ввиду.
L>Сразу про оба отвечу:
L>
L>class ABigComplexData
L>{
L>public:
L> ABigComplexData(...){...};
L> ~ABigComplexData(){...};
L> void Go(){...};
L> ...
L>}
L>void use()
L>{
L> //тут с abcd ничего делать нельзя, его ещё нет
L> ABigComplexData abcd(...);
L> //тут он уже сконструирован
L> abcd.Go();
L> ...
L> if(...)
L> return;//деструктор вызван автоматически
L> ...
L> //тут тоже
L>}
L>
А теперь замени на ABigComplexData на ABigComplexData * — и пойми, что в Дельфи объект это всегда указатель на объект.
L>На дельфи не писал очень давно, пишу по памяти, если что поправляйте.
L>[pascal] L>class ABCD L>begin L> constructor Init(); L> destructor Done(); L> procedure Go(); L> ... L>end;
DOO>>Шаблоны — на вкус и цвет. Мне они как-то не нравились в свое время.
L>Ну хорошо, вопрос в лоб — нужен список элементов T, которые мы только что придумали. Аналог std::list<T> какой?
Tlist, потому что все классы наследники TObject. Сейчас ты мне скажешь, что мне компилятор ни фига не проверит, что в моем TList'е все объекти одного класса, но я, сильно поднатужившись, приведу тебе примеры, какую динамику это дает — просто программер на C++ с шаблонами не мыслит о своей программе как о чем-то меняющемся во время выполнения.
DOO>>Про оптимизатор на уровне Intel C++ — ну и сколько процентов народу используют этот компилятор? А у остальных тоже не такие уж выдающиеся результаты по сравнению с ним.
L>А фокус в том, что он есть. И если нужно — можно использовать. А в дельфи — нужно, не нужно, а про качественную машинную оптимизацию можно забыть.
Была старая статья здесь на сайте по сравнению скорости работы разных компиляторов — дак вот, если откроешь, то увидешь 2 факта:
1. Intel C++ не всегда рулит
2. Delphi иногда очень сильно обходит других
TEO>Кризис мозга у обоих в чистом виде. Читайте оба — Википедиа — C++, особенно раздел "История". А вот потом уже делайте различные умозаключения, только, пожалуйста, исторически и логически правильные.
Прочитал. Только утвердился в своих предположениях. Есть что-то сказать по существу?
Здравствуйте, TheEvilOne, Вы писали:
TEO>Конечно, про ROCS, видимо, ни Вы, ни Ваши "заказчики" и слыхом не слыхивали.
Во-первых, я где-то упомянул заказчиков? Вроде как нет...
А во-вторых, чем в этом случае мне поможет зубная паста? Ибо кроме нее с таким именем гуголь ничего не знает.
Здравствуйте, DOOM, Вы писали:
DOO>А теперь замени на ABigComplexData на ABigComplexData * — и пойми, что в Дельфи объект это всегда указатель на объект.
L>>Ну хорошо, вопрос в лоб — нужен список элементов T, которые мы только что придумали. Аналог std::list<T> какой? DOO>Tlist, потому что все классы наследники TObject. Сейчас ты мне скажешь, что мне компилятор ни фига не проверит, что в моем TList'е все объекти одного класса, но я, сильно поднатужившись, приведу тебе примеры, какую динамику это дает — просто программер на C++ с шаблонами не мыслит о своей программе как о чем-то меняющемся во время выполнения.
Ты не понял. Во-первых, в C++ можно и std::list< void * >, во-вторых, это дает не гибкость, а широкое поле для ошибок и проблем с приведением типов. И конечно же негативно сказывается на производительности.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, gandjustas, Вы писали:
kuj>>>.NET куда больше взяла из мира Java все-же.
G>>А язык C# взял очень много от языка Delphi.
kuj>Это шутка? Можно хотя бы пять первых пунктов?
1)Свойства
2)Делегаты и события
3)Cсылочная объектная модель (хотя этоже характерно и для Java)
4)ref и out параметры.
5)(больше вопрос платформы) Основная направленность на Windows
Здравствуйте, gandjustas, Вы писали:
kuj>>Здравствуйте, gandjustas, Вы писали:
kuj>>>>.NET куда больше взяла из мира Java все-же.
G>>>А язык C# взял очень много от языка Delphi.
kuj>>Это шутка? Можно хотя бы пять первых пунктов?
G>1)Свойства
Java get/set
G>2)Делегаты и события
Java
G>3)Cсылочная объектная модель (хотя этоже характерно и для Java)
Reference/value вообще-то. Это от Java (хотя и не совсем полностью).
G>4)ref и out параметры.
Java
G>5)(больше вопрос платформы) Основная направленность на Windows
В C# гораздо больше взято от Java, чем от Object Pascal.
Здравствуйте, hattab, Вы писали:
H>Да-да. Я это уже слышал и не раз. За короткий срок невозможно научиться грамотно программировать на чем-бы то нибыло. Я соглашусь, что двоечнику после Delphi-AccessViolation'ов будет легче под .Net/Java. Однако создавать качественного продукта он не сможет. Пердульки бухгалтерские его удел. Максимум.
...
H>Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем.
Сопоставляя выделенное можно сделать неутешительные выводы.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
MC>>>Речь не о SOAP-сервисах, а о создании веб-морд. Т.е. упрощенно — когда есть HTML-шаблоны и java/.net код, который на их основе хитро генерит динамические страницы. Ну, короче, как в php.
H>>WebSnap. Ребята, оно было еще в 6 версии. Intraweb еще круче
kuj>Хочу полноценный MVC с unit test`ами и расширяемым view-engine по типу Brail (из Castle Monorail)! Где?
Здравствуйте, sndanil, Вы писали:
S>Здравствуйте, hattab, Вы писали:
H>>>>Дженерики есть в 2007 под .Net. В 2008 обещают и для нативного кода. G>>>Мда... Это на фоне того, что появилось в C# 3.0 в 2007 году. Делфи тут оооочень сильно отстает.
H>>Уж не про LINQ ли ты говоришь Ну в 2008 или 2009 обещают анонимные методы добавить еще.
H>>Заметь, не я тут на языки наезжал не имея представления о текущем положении дел.
S>немного улыбнуло ... ты в каком году живешь, раз у тебя это уже текущее состояние дел?
Дернуть слова из контекста и поржать. Намана. А вдумчиво и с начала?
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
H>>>>Ты знаешь, для меня веб-разработка, где-то очень далеко за горизонтом G>>>А зря. Дядька Фаулер еще в 2003 году сказал что если нет особых причин разрабатывать desktop клиент для корпоративного приложения, то лучше сразу заниматься веб-мордой. Web уже давно не только сайты знакомств и порнуха. Ты отстатешь от прогресса.
H>>Т.е. все не веб-девелоперы сидят в глубокой #опе прогресса... Я говорю, WebSnap был уже в 6 версии (ты говоришь сидел на 7 и не знаешь об этом?) И вообще, не сотвори себе кумира.
kuj>Что на этом WebSnap`е хоть было написано? Урлы сайтов плиз.
Если тебе интересны существующие проекты под WebSnap, самое время погрузиться в гугл. Мне оно надо?
Здравствуйте, kuj, Вы писали:
G>>1)Свойства kuj>Java get/set
Это не свойства
G>>2)Делегаты и события kuj>Java
Их в Java нет, в основном интерфейсы с одинм методом применяются
G>>3)Cсылочная объектная модель (хотя этоже характерно и для Java) kuj>Reference/value вообще-то. Это от Java (хотя и не совсем полностью).
Это для многих языков
G>>4)ref и out параметры. kuj>Java
Нет их там
G>>5)(больше вопрос платформы) Основная направленность на Windows kuj>
kuj>В C# гораздо больше взято от Java, чем от Object Pascal.
Здравствуйте, kuj, Вы писали:
kuj>Как в Delphi обстоят дела с unit test`ами? О каком scalability приложения может вообще идти речь, когда нет ни unit test`ов, ни DI/IoC?...
Здравствуйте, gandjustas, Вы писали:
G>Тем более WPF при простом рисовании окошек и двумерной графики практически не тормозит на современных компах.
При простом рисовании окошек и двумерной графике ГУЙ вообще не имеет права тормозить на современных компах.
Я так понимаю "практически не тормозит" в данном случае означает "тормозит, но еще пока терпимо"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, DOOM, Вы писали:
L>>Ой, то есть Вы ещё и помните, что вот эту временную переменную уже можно использовать заново, а вот эту не стоит? DOO>Не понял замечания. Когда переменную всегда надо объявлять в одном месте, то у тебя временные переменные будут универсальны — какой-нибудь tmp, который будет каждый раз использоваться. В случае, когда переменную можно объявить где угодно, сразу начинается злоупотребление (еще и с венгерской нотацией какой-нибудь для полного счастья).
Ну и надо всё время проверять, что в этом месте процедуры этот tmp ещё нужен, а чуть ниже по тексту уже нет.
L>>>>Во-вторых — оно в каких случаях нужно-то? DOO>>>Что конкретно? Понять, что это перегруженный оператор? Это нужно когда читаешь/модифицируешь чужой код. L>>Писать в каких слуаях это нужно: когда нужно явно вызывать неявное приведение типов? DOO>Ты о чем? О том примере — это было так, что ввспомнилось из смутного прошлого. В общем и целом перегрузка операторов делает код write only. DOO>P.S. А я еще и ООП в целом не люблю
Ну так написать везде можно так, что потом 100 лет не расхлебаешь.
L>>Ну вот сколько бы я не видел реализаций С++ везде был препроцессор. А в Дельфи? DOO> А сколько реализаций Дельфи ты видел?
Одну. От Борланда. Вы назовёте ту, где есть препроцессор?
DOO>А теперь замени на ABigComplexData на ABigComplexData * — и пойми, что в Дельфи объект это всегда указатель на объект.
Ну и что в этом хорошего? Кстати, kuj про shared/scoped_ptr не зря вспомнил. В дельфи как их реализовать?
DOO>>>Шаблоны — на вкус и цвет. Мне они как-то не нравились в свое время. L>>Ну хорошо, вопрос в лоб — нужен список элементов T, которые мы только что придумали. Аналог std::list<T> какой? DOO>Tlist, потому что все классы наследники TObject. Сейчас ты мне скажешь, что мне компилятор ни фига не проверит, что в моем TList'е все объекти одного класса, но я, сильно поднатужившись, приведу тебе примеры, какую динамику это дает — просто программер на C++ с шаблонами не мыслит о своей программе как о чем-то меняющемся во время выполнения.
Это дает лишний уровень косвенности, хранятся-то там тогда не объекты, а указатели на них. На маленьких по размеру теряем, это ж каждый раз надо из кучи дергать по несколько байт.
Но намного важнее то, что в реальных задачах нужны списки чего-то, а не всего чего угодно. В С++ с шаблонами за этим следит компилятор и дает по рукам при попытке это нарушить. Кроме того не надо делать лишних и опасных движений, вроде приведения типов. При этом в С++ не запрещено выделить некоторую сущность и хранить список [умных] указателей на неё, приводя по мере надобности. Гибкость есть. И свобода выбора.
DOO>>>Про оптимизатор на уровне Intel C++ — ну и сколько процентов народу используют этот компилятор? А у остальных тоже не такие уж выдающиеся результаты по сравнению с ним.
L>>А фокус в том, что он есть. И если нужно — можно использовать. А в дельфи — нужно, не нужно, а про качественную машинную оптимизацию можно забыть. DOO>Была старая статья здесь на сайте по сравнению скорости работы разных компиляторов — дак вот, если откроешь, то увидешь 2 факта: DOO>1. Intel C++ не всегда рулит DOO>2. Delphi иногда очень сильно обходит других
Не спорю. Но работа с плавающей точкой, а именно это меня в своё время интересовало, у интела сделан на 5+.
DOO>Но вообще статейку не мешало б обновить...
Здравствуйте, kuj, Вы писали:
kuj>>>Хотя это и повсеместная практика на КСВ, но все-таки это не хорошо кидаться безосновательными утверждениями...
H>>Прикольная практика это ссылки просить по всякому поводу. Где же мне их помнить, истории уж полгода если не больше...
kuj>А что прикажешь делать? Верить тебе на слово про звон?
Я еще раз говорю, у меня нет идеи доказать тебе чего-то Я описал реальную ситуацию, а вопросы веры это не ко мне.
H>>Я же упомянул о сигналящем менеджере. Что еще фактору нужно? Нужно в смирительную рубашку погрузить тело бренное, чтоб не дай бог глаз вилкой не выколол... Есть инструмент контроля. О чем тут спорить еще?
kuj>Ты хоть понял о чем речь? В человеческой натуре допускать ошибки. Задача современного языка программирования создать максимально гибкий и удобный инструмент с минимальной вероятностью допустить ошибку по вине данного человеческого фактора.
Да не избавляет вас управляемость от алгоритмических граблей и утечек. Работая с инструментом надо знать, как с ним работать, а не так, как проповедовал gandjustas. Все вокруг этого вертится.
H>>Есть другие идеи улыбающиеся мне сильнее чем дженерики и дающие не меньше пользы. Ну вот честно скажу, дженерики это хорошо и привлекательно.
kuj>Не понял при чем тут другие идеи, которые тебя привлекают больше? Мне вот игра в снукер нравится больше, чем яблоки и что?
Мы говорили о плюсах и минусах, если ты забыл. Ну и дженерики, это вроде как плюс .Net/Java. Но насколько это весомый плюс, большой вопрос. Я понят?
kuj>>>Поясняю: препроцессорная реализация это костыль. Имея generics на языковом уровне я получаю все плюшки статически типизированной среды разработки: intellisense, refactoring и прочее.
H>>Все это понятно и никто не оспаривает собственно идеи дженериков Чего на этом так заостряться? Будут они у нативных дельфистов во второй половине этого года
kuj>Угу, в Вилариба еще моют, а в Вилабаджа уже празднуют.
Ну в 2007 для .Net уже есть. Успокойся. Вам нативу-то вообще противопоставить нечего
Здравствуйте, gandjustas, Вы писали:
G>>>1)Свойства kuj>>Java get/set G>Это не свойства
Как это не свойства, а что это?
G>>>2)Делегаты и события kuj>>Java G>Их в Java нет,
(далекий 1996 год) http://java.sys-con.com/read/49097.htm
G>>>4)ref и out параметры. kuj>>Java G>Нет их там
Да, бес попутал. Сорри.
kuj>>В C# гораздо больше взято от Java, чем от Object Pascal.
G>Можешь от Delphi приписать прямоугольные массивы
Здравствуйте, kuj, Вы писали:
kuj>>>Ну захочет Висту и что? К тому времени XP давно уже не будет продаваться и скорее всего уже будет Windows 7...
H>>Если так то ладно, а если нет?
kuj>А кабы, да кабы во рту вырасли грибы...
kuj>Неконструктивный спор получается.
Я и предлагал не развивать эту тему. Вам я нифига не докажу, а время потрачу...
kuj>>>.NET 2.0 работает себе на древней Windows 98, которой уже ОЙ как много лет...
kuj>>>К тому же все это копейки на фоне стоимости разработки и сопровождения.
H>>У нас сервер аппликух работал в пилотном варианте на машинке 486DX2 с 12 метрами на борту + WinNT4.0 + MSSQL6.5. (5-8 клиентов. и это трехзвенка на MIDAS) И что?
kuj>Выложить пару штук зеленых на железку или выложить пару сотен штук зеленых на разработку и сопровождение... Вот тебе и что.
Я у тебя щас смету попрошу, по аналогии со ссылками. Давай напрягайся.
kuj>>>Как в Delphi обстоят дела с unit test`ами? О каком scalability приложения может вообще идти речь, когда нет ни unit test`ов, ни DI/IoC?...
kuj>Но это только state-based тесты. Хочу interaction-based test.
kuj>Типа:
Не знаю, не спец.
H>>>>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java?
kuj>>>Web-приложения это далеко не только SOAP и таки да — хуже, так как сложнее в разработке и сопровождении. По вышеозначенным причинам.
H>>Такие выводы интересные? Ты чтоль разработкой под Delphi занимался и веб сервисы писал, чтоб такое говорить? А если писал, давай по пунктам . Или ты снова про дженерики будешь говорить
kuj>Занимался. Буду говорить и про дженерики, и про O/RM, и про MVC, и про Unit tests, и про extension methods, и про многое другое.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
H>>>>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java?
G>>>Хуже. В WCF можно параметры сервиса (протоколы и пр.) поменять в конфиге, не трогая код.
H>>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы
kuj>Угу, пропал exe-шник — отвалилась голова.
У тебя конфиги ни разу не слетали? Если у меня слетит конфиг, моя прилага не забудет как по XML-RPC разговаривать
Здравствуйте, hattab, Вы писали:
kuj>>>>Хотя это и повсеместная практика на КСВ, но все-таки это не хорошо кидаться безосновательными утверждениями...
H>>>Прикольная практика это ссылки просить по всякому поводу. Где же мне их помнить, истории уж полгода если не больше...
kuj>>А что прикажешь делать? Верить тебе на слово про звон?
H>Я еще раз говорю, у меня нет идеи доказать тебе чего-то Я описал реальную ситуацию, а вопросы веры это не ко мне.
Ты не описывал реальную ситуацию а сослался на какие-то там форумы, где кто-кто кому-то когда-то рекомендовал "понатыкать GC.Collect".
H>>>Я же упомянул о сигналящем менеджере. Что еще фактору нужно? Нужно в смирительную рубашку погрузить тело бренное, чтоб не дай бог глаз вилкой не выколол... Есть инструмент контроля. О чем тут спорить еще?
kuj>>Ты хоть понял о чем речь? В человеческой натуре допускать ошибки. Задача современного языка программирования создать максимально гибкий и удобный инструмент с минимальной вероятностью допустить ошибку по вине данного человеческого фактора.
H>Да не избавляет вас управляемость от алгоритмических граблей и утечек.
Не панацея конечно, но в целом заметно улучшает ситуацию. Я это знаю по собственному опыту.
H>Работая с инструментом надо знать, как с ним работать, а не так, как проповедовал gandjustas. Все вокруг этого вертится.
Да при чем тут это?
H>>>Есть другие идеи улыбающиеся мне сильнее чем дженерики и дающие не меньше пользы. Ну вот честно скажу, дженерики это хорошо и привлекательно.
kuj>>Не понял при чем тут другие идеи, которые тебя привлекают больше? Мне вот игра в снукер нравится больше, чем яблоки и что?
H>Мы говорили о плюсах и минусах, если ты забыл. Ну и дженерики, это вроде как плюс .Net/Java. Но насколько это весомый плюс, большой вопрос. Я понят?
Да-да, игра в снукер это больше, чем яблоки, хотя мне рекомендовали покататься на сферических конях в банаховом пространстве...
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, hattab, Вы писали:
H>>Причем тут цена фреймвока? Слабают гуй на WPF и опа, попали на мощное видео или будут тормоза. Апгрейд. Захочет какая-то фенька хоститься под IISx.x, а IISx.x захочет Win2010 c Enterprise лицензией. Попали на апгрейд сервера. Ну в общем аналогии можно продолжать и продолжать. Майкрософт деньги вытягивать умеет. G>В общем случае — не воя головная боль. Если заказчик готов платить деньги, то делай на чем проще. Если продукт коробочный, то изначально известно на какую аудиторию расчитано и какие технологии будут задействованы. G>Тем более WPF при простом рисовании окошек и двумерной графики практически не тормозит на современных компах.
Нифига себе не моя (не приходило в голову, что заказчик и работодатель может быть одним лицом?)... Кого потом драть будут за возрастающие требования, Гейтса чтоль?
H>>>>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java? G>>>Хуже. В WCF можно параметры сервиса (протоколы и пр.) поменять в конфиге, не трогая код. H>>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы G>Когда я аботал на делфях клиент умудрился поудалять ini файлы с настройками. G>От пользователя-дурака никто не застрахован.
Конечно никто. Но если у тебя софтина перестала от этого работать...
Здравствуйте, hattab, Вы писали:
H>>>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы
kuj>>Угу, пропал exe-шник — отвалилась голова.
H>У тебя конфиги ни разу не слетали? Если у меня слетит конфиг, моя прилага не забудет как по XML-RPC разговаривать
Не знаю как оно в Делфи, но в .NET и Java конфиги не имеют такой привычки — куда-то там слетать...
Здравствуйте, hattab, Вы писали:
kuj>>Выложить пару штук зеленых на железку или выложить пару сотен штук зеленых на разработку и сопровождение... Вот тебе и что.
H>Я у тебя щас смету попрошу, по аналогии со ссылками. Давай напрягайся.
NDA.
H>>>Такие выводы интересные? Ты чтоль разработкой под Delphi занимался и веб сервисы писал, чтоб такое говорить? А если писал, давай по пунктам . Или ты снова про дженерики будешь говорить
kuj>>Занимался. Буду говорить и про дженерики, и про O/RM, и про MVC, и про Unit tests, и про extension methods, и про многое другое.
H>Ты по пунктам давай...
Здравствуйте, DOOM, Вы писали:
DOO>2. Delphi иногда очень сильно обходит других
Насколько я помню все преимущества дельфи заключались в том, что аллокатор памяти в дельфином рантайме был написан с упором на быструю аллокацию.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Lloyd, Вы писали:
L>Видимо имелось в виду то, что формат dfm-а время от времени перестает пониматься более новой версией IDE.
Не было такого никогда. В какой-то версии (лет 10 назад) появился текстовый формат dfm, который стал использоваться по умолчанию (имхо, полезно для систем контроля версий), но и старый (двоичный) формат продолжает поддерживаться. Из-за этого формы, созданные после перехода на текстовый формат, могут не читаться старыми версиями, но не наоборот — новые версии всегда читают формы, созданные старыми версиями, и могут сохранять формы в формате, понимаемом старыми версиями — задаётся в настройках IDE Tools->Options->VCL Designer->New forms as text.
---
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true
Здравствуйте, gandjustas, Вы писали:
L>>С тем же успехом можно сказать, что и в C++ нельзя позвращать ссылку, т.к. ее нужно будет освобождать. G>В C++ можно вернуть объект (не ссылку), в делфяф такое нельзя сделать в принципе
В принципе можно http://www.rsdn.ru/forum/message/551720.1.aspx
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, kuj, Вы писали:
kuj>>Как в Delphi обстоят дела с unit test`ами? О каком scalability приложения может вообще идти речь, когда нет ни unit test`ов, ни DI/IoC?...
L>Как scalability связано с unittest-ами?
Транзитивно. Рефакторинг и оптимизация кода без юнит тестов очень затруднена.
Здравствуйте, hattab, Вы писали:
H>>>Т.е. все не веб-девелоперы сидят в глубокой #опе прогресса... Я говорю, WebSnap был уже в 6 версии (ты говоришь сидел на 7 и не знаешь об этом?) И вообще, не сотвори себе кумира.
kuj>>Что на этом WebSnap`е хоть было написано? Урлы сайтов плиз.
H>Если тебе интересны существующие проекты под WebSnap, самое время погрузиться в гугл. Мне оно надо?
Здравствуйте, kuj, Вы писали:
kuj>>>Я тебе как разработчик .Net с 99% вероятностью скажу, что фризы эти, если они и имеют место, не имеют отношения к GC.
H>>Мне как пользователю этой пердульки мало интересно отчего она замерзает время от времени. Я виже результат. Мне если честно лень мониторить перфкоунтеры .Net GC, чтоб сказать точно.
kuj>Ну и при чем тут был наезд на .NET`овский GC? Ляпнул наобум? Или ты думаешь, что на Делфи нельзя написать так, чтоб не было фризов и прочих глюков? Ой-вэй...
Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом.
kuj>>>>>В том, что GC один на всех. Если один процесс пнет его — очисти кучу в то время, как другой процесс нагружает его alloc`ами, то что произойдет? GC сам должен регулировать этот процесс, чтоб для пользователя он был абсолютно незаметным.
H>>>>Мы точно о Delphi говорим? kuj>>>Конечно нет. В Delphi (не .NET) нет GC.
H>>В таком случае о каких процессах шла речь и что это за минусы тут приписали Delphi?
kuj>Речь шла о том, что в Delphi нет ни полноценного GC, ни нормальной реализации smart pointer типа boost::auto_ptr<>.
H>>>>Какие там разные процессы? Или ты про разные Delphi-процессы? Там же нет такого отдельного понятия, как GC в .Net/Java. Просто есть типы с управляемым временем жизни. Вышла переменная из области видимости -- компилер ее тут же зафиналил. Все просто и эффективно.
kuj>>>Ты не путай GC и недо- smart pointers. kuj>>>В C++, например, есть реализация smart pointers (в boost), базирующаяся на подсчете ссылок. Это куда эффективнее области видимости.
H>>Я и не путаю. Я ясность внес. Ты сказал что типы с управляемым временм жизни в Delphi это ее минус. Я вот уже на протяжении больше половины топика пытаюсь из тебя истуну выудить -- почему?
kuj>Я такого не говорил. Давай не будем перекручивать слова, ага?
А кого я квотил-то? Читай с "В том, что GC один на всех"?
kuj>>>>>Я писал где-то в этом топике. Вся сила интерфейсов раскрывается при наличии полноценного DI/IoC контейнера.
H>>>>Все это сильно зависит от способа применения и изобретательности
kuj>>>Не понял. Поясни.
H>>Интерфейсы удобно рассматривать, как часть некого API. Отрыв от реализации и все такое. Зная, как они реализованы в Delphi, и в купе с агрегированием и делегированием можно получить приличные бенефиты используя эти знания. Блин, как я сегодня писать запарился...
kuj>В конечном итоге это костыль на фоне того, как применяются интерфейсе в управляемых средах типа .NET и Java
Все что за рамками шаблонного мышления -- костыль. Класс. Один обвиняет в ретроградстве, другой ярлыки навешивает. Нормальная компания
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, hattab, Вы писали:
H>>Да-да. Я это уже слышал и не раз. За короткий срок невозможно научиться грамотно программировать на чем-бы то нибыло. Я соглашусь, что двоечнику после Delphi-AccessViolation'ов будет легче под .Net/Java. Однако создавать качественного продукта он не сможет. Пердульки бухгалтерские его удел. Максимум.
L>...
H>>Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем.
L>Сопоставляя выделенное можно сделать неутешительные выводы.
Тебя бухгалтерия чтоль смутила? Так, как только разговор заходит о Delphi/C# сразу начинаются терки на тему корпоративных ИС. В большинстве своем это что?
Здравствуйте, kuj, Вы писали:
H>>Я еще раз говорю, у меня нет идеи доказать тебе чего-то Я описал реальную ситуацию, а вопросы веры это не ко мне.
kuj>Ты не описывал реальную ситуацию а сослался на какие-то там форумы, где кто-кто кому-то когда-то рекомендовал "понатыкать GC.Collect".
Здесь
kuj>>>Ты хоть понял о чем речь? В человеческой натуре допускать ошибки. Задача современного языка программирования создать максимально гибкий и удобный инструмент с минимальной вероятностью допустить ошибку по вине данного человеческого фактора.
H>>Да не избавляет вас управляемость от алгоритмических граблей и утечек.
kuj>Не панацея конечно, но в целом заметно улучшает ситуацию. Я это знаю по собственному опыту.
Фиг два она улучшает Расслабление внимания может аукнуться серьезными проблемами (ты же и сам об этом писал). В то время, как с утечками люди умеют бороться уже очень давно.
H>>Работая с инструментом надо знать, как с ним работать, а не так, как проповедовал gandjustas. Все вокруг этого вертится.
kuj>Да при чем тут это?
При том, что если я знаю что в Delphi нужно дергать Free я это делаю. А если человек не знает, что dbconnection нужно освободить... Поможет .Net в этом? Да-да using...
H>>Мы говорили о плюсах и минусах, если ты забыл. Ну и дженерики, это вроде как плюс .Net/Java. Но насколько это весомый плюс, большой вопрос. Я понят?
kuj>Да-да, игра в снукер это больше, чем яблоки, хотя мне рекомендовали покататься на сферических конях в банаховом пространстве...
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
H>>>>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы
kuj>>>Угу, пропал exe-шник — отвалилась голова.
H>>У тебя конфиги ни разу не слетали? Если у меня слетит конфиг, моя прилага не забудет как по XML-RPC разговаривать
kuj>Не знаю как оно в Делфи, но в .NET и Java конфиги не имеют такой привычки — куда-то там слетать...
И юзеры с админами ну прям небожители. Охотно верю.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
kuj>>>Выложить пару штук зеленых на железку или выложить пару сотен штук зеленых на разработку и сопровождение... Вот тебе и что.
H>>Я у тебя щас смету попрошу, по аналогии со ссылками. Давай напрягайся.
kuj>NDA.
Твой ответ был предсказуем на 99% Как только попросишь чего показать, так сразу NDA. Чтож, верю
H>>>>Такие выводы интересные? Ты чтоль разработкой под Delphi занимался и веб сервисы писал, чтоб такое говорить? А если писал, давай по пунктам . Или ты снова про дженерики будешь говорить
kuj>>>Занимался. Буду говорить и про дженерики, и про O/RM, и про MVC, и про Unit tests, и про extension methods, и про многое другое.
H>>Ты по пунктам давай...
kuj>А смысл? Сам же сказал только что, что не спец?
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
H>>>>Т.е. все не веб-девелоперы сидят в глубокой #опе прогресса... Я говорю, WebSnap был уже в 6 версии (ты говоришь сидел на 7 и не знаешь об этом?) И вообще, не сотвори себе кумира.
kuj>>>Что на этом WebSnap`е хоть было написано? Урлы сайтов плиз.
H>>Если тебе интересны существующие проекты под WebSnap, самое время погрузиться в гугл. Мне оно надо?
kuj>Это ведь ты его привел в качестве примера?
Я привер пример тула. Чего еще? Примеры нужны? Ищи. Только думаю это все в корпоративном секторе, коли на него нацелено...
Здравствуйте, hattab, Вы писали:
kuj>>>>Выложить пару штук зеленых на железку или выложить пару сотен штук зеленых на разработку и сопровождение... Вот тебе и что.
H>>>Я у тебя щас смету попрошу, по аналогии со ссылками. Давай напрягайся.
kuj>>NDA.
H>Твой ответ был предсказуем на 99% Как только попросишь чего показать, так сразу NDA. Чтож, верю
Нефига себе "чего". Может тебе еще ключи от квартиры, где деньги лежат?
H>>>>>Такие выводы интересные? Ты чтоль разработкой под Delphi занимался и веб сервисы писал, чтоб такое говорить? А если писал, давай по пунктам . Или ты снова про дженерики будешь говорить
kuj>>>>Занимался. Буду говорить и про дженерики, и про O/RM, и про MVC, и про Unit tests, и про extension methods, и про многое другое.
H>>>Ты по пунктам давай...
kuj>>А смысл? Сам же сказал только что, что не спец?
H>Так я хоть сравню объем траха
Здравствуйте, kuj, Вы писали:
H>>>>Я у тебя щас смету попрошу, по аналогии со ссылками. Давай напрягайся.
kuj>>>NDA.
H>>Твой ответ был предсказуем на 99% Как только попросишь чего показать, так сразу NDA. Чтож, верю
kuj>Нефига себе "чего". Может тебе еще ключи от квартиры, где деньги лежат?
Я всего лишь смету попросил... Ну, смету громко сказано Интересно было посмотреть, как ты там рассчитал все на два килобакса с железкой и кучей килобаксов с поддержкой и споровождением
kuj>Трах это не к нам.
kuj>>>>Ты хоть понял о чем речь? В человеческой натуре допускать ошибки. Задача современного языка программирования создать максимально гибкий и удобный инструмент с минимальной вероятностью допустить ошибку по вине данного человеческого фактора.
H>>>Да не избавляет вас управляемость от алгоритмических граблей и утечек.
kuj>>Не панацея конечно, но в целом заметно улучшает ситуацию. Я это знаю по собственному опыту.
H>Фиг два она улучшает Расслабление внимания может аукнуться серьезными проблемами (ты же и сам об этом писал). В то время, как с утечками люди умеют бороться уже очень давно.
FxCop проверка у нас вмонтированная в билд-сервер. Так что даже при желании не сломаешь.
H>>>Работая с инструментом надо знать, как с ним работать, а не так, как проповедовал gandjustas. Все вокруг этого вертится.
kuj>>Да при чем тут это?
H>При том, что если я знаю что в Delphi нужно дергать Free я это делаю. А если человек не знает, что dbconnection нужно освободить... Поможет .Net в этом? Да-да using...
FxCop поможет... И не только с этой проблемой, кстати.
Здравствуйте, hattab, Вы писали:
kuj>>>>Я тебе как разработчик .Net с 99% вероятностью скажу, что фризы эти, если они и имеют место, не имеют отношения к GC.
H>>>Мне как пользователю этой пердульки мало интересно отчего она замерзает время от времени. Я виже результат. Мне если честно лень мониторить перфкоунтеры .Net GC, чтоб сказать точно.
kuj>>Ну и при чем тут был наезд на .NET`овский GC? Ляпнул наобум? Или ты думаешь, что на Делфи нельзя написать так, чтоб не было фризов и прочих глюков? Ой-вэй...
H>Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом.
Ну мало-ли что они там делают в интерфейсном потоке?
kuj>>>>>>В том, что GC один на всех. Если один процесс пнет его — очисти кучу в то время, как другой процесс нагружает его alloc`ами, то что произойдет? GC сам должен регулировать этот процесс, чтоб для пользователя он был абсолютно незаметным.
H>>>>>Мы точно о Delphi говорим? kuj>>>>Конечно нет. В Delphi (не .NET) нет GC.
H>>>В таком случае о каких процессах шла речь и что это за минусы тут приписали Delphi?
kuj>>Речь шла о том, что в Delphi нет ни полноценного GC, ни нормальной реализации smart pointer типа boost::auto_ptr<>.
H>>>>>Какие там разные процессы? Или ты про разные Delphi-процессы? Там же нет такого отдельного понятия, как GC в .Net/Java. Просто есть типы с управляемым временем жизни. Вышла переменная из области видимости -- компилер ее тут же зафиналил. Все просто и эффективно.
kuj>>>>Ты не путай GC и недо- smart pointers. kuj>>>>В C++, например, есть реализация smart pointers (в boost), базирующаяся на подсчете ссылок. Это куда эффективнее области видимости.
H>>>Я и не путаю. Я ясность внес. Ты сказал что типы с управляемым временм жизни в Delphi это ее минус. Я вот уже на протяжении больше половины топика пытаюсь из тебя истуну выудить -- почему?
kuj>>Я такого не говорил. Давай не будем перекручивать слова, ага?
H>А кого я квотил-то? Читай с "В том, что GC один на всех"?
Читай выделенное жирным.
kuj>>>>>>Я писал где-то в этом топике. Вся сила интерфейсов раскрывается при наличии полноценного DI/IoC контейнера.
H>>>>>Все это сильно зависит от способа применения и изобретательности
kuj>>>>Не понял. Поясни.
H>>>Интерфейсы удобно рассматривать, как часть некого API. Отрыв от реализации и все такое. Зная, как они реализованы в Delphi, и в купе с агрегированием и делегированием можно получить приличные бенефиты используя эти знания. Блин, как я сегодня писать запарился...
kuj>>В конечном итоге это костыль на фоне того, как применяются интерфейсе в управляемых средах типа .NET и Java
H>Все что за рамками шаблонного мышления -- костыль. Класс. Один обвиняет в ретроградстве, другой ярлыки навешивает. Нормальная компания
Все что можно делать в Делфи, можно делать и в .NET, но не все, что можно делать в .NET, можно сделать в Delphi. Улавливаешь мысль?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, hattab, Вы писали:
H>>>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно) G>>Хо-хо-хо. Сколько стоит экспресс версия Visual С#? Не поверишь — нисколько. А продуктивность программистов на шарпе гораздо выше, чем на делфях (сравниваю с 7 версией, но из написанного понятно что даже современные версии не догоняют). G>>Как раз языки и платформы имеет смысл сравнивать не в формате нравится\не нравится, а в количественном измерении: "стоимость" программистов, стоимость обучения программистов, среднее время разработки, средняя плотность багов.
H>Ты знаешь, TurboDelphi Explorer так же абсолютно бесплатна. С полноценным гуй-дизайнером и новыми фичами среды. Pro версия стоила кажется, что-то около $400. Цен на 2007 к сожалению не знаю, но думаю там все в тех же рамках.
Turbo Delphi Explorer не позволяет устанавливать компоненты. т.е. Unicode приложение ты УЖЕ не сделаешь -> фтопку.
Turbo 2006 а не 2007, и в России уже не купишь.
Здравствуйте, kuj, Вы писали:
kuj>>>Не панацея конечно, но в целом заметно улучшает ситуацию. Я это знаю по собственному опыту.
H>>Фиг два она улучшает Расслабление внимания может аукнуться серьезными проблемами (ты же и сам об этом писал). В то время, как с утечками люди умеют бороться уже очень давно.
kuj>FxCop проверка у нас вмонтированная в билд-сервер. Так что даже при желании не сломаешь.
И у нас об утечках лог создается... Где, сколько и чего утекло
H>>>>Работая с инструментом надо знать, как с ним работать, а не так, как проповедовал gandjustas. Все вокруг этого вертится.
kuj>>>Да при чем тут это?
H>>При том, что если я знаю что в Delphi нужно дергать Free я это делаю. А если человек не знает, что dbconnection нужно освободить... Поможет .Net в этом? Да-да using...
kuj>FxCop поможет... И не только с этой проблемой, кстати.
Я знаю, что такое FxCop У Борланда давно уже был CodeGuadr для C++ (задачи примерно те же).
Здравствуйте, kuj, Вы писали:
H>>Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом.
kuj>Ну мало-ли что они там делают в интерфейсном потоке?
А ссылку читал? Есть идеи?
kuj>>>>>>>В том, что GC один на всех. Если один процесс пнет его — очисти кучу в то время, как другой процесс нагружает его alloc`ами, то что произойдет? GC сам должен регулировать этот процесс, чтоб для пользователя он был абсолютно незаметным.
H>>>>>>Мы точно о Delphi говорим? kuj>kuj>>>>Конечно нет. В Delphi (не .NET) нет GC.
H>>>>В таком случае о каких процессах шла речь и что это за минусы тут приписали Delphi?
kuj>>>Речь шла о том, что в Delphi нет ни полноценного GC, ни нормальной реализации smart pointer типа boost::auto_ptr<>.
H>>>>>>Какие там разные процессы? Или ты про разные Delphi-процессы? Там же нет такого отдельного понятия, как GC в .Net/Java. Просто есть типы с управляемым временем жизни. Вышла переменная из области видимости -- компилер ее тут же зафиналил. Все просто и эффективно.
kuj>>>>>Ты не путай GC и недо- smart pointers. kuj>>>>>В C++, например, есть реализация smart pointers (в boost), базирующаяся на подсчете ссылок. Это куда эффективнее области видимости.
H>>>>Я и не путаю. Я ясность внес. Ты сказал что типы с управляемым временм жизни в Delphi это ее минус. Я вот уже на протяжении больше половины топика пытаюсь из тебя истуну выудить -- почему?
kuj>>>Я такого не говорил. Давай не будем перекручивать слова, ага?
H>>А кого я квотил-то? Читай с "В том, что GC один на всех"?
kuj>Читай выделенное жирным.
Я уже десять раз перечитал. В чем минус управляемых типов в Delphi?
H>>Все что за рамками шаблонного мышления -- костыль. Класс. Один обвиняет в ретроградстве, другой ярлыки навешивает. Нормальная компания
kuj>Все что можно делать в Делфи, можно делать и в .NET, но не все, что можно делать в .NET, можно сделать в Delphi. Улавливаешь мысль?
Все что делается в .Net можно сделать и в Delphi (другим способом, соответствующим реалиям). Если ты думаешь, что чего-то сделать невозможно, это твое большое заблуждение.
Здравствуйте, squid, Вы писали:
H>>>>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно) G>>>Хо-хо-хо. Сколько стоит экспресс версия Visual С#? Не поверишь — нисколько. А продуктивность программистов на шарпе гораздо выше, чем на делфях (сравниваю с 7 версией, но из написанного понятно что даже современные версии не догоняют). G>>>Как раз языки и платформы имеет смысл сравнивать не в формате нравится\не нравится, а в количественном измерении: "стоимость" программистов, стоимость обучения программистов, среднее время разработки, средняя плотность багов.
H>>Ты знаешь, TurboDelphi Explorer так же абсолютно бесплатна. С полноценным гуй-дизайнером и новыми фичами среды. Pro версия стоила кажется, что-то около $400. Цен на 2007 к сожалению не знаю, но думаю там все в тех же рамках.
S>Turbo Delphi Explorer не позволяет устанавливать компоненты. т.е. Unicode приложение ты УЖЕ не сделаешь -> фтопку.
Правда? Есть библы, строящие гуй по XML-декларации (что-то типа WPF получается). Гуй строится в их дизайнере, а потом создается в рантайме без всяких хлопот. Это сложный вариант (и ссылок не дам, ибо за ненадобностью не храню) А есть простой. У меня в TurboDelphi Explorer установлены сторонние компоненты. Делов на пять минут, и ни каких хаков и нарушений лицензии. Косяк в другом. Качество Турбы не сильно на высоте
S>Turbo 2006 а не 2007, и в России уже не купишь. S>спасибо, Борланд!!!
Ну, пусть не турбо, просто 2007 Pro (Std), что много стоит?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, squid, Вы писали:
H>>>>>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно) G>>>>Хо-хо-хо. Сколько стоит экспресс версия Visual С#? Не поверишь — нисколько. А продуктивность программистов на шарпе гораздо выше, чем на делфях (сравниваю с 7 версией, но из написанного понятно что даже современные версии не догоняют). G>>>>Как раз языки и платформы имеет смысл сравнивать не в формате нравится\не нравится, а в количественном измерении: "стоимость" программистов, стоимость обучения программистов, среднее время разработки, средняя плотность багов.
H>>>Ты знаешь, TurboDelphi Explorer так же абсолютно бесплатна. С полноценным гуй-дизайнером и новыми фичами среды. Pro версия стоила кажется, что-то около $400. Цен на 2007 к сожалению не знаю, но думаю там все в тех же рамках.
S>>Turbo Delphi Explorer не позволяет устанавливать компоненты. т.е. Unicode приложение ты УЖЕ не сделаешь -> фтопку.
H>Правда? Есть библы, строящие гуй по XML-декларации (что-то типа WPF получается). Гуй строится в их дизайнере, а потом создается в рантайме без всяких хлопот. Это сложный вариант (и ссылок не дам, ибо за ненадобностью не храню) А есть простой. У меня в TurboDelphi Explorer установлены сторонние компоненты. Делов на пять минут, и ни каких хаков и нарушений лицензии.
гиморно это. если компонент сложный придеться париться и ставить руками все авто-инсталлера.
H> Косяк в другом. Качество Турбы не сильно на высоте
ну, тот-же 2006 насколько я понимаю. в плане компилятора и IDE. мне и 2007 по многим причинам не нравится.
S>>Turbo 2006 а не 2007, и в России уже не купишь. S>>спасибо, Борланд!!!
H>Ну, пусть не турбо, просто 2007 Pro (Std), что много стоит?
30К не много?? учитывая что VS 2008 имеет в разы больше возможностей и стоит раза в три дешевле. даже не знаю,
кто сейчас будет новый проект на Delphi начинать.
Turbo было их единственной правильной идеей за последние 5 лет. разумеется они сами ее и обосрали. ИМХО конечно.
Здравствуйте, hattab, Вы писали:
kuj>>>>Не панацея конечно, но в целом заметно улучшает ситуацию. Я это знаю по собственному опыту.
H>>>Фиг два она улучшает Расслабление внимания может аукнуться серьезными проблемами (ты же и сам об этом писал). В то время, как с утечками люди умеют бороться уже очень давно.
kuj>>FxCop проверка у нас вмонтированная в билд-сервер. Так что даже при желании не сломаешь.
H>И у нас об утечках лог создается... Где, сколько и чего утекло
У нас нету утечек. Ты не понял. FxCop анализирует сборку на соответствие наборам правил. Статически, а не в рантайм.
kuj>>FxCop поможет... И не только с этой проблемой, кстати.
H>Я знаю, что такое FxCop У Борланда давно уже был CodeGuadr для C++ (задачи примерно те же).
Здравствуйте, hattab, Вы писали:
H>>>Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом.
kuj>>Ну мало-ли что они там делают в интерфейсном потоке?
H>А ссылку читал? Есть идеи?
О чем речь? Какая ссылка?
kuj>>Читай выделенное жирным.
H>Я уже десять раз перечитал. В чем минус управляемых типов в Delphi?
Повторяю, что я нигде не говорил минус это или плюс.
H>>>Все что за рамками шаблонного мышления -- костыль. Класс. Один обвиняет в ретроградстве, другой ярлыки навешивает. Нормальная компания
kuj>>Все что можно делать в Делфи, можно делать и в .NET, но не все, что можно делать в .NET, можно сделать в Delphi. Улавливаешь мысль?
H>Все что делается в .Net можно сделать и в Delphi (другим способом, соответствующим реалиям). Если ты думаешь, что чего-то сделать невозможно, это твое большое заблуждение.
Сделай O/RM, соответствующий по функциональности nHibernate. Искренне желаю удачи.
Здравствуйте, wallaby, Вы писали:
W>Здравствуйте, goto, Вы писали:
G>>Сей ужас был в основном пораньше, > 10 лет назад. Из-за этого, в частности, многие вещи, совершенно не вычислительные, когда-то даже писали на FORTRAN IV, это был едва ли не единственный общий знаменатель. Потом им стал С.
W>Там где я начинал трудовую деятельность мейнфрейм (IBM/360) сдали на металлолом около 15 лет назад. Кстати, в нём была куча драгметаллов, вырученных денег хватило на несколько самых современных по тем временам персоналок. А cофт (в основном Кобол, меньше — Фортрана и PL) переводили на FoxPro, когда я оттуда уволился.
В той конторе, где начинал я, мэйнфреймы и т. наз. мини-эвм, жили подольше. Парк был очень разнообразным. Собирались еще ставить Эльбрус. Да, формально отмечу, что забыл про относительно стандартный PL/1, приходилось его использовать для переносимости из-за личной нелюбви к Фортрану 4.
Здравствуйте, squid, Вы писали:
S>>>Turbo Delphi Explorer не позволяет устанавливать компоненты. т.е. Unicode приложение ты УЖЕ не сделаешь -> фтопку.
H>>Правда? Есть библы, строящие гуй по XML-декларации (что-то типа WPF получается). Гуй строится в их дизайнере, а потом создается в рантайме без всяких хлопот. Это сложный вариант (и ссылок не дам, ибо за ненадобностью не храню) А есть простой. У меня в TurboDelphi Explorer установлены сторонние компоненты. Делов на пять минут, и ни каких хаков и нарушений лицензии.
S>гиморно это. если компонент сложный придеться париться и ставить руками все авто-инсталлера.
Кому как Меня не напрягло ни сколько
H>> Косяк в другом. Качество Турбы не сильно на высоте
S>ну, тот-же 2006 насколько я понимаю. в плане компилятора и IDE. мне и 2007 по многим причинам не нравится.
Я сам 2007 не смотрел (но народу вроде нравится), фига там работу над ошибками разглядвать. Выйдет 2008 -- поглядим.
S>>>Turbo 2006 а не 2007, и в России уже не купишь. S>>>спасибо, Борланд!!!
H>>Ну, пусть не турбо, просто 2007 Pro (Std), что много стоит?
S>30К не много?? учитывая что VS 2008 имеет в разы больше возможностей и стоит раза в три дешевле. даже не знаю, S>кто сейчас будет новый проект на Delphi начинать.
24700 Это если с нуля. А если апдейт?
S>Turbo было их единственной правильной идеей за последние 5 лет. разумеется они сами ее и обосрали. ИМХО конечно.
Идея Турбы мы тоже понравилась, я думал будут продолжать. Видимо их Российский контракт приободрил, что они решили не размениваться
Здравствуйте, vitaly_spb, Вы писали:
G>>>>>1)Свойства kuj>>>>Java get/set G>>>Это не свойства
kuj>>Как это не свойства, а что это?
_>Свойства — это просто синтаксический сахар к такой записи. Не считая различных фишек вроде биндинга по-умолчанию.
Свойства это просто синтаксический сахар. Согласен. И что?
Здравствуйте, hattab, Вы писали:
H>>> Косяк в другом. Качество Турбы не сильно на высоте
S>>ну, тот-же 2006 насколько я понимаю. в плане компилятора и IDE. мне и 2007 по многим причинам не нравится.
H>Я сам 2007 не смотрел (но народу вроде нравится), фига там работу над ошибками разглядвать. Выйдет 2008 -- поглядим.
2007 с тремя сервиспаками — жить можно. просто вышла виста, они добавили чуть-чуть, выпустили бяку.
сейчас через год бяку уже дописали до нормального состояния. помоему так. потому-что все баги с отрисовкой IDE в начальной версии нормальной работы не подразумевали.
S>>>>Turbo 2006 а не 2007, и в России уже не купишь. S>>>>спасибо, Борланд!!!
H>>>Ну, пусть не турбо, просто 2007 Pro (Std), что много стоит?
S>>30К не много?? учитывая что VS 2008 имеет в разы больше возможностей и стоит раза в три дешевле. даже не знаю, S>>кто сейчас будет новый проект на Delphi начинать.
H>24700 Это если с нуля. А если апдейт?
вот апдейт как-раз как студия стоит :D а откуда у меня апдейт?)
S>>Turbo было их единственной правильной идеей за последние 5 лет. разумеется они сами ее и обосрали. ИМХО конечно.
H>Идея Турбы мы тоже понравилась, я думал будут продолжать. Видимо их Российский контракт приободрил, что они решили не размениваться
просто глупо это блин. две платные Delphi по сути, а еще и RAD Studio.
Здравствуйте, kuj, Вы писали:
H>>>>Фиг два она улучшает Расслабление внимания может аукнуться серьезными проблемами (ты же и сам об этом писал). В то время, как с утечками люди умеют бороться уже очень давно.
kuj>>>FxCop проверка у нас вмонтированная в билд-сервер. Так что даже при желании не сломаешь.
H>>И у нас об утечках лог создается... Где, сколько и чего утекло
kuj>У нас нету утечек. Ты не понял. FxCop анализирует сборку на соответствие наборам правил. Статически, а не в рантайм.
Я понимаю прекрасно Я написал, как оно у нас. Контроль есть. Такого как в FxCop нет, но говорят была какая-то подобная сторонняя тулза. Видимо нафиг не нужна никому
kuj>>>FxCop поможет... И не только с этой проблемой, кстати.
H>>Я знаю, что такое FxCop У Борланда давно уже был CodeGuadr для C++ (задачи примерно те же).
kuj>А говоришь, что знаешь.......
Написал же примерно Его цель -- повышение качества кода. Только и всего.
Здравствуйте, kuj, Вы писали:
H>>>>Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом.
kuj>>>Ну мало-ли что они там делают в интерфейсном потоке?
H>>А ссылку читал? Есть идеи?
kuj>О чем речь? Какая ссылка?
Я таки привел ссылку на тему с хобота.
kuj>>>Читай выделенное жирным.
H>>Я уже десять раз перечитал. В чем минус управляемых типов в Delphi?
kuj>Повторяю, что я нигде не говорил минус это или плюс.
H>Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток?
В общем случае это таки недостаток. Особенно, когда нет в наличии generic smart pointer`ов (прерогатива C++).
kuj>>>Все что можно делать в Делфи, можно делать и в .NET, но не все, что можно делать в .NET, можно сделать в Delphi. Улавливаешь мысль?
H>>Все что делается в .Net можно сделать и в Delphi (другим способом, соответствующим реалиям). Если ты думаешь, что чего-то сделать невозможно, это твое большое заблуждение.
kuj>Сделай O/RM, соответствующий по функциональности nHibernate. Искренне желаю удачи.
Не вижу ничего нереального в задаче сделать маппинг.
Здравствуйте, hattab, Вы писали:
H>>>>>Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом.
kuj>>>>Ну мало-ли что они там делают в интерфейсном потоке?
H>>>А ссылку читал? Есть идеи?
kuj>>О чем речь? Какая ссылка?
H>Я таки привел ссылку на тему с хобота.
Еще раз повторяю: GC никак не может создавать эффект фриза, т.к. этот эффект возможен только от операции выполняемой в интерфейсном потоке — операция подвешивает цикл обработки сообщений — интерфейс перестает перерисовываться — эффект фриза.
kuj>>>>Читай выделенное жирным.
H>>>Я уже десять раз перечитал. В чем минус управляемых типов в Delphi?
kuj>>Повторяю, что я нигде не говорил минус это или плюс.
H>А это чье: здесь
H>>Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток?
H>В общем случае это таки недостаток. Особенно, когда нет в наличии generic smart pointer`ов (прерогатива C++).
Ты издеваешься? Читай выделенное до просветления:
H>>>>>>Мы точно о Delphi говорим?
kuj>kuj>>>>Конечно нет. В Delphi (не .NET) нет GC.
kuj>>>>Все что можно делать в Делфи, можно делать и в .NET, но не все, что можно делать в .NET, можно сделать в Delphi. Улавливаешь мысль?
H>>>Все что делается в .Net можно сделать и в Delphi (другим способом, соответствующим реалиям). Если ты думаешь, что чего-то сделать невозможно, это твое большое заблуждение.
kuj>>Сделай O/RM, соответствующий по функциональности nHibernate. Искренне желаю удачи.
H>Не вижу ничего нереального в задаче сделать маппинг.
Здравствуйте, hattab, Вы писали:
H>Все что делается в .Net можно сделать и в Delphi (другим способом, соответствующим реалиям). Если ты думаешь, что чего-то сделать невозможно, это твое большое заблуждение.
Еще раз повторяю, все современные языки полны по тьюрингу. То есть то что сделано на одном языке — может быть сделано на другом.
Спорить об этом смысла нет.
Вопрос только времени, необходимой квалификации программиста и плотности ошибок в коде. В этом вопросе Delphi сильно отстает от управляемых сред.
H>Не вижу ничего нереального в задаче сделать маппинг.
А ты сделай. А потом сделай "защиту от дурака", чтобы нельзя было вызвать Free для объекта просто так, чтобы он умирал только при завершении сессии
Посмотрим сколько времени тебе понадобится. Кстати ORM движки для Delphi вообще существуют?
Здравствуйте, gandjustas, Вы писали:
H>>Все что делается в .Net можно сделать и в Delphi (другим способом, соответствующим реалиям). Если ты думаешь, что чего-то сделать невозможно, это твое большое заблуждение.
G>Еще раз повторяю, все современные языки полны по тьюрингу. То есть то что сделано на одном языке — может быть сделано на другом. G>Спорить об этом смысла нет.
Нет, речь о том, что есть приемы, которые недоступны неуправляемой среде. Да, можно на Delphi написать свою управляемую среду, но никто этого делать в здравом уме не станет.
GC, DI, interaction-based тесты, AoP на атрибутах, O/RM — яркие примеры того, что есть в .NET и чего нет в Delphi.
H>>Не вижу ничего нереального в задаче сделать маппинг. G>А ты сделай. А потом сделай "защиту от дурака", чтобы нельзя было вызвать Free для объекта просто так, чтобы он умирал только при завершении сессии G>Посмотрим сколько времени тебе понадобится. Кстати ORM движки для Delphi вообще существуют?
Не существуют. Полноценный O/RM в неуправляемой среде не возможен.
Здравствуйте, hattab, Вы писали:
H>Правда? Есть библы, строящие гуй по XML-декларации (что-то типа WPF получается). Гуй строится в их дизайнере, а потом создается в рантайме без всяких хлопот.
Ты вообще WPF писал?
На днях разработчика от Microsoft показывали что может Silverlight 2.0 (а это ограниченное подмножество WPF). Там был текстбокс, который вращался вокруг своей центральной точки, в фоне которого играло видео. Текст ввовдимый туда имел градиентный цвет.
Для делфи есть что-то подобное? (можешь не отвечать)
Здравствуйте, kuj, Вы писали:
kuj>Не существуют. Полноценный O/RM в неуправляемой среде не возможен.
Ну если почитать фаулера, то возможен. Все метаданные хранить в XML и применять статическую генерацию кода.
Здравствуйте, hattab, Вы писали:
H>Он умный все же чаще по делу...
Пример уже заезженый, но всё-таки:
var pTexture : IDirect3DTextture9l
...
pTexture := nil;
В выделенной строке будет аксесс виолейшн, если переменная уже nil.
K>>3. Серьёзные проблемы с юникодом в VCL
Мы вроде бы говорим о VCL?
H>IDE ни к чему не подталкивает. На начальном этапе, да, можно писать очень криво. Если это вошло в систему, ну... ССЗБ.
Тем не менее такого кода я видел тонны. Рассуждать можно столько угодно, но факт остаётся фактом.
H>Да, Майкрософт отказала влючать пакеты Borland'а в Windows. Политика.
Ну тут действительно — не проблема среды, но всё-таки мы имеем то, что мы имеем.
H>А зачем мне совместимость IDE? Чего там совмещать?
DPK, DPR'ы, да и DCUшки от разных версий несовместимы между собой.
H>И кошек вы вероятно тоже не любите... Нет никакой проблемы с указателями -- можно использовать так, как только заблагороссудится. Можно типизированно, можно без типизации. Готовить нужно уметь
Ну так покажите, как их нужно готовить. Желательно на примере заполнения вершинного буфера IDirect3DVertexBuffer9. Стандартный плюсовый код вы без проблем найдёте в гугле.
H>Я бы мог поставить диагноз... Но обижать не хочется
Диагноз своему отцу ставьте. А тут просьба объективно отвечать на вопросы...
Здравствуйте, kuj, Вы писали:
H>>>>А ссылку читал? Есть идеи?
kuj>>>О чем речь? Какая ссылка?
H>>Я таки привел ссылку на тему с хобота.
kuj>Еще раз повторяю: GC никак не может создавать эффект фриза, т.к. этот эффект возможен только от операции выполняемой в интерфейсном потоке — операция подвешивает цикл обработки сообщений — интерфейс перестает перерисовываться — эффект фриза.
Ты ссылку читал? Там фризы на обслуживании клиентского запроса сервисом.
kuj>>>>>Читай выделенное жирным.
H>>>>Я уже десять раз перечитал. В чем минус управляемых типов в Delphi?
kuj>>>Повторяю, что я нигде не говорил минус это или плюс.
H>>А это чье: здесь
H>>>Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток?
H>>В общем случае это таки недостаток. Особенно, когда нет в наличии generic smart pointer`ов (прерогатива C++).
kuj>Ты издеваешься? Читай выделенное до просветления:
kuj>
H>>>>>>>Мы точно о Delphi говорим?
kuj>>kuj>>>>Конечно нет. В Delphi (не .NET) нет GC.
Чего ты мне показываешь последующие посты? Я и пытался из тебя в дальнейшем объяснение отквоченному вытянуть, о якобы недостатке.
kuj>>>>>Все что можно делать в Делфи, можно делать и в .NET, но не все, что можно делать в .NET, можно сделать в Delphi. Улавливаешь мысль?
H>>>>Все что делается в .Net можно сделать и в Delphi (другим способом, соответствующим реалиям). Если ты думаешь, что чего-то сделать невозможно, это твое большое заблуждение.
kuj>>>Сделай O/RM, соответствующий по функциональности nHibernate. Искренне желаю удачи.
H>>Не вижу ничего нереального в задаче сделать маппинг.
kuj>Сильно. Ладно. Все ясно... Шеридан #2.
Здравствуйте, hattab, Вы писали: H>WebSnap. Ребята, оно было еще в 6 версии. Intraweb еще круче
Да, было и что с того? Много можно привести примеров известных проектов на веб снапе или интравебе? В WWW asp.net — куда ни плюнь, везде наткнешься, всяческие питоны, джавы тоже распространены. В корпоративном пространстве — я, чесно говоря, ХЗ, но если пробежаться по айтишным вакансиям на каком-нить сайте про работу можно составить примерно такое же мнение. Ну да, клево, "дал" нам борланд инструмент для веба — а дальше что? Сдается мне, что WebSnap потому не стал так популярен, как тот же ASP.NET, что имел определенные недостатки. Если я правильно нагуглил, то один недостаток — в плане удобства развертывания — уже есть. Насколько я понял, WebSnap для каждого приложения генерит отдельный NSAPI-модуль, что, ИМХО, оверкилл и лишние телодвижения при развертывании.
Здравствуйте, gandjustas, Вы писали:
H>>Все что делается в .Net можно сделать и в Delphi (другим способом, соответствующим реалиям). Если ты думаешь, что чего-то сделать невозможно, это твое большое заблуждение.
G>Еще раз повторяю, все современные языки полны по тьюрингу. То есть то что сделано на одном языке — может быть сделано на другом. G>Спорить об этом смысла нет.
Чего ты мне-то повторяешь? Я этим лишь на высказывание kuj'а ответил.
G>Вопрос только времени, необходимой квалификации программиста и плотности ошибок в коде. В этом вопросе Delphi сильно отстает от управляемых сред.
Это все бла-бла-бла. Не понятно, толи под .Net'ом одни гении сидят, толи под Delphi дураки, что всегда все не в пользу последних. Неубедительно.
H>>Не вижу ничего нереального в задаче сделать маппинг. G>А ты сделай. А потом сделай "защиту от дурака", чтобы нельзя было вызвать Free для объекта просто так, чтобы он умирал только при завершении сессии G>Посмотрим сколько времени тебе понадобится. Кстати ORM движки для Delphi вообще существуют?
Ты мне еще предложи Windows перписать на Delphi, ага. По поводу ORM не в курсе, я этими плюшками не балуюсь
hattab пишет: > OCT>2) Чего не хватает: > OCT>иерархическое пространство имён; -- тоже не хватает > > Nested types появились в 2005/6. Или речь о другом?
Иерархия модулей. Как в .NET, Java, CL и практически везде.
> OCT>автоматическая финализация; > > Есть, для управляемых типов.
Самые обычные объекты — управляемые?
> Кроме статики и динамики какие еще варианты? А вообще Array Of xxxx.
типа такого:
var
Buffer: array[1 .. NeededLength(...)] of ...;
// NeededLength — вызов функции
> Я тоже полюбил Ada после прочтения RM95
Когда я читал, была уже 05.
> Справедливости ради, сейчас CodeGear взялась за язык (что еще развивать > в GUI под нативом). Правят древние баги, добавляют языковые фичи. > Роадмап у них, в принципе, интересный. В анкете интересовались вопросами > кросплатформенности (Linux/MacOS)...
Справедливости ради, добавили бы поддержку Ады туда. Или возможность её
органично вписать. Там COFF будет?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, hattab, Вы писали:
H>>Правда? Есть библы, строящие гуй по XML-декларации (что-то типа WPF получается). Гуй строится в их дизайнере, а потом создается в рантайме без всяких хлопот.
G>Ты вообще WPF писал? G>На днях разработчика от Microsoft показывали что может Silverlight 2.0 (а это ограниченное подмножество WPF). Там был текстбокс, который вращался вокруг своей центральной точки, в фоне которого играло видео. Текст ввовдимый туда имел градиентный цвет.
При чем тут вообще WPF? Я аналогию скромную провел, а ты в слово вцепиться решил? Не писал и не буду писать. Кому вообще, кроме впечатлительных школьниц, эта клоунада (градиенты бла-бла-бла) нужна?
G>Для делфи есть что-то подобное? (можешь не отвечать)
G>Не сравнивай "божий дар с яичницой"
А-а-а, так это божий дар Я подозревал, что тут не все чисто
Здравствуйте, hattab, Вы писали:
H>Это все бла-бла-бла. Не понятно, толи под .Net'ом одни гении сидят, толи под Delphi дураки, что всегда все не в пользу последних. Неубедительно.
Это факт, я это своими глазами наблюдаю.
H>По поводу ORM не в курсе, я этими плюшками не балуюсь
Иногда лучше молчать, чем говорить.
K>В выделенной строке будет аксесс виолейшн, если переменная уже nil.
Никогда таких проблем с интерфейсами небыло и нет по сей день.
K>>>3. Серьёзные проблемы с юникодом в VCL
K>Мы вроде бы говорим о VCL?
И что? Поставь дополнительные компоненты, это нормальная практика. Или ты еще скажешь, что в Delphi проблемы с multimedia т.к. приличных компонент в комплекте нет.
H>>IDE ни к чему не подталкивает. На начальном этапе, да, можно писать очень криво. Если это вошло в систему, ну... ССЗБ.
K>Тем не менее такого кода я видел тонны. Рассуждать можно столько угодно, но факт остаётся фактом.
Первопричина не в IDE, а в голове/руках.
H>>А зачем мне совместимость IDE? Чего там совмещать?
K>DPK, DPR'ы, да и DCUшки от разных версий несовместимы между собой.
Что за бред? Никогда при миграции проблемы с этим не возникали. DCU вообще в тему -- результат компиляции, с фига он должен быть с чем-то там совместим? Это побочный продукт.
H>>И кошек вы вероятно тоже не любите... Нет никакой проблемы с указателями -- можно использовать так, как только заблагороссудится. Можно типизированно, можно без типизации. Готовить нужно уметь
K>Ну так покажите, как их нужно готовить. Желательно на примере заполнения вершинного буфера IDirect3DVertexBuffer9. Стандартный плюсовый код вы без проблем найдёте в гугле.
Это далеко от меня, еще дальше чем ORM Но у меня сейчас такая работа, что в основном интерфейсы и указатели -- ноль проблем.
H>>Я бы мог поставить диагноз... Но обижать не хочется
K>Диагноз своему отцу ставьте. А тут просьба объективно отвечать на вопросы...
Проблема в том, что ты вопросов не задаешь. Ты рассыпался в необъяснимых ошибках, которыми тебя мучал компилятор. А в этом случае диагноз один и он известен.
TheEvilOne пишет: > Как так не хакерская? Некоторые особо одаренные люди пишут на дельфях не > только драйвера уровня ядра для виндовс ХР, но и вирусы > различные
Встречал один раз вирус на Visual Basic. Он мониторил открытые папки, и
эвакуировал себя в другую папку, как только там появлялся пользователь.
Т. е. заходишь ФАРом в WINDOWS/HELP, в листинге он есть, но на самом
деле он уже WINDOWS/INF, заходишь в WINDOWS/INF, а он уже в
WINDOWS/ещё–что–нибудь. При этом меняет запись в реестре для своей
автозагрузки. А если ключ автозагрузки убрать, то добавляет его через
полминуты.
Здравствуйте, Mr.Cat, Вы писали:
H>>WebSnap. Ребята, оно было еще в 6 версии. Intraweb еще круче
MC>Да, было и что с того? Много можно привести примеров известных проектов на веб снапе или интравебе? В WWW asp.net — куда ни плюнь, везде наткнешься, всяческие питоны, джавы тоже распространены. В корпоративном пространстве — я, чесно говоря, ХЗ, но если пробежаться по айтишным вакансиям на каком-нить сайте про работу можно составить примерно такое же мнение. Ну да, клево, "дал" нам борланд инструмент для веба — а дальше что? Сдается мне, что WebSnap потому не стал так популярен, как тот же ASP.NET, что имел определенные недостатки. Если я правильно нагуглил, то один недостаток — в плане удобства развертывания — уже есть. Насколько я понял, WebSnap для каждого приложения генерит отдельный NSAPI-модуль, что, ИМХО, оверкилл и лишние телодвижения при развертывании.
Да ничего с того. А что? Мне вообще странно, когда Delphi сравнивают с тулом для веб-разработки. Да, были и есть в ней приблуды для веба, но нужно же понимать, что это не основное ее предназначение.
Здравствуйте, OCTAGRAM, Вы писали:
>> Nested types появились в 2005/6. Или речь о другом? OCT>Иерархия модулей. Как в .NET, Java, CL и практически везде.
Vendor.App.Lib1.Class1? Это есть.
>> OCT>автоматическая финализация; >> >> Есть, для управляемых типов. OCT>Самые обычные объекты — управляемые?
Нет конечно Advanced records (class-like) финалятся
>> Кроме статики и динамики какие еще варианты? А вообще Array Of xxxx. OCT>типа такого: OCT>
OCT>var
OCT> Buffer: array[1 .. NeededLength(...)] of ...;
OCT> // NeededLength — вызов функции
OCT>
Чем это будет отличаться от:
Var
Buffer : Array Of ...;
Begin
SetLength(Buffer, NeededLength(...));
...
>> Справедливости ради, сейчас CodeGear взялась за язык (что еще развивать >> в GUI под нативом). Правят древние баги, добавляют языковые фичи. >> Роадмап у них, в принципе, интересный. В анкете интересовались вопросами >> кросплатформенности (Linux/MacOS)... OCT>Справедливости ради, добавили бы поддержку Ады туда. Или возможность её OCT>органично вписать. Там COFF будет?
Здравствуйте, hattab, Вы писали:
H>Никогда таких проблем с интерфейсами небыло и нет по сей день.
Ну так объясните — почему? Желательно, без помощи поиска
H>И что? Поставь дополнительные компоненты, это нормальная практика. Или ты еще скажешь, что в Delphi проблемы с multimedia т.к. приличных компонент в комплекте нет.
Проблема в том, что работа с вещами, которых нет в стандартной поставке, сводится к поиску компонент, в то время как в C/C++, например, вопрос заключается в подключении нужных заголовков/либ из PSDK и курения MSDNа
H>Первопричина не в IDE, а в голове/руках.
Тем не менее мы имеем то, что имеем. Может покажите пример правильного, с вашей точки зрения, кода?
H>Что за бред? Никогда при миграции проблемы с этим не возникали. DCU вообще в тему -- результат компиляции, с фига он должен быть с чем-то там совместим? Это побочный продукт.
Это не бред, а реальная проблема либо для разработчика компонентов (нужно собирать отдельно под каждую версию), либо для пользователя этих компонентов (заводить компоненты от D6 в D7 удовольствие сомнительное).
H>Это далеко от меня, еще дальше чем ORM Но у меня сейчас такая работа, что в основном интерфейсы и указатели -- ноль проблем.
Здравствуйте, hattab, Вы писали: H>Да, были и есть в ней приблуды для веба, но нужно же понимать, что это не основное ее предназначение.
Воо. Дотнету, например, ничто не мешает конкурировать с дельфи (я имею в виду дельфи как платформу: язык дельфи+VCL/CLX+тулзы от борланда) в его нише и при этом иметь не приблуды, а полноценные инструменты для веба.
Здравствуйте, hattab, Вы писали: H>При чем тут вообще WPF? Я аналогию скромную провел, а ты в слово вцепиться решил? Не писал и не буду писать. Кому вообще, кроме впечатлительных школьниц, эта клоунада (градиенты бла-бла-бла) нужна?
Неужели надо объяснять, кому и зачем нужны flash/flex и все их красивости? (Афаик, именно с это парочкой должен конкурировать сильверлайт).
Здравствуйте, koandrew, Вы писали:
H>>Никогда таких проблем с интерфейсами небыло и нет по сей день.
K>Ну так объясните — почему? Желательно, без помощи поиска
Что объяснять? Почему проблем нет? Так все дело в руках, в чем же еще. Или ты думаешь, что никто кроме тебя DirectX из под Delphi не юзал чтоль? Я тут ссылочку давал на wiki со списком Delphi-софта, даже там есть чего-то на DX. Однозначно это не косяк Delphi (у нее была проблема с кодогенерацией на константных массивах, но к делу явно отношения не имеет).
H>>И что? Поставь дополнительные компоненты, это нормальная практика. Или ты еще скажешь, что в Delphi проблемы с multimedia т.к. приличных компонент в комплекте нет.
K>Проблема в том, что работа с вещами, которых нет в стандартной поставке, сводится к поиску компонент, в то время как в C/C++, например, вопрос заключается в подключении нужных заголовков/либ из PSDK и курения MSDNа
Ага Покури чего нибудь на счет OpenGL. Что нибудь близкое к GLScene. Боюсь обкуришься
H>>Первопричина не в IDE, а в голове/руках.
K>Тем не менее мы имеем то, что имеем. Может покажите пример правильного, с вашей точки зрения, кода?
Ниже смотри
H>>Что за бред? Никогда при миграции проблемы с этим не возникали. DCU вообще в тему -- результат компиляции, с фига он должен быть с чем-то там совместим? Это побочный продукт.
K>Это не бред, а реальная проблема либо для разработчика компонентов (нужно собирать отдельно под каждую версию), либо для пользователя этих компонентов (заводить компоненты от D6 в D7 удовольствие сомнительное).
Указатели (с побочным эффектом, в целях экономии памяти):
//Function XmlUnescapeString(Const AString : AnsiString) : AnsiString;
Var
CPos : Pointer;
SEnd : Pointer;
BStr : Pointer;
RPos : Pointer;
//Function _ShiftBuffer : Boolean;
Var
Len : Cardinal;
Begin
Result := Assigned(RPos);
If Result Then
Begin
Len := Cardinal(CPos) - Cardinal(BStr);
Move(BStr^, RPos^, Len);
Inc(Cardinal(RPos), Len);
End;
End;
//Begin
Result := AString;
CPos := Pointer(Result);
SEnd := Pointer(Integer(CPos) + Length(Result));
RPos := NIL;
While Cardinal(CPos) < Cardinal(SEnd) Do
Begin
If (PAnsiChar(CPos)^ = '&') And (Cardinal(CPos) + Cardinal(Length(XmlEscapedLessThanSign) - 1) <= Cardinal(SEnd)) Then
Begin
If CompareMem(CPos, PAnsiChar(XmlEscapedLessThanSign), Length(XmlEscapedLessThanSign)) Then
Begin
If Not _ShiftBuffer Then
RPos := CPos;
PAnsiChar(RPos)^ := '<';
Inc(Cardinal(RPos));
Cardinal(BStr) := Cardinal(CPos) + Cardinal(Length(XmlEscapedLessThanSign));
Inc(Cardinal(CPos), Length(XmlEscapedLessThanSign) - 1);
End
Else
If (Cardinal(CPos) + Cardinal(Length(XmlEscapedAmpersand) - 1) <= Cardinal(SEnd)) And
CompareMem(CPos, PAnsiChar(XmlEscapedAmpersand), Length(XmlEscapedAmpersand)) Then
Begin
If Not _ShiftBuffer Then
RPos := CPos;
PAnsiChar(RPos)^ := '&';
Inc(Cardinal(RPos));
Cardinal(BStr) := Cardinal(CPos) + Cardinal(Length(XmlEscapedAmpersand));
Inc(Cardinal(CPos), Length(XmlEscapedAmpersand) - 1);
End;
End;
Inc(Cardinal(CPos));
End;
_ShiftBuffer;
If Assigned(RPos) Then
SetLength(Result, Cardinal(RPos) - Cardinal(Result));
End;
//
Интерфейсы:
//Function TXmlRpcMethodsDescriber.GetParamDescriptionStruct(AMethodSignature : TXmlRpcService.IMethodSignature; AParamIndex : Integer; AParamType : TXmlRpcType) : IXmlRpcStruct;
Var
NamedParamsIntf : TXmlRpcService.IMethodNamedParams;
Begin// Создаем структуру описывающую параметр
Result := MakeXmlRpcStruct([mnType, mnDescription, mnOptional], [XmlRpcTypeToStr(AParamType), '', (AParamType <> xrtNil) And (xrtNil In AMethodSignature.GetParamTypes(AParamIndex))]);
// Если поддерживаются именованные параметры, получаем имя текущегоIf AMethodSignature.QueryInterface(TXmlRpcService.IMethodNamedParams, NamedParamsIntf) = S_OK Then
Result.InsertBefore(0, mnName, NamedParamsIntf.GetParamName(AParamIndex));
End;
//
Смотри. Что тебе это даст, мне не понятно...
H>>Проблема в том, что ты вопросов не задаешь. Ты рассыпался в необъяснимых ошибках, которыми тебя мучал компилятор. А в этом случае диагноз один и он известен.
K>Диагноз тут только у тебя, причём характерный для дельфистов...
1)Такой объем кода совсем без комментов — моветон
2)Многовато кода для обычного replace
3)Нет поддержки Uincode
4)Разве в стандартных средствах нет такой функции?
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, hattab, Вы писали: H>>Да, были и есть в ней приблуды для веба, но нужно же понимать, что это не основное ее предназначение. MC>Воо. Дотнету, например, ничто не мешает конкурировать с дельфи (я имею в виду дельфи как платформу: язык дельфи+VCL/CLX+тулзы от борланда) в его нише и при этом иметь не приблуды, а полноценные инструменты для веба.
WebSnap вполне себе полноценный инструмент. IntraWeb аналогично, с той разницей, что захостить IntraWeb удастся скорее всего, либо на дедике, либо на своем железе. Их направленность именно корпоративный сектор. Для простых страничек нужно использовать что нибудь другое.
G>1)Такой объем кода совсем без комментов — моветон G>2)Многовато кода для обычного replace G>3)Нет поддержки Uincode G>4)Разве в стандартных средствах нет такой функции?
1. Этот код будет переложен на ассемблер, если будет не лень
2. Это цена за скорость и аккуратную работу с памятью. Знаете, как в Delphi строки устроены?
3. Бай дизайн. Работаем только с однобайтовыми кодировками. Весь юникод идет в UTF-8
4. Именно такой нет. Есть StringReplace, но для моей задачи он не подходит.
Здравствуйте, hattab, Вы писали:
H>1. Этот код будет переложен на ассемблер, если будет не лень H>2. Это цена за скорость и аккуратную работу с памятью. Знаете, как в Delphi строки устроены? H>3. Бай дизайн. Работаем только с однобайтовыми кодировками. Весь юникод идет в UTF-8 H>4. Именно такой нет. Есть StringReplace, но для моей задачи он не подходит.
Похоже на ЖИРНУЮ точку в этом топике. Все уродство Delphi на лицо... Добавить нечего.
Здравствуйте, hattab, Вы писали: H>>>Да, были и есть в ней приблуды для веба, но нужно же понимать, что это не основное ее предназначение. H>WebSnap вполне себе полноценный инструмент.
Вы уж это... сами определитесь, приблуда это или полноценный инструмент
H>Что объяснять? Почему проблем нет? Так все дело в руках, в чем же еще. Или ты думаешь, что никто кроме тебя DirectX из под Delphi не юзал чтоль? Я тут ссылочку давал на wiki со списком Delphi-софта, даже там есть чего-то на DX. Однозначно это не косяк Delphi (у нее была проблема с кодогенерацией на константных массивах, но к делу явно отношения не имеет).
Так всё-таки может объяснишь тогда хотя бы как надо? Напомню пример:
var pTexture : IDirect3DTextture9;
...
pTexture := nil; //тут будет аксесс виолейшн, если переменная уже nil.
H>Ага Покури чего нибудь на счет OpenGL. Что нибудь близкое к GLScene. Боюсь обкуришься
Именно его и курил по докам. В чём сложность-то?
H>Компоненты должы всегда предоставляться в исходниках. Это первое правило при использовании сторонней либы. Иначе ССЗБ.
В первой функции 30% кода — это приведение типов. Разве это нормально?
H>У меня сегодня круговая оборона, все нормально
Кстати, у меня до сих пор осталась привычка возвращаемую переменную называть Result — привет из прошлого дельфийского опыта Хотя на дельфях уже лет 5 ничего не писал
Здравствуйте, misha_irpen, Вы писали:
_>Постоянно читая RSDN имел возможность неоднократно убедиться что большинство участников сильно не любят Delphi. Уж очень стало интересно, а за что собственно?
Лень все ответы читать, отвечу как думаю сам.
_>Сам я от большого программинга уже отошел, хотя по прежнему могу считать себя профессионалом Delphi и ASM. И у меня приактически никогда не возникало проблем из-за каких-то ограничений языка. Я с уверенностью могу сказать, что могу написать на нем абсолютно все что угодно в рамках имеющихся API и математических моделей. При этом практически никогда не приходится изобретать велосипедов и извращаться чтобы обойти ограничения языка или стандартных библиотек. В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин?
1) Язык. многословный, не всегда последовательный.
2) Сильная типизация. Сама по себе вещь хорошая, но в дельфи это такая вещь в себе. когда начинаешь юзать сторонние апи, она летит к черту.
3) Для какого то нового апи или библиотеки надо писать обертки/декларации, или искать, может уже кем-то написано. Для С/С++ это обычно в комплекте идет.
4) Наличие компонентов "на все случаи жизни". Шаг влево, шаг вправо == попытка к бегству, расстрел. гемор, если начинаешь делать что-то отличающееся.
5) Программисты дельфи. это самое мрачное. был грешок, работал долгое время на поддержке дельфевых прилад. начальнег (мегакрутой спец по дельфи и прикладной области), как то с трепетом мне показал единственный! юнит, который он сделал, оформив его для повторного использования. в юните была одна функция, разбивавшая строку по табам вроде. в коде этой функции раз пять в разных местах было сравнение с явно прописанной константой символа таб. на мое замечание, почему бы это значение не вынести в аргументы и получить более универсальную функцию, этот чел сказал — хм, интересная мысль.
Ну а так — язык как язык, есть своя ниша. Но я лично цпп предпочитаю.
_>Во время пика своей популярности Delphi занимал ту нишу, которыю ныне занимают управляемые языки программирования. Выходит что позиционирование у него верное, неужели всм оказалась так нужна эта управляемость кода? Кстати, сборка мусора для некоторых типов данных (строки и динамические массивы) у Delphi была уже тогда.
Язык кривой. Сборки мусора не было у строк. просто автоматически память выделялась под паскаль строки длинной до 255 символов. это как если бы говорить, что у std::string есть сборка мусора. Массивы, я так понимаю, подразумеваются не динамические, а автоматические.
_>Или может вам не нравиься Pascal? Но из других ваших сообщений явно следует что синтаксис -- это вторичное, да и наездов на него я вроде как не видел...
Не нравится. какашка язык.
_>Просветите плиз вашу точку зрения, только объективно. Сетования на многомилионную армию малограмотных формоклепальщиков не принимаются, это не есть свойство языка или среды разработки.
есть. свойство. языка. и среды. моск атрофируется. на билдере тоже формошлепщики есть, хотя таких меньше. потому что с дельфей никто не пересаживается — язык сложнее, и формы клепать труднее. кому это надо.
дельфи — в основном формошлепство, в этом ему нет конкурентов. и это без насмешек, это действительно очень удобно там. в билдере уже не так все просто. ничего другого, такого же удобного для клепания форм не видел. хотя в этом плане не старался развиватся и мог что-то пропустить.
самое печальное — знания дельфи, языка, компонент имхо не нужно особо. никаких фундаментальных идей там не найдешь, ничему новому не научишся. будешь ковырятся — только время зря потратишь.
Здравствуйте, misha_irpen, Вы писали:
_>Сам я от большого программинга уже отошел, хотя по прежнему могу считать себя профессионалом Delphi и ASM. И у меня приактически никогда не возникало проблем из-за каких-то ограничений языка. Я с уверенностью могу сказать, что могу написать на нем абсолютно все что угодно в рамках имеющихся API и математических моделей. При этом практически никогда не приходится изобретать велосипедов и извращаться чтобы обойти ограничения языка или стандартных библиотек. В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин?
По поводу выделенного. Си-шарпом вроде занимался тот же перец, который лет пятнадцать назад дизайнил дельфи.
Здравствуйте, Marty, Вы писали:
M>Язык кривой. Сборки мусора не было у строк. просто автоматически память выделялась под паскаль строки длинной до 255 символов. это как если бы говорить, что у std::string есть сборка мусора. Массивы, я так понимаю, подразумеваются не динамические, а автоматические.
Нет, подразумеваются именно динамические массивы и именно сборка мусора.
M>самое печальное — знания дельфи, языка, компонент имхо не нужно особо. никаких фундаментальных идей там не найдешь, ничему новому не научишся. будешь ковырятся — только время зря потратишь.
Применив делфи правильно и вовремя — можно время здорово сэкономить, как раз благодаря скорости формошлепства.
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, Marty, Вы писали:
M>>Язык кривой. Сборки мусора не было у строк. просто автоматически память выделялась под паскаль строки длинной до 255 символов. это как если бы говорить, что у std::string есть сборка мусора. Массивы, я так понимаю, подразумеваются не динамические, а автоматические.
С>Нет, подразумеваются именно динамические массивы и именно сборка мусора.
Напомните как они созданются и используются, а то что-то не могу вспомнить.
M>>самое печальное — знания дельфи, языка, компонент имхо не нужно особо. никаких фундаментальных идей там не найдешь, ничему новому не научишся. будешь ковырятся — только время зря потратишь.
С>Применив делфи правильно и вовремя — можно время здорово сэкономить, как раз благодаря скорости формошлепства.
можно. но это скорее относится к штучно изготавливаемым программам. в серийных обычно имеет смысл потратить время на оттачивание интерфейса
gandjustas пишет: > Еще раз повторяю, все современные языки полны по тьюрингу. > Спорить об этом смысла нет.
Нет, есть. Достаточно вспомнить, что такое эта машина Тьюринга. Число
занимает столько места, сколько оно есть. О производительности никогда
не встаёт вопроса. Вся эта машина Тьюринга — это чисто академические
заморочки. На практике тьюринг–полнота как таковая ещё имеет какой–то
смысл, но уравнивать ею языки не получится.
> То есть то что сделано на одном языке — может быть сделано на другом.
А вот физики говорят, что все поля эквивалентны, и при сверхбольших
энергиях становятся неотличимы (или что они там говорят?). В реальной
жизни это знание очень помогает, я заметил.
Здравствуйте, misha_irpen, Вы писали:
_>Просветите плиз вашу точку зрения, только объективно. Сетования на многомилионную армию малограмотных формоклепальщиков не принимаются, это не есть свойство языка или среды разработки.
Первые 10 страниц я прочитал, дальше уже не могу. Потому извиняюсь если дублирую чей-то другой пост.
Самое первое, что хотел бы заметить — это то, что мы живем в жестоком мире, где главное не качество, а маркетинг и продвижение. Сколько прекрасных технологий не выжило из-за более баблистых конкурентов? А сколько просто не вышло на рынок? А сколько авторов даже не начали работу из-за боязни конкурентов?
Короче все это — cruel world.
Сколько раз MS делала подлянки с частичным выполнением стандарта или недокументированым API? И в результате у конкурентов выходили несовместимые продукты, которые не могли предоставить весь функционал продуктов мс. ессно заказчики просили писать на технологии, которую "рекомендует" мс.
Как удается в таких условиях выжить джаве — мне непонятно, но sun держиться и они молодцы.
Потому уход делфи из рынка я считаю на 60% по маркетинговым причинам, а не техническим.
Теперь техническая часть.
Сразу оговорюсь — я с самых пеленок (в переносном смысле) ориенторовался на продукты MS исходя из простой как сало истины "бабло побеждает зло", но дальшие мысли попытаюсь сделать максимально объективными.
И еще: опыта в разработке на делфи у меня немного, использовал его когда только преподы заставляли писать именно на нем.
1. Делфи в некоторых вещах даже опередило свое время: в частности в datatable/gridview (может называется по-другому, но думаю все поняли). Такого уровня легкость работы с источниками данных и их отображением появилась только в .net 1.1/2.0 (2003/2005). НО при желании сделать "чуть влево-чуть вправо" надо было потратить намного больше усилий, чем сделать "по прямой". Это отталкивало и казалось что решение нерасширяемо (еще раз повторюсь, что это все ИМХО). Очень много механизмов в делфи скрыто от глаз девелопера, а вообще-то прятать надо их от юзера, а не девелопера.
2. Оптимизация. Я начинал писать любой модуль с {$O-}.
Один раз у меня был цикл
for i:=0 to 8 do
...
каково было мое удивление когда он после 8 шел в 9, 10 и так до 12, где вылезала ошибка доступа. Тогда я отнес код преподу, который слегка о*[удивился]*л с таких дел.
И это не единственный случай.
2.1. "Inaccessible due optimization". Кто знает, тот поймет.
3. IDE. Это самое слабое место всей цепочки.
3.1. Ошибка работы с чем-то.
Наверное все попадали в ситуацию когда Delphi IDE нарывалось на какую-то ошибку. Тогда оно начинало об этом гласить через какое-нить окно с единственной кнопкой "OK", часто еще с паузой в 2-3 с, с зависанием среды и в цикле. Например если что-то случилось с БД или компонент не найден.
3.2. Intellisense (ну или как там его) — мелочь, но неприятно.
Не прикалывало то что подсветка фильтрует следующий идентификатор согласно типа. Т.е., если я хочу написать
iSomeVal := getString().Length;
то метод getString() не высветится, т.к. он возвращает string а не integer.
3.3. Совсем мелочь, но задолбало. Удаление пустых обработчиков.
Лично я (потеряв из-за сбоев не один кусок кода) нажимаю Ctrl+S через каждые 5-10 с. А делфи "оптимизирует" код и удаляет пустые обработчики (в т.ч. и новосозданные). А еще когда не находит какой-то контрол норовит удалить его с формы. Такое впечатление, что из формы можно удалить контрол и все будет ОК — прога запашет. Типа девелоперы могут просто так кидать контролы.
4. "Закон один для всех". В делфи часто встречаются исключения. Например writeln — чуть ли не единственная функция, куда можно передать переменное к-во параметров. А вот простым смертным — низза. Похожая ситуация с массивами.
Остальные замечания еще меньше, потому даже писать не буду.
Резюме
Спрос на любую технологию формируется с двух сторон:
1. Заказчик.
1.1. Есть уже готовач инфраструктура на некой технологии. Отсюда некоторая инертность рынка.
1.2. Есть удачный опыт работы с технологией.
1.3. Просто скзали/услышая, что эта технология — круто.
2. Программист.
2.1. Опыт работы с технологией.
2.2. Удобство.
2.3. Библиотеки.
и т.д.
именно п.2. формируется из этих многих ИМХО которые перечислены в этой ветке (сила мелочей в том, что их много). Каждая мелочь (приятная и не очень) формирует ИМХО, которое потом формирует ИМХО коллективное, а в последствии — рынок. А еще на ИМХО влияет реклама и усилия по продвижению.
Вывод
Задача IT — предоставление сервисов в других областях народного хозяйства. Потому если вы можете сделать своего заказчика счастливым на delphi — делайте, ему скорее всего абсолютно пофиг что вы используете. Коллективное ИМХО отодвинуло delphi на второй план, но это абсолютно никому не мешает использовать его в своем проекте — главное чтобы закачик был счастлив.
If the message above is in English — means I'm wasting my work time and work computer to post here. No hard feelings
machine3000 пишет: > Также C++ даёт возможность размещать классы не только в куче, но и в > стеке и в глобальной памяти.
В C++ нельзя возвращать из функции объекты размера, не известного на
этапе компиляции.
а) строки
б) экземпляры потомка класса
C++ позволяет часть вещей сместить на стек, но не до конца. В этих
случаях будет динамическая память. IIRC в C++ нельзя конструировать
результат прямо на месте.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>C++ позволяет часть вещей сместить на стек, но не до конца. В этих OCT>случаях будет динамическая память. IIRC в C++ нельзя конструировать OCT>результат прямо на месте.
То есть?
Существует in-place new и RVO (return value optimization). В следующем Стандарте RVO станет более мощной из-за move constructors.
gandjustas пишет: > Я больше всего работал в Delphi7 — большенитсво впечатлений оттуда.
Delphi7 — это 2001й год. С тем же успехом можно ругать Windows за
дырявость, а IE — за отсутствие табов.
hattab пишет: > Vendor.App.Lib1.Class1? Это есть.
Delphi 2007?
>> > OCT>автоматическая финализация; >> > >> > Есть, для управляемых типов. > OCT>Самые обычные объекты — управляемые? > > Нет конечно Advanced records (class-like) финалятся
тоже 2007? в 2006 не помню такого
> Чем это будет отличаться от: > > Var > Buffer : Array Of ...; > > Begin > > SetLength(Buffer, NeededLength(...));
Быстродействием.
Здравствуйте, Niemand, Вы писали:
N>Один раз у меня был цикл N>
N>for i:=0 to 8 do
N>...
N>
N>каково было мое удивление когда он после 8 шел в 9, 10 и так до 12, где вылезала ошибка доступа. Тогда я отнес код преподу, который слегка о*[удивился]*л с таких дел.
Скорее всего хреновый был препод. Тема с оператором for постоянно всплывает в разных форумах по Delphi, проблема в том что отладчик неправильно показывает значение счётчика цикла for (если бы он его вообще не показывал, было бы меньше вопросов). На практике это часто выглядит так: пишется for-цикл с неочевидной ошибкой, начинают его отлаживать и обнаруживают, что ошибка проявляется когда счётчик цикла находится вне допустимого диапазона. Самое интересное начинается, если эта ошибка исчезает при отключении оптимизации или при замене for на while (и такое бывает ). У меня самого однажды было такое, для поиска ошибки пришлось неспешно изучать ассемблерный код в отладчике, и в результате for был оправдан.
---
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true
Здравствуйте, goto, Вы писали:
G>В той конторе, где начинал я, мэйнфреймы и т. наз. мини-эвм, жили подольше. Парк был очень разнообразным. Собирались еще ставить Эльбрус. Да, формально отмечу, что забыл про относительно стандартный PL/1, приходилось его использовать для переносимости из-за личной нелюбви к Фортрану 4.
А можно подробнее о переносимости? У нас как раз код на Фортране работал примерно на 6-7 разных платформах без переделки. И, если не ошибаюсь, работал быстрее PL/1. А в условиях дороговизны машинного времени с этим тоже нужно было считаться.
Здравствуйте, kuj, Вы писали:
H>>1. Этот код будет переложен на ассемблер, если будет не лень H>>2. Это цена за скорость и аккуратную работу с памятью. Знаете, как в Delphi строки устроены? H>>3. Бай дизайн. Работаем только с однобайтовыми кодировками. Весь юникод идет в UTF-8 H>>4. Именно такой нет. Есть StringReplace, но для моей задачи он не подходит.
kuj>Похоже на ЖИРНУЮ точку в этом топике. Все уродство Delphi на лицо... Добавить нечего.
Я уже привык вести тут неконструктивные споры. Ты про фризы давай растолкуй.
Здравствуйте, Mr.Cat, Вы писали:
H>>>>Да, были и есть в ней приблуды для веба, но нужно же понимать, что это не основное ее предназначение. H>>WebSnap вполне себе полноценный инструмент.
MC>Вы уж это... сами определитесь, приблуда это или полноценный инструмент
Ну вообще, для Delphi, это приблуда, ибо нифига не основную задачу решает на которую Delphi точилась. А так вообще инструмент, как инструмент...
Здравствуйте, koandrew, Вы писали:
H>>Что объяснять? Почему проблем нет? Так все дело в руках, в чем же еще. Или ты думаешь, что никто кроме тебя DirectX из под Delphi не юзал чтоль? Я тут ссылочку давал на wiki со списком Delphi-софта, даже там есть чего-то на DX. Однозначно это не косяк Delphi (у нее была проблема с кодогенерацией на константных массивах, но к делу явно отношения не имеет).
K>Так всё-таки может объяснишь тогда хотя бы как надо? Напомню пример: K>
K>var pTexture : IDirect3DTextture9;
K>...
K>pTexture := nil; //тут будет аксесс виолейшн, если переменная уже nil.
K>
К ошибкам такая конструкция приводить не должна. Если приводит, дело в коде. Еще может быть косяк с неправильным использованием интерфейсной переменной переданной в качестве константного параметра.
H>>Ага Покури чего нибудь на счет OpenGL. Что нибудь близкое к GLScene. Боюсь обкуришься
K>Именно его и курил по докам. В чём сложность-то?
До уровня GLScene. Сложность в том, что никакое готовое API тебе такого (как GLScene) высокого уровня не даст.
H>>Компоненты должы всегда предоставляться в исходниках. Это первое правило при использовании сторонней либы. Иначе ССЗБ.
K>А если всё-таки нужный мне компонент поставляется только в двоичном виде? Что делать?
Вполне. Мне так нравится. Можно было переписать с использованием типизированных указателей, но зачем? Я уже писал, что эта функция кандидат на полное переписывание на асме. Могу дать еще один пример с указателями:
//Procedure XmlRpcVarDispInvoke(Dest : PVariant; Const Source : Variant; CallDesc : PCallDesc; Params : Pointer); Cdecl;
Const
atTypeMask = $7F;
atByRef = $80;
Var
PIndex : Integer;
Strings : Array Of WideString;
StrLen : Integer;
ArgPtr : Pointer;
ArgType : Integer;
ArgByRef : Boolean;
//Procedure _IncArgPtr;
Begin{$REGION ' Контроль размера типов '}
{$IF SizeOf(Pointer) <> 4}
{$MESSAGE FATAL 'Проверить алгоритм расчета смещений (см. ComObj.DispatchInvoke)'}
{$IFEND}
{$ENDREGION}If ArgType <> varError Then
Begin
If Not ArgByRef Then
Case ArgType Of//
varVariant :
If PVarData(ArgPtr)^.VType <> varString Then
Inc(Cardinal(ArgPtr), SizeOf(TVarData) - SizeOf(Pointer));
//
//
varDouble .. varDate, varInt64 :
Inc(Cardinal(ArgPtr), 8 - SizeOf(Pointer));
//End;
Inc(Cardinal(ArgPtr), SizeOf(Pointer));
End;
End;
//Begin// Если кодирование юникода не блокировано и происходит вызов метода...If (EncodingLocks = 0) And (CallDesc.CallType = DISPATCH_METHOD) Then
Begin
StrLen := 0;
ArgPtr := Params;
// Перебираем все параметры...For PIndex := 0 To CallDesc.ArgCount - 1 Do
Begin// Получаем тип параметра и способ его передачи
ArgType := CallDesc.ArgTypes[PIndex] And atTypeMask;
ArgByRef := CallDesc.ArgTypes[PIndex] And atByRef <> 0;
//
// Если параметр является юникод-строкой...If ArgType = varOleStr Then
Begin// Увеличиваем размер массива перекодированных строк
SetLength(Strings, StrLen + 1);
// Если параметр передается по ссылке...If ArgByRef Then
Begin// Перекодируем строку и обновляем ссылку в параметре
Strings[StrLen] := Utf8Encode(PWideString(ArgPtr^)^);
Pointer(ArgPtr^) := Pointer(@Strings[StrLen])
End
Else// ... по значению...Begin// Перекодируем строку и обновляем ссылку в параметре
Strings[StrLen] := Utf8Encode(PWideString(ArgPtr)^);
Pointer(ArgPtr^) := Pointer(Strings[StrLen]);
End;
// Увеличиваем счетчик перекодированных строк
Inc(StrLen);
End;
// Считаем смещение следующего параметра
_IncArgPtr;
End;
End;
// Вызываем старую процедуру диспетчеризации вызова
OldVarDispProc(Dest, Source, CallDesc, Params);
End;
//
Здравствуйте, OCTAGRAM, Вы писали:
>> Vendor.App.Lib1.Class1? Это есть. OCT>Delphi 2007?
C 2005.
>>> > OCT>автоматическая финализация; >>> > >>> > Есть, для управляемых типов. >> OCT>Самые обычные объекты — управляемые? >> >> Нет конечно Advanced records (class-like) финалятся OCT>тоже 2007? в 2006 не помню такого
С 2005
>> Чем это будет отличаться от: >> >> Var >> Buffer : Array Of ...; >> >> Begin >> >> SetLength(Buffer, NeededLength(...)); OCT>Быстродействием.
У Delphi 2006 офигительно быстрый менеджер памяти.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>gandjustas пишет: >> Я больше всего работал в Delphi7 — большенитсво впечатлений оттуда. OCT>Delphi7 — это 2001й год. С тем же успехом можно ругать Windows за OCT>дырявость, а IE — за отсутствие табов.
Версии после Delphi 7 — с поддержкой .NET. Многие новшества, принесенные в язык — заслуга .NET
Здравствуйте, Сергей, Вы писали:
M>>самое печальное — знания дельфи, языка, компонент имхо не нужно особо. никаких фундаментальных идей там не найдешь, ничему новому не научишся. будешь ковырятся — только время зря потратишь.
С>Применив делфи правильно и вовремя — можно время здорово сэкономить, как раз благодаря скорости формошлепства.
Ты будешь сильно удивлен наверное, но "формошлепство" в полной мере есть в .NET
Здравствуйте, kuj, Вы писали:
G>>Не знаю как сейчас, но на Дельфи еще недавно учили толпы студентов и школьников (а какая альтернатива? Бэйсик?). Учили очень часто низкокачественно. Одно время действительно гуляло большое количество "крутых программистов на Дельфи", которые веселили искушенную публику разными штуками, и кодом. По личным ощущениям массово стали нормально учить программированию только последние несколько лет, и в серьезных местах преподают уже не Дельфи (если что, поправьте, пож-та, кто ближе к образованию).
kuj>Делфи все еще даже в ВУЗах на программистских специальностях преподают.
kuj>Программы в ВУЗах очень инертны — они никак не поспевают за стремительным развитием IT.
kuj>Вместо Delphi пора преподавать .NET технологии. kuj>Вместо Prolog — Erlang. kuj>и т.д.
Здравствуйте, misha_irpen, Вы писали:
Чем вам всем не угодил Delphi?
например тем, что приходится постоянно переписывать программы с Delphi на C++ для уменьшения их размера. К тому же, на Delphi сложнее написать хорошие игры. imho
Здравствуйте, se_sss, Вы писали:
G>>>Во всех программах на делфи, которые я видел, были утечки памяти. Для Java и .NET такого быть не может
J>>хм. прочем тут дельфи? Утечки памяти были, есть и будут во всех языках без GC
_>И с gc тоже. Ещё какие!
Здравствуйте, wallaby, Вы писали:
W>Скорее всего хреновый был препод. Тема с оператором for постоянно всплывает в разных форумах по Delphi, проблема в том что отладчик неправильно показывает значение счётчика цикла for (если бы он его вообще не показывал, было бы меньше вопросов). На практике это часто выглядит так: пишется for-цикл с неочевидной ошибкой, начинают его отлаживать и обнаруживают, что ошибка проявляется когда счётчик цикла находится вне допустимого диапазона. Самое интересное начинается, если эта ошибка исчезает при отключении оптимизации или при замене for на while (и такое бывает ). У меня самого однажды было такое, для поиска ошибки пришлось неспешно изучать ассемблерный код в отладчике, и в результате for был оправдан.
Оценку уже поставил, но добавлю — что если для поиска бага из-за комбинации РОДНОГО оптимизатора и РОДНОГО дебаггера надо лезть в асм, то надо выкидывать это далеко. А на месте препода сам был бы в недоумении.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, goto, Вы писали:
G>>В той конторе, где начинал я, мэйнфреймы и т. наз. мини-эвм, жили подольше. Парк был очень разнообразным. Собирались еще ставить Эльбрус. Да, формально отмечу, что забыл про относительно стандартный PL/1, приходилось его использовать для переносимости из-за личной нелюбви к Фортрану 4.
P>А можно подробнее о переносимости? У нас как раз код на Фортране работал примерно на 6-7 разных платформах без переделки. И, если не ошибаюсь, работал быстрее PL/1. А в условиях дороговизны машинного времени с этим тоже нужно было считаться.
Про Fortran IV я выше говорил, он обладал наилучшей переносимостью. Почему был выбран PL/1: много кода переносилось на PL/1 с Алгола (выбор здесь делал не только я, я вообще был студентом); больше нравился "эмоционально"; с более компактным кодом (меньше строк) тогда было удобнее работать технически.
Каких-то специальных сравнений производитеьлности PL и Фортрана мы тогда не проводили, но думаю, что компилятор PL/1 на IBM и ЕС был достаточно эффективным. А вот на одном компе (кажется это был Control Data. Точно не знаю, т.к. компы тогда часто ввозились контрабандно и им давались свои имена) мы как-то с одним мужиком написали независимо 2 программки, кот. использовали один и тот же выч. алгоритм. Писали не для соревнования, просто совпало, и считали они разные вещи. Я писал на PL. Для быстродействия нигде не ипользовал массивы, только структуры и пойнтеры (практически связные списки), оптимизировал циклы. А мужик написал на Фортране крайне незатейливо, в лоб, вообще без оптимизации с использованием кучи 2-мерных массивов даже в самых критических местах. Словом, как блондинка. Его программа работала быстрее моей! Я поначалу не мог поверить, просто в голове не укладывалось. Правда, конкретно на том компе компилятор PL был видимо совсем фиговым (реализовано было какое-то подмножество языка, называлось это кажись PL/M), но тем не менее. Только тогда я осознал, что Фортран — это очень круто . Оптимизация там офигительная.
Позже имел дело с мини-компами Norsk Data (графика, CAD), весьма передовыми в 90-х. Их система SINTRAN, если не изменяет склорез, была вообще написана на Фортране. API были заточены под Фортран. Весь их CAD был написан на нем. Вообще очень интересная система, оччень интересно был устроен UI.
Раз уж расвспоминался. Отношение к быстродействию программ было вообще странным. Мэйнфреймы были разные, и я не мог объективно судить, какой из них быстрее, насколько. Информации не было. Интерактивности не было. Там были не профессиональные программисты. Просто обычно надо было что-то посчитать, и ученые и инженеры садились сами писать программы, это было необходимой побочной работой. Доходило до смешного. В одну работающую программу на PL/1 в описание целочисленных переменных я добавил BIN(32) кажется (по дефолту там целые хранятся в десятичном формате). И программа реально заработала почти в 10 раз быстрее, т.к. при каждой индексации ей не приходилось преобразовывать типы. Мне сказали: шаман! И допустили к участию в принятии некоторых решений Т.е. программирование не было основным занятием.
Еще, если кому интересно, скажу, что производительность труда современного программера по сравнению с тогдашним, сидящим за терминалом мэйнфрейма, выше наверное раз в 10-30.
Здравствуйте, lifrsdn, Вы писали:
L>Оценку уже поставил, но добавлю — что если для поиска бага из-за комбинации РОДНОГО оптимизатора и РОДНОГО дебаггера надо лезть в асм, то надо выкидывать это далеко. А на месте препода сам был бы в недоумении.
Назови эффективную среду разработки свободную от граблей.
---
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true
Здравствуйте, wallaby, Вы писали:
L>>Оценку уже поставил, но добавлю — что если для поиска бага из-за комбинации РОДНОГО оптимизатора и РОДНОГО дебаггера надо лезть в асм, то надо выкидывать это далеко. А на месте препода сам был бы в недоумении.
W>Назови эффективную среду разработки свободную от граблей.
Здравствуйте, goto, Вы писали:
G>Про Fortran IV я выше говорил, он обладал наилучшей переносимостью.
+1 :beer:
G>Почему был выбран PL/1: много кода переносилось на PL/1 с Алгола (выбор здесь делал не только я, я вообще был студентом); больше нравился "эмоционально"; с более компактным кодом (меньше строк) тогда было удобнее работать технически.
G>Каких-то специальных сравнений производитеьлности PL и Фортрана мы тогда не проводили, но думаю, что компилятор PL/1 на IBM и ЕС был достаточно эффективным.
Их, если мне склероз не изменяет, было 2: PL/1-F и PL/1-O. Какой-то из них отладочный, а другой — оптимизирующий (на IBM/360). Фортранов, по-моему, тоже.
G>Правда, конкретно на том компе компилятор PL был видимо совсем фиговым (реализовано было какое-то подмножество языка, называлось это кажись PL/M), но тем не менее. Только тогда я осознал, что Фортран — это очень круто :) . Оптимизация там офигительная.
PL/M — это какой-то обрубок от PL/1. Зато, говорят, работал даже на CP/M-86.
G>Доходило до смешного. В одну работающую программу на PL/1 в описание целочисленных переменных я добавил BIN(32) кажется (по дефолту там целые хранятся в десятичном формате). И программа реально заработала почти в 10 раз быстрее, т.к. при каждой индексации ей не приходилось преобразовывать типы. Мне сказали: шаман! И допустили к участию в принятии некоторых решений :) Т.е. программирование не было основным занятием.
Преимущество Фортрана в том, что там не надо было об этом думать. А в PL/1 DEC FIXED — хорошим тормозом было. BIN FIXED — уже не помню. Помню только, то, что начиналось с I, J, K, L, M, N по умолчанию было BIN FIXED. Хотя могу и ошибаться, а в книжку лезть лень :)
G>Еще, если кому интересно, скажу, что производительность труда современного программера по сравнению с тогдашним, сидящим за терминалом мэйнфрейма, выше наверное раз в 10-30.
А если сравнить с ковыряющим дырки в перфокартах? ;)
Простите за offtopic. Не надо считать это развязыванием войны Fortran vs PL/1 :)
Здравствуйте, Cyberax, Вы писали:
P>>Простите за offtopic. Не надо считать это развязыванием войны Fortran vs PL/1 :) C>А что, в ней есть кому воевать? :)
Здравствуйте, goto, Вы писали:
G>Еще, если кому интересно, скажу, что производительность труда современного программера по сравнению с тогдашним, сидящим за терминалом мэйнфрейма, выше наверное раз в 10-30.
Зато какой был кайф когда после всех итераций цикла
1) написать программу на специальных бланках;
2) отдать барышне пробить перфокарты (которая постоянно путала 'S' и '5');
3) дождаться своего времени, запустить программу и получить листинг с ошибками;
4) исправить найденные ошибки и возвратиться к пункту 1)
программа запускалась на исполнение работала.
---
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true
Здравствуйте, Marty, Вы писали:
M>1) Язык. многословный, не всегда последовательный.
Типа плюсы сильно последовательные.
M>2) Сильная типизация. Сама по себе вещь хорошая, но в дельфи это такая вещь в себе. когда начинаешь юзать сторонние апи, она летит к черту.
Ни разу не замечал, примерчик можно?
M>3) Для какого то нового апи или библиотеки надо писать обертки/декларации, или искать, может уже кем-то написано. Для С/С++ это обычно в комплекте идет.
Это вина не языка.
M>4) Наличие компонентов "на все случаи жизни". Шаг влево, шаг вправо == попытка к бегству, расстрел. гемор, если начинаешь делать что-то отличающееся.
Ага, то есть наличие компонентов уже плохо Так не пользуйтесь ими вообще, в чем проблема-то?
M>5) Программисты дельфи. это самое мрачное. был грешок, работал долгое время на поддержке дельфевых прилад. начальнег (мегакрутой спец по дельфи и прикладной области), как то с трепетом мне показал единственный! юнит, который он сделал, оформив его для повторного использования. в юните была одна функция, разбивавшая строку по табам вроде. в коде этой функции раз пять в разных местах было сравнение с явно прописанной константой символа таб. на мое замечание, почему бы это значение не вынести в аргументы и получить более универсальную функцию, этот чел сказал — хм, интересная мысль.
Это не свойство языка и среды разработки.
M>Язык кривой. Сборки мусора не было у строк. просто автоматически память выделялась под паскаль строки длинной до 255 символов.
Какие 255 символов? Вы Delphi вообще видели, или по воспоминаниям о Turbo Pascal пишете?
_>>Массивы, я так понимаю, подразумеваются не динамические, а автоматические.
_>>Или может вам не нравиься Pascal? Но из других ваших сообщений явно следует что синтаксис -- это вторичное, да и наездов на него я вроде как не видел... M>Не нравится. какашка язык.
То же самое могу с уверенностью сказать по все сиподобные какашки, и хрен оспоришь.
_>>Просветите плиз вашу точку зрения, только объективно. Сетования на многомилионную армию малограмотных формоклепальщиков не принимаются, это не есть свойство языка или среды разработки. M>есть. свойство. языка. и среды. моск атрофируется.
Что за фигню вы пишете? От чего конткретно атрофируется "моск"?
M>дельфи — в основном формошлепство, в этом ему нет конкурентов. и это без насмешек, это действительно очень удобно там. в билдере уже не так все просто. ничего другого, такого же удобного для клепания форм не видел. хотя в этом плане не старался развиватся и мог что-то пропустить.
А чем все .NET-языки не формошлепство?
Здравствуйте, Privalov, Вы писали:
... P>А если сравнить с ковыряющим дырки в перфокартах?
...
Я когда студентом пришел "на базу", в НИИ, мне выдали 50 или 100 перфокарт и сказали: посчитай то-то, больше перфокарт не дадим. Потом придешь — может быть, посадим за терминал.
rsdn — место центровое. Надо устроить здесь виртуальный музей отечественной истории IT (отечественная будет интересней по-житейски). Могу предложить свое чучело в образе человека, держащего в руке перфокарту и разглядывающего на просвет дырки в ней, а в другой руке пусть будет лезвие безопасной бритвы . Но чучело — это не сейчас, попозже.
Здравствуйте, wallaby, Вы писали:
... W>Зато какой был кайф когда после всех итераций цикла W>1) написать программу на специальных бланках; W>2) отдать барышне пробить перфокарты (которая постоянно путала 'S' и '5'); W>3) дождаться своего времени, запустить программу и получить листинг с ошибками; W>4) исправить найденные ошибки и возвратиться к пункту 1)
W>программа запускалась на исполнение работала.
Вот последнее меня до сих пор не перестает удивлять. Хотя однажды мой дружище, анти-программер по натуре, как-то в 1-й раз в жизни прочитал книжку по Фортрану, написал на бумаге карандашом программу строк на 200-300, сам настучал код на терминале, распечатал и сверил текст по бумажке, запустил на счет... она все посчитала абсолютно правильно с первого раза, и даже в выводе сразу оказалось именно то, что он хотел! Свидетелем вот такого невероятно циничного события я был. И он после этого все также цинично еще годы (!) не подходил к компьютерам, ни к мэйнфреймам, ни к писюкам, ни к каким.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Privalov, Вы писали:
P>>Простите за offtopic. Не надо считать это развязыванием войны Fortran vs PL/1 C>А что, в ней есть кому воевать?
Здравствуйте, kuj, Вы писали:
_>>А чем все .NET-языки не формошлепство? kuj>.NET-языки ничего ни о каком формошлепстве не знают.
Ладно-ладно, уел! Скажу так: чем все современные визуальные IDE не формошлепство?
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, misha_irpen, Вы писали:
_>>А чем все .NET-языки не формошлепство?
kuj>.NET-языки ничего ни о каком формошлепстве не знают.
маленькая ремарка: в winforms форма генерируется с помощью *.designer.cs (*.designer.vb) файла, в котором лежит валидный исходник, который при желании можно поправить ручками (хотя лучше и не надо). В делфи есть dfm файлы, механизм привязки к коду которых скрыт (нет MessageMap'ов как MFC), что не дает такой свободы действий.
If the message above is in English — means I'm wasting my work time and work computer to post here. No hard feelings
Здравствуйте, goto, Вы писали:
G>rsdn — место центровое. Надо устроить здесь виртуальный музей отечественной истории IT (отечественная будет интересней по-житейски). Могу предложить свое чучело в образе человека, держащего в руке перфокарту и разглядывающего на просвет дырки в ней, а в другой руке пусть будет лезвие безопасной бритвы :)) . Но чучело — это не сейчас, попозже.
Здравствуйте, hattab, Вы писали:
H>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы
Гы. Это был аргумент из серии "я вот тут комп с десятого этажа уронил, теперь он гад загружаться не хочет". Догадываешься, что случится, если в линухе все конфиги пропадут? Конфиги — такие же файлы, как и екзешники.
Здравствуйте, wallaby, Вы писали:
W>Зато какой был кайф когда после всех итераций цикла W>1) написать программу на специальных бланках; W>2) отдать барышне пробить перфокарты (которая постоянно путала 'S' и '5'); W>3) дождаться своего времени, запустить программу и получить листинг с ошибками; W>4) исправить найденные ошибки и возвратиться к пункту 1)
W>программа запускалась на исполнение работала.
Бррр.... Не надо об этом, вот ради бога, не надо. Мазохисты блин. Кайф у них. Выпить ящик пива, потом сутки не ходить в туалет, а вот потом — сходить в туалет!
Здравствуйте, Niemand, Вы писали:
_>>>А чем все .NET-языки не формошлепство?
kuj>>.NET-языки ничего ни о каком формошлепстве не знают.
N>маленькая ремарка: в winforms форма генерируется с помощью *.designer.cs (*.designer.vb) файла, в котором лежит валидный исходник, который при желании можно поправить ручками (хотя лучше и не надо). В делфи есть dfm файлы, механизм привязки к коду которых скрыт (нет MessageMap'ов как MFC), что не дает такой свободы действий.
От кого скрыт? От формошлепщиков? Так от них много чего скрыто, если Ctrl+MouseClick юзать не умеют. Берешь dfm (благо он давно уже текстовый) и правишь, как душе угодно. Прям из IDE можешь. Все объявленные контролы увидишь в дизайнере (но они не станут членами класса. доступ к ним можно будет получить через свойства Controls и Components), все изменения будут мгновенно на них отражаться. О какой свободе речь?
Здравствуйте, Дм.Григорьев, Вы писали:
H>>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы
ДГ>Гы. Это был аргумент из серии "я вот тут комп с десятого этажа уронил, теперь он гад загружаться не хочет". Догадываешься, что случится, если в линухе все конфиги пропадут? Конфиги — такие же файлы, как и екзешники.
Какое мне дело до Линукса? Ни одного юзера не допрет править руками exe'шник, а конфиг за милу душу. Но если тебе приятно не замечать проблемы, чтож, хозяин -- барин.
_>Ладно-ладно, уел! Скажу так: чем все современные визуальные IDE не формошлепство?
Я так понимаю по-вашему в современных визуальных IDE иначе как формы клипать ничего не получится? И веб-сервисы, и win-сервисы, и консольные приложения не написать?
...Ei incumbit probatio, qui dicit, non qui negat...
H>>>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы
ДГ>>Гы. Это был аргумент из серии "я вот тут комп с десятого этажа уронил, теперь он гад загружаться не хочет". Догадываешься, что случится, если в линухе все конфиги пропадут? Конфиги — такие же файлы, как и екзешники.
H>Какое мне дело до Линукса? Ни одного юзера не допрет править руками exe'шник, а конфиг за милу душу. Но если тебе приятно не замечать проблемы, чтож, хозяин -- барин.
К слову .NET по-умолчанию пишет конфиг в скрытую папку в documents and settigs\<user>\local settings\app. data\<program folder> Только единицы пользователей его там найдут и еще меньше из них окажется достаточно криворукими, чтоб его удалить, а если это и случится при следующем запуске он будет создан по-новой из <app>.config`а, который хранит default значения для user settings.
Здравствуйте, kuj, Вы писали:
H>>Какое мне дело до Линукса? Ни одного юзера не допрет править руками exe'шник, а конфиг за милу душу. Но если тебе приятно не замечать проблемы, чтож, хозяин -- барин.
kuj>К слову .NET по-умолчанию пишет конфиг в скрытую папку в documents and settigs\<user>\local settings\app. data\<program folder> Только единицы пользователей его там найдут и еще меньше из них окажется достаточно криворукими, чтоб его удалить, а если это и случится при следующем запуске он будет создан по-новой из <app>.config`а, который хранит default значения для user settings.
Что-то с Янусом у вас, господа, не все так гладко...
Здравствуйте, kuj, Вы писали:
kuj>К слову .NET по-умолчанию пишет конфиг в скрытую папку в documents and settigs\<user>\local settings\app. data\<program folder> Только единицы пользователей его там найдут и еще меньше из них окажется достаточно криворукими, чтоб его удалить, а если это и случится при следующем запуске он будет создан по-новой из <app>.config`а, который хранит default значения для user settings.
Да и у WindowsLive Writer'а конфиге в его-же папочке лежат...
Здравствуйте, lifrsdn, Вы писали:
W>>>Назови эффективную среду разработки свободную от граблей.
kuj>>Все, что не Borland. :P
L>Очень уж категорично.
Это был сарказм.
В действительности вышеописанных граблей ни в одной нормальной среде разработки быть не должно.
Конечно определенные грабли есть везде — где-то меньше, где-то больше. Регулярно пользуюсь VS 2005, VS 2008, пару лет тому назад еще IntelliJ IDEA в арсенале была. Все отлично — на грабли натыкаться не приходиться, работать одно удовольствие.
Кстати, в Delphi в свое время сильно раздражал "не целостный" интерфейс, где каждое окно само по себе. Но это так — дело вкуса.
Здравствуйте, hattab, Вы писали:
H>>>Какое мне дело до Линукса? Ни одного юзера не допрет править руками exe'шник, а конфиг за милу душу. Но если тебе приятно не замечать проблемы, чтож, хозяин -- барин.
kuj>>К слову .NET по-умолчанию пишет конфиг в скрытую папку в documents and settigs\<user>\local settings\app. data\<program folder> Только единицы пользователей его там найдут и еще меньше из них окажется достаточно криворукими, чтоб его удалить, а если это и случится при следующем запуске он будет создан по-новой из <app>.config`а, который хранит default значения для user settings.
H>Что-то с Янусом у вас, господа, не все так гладко...
У кого это у нас? Я к Янусу вроде никакого отношения не имею и как у него конфиги устроены понятия не имею.
Вышеописанный механизм это стандартный из System.Configuration. Но никто не запрещает сериализовать свои объекты в xml или вообще конфиг писать в sqlite базу. Пользователю вообще знать не нужно в каком формате у него конфиг и в какой папке на диске его искать... Тут вам не Linux
Здравствуйте, hattab, Вы писали:
kuj>>К слову .NET по-умолчанию пишет конфиг в скрытую папку в documents and settigs\<user>\local settings\app. data\<program folder> Только единицы пользователей его там найдут и еще меньше из них окажется достаточно криворукими, чтоб его удалить, а если это и случится при следующем запуске он будет создан по-новой из <app>.config`а, который хранит default значения для user settings.
H>Да и у WindowsLive Writer'а конфиге в его-же папочке лежат...
Если конфиг стандартный, но в папке приложения лежит <assemblyname>.config, в котором описана application configuration — то, что общее для всех пользователей и не должно меняться в рантайм, типа connection strings, а так же default values для user configuration. При запуске на основании default values для user configuration будет автоматически по вышеуказанному пути создан файл конфига для текущего пользователя системы (в случае, если он отсутствует).
Здравствуйте, kuj, Вы писали:
kuj>Вышеописанный механизм это стандартный из System.Configuration. Но никто не запрещает сериализовать свои объекты в xml или вообще конфиг писать в sqlite базу. Пользователю вообще знать не нужно в каком формате у него конфиг и в какой папке на диске его искать... Тут вам не Linux
Здравствуйте, hattab, Вы писали:
kuj>>Вышеописанный механизм это стандартный из System.Configuration. Но никто не запрещает сериализовать свои объекты в xml или вообще конфиг писать в sqlite базу. Пользователю вообще знать не нужно в каком формате у него конфиг и в какой папке на диске его искать... Тут вам не Linux
H>Я не о настроечных конфигах приложений, с которыми вообще ни каких проблем быть не должно при их потере. Я говорю http://www.rsdn.ru/forum/message/2309620.1.aspx$$url0$$
Здравствуйте, hattab, Вы писали:
K>>Так всё-таки может объяснишь тогда хотя бы как надо? Напомню пример: K>>
K>>var pTexture : IDirect3DTextture9;
K>>...
K>>pTexture := nil; //тут будет аксесс виолейшн, если переменная уже nil.
K>>
H>К ошибкам такая конструкция приводить не должна. Если приводит, дело в коде. Еще может быть косяк с неправильным использованием интерфейсной переменной переданной в качестве константного параметра.
В общем, всё с вами понятно — много слов, и все не по делу. Ок, дам вам хинт — во что преобразовывается выделенная строка "мегаумным" компилятором? Ошибка между прочим будет видна только при дизассемблировании нагенерённого этим "умником" кода — и крови попортить она может порядочно, если не знать, в чём тут соль...
H>Я не встречал коммерческих компонентов без исходного кода. Даже Delphi и та идет с полными исходниками VLC и прочих либ. Если исходников нет -- искать у конкурентов, благо выбор есть всегда.
А я встречал. Более того, встречал массу бесплатных, распространяемых только в бинарном виде (видимо стесняются показать свой код ). И что?
H><code skipped>
Это уже на что-то похоже, хотя можно было бы и получше сделать. Кстати, позабавило соглашение о вызове у этой ф-ции — можете поделиться зачем оно понадобилось? Уж не для интеропа ли с С/С++
kuj>И? Криво писать можно в любой среде и ошибки — хлеб насущный в программировании.
И какова, в таком случае, цена тезисам о том, что .Net от чего-то там оберегает, FxCop'ами ругется, все вусмерть контролит. И это еще противопоставлялось Delphi. Смех да и только.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, kuj, Вы писали:
kuj>>К слову .NET по-умолчанию пишет конфиг в скрытую папку в documents and settigs\<user>\local settings\app. data\<program folder> Только единицы пользователей его там найдут и еще меньше из них окажется достаточно криворукими, чтоб его удалить, а если это и случится при следующем запуске он будет создан по-новой из <app>.config`а, который хранит default значения для user settings.
H>Да и у WindowsLive Writer'а конфиге в его-же папочке лежат...
Здравствуйте, koandrew, Вы писали:
K>>>Так всё-таки может объяснишь тогда хотя бы как надо? Напомню пример: K>>>
K>>>var pTexture : IDirect3DTextture9;
K>>>...
K>>>pTexture := nil; //тут будет аксесс виолейшн, если переменная уже nil.
K>>>
H>>К ошибкам такая конструкция приводить не должна. Если приводит, дело в коде. Еще может быть косяк с неправильным использованием интерфейсной переменной переданной в качестве константного параметра.
K>В общем, всё с вами понятно — много слов, и все не по делу. Ок, дам вам хинт — во что преобразовывается выделенная строка "мегаумным" компилятором? Ошибка между прочим будет видна только при дизассемблировании нагенерённого этим "умником" кода — и крови попортить она может порядочно, если не знать, в чём тут соль...
Гхм... Эта операция преобразуется в вызов системной (RTL) функции IntfClear. TurboDelphi 2006.
H>>Я не встречал коммерческих компонентов без исходного кода. Даже Delphi и та идет с полными исходниками VLC и прочих либ. Если исходников нет -- искать у конкурентов, благо выбор есть всегда.
K>А я встречал. Более того, встречал массу бесплатных, распространяемых только в бинарном виде (видимо стесняются показать свой код ). И что?
Я уже писал, если кто-то юзает компоненты/библиотеки без исходников -- ССЗБ. К Delphi-то какие претензии? Это чистейшая нелепица
H>><code skipped> K>Это уже на что-то похоже, хотя можно было бы и получше сделать. Кстати, позабавило соглашение о вызове у этой ф-ции — можете поделиться зачем оно понадобилось? Уж не для интеропа ли с С/С++
Сделать лучше... Делай! В чем проблема? За экраном все поголовно герои Соглашение о вызове не моя прихоть, а следование условиям системного (не RTL, но ComObj) COM-диспатчинга. В общем, для объяснения писать много нужно, а ты я помню не любишь, когда "многа букав"
K>>>pTexture := nil; //тут будет аксесс виолейшн, если переменная уже nil.
K>>>
K>Ок, дам вам хинт — во что преобразовывается выделенная строка "мегаумным" компилятором?
Там должен втыкаться pTexture.release() по идее (я с COM из-под Delphi очень давно работал, так что могу ошибиться). Но неужели они не проверяют на nil?
Здравствуйте, Константин Б., Вы писали:
H>>Да и у WindowsLive Writer'а конфиге в его-же папочке лежат...
КБ>Ты про WindowsLiveWriter.exe.config что ли?
КБ>
Здравствуйте, vitaly_spb, Вы писали:
_>>Ладно-ладно, уел! Скажу так: чем все современные визуальные IDE не формошлепство?
_>Я так понимаю по-вашему в современных визуальных IDE иначе как формы клипать ничего не получится? И веб-сервисы, и win-сервисы, и консольные приложения не написать?
Я даже больше скажу: в современной визуальной IDE под названием Eclipse формошлёпщик по умолчанию отсутствует. И ставить его мне совершенно не интересно, потому как программируя Swing вручную, я получаю гораздо более компактный, структурированный и универсальный код. (По крайней мере, по сравнению с тем, что генерировал JBuilder Enterprise 2007, раза в три компактнее точно).
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Там должен втыкаться pTexture.release() по идее (я с COM из-под Delphi очень давно работал, так что могу ошибиться). Но неужели они не проверяют на nil?
Представьте себе, но по состоянию на D7 (тогда я ушёл с дельфи) не проверяют
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Константин Б., Вы писали:
H>>>Да и у WindowsLive Writer'а конфиге в его-же папочке лежат...
КБ>>Ты про WindowsLiveWriter.exe.config что ли?
КБ>>
kuj>>И? Криво писать можно в любой среде и ошибки — хлеб насущный в программировании.
H>И какова, в таком случае, цена тезисам о том, что .Net от чего-то там оберегает, FxCop'ами ругется, все вусмерть контролит. И это еще противопоставлялось Delphi. Смех да и только.
Среда не убережет от алгоритмических ошибок, ясное дело. Что не так?
Здравствуйте, hattab, Вы писали:
H>>>Да и у WindowsLive Writer'а конфиге в его-же папочке лежат...
КБ>>Ты про WindowsLiveWriter.exe.config что ли?
КБ>>
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>>Там должен втыкаться pTexture.release() по идее (я с COM из-под Delphi очень давно работал, так что могу ошибиться). Но неужели они не проверяют на nil?
K>Представьте себе, но по состоянию на D7 (тогда я ушёл с дельфи) не проверяют
Наглая ложь . Я сейчас поставил семерку под виртуалку и... Тот же самый IntfClear, в котором проверка разумеется присутствует.
kuj>>>И? Криво писать можно в любой среде и ошибки — хлеб насущный в программировании.
H>>И какова, в таком случае, цена тезисам о том, что .Net от чего-то там оберегает, FxCop'ами ругется, все вусмерть контролит. И это еще противопоставлялось Delphi. Смех да и только.
kuj>Среда не убережет от алгоритмических ошибок, ясное дело. Что не так?
, какого типа конфиги имеются ввиду.
kuj>По приведенной ссылке нет ничего про WindowsLive Writer. Заканчивай позориться, hattab.
WLV упомянут, как имеющий конфиги в рабочей папке. Как и BDS2006, VisualStudio и многие другие. Т.ч. не надо песен об идеальном состоянии дел у .Net прилаг.
kuj>>>>И? Криво писать можно в любой среде и ошибки — хлеб насущный в программировании.
H>>>И какова, в таком случае, цена тезисам о том, что .Net от чего-то там оберегает, FxCop'ами ругется, все вусмерть контролит. И это еще противопоставлялось Delphi. Смех да и только.
kuj>>Среда не убережет от алгоритмических ошибок, ясное дело. Что не так?
H>Твои тезисы. Перечитай, переосмысли.
Какие еще мои тезисы? Давай уж конкретно с цитатами.
, какого типа конфиги имеются ввиду.
kuj>>По приведенной ссылке нет ничего про WindowsLive Writer. Заканчивай позориться, hattab.
H>WLV упомянут, как имеющий конфиги в рабочей папке. Как и BDS2006, VisualStudio и многие другие. Т.ч. не надо песен об идеальном состоянии дел у .Net прилаг.
Ты действительно так туго думаешь, или только притворяешься? Я уже объяснял пошагово как работает стандартный конфигуратор из System.Configuration.
, какого типа конфиги имеются ввиду.
kuj>>По приведенной ссылке нет ничего про WindowsLive Writer. Заканчивай позориться, hattab.
H>WLV упомянут, как имеющий конфиги в рабочей папке. Как и BDS2006, VisualStudio и многие другие. Т.ч. не надо песен об идеальном состоянии дел у .Net прилаг.
А чем конфиги в рабочей папке не нравятся?
Они как раз делалались чтобы приложение можно было обычным копированием перемещать на другой комп и не шаманить с реестром
Здравствуйте, hattab, Вы писали:
H>Наглая ложь . Я сейчас поставил семерку под виртуалку и... Тот же самый IntfClear, в котором проверка разумеется присутствует.
А у меня вот другие данные. Приведите ассемблерный код, сгенерённый компилером для этого куска кода — вот тогда и посмотрим... У меня D7 к сожалению нет — ибо не надо оно мне сто лет уже.
Здравствуйте, vitaly_spb, Вы писали:
_>Я так понимаю по-вашему в современных визуальных IDE иначе как формы клипать ничего не получится?
Я этого не говорил. Не нужно передергивать.
_>И веб-сервисы, и win-сервисы, и консольные приложения не написать?
Все это можно и на Delphi писать. Разве что для веба он не предназначен, но даже веб писать таки можно.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Я даже больше скажу: в современной визуальной IDE под названием Eclipse формошлёпщик по умолчанию отсутствует.
Угу, вот потому его и используют одни "энтузиасты" и нищие фирмы-однодневки. А в корпоративном секторе (где существует такое понятие как срок сдачи проекта) юзают VS, который формошлепщиком оборудован по-умолчанию.
ДГ>И ставить его мне совершенно не интересно, потому как программируя Swing вручную, я получаю гораздо более компактный, структурированный и универсальный код. (По крайней мере, по сравнению с тем, что генерировал JBuilder Enterprise 2007, раза в три компактнее точно).
О какой компактности вообще можно говорить в контексте джавы? Это то же самое что из экономии веса использовать алюминиевые гайки при сборке танков. Так же оправдано.
Здравствуйте, kuj, Вы писали:
H>>>>И какова, в таком случае, цена тезисам о том, что .Net от чего-то там оберегает, FxCop'ами ругется, все вусмерть контролит. И это еще противопоставлялось Delphi. Смех да и только.
kuj>>>Среда не убережет от алгоритмических ошибок, ясное дело. Что не так?
H>>Твои тезисы. Перечитай, переосмысли.
kuj>Какие еще мои тезисы? Давай уж конкретно с цитатами.
Да тебе бесполезно что-либо цитировать. Я тебя уже тыкал носом в твоиже слова, которые мне объяснить не смог (напоминаю, о минусах сборки мусора на управляемых типах в Delphi). Ссылку на описание фризов нашел, не поленился, от тебя снова тишина. Оно мне надо так напрягаться Проще с тобой завязать и только. Будь здоров.
, какого типа конфиги имеются ввиду.
kuj>>>По приведенной ссылке нет ничего про WindowsLive Writer. Заканчивай позориться, hattab.
H>>WLV упомянут, как имеющий конфиги в рабочей папке. Как и BDS2006, VisualStudio и многие другие. Т.ч. не надо песен об идеальном состоянии дел у .Net прилаг.
kuj>Ты действительно так туго думаешь, или только притворяешься? Я уже объяснял пошагово как работает стандартный конфигуратор из System.Configuration.
Да мне пофигу, как он работает. Я тебе примеры конкретных приложений провел. А ты мне все идеалистическую картину мира рисуешь...
, какого типа конфиги имеются ввиду.
kuj>>>По приведенной ссылке нет ничего про WindowsLive Writer. Заканчивай позориться, hattab.
H>>WLV упомянут, как имеющий конфиги в рабочей папке. Как и BDS2006, VisualStudio и многие другие. Т.ч. не надо песен об идеальном состоянии дел у .Net прилаг. G>А чем конфиги в рабочей папке не нравятся? G>Они как раз делалались чтобы приложение можно было обычным копированием перемещать на другой комп и не шаманить с реестром
Настроечные конфиги нравятся всем (и я об этом уже писал). Но конфиг, от правки/потери которого теряется функциональность приложения...
Здравствуйте, koandrew, Вы писали:
H>>Наглая ложь . Я сейчас поставил семерку под виртуалку и... Тот же самый IntfClear, в котором проверка разумеется присутствует.
K>А у меня вот другие данные. Приведите ассемблерный код, сгенерённый компилером для этого куска кода — вот тогда и посмотрим... У меня D7 к сожалению нет — ибо не надо оно мне сто лет уже.
Здравствуйте, hattab, Вы писали:
H>>>>>И какова, в таком случае, цена тезисам о том, что .Net от чего-то там оберегает, FxCop'ами ругется, все вусмерть контролит. И это еще противопоставлялось Delphi. Смех да и только.
kuj>>>>Среда не убережет от алгоритмических ошибок, ясное дело. Что не так?
H>>>Твои тезисы. Перечитай, переосмысли.
kuj>>Какие еще мои тезисы? Давай уж конкретно с цитатами.
H>Да тебе бесполезно что-либо цитировать. Я тебя уже тыкал носом в твоиже слова, которые мне объяснить не смог (напоминаю, о минусах сборки мусора на управляемых
типах в Delphi). Ссылку на описание фризов нашел, не поленился, от тебя снова тишина. Оно мне надо так напрягаться Проще с тобой завязать и только. Будь здоров.
Ну-ну. Научись читать сначала и в теме разберись хоть немного.
Во-первых, я никогда и нигде не говорил о минусах или плюсах "сборки мусора на управляемых типах в Delphi".
Во-вторых, я нигде и никогда не утверждал, что FxCop или .NET или Java или что-либо еще избавляют от алгоритмических ошибок. Так что не надо ля-ля.
В-третьих, про фризы я тебе уже русским языком объяснил.
Да, похоже ты таки прав. Посыпаю голову пеплом Но я точно помню, что в моём случае было по-другому. Ну да ладно — сейчас для меня это всё равно имеет чисто академический интерес. Но подобная неявная семантика ИМХО не нужна или должна быть хотя бы отключаема, ибо, если речь идёт о DX, там паттерн освобождения следующий:
#define SAFE_RELEASE(p) if(p) { p->Release(); p = NULL; }
Надо ли рассказывать, к чему приведёт прямое применение этого распиаренного на весь СДК способа (кстати этот макрос я взял из DX SDK, который, увы и ах, но только для C/C++) в дельфях?
В общем в сухом остатке мы имеем следующее:
С/С++: приходится внимательно следить за работой с памятью Delphi: приходится чуть менее внимательно следить за работой с памятью, но при этом следить за интеллектуальными изысками компилятора, дабы не поймать непонятных ошибок C#/Java:управление памятью нас не волнует (это забота RTL/VM) главное следить за алгоритмом
И ещё — личная просьба — если не трудно — скомпиль тот же код в варианте Release (я надеюсь то, что ты показал, это Debug? ибо в противном случае весь компилерско-оптимизаторский тим надо разгонять к известной матери) и покажи — мне просто любопытно. Заранее благодарю!
Здравствуйте, hattab, Вы писали:
kuj>>Ты действительно так туго думаешь, или только притворяешься? Я уже объяснял пошагово как работает стандартный конфигуратор из System.Configuration. H>Да мне пофигу, как он работает. Я тебе примеры конкретных приложений провел.
И что мне примеры твоих конкретных приложений, если ты и сам понятия не имеешь как они устроены? Ты смешон.
H>А ты мне все идеалистическую картину мира рисуешь...
Здравствуйте, misha_irpen, Вы писали:
ДГ>>Я даже больше скажу: в современной визуальной IDE под названием Eclipse формошлёпщик по умолчанию отсутствует. _>Угу, вот потому его и используют одни "энтузиасты" и нищие фирмы-однодневки. А в корпоративном секторе (где существует такое понятие как срок сдачи проекта) юзают VS, который формошлепщиком оборудован по-умолчанию.
Здравствуйте, misha_irpen, Вы писали: _>Угу, вот потому его и используют одни "энтузиасты" и нищие фирмы-однодневки. А в корпоративном секторе (где существует такое понятие как срок сдачи проекта) юзают VS, который формошлепщиком оборудован по-умолчанию.
_>О какой компактности вообще можно говорить в контексте джавы? Это то же самое что из экономии веса использовать алюминиевые гайки при сборке танков. Так же оправдано.
Здравствуйте, Mr.Cat, Вы писали:
_>>О какой компактности вообще можно говорить в контексте джавы? Это то же самое что из экономии веса использовать алюминиевые гайки при сборке танков. Так же оправдано. MC>Дровишки, как обычно, из леса?
Не понял вопроса. Поясню свою точку зрения: по сравнению с размером JRE такая экономия что мертвому припарка. По сравнению с ее требовательности к памяти -- тоже. Хорошо хоть производительность до ума довели, и то дотнет заставил.
Здравствуйте, kuj, Вы писали:
ДГ>>>Я даже больше скажу: в современной визуальной IDE под названием Eclipse формошлёпщик по умолчанию отсутствует. _>>Угу, вот потому его и используют одни "энтузиасты" и нищие фирмы-однодневки. А в корпоративном секторе (где существует такое понятие как срок сдачи проекта) юзают VS, который формошлепщиком оборудован по-умолчанию. kuj>Поржал. Пиши еще.
Если есть конкретные возражения -- в студию. Названия компаний, активно использующих этот ваш еклипс для чего-нибудь кроме джавы -- тоже.
Иначе слив засчитывается автоматически.
Здравствуйте, misha_irpen, Вы писали: _>Не понял вопроса. Поясню свою точку зрения: по сравнению с размером JRE такая экономия что мертвому припарка.
15 мб. Один раз поставить — и забыть (ну разве что обновлять изредка). Офигеть как много, да?
_>По сравнению с ее требовательности к памяти -- тоже.
Все же к памяти требовательна не сама java, а приложения, да? Вы свято верите, что любое java-приложение можно переписать на C++, например, и оно волшебным образом будет требовать существенно меньше памяти?
, какого типа конфиги имеются ввиду.
КБ>>Да вот только это единственный конфиг которые лежит в папке Windows Live Writer'a.
H>Так у него и других-то нет (списки поддерживаемых блог-апи не в счет, это таки данные)
— Ты этот конфиг имеешь ввиду
— Нет не этот
— А других нет
— Да других нет
Здравствуйте, misha_irpen, Вы писали:
ДГ>>И ставить его мне совершенно не интересно, потому как программируя Swing вручную, я получаю гораздо более компактный, структурированный и универсальный код. (По крайней мере, по сравнению с тем, что генерировал JBuilder Enterprise 2007, раза в три компактнее точно). _>О какой компактности вообще можно говорить в контексте джавы? Это то же самое что из экономии веса использовать алюминиевые гайки при сборке танков. Так же оправдано.
JRE сейчас занимет порядка 7Мб. В JDK7 будет занимать примерно 2Мб (!!). Это много?
По памяти JRE можно тоже достаточно сильно урезать.
Здравствуйте, kuj, Вы писали:
kuj>>>Какие еще мои тезисы? Давай уж конкретно с цитатами.
H>>Да тебе бесполезно что-либо цитировать. Я тебя уже тыкал носом в твоиже слова, которые мне объяснить не смог (напоминаю, о минусах сборки мусора на управляемых kuj>типах в Delphi). Ссылку на описание фризов нашел, не поленился, от тебя снова тишина. Оно мне надо так напрягаться Проще с тобой завязать и только. Будь здоров.
kuj>Ну-ну. Научись читать сначала и в теме разберись хоть немного.
Я с Паскалем 13 лет. Спасибо.
kuj>Во-первых, я никогда и нигде не говорил о минусах или плюсах "сборки мусора на управляемых типах в Delphi".
Я тебе уже показывал твои слова об этом. Больше прыгать не собираюь. Тебе нужно -- ищи.
kuj>Во-вторых, я нигде и никогда не утверждал, что FxCop или .NET или Java или что-либо еще избавляют от алгоритмических ошибок. Так что не надо ля-ля.
Я тебе говорил про потерю ресурсов на dbconnection. Ты мне сказал, что FxCop тебе все покажет. Ы?
kuj>В-третьих, про фризы я тебе уже русским языком объяснил.
Да-да. Ты сказал, что их не может быть (ты хоть по ссылке-то ходил?)
Здравствуйте, koandrew, Вы писали:
K>Да, похоже ты таки прав. Посыпаю голову пеплом Но я точно помню, что в моём случае было по-другому. Ну да ладно — сейчас для меня это всё равно имеет чисто академический интерес. Но подобная неявная семантика ИМХО не нужна или должна быть хотя бы отключаема, ибо, если речь идёт о DX, там паттерн освобождения следующий: K>
K>#define SAFE_RELEASE(p) if(p) { p->Release(); p = NULL; }
K>
K>Надо ли рассказывать, к чему приведёт прямое применение этого распиаренного на весь СДК способа (кстати этот макрос я взял из DX SDK, который, увы и ах, но только для C/C++) в дельфях?
Ни к чему страшному не приведет. Ну будут пустые вызовы IntfClear, и что? У меня в коде есть места, где требуется ручное управление количеством ссылок, но проблем от этого у меня нет. По поводу DX. Для существует куча DX-хидеров и даже какие-то наборы компонентов. Вообще, с хидерами особых проблем никогда не было (найти можно все).
K>В общем в сухом остатке мы имеем следующее:
K>С/С++: приходится внимательно следить за работой с памятью K>Delphi: приходится чуть менее внимательно следить за работой с памятью, но при этом следить за интеллектуальными изысками компилятора, дабы не поймать непонятных ошибок K>C#/Java:управление памятью нас не волнует (это забота RTL/VM) главное следить за алгоритмом
Я еще раз говорю, если ты работаешь с инструментом и не знаешь, как он работает -- ССЗБ. Обвинять компилятор в "интеллектуальных изысках", с твоей стороны, это расписываться в своей некомпетености. Не зная броду -- не лезь в воду.
K>И ещё — личная просьба — если не трудно — скомпиль тот же код в варианте Release (я надеюсь то, что ты показал, это Debug? ибо в противном случае весь компилерско-оптимизаторский тим надо разгонять к известной матери) и покажи — мне просто любопытно. Заранее благодарю!
Попытка по-громче хлопнуть дверью? Код не изменится, я это и без перекомпиляции знаю (но вообще в Delphi нет Debug/Release. под Release можно принимать компиляцию с отключенными проверками и debug info). Но это не проблема оптимизации. В реальном приложении, вполне, могут быть причины для такого кода (это не лучший способ, но тем не менее). Ручного управления подсчетом ссылок ни кто не запрещает.
Здравствуйте, kuj, Вы писали:
kuj>>>Ты действительно так туго думаешь, или только притворяешься? Я уже объяснял пошагово как работает стандартный конфигуратор из System.Configuration. H>>Да мне пофигу, как он работает. Я тебе примеры конкретных приложений провел.
kuj>И что мне примеры твоих конкретных приложений, если ты и сам понятия не имеешь как они устроены? Ты смешон.
Какое мне дело до их устройства? Ты мне сказал, где .Net прилаги хранят свои конфиги. Я тебе привел примеры, когда конфиги храняться не там, где ты указал. О чем ты тут споришь мне не понятно
, какого типа конфиги имеются ввиду.
КБ>>>Да вот только это единственный конфиг которые лежит в папке Windows Live Writer'a.
H>>Так у него и других-то нет (списки поддерживаемых блог-апи не в счет, это таки данные)
КБ>- Ты этот конфиг имеешь ввиду КБ>- Нет не этот КБ>- А других нет КБ>- Да других нет
Alt+F7 -- поиск в Far'е. Показал папки приложений имеющих в рабочих папках файлы конфигурации. Я привел пример WLV для господина kuj, в качестве опровержения его слов о том, что .Net приложения хранят свои конфиги в ...AppData... Так понятно? Да, конфиг WLV, это не тот о котором изначально была речь.
КБ>hattab, у вас с головой все в порядке?
Здравствуйте, hattab, Вы писали:
kuj>>Во-первых, я никогда и нигде не говорил о минусах или плюсах "сборки мусора на управляемых типах в Delphi".
H>Я тебе уже показывал твои слова об этом. Больше прыгать не собираюь. Тебе нужно -- ищи.
Я тебе цитату два раза приводил, даже жирным выделил, где русским по белому написано, что речь шла не о Делфи.
Ты у нас как в анекдоте про чукчу: чукча не читатель, чукча — писатель.
kuj>>Во-вторых, я нигде и никогда не утверждал, что FxCop или .NET или Java или что-либо еще избавляют от алгоритмических ошибок. Так что не надо ля-ля.
H>Я тебе говорил про потерю ресурсов на dbconnection. Ты мне сказал, что FxCop тебе все покажет. Ы?
Мда, ты хоть понимаешь значение понятия алгоритмическая ошибка? Походу нет... Вот что Delphi делает с мозгами...
kuj>>В-третьих, про фризы я тебе уже русским языком объяснил.
H>Да-да. Ты сказал, что их не может быть (ты хоть по ссылке-то ходил?)
Я тебе объяснил пошагово как они возникают. Свои проблемы со чтением решай сам.
H>Alt+F7 -- поиск в Far'е. Показал папки приложений имеющих в рабочих папках файлы конфигурации. Я привел пример WLV для господина kuj, в качестве опровержения его слов о том, что .Net приложения хранят свои конфиги в ...AppData... Так понятно? Да, конфиг WLV, это не тот о котором изначально была речь.
Я тебе уже объяснял где и как хранят свои конфиги .NET приложения. Привел даже ссылку на великолепную статью с codeproject, где все до мельчайших подробностей расписано. До тебя нереально туго, что поделаешь — Delphi отупляет.
Здравствуйте, hattab, Вы писали:
kuj>>>>Ты действительно так туго думаешь, или только притворяешься? Я уже объяснял пошагово как работает стандартный конфигуратор из System.Configuration. H>>>Да мне пофигу, как он работает. Я тебе примеры конкретных приложений провел.
kuj>>И что мне примеры твоих конкретных приложений, если ты и сам понятия не имеешь как они устроены? Ты смешон.
H>Какое мне дело до их устройства? Ты мне сказал, где .Net прилаги хранят свои конфиги. Я тебе привел примеры, когда конфиги храняться не там, где ты указал. О чем ты тут споришь мне не понятно
Самое смешное, что в твоем примере конфиги хранятся именно там, где я сказал.
Здравствуйте, hattab, Вы писали:
H>Я еще раз говорю, если ты работаешь с инструментом и не знаешь, как он работает -- ССЗБ. Обвинять компилятор в "интеллектуальных изысках", с твоей стороны, это расписываться в своей некомпетености. Не зная броду -- не лезь в воду.
Прежде, чем указывать на сучок в чужом глазу, разберись с бревном в своем. Компетентный ты наш...
Здравствуйте, misha_irpen, Вы писали:
ДГ>>>>Я даже больше скажу: в современной визуальной IDE под названием Eclipse формошлёпщик по умолчанию отсутствует. _>>>Угу, вот потому его и используют одни "энтузиасты" и нищие фирмы-однодневки. А в корпоративном секторе (где существует такое понятие как срок сдачи проекта) юзают VS, который формошлепщиком оборудован по-умолчанию. kuj>>Поржал. Пиши еще. _>Если есть конкретные возражения -- в студию. Названия компаний, активно использующих этот ваш еклипс для чего-нибудь кроме джавы -- тоже. _>Иначе слив засчитывается автоматически.
Да ради бога считай что хочешь. Вы тут с hattab два сапога пара — подменяете Шеридана, пока он в "отпуске". Вот и говорю — пиши ище!
Здравствуйте, hattab, Вы писали:
C>>JRE сейчас занимет порядка 7Мб. В JDK7 будет занимать примерно 2Мб (!!). Это много?
H>У меня на буке j2re1.4.2_05 -- 42Мб.
Последний java runtime 6 update 5 — 7 MB дистрибутив.
Здравствуйте, Niemand, Вы писали:
N>4. "Закон один для всех". В делфи часто встречаются исключения. Например writeln — чуть ли не единственная функция, куда можно передать переменное к-во параметров. А вот простым смертным — низза. Похожая ситуация с массивами.
Занудствую . writeln — не ф-я, а оператор языка с переменным числом операндов (по кр. мере в "чистом" Паскале). Ну и разбирается там все на этапе компиляции, а не в ран-тайме.
Здравствуйте, kuj, Вы писали:
kuj>>>Во-первых, я никогда и нигде не говорил о минусах или плюсах "сборки мусора на управляемых типах в Delphi".
H>>Я тебе уже показывал твои слова об этом. Больше прыгать не собираюь. Тебе нужно -- ищи.
kuj>Я тебе цитату два раза приводил, даже жирным выделил, где русским по белому написано, что речь шла не о Делфи. kuj>Ты у нас как в анекдоте про чукчу: чукча не читатель, чукча — писатель.
Ты мне привел более поздний пост, с моими же вопросами относительно "о Delphi'ли действительно идет речь?". Вижу, ты окончательно линию потерял.
kuj>>>Во-вторых, я нигде и никогда не утверждал, что FxCop или .NET или Java или что-либо еще избавляют от алгоритмических ошибок. Так что не надо ля-ля.
H>>Я тебе говорил про потерю ресурсов на dbconnection. Ты мне сказал, что FxCop тебе все покажет. Ы?
kuj>Мда, ты хоть понимаешь значение понятия алгоритмическая ошибка? Походу нет... Вот что Delphi делает с мозгами...
Использование using это что? Не алгоритмическое требование подтираться при необходимости?
kuj>>>В-третьих, про фризы я тебе уже русским языком объяснил.
H>>Да-да. Ты сказал, что их не может быть (ты хоть по ссылке-то ходил?)
kuj>Я тебе объяснил пошагово как они возникают. Свои проблемы со чтением решай сам.
Вижу, что не ходил. Там фризы возникают не в гуевом приложении, а вин-сервисе. Чтун, блин.
Здравствуйте, kuj, Вы писали:
H>>Alt+F7 -- поиск в Far'е. Показал папки приложений имеющих в рабочих папках файлы конфигурации. Я привел пример WLV для господина kuj, в качестве опровержения его слов о том, что .Net приложения хранят свои конфиги в ...AppData... Так понятно? Да, конфиг WLV, это не тот о котором изначально была речь.
kuj>Я тебе уже объяснял где и как хранят свои конфиги .NET приложения. Привел даже ссылку на великолепную статью с codeproject, где все до мельчайших подробностей расписано. До тебя нереально туго, что поделаешь — Delphi отупляет.
Я уже десять раз написал, что речь не идет о конфигах в которых храняться измененные настройки приложения. Или у тебя ассоциативная связь только на это установлена. Сорри, это проблемы не мои.
Здравствуйте, kuj, Вы писали:
H>>Я еще раз говорю, если ты работаешь с инструментом и не знаешь, как он работает -- ССЗБ. Обвинять компилятор в "интеллектуальных изысках", с твоей стороны, это расписываться в своей некомпетености. Не зная броду -- не лезь в воду.
kuj>Прежде, чем указывать на сучок в чужом глазу, разберись с бревном в своем. Компетентный ты наш...
Пока свою некомпетентность тут демонстрируют товарищи нападающие на Delphi. А с тобой я больше поддерживать диалог не буду. Бывай.
Здравствуйте, goto, Вы писали:
N>>4. "Закон один для всех". В делфи часто встречаются исключения. Например writeln — чуть ли не единственная функция, куда можно передать переменное к-во параметров. А вот простым смертным — низза. Похожая ситуация с массивами.
G>Занудствую . writeln — не ф-я, а оператор языка с переменным числом операндов (по кр. мере в "чистом" Паскале). Ну и разбирается там все на этапе компиляции, а не в ран-тайме.
Чисто ремарка: Для переменного числа параметров есть константные массивы.
Procedure SomeProc(Const Array Of const);
Begin
End;
...
SomeProc([1]);
SomeProc([1, '1024']);
SomeProc([1, '1024', Now]);
SomeProc([1, '1024', Now, TStringList]);
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, misha_irpen, Вы писали: _>>Не понял вопроса. Поясню свою точку зрения: по сравнению с размером JRE такая экономия что мертвому припарка. MC>15 мб. Один раз поставить — и забыть (ну разве что обновлять изредка). Офигеть как много, да?
Это не мало. У меня на машине JRE нет, захочу такую программу -- буду качать все.
_>>По сравнению с ее требовательности к памяти -- тоже. MC>Все же к памяти требовательна не сама java, а приложения, да?
Ну когда примитивный конфигуратор, вся работа которого ini-файл записать, начинает тридцать метров жрать, то значит что-то неладное в самой среде. Я понимаю что тридцать метров сегодня не объем, но елки-палки, сколько можно пускать деньги пользователей в трубу? Производители новые техпроцессы осваивают не для того чтобы очередная джава с вистой их сожрала подчистую и все осталось точно так же как и было!
Здравствуйте, kuj, Вы писали:
kuj>Да ради бога считай что хочешь. Вы тут с hattab два сапога пара — подменяете Шеридана, пока он в "отпуске". Вот и говорю — пиши ище!
Ага, ваш психотип понятен. "Все кто думают не так как я -- козлы и Шериданы". Все с вами ясно.
Здравствуйте, hattab, Вы писали:
kuj>>>>Во-первых, я никогда и нигде не говорил о минусах или плюсах "сборки мусора на управляемых типах в Delphi".
H>>>Я тебе уже показывал твои слова об этом. Больше прыгать не собираюь. Тебе нужно -- ищи.
kuj>>Я тебе цитату два раза приводил, даже жирным выделил, где русским по белому написано, что речь шла не о Делфи. kuj>>Ты у нас как в анекдоте про чукчу: чукча не читатель, чукча — писатель.
H>Ты мне привел более поздний пост, с моими же вопросами относительно "о Delphi'ли действительно идет речь?". Вижу, ты окончательно линию потерял.
И до тебя все еще не дошло, что моя фраза не относилась ни коим боком к Делфи? Кто из нас линию потерял?
kuj>>>>Во-вторых, я нигде и никогда не утверждал, что FxCop или .NET или Java или что-либо еще избавляют от алгоритмических ошибок. Так что не надо ля-ля.
H>>>Я тебе говорил про потерю ресурсов на dbconnection. Ты мне сказал, что FxCop тебе все покажет. Ы?
kuj>>Мда, ты хоть понимаешь значение понятия алгоритмическая ошибка? Походу нет... Вот что Delphi делает с мозгами...
H>Использование using это что? Не алгоритмическое требование подтираться при необходимости?
Ты издеваешься или действительно так туп?
kuj>>>>В-третьих, про фризы я тебе уже русским языком объяснил.
H>>>Да-да. Ты сказал, что их не может быть (ты хоть по ссылке-то ходил?)
kuj>>Я тебе объяснил пошагово как они возникают. Свои проблемы со чтением решай сам.
H>Вижу, что не ходил. Там фризы возникают не в гуевом приложении, а вин-сервисе. Чтун, блин.
Дилетантство на лицо. Мое объяснение относится в равной степень к гуи и не гуи. Учи матчасть.
Здравствуйте, hattab, Вы писали:
H>>>Alt+F7 -- поиск в Far'е. Показал папки приложений имеющих в рабочих папках файлы конфигурации. Я привел пример WLV для господина kuj, в качестве опровержения его слов о том, что .Net приложения хранят свои конфиги в ...AppData... Так понятно? Да, конфиг WLV, это не тот о котором изначально была речь.
kuj>>Я тебе уже объяснял где и как хранят свои конфиги .NET приложения. Привел даже ссылку на великолепную статью с codeproject, где все до мельчайших подробностей расписано. До тебя нереально туго, что поделаешь — Delphi отупляет.
H>Я уже десять раз написал, что речь не идет о конфигах в которых храняться измененные настройки приложения. Или у тебя ассоциативная связь только на это установлена. Сорри, это проблемы не мои.
Если тебе голову отрезать "случайно" будешь ли ты продолжать писать сюда? Хм... стоп. Пожалуй, таки будешь.
Здравствуйте, misha_irpen, Вы писали:
MC>>Здравствуйте, misha_irpen, Вы писали: _>>>Не понял вопроса. Поясню свою точку зрения: по сравнению с размером JRE такая экономия что мертвому припарка. MC>>15 мб. Один раз поставить — и забыть (ну разве что обновлять изредка). Офигеть как много, да? _>Это не мало. У меня на машине JRE нет, захочу такую программу -- буду качать все.
Инет отвалится скачать раз 7 мб JRE? Ответ на вопрос в теме — атрофирует мозги оно... вусмерть.
_>>>По сравнению с ее требовательности к памяти -- тоже. MC>>Все же к памяти требовательна не сама java, а приложения, да? _>Ну когда примитивный конфигуратор, вся работа которого ini-файл записать, начинает тридцать метров жрать, то значит что-то неладное в самой среде. Я понимаю что тридцать метров сегодня не объем, но елки-палки, сколько можно пускать деньги пользователей в трубу? Производители новые техпроцессы осваивают не для того чтобы очередная джава с вистой их сожрала подчистую и все осталось точно так же как и было!
Java уже лет много-много лет используется и очень эффективно. Производительность и ресурсы железа с тех пор выросли многократно. Производительность JRE тоже заметно увеличилась (за счет различных оптимизаций).
Ликбез основное применение Java имеет для построения различных Enterprise-level систем.
Здравствуйте, goto, Вы писали:
G>Здравствуйте, Niemand, Вы писали:
N>>4. "Закон один для всех". В делфи часто встречаются исключения. Например writeln — чуть ли не единственная функция, куда можно передать переменное к-во параметров. А вот простым смертным — низза. Похожая ситуация с массивами.
G>Занудствую . writeln — не ф-я, а оператор языка с переменным числом операндов (по кр. мере в "чистом" Паскале). Ну и разбирается там все на этапе компиляции, а не в ран-тайме.
Продолжим занудствовать. Как с помощью этого оператора языка (очень похожего на функцию ) можно единообразно вывести в файл, в память, в отладочный вывод, в консоль, в сокет, в что-то только что придуманное? В С++ это можно сделать, что дописывая варианты printf, что наследуя ostream. Все операции будут единоообразны. Да 1 и та же функция это может делать.
_>>Я так понимаю по-вашему в современных визуальных IDE иначе как формы клипать ничего не получится? _>Я этого не говорил. Не нужно передергивать.
"Скажу так: чем все современные визуальные IDE не формошлепство?"
Где передергивание?
_>>И веб-сервисы, и win-сервисы, и консольные приложения не написать? _>Все это можно и на Delphi писать. Разве что для веба он не предназначен, но даже веб писать таки можно. _>Чего сказать-то хотели?
"Скажу так: чем все современные визуальные IDE не формошлепство?"
Отвечал на ваш вопрос, если не понятно. Кроме формошлепства кое-что еще имеется.
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, hattab, Вы писали:
H>Ни к чему страшному не приведет. Ну будут пустые вызовы IntfClear, и что?
Да что вы говорите? А подумать прежде, чем отвечать, не судьба? Ок, объясняю — произойдёт два вызова Release() — один из них явно, а второй неявно компилятором. И если после явного вызова Release() счётчик ссылок будет равным нулю, то объект себя удаляет из памяти, и второй вызов приведёт к Access Violation.
H>Я еще раз говорю, если ты работаешь с инструментом и не знаешь, как он работает -- ССЗБ. Обвинять компилятор в "интеллектуальных изысках", с твоей стороны, это расписываться в своей некомпетености. Не зная броду -- не лезь в воду.
Отключать их надо нах! Вот смотри сам — ты вроде бы знаешь об этих "изысках", тем не менее просмотрел Access Violation. Ну и кто тут после этого ССЗБ?
H>Попытка по-громче хлопнуть дверью? Код не изменится, я это и без перекомпиляции знаю (но вообще в Delphi нет Debug/Release. под Release можно принимать компиляцию с отключенными проверками и debug info). Но это не проблема оптимизации. В реальном приложении, вполне, могут быть причины для такого кода (это не лучший способ, но тем не менее). Ручного управления подсчетом ссылок ни кто не запрещает.
Не ищите подвохов там, где их нет Просто эта функция — первый кандидат на инлайнинг, и если компилер не может производить такие простейшие оптимизации — ф топку такой компилер. Вместо этих неявных извратов лучше уж оптимизатор бы нормальный сделали — толку явно больше было бы, а глюков меньше...
А по поводу ручного подсчёта ссылок — ну опять потенциальный багодром по причинам, которые я описал выше...
Моя плакать "Const Array Of const" — убей себя об стену кто такое придумал.
А ведь паскаль создавался как язык для обучения с практически очевидной семантикой.
Здравствуйте, hattab, Вы писали:
H>Я еще раз говорю, если ты работаешь с инструментом и не знаешь, как он работает -- ССЗБ. Обвинять компилятор в "интеллектуальных изысках", с твоей стороны, это расписываться в своей некомпетености. Не зная броду -- не лезь в воду.
Еще раз тебе говорю: люди реально работают с реальным инструментом (ASP.NET), далеко не все знают как работает каждая строчка написанного кода, там не менее ошибок соврешают гораздо меньше, чем эексперты, программирующие в делфи.
Здравствуйте, misha_irpen, Вы писали:
MC>>15 мб. Один раз поставить — и забыть (ну разве что обновлять изредка). Офигеть как много, да? _>Это не мало. У меня на машине JRE нет, захочу такую программу -- буду качать все.
Вы и ОС небось не обновляете? Сам долго на диалапе сидел — но даже 20-30мб проблемой никогда не были.
_>Ну когда примитивный конфигуратор, вся работа которого ini-файл записать, начинает тридцать метров жрать, то значит что-то неладное в самой среде. ... Производители новые техпроцессы осваивают не для того чтобы очередная джава с ... сожрала подчистую и все осталось точно так же как и было!
Это очень распространенный и необдуманный аргумент — когда берут в качестве примера какое-то совсем простое приложение на java (да и на любой управляемой платформе) — дай Бог, не "hello world" — и начинают распинаться, как же много простейшее приложение жрет памяти, как (в сравнении с аналогом на C, например) долго грузится и тэ дэ и тэ пэ. Надо ведь понимать, кое-какие вещи:
1)Ресурсоемкость java-приложений не растет прямо пропорционально их "сложности". Т.е. ясное дело, что у "hello world" (или конфигуратора вашего) большая часть съедаемой памяти — память, съедаемая самой jre. Однако для более сложных приложений все будет совсем не так.
2)Ресурсоемкость нескольких java-приложений не растет прямо пропорционально количеству этих приложений. Где-то мелькало на форуме — т.к в этом случае не бдет нескольких копий jre в памяти.
3)Важно знать, какой процент из этих 30мб входит в "рабочее множество", а какой просто загружен про запас, валяется в свопе и никому не мешает. Лично у меня такой информации нет, но я больше чем уверен, что большая часть этих 30мб — именно про запас загружается.
Здравствуйте, Mr.Cat, Вы писали:
MC>>>15 мб. Один раз поставить — и забыть (ну разве что обновлять изредка). Офигеть как много, да? _>>Это не мало. У меня на машине JRE нет, захочу такую программу -- буду качать все. MC>Вы и ОС небось не обновляете? Сам долго на диалапе сидел — но даже 20-30мб проблемой никогда не были.
Я сейчас сижу на выделенке 128k с безлимитным трафиком. Но как программист я думаю о пользователях, которые и на модемах сидят и через CDMA с GPRS-ом ходят, платя ощутимые деньги за каждый скачанный мегабайт.
Некоторым кажется что проблем с интернетом уже ни укого нет (особенно это сквозит во всем, что написанно столичными жителями), однако это не так. Реальность очень большого количества пользователей -- это модем на гнилой телефонной линии с повременнной оплатой или 10-20 центов за мегабайт при подключении локалкой или по воздуху.
_>>Ну когда примитивный конфигуратор, вся работа которого ini-файл записать, начинает тридцать метров жрать, то значит что-то неладное в самой среде. ... Производители новые техпроцессы осваивают не для того чтобы очередная джава с ... сожрала подчистую и все осталось точно так же как и было! MC>Это очень распространенный и необдуманный аргумент — когда берут в качестве примера какое-то совсем простое приложение на java (да и на любой управляемой платформе) — дай Бог, не "hello world" — и начинают распинаться, как же много простейшее приложение жрет памяти, как (в сравнении с аналогом на C, например) долго грузится и тэ дэ и тэ пэ. Надо ведь понимать, кое-какие вещи: MC>1)Ресурсоемкость java-приложений не растет прямо пропорционально их "сложности". Т.е. ясное дело, что у "hello world" (или конфигуратора вашего) большая часть съедаемой памяти — память, съедаемая самой jre. Однако для более сложных приложений все будет совсем не так.
Не спорю. Но нижняя планка слишком высокая.
MC>2)Ресурсоемкость нескольких java-приложений не растет прямо пропорционально количеству этих приложений. Где-то мелькало на форуме — т.к в этом случае не бдет нескольких копий jre в памяти.
Это стандартная фича винды. Сегменты кода используются процессами совместно, однако данные либо copy-on-write, либо вообще отдельные. А т.к. большая часть виртуальной машины ИМХО данные (байт-код всяких библиотек и т.п., что с точки зрения процессора кодом не является), то каждая следующая копия отжирает пусть не 30, но 20-25 метров -- запросто (это то что сам видел). Конечно со стороны саой виртуальной машины тоже могут быть предприняты меры по совместному использованию всего что можно, может уже так и есть, но еще пару лет назад было так, как я написал выше.
MC>3)Важно знать, какой процент из этих 30мб входит в "рабочее множество", а какой просто загружен про запас, валяется в свопе и никому не мешает. Лично у меня такой информации нет, но я больше чем уверен, что большая часть этих 30мб — именно про запас загружается.
Может быть, но своп тоже не резиновый ведь. Хотя согласен, это не настолько критично.
Здравствуйте, vitaly_spb, Вы писали:
_>Отвечал на ваш вопрос, если не понятно. Кроме формошлепства кое-что еще имеется.
В Delphi тоже много чего имеется. И кроме формошлепства он позволяет писать и консольные приложения (по вашему посту у меня возникло очень стойкое ощущение что вы этого просто не знали) и сервисы (аналогично). Что касается горячелюбимого веба, то не нужно его сюда приплетать, ибо на джаве в отличие од делфей, win-сервис, например, тоже не напишешь.
Здравствуйте, misha_irpen, Вы писали:
_>Я сейчас сижу на выделенке 128k с безлимитным трафиком. Но как программист я думаю о пользователях, которые и на модемах сидят и через CDMA с GPRS-ом ходят, платя ощутимые деньги за каждый скачанный мегабайт.
Сколько из них качает из интернета программы, требующие jre?
Если программа распространяется на диске, то зачем что-то качать?
Здравствуйте, misha_irpen, Вы писали:
_>Я сейчас сижу на выделенке 128k с безлимитным трафиком. Но как программист я думаю о пользователях, которые и на модемах сидят и через CDMA с GPRS-ом ходят, платя ощутимые деньги за каждый скачанный мегабайт. _>Некоторым кажется что проблем с интернетом уже ни укого нет (особенно это сквозит во всем, что написанно столичными жителями), однако это не так. Реальность очень большого количества пользователей -- это модем на гнилой телефонной линии с повременнной оплатой или 10-20 центов за мегабайт при подключении локалкой или по воздуху.
О таких пользователях лучше "думать" по-другому: например, предлагать сервис доставки ПО на диске по почте. У меня вообще складывается картина, что не так уж плохо с инетом в России на самом деле. Из общения с иногородними знакомыми/френдами по MMOG/etc. вроде как получается, что кому нужен нормальный инет, тот найдет для себя приемлемый вариант, а кто сидит на гнилом диалапе и жалуется на жизнь, тот ССЗБ. Впрочем все это только ИМХИ, так что просьба особо не пинать и в профиль не заглядывать.
_>Не спорю. Но нижняя планка слишком высокая.
А по мне — не слишком. Впрочем, тут как с фломастерами.
MC>>2)Ресурсоемкость нескольких java-приложений не растет прямо пропорционально количеству этих приложений. Где-то мелькало на форуме — т.к в этом случае не бдет нескольких копий jre в памяти. _>Это стандартная фича винды. Сегменты кода используются процессами совместно, однако данные либо copy-on-write, либо вообще отдельные. А т.к. большая часть виртуальной машины ИМХО данные (байт-код всяких библиотек и т.п., что с точки зрения процессора кодом не является), то каждая следующая копия отжирает пусть не 30, но 20-25 метров -- запросто (это то что сам видел). Конечно со стороны саой виртуальной машины тоже могут быть предприняты меры по совместному использованию всего что можно, может уже так и есть, но еще пару лет назад было так, как я написал выше.
Не только винды, а любой нормальной ОС. Лично я больше, чем уверен (на проверку сейчас свободного времени нет, хотя по-хорошему надо проверить), что шарится все, что только можно (в т.ч. байт-коды библиотек, которые ведь не меняются в ходе выполнения). Не совсем понятно, при чем тут точка зрения процессора, т.к. разделяемые страницы это механизм ОС, а не процессора. А ОС по барабану, что в зашаренных страницах находится. Также не совсем понятно, что именно Вы видели. Насколько я знаю, стандартные виндовые средства не позволяют определить, какую часть виртуального АП составляют разделяемые сраницы, а какую — "приватные". Так что понять, что копируется просто так не получится.
Здравствуйте, koandrew, Вы писали:
H>>Ни к чему страшному не приведет. Ну будут пустые вызовы IntfClear, и что?
K> Да что вы говорите? А подумать прежде, чем отвечать, не судьба? Ок, объясняю — произойдёт два вызова Release() — один из них явно, а второй неявно компилятором. И если после явного вызова Release() счётчик ссылок будет равным нулю, то объект себя удаляет из памяти, и второй вызов приведёт к Access Violation.
Ты фантазер. Однозначно. Ссылки разумеется будут декрементиться на каждый вызов и Release и IntfClear (что в результате приведет к преждевременной кончине объекта). Но ни каких Access Violation не будет (ты же перед Release проверяешь переменную). Проверь, если не веришь.
H>>Я еще раз говорю, если ты работаешь с инструментом и не знаешь, как он работает -- ССЗБ. Обвинять компилятор в "интеллектуальных изысках", с твоей стороны, это расписываться в своей некомпетености. Не зная броду -- не лезь в воду.
K>Отключать их надо нах! Вот смотри сам — ты вроде бы знаешь об этих "изысках", тем не менее просмотрел Access Violation. Ну и кто тут после этого ССЗБ?
Про Access Violation уже ответил -- его там не будет. А твоя позиция меня просто изумляет: пришел в чужой монастырь со своим уставом, и ну права качать. Право, странные замашки...
H>>Попытка по-громче хлопнуть дверью? Код не изменится, я это и без перекомпиляции знаю (но вообще в Delphi нет Debug/Release. под Release можно принимать компиляцию с отключенными проверками и debug info). Но это не проблема оптимизации. В реальном приложении, вполне, могут быть причины для такого кода (это не лучший способ, но тем не менее). Ручного управления подсчетом ссылок ни кто не запрещает.
K>Не ищите подвохов там, где их нет Просто эта функция — первый кандидат на инлайнинг, и если компилер не может производить такие простейшие оптимизации — ф топку такой компилер. Вместо этих неявных извратов лучше уж оптимизатор бы нормальный сделали — толку явно больше было бы, а глюков меньше... K>А по поводу ручного подсчёта ссылок — ну опять потенциальный багодром по причинам, которые я описал выше...
Инлайнинг IntfClear -- это раздувание кода, причем абсолютно неоправданное.
G>Моя плакать "Const Array Of const" — убей себя об стену кто такое придумал. G>А ведь паскаль создавался как язык для обучения с практически очевидной семантикой.
Мой косяк
Procedure SomeProc(Const AParams : Array Of Const);
Здравствуйте, gandjustas, Вы писали:
H>>Я еще раз говорю, если ты работаешь с инструментом и не знаешь, как он работает -- ССЗБ. Обвинять компилятор в "интеллектуальных изысках", с твоей стороны, это расписываться в своей некомпетености. Не зная броду -- не лезь в воду. G>Еще раз тебе говорю: люди реально работают с реальным инструментом (ASP.NET), далеко не все знают как работает каждая строчка написанного кода, там не менее ошибок соврешают гораздо меньше, чем эексперты, программирующие в делфи.
Статистику в студию. Иначе, как я уже говорил, это все бла-бла-бла.
Здравствуйте, hattab, Вы писали:
kuj>>Ты не описывал реальную ситуацию а сослался на какие-то там форумы, где кто-кто кому-то когда-то рекомендовал "понатыкать GC.Collect". H>Здесь
Какоето гадание на кофейной гуще.
Что там у него подвисает ХЗ.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, koandrew, Вы писали:
K> Да что вы говорите? А подумать прежде, чем отвечать, не судьба? Ок, объясняю — произойдёт два вызова Release() — один из них явно, а второй неявно компилятором. И если после явного вызова Release() счётчик ссылок будет равным нулю, то объект себя удаляет из памяти, и второй вызов приведёт к Access Violation.
Таки да, будет проблема в этом случае. Проморгал, трудный день Однако это не дает тебе права наезжать на компилер по причине того, что Сишный подход не подходит в Delphi. Да, не подходит.
Здравствуйте, WolfHound, Вы писали:
kuj>>>Ты не описывал реальную ситуацию а сослался на какие-то там форумы, где кто-кто кому-то когда-то рекомендовал "понатыкать GC.Collect". H>>Здесь WH>Какоето гадание на кофейной гуще. WH>Что там у него подвисает ХЗ.
Насколько я помню, с этим ХЗ так и не разобрались.
Здравствуйте, hattab, Вы писали:
H>Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом.
Скажу как разработчик на всем что компилируется или хотябы интерпритируется.
Я ловил фризы нативного в доску ядра линукса.
При определенных сценариях нагрузки воспроизводилось в 100% случаях.
Так что существует огромное колличество причин по которым могут происходить фризы.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, hattab, Вы писали:
H>Насколько я помню, с этим ХЗ так и не разобрались.
Следовательно делать однозначный вывод о том что подвисает именно ГЦ нельзя.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Я еще раз говорю, если ты работаешь с инструментом и не знаешь, как он работает -- ССЗБ. Обвинять компилятор в "интеллектуальных изысках", с твоей стороны, это расписываться в своей некомпетености. Не зная броду -- не лезь в воду. G>>Еще раз тебе говорю: люди реально работают с реальным инструментом (ASP.NET), далеко не все знают как работает каждая строчка написанного кода, там не менее ошибок соврешают гораздо меньше, чем эексперты, программирующие в делфи.
H>Статистику в студию. Иначе, как я уже говорил, это все бла-бла-бла.
Еще раз говорю: эту ситацию вижу своими глазами.
Лучше факты приведу, почему на .NET писать проще.
1)Нет утечек памяти.
2)Нет таких проблем с COM, как описано выше.
3)Нет проблем с организацией сетевого взаимодействия — не надо изучать "тяжелые" технологии типа DCOM, CORBA и др.
4)В .NET 3.5 практически не требуется писать DAL: типизированные запросы, проверяемые при компиляции; не надо писать SQL в программе; практически отсутсвие SQL-Injection уязвимостей
5)В .NET 3.5 очень лекая работа с XML (твой метод XmlUnescapeString даже писать не надо).
То есть для выполнения тоже задачи что на делфи программисту на C# тебуется гораздо меньше специфических знаний и меньше времени на отладку.
Здравствуйте, kuj, Вы писали:
kuj>Э-э, батенька, ты явно путаешься в понятиях. kuj>Во-первых, делегаты прекрасно реализуются в C++ в виде указателей на функцию.
Есть куда болие удобная boost::function.
kuj>Благодаря DI мой ClassA зависит только от IInterfaceB, который реализуется классами ClassB1, ClassB2 и ClassB3. В любой момент времени я могу открыть конфигурацию IoC и сменить байндинг с ClassB1, например, на ClassB2, совсем не затрагивая при этом ClassA. Да, в Delphi и C++ для этого используется паттерн фабрика, НО появляется зависимость ClassA, от фабрики! Вот такие пироги с капустой...
IoC контейнер что не фабрика?
kuj>В .Net от множественного наследования сразу отказались.
По хорошему вобще нужно было отказаться от наследование реализаций.
Интерфейсы + миксины (чтобы код реюзать) и все типы финализированные.
Ибо нефиг разводить связанность на ровном месте.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, DOOM, Вы писали:
DOO>>>Шаблон — это скорее развитый препроцессор. Препроцессор отношения к языку не имеет (что мне мешает взять и мои исходники на дельфях обработать препроцессором того же gcc?). kuj>>Ой ли? DOO>А что нет что ли? Ноги-то откуда растут? Понятно, что со временем это обрастало фичами, появилась обратная связь с компилятором и т.п. Но идея абсолютно "макросной" природы — готов поспорить, что изначально это и реализовывалось исключительно препроцессором.
Шаблоны в С++ настолько глубоко провязанны в систему типов что реализовать их препроцессором задачка не решаемая.
Вобще говоря С++ имеет очень мощьную систему типов.
Одно то что она теоритически полна по Тьрингу уже говонрит о многом.
На практике компиляторы очень сильно ограничивают глубину рекурсии да и медленный интерпритатор из компилятора С++ получается так что сильно не разойдешься.
Но даже на том что есть можно творить очень веселые и иногда даже практичные вещи.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, koandrew, Вы писали:
K>> Да что вы говорите? А подумать прежде, чем отвечать, не судьба? Ок, объясняю — произойдёт два вызова Release() — один из них явно, а второй неявно компилятором. И если после явного вызова Release() счётчик ссылок будет равным нулю, то объект себя удаляет из памяти, и второй вызов приведёт к Access Violation.
H>Таки да, будет проблема в этом случае. Проморгал, трудный день Однако это не дает тебе права наезжать на компилер по причине того, что Сишный подход не подходит в Delphi. Да, не подходит.
То есть пришли к выводу что интерфейсы кроме чем для COM использовать не стоит. Посмотри с чего обсуждение началалось.
Здравствуйте, gandjustas, Вы писали:
I>>По своему опыту скажу, что низкокачественного кода было написано дохрена и больше, чем высококачественного, не зависимо от платформы. G>Во всех программах на делфи, которые я видел, были утечки памяти. Для Java и .NET такого быть не может
Может.
Другое дело что сотворить утечку сложнее, а найти и исправить легче.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, hattab, Вы писали:
H>>Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом. WH>Скажу как разработчик на всем что компилируется или хотябы интерпритируется. WH>Я ловил фризы нативного в доску ядра линукса. WH>При определенных сценариях нагрузки воспроизводилось в 100% случаях.
Тут есть детерминированность в отличие от того случая.
WH>Так что существует огромное колличество причин по которым могут происходить фризы.
Здравствуйте, WolfHound, Вы писали:
G>>Во всех программах на делфи, которые я видел, были утечки памяти. Для Java и .NET такого быть не может WH>Может.
Здравствуйте, WolfHound, Вы писали:
H>>Насколько я помню, с этим ХЗ так и не разобрались. WH>Следовательно делать однозначный вывод о том что подвисает именно ГЦ нельзя.
100% конечно нельзя. Но уж очень на сборку смахивает, или что-то другое внутри FW
Здравствуйте, hattab, Вы писали:
H>Тут есть детерминированность в отличие от того случая.
Если за раскопки того случая посадить меня то с ооочень большой вероятностью детерминированость очень быстро найдется.
Причем скорей всего просто после чтения кода.
WH>>Так что существует огромное колличество причин по которым могут происходить фризы. H>С этим никто и не спорит.
Проблема в том что ты нашол какоето упоминание на какомто форуме о непонятно каком фризе и тупо экстраполируешь это упоминание на ГЦ.
К слову есть алгоритмы сборки мусора дающие гарантии реального времени.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, hattab, Вы писали:
H>100% конечно нельзя. Но уж очень на сборку смахивает, или что-то другое внутри FW
На сборку это какраз таки очень мало смахивает.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandjustas, Вы писали:
G>>>Во всех программах на делфи, которые я видел, были утечки памяти. Для Java и .NET такого быть не может WH>>Может. G>Каким образом? Через таймеры чтоли?
Например подписаться на событие долгоживущего объекта.
В Янусе одно время такой таракан жил.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandjustas, Вы писали:
H>>>>Я еще раз говорю, если ты работаешь с инструментом и не знаешь, как он работает -- ССЗБ. Обвинять компилятор в "интеллектуальных изысках", с твоей стороны, это расписываться в своей некомпетености. Не зная броду -- не лезь в воду. G>>>Еще раз тебе говорю: люди реально работают с реальным инструментом (ASP.NET), далеко не все знают как работает каждая строчка написанного кода, там не менее ошибок соврешают гораздо меньше, чем эексперты, программирующие в делфи.
H>>Статистику в студию. Иначе, как я уже говорил, это все бла-бла-бла.
G>Еще раз говорю: эту ситацию вижу своими глазами.
G>Лучше факты приведу, почему на .NET писать проще. G>1)Нет утечек памяти.
В D2006 об утечках становится известно сразу после завершения приложения. Но среда нативная, утечки могут быть, бесспорно.
G>2)Нет таких проблем с COM, как описано выше.
В Delphi их тоже нет. То что обсуждалось с DX, это ни какая не проблема. Это нарушений правил языка.
G>3)Нет проблем с организацией сетевого взаимодействия — не надо изучать "тяжелые" технологии типа DCOM, CORBA и др.
В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS.
G>4)В .NET 3.5 практически не требуется писать DAL: типизированные запросы, проверяемые при компиляции; не надо писать SQL в программе; практически отсутсвие SQL-Injection уязвимостей
Не SQL'ем единым, как говорится. Применение Delphi не ограничивается мордами к БД.
G>5)В .NET 3.5 очень лекая работа с XML (твой метод XmlUnescapeString даже писать не надо).
Ты знаешь, я для своей задачи выбирал SAX парсер. Перепробовал более 10 штук. Это ли не богатство выбора? Что касается моей функции, повторяю: она написана с целью сократить расход памяти при модификации строк (в Delphi для Ansi-строк работает правило Copy-On-Write) для чего используется побочный эффект при работе с указателями (т.е. я не позволяю Delphi отследить модификацию строки).
G>То есть для выполнения тоже задачи что на делфи программисту на C# тебуется гораздо меньше специфических знаний и меньше времени на отладку.
Пока ты держишься в рамках продвигаемых MS технологий/решений -- возможно. Шаг в лево и приплыли.
Здравствуйте, kuj, Вы писали:
kuj>Вместо Delphi пора преподавать .NET технологии.
Можно попробовать.
Только тогда сразу немерле Чтобы народ с юных лет понимал какое Г эти ваши C#'ы и тем болие дельфи.
kuj>Вместо Prolog — Erlang.
Не вместо, а вместе.
Ибо ерланг и пролог имеют очень разные вычислительные модели.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandjustas, Вы писали:
K>>> Да что вы говорите? А подумать прежде, чем отвечать, не судьба? Ок, объясняю — произойдёт два вызова Release() — один из них явно, а второй неявно компилятором. И если после явного вызова Release() счётчик ссылок будет равным нулю, то объект себя удаляет из памяти, и второй вызов приведёт к Access Violation.
H>>Таки да, будет проблема в этом случае. Проморгал, трудный день Однако это не дает тебе права наезжать на компилер по причине того, что Сишный подход не подходит в Delphi. Да, не подходит.
G>То есть пришли к выводу что интерфейсы кроме чем для COM использовать не стоит. Посмотри с чего обсуждение началалось.
Вовсе нет. Вывод тот же, что и ранее -- нефиг лезть со своим уставом в чужой монастырь. Играть нужно по правилам. Давайте еще начнем возмущаться по поводу утечек на таком коде:
Var
Intfs : Array Of IInterface;
Begin
SetLength(Intfs, 10);
Intfs[0] := TInterfacedObject.Create;
Intfs[1] := TInterfacedObject.Create;
Intfs[2] := TInterfacedObject.Create;
Intfs[3] := TInterfacedObject.Create;
Intfs[4] := TInterfacedObject.Create;
FillChar(Pointer(Intfs)^, Length(Intfs) * SizeOf(IInterface), 0);
End;
Я уже приводил маленький кусочек кода демонстрирующий для чего могут использоваться интерфейсы, и слабо себе представляю чем их можно там заменить. При этом, к COM'у тот код никакого отношения не имеет.
Здравствуйте, WolfHound, Вы писали:
H>>Тут есть детерминированность в отличие от того случая. WH>Если за раскопки того случая посадить меня то с ооочень большой вероятностью детерминированость очень быстро найдется. WH>Причем скорей всего просто после чтения кода.
Может да, а может нет
WH>>>Так что существует огромное колличество причин по которым могут происходить фризы. H>>С этим никто и не спорит. WH>Проблема в том что ты нашол какоето упоминание на какомто форуме о непонятно каком фризе и тупо экстраполируешь это упоминание на ГЦ.
Там это дело обсуждали тоже не новички, и советы мониторить GC таки были. Что читал, о том и говорю.
WH>К слову есть алгоритмы сборки мусора дающие гарантии реального времени.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>В Delphi их тоже нет. То что обсуждалось с DX, это ни какая не проблема. Это нарушений правил языка.
В C# не надо таких правил даже знать не надо. Просто нет особенностей работы с COM.
H>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS.
И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов?
.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов.
H>Не SQL'ем единым, как говорится. Применение Delphi не ограничивается мордами к БД.
Морда к БД — как раз основное применение делфи. Сложную логику там реализовывать напряжно.
Работа с БД — одна из основных частей бизнес-приложений. Это чуть ли не самый большой рынок сейчас.
H>Ты знаешь, я для своей задачи выбирал SAX парсер. Перепробовал более 10 штук. Это ли не богатство выбора? Что касается моей функции, повторяю: она написана с целью сократить расход памяти при модификации строк (в Delphi для Ansi-строк работает правило Copy-On-Write) для чего используется побочный эффект при работе с указателями (т.е. я не позволяю Delphi отследить модификацию строки).
1)SAX и DOM рядом не валялись новой билиотекой по работе XML в .NET 3.5
2)Зачем алгоритм банальной замены символов надо оптимизировать по памяти? я бы еще понял по быстродействию.
H>Пока ты держишься в рамках продвигаемых MS технологий/решений -- возможно. Шаг в лево и приплыли.
А ты под какую ОС пишешь? И кто придумал COM технологию?
Здравствуйте, hattab, Вы писали:
H>Вовсе нет. Вывод тот же, что и ранее -- нефиг лезть со своим уставом в чужой монастырь. Играть нужно по правилам. Давайте еще начнем возмущаться по поводу утечек на таком коде:
H>
Здравствуйте, hattab, Вы писали:
WH>>К слову есть алгоритмы сборки мусора дающие гарантии реального времени. H>Чудесно. Используются в .Net?
Разве Windows — realtime ОС?
Здравствуйте, gandjustas, Вы писали:
H>>В Delphi их тоже нет. То что обсуждалось с DX, это ни какая не проблема. Это нарушений правил языка. G>В C# не надо таких правил даже знать не надо. Просто нет особенностей работы с COM.
Что, ссылки руками считаете, или наоборот нет возможности ручного управления?
H>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов.
Элементарно MIDAS, это Delphi трехзвенка, делала это еще в далеком 99 году. И по DCOM, и по CORBA, и OLEEnterprise (была у Inprise такая фенька), и по сокетам. Потом еще SOAP появился, но он вроде не очень юзабельный был.
H>>Не SQL'ем единым, как говорится. Применение Delphi не ограничивается мордами к БД. G>Морда к БД — как раз основное применение делфи. Сложную логику там реализовывать напряжно. G>Работа с БД — одна из основных частей бизнес-приложений. Это чуть ли не самый большой рынок сейчас.
Я не об основном предназначении говорю. Я сказал, что этим не ограничивается (в приводимом мною wiki сколько софта для работы с БД?)
H>>Ты знаешь, я для своей задачи выбирал SAX парсер. Перепробовал более 10 штук. Это ли не богатство выбора? Что касается моей функции, повторяю: она написана с целью сократить расход памяти при модификации строк (в Delphi для Ansi-строк работает правило Copy-On-Write) для чего используется побочный эффект при работе с указателями (т.е. я не позволяю Delphi отследить модификацию строки). G>1)SAX и DOM рядом не валялись новой билиотекой по работе XML в .NET 3.5
Мне не интересно, я все равно напрямую с документом XML не работаю. Мне хватает SAX'а за глаза.
G>2)Зачем алгоритм банальной замены символов надо оптимизировать по памяти? я бы еще понял по быстродействию.
Дело в том, что Delphi при присваивании строк, на самом деле строки не копирует, а просто копирует ссылку и увеличивает счетчик ссылок. В дальнейшем, если в строку вносятся изменения, Delphi уже реально копирует строку (тот самый Copy-On-Write). Этот механизм помогает избежать перерасхода/перемещений памяти при копировании строк. Так вот. Если в мегабайтной строке потребуется поменять символ, нам не избежать копирования мегабайта. Оно нам надо? Поэтому указатели и побочный эффект. Этот код настолько часто вызывается, что оптимизировать есть ради чего.
H>>Пока ты держишься в рамках продвигаемых MS технологий/решений -- возможно. Шаг в лево и приплыли. G>А ты под какую ОС пишешь? И кто придумал COM технологию?
Я не о том. Что есть в .Net для XML-RPC, JSON, Jabber? Будешь искать либы или сам писать.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, hattab, Вы писали:
WH>>>К слову есть алгоритмы сборки мусора дающие гарантии реального времени. H>>Чудесно. Используются в .Net? G>Разве Windows — realtime ОС?
Нет, разумеется. Но смысл упоминать алгоритмы если они не применяются в обсуждаемом фреймвоке?
Здравствуйте, hattab, Вы писали:
H> Ты фантазер. Однозначно. Ссылки разумеется будут декрементиться на каждый вызов и Release и IntfClear (что в результате приведет к преждевременной кончине объекта). Но ни каких Access Violation не будет (ты же перед Release проверяешь переменную). Проверь, если не веришь.
Ну давай пройдёмся по строкам (если тут опять нету никакой скрытой семантики ).
Итак, мы имеем:
var intf : IUnknown;
//тут он откуда-то берётся, и счётчик ссылок его равен 1
intf._Release(); //тут счётчик ссылок обнуляется, что приводит к удалению объекта,
//а указатель продолжает ссылаться на то место, где был объект.
//Тут я делаю за компилятор его работу - инлайню функцию :)if (intf <> nil) //проверка проходит, т.к. указатель не равен нулюbegin
intf._Release(); //тут возможны любые чудеса, т.к. intf по сути является "висящим" указателем
intf := nil; //допустим здесь, что компилятор не проявляет самодеятельности :)end;
Так понятнее?
H>Про Access Violation уже ответил -- его там не будет. А твоя позиция меня просто изумляет: пришел в чужой монастырь со своим уставом, и ну права качать. Право, странные замашки...
См. выше.
H>Инлайнинг IntfClear -- это раздувание кода, причем абсолютно неоправданное.
Вот это новость! Единственное место, где реально "размер имеет значение" — это сфера embedded, но это явно не наш случай Во всех остальных случаях предпочтут больший размер файла при повышении производительности.
Здравствуйте, hattab, Вы писали:
H>Таки да, будет проблема в этом случае. Проморгал, трудный день Однако это не дает тебе права наезжать на компилер по причине того, что Сишный подход не подходит в Delphi. Да, не подходит.
Вот-вот — это проморгал даже ты, по своим же словам профессионал в дельфях. Что же говорить про менее квалифицированных программистов? Но самое страшное тут — что в части случаев этот код таки не будет сбоить — вот получите "плавающий" баг и распишитесь... Ну как так можно?
Кстати всё ещё веселее в операторе as, тоже имеющий неочевидную неявную семантику. В общем, такое ощущение, что разработчики компилятора специально аккуратно раскладывали грабли. Поэтому я в своё время и пришёл к выводу, что ничего серьёзнее базоморд на дельфях лучше не писать во избежание нервных срывов с "лестными" словами в адрес борланда/инпрайза и его программистов...
Здравствуйте, WolfHound, Вы писали:
kuj>>Э-э, батенька, ты явно путаешься в понятиях. kuj>>Во-первых, делегаты прекрасно реализуются в C++ в виде указателей на функцию. WH>Есть куда болие удобная boost::function.
kuj>>Благодаря DI мой ClassA зависит только от IInterfaceB, который реализуется классами ClassB1, ClassB2 и ClassB3. В любой момент времени я могу открыть конфигурацию IoC и сменить байндинг с ClassB1, например, на ClassB2, совсем не затрагивая при этом ClassA. Да, в Delphi и C++ для этого используется паттерн фабрика, НО появляется зависимость ClassA, от фабрики! Вот такие пироги с капустой... WH>IoC контейнер что не фабрика?
IoC контейнер это больше, чем классическая фабрика.
Здравствуйте, WolfHound, Вы писали:
kuj>>Вместо Delphi пора преподавать .NET технологии. WH>Можно попробовать. WH>Только тогда сразу немерле Чтобы народ с юных лет понимал какое Г эти ваши C#'ы и тем болие дельфи.
Тогда уж IronRuby или хотя бы, чтоб народ с юных лет понимал какое Г этот ваш Nemerle.
kuj>>Вместо Prolog — Erlang. WH>Не вместо, а вместе. WH>Ибо ерланг и пролог имеют очень разные вычислительные модели.
Здравствуйте, gandjustas, Вы писали:
G>Еще раз говорю: эту ситацию вижу своими глазами.
G>Лучше факты приведу, почему на .NET писать проще. G>1)Нет утечек памяти. G>2)Нет таких проблем с COM, как описано выше. G>3)Нет проблем с организацией сетевого взаимодействия — не надо изучать "тяжелые" технологии типа DCOM, CORBA и др. G>4)В .NET 3.5 практически не требуется писать DAL: типизированные запросы, проверяемые при компиляции; не надо писать SQL в программе; практически отсутсвие SQL-Injection уязвимостей G>5)В .NET 3.5 очень лекая работа с XML (твой метод XmlUnescapeString даже писать не надо).
.NET 3.5 "делает" Делфи по всем статьям, очевидно. Но имеет ли это значение, если Delphi мертв...
Здравствуйте, gandjustas, Вы писали:
H>>В Delphi их тоже нет. То что обсуждалось с DX, это ни какая не проблема. Это нарушений правил языка. G>В C# не надо таких правил даже знать не надо. Просто нет особенностей работы с COM.
При чем любую .NET-сборку можно легким движением руки превратить в COM-visible.
H>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов.
А еще есть вещи типа nServiceBus с очень высокой scalability.
Куда там Delphi...
H>>Не SQL'ем единым, как говорится. Применение Delphi не ограничивается мордами к БД. G>Морда к БД — как раз основное применение делфи. Сложную логику там реализовывать напряжно. G>Работа с БД — одна из основных частей бизнес-приложений. Это чуть ли не самый большой рынок сейчас.
А учитывая, что "морды к БД" сейчас обычно в виде web-интерфейса реализуются, то и тут Delphi курит бамбук. Про O/RM типа nHibernate или Entity Framework (LINQ for SQL) в Delphi и мечтать не приходится.
H>>Ты знаешь, я для своей задачи выбирал SAX парсер. Перепробовал более 10 штук. Это ли не богатство выбора? Что касается моей функции, повторяю: она написана с целью сократить расход памяти при модификации строк (в Delphi для Ansi-строк работает правило Copy-On-Write) для чего используется побочный эффект при работе с указателями (т.е. я не позволяю Delphi отследить модификацию строки).
G>1)SAX и DOM рядом не валялись новой билиотекой по работе XML в .NET 3.5 G>2)Зачем алгоритм банальной замены символов надо оптимизировать по памяти? я бы еще понял по быстродействию.
Классика — пока в лагере Делфи глупые туземцы перебирают SAX парсеры, в лагере .NET уже давно все отпарсено и жители празднуют!
Здравствуйте, hattab, Вы писали:
H>>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов.
H>Элементарно MIDAS, это Delphi трехзвенка, делала это еще в далеком 99 году. И по DCOM, и по CORBA, и OLEEnterprise (была у Inprise такая фенька), и по сокетам. Потом еще SOAP появился, но он вроде не очень юзабельный был.
К слову о Web-сервисах. Как у Делфи обстоят дела с поддержкой WS-Security 1.1, WS-Trust, WS-SecureConversation, WS-Addressing и MTOM?..
H>>>Пока ты держишься в рамках продвигаемых MS технологий/решений -- возможно. Шаг в лево и приплыли. G>>А ты под какую ОС пишешь? И кто придумал COM технологию?
H>Я не о том. Что есть в .Net для XML-RPC, JSON, Jabber? Будешь искать либы или сам писать.
Море всего на любой вкус. В основном OSS, к тому же -> codeplex, sourceforge.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>Что, ссылки руками считаете, или наоборот нет возможности ручного управления?
.NET ссылки считает.
H>Элементарно MIDAS, это Delphi трехзвенка, делала это еще в далеком 99 году. И по DCOM, и по CORBA, и OLEEnterprise (была у Inprise такая фенька), и по сокетам. Потом еще SOAP появился, но он вроде не очень юзабельный был.
Наверное тяжело спорить о том, чего не знаешь.
// Client.csusing System;
using System.Runtime.Remoting;
using TestObject;
namespace Client
{
class Client
{
[STAThread]
static void Main(string[] args)
{
RemotingConfiguration.Configure("Client.exe.config");
Test test = new Test();
Console.WriteLine(test.GetAppName()); //Здесь test.GetAppName() вызовется на сервере!!!!
}
}
}
Такое на делфи возможно?
H>Мне не интересно, я все равно напрямую с документом XML не работаю. Мне хватает SAX'а за глаза.
Не показывай свою ограниченность. SAX парсер далеко не для всех задач подходит.
H>Дело в том, что Delphi при присваивании строк, на самом деле строки не копирует, а просто копирует ссылку и увеличивает счетчик ссылок. В дальнейшем, если в строку вносятся изменения, Delphi уже реально копирует строку (тот самый Copy-On-Write). Этот механизм помогает избежать перерасхода/перемещений памяти при копировании строк. Так вот. Если в мегабайтной строке потребуется поменять символ, нам не избежать копирования мегабайта. Оно нам надо? Поэтому указатели и побочный эффект. Этот код настолько часто вызывается, что оптимизировать есть ради чего.
Ты сам понимаешь, что пишешь костыли?
В .NET и Java есть StringBuilder, который не копирует строку при изменении. Там достаточно пару раз вызвать Replace.
H>Я не о том. Что есть в .Net для XML-RPC, JSON, Jabber? Будешь искать либы или сам писать.
А в делфи есть? Это ведь тоже сторонние библиотеки. .NET не распространяется со сторонними библиотеками.
Кстати для JSON сериализации все есть.
Здравствуйте, koandrew, Вы писали:
K>Вот-вот — это проморгал даже ты, по своим же словам профессионал в дельфях. Что же говорить про менее квалифицированных программистов? Но самое страшное тут — что в части случаев этот код таки не будет сбоить — вот получите "плавающий" баг и распишитесь... Ну как так можно?
Мне трудно поверить, что ты не понимаешь банальной истины следования правилам языка Чаще всего, на Delphi, вообще не приходится применять ручное управление подсчетом ссылок. Но если уж берешься -- будь добр соответствовать. С этим тезисом ты станешь спорить? В .Net небходимость использования using тоже далеко не очевидна, что мне теперь накинуться на нее с криками MD?
В твоем примере достаточно было заменить Intf := NIL на Pointer(Intf) := NIL, и проблемы бы не было. Это вообще сродни ситуациям получения переполнения стека на рекурсивных функциях, рекурсии в сеттере свойства и прочим подобным. Это говорит только об одном -- о квалификации программиста. То, что я не заметил косяка в коде говорит только о моей невнимательности, но я при чтении форумов и не стараюсь фокусироваться (даже имя параметра в декларации SomeProc пропустил).
K>Кстати всё ещё веселее в операторе as, тоже имеющий неочевидную неявную семантику. В общем, такое ощущение, что разработчики компилятора специально аккуратно раскладывали грабли. Поэтому я в своё время и пришёл к выводу, что ничего серьёзнее базоморд на дельфях лучше не писать во избежание нервных срывов с "лестными" словами в адрес борланда/инпрайза и его программистов...
Очевидно Asus, Macromedia, Skype, Yahoo и другие так не думают.
Здравствуйте, koandrew, Вы писали:
H>>Инлайнинг IntfClear -- это раздувание кода, причем абсолютно неоправданное.
K>Вот это новость! Единственное место, где реально "размер имеет значение" — это сфера embedded, но это явно не наш случай Во всех остальных случаях предпочтут больший размер файла при повышении производительности.
Повышение производительности за счет инлайнинга операций подсчета ссылок, это сродни полировке заклепок на танке, в надежде улучшить его аэродинамику.
Здравствуйте, gandjustas, Вы писали:
H>>Что, ссылки руками считаете, или наоборот нет возможности ручного управления? G>.NET ссылки считает.
Т.е. ручками вам не дают считать?
H>>Элементарно MIDAS, это Delphi трехзвенка, делала это еще в далеком 99 году. И по DCOM, и по CORBA, и OLEEnterprise (была у Inprise такая фенька), и по сокетам. Потом еще SOAP появился, но он вроде не очень юзабельный был. G>Наверное тяжело спорить о том, чего не знаешь.
G>Код из статьи
G>// Client.cs
G>using System;
G>using System.Runtime.Remoting;
G>using TestObject;
G>namespace Client
G>{
G> class Client
G> {
G> [STAThread]
G> static void Main(string[] args)
G> {
G> RemotingConfiguration.Configure("Client.exe.config");
G> Test test = new Test();
G> Console.WriteLine(test.GetAppName()); //Здесь test.GetAppName() вызовется на сервере!!!!
G> }
G> }
G>}
G>
G>Такое на делфи возможно?
Да не Delphi, много как можно... Можно так:
Var
WS : IMyWebService;
Begin
ws := (RIO as IMyWebService);
WriteLn(ws.GetAppName);
// GetAppName тоже отработает на сервере. RIO интерфейс IMyWebService не реализует (все делается в динамике)End;
Код не полный, я с SOAP'ом не работал плотно. Могу на своем XML-RPC:
Begin
WriteLn(XmlRpcValueToStr(XmlRpcServerProxy('http://foxrate.org/rpc/').foxrate.currencyConvert('USD', 'RUB', 1.0)));
// На сервере http://foxrate.org/rpc/ будет дернут метод foxrate.currencyConvertEnd;
H>>Мне не интересно, я все равно напрямую с документом XML не работаю. Мне хватает SAX'а за глаза. G>Не показывай свою ограниченность. SAX парсер далеко не для всех задач подходит.
Я говорю не о задаче в вакуме, а своей конкретной.
H>>Дело в том, что Delphi при присваивании строк, на самом деле строки не копирует, а просто копирует ссылку и увеличивает счетчик ссылок. В дальнейшем, если в строку вносятся изменения, Delphi уже реально копирует строку (тот самый Copy-On-Write). Этот механизм помогает избежать перерасхода/перемещений памяти при копировании строк. Так вот. Если в мегабайтной строке потребуется поменять символ, нам не избежать копирования мегабайта. Оно нам надо? Поэтому указатели и побочный эффект. Этот код настолько часто вызывается, что оптимизировать есть ради чего. G>Ты сам понимаешь, что пишешь костыли? G>В .NET и Java есть StringBuilder, который не копирует строку при изменении. Там достаточно пару раз вызвать Replace.
Это не костыль, это мягкий хак. У нас тоже есть строки не копируемые при изменениях, но мне нужна AnsiString.
H>>Я не о том. Что есть в .Net для XML-RPC, JSON, Jabber? Будешь искать либы или сам писать. G>А в делфи есть? Это ведь тоже сторонние библиотеки. .NET не распространяется со сторонними библиотеками. G>Кстати для JSON сериализации все есть.
Я и говорю, как только выйдешь за рамки MS tech, твое положение будет ни чем не лучше моего.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Что, ссылки руками считаете, или наоборот нет возможности ручного управления? G>>.NET ссылки считает. H>Т.е. ручками вам не дают считать?
Не дают.
H>Да не Delphi, много как можно... Можно так: H>
H>Var
H> WS : IMyWebService;
H>Begin
H> ws := (RIO as IMyWebService);
H> WriteLn(ws.GetAppName);
H> // GetAppName тоже отработает на сервере. RIO интерфейс IMyWebService не реализует (все делается в динамике)
H>End;
H>
А что такое RIO и где конфигурация? Да и странно (неочевидно) такое поведение оператора as.
H>Код не полный, я с SOAP'ом не работал плотно. Могу на своем XML-RPC: H>
H>Begin
H> WriteLn(XmlRpcValueToStr(XmlRpcServerProxy('http://foxrate.org/rpc/').foxrate.currencyConvert('USD', 'RUB', 1.0)));
H> // На сервере http://foxrate.org/rpc/ будет дернут метод foxrate.currencyConvert
H>End;
H>
После вызова XmlRpcServerProxy не надо этому прокси Free делать? Или он сам освобождается за счет своеобразного сборщика мусора для COM объектов в делфи? Не боишься что фризы будут? Или памяти непомерно схавает при куче таких вызовов?
Да и строка, возвращаемая XmlRpcValueToStr, управляется сборщиком мусора.
Странно что при этом ты ругаешь управляемые платформы.
H>Я и говорю, как только выйдешь за рамки MS tech, твое положение будет ни чем не лучше моего.
Только выйти за рамки MS Tech гораздо сложнее, чем выйти за рамки стандартного VCL.
Здравствуйте, hattab, Вы писали:
H>>>Я не о том. Что есть в .Net для XML-RPC, JSON, Jabber? Будешь искать либы или сам писать. G>>А в делфи есть? Это ведь тоже сторонние библиотеки. .NET не распространяется со сторонними библиотеками. G>>Кстати для JSON сериализации все есть.
H>Я и говорю, как только выйдешь за рамки MS tech, твое положение будет ни чем не лучше моего.
Что есть "рамки MS tech"?
В любом случае есть понастоящему кроссплатформенная Java. Любой .NET`чик легко сможет перейти программировать на Java и любой Java-программист — на .NET Архитектура и фреймворки обеих платформ весьма схожи. Многие инструменты, широко применяемые в .NET, это всего-навсего порты с Java (Hibernate -> nHibernate, Spring — Spring.NET, log4j -> log4net и т.д.)
Что до ресурсоемкости и быстродействия Java... открой для себя IntelliJ IDEA — Delphi до нее, что до неба по удобству и быстродействию.
Здравствуйте, gandjustas, Вы писали:
H>>>>Что, ссылки руками считаете, или наоборот нет возможности ручного управления? G>>>.NET ссылки считает. H>>Т.е. ручками вам не дают считать? G>Не дают.
Я и не удивлен даже, после претензий высказываемых в адресс Delphi.
H>>Да не Delphi, много как можно... Можно так: H>>
H>>Var
H>> WS : IMyWebService;
H>>Begin
H>> ws := (RIO as IMyWebService);
H>> WriteLn(ws.GetAppName);
H>> // GetAppName тоже отработает на сервере. RIO интерфейс IMyWebService не реализует (все делается в динамике)
H>>End;
H>>
G>А что такое RIO и где конфигурация? Да и странно (неочевидно) такое поведение оператора as.
RIO это объект класса THttpRIO, создать можно где угодно, как и проинициализировать. Обычно (подчеркиваю, обычно) он лежит в каком нибудь дата-модуле. Интерфейс, разумеется, должен быть где-нибудь описан (но реализовывать его заглушкой не нужно). Обычно интерфейсы генерируются после экспорта из WSDL.
H>>Код не полный, я с SOAP'ом не работал плотно. Могу на своем XML-RPC: H>>
H>>Begin
H>> WriteLn(XmlRpcValueToStr(XmlRpcServerProxy('http://foxrate.org/rpc/').foxrate.currencyConvert('USD', 'RUB', 1.0)));
H>> // На сервере http://foxrate.org/rpc/ будет дернут метод foxrate.currencyConvert
H>>End;
H>>
G>После вызова XmlRpcServerProxy не надо этому прокси Free делать? Или он сам освобождается за счет своеобразного сборщика мусора для COM объектов в делфи? Не боишься что фризы будут? Или памяти непомерно схавает при куче таких вызовов?
Ни каких чисток делать не нужно, ибо это интерфейс диспетчеризации лежащий в вариантной переменной (сразу скажу, что то же самое можно делать и через объектные заглушки, и через advanced records заглушки), для которых работает управляемая сборка мусора. Фризов там просто не может быть т.к. эта сборка ни чем не отличается от ручной очистки сырой памяти (кроме автоматизации сего процесса), которая не накапливается в поколениях.
G>Да и строка, возвращаемая XmlRpcValueToStr, управляется сборщиком мусора. G>Странно что при этом ты ругаешь управляемые платформы.
Я за управляемую сборку. А претензий к .Net/Java у меня нет, ибо они мне параллельны
H>>Я и говорю, как только выйдешь за рамки MS tech, твое положение будет ни чем не лучше моего. G>Только выйти за рамки MS Tech гораздо сложнее, чем выйти за рамки стандартного VCL.
У Delphi никогда и небыло амбиций всереализующей платформы. Ее идеология в другом: есть очень немаленькое ядро, и есть компонентный подход.
kuj>>>Вместо Prolog — Erlang. WH>>Не вместо, а вместе. WH>>Ибо ерланг и пролог имеют очень разные вычислительные модели.
kuj>Не на столько разные, чтоб заморачиваться.
Очень разные. Erlang — не логическия язык программирования.
Здравствуйте, hattab, Вы писали:
H>>>>>Что, ссылки руками считаете, или наоборот нет возможности ручного управления? G>>>>.NET ссылки считает. H>>>Т.е. ручками вам не дают считать? G>>Не дают.
H> Я и не удивлен даже, после претензий высказываемых в адресс Delphi.
С какой радости их может понадобиться считать ручками? Just look how stupid you are.
H>RIO это объект класса THttpRIO, создать можно где угодно, как и проинициализировать. Обычно (подчеркиваю, обычно) он лежит в каком нибудь дата-модуле. Интерфейс, разумеется, должен быть где-нибудь описан (но реализовывать его заглушкой не нужно). Обычно интерфейсы генерируются после экспорта из WSDL.
Как в Delphi с организацией внутрикорпоративной коммуникации по MSMQ? Я конечно не рассчитываю увидеть хоть что-то близкое к nServiceBus, но хоть что-то есть?
Здравствуйте, Mamut, Вы писали:
kuj>>>>Вместо Prolog — Erlang. WH>>>Не вместо, а вместе. WH>>>Ибо ерланг и пролог имеют очень разные вычислительные модели.
kuj>>Не на столько разные, чтоб заморачиваться.
M>Очень разные. Erlang — не логическия язык программирования.
Мамут как всегда на высоте... взял и обосрал Erlang. Мол, нелогичный он какой-то...
kuj>>>Не на столько разные, чтоб заморачиваться. M>>Очень разные. Erlang — не логический язык программирования.
kuj>Мамут как всегда на высоте... взял и обосрал Erlang. Мол, нелогичный он какой-то...
Ты бы это... Взял бы и посмотрел на Эрланг, что ли. Prolog и Erlang — два абсолютно разных языка.
Ну и эта... Если ты не знаешь, что таое логический язык программирования... Почитай что-ли...
Вместо Prolog — Erlang
Не на столько разные, чтоб заморачиваться
Здравствуйте, Mamut, Вы писали:
kuj>>>>Не на столько разные, чтоб заморачиваться. M>>>Очень разные. Erlang — не логический язык программирования.
kuj>>Мамут как всегда на высоте... взял и обосрал Erlang. Мол, нелогичный он какой-то...
M>Ты бы это... Взял бы и посмотрел на Эрланг, что ли. Prolog и Erlang — два абсолютно разных языка.
Эх, Мамут-Мамут, сам-то читал? Эрланг и Пролог — функциональные языки. Эрланг базируется на идентичном Прологу синтаксисе. Да, в Эрланг много всего того, чего нет в Прологе, но это не значит, что он хуже для преподавания. Скорее наоборот.
Здравствуйте, kuj, Вы писали:
H>>>>>>Что, ссылки руками считаете, или наоборот нет возможности ручного управления? G>>>>>.NET ссылки считает. H>>>>Т.е. ручками вам не дают считать? G>>>Не дают.
H>> Я и не удивлен даже, после претензий высказываемых в адресс Delphi.
kuj>С какой радости их может понадобиться считать ручками? Just look how stupid you are.
H>>RIO это объект класса THttpRIO, создать можно где угодно, как и проинициализировать. Обычно (подчеркиваю, обычно) он лежит в каком нибудь дата-модуле. Интерфейс, разумеется, должен быть где-нибудь описан (но реализовывать его заглушкой не нужно). Обычно интерфейсы генерируются после экспорта из WSDL.
kuj>Как в Delphi с организацией внутрикорпоративной коммуникации по MSMQ? Я конечно не рассчитываю увидеть хоть что-то близкое к nServiceBus, но хоть что-то есть?
Я задал два вопроса, на что получил -1. hattab ты, собственно, с чем не согласен? Слив засчитан.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>>>Что, ссылки руками считаете, или наоборот нет возможности ручного управления? G>>>>.NET ссылки считает. H>>>Т.е. ручками вам не дают считать? G>>Не дают. H> Я и не удивлен даже, после претензий высказываемых в адресс Delphi.
Чего смешного. Назови 3 объективные причины вызывать AddRef и Release.
Только не забывай, что в делфи это еще сопровождается автоматическй считалкой, что очень чревато багами при совмещении того и другого.
H>Ни каких чисток делать не нужно, ибо это интерфейс диспетчеризации лежащий в вариантной переменной (сразу скажу, что то же самое можно делать и через объектные заглушки, и через advanced records заглушки), для которых работает управляемая сборка мусора. Фризов там просто не может быть т.к. эта сборка ни чем не отличается от ручной очистки сырой памяти (кроме автоматизации сего процесса), которая не накапливается в поколениях.
И в какой момент эта сборка мусора происходит?
H>У Delphi никогда и небыло амбиций всереализующей платформы. Ее идеология в другом: есть очень немаленькое ядро, и есть компонентный подход.
И есть exeшники по 1.5 метров. Спасибо, поржал.
В .NET и Java компонентный подход гораздо сильнее, чем в делфи. Причем он гораздо более умно сделан. Нету привязки всего к формам.
Я видел Дельфи только в середине 90х, на самом раннем этапе его развития. С тех пор я о нем только от других слышал, сам не трогал.
Недостатки: отсутствие толковой оптимизации кода, что делает его медленнее Явы и Шарпа. Отвратительно уродский слой работы с базами данных под названием BDE. Проблемы с обращением к компонентам OLE Automation.
VB6 был намного лучше, ибо свободен от этих проблем (у него полноценный компилятор, вторая фаза от MS C++ compiler). У него ADO вместо BDE.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>VB6 был намного лучше, ибо свободен от этих проблем (у него полноценный компилятор, вторая фаза от MS C++ compiler). У него ADO вместо BDE.
В VB6 зато был абсолютно идиотский язык, и достаточно убогая компонентная модель (в Дельфи они однозначно была лучше).
Другое дело, что Delphi с VB6 сейчас сливают C#, Java и даже С++ с адекватным инструментарием.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>VB6 был намного лучше, ибо свободен от этих проблем (у него полноценный компилятор, вторая фаза от MS C++ compiler). У него ADO вместо BDE.
Щас тебя закидуют тухлыми помидорами, потому что в делфи, кажись с пятой версии, есть ADO. Причем именно ADO является основным иструментом с тех пор.
Здравствуйте, gandjustas, Вы писали:
H>>>>>>Что, ссылки руками считаете, или наоборот нет возможности ручного управления? G>>>>>.NET ссылки считает. H>>>>Т.е. ручками вам не дают считать? G>>>Не дают. H>> Я и не удивлен даже, после претензий высказываемых в адресс Delphi. G>Чего смешного. Назови 3 объективные причины вызывать AddRef и Release. G>Только не забывай, что в делфи это еще сопровождается автоматическй считалкой, что очень чревато багами при совмещении того и другого.
Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок.
H>>Ни каких чисток делать не нужно, ибо это интерфейс диспетчеризации лежащий в вариантной переменной (сразу скажу, что то же самое можно делать и через объектные заглушки, и через advanced records заглушки), для которых работает управляемая сборка мусора. Фризов там просто не может быть т.к. эта сборка ни чем не отличается от ручной очистки сырой памяти (кроме автоматизации сего процесса), которая не накапливается в поколениях. G>И в какой момент эта сборка мусора происходит?
В момент выхода переменых из области видимости. Ты не знал?
H>>У Delphi никогда и небыло амбиций всереализующей платформы. Ее идеология в другом: есть очень немаленькое ядро, и есть компонентный подход. G>И есть exeшники по 1.5 метров. Спасибо, поржал.
В MS Office есть экзешки по 3 метра, и? Размер файла вообще придирка странная: ни на чем негативно не сказывается, избавиться от этого элементарно (у нас есть пакеты). Проблема из области психологии, полагаю
G>В .NET и Java компонентный подход гораздо сильнее, чем в делфи. Причем он гораздо более умно сделан. Нету привязки всего к формам.
У нас привязки к формам тоже нет Это очередная нелепая нападка.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Недостатки: отсутствие толковой оптимизации кода, что делает его медленнее Явы и Шарпа. Отвратительно уродский слой работы с базами данных под названием BDE. Проблемы с обращением к компонентам OLE Automation.
Оптимизация кода не идеальная. Но этот код не медленнее Java/C# (для себя полгода назад писал расчетный (примитивный расчет с использование типов Double) бенч на C# и Delphi. Писал объективно, ибо для себя. Разница почти 2 раза в пользу Delphi). Примеры приводить не буду, пенисометрия мне не интересна. Если угодно, пусть это останется моим голословным утверждением по аналогии с уже звучавшими от опонентов. BDE это конечно кошмар, но уже давно есть и ADO, и DbExpress (который, к слову, и является основной рекомендуемой техникой). Проблем с OLE Automation не испытываю со времен пятерки.
MSS>VB6 был намного лучше, ибо свободен от этих проблем (у него полноценный компилятор, вторая фаза от MS C++ compiler). У него ADO вместо BDE.
Object-based лучше Object-Oriented (Или VB6 уже был полноценным OO-language?)
Здравствуйте, hattab, Вы писали:
H>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок.
Вот здесь и проявятся плюсы .NET — на Delphi (да и на любой другой платформе без GC) надо писать все эти AddRef, Release (не факт, что не забудешь вызвать их в нужном месте), а на .Net, Java etc. все происходит автоматом.
Здравствуйте, Эдик, Вы писали:
Э>Здравствуйте, hattab, Вы писали:
H>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок.
Э>Вот здесь и проявятся плюсы .NET — на Delphi (да и на любой другой платформе без GC) надо писать все эти AddRef, Release (не факт, что не забудешь вызвать их в нужном месте), а на .Net, Java etc. все происходит автоматом.
Ну расскажи, как автоматом разрулятся взаимные ссылки
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>VB6 был намного лучше, ибо свободен от этих проблем (у него полноценный компилятор, вторая фаза от MS C++ compiler). У него ADO вместо BDE. G>Щас тебя закидуют тухлыми помидорами, потому что в делфи, кажись с пятой версии, есть ADO. Причем именно ADO является основным иструментом с тех пор.
ADO, DbExpress (основная) и целая куча нативных движков начиная от Oracle и заканчивая самыми примитивными. У тебя, как всегда, информация из 98-2000 Хватит уже лаять в след давно ушедшему поезду.
Здравствуйте, hattab, Вы писали:
H>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок.
Такое в .NET работает нормально. .NET не отменяет подсчет ссылок (это вообще обязанность COM объекта), .NET скрывает это от программиста. Поэтому в .NET нету разницы между COM и не-COM.
Короче причин не вижу, слив засчитан.
H>В момент выхода переменых из области видимости. Ты не знал?
А если объект сохраняется в глобаьной переменной или поле класса, то когда?
H>>>У Delphi никогда и небыло амбиций всереализующей платформы. Ее идеология в другом: есть очень немаленькое ядро, и есть компонентный подход. G>>И есть exeшники по 1.5 метров. Спасибо, поржал.
H>В MS Office есть экзешки по 3 метра, и? Размер файла вообще придирка странная: ни на чем негативно не сказывается, избавиться от этого элементарно (у нас есть пакеты). Проблема из области психологии, полагаю
Это к вопросу о маленьком ядре и компонентах.
Здравствуйте, kuj, Вы писали:
WH>>Ибо ерланг и пролог имеют очень разные вычислительные модели. kuj>Не на столько разные, чтоб заморачиваться.
После этого заявления все твои суждения о языках программирования можно отправлять в топку вобще не читая.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, kuj, Вы писали:
kuj>Эх, Мамут-Мамут, сам-то читал? Эрланг и Пролог — функциональные языки.
Ага. И форт с паскалем тоже.
kuj>Эрланг базируется на идентичном Прологу синтаксисе. Да, в Эрланг много всего того, чего нет в Прологе, но это не значит, что он хуже для преподавания. Скорее наоборот. Эта вакансия
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Эдик, Вы писали:
Э>>Здравствуйте, hattab, Вы писали:
H>>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок. Э>>Вот здесь и проявятся плюсы .NET — на Delphi (да и на любой другой платформе без GC) надо писать все эти AddRef, Release (не факт, что не забудешь вызвать их в нужном месте), а на .Net, Java etc. все происходит автоматом. H>Ну расскажи, как автоматом разрулятся взаимные ссылки
Здравствуйте, WolfHound, Вы писали:
kuj>>IoC контейнер это больше, чем классическая фабрика. WH>И что в нем такого?
Например, декларативное управление зависимостями.
Хотя под шаблон "фабрика" вообще многое можно подогнать...
Здравствуйте, gandjustas, Вы писали:
H>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок. G>Такое в .NET работает нормально. .NET не отменяет подсчет ссылок (это вообще обязанность COM объекта), .NET скрывает это от программиста. Поэтому в .NET нету разницы между COM и не-COM. G>Короче причин не вижу, слив засчитан.
Ты давай расскажи, как .Net будет разруливать это. Мне ждать ответа, или ты слил?
H>>В момент выхода переменых из области видимости. Ты не знал? G>А если объект сохраняется в глобаьной переменной или поле класса, то когда?
В глобальной переменной будет храниться до тех пор, пока ей не будет назначено другое значение. В поле класса аналогично, или до тех пор, пока объект-владелей жив.
H>>>>У Delphi никогда и небыло амбиций всереализующей платформы. Ее идеология в другом: есть очень немаленькое ядро, и есть компонентный подход. G>>>И есть exeшники по 1.5 метров. Спасибо, поржал.
H>>В MS Office есть экзешки по 3 метра, и? Размер файла вообще придирка странная: ни на чем негативно не сказывается, избавиться от этого элементарно (у нас есть пакеты). Проблема из области психологии, полагаю G>Это к вопросу о маленьком ядре и компонентах.
Читай внимательно: "немаленькое ядро". Немаленькое не в смысле размера, а в смысле охватывата.
Здравствуйте, gandjustas, Вы писали:
H>>>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок. Э>>>Вот здесь и проявятся плюсы .NET — на Delphi (да и на любой другой платформе без GC) надо писать все эти AddRef, Release (не факт, что не забудешь вызвать их в нужном месте), а на .Net, Java etc. все происходит автоматом. H>>Ну расскажи, как автоматом разрулятся взаимные ссылки
G>Не боись, действительно все это разруливается.
Очень хочется послушать, как это будет сделано. Жду.
Здравствуйте, Cyberax, Вы писали:
C>Например, декларативное управление зависимостями. C>Хотя под шаблон "фабрика" вообще многое можно подогнать...
И я о томже.
Тем болие в контексте разговора нам по любому нужно зависить от чегото.
А как это что-то назвать фабрика, IoC контейнер, хрумбабулек прумкабятый,... не важно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
(с примерами реализации). Идея в том, чтобы отделить граф "доступных" объектов от графа "недоступных", несмотря на наличие взаимных ссылок у "недоступных" объектов.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок. Э>>>>Вот здесь и проявятся плюсы .NET — на Delphi (да и на любой другой платформе без GC) надо писать все эти AddRef, Release (не факт, что не забудешь вызвать их в нужном месте), а на .Net, Java etc. все происходит автоматом. H>>>Ну расскажи, как автоматом разрулятся взаимные ссылки
G>>Не боись, действительно все это разруливается.
H>Очень хочется послушать, как это будет сделано. Жду.
Если дочерний объект ссылается на родителя, то он увеличивает ему счетчик сылок. Тогда родительский объект будет жить пока живут дочерние. Соответственно если объект создает дочерние, то он и должен их удалять. Это вообще COM-объект так должен работать.
.NET объекты выставленные как COM так и работают
Здравствуйте, WolfHound, Вы писали:
WH>Тем болие в контексте разговора нам по любому нужно зависить от чегото. WH>А как это что-то назвать фабрика, IoC контейнер, хрумбабулек прумкабятый,... не важно.
Вот ClassA, который зависит от IInterfaceB. Вот ClassB : IInterfaceB. В ClassA нет ни одного упоминания ни ClassB, ни IoC-контейнера.
IoC.Resolve<> с помощью DI конструирует и передает объекты ClassB в ClassA (setter / interface / constructor injection). Более того, IoC-контейнеры часто используются для AoP (aspect oriented programming) с помощью interceptors и dependency injection.
H>>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок. G>>Такое в .NET работает нормально. .NET не отменяет подсчет ссылок (это вообще обязанность COM объекта), .NET скрывает это от программиста. Поэтому в .NET нету разницы между COM и не-COM. G>>Короче причин не вижу, слив засчитан.
H>Ты давай расскажи, как .Net будет разруливать это. Мне ждать ответа, или ты слил?
Здравствуйте, hattab, Вы писали:
MSS>>Недостатки: отсутствие толковой оптимизации кода, что делает его медленнее Явы и Шарпа. Отвратительно уродский слой работы с базами данных под названием BDE. Проблемы с обращением к компонентам OLE Automation.
H>Оптимизация кода не идеальная. Но этот код не медленнее Java/C# (для себя полгода назад писал расчетный (примитивный расчет с использование типов Double) бенч на C# и Delphi. Писал объективно, ибо для себя. Разница почти 2 раза в пользу Delphi).
Это значит только, что писать под .NET не умеешь.
В целом ряде случаев .NET дает более высокую производительность за счет более тонкой оптимизации под целевой процессор (компиляция из байт-кода в машинный производится непосредственно там, где он будет выполняться).
H>Примеры приводить не буду, пенисометрия мне не интересна. Если угодно, пусть это останется моим голословным утверждением по аналогии с уже звучавшими от опонентов. BDE это конечно кошмар, но уже давно есть и ADO, и DbExpress (который, к слову, и является основной рекомендуемой техникой). Проблем с OLE Automation не испытываю со времен пятерки.
Угу, в .NET LINQ for SQL, а в Delphi все пользуются низкоуровневыми средствами. Нашел чем гордиться.
Здравствуйте, Mr.Cat, Вы писали:
H>>Ты давай расскажи, как .Net будет разруливать это. Мне ждать ответа, или ты слил?
MC>Похоже, Вы не в курсе про принципы работы GC. Для начала про один из вариантов можно почитать здесь
(с примерами реализации). Идея в том, чтобы отделить граф "доступных" объектов от графа "недоступных", несмотря на наличие взаимных ссылок у "недоступных" объектов.
Вероятно, имеет смысл уточнить: мы говорим не об объектах, а об интерфейсах. Для интерфейсов существует только один способ GC -- подсчет ссылок.
H>ADO, DbExpress (основная) и целая куча нативных движков начиная от Oracle и заканчивая самыми примитивными. У тебя, как всегда, информация из 98-2000 Хватит уже лаять в след давно ушедшему поезду.
Так и есть. Именно потому в 98-2000 люди шарахались от Дельфей.
BDE — аналог Jet из Access. Для своей родной файловой БД неплох, но обращения к внешним SQL источникам там идут через механизм attached table, который, как я понимаю, откачивает почти всю выборку из внешнего SQL в таблицу во временной "родной" БД, и потом листает именно ее.
Дрянь. И BDE дрянь, и использование Access для SQL Server и Oracle тоже дрянь.
Здравствуйте, hattab, Вы писали: H>Вероятно, имеет смысл уточнить: мы говорим не об объектах, а об интерфейсах. Для интерфейсов существует только один способ GC -- подсчет ссылок.
Вы под интерфейсом понимаете COM-интерфейс? Тогда ХЗ, возможно, Вы и правы. Не знаю, как работает GC для оберток COM-объектов.
Здравствуйте, gandjustas, Вы писали:
H>>>>>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок. Э>>>>>Вот здесь и проявятся плюсы .NET — на Delphi (да и на любой другой платформе без GC) надо писать все эти AddRef, Release (не факт, что не забудешь вызвать их в нужном месте), а на .Net, Java etc. все происходит автоматом. H>>>>Ну расскажи, как автоматом разрулятся взаимные ссылки
G>>>Не боись, действительно все это разруливается.
H>>Очень хочется послушать, как это будет сделано. Жду.
G>Если дочерний объект ссылается на родителя, то он увеличивает ему счетчик сылок. Тогда родительский объект будет жить пока живут дочерние. Соответственно если объект создает дочерние, то он и должен их удалять. Это вообще COM-объект так должен работать. G>.NET объекты выставленные как COM так и работают
Я еще раз уточняю: речь идет об интерфейсах. А менять условие задачи, для подгона под ответ -- это моветон. Интерфейс-родитель не может удалить дочерние т.к. они должны быть удалены только в момент смерти самого родителя, а он не может умереть пока жив хоть один дочерний. В свою очередь, дочерние интерфейсы сами имеют ссылку на родителя. Плюс, на дочерние интерфейсы (да и на родительский) имеются ссылки со стороны приложения.
Эта задача не высосона из пальца. Не так давно я эту ситуацию разруливал именно благодаря наличию ручного управления счетчиком ссылок. Сразу добавлю, просчета в проектировании тут нет
Здравствуйте, Mr.Cat, Вы писали:
H>>Вероятно, имеет смысл уточнить: мы говорим не об объектах, а об интерфейсах. Для интерфейсов существует только один способ GC -- подсчет ссылок.
MC>Вы под интерфейсом понимаете COM-интерфейс? Тогда ХЗ, возможно, Вы и правы. Не знаю, как работает GC для оберток COM-объектов.
Хм... Ну пусть будет COM-объект. Хотя в Delphi интерфейсы могут иметь не только COM-объекты.
Здравствуйте, kuj, Вы писали:
kuj>Это значит только, что писать под .NET не умеешь.
kuj>В целом ряде случаев
"Какой ряд вы называете целым?"
kuj> .NET дает более высокую производительность за счет более тонкой оптимизации под целевой процессор (компиляция из байт-кода в машинный производится непосредственно там, где он будет выполняться).
У JIT-компиляторов оптимизация получается неважная — потому что важно обеспечить быструю компиляцию.
Здравствуйте, Maxim S. Shatskih, Вы писали:
H>>ADO, DbExpress (основная) и целая куча нативных движков начиная от Oracle и заканчивая самыми примитивными. У тебя, как всегда, информация из 98-2000 Хватит уже лаять в след давно ушедшему поезду.
MSS>Так и есть. Именно потому в 98-2000 люди шарахались от Дельфей.
Пятерка (99 год) одна из самых популярных версий. Шестерка (2001) первая версия с возможностью кросс-платформенного программирования (CLX проекты были полностью совместимы с Kylix). Исход начался позднее, даже позднее выхода семерки. Восьмая версия (чисто-.Net) самая неудачная.
MSS>BDE — аналог Jet из Access. Для своей родной файловой БД неплох, но обращения к внешним SQL источникам там идут через механизм attached table, который, как я понимаю, откачивает почти всю выборку из внешнего SQL в таблицу во временной "родной" БД, и потом листает именно ее.
Кажется, BDE появился раньше Jet (хотя тут могу ошибаться)
MSS>Дрянь. И BDE дрянь, и использование Access для SQL Server и Oracle тоже дрянь.
BDE -- дрянь, не спорю. Прямой (и высокоуровневый) доступ -- рулез. А DbExpress обеспечивает, практически, и то и другое
Здравствуйте, hattab, Вы писали:
H>Я еще раз уточняю: речь идет об интерфейсах. А менять условие задачи, для подгона под ответ -- это моветон. Интерфейс-родитель не может удалить дочерние т.к. они должны быть удалены только в момент смерти самого родителя, а он не может умереть пока жив хоть один дочерний. В свою очередь, дочерние интерфейсы сами имеют ссылку на родителя. Плюс, на дочерние интерфейсы (да и на родительский) имеются ссылки со стороны приложения.
Теперь понял. Ты сам показал еще один (даже два) недостаток делфи
В .NET и Java интерфейс — просто контракт, ссылка на интерфейс (переменная типа интнрфейс) подчиняется темже правилам, что и объекты. У интерфейсов нету никаких ссылок и считать их не надо. GC нормально разруливает любые цикличесике зависимотси.
В делфи интерфейсы обладают семантикой COM-объектов (это само по себе недостаток — номер раз). Хотя делфи и поддерживает более-менее автоматизированный подсчет ссылок, но есть задачи, в которых подсчет ссылок приходится писать руками которые иллюстрирует твоя задача (недостаток номер два).
В .NET и Java такого вообще нет из-за другой семантики интерфейсов. А при работе с .NET объектами через COM таких проблема не возникает потому что сборщик мусора нормально разруливает подобные ситуации.
H>Эта задача не высосона из пальца. Не так давно я эту ситуацию разруливал именно благодаря наличию ручного управления счетчиком ссылок. Сразу добавлю, просчета в проектировании тут нет
Коненчо не высосана из пальца. Просчет тут именно в использовании делфи.
Здравствуйте, Эдик, Вы писали:
H>>Речь об интерфейсах.
Э>Это ничего не меняет — за каждой ссылкой на интерфейс стоит объект и по ссылке на интерфейс GC доберется до объекта.
Гхм. А если этот интерфейс от нативного COM-объекта?
Здравствуйте, gandjustas, Вы писали:
H>>Я еще раз уточняю: речь идет об интерфейсах. А менять условие задачи, для подгона под ответ -- это моветон. Интерфейс-родитель не может удалить дочерние т.к. они должны быть удалены только в момент смерти самого родителя, а он не может умереть пока жив хоть один дочерний. В свою очередь, дочерние интерфейсы сами имеют ссылку на родителя. Плюс, на дочерние интерфейсы (да и на родительский) имеются ссылки со стороны приложения. G>Теперь понял. Ты сам показал еще один (даже два) недостаток делфи G>В .NET и Java интерфейс — просто контракт, ссылка на интерфейс (переменная типа интнрфейс) подчиняется темже правилам, что и объекты. У интерфейсов нету никаких ссылок и считать их не надо. GC нормально разруливает любые цикличесике зависимотси. G>В делфи интерфейсы обладают семантикой COM-объектов (это само по себе недостаток — номер раз). Хотя делфи и поддерживает более-менее автоматизированный подсчет ссылок, но есть задачи, в которых подсчет ссылок приходится писать руками которые иллюстрирует твоя задача (недостаток номер два).
Справедливости ради, ручной подсчет делается только в интерфейсе-родителе (изменяется метод Release). Мои пользователи об этом даже не подозревают и пользуются обычными приемами при работе.
G>В .NET и Java такого вообще нет из-за другой семантики интерфейсов. А при работе с .NET объектами через COM таких проблема не возникает потому что сборщик мусора нормально разруливает подобные ситуации.
Ок. Кого он убьет раньше, родителя или дочерний интерфейс? Далее. Если тебе придется работать с COM-интерфейсами и будет аналогичная ситуация, ты без подсчета ссылок усядешься в лужу.
H>>Эта задача не высосона из пальца. Не так давно я эту ситуацию разруливал именно благодаря наличию ручного управления счетчиком ссылок. Сразу добавлю, просчета в проектировании тут нет G>Коненчо не высосана из пальца. Просчет тут именно в использовании делфи.
Меня устраивает нативная среда с внятным, полуавтоматическим GC (таким, какой он есть) и развитым языком
Здравствуйте, hattab, Вы писали:
H>Гхм. А если этот интерфейс от нативного COM-объекта?
Я, честно говоря, с COM-объектами из .NET не работал, но вот что пишет Э. Троелсен («C# и платформа .NET»):
«…всю черновую работу берет на себя модуль RCW (run-time callable wrapper). Он производит кэширование всех ссылок на интерфейсы и в нужный момент производит вызов метода Release() для сервера COM, на который больше нет активных ссылок со стороны клиентов .NET. В результате клиентам .NET нет необходимости явно производить вызовы методов AddRef(), Release() или QueryInterface()».
И там же:
«…RCW создавать вручную не нужно — это произодится автоматически…»
То есть, если я правильно понял, при добавлении в проект ссылки на COM-тип автоматически создается обертка для него, которая и занимается всей черновой работой.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>В .NET и Java такого вообще нет из-за другой семантики интерфейсов. А при работе с .NET объектами через COM таких проблема не возникает потому что сборщик мусора нормально разруливает подобные ситуации. H>Ок. Кого он убьет раньше, родителя или дочерний интерфейс? Далее. Если тебе придется работать с COM-интерфейсами и будет аналогичная ситуация, ты без подсчета ссылок усядешься в лужу.
Ну это ты зря. тебе же дали ссылки на механизм работы GC. CG сам отлично справляется с такой ситуацией.
Вкратце будет так: когда родитель и дочерние объекты станут недостижимым умрут все.
H>Меня устраивает нативная среда с внятным, полуавтоматическим GC (таким, какой он есть) и развитым языком
Просто ты в других мало работал.
Когда у нас на работе пришла девушка я заставлял её писать Linq запросы вместо SQL, хотя она сильно сопростивлялась и говорила что написать JOIN на SQL гораздо легче. Ниче, через месяц привыкла, теперь даже желания не возникает SQLи писать
Здравствуйте, Эдик, Вы писали:
Э>То есть, если я правильно понял, при добавлении в проект ссылки на COM-тип автоматически создается обертка для него, которая и занимается всей черновой работой.
Вроде того.
Здравствуйте, Эдик, Вы писали:
Э>Я, честно говоря, с COM-объектами из .NET не работал, но вот что пишет Э. Троелсен («C# и платформа .NET»): Э>
Э>«…всю черновую работу берет на себя модуль RCW (run-time callable wrapper). Он производит кэширование всех ссылок на интерфейсы и в нужный момент производит вызов метода Release() для сервера COM, на который больше нет активных ссылок со стороны клиентов .NET. В результате клиентам .NET нет необходимости явно производить вызовы методов AddRef(), Release() или QueryInterface()».
Э>И там же: Э>
Э>«…RCW создавать вручную не нужно — это произодится автоматически…»
Э>То есть, если я правильно понял, при добавлении в проект ссылки на COM-тип автоматически создается обертка для него, которая и занимается всей черновой работой.
Delphi тоже сама ссылки считает Но дело в том, что взаимозависимость уже есть, по условию задачи. Т.е. два COM-интерфейса ссылаются друг на друга. Кого и главное, когда убивать?
Здравствуйте, Сергей, Вы писали:
kuj>> .NET дает более высокую производительность за счет более тонкой оптимизации под целевой процессор (компиляция из байт-кода в машинный производится непосредственно там, где он будет выполняться).
С>У JIT-компиляторов оптимизация получается неважная — потому что важно обеспечить быструю компиляцию.
Хорошо придумал. В действительности, оптимизация на очень достойном уровне. RTFM вообщем.
Здравствуйте, gandjustas, Вы писали:
G>>>В .NET и Java такого вообще нет из-за другой семантики интерфейсов. А при работе с .NET объектами через COM таких проблема не возникает потому что сборщик мусора нормально разруливает подобные ситуации. H>>Ок. Кого он убьет раньше, родителя или дочерний интерфейс? Далее. Если тебе придется работать с COM-интерфейсами и будет аналогичная ситуация, ты без подсчета ссылок усядешься в лужу. G>Ну это ты зря. тебе же дали ссылки на механизм работы GC. CG сам отлично справляется с такой ситуацией. G>Вкратце будет так: когда родитель и дочерние объекты станут недостижимым умрут все.
Кому они станут недостижимы? Родитель ссылается на дочерний, дочерний ссылается на родителя. Кого GC должен убить раньше?
H>>Меня устраивает нативная среда с внятным, полуавтоматическим GC (таким, какой он есть) и развитым языком G>Просто ты в других мало работал. G>Когда у нас на работе пришла девушка я заставлял её писать Linq запросы вместо SQL, хотя она сильно сопростивлялась и говорила что написать JOIN на SQL гораздо легче. Ниче, через месяц привыкла, теперь даже желания не возникает SQLи писать
По моему скромному мнению, расширение семантики языка в угоду прикладному посылу (это я о LINQ) -- дикий кю. На такое способна только MS. Я уже неоднократно слышал от сторонников .Net, что MS все больше и больше изгаживает C#. Просьба, за наезд не считать.
Здравствуйте, hattab, Вы писали:
H>Кому они станут недостижимы? Родитель ссылается на дочерний, дочерний ссылается на родителя. Кого GC должен убить раньше?
Ну почитай ты наконец статьи про GC. Там все написано.
Родитель ссылается на дочерний, дочерний ссылается на родителя, а на них никто не ссылвается — вот они и недостижимы. GC за один проход уберет всех. Думаешь GC настолько дурной что каждый раз проверяет все объекты в куче?
H>По моему скромному мнению, расширение семантики языка в угоду прикладному посылу (это я о LINQ) -- дикий кю. На такое способна только MS. Я уже неоднократно слышал от сторонников .Net, что MS все больше и больше изгаживает C#. Просьба, за наезд не считать.
Ну ведь можно его не использовать.
Здравствуйте, hattab, Вы писали:
H>Delphi тоже сама ссылки считает Но дело в том, что взаимозависимость уже есть, по условию задачи. Т.е. два COM-интерфейса ссылаются друг на друга. Кого и главное, когда убивать?
Вся прелесть .NET, что не нужно думать о том кого и когда убивать — все делает GC. Например:
class Parent
{
Child _child;
public Parent()
{
_child = new Child(this);
}
}
class Child
{
Parent _parent;
public Child(Parent parent)
{
_parent = parent;
}
}
class Program
{
static void Main()
{
var x = new Parent();
// Что-то делаем с x
x = null;
// Объект, на который ссылался x, стал недостижим и x._child стал недостижим.
// GC прибьет их обоих, несмотря на то, что они ссылаются друг на друга,
// т.е. GC отслеживает циклические ссылки.
}
}
Здравствуйте, hattab, Вы писали:
H>…для себя полгода назад писал расчетный (примитивный расчет с использование типов Double) бенч на C# и Delphi. Писал объективно, ибо для себя. Разница почти 2 раза в пользу Delphi…
Без исходников говорить что-либо трудно, так что про данный конкретный случай не стану ничего утверждать. Но несколько раз натыкался на тесты производительности .NET, которые были написаны некорректно. Это и использование DateTime вместо Stopwatch или QueryPerformanceCounter для замера времени, и отсутсвие холостого прогона перед запуском тестов (для того, чтобы JIT-компилятор отработал).
Здравствуйте, gandjustas, Вы писали:
H>>Кому они станут недостижимы? Родитель ссылается на дочерний, дочерний ссылается на родителя. Кого GC должен убить раньше? G>Ну почитай ты наконец статьи про GC. Там все написано. G>Родитель ссылается на дочерний, дочерний ссылается на родителя, а на них никто не ссылвается — вот они и недостижимы. GC за один проход уберет всех. Думаешь GC настолько дурной что каждый раз проверяет все объекты в куче?
Но они-то друг на друга ссылаются, как их можно убивать??? У родителя они (дочерние) лежат в списке интерфейсов, который он (родитель) должен сам в деструкторе почистить (т.е. сам отказаться от ссылки на дочерний интерфейс). А если пред очисткой он (родитель) еще и дернуть должен дочерний интерфейс для каких-либо целей? А если дочерний при смерти должен дернуть родителя? Что значит, GC за один проход уберет их всех? Он деструкторы вызывать будет?
H>>По моему скромному мнению, расширение семантики языка в угоду прикладному посылу (это я о LINQ) -- дикий кю. На такое способна только MS. Я уже неоднократно слышал от сторонников .Net, что MS все больше и больше изгаживает C#. Просьба, за наезд не считать. G>Ну ведь можно его не использовать.
Ты про C# или LINQ? Если про LINQ, то это не меняет общей оценки языка. Если про C#... Он же является основным языком .Net. Его активно развивает MS, под него (наверняка) подкраивается исполняющая среда. Везде (на .Net-форумах) только и разговоров, что о C# (изредка о VB/C++). Я для себя сразу отмел вариант, писать под .Net на ObjectPascal, ибо это будет просто глупо, в силу вышеозначеных причин. Есть Ada под .Net, но опять же считаю это не самой лучшей идеей т.к. основная поддержка со стороны MS направлена на C#.
Здравствуйте, Эдик, Вы писали:
H>>Delphi тоже сама ссылки считает Но дело в том, что взаимозависимость уже есть, по условию задачи. Т.е. два COM-интерфейса ссылаются друг на друга. Кого и главное, когда убивать?
Э>Вся прелесть .NET, что не нужно думать о том кого и когда убивать — все делает GC. Например: Э>
Э>class Parent
Э>{
Э> Child _child;
Э> public Parent()
Э> {
Э> _child = new Child(this);
Э> }
Э>}
Э>class Child
Э>{
Э> Parent _parent;
Э> public Child(Parent parent)
Э> {
Э> _parent = parent;
Э> }
Э>}
Э>class Program
Э>{
Э> static void Main()
Э> {
Э> var x = new Parent();
Э> // Что-то делаем с x
Э> x = null;
Э> // Объект, на который ссылался x, стал недостижим и x._child стал недостижим.
Э> // GC прибьет их обоих, несмотря на то, что они ссылаются друг на друга,
Э> // т.е. GC отслеживает циклические ссылки.
Э> }
Э>}
Э>
Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release).
Здравствуйте, hattab, Вы писали:
H>>>Кому они станут недостижимы? Родитель ссылается на дочерний, дочерний ссылается на родителя. Кого GC должен убить раньше? G>>Ну почитай ты наконец статьи про GC. Там все написано. G>>Родитель ссылается на дочерний, дочерний ссылается на родителя, а на них никто не ссылвается — вот они и недостижимы. GC за один проход уберет всех. Думаешь GC настолько дурной что каждый раз проверяет все объекты в куче?
H>Но они-то друг на друга ссылаются, как их можно убивать???
Еще одно доказательство того, что Delphi отупляет. Как их можно удалять, если на них никто не ссылается — ответ: молча!
Здравствуйте, Эдик, Вы писали:
Э>Это и использование DateTime вместо Stopwatch или QueryPerformanceCounter для замера времени,
Я например использую DateTime вместо Stopwatch или QueryPerformanceCounter.
Знаешь почему?
По тому что QueryPerformanceCounter (на котором работает Stopwatch) на некоторых процессорах (в частности на моем) глючит.
Как вариант еще можно повозиться с timeGetTime.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Эдик, Вы писали:
H>>…для себя полгода назад писал расчетный (примитивный расчет с использование типов Double) бенч на C# и Delphi. Писал объективно, ибо для себя. Разница почти 2 раза в пользу Delphi…
Э>Без исходников говорить что-либо трудно, так что про данный конкретный случай не стану ничего утверждать. Но несколько раз натыкался на тесты производительности .NET, которые были написаны некорректно. Это и использование DateTime вместо Stopwatch или QueryPerformanceCounter для замера времени, и отсутсвие холостого прогона перед запуском тестов (для того, чтобы JIT-компилятор отработал).
Я не буду меряться органами Мой бенчь (а я реально рассматривал перспективу перехода под .Net) был очень прост: в цикле (100.000.000) выполнялись несложные расчеты (основные операции +,-,/,*). Время замерялось именно Stopwatch, под Delphi перф-коунтером. Все лишнее выгружалось. Частота устанавливалась на максимум (у меня бука) без возможности тротлинга. Делалось несколько прогонов, как одного бенча так и другого. Потом откидывались лучшие и худшие результаты и бралось среднее значение. По этому бенчу я не оценивал общую производительность .Net. Померял только то, что померял.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Кому они станут недостижимы? Родитель ссылается на дочерний, дочерний ссылается на родителя. Кого GC должен убить раньше? G>>Ну почитай ты наконец статьи про GC. Там все написано. G>>Родитель ссылается на дочерний, дочерний ссылается на родителя, а на них никто не ссылвается — вот они и недостижимы. GC за один проход уберет всех. Думаешь GC настолько дурной что каждый раз проверяет все объекты в куче?
H>Но они-то друг на друга ссылаются, как их можно убивать??? У родителя они (дочерние) лежат в списке интерфейсов, который он (родитель) должен сам в деструкторе почистить (т.е. сам отказаться от ссылки на дочерний интерфейс). А если пред очисткой он (родитель) еще и дернуть должен дочерний интерфейс для каких-либо целей? А если дочерний при смерти должен дернуть родителя? Что значит, GC за один проход уберет их всех? Он деструкторы вызывать будет?
Если у объектов есть финализаторы, то они еще некоторое время проживут. Сначала выполнятся финализаторы для всех, а только на следующем проходе их GC уберет все объекты.
Ну что ты как дите. Пытаешься доказать что не работет что-то, что другие использут каждый день. Лучше бы изучением вопроса занялся вместо задавания таких вопросов.
Здравствуйте, hattab, Вы писали:
H>Я не буду меряться органами Мой бенчь (а я реально рассматривал перспективу перехода под .Net) был очень прост: в цикле (100.000.000) выполнялись несложные расчеты (основные операции +,-,/,*). Время замерялось именно Stopwatch, под Delphi перф-коунтером. Все лишнее выгружалось. Частота устанавливалась на максимум (у меня бука) без возможности тротлинга. Делалось несколько прогонов, как одного бенча так и другого. Потом откидывались лучшие и худшие результаты и бралось среднее значение. По этому бенчу я не оценивал общую производительность .Net. Померял только то, что померял.
У тебя в пограмме такие серьезные вычисления, что требуется нереальное быстродействие?
Тогда можен написать отдельную библиотеку на асме и для всего остального юзать C# ?
Здравствуйте, hattab, Вы писали:
H>Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release).
Если говорить о COM, то он базируется на подсчете ссылок, это одна из его основ. А у подсчета ссылок есть ограничение — он не может корректно работать с циклическими зависимостями. Так что тут проблема не в технологии, а в дизайне конкретного приложения — в дизайне не учтены ограничения технологии и приходится их нарушать.
Здравствуйте, hattab, Вы писали: H>Хотя в Delphi интерфейсы могут иметь не только COM-объекты.
Так Вы когда говорили
Для интерфейсов существует только один способ GC -- подсчет ссылок.
Вы какие интерфейсы имели в виду? Если COM-интерфейсы (технический аспект) — это одно. Если, скажем так, ООП-интерфейсы (теоретический аспект) — то Вы абсолютно не правы. Рекомендую Вам все же почитать про то, как реализуется сборка мусора в java или .NET (ссылки Вам уже дали).
В Вашем случае с деревом объектов GC сможет выявить, что дерево целиком недоступно — это раз. Далее он в неопределенном порядке выполнит финализаторы объектов, а потом и освободит память. Соответственно, в финализаторах родители и потомки никак не взаимодействуют.
Можете сколько угодно критиковать такую схему, но она реально работает ака успешно применяется (и без всякого Вашего подсчета ссылок).
Здравствуйте, WolfHound, Вы писали:
H>>Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release). WH>А зачем нам COM-интерфейсы?
Здравствуйте, gandjustas, Вы писали:
H>>>>Кому они станут недостижимы? Родитель ссылается на дочерний, дочерний ссылается на родителя. Кого GC должен убить раньше? G>>>Ну почитай ты наконец статьи про GC. Там все написано. G>>>Родитель ссылается на дочерний, дочерний ссылается на родителя, а на них никто не ссылвается — вот они и недостижимы. GC за один проход уберет всех. Думаешь GC настолько дурной что каждый раз проверяет все объекты в куче?
H>>Но они-то друг на друга ссылаются, как их можно убивать??? У родителя они (дочерние) лежат в списке интерфейсов, который он (родитель) должен сам в деструкторе почистить (т.е. сам отказаться от ссылки на дочерний интерфейс). А если пред очисткой он (родитель) еще и дернуть должен дочерний интерфейс для каких-либо целей? А если дочерний при смерти должен дернуть родителя? Что значит, GC за один проход уберет их всех? Он деструкторы вызывать будет?
G>Если у объектов есть финализаторы, то они еще некоторое время проживут. Сначала выполнятся финализаторы для всех, а только на следующем проходе их GC уберет все объекты.
Есть гарантия, что финализатор родителя выполнится последним?
G>Ну что ты как дите. Пытаешься доказать что не работет что-то, что другие использут каждый день. Лучше бы изучением вопроса занялся вместо задавания таких вопросов.
Я не пытаюсь ни кому и ничего доказывать. Я описываю реальную задачу и пытаюсь разобраться, как оно сможет быть решено под .Net.
Здравствуйте, gandjustas, Вы писали:
H>>Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release).
G>Еще раз, запомни простую вещь: в .NET нету разницы между COM и не-COM
Ок. У .Net-интерфейсов есть механизм подсчета ссылок? И почему мне Mr.Cat говорил, что не в курсе, как устроен GC для COM-интерфейсов? Есть какое-то различие? Просвети.
Здравствуйте, gandjustas, Вы писали:
H>>Я не буду меряться органами Мой бенчь (а я реально рассматривал перспективу перехода под .Net) был очень прост: в цикле (100.000.000) выполнялись несложные расчеты (основные операции +,-,/,*). Время замерялось именно Stopwatch, под Delphi перф-коунтером. Все лишнее выгружалось. Частота устанавливалась на максимум (у меня бука) без возможности тротлинга. Делалось несколько прогонов, как одного бенча так и другого. Потом откидывались лучшие и худшие результаты и бралось среднее значение. По этому бенчу я не оценивал общую производительность .Net. Померял только то, что померял.
G>У тебя в пограмме такие серьезные вычисления, что требуется нереальное быстродействие?
Мне нужно было сравнить -- я сравнил.
G>Тогда можен написать отдельную библиотеку на асме и для всего остального юзать C# ?
Здравствуйте, Эдик, Вы писали:
H>>Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release).
Э>Если говорить о COM, то он базируется на подсчете ссылок, это одна из его основ. А у подсчета ссылок есть ограничение — он не может корректно работать с циклическими зависимостями.
Автоматически разумеется не может. Но для этого есть возможность ручного управления.
Э> Так что тут проблема не в технологии, а в дизайне конкретного приложения — в дизайне не учтены ограничения технологии и приходится их нарушать.
При возможности ручного управления это не ограничения. Я решил задачу переписав метод Release родительского интерфейса.
Здравствуйте, Mr.Cat, Вы писали:
H>>Хотя в Delphi интерфейсы могут иметь не только COM-объекты.
MC>Так Вы когда говорили MC>
MC>Для интерфейсов существует только один способ GC -- подсчет ссылок.
MC>Вы какие интерфейсы имели в виду? Если COM-интерфейсы (технический аспект) — это одно. Если, скажем так, ООП-интерфейсы (теоретический аспект) — то Вы абсолютно не правы. Рекомендую Вам все же почитать про то, как реализуется сборка мусора в java или .NET (ссылки Вам уже дали).
Я читал, спасибо. И раньше еще читал В нативной Delphi тип интерфейсов один -- COM, как вы его называете. Их я и имел ввиду.
MC>В Вашем случае с деревом объектов GC сможет выявить, что дерево целиком недоступно — это раз. Далее он в неопределенном порядке выполнит финализаторы объектов, а потом и освободит память. Соответственно, в финализаторах родители и потомки никак не взаимодействуют.
Вот (неопределенный порядок, невозможность взаимодействия в финализаторах). Значит тут, и таким способом, задачу не решить. Не смертельно, конечно, но не сильно приятно.
MC>Можете сколько угодно критиковать такую схему, но она реально работает ака успешно применяется (и без всякого Вашего подсчета ссылок).
Я еще раз говорю: .Net критиковать не собираюсь. Живите, как умеете Спасибо за развернутый ответ
Здравствуйте, hattab, Вы писали:
H>Если люди чего-то там не знали/забывали, это характеризует только их, но не инструмент. Если выражаться простым языком: не можешь срать -- не мучай жопу. В управляемых средах, таки, есть место ручной очистке (пусть даже семантически скрываемой) для объектов владеющих ресурсами. Что начнется, когда
В оригинале вобще-то звучит вобще-то "не хочешь срать — не мучай жопу". Разница существенная. В дальнейшем просьба быть точнее, а то минусы буду ставить нещадно!
Здравствуйте, hattab, Вы писали:
MC>>>>Речь не о SOAP-сервисах, а о создании веб-морд. Т.е. упрощенно — когда есть HTML-шаблоны и java/.net код, который на их основе хитро генерит динамические страницы. Ну, короче, как в php.
H>>>WebSnap. Ребята, оно было еще в 6 версии. Intraweb еще круче
Ну вот здесь говришь...
kuj>>Хочу полноценный MVC с unit test`ами и расширяемым view-engine по типу Brail (из Castle Monorail)! Где?
H>Я не занимаюсь вебом, ничего сказать не могу.
Здравствуйте, hattab, Вы писали:
H>>>>>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы
kuj>>>>Угу, пропал exe-шник — отвалилась голова.
H>>>У тебя конфиги ни разу не слетали? Если у меня слетит конфиг, моя прилага не забудет как по XML-RPC разговаривать
kuj>>Не знаю как оно в Делфи, но в .NET и Java конфиги не имеют такой привычки — куда-то там слетать...
H>И юзеры с админами ну прям небожители. Охотно верю.
Ну так какое отношение .Net имеет к админам? Если уж ты такой любитель народных поговорок (впрочем как и я): с дуру можно и х.. сломать"
Здравствуйте, hattab, Вы писали:
ДГ>>Гы. Это был аргумент из серии "я вот тут комп с десятого этажа уронил, теперь он гад загружаться не хочет". Догадываешься, что случится, если в линухе все конфиги пропадут? Конфиги — такие же файлы, как и екзешники.
H>Какое мне дело до Линукса? Ни одного юзера не допрет править руками exe'шник, а конфиг за милу душу. Но если тебе приятно не замечать проблемы, чтож, хозяин -- барин.
Здравствуйте, hattab, Вы писали:
kuj>>FxCop поможет... И не только с этой проблемой, кстати.
H>Я знаю, что такое FxCop У Борланда давно уже был CodeGuadr для C++ (задачи примерно те же).
Бгга Я наелся дерьма C++ Builder даже не считая CodeGuard-а еще 5 лет назад. Ф топку .
До сих пор помню такой замечательный глюк CodeGuard-a: компилирую проект, в рантайме летит ошибка на ровном месте, я меняю местами объявления шаблонрв класса в исходном файле — все работает нормально. После этого отказался от CodeGuard-а, через некоторое время понял, что глюкавый компилятор тоже меня не устравает. Начинал я вообще с Turbo C++ 1.0.
Про Дельфи не скажу, но от поделий Богланд меня что-то воротит. Может вспомним еще угробище под названием Interbase?
Здравствуйте, OCTAGRAM, Вы писали:
OCT>TheEvilOne пишет: >> Как так не хакерская? Некоторые особо одаренные люди пишут на дельфях не >> только драйвера уровня ядра для виндовс ХР, но и вирусы >> различные OCT>Встречал один раз вирус на Visual Basic. Он мониторил открытые папки, и OCT>эвакуировал себя в другую папку, как только там появлялся пользователь. OCT>Т. е. заходишь ФАРом в WINDOWS/HELP, в листинге он есть, но на самом OCT>деле он уже WINDOWS/INF, заходишь в WINDOWS/INF, а он уже в OCT>WINDOWS/ещё–что–нибудь. При этом меняет запись в реестре для своей OCT>автозагрузки. А если ключ автозагрузки убрать, то добавляет его через OCT>полминуты.
OCT>Не руткит, но всё равно занятная поделка.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, kuj, Вы писали:
L>>>Нет, я топики не ношу. Максимум — майки.
kuj>>А минимум топлес?
L>Не, минимум — это еще и даунлесс.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали: G>>Если у объектов есть финализаторы, то они еще некоторое время проживут. Сначала выполнятся финализаторы для всех, а только на следующем проходе их GC уберет все объекты.
H>Есть гарантия, что финализатор родителя выполнится последним?
Нет, а оно вам надо?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release).
G>>Еще раз, запомни простую вещь: в .NET нету разницы между COM и не-COM
H>Ок. У .Net-интерфейсов есть механизм подсчета ссылок? И почему мне Mr.Cat говорил, что не в курсе, как устроен GC для COM-интерфейсов? Есть какое-то различие? Просвети.
Нет различий.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mr.Cat, Вы писали:
MC>>В Вашем случае с деревом объектов GC сможет выявить, что дерево целиком недоступно — это раз. Далее он в неопределенном порядке выполнит финализаторы объектов, а потом и освободит память. Соответственно, в финализаторах родители и потомки никак не взаимодействуют. H>Вот (неопределенный порядок, невозможность взаимодействия в финализаторах). Значит тут, и таким способом, задачу не решить. Не смертельно, конечно, но не сильно приятно.
Теперь приведи 3 причины почему финализаторы должны ввыполняться в определенном порядке.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, gandjustas, Вы писали:
G>>>>1)Свойства kuj>>>Java get/set G>>Это не свойства
kuj>Как это не свойства, а что это?
Это пара случайно обозванных методов. На всякий случай напомню, что свойства в дельфи и в дотнете проверяет компилятор, так что невозможно допустить опечатку в имени или поменять тип свойства несогласованным образом. Также на всякий случай напомню, что свойства в дельфи и дотнете хранят свои метаданные, независимые от методов, которыми свойства реализованы. Ничего похожего на свойства в джаве нет.
kuj>(далекий 1996 год) kuj>http://java.sys-con.com/read/49097.htm
На всякий случай напомню, что в дельфи и дотнете делегаты контролируются компилятором и средой исполнения, так что, к примеру, невозможно положить в делегат ссылку на метод с неподходящей сигнатурой. В предлагаемом примере выполняется late binding, который никак не контролируется компилятором. Кроме того, приходится вручную даункастить результат вызова "делегата". Так что, ничего похожего на делегаты в джаве нет.
kuj>>>В C# гораздо больше взято от Java, чем от Object Pascal.
Смею предположить, что сие утверждение просто говорит о том, что ты плохо знаешь Object Pascal, и хорошо — Java.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kuj, Вы писали:
kuj>В действительности вышеописанных граблей ни в одной нормальной среде разработки быть не должно.
kuj>Конечно определенные грабли есть везде — где-то меньше, где-то больше. Регулярно пользуюсь VS 2005, VS 2008, пару лет тому назад еще IntelliJ IDEA в арсенале была. Все отлично — на грабли натыкаться не приходиться, работать одно удовольствие.
Да есть тоже немножко. Сейчас пользуем VS 2005 SP1:
— Если попробовать в док. комментариях добавить для достаточно большого файла
/// <summary>
/// asda
/// </summary>
/// <param name="dsda"> asas /</param>
вот например в этом месте попытаться напечатать слэш — студия виснет.
— До SP1 одолевал WinForms дизайнер — открываешь допустим свой контрол, а на нем кнопки съехали. Ну это уже не в счет.
— WinForms дизайнер — шрифты в дизайнере могут оказаться другого размера, чем на реальной форме.
— Есть проблемы с дизайнером ReportViewer-а — преобразование единиц измерения, например мм-см, и прочие мелочи типа неверного преобразования margins страницы — это самое неприятное.
Это все, на что наткнулся лично я. Но все это мелочи. А работать и правда одно удовольствие.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, DOOM, Вы писали:
DOO>>2. Delphi иногда очень сильно обходит других CC>Насколько я помню все преимущества дельфи заключались в том, что аллокатор памяти в дельфином рантайме был написан с упором на быструю аллокацию.
В общем-то пора бы уже наверное перечитать эту статью, но еще по-моему Дельфи на каких-то тестах с деревом объектов рулил.
L>Ну и надо всё время проверять, что в этом месте процедуры этот tmp ещё нужен, а чуть ниже по тексту уже нет.
Неужели это такая проблема помнить свои переменные в рамках одной синтаксической конструкции?
Попиши на асме какое-то время — дисциплина подтянется
L>>>>>Во-вторых — оно в каких случаях нужно-то? DOO>>>>Что конкретно? Понять, что это перегруженный оператор? Это нужно когда читаешь/модифицируешь чужой код. L>>>Писать в каких слуаях это нужно: когда нужно явно вызывать неявное приведение типов? DOO>>Ты о чем? О том примере — это было так, что ввспомнилось из смутного прошлого. В общем и целом перегрузка операторов делает код write only. DOO>>P.S. А я еще и ООП в целом не люблю
L>Ну так написать везде можно так, что потом 100 лет не расхлебаешь.
В общем случае программа написанная на контекстно свободном языке читается легче (человеку банально сложно искать границы контекстов и учитывать их при чтении, лучше, чтобы все нужные данные были здесь и сейчас) — таким образом стандартная процедурная программа на голом C читается элементарно, а навороченная вся из себя шалонно-объектная на C++ вообще никак не читается — тебе надо всегда куда-то отматывать, много всего держать в голове и т.д.
Кстати, Дельфийские программы читались очень неплохо, правда с очень большой помощью IDE, которая безошибочно (в отличие от VS 6.0) определяла, что
это за функция или метод объекта.
L>Одну. От Борланда. Вы назовёте ту, где есть препроцессор?
Еще раз — я могу использовать внешний препроцессор. Меня же не ломает писать программки на C в Vim'е и собирать их make'ом с gcc
DOO>>А теперь замени на ABigComplexData на ABigComplexData * — и пойми, что в Дельфи объект это всегда указатель на объект.
L>Ну и что в этом хорошего? Кстати, kuj про shared/scoped_ptr не зря вспомнил. В дельфи как их реализовать?
Никак
Чтобы язык был простым от чего-то надо отказываться.
Этих shared/scoped_ptr нет, например, и в Javascript, но это не мешает последнему занимать свою нишу...
DOO>>>>Шаблоны — на вкус и цвет. Мне они как-то не нравились в свое время. L>>>Ну хорошо, вопрос в лоб — нужен список элементов T, которые мы только что придумали. Аналог std::list<T> какой? DOO>>Tlist, потому что все классы наследники TObject. Сейчас ты мне скажешь, что мне компилятор ни фига не проверит, что в моем TList'е все объекти одного класса, но я, сильно поднатужившись, приведу тебе примеры, какую динамику это дает — просто программер на C++ с шаблонами не мыслит о своей программе как о чем-то меняющемся во время выполнения.
L>Это дает лишний уровень косвенности, хранятся-то там тогда не объекты, а указатели на них. На маленьких по размеру теряем, это ж каждый раз надо из кучи дергать по несколько байт.
Можно это даже не комментировать? Обсуждая таких монстров экономить по паре байт...
L>Но намного важнее то, что в реальных задачах нужны списки чего-то, а не всего чего угодно. В С++ с шаблонами за этим следит компилятор и дает по рукам при попытке это нарушить. Кроме того не надо делать лишних и опасных движений, вроде приведения типов. При этом в С++ не запрещено выделить некоторую сущность и хранить список [умных] указателей на неё, приводя по мере надобности. Гибкость есть. И свобода выбора.
Это зависит от архитектуры — еще раз, я в свое время убедился насколько различны подходы в проектировании у дельфиста и C++'ника — дельфист пишет динамическую программу, а C++'ник статическую, поэтому для тебя строгая типизация — преимущество, для дельфиста — ограничение.
А вся твоя пресловутая свобода выбора в C++ сильно ограничивается поддержкой со стороны IDE.
DOO>>>>Про оптимизатор на уровне Intel C++ — ну и сколько процентов народу используют этот компилятор? А у остальных тоже не такие уж выдающиеся результаты по сравнению с ним.
L>>>А фокус в том, что он есть. И если нужно — можно использовать. А в дельфи — нужно, не нужно, а про качественную машинную оптимизацию можно забыть.
Фокус в том, что то же ядро линукса я, например, Intel C++ так запросто не соберу (когда-то, кстати, были патчи позволявшие сделать это...) — у серьезных проектов один фиг есть привязка к конкретным фичам компилятора.
kuj>Ты не понял. Во-первых, в C++ можно и std::list< void * >, во-вторых, это дает не гибкость, а широкое поле для ошибок и проблем с приведением типов.
И снова мы упираемся в различные подходы — для тебя программа во время выполнения статична, для дельфиста — нет.
kuj>И конечно же негативно сказывается на производительности.
Это почему? Потому что надо будет поддержку RTTI включить? Ну в дельфи ее просто не выключить
Здравствуйте, WolfHound, Вы писали:
WH>Но даже на том что есть можно творить очень веселые и иногда даже практичные вещи.
Это, как правило, не есть тезис в пользу промышленного языка
У нас один преподаватель в университете про языки с очень большим числом степеней свободы говорил, что это миры: мир ассемблера, мир перла и т.п. Изучать эти миры можно хоть всю жизнь, но суровая действительность требует практических скучных решений
H>>В Delphi их тоже нет. То что обсуждалось с DX, это ни какая не проблема. Это нарушений правил языка. G>В C# не надо таких правил даже знать не надо. Просто нет особенностей работы с COM.
Интересно, пишущих на басике всегда чморили за то, что они ни фига ни в чем не понимают, но пишут — а теперь это уже плюсом стало... Любое незнание раон или поздно вылезет тебе боком.
H>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов.
Угу... А какие протоколы обмена используются? А какие порты? А как там с безопасностью?
H>>Не SQL'ем единым, как говорится. Применение Delphi не ограничивается мордами к БД. G>Морда к БД — как раз основное применение делфи. Сложную логику там реализовывать напряжно. G>Работа с БД — одна из основных частей бизнес-приложений. Это чуть ли не самый большой рынок сейчас.
G>1)SAX и DOM рядом не валялись новой билиотекой по работе XML в .NET 3.5
На вкус и цвет фломастеры разные. Как ты будешь писать Jabber сервер, используя DOM?
G>// Client.cs
G>using System;
G>using System.Runtime.Remoting;
G>using TestObject;
G>namespace Client
G>{
G> class Client
G> {
G> [STAThread]
G> static void Main(string[] args)
G> {
G> RemotingConfiguration.Configure("Client.exe.config");
G> Test test = new Test();
G> Console.WriteLine(test.GetAppName()); //Здесь test.GetAppName() вызовется на сервере!!!!
G> }
G> }
G>}
G>
G>Такое на делфи возможно?
Такое возможно даже на VBScript. DCOM называется. Вот только вся твоя красота может быть (да точно будет!) обломана настройками безопасности. Ты хоть сможешь это корректно обработать?
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, lifrsdn, Вы писали:
L>>Ну и что в этом хорошего? Кстати, kuj про shared/scoped_ptr не зря вспомнил. В дельфи как их реализовать? DOO>Никак DOO>Чтобы язык был простым от чего-то надо отказываться. DOO>Этих shared/scoped_ptr нет, например, и в Javascript, но это не мешает последнему занимать свою нишу...
В Javascript есть GC. Там поинтеры вообще не нужны. А в делфи нет.
Короче -1
G>>// Client.cs
G>>using System;
G>>using System.Runtime.Remoting;
G>>using TestObject;
G>>namespace Client
G>>{
G>> class Client
G>> {
G>> [STAThread]
G>> static void Main(string[] args)
G>> {
G>> RemotingConfiguration.Configure("Client.exe.config");
G>> Test test = new Test();
G>> Console.WriteLine(test.GetAppName()); //Здесь test.GetAppName() вызовется на сервере!!!!
G>> }
G>> }
G>>}
G>>
G>>Такое на делфи возможно? DOO>Такое возможно даже на VBScript. DCOM называется.
Какие еще языки поддерживают такуюже легкость работы с COM? Что-то мне кажется что никакие.
Если попробовать написать подобное с DCOM на С++ или Delphi, то получится в разы больше кода, не считая автогенерных Proxy и Stub.
А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие)
DOO>Вот только вся твоя красота может быть (да точно будет!) обломана настройками безопасности. Ты хоть сможешь это корректно обработать?
Remoting можно настроить чтобы он работал через HTTP c помощью SOAP. Все это в конфиге, как на клиенте, так и на сервере
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
H>>>В Delphi их тоже нет. То что обсуждалось с DX, это ни какая не проблема. Это нарушений правил языка. G>>В C# не надо таких правил даже знать не надо. Просто нет особенностей работы с COM. DOO>Интересно, пишущих на басике всегда чморили за то, что они ни фига ни в чем не понимают, но пишут — а теперь это уже плюсом стало... Любое незнание раон или поздно вылезет тебе боком.
А может все-такие "чморили" за результат? (Лично я всегда им завидовал. То что они берут и делают не заморачиваясь всякой ерундой.) Если язык позволяет получать качественный результат без знания чего-то то это языку определенно в плюс.
H>>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов. DOO>Угу... А какие протоколы обмена используются? А какие порты? А как там с безопасностью?
Здравствуйте, _d_m_, Вы писали:
___>Неа. Только не стоит забывать, что JIT компилятор работает с байт кодом, а не с исходниками. Яволь?
Вот смотри: у нас есть обычный компилятор и JIT. У первого — времени столько, сколько понадобится, никаких ограничений не накладывается.
У второго — ограничение на время генерации машинного кода. При прочих равных, у первого больше возможностей породить более оптимизированный код.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, DOOM, Вы писали:
DOO>>Такое возможно даже на VBScript. DCOM называется. G>Какие еще языки поддерживают такуюже легкость работы с COM? Что-то мне кажется что никакие.
Да почему — в Дельфях можно было подрубать те же IDispatch'и и превращать программу в какое-то подобие скрипта... Абсолютно аналогично VBScript'у.
G>Если попробовать написать подобное с DCOM на С++ или Delphi, то получится в разы больше кода, не считая автогенерных Proxy и Stub. G>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие)
В Дельфи можно было этого избежать.
DOO>>Вот только вся твоя красота может быть (да точно будет!) обломана настройками безопасности. Ты хоть сможешь это корректно обработать? G>Remoting можно настроить чтобы он работал через HTTP c помощью SOAP. Все это в конфиге, как на клиенте, так и на сервере
Вопрос даже не в протоколе передачи — вопрос в настройках безопасности для сборок .Net, в настройках DCOM на целевом компьютере (ну тут стоит отметить, даже MS'овский софт не способен адекватно обработать ситуацию с кривыми правами на DCOM).
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>В C# не надо таких правил даже знать не надо. Просто нет особенностей работы с COM. DOO>Интересно, пишущих на басике всегда чморили за то, что они ни фига ни в чем не понимают, но пишут — а теперь это уже плюсом стало... Любое незнание раон или поздно вылезет тебе боком.
Во-первых .NET и С# позволяет решать гораздо больший круг задач чем вбасик. Во-вторых интероп на .NET гораздо проще. В-третьих С# полноценный ОО-язык, в отличие от VB 6.0.
Может в .NET незнание и вылезкт боком, но гораздо позже, чем в VB. А за это время программист сможет изучить все что надо.
H>>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов. DOO>Угу... А какие протоколы обмена используются? А какие порты? А как там с безопасностью?
Читайте доки, все в конфигах указывается.
Если мало вожможностей Remoting, то используйте WCF, там очень много всего поддерживается. Только модель программирования там менее лаконичная.
G>>1)SAX и DOM рядом не валялись новой билиотекой по работе XML в .NET 3.5 DOO>На вкус и цвет фломастеры разные. Как ты будешь писать Jabber сервер, используя DOM?
Когда мне понадобится Jabber сервер я найду готовую реализацию на .NET
КБ>А может все-такие "чморили" за результат?
Может. Но когда ты связан по рукам и ногам и должен идти единственно верной дорогой — результат и начинает хромать (ты не всегда понимаешь эту верную дорогу и начинаешь выдумывать какие-то жуткие костыли). К слову сказать, мне как-то приходилось пописывать на VB приложения для Access'а — ощущение, что тебя заперли в комнате со стенами обитыми матрасами, по другому не назвать.
H>>>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>>>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>>>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов. DOO>>Угу... А какие протоколы обмена используются? А какие порты? А как там с безопасностью?
КБ>А как в конфиге напишешь так и будет
Только подавляющее большинство пользователей этого Remoting'а даже не подозревают про существование этого конфига?
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, DOOM, Вы писали:
DOO>>>Такое возможно даже на VBScript. DCOM называется. G>>Какие еще языки поддерживают такуюже легкость работы с COM? Что-то мне кажется что никакие. DOO>Да почему — в Дельфях можно было подрубать те же IDispatch'и и превращать программу в какое-то подобие скрипта... Абсолютно аналогично VBScript'у.
И получать Runtime error на коде, который выглядит как обычный статический.
G>>Если попробовать написать подобное с DCOM на С++ или Delphi, то получится в разы больше кода, не считая автогенерных Proxy и Stub. G>>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие) DOO>В Дельфи можно было этого избежать.
Ну да, использовать простые типы
DOO>>>Вот только вся твоя красота может быть (да точно будет!) обломана настройками безопасности. Ты хоть сможешь это корректно обработать? G>>Remoting можно настроить чтобы он работал через HTTP c помощью SOAP. Все это в конфиге, как на клиенте, так и на сервере DOO>Вопрос даже не в протоколе передачи — вопрос в настройках безопасности для сборок .Net, в настройках DCOM на целевом компьютере (ну тут стоит отметить, даже MS'овский софт не способен адекватно обработать ситуацию с кривыми правами на DCOM).
Remoting вообще не использует DCOM. Для сборок на компе по-умолчанию FullTrust. При работе через 80 порт по протоколу HTTP все будет пучком.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, Константин Б., Вы писали:
КБ>>А может все-такие "чморили" за результат? DOO>Может. Но когда ты связан по рукам и ногам и должен идти единственно верной дорогой — результат и начинает хромать (ты не всегда понимаешь эту верную дорогу и начинаешь выдумывать какие-то жуткие костыли). К слову сказать, мне как-то приходилось пописывать на VB приложения для Access'а — ощущение, что тебя заперли в комнате со стенами обитыми матрасами, по другому не назвать.
Ну на C# такого ощущения нет.
H>>>>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>>>>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>>>>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов. DOO>>>Угу... А какие протоколы обмена используются? А какие порты? А как там с безопасностью?
КБ>>А как в конфиге напишешь так и будет DOO>Только подавляющее большинство пользователей этого Remoting'а даже не подозревают про существование этого конфига?
А им и не надо. Ты видел хоть раз чтобы пользователи распределенного приложения сами правили конфиги (про линукс молчать, там другого пути нет)?
Тем более никто не мешает написать красивый графический конфигуратор.
Если ты имеешь ввиду программситов, которые используют распределенные объекты, то им незнание не мешает. Достаточно чтобы один программист знал это написать.
G>Remoting вообще не использует DCOM.
Что бы он там не использовал, но у меня все равно должен быть инструмент, который скажет — вот эту бяку запускать только локлаьно и только админом, эту вообще не запускать и т.п.
G>Для сборок на компе по-умолчанию FullTrust.
Настройки по умолчанию это неинтересно. Надо знать какие конкретно права необходимы сборке локально и удаленно, чтобы remoting работал как надо. Иначе будут непонятки (сменятся умолчания с выходом очередного SP и все — приехали).
Вообще проблема не надумана — после установки ISA Server 2004 SP2 на W2k3 SP1 R2 некоторые инструменты администрирования MS перестают работать (например, настройка NLB кластера) — в чем конкретно проблема
G>При работе через 80 порт по протоколу HTTP все будет пучком.
А MS RPC тоже частенько работает только по 445-му порту (ну или 139-му), но это не значит, что нет грамотных МЭ, которые не отсекут конкретный интерфейс...
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>Remoting вообще не использует DCOM. DOO>Что бы он там не использовал, но у меня все равно должен быть инструмент, который скажет — вот эту бяку запускать только локлаьно и только админом, эту вообще не запускать и т.п.
Есть такое.
G>>Для сборок на компе по-умолчанию FullTrust. DOO>Настройки по умолчанию это неинтересно. Надо знать какие конкретно права необходимы сборке локально и удаленно, чтобы remoting работал как надо. Иначе будут непонятки (сменятся умолчания с выходом очередного SP и все — приехали).
В MSDN все это есть. Если не хватает каких-то прав, то .NET очень адекватно выругается с указанием чего конкретно не хватает.
DOO>Вообще проблема не надумана — после установки ISA Server 2004 SP2 на W2k3 SP1 R2 некоторые инструменты администрирования MS перестают работать (например, настройка NLB кластера) — в чем конкретно проблема
Причем здесь .NET и языки?
G>>При работе через 80 порт по протоколу HTTP все будет пучком. DOO> DOO>А MS RPC тоже частенько работает только по 445-му порту (ну или 139-му), но это не значит, что нет грамотных МЭ, которые не отсекут конкретный интерфейс...
Товарищ, 80 порт открыт на 99,9% машин. По умолчанию все фаерволы оставляют 80 порт открытым.
Здравствуйте, gandjustas, Вы писали:
G>В MSDN все это есть. Если не хватает каких-то прав, то .NET очень адекватно выругается с указанием чего конкретно не хватает.
Хотелось бы верить.
DOO>>Вообще проблема не надумана — после установки ISA Server 2004 SP2 на W2k3 SP1 R2 некоторые инструменты администрирования MS перестают работать (например, настройка NLB кластера) — в чем конкретно проблема G>Причем здесь .NET и языки?
Это демонстрация. Пусть тут DCOM и RPC — но смысл в том же. Все это хорошо работает, пока не пытаешься что-то поменять.
DOO>>А MS RPC тоже частенько работает только по 445-му порту (ну или 139-му), но это не значит, что нет грамотных МЭ, которые не отсекут конкретный интерфейс... G>Товарищ, 80 порт открыт на 99,9% машин. По умолчанию все фаерволы оставляют 80 порт открытым.
Товарищ, открытый порт еще ничего не значит. Давно уже все используют МЭ прикладного уровня, особенно для Web-трафика. Я тебе специально в пример привел RPC — на ISA сервере я могу перекрыть конкретные RPC интерфейсы, даже если используется транспорт nc_acn_named_pipes — который гуляет поверх SMB, т.е. 445-го или 139-го порта.
Здравствуйте, DOOM, Вы писали:
DOO>>>А MS RPC тоже частенько работает только по 445-му порту (ну или 139-му), но это не значит, что нет грамотных МЭ, которые не отсекут конкретный интерфейс... G>>Товарищ, 80 порт открыт на 99,9% машин. По умолчанию все фаерволы оставляют 80 порт открытым. DOO>Товарищ, открытый порт еще ничего не значит. Давно уже все используют МЭ прикладного уровня, особенно для Web-трафика. Я тебе специально в пример привел RPC — на ISA сервере я могу перекрыть конкретные RPC интерфейсы, даже если используется транспорт nc_acn_named_pipes — который гуляет поверх SMB, т.е. 445-го или 139-го порта.
Это из тойже оперы что поудалять конфиги,а потом жаловаться на .NET.
Здравствуйте, gandjustas, Вы писали:
DOO>>Товарищ, открытый порт еще ничего не значит. Давно уже все используют МЭ прикладного уровня, особенно для Web-трафика. Я тебе специально в пример привел RPC — на ISA сервере я могу перекрыть конкретные RPC интерфейсы, даже если используется транспорт nc_acn_named_pipes — который гуляет поверх SMB, т.е. 445-го или 139-го порта. G>Это из тойже оперы что поудалять конфиги,а потом жаловаться на .NET.
Жаловаться я буду на программера, который от радости "что не надо ничего знать, чтобы написать коммуникацию между процессами на разных компьютерах" не удосужился правильно обработать различные вполне себе жизненные ситуации. Точнее даже не жаловаться, а материть его...
Точнее даже не конечного кодера, а архитектора. Классическому кодеру и не надо ничего знать — тут да, .Net удешевляет труд кодера за счет упрощения. Вот только упрощение это может привести к тому, что кодер пропадет вообще
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, lifrsdn, Вы писали:
L>>Ну и надо всё время проверять, что в этом месте процедуры этот tmp ещё нужен, а чуть ниже по тексту уже нет. DOO>Неужели это такая проблема помнить свои переменные в рамках одной синтаксической конструкции? DOO>Попиши на асме какое-то время — дисциплина подтянется
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
DOO>>>Товарищ, открытый порт еще ничего не значит. Давно уже все используют МЭ прикладного уровня, особенно для Web-трафика. Я тебе специально в пример привел RPC — на ISA сервере я могу перекрыть конкретные RPC интерфейсы, даже если используется транспорт nc_acn_named_pipes — который гуляет поверх SMB, т.е. 445-го или 139-го порта. G>>Это из тойже оперы что поудалять конфиги,а потом жаловаться на .NET.
DOO>Жаловаться я буду на программера, который от радости "что не надо ничего знать, чтобы написать коммуникацию между процессами на разных компьютерах" не удосужился правильно обработать различные вполне себе жизненные ситуации. Точнее даже не жаловаться, а материть его... DOO>Точнее даже не конечного кодера, а архитектора. Классическому кодеру и не надо ничего знать — тут да, .Net удешевляет труд кодера за счет упрощения. Вот только упрощение это может привести к тому, что кодер пропадет вообще
То есть надо обработать Exeptionы. Да уж, тяжелая задача.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>Remoting вообще не использует DCOM. DOO>Что бы он там не использовал, но у меня все равно должен быть инструмент, который скажет — вот эту бяку запускать только локлаьно и только админом, эту вообще не запускать и т.п.
G>>Для сборок на компе по-умолчанию FullTrust. DOO>Настройки по умолчанию это неинтересно. Надо знать какие конкретно права необходимы сборке локально и удаленно, чтобы remoting работал как надо. Иначе будут непонятки (сменятся умолчания с выходом очередного SP и все — приехали).
Сомнительно. Аргумент из серии "а у вас негров линчуют".
DOO>Вообще проблема не надумана — после установки ISA Server 2004 SP2 на W2k3 SP1 R2 некоторые инструменты администрирования MS перестают работать (например, настройка NLB кластера) — в чем конкретно проблема
Ты явно куда-то не в ту степь полез.
G>>При работе через 80 порт по протоколу HTTP все будет пучком. DOO> DOO>А MS RPC тоже частенько работает только по 445-му порту (ну или 139-му), но это не значит, что нет грамотных МЭ, которые не отсекут конкретный интерфейс...
А у нас прикинь, на техосмотре брызговики требуют ставить, а на моей машине они штатно не предусмотрены производителем. О чем это я? Ну да не в тему, ну раз мы делимся наболевшими проблемами, то я тоже.
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, _d_m_, Вы писали:
___>>Неа. Только не стоит забывать, что JIT компилятор работает с байт кодом, а не с исходниками. Яволь?
С>Вот смотри: у нас есть обычный компилятор и JIT. У первого — времени столько, сколько понадобится, никаких ограничений не накладывается.
А теперь ты смотри: у нас есть сначала компилятор в байт код, у него есть времени столько, сколько понадобидться, никакаких ограничений не накладывается, чтобы произвести оптимизированный байт код. А потом этот код берет жит компилер и оптимизирует под конкретные: процессор/много процессоров/архитектуру (32/64)/ОС/объем ОЗУ. Хотя время на жит компиляцию конечно тратиться. Ну теперь яволь?
Легко. Лично сталкивался с ситуацией когда на одной из моторол (платформа Java ME)после каждого проигрывания wav-файла число потоков в системе всегда увеличивалось и не уменьшалось никакими средствами.
Понятно, что это вина не джавы, как таковой, а корявой реализации библиотек производителями телефонов, не всё же...
Здравствуйте, se_sss, Вы писали:
_>>>И с gc тоже. Ещё какие!
kuj>>Какие?
_> Легко. Лично сталкивался с ситуацией когда на одной из моторол (платформа Java ME)после каждого проигрывания wav-файла число потоков в системе всегда увеличивалось и не уменьшалось никакими средствами. _>Понятно, что это вина не джавы, как таковой, а корявой реализации библиотек производителями телефонов, не всё же...
Моторолы, как я слышал, вабще отличаются глючностью софта.
Здравствуйте, Maxim S. Shatskih, Вы писали:
C>>, и достаточно убогая компонентная модель (в Дельфи они однозначно была лучше). MSS>Это OCXы-то? весьма развитая модель.
В Дельфи вообще-то не OCXи, там свои собственные компоненты.
MSS>Когда программы, созданные тулом, плохо работают с базой данных — тут не то что VB6 лучше покажется, а и PowerBuilder.
Borland умел ADO использовать. А до появления ADO вообще везде плохо было.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, DOOM, Вы писали:
DOO>>Здравствуйте, lifrsdn, Вы писали:
L>>>Ну и надо всё время проверять, что в этом месте процедуры этот tmp ещё нужен, а чуть ниже по тексту уже нет. DOO>>Неужели это такая проблема помнить свои переменные в рамках одной синтаксической конструкции? DOO>>Попиши на асме какое-то время — дисциплина подтянется
___>Аргумент ваще никакой.
Каков изначальный посыл
Проблемы с запоминанием использования переменной на 10-15 строках (а длиннее редко бывают конструкции) — это тоже знаете ли...
Здравствуйте, hattab, Вы писали: H>Я привер пример тула. Чего еще? Примеры нужны? Ищи. Только думаю это все в корпоративном секторе, коли на него нацелено...
Этот тул нежизнеспособен. Авторы WebSnap не поняли, что такое веб приложения, и как их нужно писать. Еще вопросы?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, hattab, Вы писали: H>Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом.
Ну если захотелось помериться хамилками, то объясни мне, как Дельфи разработчик, отчего в дельфи программах утечки памяти наступают на ровном месте. Ась?
Я вот учил ПДД по вот такой дельфийской программе — приходилось перезапускать раз в десять минут из-за чудовищных ликов. А казалось бы — место ровнее некуда.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Сергей, Вы писали:
С>>У JIT-компиляторов оптимизация получается неважная — потому что важно обеспечить быструю компиляцию.
kuj>Хорошо придумал. В действительности, оптимизация на очень достойном уровне. RTFM вообщем.
Я верю, что оптимизация у .NET-компиляторов лучше, чем у Delphi — потому что у нее все совсем уж плохо.
Но если сравнить с хорошим оптимизирующим C/C++ компилятором, я думаю, дотнетовский JIT-компилятор проиграет.
Тут соображение такое: у обычного не-JIT-компилятора ограничений на время фактически нет, а для JIT — есть ограничения на время генерации кода.
Некоторая работа, конечно, делается заранее — компиляция в байт код (тут есть место для оптимизаций, но не "под конкретный процессор", о чем было написано в том сообщений, в ответ на которое я написал свое), но те задачи, что нужно делать Just-In-Time, должны выполняться быстро.
Т.е. JIT изначально находится в худших условиях по ограничениям на время, поэтому при прочих равных не-JIT имеет больше возможностей для оптимизации.
Разумеется, это не повод для выбрасывания дотнета "в печку".
Здравствуйте, _d_m_, Вы писали:
H>>Если люди чего-то там не знали/забывали, это характеризует только их, но не инструмент. Если выражаться простым языком: не можешь срать -- не мучай жопу. В управляемых средах, таки, есть место ручной очистке (пусть даже семантически скрываемой) для объектов владеющих ресурсами. Что начнется, когда
___>В оригинале вобще-то звучит вобще-то "не хочешь срать — не мучай жопу". Разница существенная. В дальнейшем просьба быть точнее, а то минусы буду ставить нещадно!
Мне доводилось слышать в моем варианте. А виртуальный фетишь меня не прет, т.ч. хоть обминусись
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, hattab, Вы писали:
MC>>>>>Речь не о SOAP-сервисах, а о создании веб-морд. Т.е. упрощенно — когда есть HTML-шаблоны и java/.net код, который на их основе хитро генерит динамические страницы. Ну, короче, как в php.
H>>>>WebSnap. Ребята, оно было еще в 6 версии. Intraweb еще круче
___>Ну вот здесь говришь...
kuj>>>Хочу полноценный MVC с unit test`ами и расширяемым view-engine по типу Brail (из Castle Monorail)! Где?
H>>Я не занимаюсь вебом, ничего сказать не могу.
___>А здесь ничего не можешь сказать. Как так?
Очень просто. Я знаю о наличии этих штук. Знаю их предназначение и видел демки. Но я с этим не работал лично, поэтому точнее сказать ничего не могу. Есть вопросы -- читай доки/рой гугл.
MSS>>BDE — аналог Jet из Access. Для своей родной файловой БД неплох, но обращения к внешним SQL источникам там идут через механизм attached table, который, как я понимаю, откачивает почти всю выборку из внешнего SQL в таблицу во временной "родной" БД, и потом листает именно ее.
H>Кажется, BDE появился раньше Jet (хотя тут могу ошибаться)
Примерно одновременно, в двух совершенно аналогичных продуктах Paradox и Access. BDE тогда назывался IDAPI.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, DOOM, Вы писали:
DOO>>Здравствуйте, gandjustas, Вы писали:
DOO>>>>Товарищ, открытый порт еще ничего не значит. Давно уже все используют МЭ прикладного уровня, особенно для Web-трафика. Я тебе специально в пример привел RPC — на ISA сервере я могу перекрыть конкретные RPC интерфейсы, даже если используется транспорт nc_acn_named_pipes — который гуляет поверх SMB, т.е. 445-го или 139-го порта. G>>>Это из тойже оперы что поудалять конфиги,а потом жаловаться на .NET.
DOO>>Жаловаться я буду на программера, который от радости "что не надо ничего знать, чтобы написать коммуникацию между процессами на разных компьютерах" не удосужился правильно обработать различные вполне себе жизненные ситуации. Точнее даже не жаловаться, а материть его... DOO>>Точнее даже не конечного кодера, а архитектора. Классическому кодеру и не надо ничего знать — тут да, .Net удешевляет труд кодера за счет упрощения. Вот только упрощение это может привести к тому, что кодер пропадет вообще
G>То есть надо обработать Exeptionы. Да уж, тяжелая задача.
Надо их корректно обработать.
Еще пример (опять жизненный): была у меня проблема в работе VMWare virtual infrastructure client (этот уже на .Net'е писан) — не мог цепляться к удаленной консоли. Клиент говорил, что-то типа: Failed to establish remote MKS connection. Could not read /bla-bla-bla/machine_name.vmx. Молодца. Просто море отладочной информации — а почему он его could not read? Если сам клиент не смог бы, например, показать свойства виртуальной машины без доступа к этому файлу? Вот сидел и гадал. Твоя обработка исключения будет приводить к точно таким же "подробным" диагностическим сообщениям. Чтобы сделать грамотно, надо все-таки знать, как это работает, а не так, что "вот как просто, можно даже ни черта не знать, чтобы пользоваться".
Здравствуйте, _d_m_, Вы писали:
H>>>>>>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы
kuj>>>>>Угу, пропал exe-шник — отвалилась голова.
H>>>>У тебя конфиги ни разу не слетали? Если у меня слетит конфиг, моя прилага не забудет как по XML-RPC разговаривать
kuj>>>Не знаю как оно в Делфи, но в .NET и Java конфиги не имеют такой привычки — куда-то там слетать...
H>>И юзеры с админами ну прям небожители. Охотно верю.
___>Ну так какое отношение .Net имеет к админам? Если уж ты такой любитель народных поговорок (впрочем как и я): с дуру можно и х.. сломать"
Здравствуйте, _d_m_, Вы писали:
ДГ>>>Гы. Это был аргумент из серии "я вот тут комп с десятого этажа уронил, теперь он гад загружаться не хочет". Догадываешься, что случится, если в линухе все конфиги пропадут? Конфиги — такие же файлы, как и екзешники.
H>>Какое мне дело до Линукса? Ни одного юзера не допрет править руками exe'шник, а конфиг за милу душу. Но если тебе приятно не замечать проблемы, чтож, хозяин -- барин.
___>Мужики, он против Линукса — налетай
Здравствуйте, _d_m_, Вы писали:
kuj>>>FxCop поможет... И не только с этой проблемой, кстати.
H>>Я знаю, что такое FxCop У Борланда давно уже был CodeGuadr для C++ (задачи примерно те же).
___>Бгга Я наелся дерьма C++ Builder даже не считая CodeGuard-а еще 5 лет назад. Ф топку .
___>До сих пор помню такой замечательный глюк CodeGuard-a: компилирую проект, в рантайме летит ошибка на ровном месте, я меняю местами объявления шаблонрв класса в исходном файле — все работает нормально. После этого отказался от CodeGuard-а, через некоторое время понял, что глюкавый компилятор тоже меня не устравает. Начинал я вообще с Turbo C++ 1.0.
Кто не без греха...
___>Про Дельфи не скажу, но от поделий Богланд меня что-то воротит. Может вспомним еще угробище под названием Interbase?
Есть такая штука: индивидуальная препаратная непереносимость Про интербейс спорить не буду, мне его клон (FB) вполне нравится (но я и с MSSQL (6.5-2000) работал).
Здравствуйте, _d_m_, Вы писали:
___>А теперь ты смотри: у нас есть сначала компилятор в байт код, у него есть времени столько, сколько понадобидться, никакаких ограничений не накладывается, чтобы произвести оптимизированный байт код.
Это все понятно. Тут у JIT и не-JIT условия одинаковые и работу свою они могут сделать одинаково хорошо.
К примеру, GCC и так сначала компилирует программу в некоторое промежуточное представление, а только потом — генерирует код под конкретную архитектуру.
Но на этой стадии — никаких оптимизаций под конкретную архитектуру нет и быть не может.
___> А потом этот код берет жит компилер и оптимизирует под конкретные: процессор/много процессоров/архитектуру (32/64)/ОС/объем ОЗУ. Хотя время на жит компиляцию конечно тратиться.
На этой стадии JIT долго работать не имеет права, а для обычного компилятора время не так важно.
Соответственно, у обычного компилятора (как их по-научному называть-то? а то уж больно похоже на "обычный порошок") больше возможностей для оптимизации машинного кода.
Это, конечно, не повод выбрасывать дотнет "в печку", только соображение о том, что там не все так хорошо, как хотелось бы.
Ну и недостаток этот, конечно, не критический.
Здравствуйте, gandjustas, Вы писали:
H>>Здравствуйте, gandjustas, Вы писали: G>>>Если у объектов есть финализаторы, то они еще некоторое время проживут. Сначала выполнятся финализаторы для всех, а только на следующем проходе их GC уберет все объекты.
H>>Есть гарантия, что финализатор родителя выполнится последним? G>Нет, а оно вам надо?
По условию задачи: родитель живет, пока жив хоть один дочерний интерфейс.
Здравствуйте, gandjustas, Вы писали:
MC>>>В Вашем случае с деревом объектов GC сможет выявить, что дерево целиком недоступно — это раз. Далее он в неопределенном порядке выполнит финализаторы объектов, а потом и освободит память. Соответственно, в финализаторах родители и потомки никак не взаимодействуют. H>>Вот (неопределенный порядок, невозможность взаимодействия в финализаторах). Значит тут, и таким способом, задачу не решить. Не смертельно, конечно, но не сильно приятно.
G>Теперь приведи 3 причины почему финализаторы должны ввыполняться в определенном порядке.
Я уже писал. Чилды должны умереть раньше, чем родитель.
Здравствуйте, DOOM, Вы писали:
kuj>>И конечно же негативно сказывается на производительности. DOO>Это почему? Потому что надо будет поддержку RTTI включить? Ну в дельфи ее просто не выключить
Вообще, в Delphi, RTTI создается только для потомков TPersistent. Для всего прочего, ее нужно включать директивой {$TYPEINFO ON}, и {$METHODINFO ON} для extended RTTI.
Здравствуйте, DOOM, Вы писали:
DOO>Надо их корректно обработать. DOO>Еще пример (опять жизненный): была у меня проблема в работе VMWare virtual infrastructure client (этот уже на .Net'е писан) — не мог цепляться к удаленной консоли. Клиент говорил, что-то типа: Failed to establish remote MKS connection. Could not read /bla-bla-bla/machine_name.vmx. Молодца. Просто море отладочной информации — а почему он его could not read? Если сам клиент не смог бы, например, показать свойства виртуальной машины без доступа к этому файлу? Вот сидел и гадал. Твоя обработка исключения будет приводить к точно таким же "подробным" диагностическим сообщениям. Чтобы сделать грамотно, надо все-таки знать, как это работает, а не так, что "вот как просто, можно даже ни черта не знать, чтобы пользоваться".
Сомневаюсь что там Remoting был.
Здравствуйте, hattab, Вы писали:
___>>А здесь ничего не можешь сказать. Как так?
H>Очень просто. Я знаю о наличии этих штук. Знаю их предназначение и видел демки. Но я с этим не работал лично, поэтому точнее сказать ничего не могу. Есть вопросы -- читай доки/рой гугл.
Вот так у тебя все просто. Сначала выдвинул в качестве аргумента, а потом сказал, что мол я в этом не бум бум и не пойти ли тебе в гугл.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
MC>>>>В Вашем случае с деревом объектов GC сможет выявить, что дерево целиком недоступно — это раз. Далее он в неопределенном порядке выполнит финализаторы объектов, а потом и освободит память. Соответственно, в финализаторах родители и потомки никак не взаимодействуют. H>>>Вот (неопределенный порядок, невозможность взаимодействия в финализаторах). Значит тут, и таким способом, задачу не решить. Не смертельно, конечно, но не сильно приятно.
G>>Теперь приведи 3 причины почему финализаторы должны ввыполняться в определенном порядке.
H>Я уже писал. Чилды должны умереть раньше, чем родитель.
Зачем, сферический конь в вакууме? Можешь считать что они умрут одновременно.
Ты же писал что-то такое. Приведи условия реальной задачи, тогда посмотрим как она решается в .NET
G>>>// Client.cs
G>>>using System;
G>>>using System.Runtime.Remoting;
G>>>using TestObject;
G>>>namespace Client
G>>>{
G>>> class Client
G>>> {
G>>> [STAThread]
G>>> static void Main(string[] args)
G>>> {
G>>> RemotingConfiguration.Configure("Client.exe.config");
G>>> Test test = new Test();
G>>> Console.WriteLine(test.GetAppName()); //Здесь test.GetAppName() вызовется на сервере!!!!
G>>> }
G>>> }
G>>>}
G>>>
G>>>Такое на делфи возможно? DOO>>Такое возможно даже на VBScript. DCOM называется. G>Какие еще языки поддерживают такуюже легкость работы с COM? Что-то мне кажется что никакие. G>Если попробовать написать подобное с DCOM на С++ или Delphi, то получится в разы больше кода, не считая автогенерных Proxy и Stub.
В какие разы??? Не смеши. Будет ровно таже -- строчка две и всех делов. Но мы от DCOM отказались именно по причине его настроек безопасности. Сеть работала не с MS-инфраструктурой, посему это был большой геморой.
G>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие)
В чем та возня? Объекты маршалить можно не напрягаясь, если знать как
DOO>>Вот только вся твоя красота может быть (да точно будет!) обломана настройками безопасности. Ты хоть сможешь это корректно обработать? G>Remoting можно настроить чтобы он работал через HTTP c помощью SOAP. Все это в конфиге, как на клиенте, так и на сервере
Здравствуйте, hattab, Вы писали:
H>В какие разы??? Не смеши. Будет ровно таже -- строчка две и всех делов. Но мы от DCOM отказались именно по причине его настроек безопасности. Сеть работала не с MS-инфраструктурой, посему это был большой геморой.
А прозрачно для прилодения сделать объект не удаленным, а локальным?
Про поменять протокол и формат сериализации вообще молчу.
G>>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие) H>В чем та возня? Объекты маршалить можно не напрягаясь, если знать как
В .NET вообще маршалить не надо, а знать тем более. Главное чтобы передаваемые объекты были сериализуемыми.
Здравствуйте, gandjustas, Вы писали:
DOO>>>>Такое возможно даже на VBScript. DCOM называется. G>>>Какие еще языки поддерживают такуюже легкость работы с COM? Что-то мне кажется что никакие. DOO>>Да почему — в Дельфях можно было подрубать те же IDispatch'и и превращать программу в какое-то подобие скрипта... Абсолютно аналогично VBScript'у. G>И получать Runtime error на коде, который выглядит как обычный статический.
А на своем test.GetAppName() ты думаешь не можешь получить эксепшен? Я думаю ты хотел сказать, что при написании можно ошибиться в имени метода. Если так, это не проблема, ибо Delphi умеет генерить заглушки.
G>>>Если попробовать написать подобное с DCOM на С++ или Delphi, то получится в разы больше кода, не считая автогенерных Proxy и Stub. G>>>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие) DOO>>В Дельфи можно было этого избежать. G>Ну да, использовать простые типы
Зачем ты снова говоришь неправду? Ты пробовал и у тебя не получилось?
Здравствуйте, hattab, Вы писали:
kuj>>>>Не знаю как оно в Делфи, но в .NET и Java конфиги не имеют такой привычки — куда-то там слетать...
H>>>И юзеры с админами ну прям небожители. Охотно верю.
___>>Ну так какое отношение .Net имеет к админам? Если уж ты такой любитель народных поговорок (впрочем как и я): с дуру можно и х.. сломать"
H>Ситуация, вполне себе, жизненная
Не спорю. Но тем не менее никакого отношения к "пердмету" разговора не имеющая. Или скажем по другому: юзеры/админы относятся к Дельфи/C#-ДотНет также как считать, что пользователи могут залить клавиатуру кофе недостатком клавиатуры.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
DOO>>>>>Такое возможно даже на VBScript. DCOM называется. G>>>>Какие еще языки поддерживают такуюже легкость работы с COM? Что-то мне кажется что никакие. DOO>>>Да почему — в Дельфях можно было подрубать те же IDispatch'и и превращать программу в какое-то подобие скрипта... Абсолютно аналогично VBScript'у. G>>И получать Runtime error на коде, который выглядит как обычный статический.
H>А на своем test.GetAppName() ты думаешь не можешь получить эксепшен? Я думаю ты хотел сказать, что при написании можно ошибиться в имени метода. Если так, это не проблема, ибо Delphi умеет генерить заглушки.
В делфи можно включить режим, когда для каждого объекта, реализующего IDispatch вызовы методов через точку будут оборачиаваться в вызовы Invoke. При синтаксической ошибке в имени метода будет получатся Runtime exception. То что делфи умеет генерить заглушки я знаю.
G>>>>Если попробовать написать подобное с DCOM на С++ или Delphi, то получится в разы больше кода, не считая автогенерных Proxy и Stub. G>>>>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие) DOO>>>В Дельфи можно было этого избежать. G>>Ну да, использовать простые типы H>Зачем ты снова говоришь неправду? Ты пробовал и у тебя не получилось?
Я пробовал, у меня получилось и больше не хочу.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>Если ты имеешь ввиду программситов, которые используют распределенные объекты, то им незнание не мешает.
H>Шедевр
Правда жизни. Сам так работал пару месяцев, пока не изучил что такое Remoting.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, _d_m_, Вы писали:
H>>>Если люди чего-то там не знали/забывали, это характеризует только их, но не инструмент. Если выражаться простым языком: не можешь срать -- не мучай жопу. В управляемых средах, таки, есть место ручной очистке (пусть даже семантически скрываемой) для объектов владеющих ресурсами. Что начнется, когда
___>>В оригинале вобще-то звучит вобще-то "не хочешь срать — не мучай жопу". Разница существенная. В дальнейшем просьба быть точнее, а то минусы буду ставить нещадно!
H>Мне доводилось слышать в моем варианте. А виртуальный фетишь меня не прет, т.ч. хоть обминусись
Это искажение фактов. Так вот и писались библия и евангелия. Каждый человек непременно добавляет свое частное IMHO.
Насчет минусов — ты вообще заметил смайлик? Шутка же. Сам к оценкам отношусь двояко — ставлю когда ну уж совсем нравится или нет. Отрицательные оценки ставлю очень редко. Оценки своих сообщений не смотрю, т.к. во первых, в Outlook Express-е их не видно, во вторых: ибланов много, минусов наставят будь здоров — ну что мне из-за этого настроение портить — не дождутся. Вобщем, живу по совести — остальное все х..ня.
Здравствуйте, hattab, Вы писали:
___>>Про Дельфи не скажу, но от поделий Богланд меня что-то воротит. Может вспомним еще угробище под названием Interbase?
H>Есть такая штука: индивидуальная препаратная непереносимость Про интербейс спорить не буду, мне его клон (FB) вполне нравится (но я и с MSSQL (6.5-2000) работал).
FB это уже другая пестня, которая к Богланд уже не имеет никакого отношения.
Здравствуйте, Sinclair, Вы писали:
H>>Я привер пример тула. Чего еще? Примеры нужны? Ищи. Только думаю это все в корпоративном секторе, коли на него нацелено... S>Этот тул нежизнеспособен. Авторы WebSnap не поняли, что такое веб приложения, и как их нужно писать. Еще вопросы?
Мой пост был ответом на вопрос: что у вас для Web. Вопросы?
Здравствуйте, Sinclair, Вы писали:
H>>Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом. S>Ну если захотелось помериться хамилками, то объясни мне, как Дельфи разработчик, отчего в дельфи программах утечки памяти наступают на ровном месте. Ась?
Тут уже приводили пример кода, где, как-бы на ровном месте...
S>Я вот учил ПДД по вот такой дельфийской программе — приходилось перезапускать раз в десять минут из-за чудовищных ликов. А казалось бы — место ровнее некуда.
У меня приятель писал прогу для ПДД еще на DOS'овском паскале. Вери кул. И?
Здравствуйте, _d_m_, Вы писали:
___>>>А здесь ничего не можешь сказать. Как так?
H>>Очень просто. Я знаю о наличии этих штук. Знаю их предназначение и видел демки. Но я с этим не работал лично, поэтому точнее сказать ничего не могу. Есть вопросы -- читай доки/рой гугл.
___>Вот так у тебя все просто. Сначала выдвинул в качестве аргумента, а потом сказал, что мол я в этом не бум бум и не пойти ли тебе в гугл.
Конечно просто. Был вопрос: что у вас есть? Я ответил. Я не работаю со всем, что включает в себя Delphi.
Здравствуйте, gandjustas, Вы писали:
H>>Я уже писал. Чилды должны умереть раньше, чем родитель. G>Зачем, сферический конь в вакууме? Можешь считать что они умрут одновременно. G>Ты же писал что-то такое. Приведи условия реальной задачи, тогда посмотрим как она решается в .NET
Я и так привел условия реальной задачи. Чилды должны умирать раньше парента. Я уже говорил, про попытку кроить задачу под решение. Просто согласиь, что такие моменты ты не контролируешь, и разойдемся спокойно.
Здравствуйте, gandjustas, Вы писали:
H>>В какие разы??? Не смеши. Будет ровно таже -- строчка две и всех делов. Но мы от DCOM отказались именно по причине его настроек безопасности. Сеть работала не с MS-инфраструктурой, посему это был большой геморой. G>А прозрачно для прилодения сделать объект не удаленным, а локальным?
Вообще ни каких проблем
G>Про поменять протокол и формат сериализации вообще молчу.
Я перечислял уже протоколы по которым может работать MIDAS.
G>>>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие) H>>В чем та возня? Объекты маршалить можно не напрягаясь, если знать как G>В .NET вообще маршалить не надо, а знать тем более. Главное чтобы передаваемые объекты были сериализуемыми.
Маршалить = передавать (в обобщенной форме). Про знание о сериализации я и говорю
Здравствуйте, _d_m_, Вы писали:
kuj>>>>>Не знаю как оно в Делфи, но в .NET и Java конфиги не имеют такой привычки — куда-то там слетать...
H>>>>И юзеры с админами ну прям небожители. Охотно верю.
___>>>Ну так какое отношение .Net имеет к админам? Если уж ты такой любитель народных поговорок (впрочем как и я): с дуру можно и х.. сломать"
H>>Ситуация, вполне себе, жизненная
___>Не спорю. Но тем не менее никакого отношения к "пердмету" разговора не имеющая. Или скажем по другому: юзеры/админы относятся к Дельфи/C#-ДотНет также как считать, что пользователи могут залить клавиатуру кофе недостатком клавиатуры.
Delphi не обязывает программиста иметь конфигурационные файлы, от которых будет зависеть работоспособность приложения. Вот и вся разница.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Я уже писал. Чилды должны умереть раньше, чем родитель. G>>Зачем, сферический конь в вакууме? Можешь считать что они умрут одновременно. G>>Ты же писал что-то такое. Приведи условия реальной задачи, тогда посмотрим как она решается в .NET
H>Я и так привел условия реальной задачи. Чилды должны умирать раньше парента. Я уже говорил, про попытку кроить задачу под решение. Просто согласиь, что такие моменты ты не контролируешь, и разойдемся спокойно.
Всегда нужно решение конкретной задачи, а не абстрактной. Приведи КОНКРЕТНУЮ зададу и я показу как она решается на .NET.
В твоих условиях это только ЖЕЛАНИЕ чтобы чилды умирали раньше парента. Если ничего им не мешет упирать позже парента, то почему все должно быть как ты хочешь?
Здравствуйте, _d_m_, Вы писали:
___>>>Мужики, он против Линукса — налетай
H>>Я не против Он мне... В общем, фиолетов.
___>Это была шутка йумара. Здесь есть ярые поборники оного, впрочем, как и ты Дельфи.
Я не поборник Delphi Я осведомлен о ее проблемах сильно больше, нежели нападающие тут. Я просто скромно, честь девушки отстаиваю
Здравствуйте, hattab, Вы писали:
G>>>>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие) H>>>В чем та возня? Объекты маршалить можно не напрягаясь, если знать как G>>В .NET вообще маршалить не надо, а знать тем более. Главное чтобы передаваемые объекты были сериализуемыми.
H>Маршалить = передавать (в обобщенной форме). Про знание о сериализации я и говорю
А зачем знать? достаточно чтобы объект был сериализуемым (имел соответсвующий атрибут). В COM нельзя любой класс передать в метод.
Здравствуйте, gandjustas, Вы писали:
H>>А на своем test.GetAppName() ты думаешь не можешь получить эксепшен? Я думаю ты хотел сказать, что при написании можно ошибиться в имени метода. Если так, это не проблема, ибо Delphi умеет генерить заглушки. G>В делфи можно включить режим, когда для каждого объекта, реализующего IDispatch вызовы методов через точку будут оборачиаваться в вызовы Invoke. При синтаксической ошибке в имени метода будет получатся Runtime exception. То что делфи умеет генерить заглушки я знаю.
В Delphi такого режима нет В Delphi можно от варианта хранящего IDispatch звать методы. Это, кстати, я тебе в примере на XML-RPC показывал.
Здравствуйте, _d_m_, Вы писали:
___>Насчет минусов — ты вообще заметил смайлик? Шутка же. Сам к оценкам отношусь двояко — ставлю когда ну уж совсем нравится или нет. Отрицательные оценки ставлю очень редко. Оценки своих сообщений не смотрю, т.к. во первых, в Outlook Express-е их не видно, во вторых: ибланов много, минусов наставят будь здоров — ну что мне из-за этого настроение портить — не дождутся. Вобщем, живу по совести — остальное все х..ня.
Здравствуйте, _d_m_, Вы писали:
___>>>Про Дельфи не скажу, но от поделий Богланд меня что-то воротит. Может вспомним еще угробище под названием Interbase?
H>>Есть такая штука: индивидуальная препаратная непереносимость Про интербейс спорить не буду, мне его клон (FB) вполне нравится (но я и с MSSQL (6.5-2000) работал).
___>FB это уже другая пестня, которая к Богланд уже не имеет никакого отношения.
С Interbase'ом вообще мало работал, так, чисто для тестов. Но на Абрамсах он, тем не менее, стоял
Здравствуйте, gandjustas, Вы писали:
H>>Я и так привел условия реальной задачи. Чилды должны умирать раньше парента. Я уже говорил, про попытку кроить задачу под решение. Просто согласиь, что такие моменты ты не контролируешь, и разойдемся спокойно. G>Всегда нужно решение конкретной задачи, а не абстрактной. Приведи КОНКРЕТНУЮ зададу и я показу как она решается на .NET. G>В твоих условиях это только ЖЕЛАНИЕ чтобы чилды умирали раньше парента. Если ничего им не мешет упирать позже парента, то почему все должно быть как ты хочешь?
Чилды могут желать дернуть парента в момент своей смерти. На этапе проектирования я этот момент контролировать не могу т.к. чилды могут быть реализованы позднее и другим программистом, и ему может понадобиться дернуть парент перед смертью чилда. Я всячески пытаюсь избежать связанности реализаций, отсюда такое требование.
Здравствуйте, gandjustas, Вы писали:
G>>>>>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие) H>>>>В чем та возня? Объекты маршалить можно не напрягаясь, если знать как G>>>В .NET вообще маршалить не надо, а знать тем более. Главное чтобы передаваемые объекты были сериализуемыми.
H>>Маршалить = передавать (в обобщенной форме). Про знание о сериализации я и говорю G>А зачем знать? достаточно чтобы объект был сериализуемым (имел соответсвующий атрибут). В COM нельзя любой класс передать в метод.
В COM вообще нельзя ничего сложнее интерфейса да варианта передавать в метод . Я говорю о том, что если человек знает, как сериализовать объект, у него проблем с маршалингом оного не представится.
Здравствуйте, hattab, Вы писали:
H>Чилды могут желать дернуть парента в момент своей смерти. На этапе проектирования я этот момент контролировать не могу т.к. чилды могут быть реализованы позднее и другим программистом, и ему может понадобиться дернуть парент перед смертью чилда. Я всячески пытаюсь избежать связанности реализаций, отсюда такое требование.
Ну приведи реальный пример задачи. Я больше чем уверен, что GC нормально ситуацию разрулит.
Сферический конь в вакууме не интересует
Здравствуйте, hattab, Вы писали:
H>Delphi не обязывает программиста иметь конфигурационные файлы, от которых будет зависеть работоспособность приложения. Вот и вся разница.
Не понял разницы. ДотНет программы тоже не обязывают. А даже если бы обязывали: "также как считать, что пользователи могут залить клавиатуру кофе недостатком клавиатуры."
Здравствуйте, hattab, Вы писали:
___>>Это была шутка йумара. Здесь есть ярые поборники оного, впрочем, как и ты Дельфи.
H>Я не поборник Delphi Я осведомлен о ее проблемах сильно больше, нежели нападающие тут. Я просто скромно, честь девушки отстаиваю
Она не девушка, так что смысл отстаивать? Да и по поводу чести девушки я тоже другого мнения что с ней делать (и девушки тоже, хотя обычно молчат). Отстаивать надо пену на пиве в кружках
Здравствуйте, hattab, Вы писали:
H>В COM вообще нельзя ничего сложнее интерфейса да варианта передавать в метод . Я говорю о том, что если человек знает, как сериализовать объект, у него проблем с маршалингом оного не представится.
Пример, я не знаю как сериализуется объект. Я могу написать класс и пометить его атрибутом Serializable. И потом передавать по сети совершенно нормально.
В DCOM так не получится.
Здравствуйте, hattab, Вы писали:
___>>FB это уже другая пестня, которая к Богланд уже не имеет никакого отношения.
H>С Interbase'ом вообще мало работал, так, чисто для тестов. Но на Абрамсах он, тем не менее, стоял
Ну это не плюс Абрамсов, хотя пендосы так им гордятся. Один из лучших танков в мире, однако не лучший, но когда появится на них:
— автомат заряжания (у нас еще в на Т-64);
— стрельба как снарядами, так и ракетами на 5км по лазерному лучу из орудия причем зарядка ведется штатным автоматом заряжания (Т-64);
— аналог системы "Арена" (СССР 80 годы);
— приемлимый силуэт (Т-90 он явно сливает);
— приемлимый вес для езды по слабым грунтам и по большинству автомобильных мостов (Т-90 он сливает вчистую).
Вот тогда можно будет приводить в пример Абрамс. А так Абрамс для меня не авторитет.
PS: Смотрел передачу по National Geographic про Абрамс. Так вот там он позиционируется как единственный танк с ГТД. А про Т-80/Т-80У они типа не знали. Офтоп конечно, но по теме военной техники со мной лучше не спорить.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, hattab, Вы писали: H>>Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом. S>Ну если захотелось помериться хамилками, то объясни мне, как Дельфи разработчик, отчего в дельфи программах утечки памяти наступают на ровном месте. Ась? S>Я вот учил ПДД по вот такой дельфийской программе — приходилось перезапускать раз в десять минут из-за чудовищных ликов. А казалось бы — место ровнее некуда.
Синклар, от тебя не ожидал — это не аргумент. Угробищную программу можно написать на любом языке, хотя как тут уже говорили, таких дельфописателей больше всего будет. Я вот пару лет назад наблюдал прогу для учета и печати акцизных марок на Дельфи от фирмы "Атлас" — это ваще полный звездец. Так ее еще в свое время обязали пользоваться — и не ипет. Обычная десктопная прога жрала 300-500 Мб ОЗУ да еще глюков воз и маленькая тележка.
Здравствуйте, DOOM, Вы писали:
DOO>У нас один преподаватель в университете про языки с очень большим числом степеней свободы говорил, что это миры: мир ассемблера, мир перла и т.п. Изучать эти миры можно хоть всю жизнь, но суровая действительность требует практических скучных решений
Эти миры можно изучать очень долго только если будешь изучать один конкретный мир.
Если начать изучать все сразу то это волшебным образом займет намного меньше времени чем изучение одного мира.
Скажем метапрограммирование на шаблонах становится тривиальным после изучения функциональщины.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, hattab, Вы писали:
WH>>А зачем нам COM-интерфейсы? H>По условию задачи.
Что это за условия такие?
Кого вобще волнует какие там интерфейсы?
Заказчика волнует только чтобы программа делала то что ему надо.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, OCTAGRAM, Вы писали:
>> Также C++ даёт возможность размещать классы не только в куче, но и в >> стеке и в глобальной памяти. OCT>В C++ нельзя возвращать из функции объекты размера, не известного на OCT>этапе компиляции. OCT>а) строки OCT>б) экземпляры потомка класса
Я стараюсь вообще не возвращать из функции объектов, а только передовать их в функции.
Строки тоже можно не возвращать. Достаточно возвращать указатель на строку и длину. А текст, внутри которого находится эта строка, может жить где-то на другом уровне стека. Также, как и выходной буфер, если речь идёт о выводе текста. А то месят, месят байты, складывая и разрезая один и тот же текст бог знает сколько раз.
Здравствуйте, hattab, Вы писали:
H>По условию задачи: родитель живет, пока жив хоть один дочерний интерфейс.
Перестань описывать решение.
Опиши задачу.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandjustas, Вы писали:
H>>Чилды могут желать дернуть парента в момент своей смерти. На этапе проектирования я этот момент контролировать не могу т.к. чилды могут быть реализованы позднее и другим программистом, и ему может понадобиться дернуть парент перед смертью чилда. Я всячески пытаюсь избежать связанности реализаций, отсюда такое требование.
G>Ну приведи реальный пример задачи. Я больше чем уверен, что GC нормально ситуацию разрулит. G>Сферический конь в вакууме не интересует
Я же тебе написал: на этапе проектирования я не могу контролировать этот момент. Это может потребоваться в будущем, и даже не мне. Что непонятного? Ты методы виртуальными делаешь для чего? Чтоб тут же их заюзать в потомки и все? Проектирвать на перспективу нужно. Это не сферическая задача, это часть моей текущей задачи, описывать которую ну ни какого смысла нет т.к. ключевой момент я уже выделил.
Здравствуйте, _d_m_, Вы писали:
H>>Delphi не обязывает программиста иметь конфигурационные файлы, от которых будет зависеть работоспособность приложения. Вот и вся разница.
___>Не понял разницы. ДотНет программы тоже не обязывают. А даже если бы обязывали: "также как считать, что пользователи могут залить клавиатуру кофе недостатком клавиатуры."
В смысле не обязывают? А эти конфиги упоминаемые тут для настройки ремотинга? Для пользователей любящих кофе давно есть клавы-"непромокайки" , и даже буки такие есть (видимо производитель счел, таки, недостатком )
Здравствуйте, _d_m_, Вы писали:
___>>>Это была шутка йумара. Здесь есть ярые поборники оного, впрочем, как и ты Дельфи.
H>>Я не поборник Delphi Я осведомлен о ее проблемах сильно больше, нежели нападающие тут. Я просто скромно, честь девушки отстаиваю
___>Она не девушка, так что смысл отстаивать? Да и по поводу чести девушки я тоже другого мнения что с ней делать (и девушки тоже, хотя обычно молчат). Отстаивать надо пену на пиве в кружках
Продукт хоть и носит имя города, но символом его (продукта) является Афина (которая девственница по мифологии), долгое время прусутствовавшая на сплешах
Здравствуйте, hattab, Вы писали:
H>Я же тебе написал: на этапе проектирования я не могу контролировать этот момент. Это может потребоваться в будущем, и даже не мне. Что непонятного? Ты методы виртуальными делаешь для чего? Чтоб тут же их заюзать в потомки и все? Проектирвать на перспективу нужно. Это не сферическая задача, это часть моей текущей задачи, описывать которую ну ни какого смысла нет т.к. ключевой момент я уже выделил.
Ты выделил не ключевой момент задачи, а ключевой момент её решения твоим способом.
Набор классов — не задача.
Опишешь задачу, больше чем уверен найдется адекватное решение на .NET.
Здравствуйте, gandjustas, Вы писали:
H>>В COM вообще нельзя ничего сложнее интерфейса да варианта передавать в метод . Я говорю о том, что если человек знает, как сериализовать объект, у него проблем с маршалингом оного не представится. G>Пример, я не знаю как сериализуется объект. Я могу написать класс и пометить его атрибутом Serializable. И потом передавать по сети совершенно нормально.
Улови разницу между "знаю, как сериализовать объект" и "знаю, как сериализуется объект".
G>В DCOM так не получится.
Немного больше работы ручками (создать библиотеки типов), только и всего. Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>В COM вообще нельзя ничего сложнее интерфейса да варианта передавать в метод . Я говорю о том, что если человек знает, как сериализовать объект, у него проблем с маршалингом оного не представится. G>>Пример, я не знаю как сериализуется объект. Я могу написать класс и пометить его атрибутом Serializable. И потом передавать по сети совершенно нормально. H>Улови разницу между "знаю, как сериализовать объект" и "знаю, как сериализуется объект".
Пойми что в для передачи объектов по сети с помощью Remoting не нужно знать ни того, ни другого.
G>>В DCOM так не получится. H>Немного больше работы ручками (создать библиотеки типов), только и всего.
Ну да, немного тут, немного там, а в итоге рукописного кода в разы меньше и ошибок соответственно в разы меньше.
H>Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит.
Это очень важный момент при разработке в большой команде.
Здравствуйте, _d_m_, Вы писали:
___>>>FB это уже другая пестня, которая к Богланд уже не имеет никакого отношения.
H>>С Interbase'ом вообще мало работал, так, чисто для тестов. Но на Абрамсах он, тем не менее, стоял
___>Ну это не плюс Абрамсов, хотя пендосы так им гордятся. Один из лучших танков в мире, однако не лучший, но когда появится на них: ___>- автомат заряжания (у нас еще в на Т-64); ___>- стрельба как снарядами, так и ракетами на 5км по лазерному лучу из орудия причем зарядка ведется штатным автоматом заряжания (Т-64); ___>- аналог системы "Арена" (СССР 80 годы); ___>- приемлимый силуэт (Т-90 он явно сливает); ___>- приемлимый вес для езды по слабым грунтам и по большинству автомобильных мостов (Т-90 он сливает вчистую).
___>Вот тогда можно будет приводить в пример Абрамс. А так Абрамс для меня не авторитет.
___>PS: Смотрел передачу по National Geographic про Абрамс. Так вот там он позиционируется как единственный танк с ГТД. А про Т-80/Т-80У они типа не знали. Офтоп конечно, но по теме военной техники со мной лучше не спорить.
Я не говорю о плюсах Абрамса (а Oracle стоял на Тамагавках), я говорю, что этот факт хоть как-то, но характеризует Interbase
Вот еще:
Еще
один малоизвестный факт — использование InterBase для хранения
информации о кредитках в считывающих устройствах, которые используются
на немецких железных дорогах — одной из самых быстрых и развитых
транспортных систем в мире.
Здравствуйте, gandjustas, Вы писали:
H>>Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит. G>Это очень важный момент при разработке в большой команде.
Кто-то за это все равно платит — в данном случае, компенсируя отсутствие знаний у конечного кодера, архитектор должен залазить очень глубоко в проекте — т.е. все перевели на одного человека, это еще менее надежно.
Здравствуйте, WolfHound, Вы писали:
WH>>>А зачем нам COM-интерфейсы? H>>По условию задачи. WH>Что это за условия такие? WH>Кого вобще волнует какие там интерфейсы? WH>Заказчика волнует только чтобы программа делала то что ему надо.
Со ссылками, вроде, разобрались. Но появился другой вопрос: как контролировать последовательность смерти интерфейсов, если она важна?
Здравствуйте, hattab, Вы писали:
H>Со ссылками, вроде, разобрались. Но появился другой вопрос: как контролировать последовательность смерти интерфейсов, если она важна?
А когда она важна?
От ответа на этот вопрос зависит ответ как контролировать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandjustas, Вы писали:
H>>Я же тебе написал: на этапе проектирования я не могу контролировать этот момент. Это может потребоваться в будущем, и даже не мне. Что непонятного? Ты методы виртуальными делаешь для чего? Чтоб тут же их заюзать в потомки и все? Проектирвать на перспективу нужно. Это не сферическая задача, это часть моей текущей задачи, описывать которую ну ни какого смысла нет т.к. ключевой момент я уже выделил.
G>Ты выделил не ключевой момент задачи, а ключевой момент её решения твоим способом. G>Набор классов — не задача.
У меня не набор классов. У меня набор интерфейсов. Ключевое значение имеет обеспечение возможности чилдов иметь парента, когда они хотят.
G>Опишешь задачу, больше чем уверен найдется адекватное решение на .NET.
Так я и так ее описал. Это не решение моим способом, как ты говоришь, это и есть задача. Я тебе могу описать ее в терминах предметной области, но что тебе это даст?
G>ЗЫ С выделенным категорически не согласен.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
H>>>Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит. G>>Это очень важный момент при разработке в большой команде.
DOO>Кто-то за это все равно платит — в данном случае, компенсируя отсутствие знаний у конечного кодера, архитектор должен залазить очень глубоко в проекте — т.е. все перевели на одного человека, это еще менее надежно.
А разве схема "один мегаархитектор и куча быдлокодеров" где-то работает?
Здравствуйте, gandjustas, Вы писали:
H>>>>В COM вообще нельзя ничего сложнее интерфейса да варианта передавать в метод . Я говорю о том, что если человек знает, как сериализовать объект, у него проблем с маршалингом оного не представится. G>>>Пример, я не знаю как сериализуется объект. Я могу написать класс и пометить его атрибутом Serializable. И потом передавать по сети совершенно нормально. H>>Улови разницу между "знаю, как сериализовать объект" и "знаю, как сериализуется объект". G>Пойми что в для передачи объектов по сети с помощью Remoting не нужно знать ни того, ни другого.
Аналогично и в Delphi Можно делать ручками (о чем я и говорил), а можно пользоваться предоставляемым инструментом, который есть.
G>>>В DCOM так не получится. H>>Немного больше работы ручками (создать библиотеки типов), только и всего. G>Ну да, немного тут, немного там, а в итоге рукописного кода в разы меньше и ошибок соответственно в разы меньше.
Кто говорит о рукописном? Есть редактор библиотеки типов, который сам все напишет.
H>>Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит. G>Это очень важный момент при разработке в большой команде.
При разработке в большой комаде, нужна идеология черного ящика для ядра системы, и такая его реализация, чтоб малограмотные не могли даже чихнуть без разрешения. Готовые универсальные решения, слабо подходят для такого типа разработки. В будущем обязательно вылезет какая нибудь проблема не укладывающаяся в "универсальные" рамки.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>У меня не набор классов. У меня набор интерфейсов.
Перестань повторять эту тупость порожденную кривостью делфи. В любом случае это будут какие-то объекты.
H>Ключевое значение имеет обеспечение возможности чилдов иметь парента, когда они хотят.
А парент просто хранит ссылки на детей?
G>>Опишешь задачу, больше чем уверен найдется адекватное решение на .NET. H>Так я и так ее описал. Это не решение моим способом, как ты говоришь, это и есть задача. Я тебе могу описать ее в терминах предметной области, но что тебе это даст?
Еще раз. Ты описываешь решение задачи, а ты опиши саму задачу. Забудь что у тебя есть компьютер, классы, интерфейсы. Просто скажи что должен увидеть пользователь.
G>>ЗЫ С выделенным категорически не согласен. H>Да-да, ведь рефакторинг это круто
Не в рефакторигне дело.
Здравствуйте, hattab, Вы писали:
H>Кто говорит о рукописном? Есть редактор библиотеки типов, который сам все напишет.
С ужасно кривым интерфейсом редактирования. (Надеюсь с седьмой версии улучшили)
Здравствуйте, gandjustas, Вы писали:
H>>>>Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит. G>>>Это очень важный момент при разработке в большой команде.
DOO>>Кто-то за это все равно платит — в данном случае, компенсируя отсутствие знаний у конечного кодера, архитектор должен залазить очень глубоко в проекте — т.е. все перевели на одного человека, это еще менее надежно. G>А разве схема "один мегаархитектор и куча быдлокодеров" где-то работает?
Ну вот. Ты сам понимаешь, что такое невозможно — так что придется кодеру вникать, никуда не денется.
Hi misha_irpen
ДГ>>>>Я даже больше скажу: в современной визуальной IDE под названием Eclipse формошлёпщик по умолчанию отсутствует. _>>>Угу, вот потому его и используют одни "энтузиасты" и нищие фирмы-однодневки. А в корпоративном секторе (где существует такое понятие как срок сдачи проекта) юзают VS, который формошлепщиком оборудован по-умолчанию. kuj>>Поржал. Пиши еще. _>Если есть конкретные возражения -- в студию. Названия компаний, активно использующих этот ваш еклипс для чего-нибудь кроме джавы -- тоже.
Я давно не слежу за java. И еще больше за WebSphere. Но насколько мне известно то в WebSphere Studio (знающие люди поправьте) изпользуется Eclipse. Вернее сказать WebSphere Studio это специально заточенный Eclipse. И все это добро делает такая маленькая и неизвестная конторка с именем IBM.
_>Иначе слив засчитывается автоматически.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
H>>>>>Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит. G>>>>Это очень важный момент при разработке в большой команде.
DOO>>>Кто-то за это все равно платит — в данном случае, компенсируя отсутствие знаний у конечного кодера, архитектор должен залазить очень глубоко в проекте — т.е. все перевели на одного человека, это еще менее надежно. G>>А разве схема "один мегаархитектор и куча быдлокодеров" где-то работает?
DOO>Ну вот. Ты сам понимаешь, что такое невозможно — так что придется кодеру вникать, никуда не денется.
Это не зависит от языка и платформы. В любом случае нужны толковые программисты кроме мегаархитектора.
Только в Delphi например, любой кодер может утечку памяти в люом месте вызвать, в отличие от .NET и Java
G>Это не зависит от языка и платформы. В любом случае нужны толковые программисты кроме мегаархитектора.
Ну вот. Т.е. .Net, .Net'ом а руки все-таки должны расти из правильного места...
G>Только в Delphi например, любой кодер может утечку памяти в люом месте вызвать, в отличие от .NET и Java
Ну я думаю по незнанию и в .Net с джавой тоже можно изрядно напортачить (в крайнем случае насмотрелся я на бажные продукты циски, писанные на джаве).
Здравствуйте, hattab, Вы писали:
___>>Не спорю. Но тем не менее никакого отношения к "пердмету" разговора не имеющая. Или скажем по другому: юзеры/админы относятся к Дельфи/C#-ДотНет также как считать, что пользователи могут залить клавиатуру кофе недостатком клавиатуры.
H>Delphi не обязывает программиста иметь конфигурационные файлы, от которых будет зависеть работоспособность приложения. Вот и вся разница.
Здравствуйте, _d_m_, Вы писали:
___>Про Дельфи не скажу, но от поделий Богланд меня что-то воротит. Может вспомним еще угробище под названием Interbase?
kuj>>Ты не понял. Во-первых, в C++ можно и std::list< void * >, во-вторых, это дает не гибкость, а широкое поле для ошибок и проблем с приведением типов. DOO>И снова мы упираемся в различные подходы — для тебя программа во время выполнения статична, для дельфиста — нет.
Ась?
kuj>>И конечно же негативно сказывается на производительности. DOO>Это почему?
Потому, что приведение типов.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, DOOM, Вы писали:
kuj>>>Ты не понял. Во-первых, в C++ можно и std::list< void * >, во-вторых, это дает не гибкость, а широкое поле для ошибок и проблем с приведением типов. DOO>>И снова мы упираемся в различные подходы — для тебя программа во время выполнения статична, для дельфиста — нет. kuj>Ась?
Да елки-палки. Вот есть у меня TList — я в него что-то складываю в функции, полученное параметром к этой самой функции — никто не знает до этапа выполнения, что там будет — какой такой объект? Какого такого типа? Такие ситуации встречаются очень даже часто — и проку мне от твоего типизированного контейнера?
Я реально в свое время был просто в каком-то мега восторге, что я могу определить минимум на этапе написания и сделать все функции и объекты универсальными...
kuj>>>И конечно же негативно сказывается на производительности. DOO>>Это почему? kuj>Потому, что приведение типов.
o_O И какие же это накладные расходы в run time? Особенно хотелось бы услышать про накладные расходы у приведений вида:
1. У Javascript есть нормальный garbage collector. Ему не нужны smart pointer`ы.
2. Делфи — динамический язык? А Борланд об этом знает? Если хочешь посмотреть на динамический язык возьми ruby или python, например.
Ликбез: Delphi, C++ и C# — статические строго типизированные языки. Неужто ты серьезно думаешь, что если есть generic`и, то пропадает возможность кастинга объекта к суперклассу?
Серьезно, ребят, завязывайте с Delphi. Delphi — зло, оно отупляет.
Здравствуйте, DOOM, Вы писали:
kuj>>>>Ты не понял. Во-первых, в C++ можно и std::list< void * >, во-вторых, это дает не гибкость, а широкое поле для ошибок и проблем с приведением типов. DOO>>>И снова мы упираемся в различные подходы — для тебя программа во время выполнения статична, для дельфиста — нет. kuj>>Ась? DOO>Да елки-палки. Вот есть у меня TList — я в него что-то складываю в функции, полученное параметром к этой самой функции — никто не знает до этапа выполнения, что там будет — какой такой объект? Какого такого типа? Такие ситуации встречаются очень даже часто — и проку мне от твоего типизированного контейнера?
Что запрещает использовать IList<object> ? Религия?
kuj>>>>И конечно же негативно сказывается на производительности. DOO>>>Это почему? kuj>>Потому, что приведение типов. DOO>o_O И какие же это накладные расходы в run time? Особенно хотелось бы услышать про накладные расходы у приведений вида: DOO>
Здравствуйте, se_sss, Вы писали:
_> Легко. Лично сталкивался с ситуацией когда на одной из моторол (платформа Java ME)после каждого проигрывания wav-файла число потоков в системе всегда увеличивалось и не уменьшалось никакими средствами. _>Понятно, что это вина не джавы, как таковой, а корявой реализации библиотек производителями телефонов, не всё же...
Здравствуйте, hattab, Вы писали:
H>>>Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release).
G>>Еще раз, запомни простую вещь: в .NET нету разницы между COM и не-COM
H>Ок. У .Net-интерфейсов есть механизм подсчета ссылок? И почему мне Mr.Cat говорил, что не в курсе, как устроен GC для COM-интерфейсов? Есть какое-то различие? Просвети.
Ты статью в codeproject, ссылку на которую я тебе дал, явно не читал. Объясни почему мы должны тут восполнять пробелы в твоем образовании? Назови хоть одну причину.
Здравствуйте, kuj, Вы писали:
kuj>1. У Javascript есть нормальный garbage collector. Ему не нужны smart pointer`ы.
Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша.
kuj>2. Делфи — динамический язык?
В достаточной мере.
kuj>А Борланд об этом знает?
Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать.
kuj>Если хочешь посмотреть на динамический язык возьми ruby или python, например.
Кстати, мое первое впечатление от питона было — о! Дельфи в виде скрипта. Очень много похожего.
kuj>Ликбез: Delphi, C++ и C# — статические строго типизированные языки.
На вскидку из гугла:
TabGrid := VarArrayCreate([0,(R - 1),0,(C - 1)],VarOleStr);
I := 0;
// Определяем цикл для заполнения массива-матрицыrepeat
for J := 0 to (C - 1) do
TabGrid[I,J] := GenericStringGrid.Cells[J,I];
Inc(I,1);
until
I > (R - 1);
Опа. Не попадает как-то в узкие рамки статической строгой типизации? Причем заметь — надо писать не что-то вроде SetVariantArrayValue(TabGrid,i,j), а просто TabGrid[i,j] — при этом TabGrid не является массивом до момента выполнения строчки TabGrid := VarArrayCreate([0,(R — 1),0,(C — 1)],VarOleStr);
kuj>Неужто ты серьезно думаешь, что если есть generic`и, то пропадает возможность кастинга объекта к суперклассу?
Нет не пропадает. Я тебе просто говорю, что когда это активно используется в программах проку от твоих универсальных контейнеров — ноль.
kuj>Серьезно, ребят, завязывайте с Delphi. Delphi — зло, оно отупляет.
Ну а ты пальцы гнуть бы завязывал...
MC>>Вы какие интерфейсы имели в виду? Если COM-интерфейсы (технический аспект) — это одно. Если, скажем так, ООП-интерфейсы (теоретический аспект) — то Вы абсолютно не правы. Рекомендую Вам все же почитать про то, как реализуется сборка мусора в java или .NET (ссылки Вам уже дали).
H>Я читал, спасибо. И раньше еще читал В нативной Delphi тип интерфейсов один -- COM, как вы его называете. Их я и имел ввиду.
Ты уж определись сколько типов интерфейсов есть в Delphi. Не ты ли недавно говорил, что в Delphi интерфейсы могут быть и не COM?
MC>>В Вашем случае с деревом объектов GC сможет выявить, что дерево целиком недоступно — это раз. Далее он в неопределенном порядке выполнит финализаторы объектов, а потом и освободит память. Соответственно, в финализаторах родители и потомки никак не взаимодействуют.
H>Вот (неопределенный порядок, невозможность взаимодействия в финализаторах). Значит тут, и таким способом, задачу не решить. Не смертельно, конечно, но не сильно приятно.
Какая разница в каком порядке они удаляется? Никому от порядка их удаления ни жарко ни холодно. Твоя моя понимать?
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, DOOM, Вы писали:
kuj>DOOM открой для себя SOAP, MSMQ, Json.
Ты веточкой не ошибся? К чему ты это написал?
Здравствуйте, DOOM, Вы писали:
H>>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов. DOO>Угу... А какие протоколы обмена используются? А какие порты? А как там с безопасностью?
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, kuj, Вы писали:
kuj>>1. У Javascript есть нормальный garbage collector. Ему не нужны smart pointer`ы. DOO>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша.
Не показывай свою необразованность. В C нет обънектов, смарт поинтеры там не нужны.
kuj>>2. Делфи — динамический язык? DOO>В достаточной мере.
Не более динаический, чем С++. Можно везде писать (void*) и кастить при каждом обращении.
kuj>>А Борланд об этом знает? DOO>Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать.
Наверное ворнинги не от хорошей жизни.
kuj>>Если хочешь посмотреть на динамический язык возьми ruby или python, например. DOO>Кстати, мое первое впечатление от питона было — о! Дельфи в виде скрипта. Очень много похожего.
У тебя мания делфи
kuj>>Ликбез: Delphi, C++ и C# — статические строго типизированные языки. DOO>На вскидку из гугла: DOO>
DOO>TabGrid := VarArrayCreate([0,(R - 1),0,(C - 1)],VarOleStr);
DOO> I := 0;
DOO> // Определяем цикл для заполнения массива-матрицы
DOO> repeat
DOO> for J := 0 to (C - 1) do
DOO> TabGrid[I,J] := GenericStringGrid.Cells[J,I];
DOO> Inc(I,1);
DOO> until
DOO> I > (R - 1);
DOO>
DOO>Опа. Не попадает как-то в узкие рамки статической строгой типизации? Причем заметь — надо писать не что-то вроде SetVariantArrayValue(TabGrid,i,j), а просто TabGrid[i,j] — при этом TabGrid не является массивом до момента выполнения строчки TabGrid := VarArrayCreate([0,(R — 1),0,(C — 1)],VarOleStr);
И ты этим гордишься? Это бездонная бочка ошибок на самом деле.
kuj>>Неужто ты серьезно думаешь, что если есть generic`и, то пропадает возможность кастинга объекта к суперклассу? DOO>Нет не пропадает. Я тебе просто говорю, что когда это активно используется в программах проку от твоих универсальных контейнеров — ноль.
kuj>>Серьезно, ребят, завязывайте с Delphi. Delphi — зло, оно отупляет. DOO>Ну а ты пальцы гнуть бы завязывал...
Ты бы завязывал писать глупости
Здравствуйте, Sinclair, Вы писали:
kuj>>>>В C# гораздо больше взято от Java, чем от Object Pascal. S>Смею предположить, что сие утверждение просто говорит о том, что ты плохо знаешь Object Pascal, и хорошо — Java.
Смею предположить, что сие утверждение просто говорит о том, что ты плохо знаешь Java.
Здравствуйте, _d_m_, Вы писали:
kuj>>В действительности вышеописанных граблей ни в одной нормальной среде разработки быть не должно.
kuj>>Конечно определенные грабли есть везде — где-то меньше, где-то больше. Регулярно пользуюсь VS 2005, VS 2008, пару лет тому назад еще IntelliJ IDEA в арсенале была. Все отлично — на грабли натыкаться не приходиться, работать одно удовольствие.
___>Да есть тоже немножко. Сейчас пользуем VS 2005 SP1: ___>- Если попробовать в док. комментариях добавить для достаточно большого файла ___>/// <summary> ___>/// asda ___>/// </summary> ___>/// <param name="dsda"> asas /</param> ___>вот например в этом месте попытаться напечатать слэш — студия виснет.
Хмм, интересно. На сколько большой должен быть файл, чтоб студия зависла? На .cs в 360kB не виснет и не тормозит... Большего cs-файла под рукой нету...
___>- До SP1 одолевал WinForms дизайнер — открываешь допустим свой контрол, а на нем кнопки съехали. Ну это уже не в счет.
Не сталкивался. Я, правда, с WinForms мало работаю.
___>- WinForms дизайнер — шрифты в дизайнере могут оказаться другого размера, чем на реальной форме.
Это как? Можно сценарий для воспроизведения?
___>- Есть проблемы с дизайнером ReportViewer-а — преобразование единиц измерения, например мм-см, и прочие мелочи типа неверного преобразования margins страницы — это самое неприятное.
Здравствуйте, Сергей, Вы писали:
kuj>>Хорошо придумал. В действительности, оптимизация на очень достойном уровне. RTFM вообщем.
С>Я верю, что оптимизация у .NET-компиляторов лучше, чем у Delphi — потому что у нее все совсем уж плохо. С>Но если сравнить с хорошим оптимизирующим C/C++ компилятором, я думаю, дотнетовский JIT-компилятор проиграет.
Здравствуйте, DOOM, Вы писали:
kuj>>1. У Javascript есть нормальный garbage collector. Ему не нужны smart pointer`ы. DOO>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша.
Кроме Delphi. Ее мини-ниша полностью занята .NET
kuj>>2. Делфи — динамический язык? DOO>В достаточной мере.
Скажу тебе по секрету Delphi никогда не был, не является, и вряд ли когда-то станет динамическим языком.
В отличии от платформы .NET, для которой Microsoft`ом несколько лет активно разрабатывается DLR — Dynamic Language Runtime.
kuj>>А Борланд об этом знает? DOO>Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать.
И при чем тут динамические языки?
kuj>>Если хочешь посмотреть на динамический язык возьми ruby или python, например. DOO>Кстати, мое первое впечатление от питона было — о! Дельфи в виде скрипта. Очень много похожего.
Всего-лишь говорит о твоей низкой квалификации, если для тебя "Питон — это дельфи в виде скрипта".
kuj>>Ликбез: Delphi, C++ и C# — статические строго типизированные языки. DOO>На вскидку из гугла: DOO>
DOO>TabGrid := VarArrayCreate([0,(R - 1),0,(C - 1)],VarOleStr);
DOO> I := 0;
DOO> // Определяем цикл для заполнения массива-матрицы
DOO> repeat
DOO> for J := 0 to (C - 1) do
DOO> TabGrid[I,J] := GenericStringGrid.Cells[J,I];
DOO> Inc(I,1);
DOO> until
DOO> I > (R - 1);
DOO>
DOO>Опа. Не попадает как-то в узкие рамки статической строгой типизации? Причем заметь — надо писать не что-то вроде SetVariantArrayValue(TabGrid,i,j), а просто TabGrid[i,j] — при этом TabGrid не является массивом до момента выполнения строчки TabGrid := VarArrayCreate([0,(R — 1),0,(C — 1)],VarOleStr);
VarArrayCreate создает массив значений типа Variant. При чем тут динамические языки? Ты, батенька, серьезно не в теме.
kuj>>Неужто ты серьезно думаешь, что если есть generic`и, то пропадает возможность кастинга объекта к суперклассу? DOO>Нет не пропадает. Я тебе просто говорю, что когда это активно используется в программах проку от твоих универсальных контейнеров — ноль.
Проку от них ровно столько, сколько проку от подобного контейнера в Delрhi. Кроме того, что я могу явно ограничить супертип, что уменьшит поле для ошибок на этапе компиляции. Вообщем, ты снова явно не в теме.
Здравствуйте, se_sss, Вы писали:
kuj>>А GC тут при чем? _>При том, что GС не гарантирует отсутствия утечек
Гарантирует отсутствие утечек в управляемых ресурсах.
Здравствуйте, se_sss, Вы писали:
kuj>>А GC тут при чем? _>При том, что GС не гарантирует отсутствия утечек
GC в .NET гарантирует отсутствие утечек, то есть гарантирует, что вся занятая память будет рано или позно освобождена.
Есть некоторые ситуации, когда это "поздно" наступает в момент завершения программы, несмотря на то что видимых ссылок на эту память нет, но обнаружить и устранить такое очень легко.
Здравствуйте, gandjustas, Вы писали:
G>GC в .NET гарантирует отсутствие утечек, то есть гарантирует, что вся занятая память будет рано или позно освобождена.
Не гарантирует.
G>Есть некоторые ситуации, когда это "поздно" наступает в момент завершения программы,
Так это и есть утечка ибо нормальные ОС по любому освободят всю память которую захапал завершенный процесс.
G>несмотря на то что видимых ссылок на эту память нет, но обнаружить и устранить такое очень легко.
С этим никто не спорит.
Но и говорить что ГЦ дает гарантии отсутствия утечек нельзя.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, gandjustas, Вы писали:
G>>Есть некоторые ситуации, когда это "поздно" наступает в момент завершения программы, WH>Так это и есть утечка ибо нормальные ОС по любому освободят всю память которую захапал завершенный процесс.
Тут еще можно ввспонить про домены приложений. Память освобождается при выгрузке домена.
Поэтому утечки в .NET, не тоже самое что утечки нативной папями.
Здравствуйте, WolfHound, Вы писали:
H>>Со ссылками, вроде, разобрались. Но появился другой вопрос: как контролировать последовательность смерти интерфейсов, если она важна? WH>А когда она важна? WH>От ответа на этот вопрос зависит ответ как контролировать.
Когда чилдам может потребоваться парент. И нужно гарантировать, что парент будет жив. Со ссылками тоже: если твои интерфейсы отдать во вне, в неуправляемую среду, то GC за ними следить не сможет?
Здравствуйте, hattab, Вы писали:
H>Когда чилдам может потребоваться парент. И нужно гарантировать, что парент будет жив. Со ссылками тоже: если твои интерфейсы отдать во вне, в неуправляемую среду, то GC за ними следить не сможет?
Хватит решение расказывать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandjustas, Вы писали:
H>>У меня не набор классов. У меня набор интерфейсов. G>Перестань повторять эту тупость порожденную кривостью делфи. В любом случае это будут какие-то объекты.
Ты так и не понял Как ты у объекта спросишь, может ли он летать? (я надеюсь ты не станешь проверять его предков, типа Object Is TCanFlyObject?) У интерфейса ты позовешь QueryInterface(ICanFly, CanFlyIntf). Теперь понятно?
H>>Ключевое значение имеет обеспечение возможности чилдов иметь парента, когда они хотят. G>А парент просто хранит ссылки на детей?
Что значит просто? Ну да, имеет список своих чилдов.
G>>>Опишешь задачу, больше чем уверен найдется адекватное решение на .NET. H>>Так я и так ее описал. Это не решение моим способом, как ты говоришь, это и есть задача. Я тебе могу описать ее в терминах предметной области, но что тебе это даст? G>Еще раз. Ты описываешь решение задачи, а ты опиши саму задачу. Забудь что у тебя есть компьютер, классы, интерфейсы. Просто скажи что должен увидеть пользователь.
Пользователь ничего не должен увидеть Мой пользователь -- другой программист, реализовавший какой-то функционал на чилде и решивший, что хочет чего-то от парента, когда бы то нибыло (это вообще-то логично, раз я чилд, я даже и недумаю что парент может сдохнуть раньше меня).
G>>>ЗЫ С выделенным категорически не согласен. H>>Да-да, ведь рефакторинг это круто G>Не в рефакторигне дело.
А в чем? Будешь по десять раз редизайнить систему при малейших изменениях, вызванных недальновидным проектированием.
Здравствуйте, gandjustas, Вы писали:
H>>Кто говорит о рукописном? Есть редактор библиотеки типов, который сам все напишет. G>С ужасно кривым интерфейсом редактирования. (Надеюсь с седьмой версии улучшили)
Вроде чего-то там переделывали, но я после семерки с DCOM, да и вообще с Enterprise фишками не работаю.
Здравствуйте, gandjustas, Вы писали:
kuj>>>А Борланд об этом знает? DOO>>Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать. G>Наверное ворнинги не от хорошей жизни.
Тебе что, всякий раз нужно показывать ключевые моменты? У нативных проектов эти ворнинги отключаются по умолчанию.
Здравствуйте, WolfHound, Вы писали:
H>>Когда чилдам может потребоваться парент. И нужно гарантировать, что парент будет жив. Со ссылками тоже: если твои интерфейсы отдать во вне, в неуправляемую среду, то GC за ними следить не сможет? WH>Хватит решение расказывать.
Еще раз говорю, это не решение. Это этап проектирования (не смотря на то, что и решение уже есть). Я, gandjustas'у уже давно пытаюсь это объяснить.
Здравствуйте, hattab, Вы писали:
H>Еще раз говорю, это не решение. Это этап проектирования (не смотря на то, что и решение уже есть). Я, gandjustas'у уже давно пытаюсь это объяснить.
Бла-бла-бла.
Задача:
Написать интерпритатор. Делаем xml-based язык. Парсим xml в dom. Далие просто по имени элемента передаем управление соответствующему обработчику. Вот главный цикл:
А теперь реальная задача: Сделать пакетную обработку картинок.
Благодоря этому мегадвиглу я на вопрос: А давай сделаем?
За редким исключением (когда нужной комманды еще нет) отвечаю: Делате.
Вот от тебя ничего кроме первого абзаца не слышно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, DOOM, Вы писали:
DOO>>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша. kuj>Кроме Delphi. Ее мини-ниша полностью занята .NET
.NET, конечно, занял большую часть ниши Delphi.
Но не полностью, нет.
Здравствуйте, kuj, Вы писали:
H>>Я читал, спасибо. И раньше еще читал В нативной Delphi тип интерфейсов один -- COM, как вы его называете. Их я и имел ввиду.
kuj>Ты уж определись сколько типов интерфейсов есть в Delphi. Не ты ли недавно говорил, что в Delphi интерфейсы могут быть и не COM?
ignore off
Ты так туп, что не можешь прочитать, что написано COM, как вы их называете. Да, интерфейсы Delphi бинарно совместимы с COM. Но интерфейсы могут иметь не только COM-объекты, и называть такие интерфейсы COM-интерфейсами нельзя.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>У меня не набор классов. У меня набор интерфейсов. G>>Перестань повторять эту тупость порожденную кривостью делфи. В любом случае это будут какие-то объекты.
H>Ты так и не понял Как ты у объекта спросишь, может ли он летать? (я надеюсь ты не станешь проверять его предков, типа Object Is TCanFlyObject?) У интерфейса ты позовешь QueryInterface(ICanFly, CanFlyIntf). Теперь понятно?
Ну хватит уже показывать свое незнание.
В C# вообще нету QueryInterface, приведение к типу интерфейса осуществляется темеже способами, что обычное приведение типа.
Из одного твоего предложения сразу видно что: а)ты не работал с .NET языками б)ты не работал на С++ в)ты не работал с COM не в Delphi г)ты плохо понимаешь зачем вообще нужны интерфейсы.
H>>>Ключевое значение имеет обеспечение возможности чилдов иметь парента, когда они хотят. G>>А парент просто хранит ссылки на детей? H>Что значит просто? Ну да, имеет список своих чилдов.
Тогда такая ситуация нормально разрулится GC.
G>>>>ЗЫ С выделенным категорически не согласен. H>>>Да-да, ведь рефакторинг это круто G>>Не в рефакторигне дело. H>А в чем? Будешь по десять раз редизайнить систему при малейших изменениях, вызванных недальновидным проектированием.
Честно гворя даже не хочу тебе объяснять
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, WolfHound, Вы писали:
H>>>Когда чилдам может потребоваться парент. И нужно гарантировать, что парент будет жив. Со ссылками тоже: если твои интерфейсы отдать во вне, в неуправляемую среду, то GC за ними следить не сможет? WH>>Хватит решение расказывать.
H>Еще раз говорю, это не решение. Это этап проектирования (не смотря на то, что и решение уже есть). Я, gandjustas'у уже давно пытаюсь это объяснить.
Тебе уже 3 человека написали чтобы ты сказал исходное условие задачи.
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, kuj, Вы писали:
kuj>>Здравствуйте, DOOM, Вы писали:
DOO>>>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша. kuj>>Кроме Delphi. Ее мини-ниша полностью занята .NET
С>.NET, конечно, занял большую часть ниши Delphi. С>Но не полностью, нет.
Конечно, нужен же инструмент, в котором люди смогут писать программы с бешеными утечками памяти.
Какая часть ниши Delphi еще не занята .NET?
Здравствуйте, Сергей, Вы писали:
DOO>>>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша. kuj>>Кроме Delphi. Ее мини-ниша полностью занята .NET
С>.NET, конечно, занял большую часть ниши Delphi. С>Но не полностью, нет.
H>Да, интерфейсы Delphi бинарно совместимы с COM. Но интерфейсы могут иметь не только COM-объекты, и называть такие интерфейсы COM-интерфейсами нельзя.
Каждый объект, реализующий интерфейс преобретает семантику COM-объекта. То есть при использовании становится фактически COM-объектом.
Поэтому итнерфейсы в Delphi — именно COM-интерфейсы.
Можешь не спорить, это факт.
Здравствуйте, gandjustas, Вы писали:
H>>>>Когда чилдам может потребоваться парент. И нужно гарантировать, что парент будет жив. Со ссылками тоже: если твои интерфейсы отдать во вне, в неуправляемую среду, то GC за ними следить не сможет? WH>>>Хватит решение расказывать.
H>>Еще раз говорю, это не решение. Это этап проектирования (не смотря на то, что и решение уже есть). Я, gandjustas'у уже давно пытаюсь это объяснить.
G>Тебе уже 3 человека написали чтобы ты сказал исходное условие задачи.
До человека уж очень медленно все доходит. Что поделаешь?
H>>>Я читал, спасибо. И раньше еще читал В нативной Delphi тип интерфейсов один -- COM, как вы его называете. Их я и имел ввиду.
kuj>>Ты уж определись сколько типов интерфейсов есть в Delphi. Не ты ли недавно говорил, что в Delphi интерфейсы могут быть и не COM?
H>ignore off
H>Ты так туп, что не можешь прочитать, что написано COM, как вы их называете. Да, интерфейсы Delphi бинарно совместимы с COM. Но интерфейсы могут иметь не только COM-объекты, и называть такие интерфейсы COM-интерфейсами нельзя.
H>ignore on
Скорее ты так туп, что не можешь выразить свою мысль:
"В нативной Delphi тип интерфейсов один -- COM, как вы его называете"
Один это не два, не три и не пять. Один это один. Учись выражать свои мысли.
Здравствуйте, gandjustas, Вы писали:
H>>Да, интерфейсы Delphi бинарно совместимы с COM. Но интерфейсы могут иметь не только COM-объекты, и называть такие интерфейсы COM-интерфейсами нельзя. G>Каждый объект, реализующий интерфейс преобретает семантику COM-объекта. То есть при использовании становится фактически COM-объектом. G>Поэтому итнерфейсы в Delphi — именно COM-интерфейсы. G>Можешь не спорить, это факт.
Здравствуйте, WolfHound, Вы писали:
WH>Вот от тебя ничего кроме первого абзаца не слышно.
Уговорил. Есть задача, написать сервер XML-RPC. Реализовать гибкую систему API (подключение/отключение методов, группы методов в любой момент работы сервера). Как реализуются методы мы не знаем. Это могут быть и нативные объекты подключенные в виде некого API, это могут быть скриптовые методы, это может быть все что угодно. Сервер должен уметь валидировать список параметров методов, запрашиваемых на выполнение, с учетом возможной перегрузки методов и наличия дефолтных параметров. Сервер не должен навязывать какой либо идеологии в реализации подключаемых методов. Реализации API должны позволять расширять свою функциональность для получения дополнительных возможностей, например: протоколирования, перехвата, построения справочной информации, самоописания.
Это очень краткое описание. Для справки: мои парент и чилды, это абстракция ServiceObject (некое API) и MethodHandler (обработчик метода). ServiceObject являет собою некое API (какое, мы не знаем), и для каждого метода имеет MethodHandler.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Сергей, Вы писали:
С>>.NET, конечно, занял большую часть ниши Delphi. С>>Но не полностью, нет. G>Конечно, нужен же инструмент, в котором люди смогут писать программы с бешеными утечками памяти. G>Какая часть ниши Delphi еще не занята .NET?
— Шаровара. Дотнету уже много лет, а шароварную программу, написанную на дотнете, встретить не так просто. Ну, и судя по флеймам "Шаровара на С# — реально ли?", дотнет шароварщики не очень жалуют.
— Просто пример — Inno Setup. Он написан на делфи, писать аналог на дотнете — на данный момент не очень осмысленное занятие.
— Другой пример, из своего опыта. Не так давно писал GINA (модуль для Winlogon) на Delphi. Нужен был довольно-таки богатый интерфейс. Получилось быстро, все довольны. Возможно ли было написать такое на дотнете — думаю, нет, т.к. GINA — это DLL, экспортирующая строго определенный набор функций, которую загружает непосредственно winlogon.
Здравствуйте, gandjustas, Вы писали:
H>>Ты так и не понял Как ты у объекта спросишь, может ли он летать? (я надеюсь ты не станешь проверять его предков, типа Object Is TCanFlyObject?) У интерфейса ты позовешь QueryInterface(ICanFly, CanFlyIntf). Теперь понятно? G>Ну хватит уже показывать свое незнание. G>В C# вообще нету QueryInterface, приведение к типу интерфейса осуществляется темеже способами, что обычное приведение типа.
В Delphi это тоже есть (CanFlyIntf := FlyObject) (хотя семантические различия мне пофигу), да вот прикол: ты не можешь использовать такое приведение если не знаешь к чему приводить нужно. Расширяй сознание.
G>Из одного твоего предложения сразу видно что: а)ты не работал с .NET языками б)ты не работал на С++ в)ты не работал с COM не в Delphi г)ты плохо понимаешь зачем вообще нужны интерфейсы.
Прекрати расширять сознание. Ты обкурился.
H>>>>Ключевое значение имеет обеспечение возможности чилдов иметь парента, когда они хотят. G>>>А парент просто хранит ссылки на детей? H>>Что значит просто? Ну да, имеет список своих чилдов. G>Тогда такая ситуация нормально разрулится GC.
Ты как б... твердолобый. Я тебе про Фому, ты мне про Ерему...
G>>>>>ЗЫ С выделенным категорически не согласен. H>>>>Да-да, ведь рефакторинг это круто G>>>Не в рефакторигне дело. H>>А в чем? Будешь по десять раз редизайнить систему при малейших изменениях, вызванных недальновидным проектированием. G>Честно гворя даже не хочу тебе объяснять
Здравствуйте, gandjustas, Вы писали:
DOO>>>>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша. kuj>>>Кроме Delphi. Ее мини-ниша полностью занята .NET
С>>.NET, конечно, занял большую часть ниши Delphi. С>>Но не полностью, нет. G>Конечно, нужен же инструмент, в котором люди смогут писать программы с бешеными утечками памяти.
Я смотрю, ты с kuj'ем, два сапога -- пара. Скоро тоже отправишься в игнор.
G>Какая часть ниши Delphi еще не занята .NET?
Нативные десктоп-приложения, без тормозного рантайма и диких требований к мемори.
Здравствуйте, gandjustas, Вы писали:
H>>Да, интерфейсы Delphi бинарно совместимы с COM. Но интерфейсы могут иметь не только COM-объекты, и называть такие интерфейсы COM-интерфейсами нельзя. G>Каждый объект, реализующий интерфейс преобретает семантику COM-объекта. То есть при использовании становится фактически COM-объектом. G>Поэтому итнерфейсы в Delphi — именно COM-интерфейсы. G>Можешь не спорить, это факт.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, WolfHound, Вы писали:
WH>>Вот от тебя ничего кроме первого абзаца не слышно.
H>Уговорил. Есть задача, написать сервер XML-RPC. Реализовать гибкую систему API (подключение/отключение методов, группы методов в любой момент работы сервера). Как реализуются методы мы не знаем. Это могут быть и нативные объекты подключенные в виде некого API, это могут быть скриптовые методы, это может быть все что угодно. Сервер должен уметь валидировать список параметров методов, запрашиваемых на выполнение, с учетом возможной перегрузки методов и наличия дефолтных параметров. Сервер не должен навязывать какой либо идеологии в реализации подключаемых методов. Реализации API должны позволять расширять свою функциональность для получения дополнительных возможностей, например: протоколирования, перехвата, построения справочной информации, самоописания.
H>Это очень краткое описание. Для справки: мои парент и чилды, это абстракция ServiceObject (некое API) и MethodHandler (обработчик метода). ServiceObject являет собою некое API (какое, мы не знаем), и для каждого метода имеет MethodHandler.
H>Для примера кусочек реализации: H>
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Сергей, Вы писали:
С>>>.NET, конечно, занял большую часть ниши Delphi. С>>>Но не полностью, нет. G>>Конечно, нужен же инструмент, в котором люди смогут писать программы с бешеными утечками памяти. G>>Какая часть ниши Delphi еще не занята .NET?
С>- Шаровара. Дотнету уже много лет, а шароварную программу, написанную на дотнете, встретить не так просто. Ну, и судя по флеймам "Шаровара на С# — реально ли?", дотнет шароварщики не очень жалуют. С>- Просто пример — Inno Setup. Он написан на делфи, писать аналог на дотнете — на данный момент не очень осмысленное занятие. С>- Другой пример, из своего опыта. Не так давно писал GINA (модуль для Winlogon) на Delphi. Нужен был довольно-таки богатый интерфейс. Получилось быстро, все довольны. Возможно ли было написать такое на дотнете — думаю, нет, т.к. GINA — это DLL, экспортирующая строго определенный набор функций, которую загружает непосредственно winlogon.
Ты уверен что это ниши Delphi ?
Для таких задач по большей части C++ используют.
Здравствуйте, Сергей, Вы писали:
С>>>.NET, конечно, занял большую часть ниши Delphi. С>>>Но не полностью, нет. G>>Конечно, нужен же инструмент, в котором люди смогут писать программы с бешеными утечками памяти. G>>Какая часть ниши Delphi еще не занята .NET?
С>- Шаровара. Дотнету уже много лет, а шароварную программу, написанную на дотнете, встретить не так просто. Ну, и судя по флеймам "Шаровара на С# — реально ли?", дотнет шароварщики не очень жалуют.
Какого года твои сведенья? Либо .NET, либо C++. На Delphi единицы и в основном это legacy-проекты.
С>- Просто пример — Inno Setup. Он написан на делфи, писать аналог на дотнете — на данный момент не очень осмысленное занятие.
Есть Wix, который лучше за счет простоты использования в continous integration процессе.
С>- Другой пример, из своего опыта. Не так давно писал GINA (модуль для Winlogon) на Delphi. Нужен был довольно-таки богатый интерфейс. Получилось быстро, все довольны. Возможно ли было написать такое на дотнете — думаю, нет, т.к. GINA — это DLL, экспортирующая строго определенный набор функций, которую загружает непосредственно winlogon.
Пишешь .NET сборку со сколь угодно богатым интерфейсом, делаешь ее COM-visible. Пишешь dll на C++, которая будет выполнять роль медиатора. Все.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали: G>>Какая часть ниши Delphi еще не занята .NET?
H>Нативные десктоп-приложения, без тормозного рантайма и диких требований к мемори.
Насмешил. Скачай Paint.NET и попробуй тоже на Delphi повторить.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Ты так и не понял Как ты у объекта спросишь, может ли он летать? (я надеюсь ты не станешь проверять его предков, типа Object Is TCanFlyObject?) У интерфейса ты позовешь QueryInterface(ICanFly, CanFlyIntf). Теперь понятно? G>>Ну хватит уже показывать свое незнание. G>>В C# вообще нету QueryInterface, приведение к типу интерфейса осуществляется темеже способами, что обычное приведение типа. H>В Delphi это тоже есть (CanFlyIntf := FlyObject) (хотя семантические различия мне пофигу), да вот прикол: ты не можешь использовать такое приведение если не знаешь к чему приводить нужно. Расширяй сознание.
Новое слово в ООП — приведение типов, когда не заешь к чему приводить....
Здравствуйте, gandjustas, Вы писали:
H>>И что? Стало сильно понятнее?
G>Конечно стало понятнее. G>Еще раз убедился что подсчет ссылок в твоем решении то как раз ошибка выбора платформы.
Я знаю, что ты ничего не понял. Прибереги свою желчь.
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, gandjustas, Вы писали:
G>>Ты уверен что это ниши Delphi ? G>>Для таких задач по большей части C++ используют.
С>Скажем так, на мой взгляд, это области, в которых примененить Delphi зачастую оказывается эффективнее, чем дотнет.
Может быть, но это не ниша Delphi как ни крути.
Здравствуйте, gandjustas, Вы писали:
G>>>Какая часть ниши Delphi еще не занята .NET?
H>>Нативные десктоп-приложения, без тормозного рантайма и диких требований к мемори. G>Насмешил. Скачай Paint.NET и попробуй тоже на Delphi повторить.
Как раз недавно в новостях проскакивало. А вообще, создается впечатление, что нетерам, кроме Paint.Net и показывать-то больше нечего Прям замусолили его приводя в пример
Здравствуйте, hattab, Вы писали:
WH>>Вот от тебя ничего кроме первого абзаца не слышно.
H>Уговорил. Есть задача,
Это не задача. Это тоже решение.
H>написать сервер XML-RPC.
Изобретаете велосипеды? Жесть.
Открой для себя .NET Remoting
H>Реализовать гибкую систему API (подключение/отключение методов, группы методов в любой момент работы сервера). Как реализуются методы мы не знаем. Это могут быть и нативные объекты подключенные в виде некого API, это могут быть скриптовые методы, это может быть все что угодно. Сервер должен уметь валидировать список параметров методов, запрашиваемых на выполнение, с учетом возможной перегрузки методов и наличия дефолтных параметров. Сервер не должен навязывать какой либо идеологии в реализации подключаемых методов. Реализации API должны позволять расширять свою функциональность для получения дополнительных возможностей, например: протоколирования, перехвата, построения справочной информации, самоописания.
И для этой задачи вы выбрали Delphi?.... Посыпаю голову пеплом.
Здравствуйте, gandjustas, Вы писали:
H>>>>Ты так и не понял Как ты у объекта спросишь, может ли он летать? (я надеюсь ты не станешь проверять его предков, типа Object Is TCanFlyObject?) У интерфейса ты позовешь QueryInterface(ICanFly, CanFlyIntf). Теперь понятно? G>>>Ну хватит уже показывать свое незнание. G>>>В C# вообще нету QueryInterface, приведение к типу интерфейса осуществляется темеже способами, что обычное приведение типа. H>>В Delphi это тоже есть (CanFlyIntf := FlyObject) (хотя семантические различия мне пофигу), да вот прикол: ты не можешь использовать такое приведение если не знаешь к чему приводить нужно. Расширяй сознание.
G>Новое слово в ООП — приведение типов, когда не заешь к чему приводить....
Именно так. Именно поэтому интерфейсы. Начинай расширять сознание уже.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>И что? Стало сильно понятнее?
G>>Конечно стало понятнее. G>>Еще раз убедился что подсчет ссылок в твоем решении то как раз ошибка выбора платформы.
H>Я знаю, что ты ничего не понял. Прибереги свою желчь.
Читать мысли ты тоже не умеешь.
Задача вполне понятная. Пути решения её тоже.
Не вижу причин считать ссылки при реализации на .NET или Java
Здравствуйте, hattab, Вы писали:
G>>Новое слово в ООП — приведение типов, когда не заешь к чему приводить.... H>Именно так. Именно поэтому интерфейсы. Начинай расширять сознание уже.
Ржунимагу, уж простите.
Продублируй это сообщене на форуме по архитетуре ПО. Путь там посмеются кто КСВ не читает.
Здравствуйте, hattab, Вы писали:
G>>>>Ну хватит уже показывать свое незнание. G>>>>В C# вообще нету QueryInterface, приведение к типу интерфейса осуществляется темеже способами, что обычное приведение типа. H>>>В Delphi это тоже есть (CanFlyIntf := FlyObject) (хотя семантические различия мне пофигу), да вот прикол: ты не можешь использовать такое приведение если не знаешь к чему приводить нужно. Расширяй сознание.
G>>Новое слово в ООП — приведение типов, когда не заешь к чему приводить....
H>Именно так. Именно поэтому интерфейсы.
Валяюсь под столом!
H>Начинай расширять сознание уже.
Ты явно расширил уже... Подскажи, где такую забористую травку берешь?
Здравствуйте, kuj, Вы писали:
kuj>Какого года твои сведенья? Либо .NET, либо C++. На Delphi единицы и в основном это legacy-проекты.
Delphi, конечно, не самое популярное средство разработки шароварных программ.
Но мне как-то пока не встречались шароварные программы, написанные на дотнете.
А вот Delphi-программы — видел не одну.
kuj>Есть Wix, который лучше за счет простоты использования в continous integration процессе.
Лучше ли Wix, чем InnoSetup, спорить не хочу, но Wix — это другое. Это для создания MSI-инсталлеров.
kuj>Пишешь .NET сборку со сколь угодно богатым интерфейсом, делаешь ее COM-visible. Пишешь dll на C++, которая будет выполнять роль медиатора. Все.
С прослойкой на C++ можно и на яваскрипте написать.
Здравствуйте, gandjustas, Вы писали:
G>>>Новое слово в ООП — приведение типов, когда не заешь к чему приводить.... H>>Именно так. Именно поэтому интерфейсы. Начинай расширять сознание уже. G> G>Ржунимагу, уж простите.
Поржал? Теперь подумай: на момент проектирования класса/объекта ты не будешь знать к чему придется приводить твой объект. А может DOOM, именно об этой статике в голове говорил...
Здравствуйте, Сергей, Вы писали:
kuj>>Есть Wix, который лучше за счет простоты использования в continous integration процессе.
С>Лучше ли Wix, чем InnoSetup, спорить не хочу, но Wix — это другое. Это для создания MSI-инсталлеров.
И что? Чем не угодили MSI-инсталлеры? А про ClickOnce слышать доводилось?
kuj>>Пишешь .NET сборку со сколь угодно богатым интерфейсом, делаешь ее COM-visible. Пишешь dll на C++, которая будет выполнять роль медиатора. Все.
С>С прослойкой на C++ можно и на яваскрипте написать.
Богатый интерфейс на яваскрипте? Флаг в руки, ветер в спину.
Здравствуйте, hattab, Вы писали:
G>>>>Новое слово в ООП — приведение типов, когда не заешь к чему приводить.... H>>>Именно так. Именно поэтому интерфейсы. Начинай расширять сознание уже. G>> G>>Ржунимагу, уж простите.
H>Поржал? Теперь подумай: на момент проектирования класса/объекта ты не будешь знать к чему придется приводить твой объект. А может DOOM, именно об этой статике в голове говорил...
Ты еще и в ООП не бум-бум... Жесть.
Во-первых, в нормальных языках есть наследование, что позволяет присваивать разнородные объекты, унаследованные от общего суперкласса, к переменной типа суперкласса, где суперкласс — класс менее обобщенный, чем какой-нибудь System.Object, и тем самым значительно ограничить возможные ошибки на этапе компиляции.
Во-вторых, в нормальных языках есть интерфейсы, что позволяет присваивать разнородные объекты, реализующие этот интерфейс, к переменной типа этот интерфейс, что позволяет манипулировать данными объектами, как будто бы они все однородны — единообразно, и снимает зависимость от конкретной реализации.
В-третьих, в нормальных языках есть generic-типы, что позволяет на этапе компиляции максимально уточнить тип, что благоприятно сказывается на общем качестве кода, так как позволяет выявить многие проблемы еще на этапе компиляции.
Если это так, что это еще один камень в огород Делфи, ибо конструкция "INonCOMInterface = Interface(IUnknown)" в таком случае ни что иное, как полный бред.
G>>>>А то что они наследуют IUnknown ничего не значит уже?
H>>>Конечно не значит. Учи матчасть. G>>А что тогда занчит?
H>Значит семантика у них идентичная и все тут. Можно у второго поменять IUnknown на IInterface, но разницы не будет ибо это идентичные типы.
Семантика — поведение в данном случае. Если объект выглядит как COM и ведет себя как COM, почему он не является COM?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>>>Новое слово в ООП — приведение типов, когда не заешь к чему приводить.... H>>>Именно так. Именно поэтому интерфейсы. Начинай расширять сознание уже. G>> G>>Ржунимагу, уж простите.
H>Поржал? Теперь подумай: на момент проектирования класса/объекта ты не будешь знать к чему придется приводить твой объект. А может DOOM, именно об этой статике в голове говорил...
Да, буду. Объект всегда приводится к одному их базовых классах или к одному их реализуемых интерфейсов. Другого просто не может быть.
Здравствуйте, hattab, Вы писали:
H>Значит семантика у них идентичная и все тут. Можно у второго поменять IUnknown на IInterface, но разницы не будет ибо это идентичные типы.
"In programming, the IUnknown interface is the fundamental interface in the Component Object Model (COM). The published COM specification mandates that COM objects must minimally implement this interface. Furthermore, every other COM interface must be derived from IUnknown."
"IInterface
Basic interface for all COM based interfaces
Declaration
Source position: objpash.inc line 196
type IInterface = IUnknown;
Description
IInterface is the basic interface from which all COM style interfaces descend."
Здравствуйте, Дм.Григорьев, Вы писали:
_>>Сам я от большого программинга уже отошел ДГ>"Вот и ответ," — сказал Шекспир.
Ответ предполагает наличие вопроса. В исходном сообщении вопрос был задан только один, данный "ответ" к нему не подходит. Так на какой же вопрос эта фраза является ответом?
ДГ>Походу, тут большинство спорщиков "уже отошли".
Это неизбежно, ширпотребный кодинг -- это работа молодых. Для нешерпотребного же кодинга не нужно столько народу, излишек уходит в другие области.
Здравствуйте, hattab, Вы писали:
H>Повышение производительности за счет инлайнинга операций подсчета ссылок, это сродни полировке заклепок на танке, в надежде улучшить его аэродинамику.
Мда... Мозги у вас зашорены основательно. Ну подумайте сами — имеет ли смысл не инлайнить функции, расходы на исполнение которой сопоставимо с расходами на её вызов? Ведь в случае инлайна прирост производительности этого фрагмента будет очень серьёзным...
G>>>>>А то что они наследуют IUnknown ничего не значит уже?
H>>>>Конечно не значит. Учи матчасть. G>>>А что тогда занчит?
H>>Значит семантика у них идентичная и все тут. Можно у второго поменять IUnknown на IInterface, но разницы не будет ибо это идентичные типы. G>Семантика — поведение в данном случае. Если объект выглядит как COM и ведет себя как COM, почему он не является COM?
Да он (INonCOMInterface) даже не выглядит, как COM . Соглашение о вызовах в COM какое? А тут какое? Типы допустимые в COM, какие? А тут? Общаться с тобой все веселее и веселее...
Здравствуйте, koandrew, Вы писали:
H>>Повышение производительности за счет инлайнинга операций подсчета ссылок, это сродни полировке заклепок на танке, в надежде улучшить его аэродинамику.
K>Мда... Мозги у вас зашорены основательно. Ну подумайте сами — имеет ли смысл не инлайнить функции, расходы на исполнение которой сопоставимо с расходами на её вызов? Ведь в случае инлайна прирост производительности этого фрагмента будет очень серьёзным...
Цифры в студию Боюсь, только, даже на миллионе итераций разница будет в микросекундах. А теперь прикинь, как нечасто вызываются эти функции.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Mamut, Вы писали:
kuj>>>>>Не на столько разные, чтоб заморачиваться. M>>>>Очень разные. Erlang — не логический язык программирования.
kuj>>>Мамут как всегда на высоте... взял и обосрал Erlang. Мол, нелогичный он какой-то...
M>>Ты бы это... Взял бы и посмотрел на Эрланг, что ли. Prolog и Erlang — два абсолютно разных языка.
kuj>Эх, Мамут-Мамут, сам-то читал? Эрланг и Пролог — функциональные языки. Эрланг базируется на идентичном Прологу синтаксисе. Да, в Эрланг много всего того, чего нет в Прологе, но это не значит, что он хуже для преподавания. Скорее наоборот.
То, что они оба функциональные и то, что синтаксис Эрланга похож на паскалевский, не значит, что они взаимозаменяемы. Пролог ты Эрлангом не заменишь.
Здравствуйте, gandjustas, Вы писали:
G>>>>>Новое слово в ООП — приведение типов, когда не заешь к чему приводить.... H>>>>Именно так. Именно поэтому интерфейсы. Начинай расширять сознание уже. G>>> G>>>Ржунимагу, уж простите.
H>>Поржал? Теперь подумай: на момент проектирования класса/объекта ты не будешь знать к чему придется приводить твой объект. А может DOOM, именно об этой статике в голове говорил... G>Да, буду. Объект всегда приводится к одному их базовых классах или к одному их реализуемых интерфейсов. Другого просто не может быть.
Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface.
Здравствуйте, hattab, Вы писали:
H>>>Повышение производительности за счет инлайнинга операций подсчета ссылок, это сродни полировке заклепок на танке, в надежде улучшить его аэродинамику.
K>>Мда... Мозги у вас зашорены основательно. Ну подумайте сами — имеет ли смысл не инлайнить функции, расходы на исполнение которой сопоставимо с расходами на её вызов? Ведь в случае инлайна прирост производительности этого фрагмента будет очень серьёзным...
H>Цифры в студию Боюсь, только, даже на миллионе итераций разница будет в микросекундах. А теперь прикинь, как нечасто вызываются эти функции.
Хохо, и это говорит человек, который сравнивал Delphi и .NET бенчмарком со 100 млн. итераций. Браво-браво... Называется, за что боролись, на то и напоролись.
Здравствуйте, hattab, Вы писали:
G>>>>>>Новое слово в ООП — приведение типов, когда не заешь к чему приводить.... H>>>>>Именно так. Именно поэтому интерфейсы. Начинай расширять сознание уже. G>>>> G>>>>Ржунимагу, уж простите.
H>>>Поржал? Теперь подумай: на момент проектирования класса/объекта ты не будешь знать к чему придется приводить твой объект. А может DOOM, именно об этой статике в голове говорил... G>>Да, буду. Объект всегда приводится к одному их базовых классах или к одному их реализуемых интерфейсов. Другого просто не может быть.
H>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface.
Здравствуйте, kuj, Вы писали:
H>>Значит семантика у них идентичная и все тут. Можно у второго поменять IUnknown на IInterface, но разницы не будет ибо это идентичные типы.
kuj>"In programming, the IUnknown interface is the fundamental interface in the Component Object Model (COM). The published COM specification mandates that COM objects must minimally implement this interface. Furthermore, every other COM interface must be derived from IUnknown."
kuj>"IInterface
kuj>Basic interface for all COM based interfaces kuj>Declaration
kuj>Source position: objpash.inc line 196
kuj>type IInterface = IUnknown; kuj>Description
kuj>IInterface is the basic interface from which all COM style interfaces descend."
kuj>hattab, хватит уже расширять свое сознание.
ignore off
Я и сказал, что IInterface это идентичный IUnknown тип. Тебе чего-то не понятно? Сперва разберись с моим примером на INonCOMInterface, а потом будешь мне статейки для чайников цитировать
H>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface.
Для таких случаев делается wrapper-объект, который содержит старый объект в виде приватной переменной. И?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, kuj, Вы писали:
H>>>Значит семантика у них идентичная и все тут. Можно у второго поменять IUnknown на IInterface, но разницы не будет ибо это идентичные типы.
kuj>>"In programming, the IUnknown interface is the fundamental interface in the Component Object Model (COM). The published COM specification mandates that COM objects must minimally implement this interface. Furthermore, every other COM interface must be derived from IUnknown."
kuj>>"IInterface
kuj>>Basic interface for all COM based interfaces kuj>>Declaration
kuj>>Source position: objpash.inc line 196
kuj>>type IInterface = IUnknown; kuj>>Description
kuj>>IInterface is the basic interface from which all COM style interfaces descend."
kuj>>hattab, хватит уже расширять свое сознание.
H>ignore off
H>Я и сказал, что IInterface это идентичный IUnknown тип. Тебе чего-то не понятно? Сперва разберись с моим примером на INonCOMInterface, а потом будешь мне статейки для чайников цитировать
H>ignore on
Все мои знания по ООП говорят мне, что оба раза мы создали COM-объект, унаследовавшись от базового COM-интерфейса. То, что второй объект не имеет методов, доступных из других COM-обхектов (в частности, они не используют стандартные COM-типы), никак этому факту не противоречит
Здравствуйте, hattab, Вы писали:
H>Я и сказал, что IInterface это идентичный IUnknown тип.
Ликбез: IInterface — наследник IUnknown.
H>Тебе чего-то не понятно? Сперва разберись с моим примером на INonCOMInterface, а потом будешь мне статейки для чайников цитировать
Ты разберись со "стейками для чайников" потом будешь говорить что мне делать, ок?
Здравствуйте, Mamut, Вы писали:
M>Все мои знания по ООП говорят мне, что оба раза мы создали COM-объект, унаследовавшись от базового COM-интерфейса. То, что второй объект не имеет методов, доступных из других COM-обхектов (в частности, они не используют стандартные COM-типы), никак этому факту не противоречит
Это верно с одним но — оба интерфейса автоматически наследуют все методы родительского интерфейса IUnknown: AddRef, Release, QueryInterface.
Здравствуйте, Mamut, Вы писали:
H>>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface.
M>Для таких случаев делается wrapper-объект, который содержит старый объект в виде приватной переменной. И?
В .NET и Java в таком случае обычно используется IoC/DI контейнер: класс зависит только от интерфейса, а любую новую имплементацию можно в любой момент зарегистрировать в runtime или в файле конфигурации — без каких-либо модификаций в коде.
Здравствуйте, hattab, Вы писали:
H>Цифры в студию Боюсь, только, даже на миллионе итераций разница будет в микросекундах. А теперь прикинь, как нечасто вызываются эти функции.
Немного пугает лёгкость с которой ты бросаешься терагерцами.
Здравствуйте, Mamut, Вы писали:
H>>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface.
M>Для таких случаев делается wrapper-объект, который содержит старый объект в виде приватной переменной. И?
Да-да, все сводится к рождению своего Query-blah-blah-blah
Здравствуйте, Mamut, Вы писали:
H>>>>Значит семантика у них идентичная и все тут. Можно у второго поменять IUnknown на IInterface, но разницы не будет ибо это идентичные типы.
kuj>>>"In programming, the IUnknown interface is the fundamental interface in the Component Object Model (COM). The published COM specification mandates that COM objects must minimally implement this interface. Furthermore, every other COM interface must be derived from IUnknown."
kuj>>>"IInterface
kuj>>>Basic interface for all COM based interfaces kuj>>>Declaration
kuj>>>Source position: objpash.inc line 196
kuj>>>type IInterface = IUnknown; kuj>>>Description
kuj>>>IInterface is the basic interface from which all COM style interfaces descend."
kuj>>>hattab, хватит уже расширять свое сознание.
H>>ignore off
H>>Я и сказал, что IInterface это идентичный IUnknown тип. Тебе чего-то не понятно? Сперва разберись с моим примером на INonCOMInterface, а потом будешь мне статейки для чайников цитировать
H>>ignore on
M>Все мои знания по ООП говорят мне, что оба раза мы создали COM-объект, унаследовавшись от базового COM-интерфейса. То, что второй объект не имеет методов, доступных из других COM-обхектов (в частности, они не используют стандартные COM-типы), никак этому факту не противоречит
У интерфейсов нет понятий видимости или невидимости методов. Интерфейс рассматривается только в целом. Тот факт, что второй интерфейс не совместим с типами COM, делает его не COM интерфейсом.
Здравствуйте, kuj, Вы писали:
H>>Я и сказал, что IInterface это идентичный IUnknown тип.
kuj>Ликбез: IInterface — наследник IUnknown.
В статейках для чайников еще и не такое пишут. IUnknown = IInterface; (system.pas; line: 257)
H>>Тебе чего-то не понятно? Сперва разберись с моим примером на INonCOMInterface, а потом будешь мне статейки для чайников цитировать
kuj>Ты разберись со "стейками для чайников" потом будешь говорить что мне делать, ок?
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, hattab, Вы писали: H>>Цифры в студию Боюсь, только, даже на миллионе итераций разница будет в микросекундах.
MC>Вызов функции — это сброс конвейера. Ничего хорошего в этом нет.
Нужно понимать, что предлагают инлайнить. Предлагают инлайнить функции вызывающиеся настолько редко, что ни какой выгоды от этого мы не получим вообще.
Здравствуйте, Don Reba, Вы писали:
H>>Цифры в студию Боюсь, только, даже на миллионе итераций разница будет в микросекундах. А теперь прикинь, как нечасто вызываются эти функции.
DR>Немного пугает лёгкость с которой ты бросаешься терагерцами.
Здравствуйте, hattab, Вы писали: H>Нужно понимать, что предлагают инлайнить. Предлагают инлайнить функции вызывающиеся настолько редко, что ни какой выгоды от этого мы не получим вообще.
Можно взглянуть на это и по-другому. Функции вызываются редко, следовательно, проигрыш в размере исполняемого файла будет невелик.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, hattab, Вы писали: H>>Нужно понимать, что предлагают инлайнить. Предлагают инлайнить функции вызывающиеся настолько редко, что ни какой выгоды от этого мы не получим вообще.
MC>Можно взглянуть на это и по-другому. Функции вызываются редко, следовательно, проигрыш в размере исполняемого файла будет невелик.
Представь другую ситуацию: их много и они размазаны по сложному коду, где на один их вызов будет происходить куча других операций. Я вообще не понимаю фига это обсуждать без цифр полученных на реальном приложении
Здравствуйте, koandrew, Вы писали:
H>>Повышение производительности за счет инлайнинга операций подсчета ссылок, это сродни полировке заклепок на танке, в надежде улучшить его аэродинамику.
K>Мда... Мозги у вас зашорены основательно. Ну подумайте сами — имеет ли смысл не инлайнить функции, расходы на исполнение которой сопоставимо с расходами на её вызов? Ведь в случае инлайна прирост производительности этого фрагмента будет очень серьёзным...
Меня вдруг осенило! А их же вообще нельзя заинлайнить, это же методы интерфейса, о реализации которого, по определению, компилятор не имеет понятия
Здравствуйте, hattab, Вы писали: H>Представь другую ситуацию: их много и они размазаны по сложному коду, где на один их вызов будет происходить куча других операций. Я вообще не понимаю фига это обсуждать без цифр полученных на реальном приложении
Без цифр — согласен, фигово. Однако вызов функции посреди сложного кода будет негативно сказываться на его производительности (хотя со сбросом конвейера я погорячился, конечно — но негатив будет хотя бы из-за того, что выборка команд не будет последовательной — а будет "скакать").
Здравствуйте, _d_m_, Вы писали: ___>Синклар, от тебя не ожидал — это не аргумент. Угробищную программу можно написать на любом языке,
Совершенно верно. Это и был мой аргумент.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kuj, Вы писали: kuj>Смею предположить, что сие утверждение просто говорит о том, что ты плохо знаешь Java. Да, лет семь уже на ней не писал ничего.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, hattab, Вы писали:
H>Меня вдруг осенило! А их же вообще нельзя заинлайнить, это же методы интерфейса, о реализации которого, по определению, компилятор не имеет понятия
Неверно тебя осенило Я не предлагал инлайнить реализацию Release() (хотя современные С++ компиляторы в ряде случаев умеют устранять виртуальность ) — говорю о ф-ции IntfClear или как она там называется. Сама ф-ция — десяток ассемблерных команд, поэтому время их выполнения будет сравнимо с временем вызова ф-ции. Но дело не в этом конкретном случае — вам тут уже рекомендовали расширить сознание — если компилер не может инлайнить даже такие простые случаи, то он не может инлайнить ничего вообще. Кстати об этом косвенно говорит тот факт, что дельфи-программы можно построчно дебажить в релизном варианте (что автоматически означает отсутствие всяких инлайнов).
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, _d_m_, Вы писали:
kuj>>>В действительности вышеописанных граблей ни в одной нормальной среде разработки быть не должно.
kuj>>>Конечно определенные грабли есть везде — где-то меньше, где-то больше. Регулярно пользуюсь VS 2005, VS 2008, пару лет тому назад еще IntelliJ IDEA в арсенале была. Все отлично — на грабли натыкаться не приходиться, работать одно удовольствие.
___>>Да есть тоже немножко. Сейчас пользуем VS 2005 SP1: ___>>- Если попробовать в док. комментариях добавить для достаточно большого файла ___>>/// <summary> ___>>/// asda ___>>/// </summary> ___>>/// <param name="dsda"> asas /</param> ___>>вот например в этом месте попытаться напечатать слэш — студия виснет.
kuj>Хмм, интересно. На сколько большой должен быть файл, чтоб студия зависла? На .cs в 360kB не виснет и не тормозит... Большего cs-файла под рукой нету...
Ну не такой уж большой — 69К. Проблема проявляется именно в этом файле. Скорее всего проблема возникает из-за содержимого, но то что проблема воспроизводима — это факт.
___>>- До SP1 одолевал WinForms дизайнер — открываешь допустим свой контрол, а на нем кнопки съехали. Ну это уже не в счет.
kuj>Не сталкивался. Я, правда, с WinForms мало работаю.
___>>- WinForms дизайнер — шрифты в дизайнере могут оказаться другого размера, чем на реальной форме.
kuj>Это как? Можно сценарий для воспроизведения?
Вот:
Слева кнопка в дизайнере, справа реально запущенное приложение. MS Sans Serif 9.75pt.
___>>- Есть проблемы с дизайнером ReportViewer-а — преобразование единиц измерения, например мм-см, и прочие мелочи типа неверного преобразования margins страницы — это самое неприятное.
kuj>Ну это скорее глюк ReportViewer`а?
Здравствуйте, hattab, Вы писали:
H>У интерфейсов нет понятий видимости или невидимости методов. Интерфейс рассматривается только в целом. Тот факт, что второй интерфейс не совместим с типами COM, делает его не COM интерфейсом.
COM интерфейсом делает наследие от IUnknown.
Методы в принципе могут быть любыми. Если ты используешь другое соглашение о вызове, то этот объект может быть использовать только в среде Delphi. Если аргументы не являются variant — совместимыми, то нелюзя вызывать метоеды через IDispatch.
Здравствуйте, hattab, Вы писали:
H>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface.
Ты сейчас как-то криво рассказал про фабрику классов. Тольео её придумали гораздо раньше COM
Кстати COM нужен не для получения сущности (хотя непонятно чт ты имеешь ввиду) о наличии которой неизвестно на момент проектирования.
COM — бинарный стандарт повтороно используемых компонент. Все компоненты знают на момент проектирования какие инерфейсы они поддерживают
В статье есть ответ ровно на один вопрос: какие порты. Больше ровным счетом ничего — ни механизма обмена (со стороны ОС, а не .Net сборки), ни методов аутентификации, ничего. Еще раз повторяю — даже если кодер не заморачивается такими вопросами (вообще говоря, и не должен) — все эти вопросы должны появится в голове у архитектора.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, DOOM, Вы писали:
DOO>>Здравствуйте, kuj, Вы писали:
kuj>>>1. У Javascript есть нормальный garbage collector. Ему не нужны smart pointer`ы. DOO>>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша. G>Не показывай свою необразованность. В C нет обънектов, смарт поинтеры там не нужны.
Хорош уже откровенно тупить — где написано, что как только появляются объекты, то нужны смарт пойнтеры? Ты бы еще сказал, что на C нельзя написать <подставь сюда свой типичный проект>, потому что там нет объектов! Я тебе и привожу примеры, где прекрасно живется без твоих смарт пойнтеров — не важно по какой причине. В дельфи, к пример, все наследники TComponent'а в обязательном порядке обладают owner'ом — который отвечает за убийство своих подопечных, когда умирает сам. Соответственно все завязано на основную форму приложения, а значит все объекты будут корректно уничтожены рано или поздно — это вариант борьбы с отсутствием автоматического контроля времени жизни объекта. И, если человек хоть немного понимает, что такое указатель, объект и т.п., то у него не будет проблем с утечками.
Почему что, господа апологеты C++ забывают про знаменитые грабли под названием конструктор копирования, например — вот уж сколько ошибок вызывает его некорректное определение или непонимание, когда он вызовется.
kuj>>>2. Делфи — динамический язык? DOO>>В достаточной мере. G>Не более динаический, чем С++. Можно везде писать (void*) и кастить при каждом обращении.
Да... Ну ладно — тогда создай мне экземпляр класса по его строковому имени в ран-тайме. Или хотя бы перечисли методы объекта в ран-тайме.
Да, конечно, в Дельфи нету JIT'а, но и статическим строго типизированным его не назовешь.
kuj>>>А Борланд об этом знает? DOO>>Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать. G>Наверное ворнинги не от хорошей жизни.
Ворнинги от того, что в .Net банально многое нельзя, а значит программа не перенесется в среду .Net.
kuj>>>Ликбез: Delphi, C++ и C# — статические строго типизированные языки. DOO>>На вскидку из гугла: DOO>>
DOO>>TabGrid := VarArrayCreate([0,(R - 1),0,(C - 1)],VarOleStr);
DOO>> I := 0;
DOO>> // Определяем цикл для заполнения массива-матрицы
DOO>> repeat
DOO>> for J := 0 to (C - 1) do
DOO>> TabGrid[I,J] := GenericStringGrid.Cells[J,I];
DOO>> Inc(I,1);
DOO>> until
DOO>> I > (R - 1);
DOO>>
DOO>>Опа. Не попадает как-то в узкие рамки статической строгой типизации? Причем заметь — надо писать не что-то вроде SetVariantArrayValue(TabGrid,i,j), а просто TabGrid[i,j] — при этом TabGrid не является массивом до момента выполнения строчки TabGrid := VarArrayCreate([0,(R — 1),0,(C — 1)],VarOleStr); G>И ты этим гордишься? Это бездонная бочка ошибок на самом деле.
kuj>>>Ликбез: Delphi, C++ и C# — статические строго типизированные языки.
DOO>>На вскидку из гугла:
Я не горжусь, а показываю тебе, да kuj'у ваши заблуждения. А твоя фраза очень неплохо попадает под один из приемов женской логики:
* В женской логике каждое утверждение может быть не только опровергнуто, но и отвергнуто. Отвергая высказывание, вы признаете его бессмысленным и оставляете без внимания. Если вы отвергли последнее высказывание собеседницы, ваше предпоследнее утверждение остается без ответа и, таким образом, становится доказанным. Например, самые основательные соображения можно отвергнуть словами "Ну и что?" или "А больше ничего не смог придумать?".
Так что подумай над своими методами ведения спора.
DOO>>Ну а ты пальцы гнуть бы завязывал... G>Ты бы завязывал писать глупости
А ты покажи хотя бы одну. Да еще обоснованно.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, DOOM, Вы писали:
kuj>>>1. У Javascript есть нормальный garbage collector. Ему не нужны smart pointer`ы. DOO>>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша. kuj>Кроме Delphi. Ее мини-ниша полностью занята .NET
Во-первых, RAD — это не мини ниша.
Во-вторых, я и не спорю. Хот замечу, что Qt под Linux пока сильнее, чем Mono...
kuj>>>2. Делфи — динамический язык? DOO>>В достаточной мере. kuj>Скажу тебе по секрету Delphi никогда не был, не является, и вряд ли когда-то станет динамическим языком.
В полной мере нет. Но не все так строго делится на белое и черное. Delphi является более динамическим, чем C++, например.
kuj>>>А Борланд об этом знает? DOO>>Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать. kuj>И при чем тут динамические языки?
Это к вопросу о статической типизации. Или ты под динамическим языком понимаешь только тот, у которого есть функция типа eval?
kuj>>>Если хочешь посмотреть на динамический язык возьми ruby или python, например. DOO>>Кстати, мое первое впечатление от питона было — о! Дельфи в виде скрипта. Очень много похожего. kuj>Всего-лишь говорит о твоей низкой квалификации, если для тебя "Питон — это дельфи в виде скрипта".
Я бы на твоем месте ярлыки не вешал и квалификацию других людей не оценивал.
kuj>>>Ликбез: Delphi, C++ и C# — статические строго типизированные языки. DOO>>На вскидку из гугла: DOO>>
DOO>>TabGrid := VarArrayCreate([0,(R - 1),0,(C - 1)],VarOleStr);
DOO>> I := 0;
DOO>> // Определяем цикл для заполнения массива-матрицы
DOO>> repeat
DOO>> for J := 0 to (C - 1) do
DOO>> TabGrid[I,J] := GenericStringGrid.Cells[J,I];
DOO>> Inc(I,1);
DOO>> until
DOO>> I > (R - 1);
DOO>>
DOO>>Опа. Не попадает как-то в узкие рамки статической строгой типизации? Причем заметь — надо писать не что-то вроде SetVariantArrayValue(TabGrid,i,j), а просто TabGrid[i,j] — при этом TabGrid не является массивом до момента выполнения строчки TabGrid := VarArrayCreate([0,(R — 1),0,(C — 1)],VarOleStr);
kuj>VarArrayCreate создает массив значений типа Variant. При чем тут динамические языки? Ты, батенька, серьезно не в теме.
В VBscript'е любая переменаая это тоже Variant — если ты внедришь движок VB через соответсвующий COM объект в свою программу, то ты даже сможешь получать к ним доступ. Вопрос в прямой поддержке со стороны языка — VBScript поддерживает эти Variant'ы прозрачно, Delphi — тоже, C++ — нет. Соотвественно нельзя говорить, что в Delphi статическая типизация. Все, что отличает его от какого-нибудь скрипта — это отсутствие функции типа eval. Это делает Дельфи некоторым промежуточным языком, но ни как не "статическим языком со строгой типизацией".
Еще интереснее было бы поглядеть на внутренности Perl'а и, так называемые, xsub — здесь уже получается смесь перловского интерфейса с классическим. Дак что, после этого Perl становится статическим языком со строгой типизацией?
kuj>Проку от них ровно столько, сколько проку от подобного контейнера в Delрhi. Кроме того, что я могу явно ограничить супертип, что уменьшит поле для ошибок на этапе компиляции. Вообщем, ты снова явно не в теме.
Для особо одаренных напомню, что в дельфи все объпекты потомки TObject — т.е. супертип уже ограничен. Прямо такой уж жизненной необходимости отсекать дерево при помощи какого-то промежуточного объекта я не вижу — это можно сделать еще в куче мест, в том числе в рантайме.
P.S. Выделенное я мог бы тебе сказать уже раз так много, но не имею привычки судить о познаниях человека заочно. Тебе бы тоже не советовал.
Здравствуйте, DOOM, Вы писали:
DOO>Хорош уже откровенно тупить — где написано, что как только появляются объекты, то нужны смарт пойнтеры? Ты бы еще сказал, что на C нельзя написать <подставь сюда свой типичный проект>, потому что там нет объектов!
Смарт-поинтеры нужны в C++, потому что можно забытьнаписать delete. Они также нужны в Delph, потому что там можно забыть написать Free.
Любоую программу можно написать без объектов, только вопрос времени.
DOO>Я тебе и привожу примеры, где прекрасно живется без твоих смарт пойнтеров — не важно по какой причине.
Что-то я не увидел примеров.
DOO>В дельфи, к пример, все наследники TComponent'а в обязательном порядке обладают owner'ом — который отвечает за убийство своих подопечных, когда умирает сам.
Только далеко не все классы являются наследниками TComponent DOO>Соответственно все завязано на основную форму приложения, а значит все объекты будут корректно уничтожены рано или поздно — это вариант борьбы с отсутствием автоматического контроля времени жизни объекта.
Выделенное — офигенный недостаток.
DOO>И, если человек хоть немного понимает, что такое указатель, объект и т.п., то у него не будет проблем с утечками.
В .NET и Java у человека не будет проблем с утечками даже если он не понимает указатели.
kuj>>>>2. Делфи — динамический язык? DOO>>>В достаточной мере. G>>Не более динаический, чем С++. Можно везде писать (void*) и кастить при каждом обращении. DOO>Да... Ну ладно — тогда создай мне экземпляр класса по его строковому имени в ран-тайме. Или хотя бы перечисли методы объекта в ран-тайме.
В С++ нет метаданных, поэтому такое невозможно. Но налитчие метаданных не делает язык динамическим.
В .NET и Java есть метаданные, но они не позиционируются как динамические языки.
DOO>Да, конечно, в Дельфи нету JIT'а, но и статическим строго типизированным его не назовешь.
Еще как назовешь. В динамических языках контроль типа осуществляется на стадии компиляции. Нельязя в делфи сравнить число со строкой, будет ошибка компиляции. то и есть проявление счтатической типизации.
В Javascript например написать сравнение числа со строкой вполне можно, это вызвоет ошибку времени выполнения.
DOO>Ворнинги от того, что в .Net банально многое нельзя, а значит программа не перенесется в среду .Net.
В .NET можно сделать все, что можно в делфи.
DOO>Так что подумай над своими методами ведения спора.
То есть ты хочешь сказать что использование вариантных типов не приводит к увечличению числа ошибок?
DOO>>>Ну а ты пальцы гнуть бы завязывал... G>>Ты бы завязывал писать глупости DOO>А ты покажи хотя бы одну. Да еще обоснованно.
Глупость номер раз — Delphi динамический язык
Глупость номер два — использование вариантных типов везде.
Здравствуйте, hattab, Вы писали:
H>Я не говорю о плюсах Абрамса (а Oracle стоял на Тамагавках), я говорю, что этот факт хоть как-то, но характеризует Interbase
Нет, этот факт характеризует Абрамс — да и никто не застрахован от неудачных решений и выбора. А с Interbase я знаком не понаслышке и мне есть с чем сравнивать. Даже ярые апологеты FB отзаваются об Interbase достаточно не лестно.
H>Вот еще: H>
Еще
H> один малоизвестный факт — использование InterBase для хранения
H> информации о кредитках в считывающих устройствах, которые используются
H> на немецких железных дорогах — одной из самых быстрых и развитых
H> транспортных систем в мире.
"никто не застрахован от неудачных решений и выбора". И это вероятно случилось после того, как исходники IB были выложены Богланд, видать сами рихтуют косяки.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Сергей, Вы писали:
kuj>>>Есть Wix, который лучше за счет простоты использования в continous integration процессе.
С>>Лучше ли Wix, чем InnoSetup, спорить не хочу, но Wix — это другое. Это для создания MSI-инсталлеров.
kuj>И что? Чем не угодили MSI-инсталлеры? А про ClickOnce слышать доводилось?
kuj>>>Пишешь .NET сборку со сколь угодно богатым интерфейсом, делаешь ее COM-visible. Пишешь dll на C++, которая будет выполнять роль медиатора. Все.
С>>С прослойкой на C++ можно и на яваскрипте написать.
kuj>Богатый интерфейс на яваскрипте? Флаг в руки, ветер в спину.
А в чем проблема? Можно и интерфейс. Можно и прямо COM объект настрочить на JS (точнее, конечно, это WSH)... Не знал?
Здравствуйте, koandrew, Вы писали:
H>>Меня вдруг осенило! А их же вообще нельзя заинлайнить, это же методы интерфейса, о реализации которого, по определению, компилятор не имеет понятия
K>Неверно тебя осенило Я не предлагал инлайнить реализацию Release() (хотя современные С++ компиляторы в ряде случаев умеют устранять виртуальность ) — говорю о ф-ции IntfClear или как она там называется. Сама ф-ция — десяток ассемблерных команд, поэтому время их выполнения будет сравнимо с временем вызова ф-ции. Но дело не в этом конкретном случае — вам тут уже рекомендовали расширить сознание — если компилер не может инлайнить даже такие простые случаи, то он не может инлайнить ничего вообще. Кстати об этом косвенно говорит тот факт, что дельфи-программы можно построчно дебажить в релизном варианте (что автоматически означает отсутствие всяких инлайнов).
Delphi программы в релизном варианте не поотлаживаешь. Отключи DebugInfo и отладчик работать перестанет. По поводу IntfClear... Ты сам понимаешь нелепость своего предложения об инлайне? Давай уже цифры.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, hattab, Вы писали: H>>Цифры в студию Боюсь, только, даже на миллионе итераций разница будет в микросекундах.
MC>Вызов функции — это сброс конвейера. Ничего хорошего в этом нет.
Здравствуйте, DOOM, Вы писали:
kuj>>Богатый интерфейс на яваскрипте? Флаг в руки, ветер в спину. DOO>А в чем проблема? Можно и интерфейс. Можно и прямо COM объект настрочить на JS (точнее, конечно, это WSH)... Не знал?
Да ну, а пример покажешь?
Здравствуйте, gandjustas, Вы писали:
H>>У интерфейсов нет понятий видимости или невидимости методов. Интерфейс рассматривается только в целом. Тот факт, что второй интерфейс не совместим с типами COM, делает его не COM интерфейсом. G>COM интерфейсом делает наследие от IUnknown.
G>Методы в принципе могут быть любыми. Если ты используешь другое соглашение о вызове, то этот объект может быть использовать только в среде Delphi. Если аргументы не являются variant — совместимыми, то нелюзя вызывать метоеды через IDispatch.
И при чем тут IDispatch
G>Ты бы лучше про COM прочитал сначала.
Если спека X-Man имеет десять пунктов, а ты соответствуешь только одному... Тебя можно назвать X-Man? Лечи голову, Вилли (с)
Здравствуйте, gandjustas, Вы писали:
H>>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface. G>Ты сейчас как-то криво рассказал про фабрику классов. Тольео её придумали гораздо раньше COM
Фабрика-то ту при чем? В своем ли ты уме??
G>Кстати COM нужен не для получения сущности (хотя непонятно чт ты имеешь ввиду) о наличии которой неизвестно на момент проектирования. G>COM — бинарный стандарт повтороно используемых компонент. Все компоненты знают на момент проектирования какие инерфейсы они поддерживают
Я уж и не знаю, какие тебе еще примеры приводить, чтоб ты понял... Вот прикинь, получил ты интерфейс IUnknown (неважно, как и от кого), ты можешь запросить у него интерфейс ICanFly? Можешь. Можешь даже в том случае, если реализующий (IUnknown) объект не имеет понятия о ICanFly. Теперь давай тоже самое с объектами.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>И при чем тут IDispatch
А ты почитай — узнаешь
G>>Ты бы лучше про COM прочитал сначала. H>Если спека X-Man имеет десять пунктов, а ты соответствуешь только одному... Тебя можно назвать X-Man? Лечи голову, Вилли (с)
А ты читал спеку по COM?
В книге дональда боска (архитектора COM ксати) написано что любой интерфейс — наследник от IUnknown является COM интерфейсом.
Здравствуйте, gandjustas, Вы писали:
H>>И при чем тут IDispatch G>А ты почитай — узнаешь
Ты мне предлагаешь почитать о том, что мне приходилось реализовывать Я тебе свой пример XML-RPC вызова приводил через диспатчинг (сразу скажу, диспатчинг делаю я сам), аль ты забыл?
G>>>Ты бы лучше про COM прочитал сначала. H>>Если спека X-Man имеет десять пунктов, а ты соответствуешь только одному... Тебя можно назвать X-Man? Лечи голову, Вилли (с) G>А ты читал спеку по COM? G>В книге дональда боска (архитектора COM ксати) написано что любой интерфейс — наследник от IUnknown является COM интерфейсом.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface. G>>Ты сейчас как-то криво рассказал про фабрику классов. Тольео её придумали гораздо раньше COM
H>Фабрика-то ту при чем? В своем ли ты уме??
При том. Создание объекта, тип которого известен только во время выполенения — задача фабрки\фабричного метода.
H>Я уж и не знаю, какие тебе еще примеры приводить, чтоб ты понял... Вот прикинь, получил ты интерфейс IUnknown (неважно, как и от кого), ты можешь запросить у него интерфейс ICanFly? Можешь. Можешь даже в том случае, если реализующий (IUnknown) объект не имеет понятия о ICanFly. Теперь давай тоже самое с объектами.
Ну на C# я напишу
(obj as IInterface)//Если obj реализует IInterface, то вернется переменная этого типа, иначе будет null.
При этом человек, который писал о класс объекта obj мог и не знать о существовании IInterface.
Ты вообще знаешь для чего QueryInterface придумали?
Здравствуйте, gandjustas, Вы писали: G>Еще как назовешь. В динамических языках контроль типа осуществляется на стадии компиляции. Нельязя в делфи сравнить число со строкой, будет ошибка компиляции.
Можно. Еще как можно. Более того, в Delphi можно сделать вызов метода, которого объект не поддерживает, и узнать об этом только в рантайме. В точности, как в JS. Вот этот код прекрасно скомпилируется:
var
obj: Variant;
begin
obj.FillRect(100, 200, 10, 15, "Blue");
end;
Это и есть проявление динамической типизации.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>И при чем тут IDispatch G>>А ты почитай — узнаешь
H>Ты мне предлагаешь почитать о том, что мне приходилось реализовывать Я тебе свой пример XML-RPC вызова приводил через диспатчинг (сразу скажу, диспатчинг делаю я сам), аль ты забыл?
Маладец!!!
G>>>>Ты бы лучше про COM прочитал сначала. H>>>Если спека X-Man имеет десять пунктов, а ты соответствуешь только одному... Тебя можно назвать X-Man? Лечи голову, Вилли (с) G>>А ты читал спеку по COM? G>>В книге дональда боска (архитектора COM ксати) написано что любой интерфейс — наследник от IUnknown является COM интерфейсом. H>Прекращай тупить.
Аргументы кончились?
Здравствуйте, gandjustas, Вы писали:
H>>>>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface. G>>>Ты сейчас как-то криво рассказал про фабрику классов. Тольео её придумали гораздо раньше COM
H>>Фабрика-то ту при чем? В своем ли ты уме?? G>При том. Создание объекта, тип которого известен только во время выполенения — задача фабрки\фабричного метода.
Так нам не требуется ничего создавать. Нужно узнать у сущности, умеет ли она летать.
H>>Я уж и не знаю, какие тебе еще примеры приводить, чтоб ты понял... Вот прикинь, получил ты интерфейс IUnknown (неважно, как и от кого), ты можешь запросить у него интерфейс ICanFly? Можешь. Можешь даже в том случае, если реализующий (IUnknown) объект не имеет понятия о ICanFly. Теперь давай тоже самое с объектами.
G>Ну на C# я напишу G>
G> (obj as IInterface)//Если obj реализует IInterface, то вернется переменная этого типа, иначе будет null.
G>
G>При этом человек, который писал о класс объекта obj мог и не знать о существовании IInterface.
А что произойдет в момент компиляции, если obj не реализует IInterface?
G>Ты вообще знаешь для чего QueryInterface придумали?
Здравствуйте, gandjustas, Вы писали:
G>>>>>Ты бы лучше про COM прочитал сначала. H>>>>Если спека X-Man имеет десять пунктов, а ты соответствуешь только одному... Тебя можно назвать X-Man? Лечи голову, Вилли (с) G>>>А ты читал спеку по COM? G>>>В книге дональда боска (архитектора COM ксати) написано что любой интерфейс — наследник от IUnknown является COM интерфейсом. H>>Прекращай тупить. G>Аргументы кончились?
Я тебе уже привел пример не COM-интерфейса, а для тебя это, похоже, картину мира нарушает. Ну-ну...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали: G>>Еще как назовешь. В динамических языках контроль типа осуществляется на стадии компиляции. Нельязя в делфи сравнить число со строкой, будет ошибка компиляции. S>Можно. Еще как можно. Более того, в Delphi можно сделать вызов метода, которого объект не поддерживает, и узнать об этом только в рантайме. В точности, как в JS. Вот этот код прекрасно скомпилируется: S>
S>Это и есть проявление динамической типизации.
Да знаю я это. Пару страниц назад сам об этом писал. Причем какя-то опция компилятора отключает это.
Но код
var
i: integer;
begin
i:='dgfdgdf';
end;
Вызвоет ошибку компиляции, что есть проявление статической типизации.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>>>>>Ты бы лучше про COM прочитал сначала. H>>>>>Если спека X-Man имеет десять пунктов, а ты соответствуешь только одному... Тебя можно назвать X-Man? Лечи голову, Вилли (с) G>>>>А ты читал спеку по COM? G>>>>В книге дональда боска (архитектора COM ксати) написано что любой интерфейс — наследник от IUnknown является COM интерфейсом. H>>>Прекращай тупить. G>>Аргументы кончились?
H>Я тебе уже привел пример не COM-интерфейса, а для тебя это, похоже, картину мира нарушает. Ну-ну...
Ну ты тупой. Сам создатель COM говорит что любой интерфейс — наследник IUnknown является COM интерфейсом.
А ты продолжаешь свое повторять.
УУУУ! Сил читать 75 листов нет и времени.
От себя:
— все примеры, SDK и тому подобные вещи идут с примерами на СИ и Шарпе. Задолбался я переводить это все на паскаль.
— begin, end
— var
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Фабрика-то ту при чем? В своем ли ты уме?? G>>При том. Создание объекта, тип которого известен только во время выполенения — задача фабрки\фабричного метода. H>Так нам не требуется ничего создавать. Нужно узнать у сущности, умеет ли она летать.
А кто мешает написать метод, который спрашивает может ли фабрика создать такой тип?
G>>Ну на C# я напишу G>>
G>> (obj as IInterface)//Если obj реализует IInterface, то вернется переменная этого типа, иначе будет null.
G>>
G>>При этом человек, который писал о класс объекта obj мог и не знать о существовании IInterface. H>А что произойдет в момент компиляции, если obj не реализует IInterface?
Ничего.
G>>Ты вообще знаешь для чего QueryInterface придумали? H>Будь уверен.
Сомневаюсь.
Здравствуйте, gandjustas, Вы писали:
S>>Здравствуйте, gandjustas, Вы писали: G>>>Еще как назовешь. В динамических языках контроль типа осуществляется на стадии компиляции. Нельязя в делфи сравнить число со строкой, будет ошибка компиляции. S>>Можно. Еще как можно. Более того, в Delphi можно сделать вызов метода, которого объект не поддерживает, и узнать об этом только в рантайме. В точности, как в JS. Вот этот код прекрасно скомпилируется: S>>
S>>Это и есть проявление динамической типизации. G>Да знаю я это. Пару страниц назад сам об этом писал. Причем какя-то опция компилятора отключает это.
Здравствуйте, gandjustas, Вы писали:
G>>>>>>>Ты бы лучше про COM прочитал сначала. H>>>>>>Если спека X-Man имеет десять пунктов, а ты соответствуешь только одному... Тебя можно назвать X-Man? Лечи голову, Вилли (с) G>>>>>А ты читал спеку по COM? G>>>>>В книге дональда боска (архитектора COM ксати) написано что любой интерфейс — наследник от IUnknown является COM интерфейсом. H>>>>Прекращай тупить. G>>>Аргументы кончились?
H>>Я тебе уже привел пример не COM-интерфейса, а для тебя это, похоже, картину мира нарушает. Ну-ну... G>Ну ты тупой. Сам создатель COM говорит что любой интерфейс — наследник IUnknown является COM интерфейсом. G>А ты продолжаешь свое повторять.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, DOOM, Вы писали:
DOO>>Хорош уже откровенно тупить — где написано, что как только появляются объекты, то нужны смарт пойнтеры? Ты бы еще сказал, что на C нельзя написать <подставь сюда свой типичный проект>, потому что там нет объектов! G>Они также нужны в Delph, потому что там можно забыть написать Free.
Почему ты считаешь, что нет другого способа обойти эту забывчивость? Я же уже написал про банальный подход у TComponent (и ведь работает).
Кстати, в C я бы сказал они нужны, чтобы не забыть вызвать free на участок памяти — но народ же как-то обходится (не спорю, что тяжело им, но есть методы поиска утечек).
G>Любоую программу можно написать без объектов, только вопрос времени.
Неверно. Распространенное заблуждение, что ООП реально сильнее процедурного программирования — почитай как народ офигел, когда поняли, что никто не умеет эффективно проектировать при ООП подходе. И как потом разрабатывали UML — процесс был долгий и мучительный (если я правильно помню, только через 6 лет смогли родить первую версию UML). Т.е. плата за все плюсы ООП — гораздо более серьезная зависимость от правильного проектирования.
Популярная библиотека Gtk является чисто сишной — на одних struct'ах построена и ничего, народ пользуется.
G>Что-то я не увидел примеров.
Еще раз:
C — динамика есть. Память выделяется, надо руками звать free — самый суровый вариант. Но ведь используется в своей нише — потому, что там легко понять, что компилятор сделает их исходного кода. Ты никогда не напишешь на .Net обработчик прерывания. Просто по определению.
Javascript — использование всяких внешних объектов (например, ADO) — соединение надо закрывать (может банально стоять ограничение на количество одновременных соединений и с базой и приехали. Веб приложение на классическом ASP встало). Особенно приятно, если это объект, хранящийся в контейнере сеанса — он не будет уничтожен по завершению работы сценария.
Могу еще что-нибудь придумать...
DOO>>В дельфи, к пример, все наследники TComponent'а в обязательном порядке обладают owner'ом — который отвечает за убийство своих подопечных, когда умирает сам. G>Только далеко не все классы являются наследниками TComponent
Все визуальные — т.е. гипотетический криворукий программер, умеющий только кидать элементы на форму, будет иметь дело только с наследниками TComponent.
DOO>>Соответственно все завязано на основную форму приложения, а значит все объекты будут корректно уничтожены рано или поздно — это вариант борьбы с отсутствием автоматического контроля времени жизни объекта. G>Выделенное — офигенный недостаток.
Это by design (ну да, иногда недостаток), но в общем и целом это как раз, то, что надо.
DOO>>И, если человек хоть немного понимает, что такое указатель, объект и т.п., то у него не будет проблем с утечками. G>В .NET и Java у человека не будет проблем с утечками даже если он не понимает указатели.
Но если он не понимает указатели, то до борьбы с утечками он просто не доберется — ничего толком работать не будет.
kuj>>>>>2. Делфи — динамический язык? DOO>>>>В достаточной мере. G>>>Не более динаический, чем С++. Можно везде писать (void*) и кастить при каждом обращении. DOO>>Да... Ну ладно — тогда создай мне экземпляр класса по его строковому имени в ран-тайме. Или хотя бы перечисли методы объекта в ран-тайме. G>В С++ нет метаданных, поэтому такое невозможно. Но налитчие метаданных не делает язык динамическим. G>В .NET и Java есть метаданные, но они не позиционируются как динамические языки.
G>Еще как назовешь. В динамических языках контроль типа осуществляется на стадии компиляции. Нельязя в делфи сравнить число со строкой, будет ошибка компиляции. то и есть проявление счтатической типизации.
Я уже приводил пример с поддержкой Variant'а на уровне синтаксиса языка — там ничего не известно на этапе компиляции.
G>В Javascript например написать сравнение числа со строкой вполне можно, это вызвоет ошибку времени выполнения.
Ошибку это не вызовет, проверил бы хоть, прежде чем писать.
DOO>>Ворнинги от того, что в .Net банально многое нельзя, а значит программа не перенесется в среду .Net. G>В .NET можно сделать все, что можно в делфи.
В .Net нет прямого доступа к памяти, или я ошибаюсь?
DOO>>Так что подумай над своими методами ведения спора. G>То есть ты хочешь сказать что использование вариантных типов не приводит к увечличению числа ошибок?
Я хочу сказать, что это другая тема. Я опроверг изначальный тезис: Дельфи — язык со строгой типизацией. Привел пример. Если тебе так интересно, что я думаю о такой поддержке Variant'а, то скажу просто — я этим старался не пользоваться. Но поддержка есть, значит не совсем строгая типизация. Вот и все.
G>Глупость номер раз — Delphi динамический язык
Я тебе показал отсутствие строгой типизации? Показал. Значит не все так просто в датском королевстве. Не укладывается Delphi в узкое определение статического языка со строгой типизацией — есть там кое-какие фичи.
G>Глупость номер два — использование вариантных типов везде. Поясни. Кто тут и где про использование вариантных типов говорил?
Здравствуйте, gandjustas, Вы писали:
H>>>>Фабрика-то ту при чем? В своем ли ты уме?? G>>>При том. Создание объекта, тип которого известен только во время выполенения — задача фабрки\фабричного метода. H>>Так нам не требуется ничего создавать. Нужно узнать у сущности, умеет ли она летать. G>А кто мешает написать метод, который спрашивает может ли фабрика создать такой тип?
Нам не нужно ничего создавать!
G>>>Ну на C# я напишу G>>>
G>>> (obj as IInterface)//Если obj реализует IInterface, то вернется переменная этого типа, иначе будет null.
G>>>
G>>>При этом человек, который писал о класс объекта obj мог и не знать о существовании IInterface. H>>А что произойдет в момент компиляции, если obj не реализует IInterface? G>Ничего.
Ok. Если это так, то такое поведение оператора as это и есть запрос интерфейса от объекта (но не приведение оного). А теперь запроси от объекта другой объект (ты же сказал, что решение на интерфейсах вызвано кривостью Delphi).
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, DOOM, Вы писали:
kuj>>>Богатый интерфейс на яваскрипте? Флаг в руки, ветер в спину. DOO>>А в чем проблема? Можно и интерфейс. Можно и прямо COM объект настрочить на JS (точнее, конечно, это WSH)... Не знал? G>Да ну, а пример покажешь?
Пожалуйста. Технология называется Windows Script Components — ставить дополнительно ничего не надо, это включено в WSH (не помню с какой версии). Очень удобный способ, на самом деле в некоторых ситуациях.
Листинг 1: Sample.wsc
<?XML version="1.0"?>
<component>
<registration
description="Sample component v1.0"
progid="Penton.Sample"
classid="{8C372226-7D30-4EC4-B1BF-F6C4CEC53AEB}"
version="1.0"
/>
<public>
<property name="Number">
<put/>
</property>
<method name="Multiply">
<parameter name="Multiplier"/>
</method>
</public>
<script language="VBScript"><![CDATA[
Dim Number
Sub put_Number(ByVal NewValue)
Number = NewValue
End Sub
Function Multiply(ByVal Multiplier)
Multiply = Number * Multiplier
End Function
]]></script>
</component>
С гуем сложнее — но могу поискать, если надо (по-моему для гуя что-то ставить еще надо).
Здравствуйте, gandjustas, Вы писали: G>Да знаю я это. Пару страниц назад сам об этом писал. Причем какя-то опция компилятора отключает это. G>Но код G>Вызвоет ошибку компиляции, что есть проявление статической типизации.
Итого? Есть два кода. Один вызывает ошибку компиляции, другой не вызывает.
Какие выводы можно сделать? Ну, кроме того, что участники дискуссии очень плохо разбираются в системах типов?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, csharpworker, Вы писали: C>- все примеры, SDK и тому подобные вещи идут с примерами на СИ и Шарпе. Задолбался я переводить это все на паскаль. C>- begin, end C>- var
Возрадуйся, ибо в новом шарпе таки есть var
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DOOM, Вы писали:
kuj>>>>1. У Javascript есть нормальный garbage collector. Ему не нужны smart pointer`ы. DOO>>>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша. G>>Не показывай свою необразованность. В C нет обънектов, смарт поинтеры там не нужны. DOO>Соответственно все завязано на основную форму приложения, а значит все объекты будут корректно уничтожены рано или поздно — это вариант борьбы с отсутствием автоматического контроля времени жизни объекта. И, если человек хоть немного понимает, что такое указатель, объект и т.п., то у него не будет проблем с утечками.
Ты вообще программированием занимаешься или как Шеридан? Судя по утверждению — последнее.
kuj>>>>2. Делфи — динамический язык? DOO>>>В достаточной мере. G>>Не более динаический, чем С++. Можно везде писать (void*) и кастить при каждом обращении. DOO>Да... Ну ладно — тогда создай мне экземпляр класса по его строковому имени в ран-тайме.
Создание класса по его строковому имени в рантайм не является признаком динамического языка.
DOO>Или хотя бы перечисли методы объекта в ран-тайме.
Перечисление методов объекта в рантайм не достаточно, чтоб для динамического языка.
DOO>Да, конечно, в Дельфи нету JIT'а, но и статическим строго типизированным его не назовешь.
У C# куда больше всяких плюшек: и extension methods, и анонимные классы и функции, и лямба-выражения, и атрибуты и многое другое, но он все еще остается статическим строго типизированным языком по-определению.
Медитируй http://en.wikipedia.org/wiki/Dynamic_programming_language
kuj>>>>А Борланд об этом знает? DOO>>>Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать. G>>Наверное ворнинги не от хорошей жизни. DOO>Ворнинги от того, что в .Net банально многое нельзя, а значит программа не перенесется в среду .Net.
Здравствуйте, DOOM, Вы писали:
kuj>>Богатый интерфейс на яваскрипте? Флаг в руки, ветер в спину.
DOO>А в чем проблема? Можно и интерфейс. Можно и прямо COM объект настрочить на JS (точнее, конечно, это WSH)... Не знал?
Пример JS скрипта на WSH с "богатым интерфейсом" в студию.
Здравствуйте, hattab, Вы писали:
G>>В .NET и Java у человека не будет проблем с утечками даже если он не понимает указатели.
H>Судя по тому, что ты тут пишешь, я вижу, что многого ты так и не понял...
Здравствуйте, kuj, Вы писали:
kuj>Мне нужно нажать только =, в то время как тебе в Delphi — зажать shift, нажать 6, отжать shift, нажать = и это для, пожалуй, наиболее используемого оператора...
Здравствуйте, hattab, Вы писали:
S>>>Можно. Еще как можно. Более того, в Delphi можно сделать вызов метода, которого объект не поддерживает, и узнать об этом только в рантайме. В точности, как в JS. Вот этот код прекрасно скомпилируется: H>Нет такой опции
Отсюда только следует, что Delphi не является ни статическим, ни динамическим языком, а некий жуткий сурогат.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
S>>>>Можно. Еще как можно. Более того, в Delphi можно сделать вызов метода, которого объект не поддерживает, и узнать об этом только в рантайме. В точности, как в JS. Вот этот код прекрасно скомпилируется: H>>Нет такой опции
kuj>Отсюда только следует, что Delphi не является ни статическим, ни динамическим языком
Ну наконец-то ты это понял...
kuj>, а некий жуткий сурогат.
А это уже субъективизм.
Здравствуйте, DOOM, Вы писали:
G>>Любоую программу можно написать без объектов, только вопрос времени. DOO>Неверно. Распространенное заблуждение, что ООП реально сильнее процедурного программирования — почитай как народ офигел, когда поняли, что никто не умеет эффективно проектировать при ООП подходе. И как потом разрабатывали UML — процесс был долгий и мучительный (если я правильно помню, только через 6 лет смогли родить первую версию UML). Т.е. плата за все плюсы ООП — гораздо более серьезная зависимость от правильного проектирования. DOO>Популярная библиотека Gtk является чисто сишной — на одних struct'ах построена и ничего, народ пользуется.
Хотелось бы посмотреть как ты будешь чисто процедурно писать средних размеров корпоративную систему. Это из разряда "на JS можно написать мощный интерфейс пользователя".
Судя по твоей писанине в этом топике ты не являешься профессиональным программистом. Завязывай уже со этой ахинеей и пустозвонством.
G>>Что-то я не увидел примеров. DOO>Еще раз: DOO>Могу еще что-нибудь придумать...
Придумай. Еще посмеемся.
DOO>>>Соответственно все завязано на основную форму приложения, а значит все объекты будут корректно уничтожены рано или поздно — это вариант борьбы с отсутствием автоматического контроля времени жизни объекта. G>>Выделенное — офигенный недостаток. DOO>Это by design (ну да, иногда недостаток), но в общем и целом это как раз, то, что надо.
DOO>>>И, если человек хоть немного понимает, что такое указатель, объект и т.п., то у него не будет проблем с утечками. G>>В .NET и Java у человека не будет проблем с утечками даже если он не понимает указатели. DOO>Но если он не понимает указатели, то до борьбы с утечками он просто не доберется — ничего толком работать не будет.
Какая взаимосвязь между пониманием что такое "указатель в Delphi" и борьбой с утечками в .NET/Java? Пиши ище!
DOO>>>Ворнинги от того, что в .Net банально многое нельзя, а значит программа не перенесется в среду .Net. G>>В .NET можно сделать все, что можно в делфи. DOO>В .Net нет прямого доступа к памяти, или я ошибаюсь?
Выкладывай для какой задачи тебе нужен прямой доступ к памяти.
G>>Глупость номер раз — Delphi динамический язык DOO>Я тебе показал отсутствие строгой типизации? Показал. Значит не все так просто в датском королевстве. Не укладывается Delphi в узкое определение статического языка со строгой типизацией — есть там кое-какие фичи.
Делфи вообще никуда не укладывается. Если хочешь узнать что такое полноценный динамический язык посмотри на Ruby.
G>>Глупость номер два — использование вариантных типов везде. DOO> Поясни. Кто тут и где про использование вариантных типов говорил?
Ты одной квотой выше.
Здравствуйте, ironwit, Вы писали:
kuj>>Мне нужно нажать только =, в то время как тебе в Delphi — зажать shift, нажать 6, отжать shift, нажать = и это для, пожалуй, наиболее используемого оператора...
I>shift+Ж в англ раскладке? :
Почему я должен помнить какая у меня там активная раскладка, если все что мне нужно, это ввести оператор присваивания?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали: G>>Да знаю я это. Пару страниц назад сам об этом писал. Причем какя-то опция компилятора отключает это. G>>Но код G>>Вызвоет ошибку компиляции, что есть проявление статической типизации. S>Итого? Есть два кода. Один вызывает ошибку компиляции, другой не вызывает. S>Какие выводы можно сделать? Ну, кроме того, что участники дискуссии очень плохо разбираются в системах типов?
Что-то это переходит в болтологию. Если язык поддерживает строгую типизацию, кроме случая использования типа Variant, то как его назвать?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>>>Ну на C# я напишу G>>>>
G>>>> (obj as IInterface)//Если obj реализует IInterface, то вернется переменная этого типа, иначе будет null.
G>>>>
G>>>>При этом человек, который писал о класс объекта obj мог и не знать о существовании IInterface. H>>>А что произойдет в момент компиляции, если obj не реализует IInterface? G>>Ничего.
H>Ok. Если это так, то такое поведение оператора as это и есть запрос интерфейса от объекта (но не приведение оного). А теперь запроси от объекта другой объект (ты же сказал, что решение на интерфейсах вызвано кривостью Delphi).
Вникай, все это нормально компилируется
interface IA
{
//...
}
interface IB
{
//...
}
class A:IA
{
//...
}
class B:IB
{
//...
}
class C:A
{
//...
}
//...
A a = new C();
(a as IA) //вернет ссылку на интерфейс IA
(a as IB) //вернет null
(a as A) //вернет ссылку на класс A
(a as B) //вернет null
(IA)a //вернет ссылку на интерфейс IA
(B)a //вылетит Exception
(IB)a //вылетит Exception
kuj>Хотелось бы посмотреть как ты будешь чисто процедурно писать средних размеров корпоративную систему.
Хотелось бы посмотреть как ты будешь писать средних размеров корпоративную систему.
Метод решения выбирают под задачу и исходя из опыта команды. Да будет тебе известно, что Дейкстра так и не признал ООП — так для сведения.
Ядро Linux написано на C и его размеры могут поконкурировать даже не со средних размеров корпоративной системой
Весь Gnome написан на C (ну может за редким исключением).
Еще примеры надо?
kuj>Это из разряда "на JS можно написать мощный интерфейс пользователя".
Ну c JS слишком долго лазить за примерами, но вот Tk — есть и для tcl, есть и для перла. Приложений на Tk масса...
kuj>Судя по твоей писанине в этом топике ты не являешься профессиональным программистом. Завязывай уже со этой ахинеей и пустозвонством.
Про то, что программированием я уже давно не занимаюсь, я написал в самом начале этого топика. А вот твои беспочвенные обвинения реально уже достали
G>>>Что-то я не увидел примеров. DOO>>Еще раз: DOO>>Могу еще что-нибудь придумать...
kuj>Придумай. Еще посмеемся.
Мда... Все-таки недаром тебя в КСВ считают неадекватным оппонентом...
DOO>>Но если он не понимает указатели, то до борьбы с утечками он просто не доберется — ничего толком работать не будет. kuj>Какая взаимосвязь между пониманием что такое "указатель в Delphi" и борьбой с утечками в .NET/Java? Пиши ище!
И еще раз возможность в этом убедиться.
DOO>>>>Ворнинги от того, что в .Net банально многое нельзя, а значит программа не перенесется в среду .Net. G>>>В .NET можно сделать все, что можно в делфи. DOO>>В .Net нет прямого доступа к памяти, или я ошибаюсь? kuj>Выкладывай для какой задачи тебе нужен прямой доступ к памяти.
Сам подумай на досуге, а.
G>>>Глупость номер два — использование вариантных типов везде. DOO>> Поясни. Кто тут и где про использование вариантных типов говорил? kuj>Ты одной квотой выше.
Я показал пример, за это мне навесили: "использование вариантных типов везде" — логических ошибок совсем не видать?
Здравствуйте, kuj, Вы писали:
kuj>Богатый интерфейс на яваскрипте? Флаг в руки, ветер в спину.
Ты под богатым интерфейсом часом не вот это имеешь в виду? Или, может быть, maps.google.com?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DOOM, Вы писали:
kuj>>Отсюда только следует, что Delphi не является ни статическим, ни динамическим языком DOO>Ну наконец-то ты это понял... kuj>>, а некий жуткий сурогат. DOO>А это уже субъективизм.
Это не субъективизм, а реалии жизни. Вместо того, чтоб сделать нормальный строго типизированный язык, взяли самую худшую черту динамического языка и прилепили ее в виде специального типа Variant.
К слову, Variant изначально был придуман Microsoft как тип данных COM. COM-объекты исторически писались почти исключительно на C++.
В нормальных строго типизированных ОО языках типа C# и Java у всех классов есть общий предок: object и java.lang.Object, соответственно, а так же полноценные метаданные и полноценный механизм reflection. Более того, у .NET в отличии от Delphi из мира dynamic languages взят еще оператор eval, позволяющий компилировать код непосредственно в рантайм. Язык остался строго типизированным, но получил многие элементы динамических языков: type inference, closures, duck typing (производная от dynamic typing: var something = new ClassA(...); ), eval, reflections.
Такой .NET язык как Boo пошел еще дальше и взял такие элементы динамических языков как: syntactic macros (в отличии от макросов в C++, макросы в Boo имеют больше черт, характерных макросам в динамических языках — они модифицируют compiler pipeline) и generators.
Полноценным динамическим языком в мире .NET на основе DLR станет IronRuby.
Здравствуйте, gandjustas, Вы писали:
G>>>Да знаю я это. Пару страниц назад сам об этом писал. Причем какя-то опция компилятора отключает это. G>>>Но код G>>>Вызвоет ошибку компиляции, что есть проявление статической типизации. S>>Итого? Есть два кода. Один вызывает ошибку компиляции, другой не вызывает. S>>Какие выводы можно сделать? Ну, кроме того, что участники дискуссии очень плохо разбираются в системах типов? G>Что-то это переходит в болтологию. Если язык поддерживает строгую типизацию, кроме случая использования типа Variant, то как его назвать?
Делфи как не называй все-равно фигня получится. Это как в анекдоте: " — мальчик или девочка?! — вырастет — само решит..."
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, DOOM, Вы писали:
kuj>>>Отсюда только следует, что Delphi не является ни статическим, ни динамическим языком DOO>>Ну наконец-то ты это понял... kuj>>>, а некий жуткий сурогат. DOO>>А это уже субъективизм.
kuj>Это не субъективизм, а реалии жизни. Вместо того, чтоб сделать нормальный строго типизированный язык, взяли самую худшую черту динамического языка и прилепили ее в виде специального типа Variant.
В результате это существенно упростило некоторые задачи, что и позволило стать дельфи языком для непрограммистов. Значит с рыночной точки зрения решение было правильным
kuj>К слову, Variant изначально был придуман Microsoft как тип данных COM. COM-объекты исторически писались почти исключительно на C++.
К чему эта цепочка умозаключений? Мы вроде уже выяснили, что COM можно и на JS написать, было бы желание...
kuj>В нормальных строго типизированных ОО языках типа C# и Java у всех классов есть общий предок: object и java.lang.Object, соответственно, а так же полноценные метаданные и полноценный механизм reflection. Более того, у .NET в отличии от Delphi из мира dynamic languages взят еще оператор eval, позволяющий компилировать код непосредственно в рантайм. Язык остался строго типизированным, но получил многие элементы динамических языков: type inference, closures, duck typing (производная от dynamic typing: var something = new ClassA(...); ), eval, reflections.
kuj>Такой .NET язык как Boo пошел еще дальше и взял такие элементы динамических языков как: syntactic macros (в отличии от макросов в C++, макросы в Boo имеют больше черт, характерных макросам в динамических языках — они модифицируют compiler pipeline) и generators.
kuj>Полноценным динамическим языком в мире .NET на основе DLR станет IronRuby.
Ну замечательно... К чему это только все?
Здравствуйте, DOOM, Вы писали:
kuj>>Хотелось бы посмотреть как ты будешь чисто процедурно писать средних размеров корпоративную систему. DOO>Хотелось бы посмотреть как ты будешь писать средних размеров корпоративную систему. DOO>Метод решения выбирают под задачу и исходя из опыта команды. Да будет тебе известно, что Дейкстра так и не признал ООП — так для сведения.
Дейкстра уж много лет как на пенсии. Так что он немного не в теме современных реалий программирования.
DOO>Ядро Linux написано на C и его размеры могут поконкурировать даже не со средних размеров корпоративной системой DOO>Весь Gnome написан на C (ну может за редким исключением). DOO>Еще примеры надо?
Давай пример корпоративной системы написанной полностью процедурными методами и хотя бы пару широкораспространенных прикладных приложений.
kuj>>Это из разряда "на JS можно написать мощный интерфейс пользователя". DOO>Ну c JS слишком долго лазить за примерами,
Слив засчитан.
kuj>>Придумай. Еще посмеемся. DOO>Мда... Все-таки недаром тебя в КСВ считают неадекватным оппонентом...
Это из серии "Мы Государь всея Руси, считаем тебя неадекватным оппонентом..."
DOO>>>>>Ворнинги от того, что в .Net банально многое нельзя, а значит программа не перенесется в среду .Net. G>>>>В .NET можно сделать все, что можно в делфи. DOO>>>В .Net нет прямого доступа к памяти, или я ошибаюсь? kuj>>Выкладывай для какой задачи тебе нужен прямой доступ к памяти. DOO>Сам подумай на досуге, а.
Слив засчитан.
G>>>>Глупость номер два — использование вариантных типов везде. DOO>>> Поясни. Кто тут и где про использование вариантных типов говорил? kuj>>Ты одной квотой выше. DOO>Я показал пример, за это мне навесили: "использование вариантных типов везде" — логических ошибок совсем не видать?
Слив засчитан. В динамических языках все типы динамические.
Здравствуйте, DOOM, Вы писали:
kuj>>Это не субъективизм, а реалии жизни. Вместо того, чтоб сделать нормальный строго типизированный язык, взяли самую худшую черту динамического языка и прилепили ее в виде специального типа Variant. DOO>В результате это существенно упростило некоторые задачи, что и позволило стать дельфи языком для непрограммистов. Значит с рыночной точки зрения решение было правильным
Variant позволил Делфи стать языком для непрограммистов? /сползаю под стол
kuj>>В нормальных строго типизированных ОО языках типа C# и Java у всех классов есть общий предок: object и java.lang.Object, соответственно, а так же полноценные метаданные и полноценный механизм reflection. Более того, у .NET в отличии от Delphi из мира dynamic languages взят еще оператор eval, позволяющий компилировать код непосредственно в рантайм. Язык остался строго типизированным, но получил многие элементы динамических языков: type inference, closures, duck typing (производная от dynamic typing: var something = new ClassA(...); ), eval, reflections.
kuj>>Такой .NET язык как Boo пошел еще дальше и взял такие элементы динамических языков как: syntactic macros (в отличии от макросов в C++, макросы в Boo имеют больше черт, характерных макросам в динамических языках — они модифицируют compiler pipeline) и generators.
kuj>>Полноценным динамическим языком в мире .NET на основе DLR станет IronRuby. DOO>Ну замечательно... К чему это только все?
К тому, что Delphi не является динамическим языком. До тебя так же туго доходит, как и для hattab`а. Впрочем, может ты его альтер-эго?
Здравствуйте, Sinclair, Вы писали:
kuj>>Богатый интерфейс на яваскрипте? Флаг в руки, ветер в спину. S>Ты под богатым интерфейсом часом не вот это имеешь в виду? Или, может быть, maps.google.com?
Часом нет. Речь шла о Windows, а не о Web. А то, может, давайте еще Silverlight сюда приплетем.
Здравствуйте, gandjustas, Вы писали:
G>>>>>Ну на C# я напишу G>>>>>
G>>>>> (obj as IInterface)//Если obj реализует IInterface, то вернется переменная этого типа, иначе будет null.
G>>>>>
G>>>>>При этом человек, который писал о класс объекта obj мог и не знать о существовании IInterface. H>>>>А что произойдет в момент компиляции, если obj не реализует IInterface? G>>>Ничего.
H>>Ok. Если это так, то такое поведение оператора as это и есть запрос интерфейса от объекта (но не приведение оного). А теперь запроси от объекта другой объект (ты же сказал, что решение на интерфейсах вызвано кривостью Delphi).
G>Вникай, все это нормально компилируется G>
G>interface IA
G>{
G> //...
G>}
G>interface IB
G>{
G> //...
G>}
G>class A:IA
G>{
G> //...
G>}
G>class B:IB
G>{
G> //...
G>}
G>class C:A
G>{
G> //...
G>}
G>//...
G>A a = new C();
G>(a as IA) //вернет ссылку на интерфейс IA
G>(a as IB) //вернет null
G>(a as A) //вернет ссылку на класс A
G>(a as B) //вернет null
G>(IA)a //вернет ссылку на интерфейс IA
G>(B)a //вылетит Exception
G>(IB)a //вылетит Exception
G>
Вникать тут не во что. Я тебя попросил вполне конкретный пример: по аналогии с запросом ICanFly, сделать запрос объекта (без использования интерфейсов, это же, с твоих слов, криво). Ты мне приведения типов показываешь Это далеко не одно и то же. Ломай стены в своей голове.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Sinclair, Вы писали:
kuj>>>Богатый интерфейс на яваскрипте? Флаг в руки, ветер в спину. S>>Ты под богатым интерфейсом часом не вот это имеешь в виду? Или, может быть, maps.google.com? kuj>Часом нет. Речь шла о Windows, а не о Web. А то, может, давайте еще Silverlight сюда приплетем.
Блин. Ты, Маугли, кого угодно достанешь (с)
Короче, есть тебе 2 варианта: HTA (это все же не web в полном понимании) и библиотека WSH.GUI — это уже просто набор ActiveX для создания гуя. Выбирай, что понравится.
Здравствуйте, DOOM, Вы писали:
kuj>>>>2. Делфи — динамический язык? DOO>>>В достаточной мере. kuj>>Скажу тебе по секрету Delphi никогда не был, не является, и вряд ли когда-то станет динамическим языком. DOO>В полной мере нет. Но не все так строго делится на белое и черное. Delphi является более динамическим, чем C++, например.
Из серии крокодил более длинный, чем зеленый — зеленый он только сверху, а длинный и снизу и сверху. Открой для себя ATL.
kuj>>>>А Борланд об этом знает? DOO>>>Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать. kuj>>И при чем тут динамические языки? DOO>Это к вопросу о статической типизации. Или ты под динамическим языком понимаешь только тот, у которого есть функция типа eval?
Нет и я уже давал ссылку на wiki и приводил в качестве примера полноценного динамического языка Ruby. Ты явно проигнорировал и то и другое.
Попробую объяснить тебе как ребенку малому: если в языке есть статическая типизация, то язык не является динамическим. Повторяй это как мантру.
kuj>>VarArrayCreate создает массив значений типа Variant. При чем тут динамические языки? Ты, батенька, серьезно не в теме. DOO>В VBscript'е любая переменаая это тоже Variant — если ты внедришь движок VB через соответсвующий COM объект в свою программу, то ты даже сможешь получать к ним доступ. Вопрос в прямой поддержке со стороны языка — VBScript поддерживает эти Variant'ы прозрачно, Delphi — тоже, C++ — нет. Соотвественно нельзя говорить, что в Delphi статическая типизация. Все, что отличает его от какого-нибудь скрипта — это отсутствие функции типа eval. Это делает Дельфи некоторым промежуточным языком, но ни как не "статическим языком со строгой типизацией".
Ты банально не имеешь ни малейшего понятия что такое динамические языки.
kuj>>Проку от них ровно столько, сколько проку от подобного контейнера в Delрhi. Кроме того, что я могу явно ограничить супертип, что уменьшит поле для ошибок на этапе компиляции. Вообщем, ты снова явно не в теме. DOO>Для особо одаренных напомню, что в дельфи все объпекты потомки TObject — т.е. супертип уже ограничен. Прямо такой уж жизненной необходимости отсекать дерево при помощи какого-то промежуточного объекта я не вижу — это можно сделать еще в куче мест, в том числе в рантайме.
List<MyBaseClass>
и
ArrayList
Ты все еще не въезжаешь?...
Бедные дети в школах и институтах... зачем их только учат Делфи. Сами себя гробим.
Здравствуйте, hattab, Вы писали:
H>>>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface.
M>>Для таких случаев делается wrapper-объект, который содержит старый объект в виде приватной переменной. И?
H>Да-да, все сводится к рождению своего Query-blah-blah-blah
Нет, все сводится к тому, что ты не знаешь банальных основ ООП.
Здравствуйте, hattab, Вы писали:
H>Я уж и не знаю, какие тебе еще примеры приводить, чтоб ты понял... Вот прикинь, получил ты интерфейс IUnknown (неважно, как и от кого), ты можешь запросить у него интерфейс ICanFly? Можешь. Можешь даже в том случае, если реализующий (IUnknown) объект не имеет понятия о ICanFly. Теперь давай тоже самое с объектами.
Здравствуйте, hattab, Вы писали:
H>>>>>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface. G>>>>Ты сейчас как-то криво рассказал про фабрику классов. Тольео её придумали гораздо раньше COM
H>>>Фабрика-то ту при чем? В своем ли ты уме?? G>>При том. Создание объекта, тип которого известен только во время выполенения — задача фабрки\фабричного метода.
H>Так нам не требуется ничего создавать. Нужно узнать у сущности, умеет ли она летать.
Мда...
if (obj is ICanFly)
{
...
}
G>>Ты вообще знаешь для чего QueryInterface придумали?
H>Будь уверен.
Да мы то давно уверены, что ты, мягко говоря, не в теме...
H>Ok. Если это так, то такое поведение оператора as это и есть запрос интерфейса от объекта (но не приведение оного).
Понятия "запрос интерфейса" и "приведение к интерфейсу" тождественные.
ISomething a = (ISomething)b;
Тоже самое, но если b не реализует ISomething, то будет сгенерировано исключение.
H>А теперь запроси от объекта другой объект (ты же сказал, что решение на интерфейсах вызвано кривостью Delphi).
Что значит "запроси от объекта другой объект"?
Ты банально не понимаешь что такое интерфейсы. Вот в чем твоя проблема.
Просвещайся.
DOO>В статье есть ответ ровно на один вопрос: какие порты. Больше ровным счетом ничего — ни механизма обмена (со стороны ОС, а не .Net сборки), ни методов аутентификации, ничего. Еще раз повторяю — даже если кодер не заморачивается такими вопросами (вообще говоря, и не должен) — все эти вопросы должны появится в голове у архитектора.
Ты статью точно читал? Судя по комментарию — нет. Прочти тогда будет о чем поговорить. Заодно посмотри статью в MSDN.
Здравствуйте, _d_m_, Вы писали:
kuj>>Хмм, интересно. На сколько большой должен быть файл, чтоб студия зависла? На .cs в 360kB не виснет и не тормозит... Большего cs-файла под рукой нету...
___>Ну не такой уж большой — 69К. Проблема проявляется именно в этом файле. Скорее всего проблема возникает из-за содержимого, но то что проблема воспроизводима — это факт.
Странно.
___>>>- До SP1 одолевал WinForms дизайнер — открываешь допустим свой контрол, а на нем кнопки съехали. Ну это уже не в счет.
kuj>>Не сталкивался. Я, правда, с WinForms мало работаю.
___>>>- WinForms дизайнер — шрифты в дизайнере могут оказаться другого размера, чем на реальной форме.
kuj>>Это как? Можно сценарий для воспроизведения?
___>Вот: ___> ___>Слева кнопка в дизайнере, справа реально запущенное приложение. MS Sans Serif 9.75pt.
Э-э, вообще-то шрифты на скриншоте идентичные. А вот ширина поля действительно разная.
Здравствуйте, Sinclair, Вы писали:
C>>- все примеры, SDK и тому подобные вещи идут с примерами на СИ и Шарпе. Задолбался я переводить это все на паскаль. C>>- begin, end C>>- var S>Возрадуйся, ибо в новом шарпе таки есть var
var в новом шарпе и в делфи несколько различаются, не находишь?
Здравствуйте, DOOM, Вы писали:
kuj>>>>Богатый интерфейс на яваскрипте? Флаг в руки, ветер в спину. S>>>Ты под богатым интерфейсом часом не вот это имеешь в виду? Или, может быть, maps.google.com? kuj>>Часом нет. Речь шла о Windows, а не о Web. А то, может, давайте еще Silverlight сюда приплетем.
DOO>Блин. Ты, Маугли, кого угодно достанешь (с) DOO>Короче, есть тебе 2 варианта: HTA (это все же не web в полном понимании) и библиотека WSH.GUI — это уже просто набор ActiveX для создания гуя. Выбирай, что понравится.
Ты давай примеры конкретных приложений, а не "наборы ActiveX для гуя".
Здравствуйте, kuj, Вы писали: kuj>Часом нет. Речь шла о Windows, а не о Web.
Хм. Ну скопируй HTML из первого примера себе на диск C:\ — будет под Windows. В чем проблема-то? В том, что ты не знал, что на JS можно писать rich text gui?
kuj>А то, может, давайте еще Silverlight сюда приплетем.
Ну, почему бы и нет? Если речь о сильверлайте с JS биндингом.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kuj, Вы писали:
___>>>>- WinForms дизайнер — шрифты в дизайнере могут оказаться другого размера, чем на реальной форме.
kuj>>>Это как? Можно сценарий для воспроизведения?
___>>Вот: ___>> ___>>Слева кнопка в дизайнере, справа реально запущенное приложение. MS Sans Serif 9.75pt.
kuj>Э-э, вообще-то шрифты на скриншоте идентичные. А вот ширина поля действительно разная.
Ну не знаю, что ты имеешь ввиду под шириной поля, но открой это изображение и посмотри в масштабе 600%:
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, ironwit, Вы писали:
kuj>>>Мне нужно нажать только =, в то время как тебе в Delphi — зажать shift, нажать 6, отжать shift, нажать = и это для, пожалуй, наиболее используемого оператора...
I>>shift+Ж в англ раскладке? :
kuj>Почему я должен помнить какая у меня там активная раскладка, если все что мне нужно, это ввести оператор присваивания?
а ты в делфи (подставить своё) работаешь в альтернативной раскладке?
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
H>>Delphi программы в релизном варианте не поотлаживаешь.
kuj>Еще один камень в огород Делфи, кстати.
А ты хоть раз C++'ную программу в релизе пробовал отлаживать?
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
H>>Delphi программы в релизном варианте не поотлаживаешь.
kuj>Еще один камень в огород Делфи, кстати.
неверная формулировка. с программой на делфи не сможешь работать отладчиком если в ехе файл не включил отладочную информацию.
Здравствуйте, ironwit, Вы писали:
kuj>>>>Мне нужно нажать только =, в то время как тебе в Delphi — зажать shift, нажать 6, отжать shift, нажать = и это для, пожалуй, наиболее используемого оператора...
I>>>shift+Ж в англ раскладке? :
kuj>>Почему я должен помнить какая у меня там активная раскладка, если все что мне нужно, это ввести оператор присваивания? I>а ты в делфи (подставить своё) работаешь в альтернативной раскладке?
У меня кроме английской еще три раскладки. Впрочем, в Delphi я, к счастью, не работаю.
kuj>>Ты давай примеры конкретных приложений, а не "наборы ActiveX для гуя".
DOO>Извини за каламбур, но с куя ли я тебе должен конкретные приложения приводить? Сказано было, что можно — показал, что можно.
Здравствуйте, DOOM, Вы писали:
H>>>Delphi программы в релизном варианте не поотлаживаешь.
kuj>>Еще один камень в огород Делфи, кстати.
DOO>А ты хоть раз C++'ную программу в релизе пробовал отлаживать?
Здравствуйте, _d_m_, Вы писали:
kuj>>Э-э, вообще-то шрифты на скриншоте идентичные. А вот ширина поля действительно разная.
___>Ну не знаю, что ты имеешь ввиду под шириной поля, но открой это изображение и посмотри в масштабе 600%: ___>
Понял теперь. Разный интервал между буквами. Да, забавный глюк (или таки фича?). На досуге попробую разобраться из-за чего это происходит.
Здравствуйте, kuj, Вы писали:
kuj>>>Э-э, вообще-то шрифты на скриншоте идентичные. А вот ширина поля действительно разная.
___>>Ну не знаю, что ты имеешь ввиду под шириной поля, но открой это изображение и посмотри в масштабе 600%: ___>>
kuj>Понял теперь. Разный интервал между буквами. Да, забавный глюк (или таки фича?). На досуге попробую разобраться из-за чего это происходит.
Уточню только: все компоненты стандартные? Кнопка на скрине это System.Windows.Forms.Button?
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, ironwit, Вы писали:
kuj>>>>>Мне нужно нажать только =, в то время как тебе в Delphi — зажать shift, нажать 6, отжать shift, нажать = и это для, пожалуй, наиболее используемого оператора...
I>>>>shift+Ж в англ раскладке? :
kuj>>>Почему я должен помнить какая у меня там активная раскладка, если все что мне нужно, это ввести оператор присваивания? I>>а ты в делфи (подставить своё) работаешь в альтернативной раскладке?
kuj>У меня кроме английской еще три раскладки. Впрочем, в Delphi я, к счастью, не работаю.
в своей среде разработки ты в какой раскладке работаешь?
Здравствуйте, ironwit, Вы писали:
kuj>>>>Почему я должен помнить какая у меня там активная раскладка, если все что мне нужно, это ввести оператор присваивания? I>>>а ты в делфи (подставить своё) работаешь в альтернативной раскладке?
kuj>>У меня кроме английской еще три раскладки. Впрочем, в Delphi я, к счастью, не работаю. I>в своей среде разработки ты в какой раскладке работаешь?
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, ironwit, Вы писали:
kuj>>>>>Почему я должен помнить какая у меня там активная раскладка, если все что мне нужно, это ввести оператор присваивания? I>>>>а ты в делфи (подставить своё) работаешь в альтернативной раскладке?
kuj>>>У меня кроме английской еще три раскладки. Впрочем, в Delphi я, к счастью, не работаю. I>>в своей среде разработки ты в какой раскладке работаешь?
kuj>В разных.
вот все равно не отстану. хоть и видно что ты сливаешь.
рассказывай какая студия
какие задачи
в каком % соотношении применяется англ раскладка и в каком остальные. и главное зачем.
или просто признай что поторопился с высказыванием насчет англ раскладки и замнем тему.
Здравствуйте, ironwit, Вы писали:
kuj>>>>>>Почему я должен помнить какая у меня там активная раскладка, если все что мне нужно, это ввести оператор присваивания? I>>>>>а ты в делфи (подставить своё) работаешь в альтернативной раскладке?
kuj>>>>У меня кроме английской еще три раскладки. Впрочем, в Delphi я, к счастью, не работаю. I>>>в своей среде разработки ты в какой раскладке работаешь?
kuj>>В разных. I>вот все равно не отстану. хоть и видно что ты сливаешь.
Ну-ну.
I>рассказывай какая студия
Какая разница?
I>какие задачи
Какая разница?
I>в каком % соотношении применяется англ раскладка и в каком остальные. и главное зачем.
В достаточном.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, ironwit, Вы писали:
kuj>>>В разных. I>>вот все равно не отстану. хоть и видно что ты сливаешь. kuj>Ну-ну.
фиксируем. СЛИВ защитан.
а если серьезно, относительно твоих мессаг ниже по топику — спорить надо культурнее и чуть аккуратнее. Прошу воспринять как конструктив, не как наезд.
Здравствуйте, ironwit, Вы писали:
kuj>>>>В разных. I>>>вот все равно не отстану. хоть и видно что ты сливаешь. kuj>>Ну-ну.
I>фиксируем. СЛИВ защитан.
I>а если серьезно, относительно твоих мессаг ниже по топику — спорить надо культурнее и чуть аккуратнее. Прошу воспринять как конструктив, не как наезд.
Нет никакого слива. Конструктива от тебя тоже нет. Чтоб ввести самый используемый оператор в Delphi надо в несколько раз больше телодвижений, чем C/C++/C#/Java. Хорошо, если бы это позитивно сказывалось на читабельности кода, но не сказывается. Поэтому совершенно объективный вывод: использование = в качестве оператора присваивания более рационально, чем использование :=.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Jack128, Вы писали:
J>>Здравствуйте, gandjustas, Вы писали:
G>>>Да даже не в этом дело. В C++ можно вернуть из метода экземпляр класса. В делфи нельзя. Ибо экземпляр — это ссылка, для которой явно надо вызвать Free.
J>>Почему нельзя, можно конечно. J>>
J>>function TSameObject.CreateStringList: TStringList;
J>>begin
J>> Result := TStringList.Create;
J>>end;
J>>
G>Не смеши меня.
G>на C++
G>
G>A f()
G>{
G> return A();
G>}
G>...
G>{
G> A x = f();
G>}//Здесь вызвовется деструктор ч
G>
А если дальше было написано: f2(x), которая куданить да засунула X. То же деструктор убьет X?
Вообще то на С++ (как и у Дельфи) утечку памяти можно получить очень легко. Вот с этим как раз и борится шарп, ява и им подобные.
kuj>Ты статью точно читал? Судя по комментарию — нет. Прочти тогда будет о чем поговорить. Заодно посмотри статью в MSDN.
Вот ты её точно не читал. на самом деле эта статья для уровня обычного кодера, а вот как все это разрешить, как отинсталлить — ничего такого нет. вся статья только вокруг использования уже настроенного окружения, в котором все работает 100%. никаких проверок на доступность, верность итд.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Lloyd, Вы писали:
L>>Здравствуйте, gandjustas, Вы писали:
G>>>На Delphi G>>>
G>>>function TSameObject.CreateStringList: TStringList;
G>>>begin
G>>> Result := TStringList.Create;
G>>>end;
G>>>...
G>>>var x:TStringList;
G>>>begin
G>>> x:=SameObject.CreateStringList;
G>>>end; //А тут ничего не вызовется, получим утечку памяти
G>>>
L>>С тем же успехом можно сказать, что и в C++ нельзя позвращать ссылку, т.к. ее нужно будет освобождать. G>В C++ можно вернуть объект (не ссылку), в делфяф такое нельзя сделать в принципе
В Дельфе структура возвращается как значение или как ссылка (это на усмотрение программиста), объекты только как ссылки.
Если в Паскале надо было писать:
PObject = ^TObject;
TObject = object
....
end;
то в Дельфи достаточно:
TObject = object
....
end;
А что С++ гоняет через стек значения всех полей объекта? Не знал.
Здравствуйте, wraithik, Вы писали:
W>В Дельфе структура возвращается как значение или как ссылка (это на усмотрение программиста), объекты только как ссылки. W>Если в Паскале надо было писать:
W>
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, ironwit, Вы писали: I>>фиксируем. СЛИВ защитан.
kuj>Нет никакого слива. Конструктива от тебя тоже нет. Чтоб ввести самый используемый оператор в Delphi надо в несколько раз больше телодвижений, чем C/C++/C#/Java. Хорошо, если бы это позитивно сказывалось на читабельности кода, но не сказывается. Поэтому совершенно объективный вывод: использование = в качестве оператора присваивания более рационально, чем использование :=.
с тем комментарием я был не согласен. с данным в общем то да. но все равно по клавишам я барабаню меньше времени чем думаю что там написать поэтому мне не жалко чутьчуть времени на лишний символ. тем более что ИМХО символ := применяется чаще на этапе разработки, и реже на этапе рефакторинга. а я пишу меньше чем рефакторю.
Здравствуйте, wraithik, Вы писали:
W>Вообще то на С++ (как и у Дельфи) утечку памяти можно получить очень легко. Вот с этим как раз и борится шарп, ява и им подобные.
С одним но: в C++ очистку можно автоматизировать с помощью smart pointers (boost::shared_ptr<> — на основе подсчета ссылок, boost::scoped_ptr<> — на основе области видимости, если память не изменяет). В этом его огромное преимущество перед Delphi.
Здравствуйте, hattab, Вы писали:
H>Вникать тут не во что. Я тебя попросил вполне конкретный пример: по аналогии с запросом ICanFly, сделать запрос объекта (без использования интерфейсов, это же, с твоих слов, криво). Ты мне приведения типов показываешь Это далеко не одно и то же. Ломай стены в своей голове.
Что в твоем понимании "запрос объекта" и "запрос интерфейса" и чем оно отличается от приведения типа?
Сколько лет программированием занимаюсь, а подобного бреда еще не слышал.
Здравствуйте, ironwit, Вы писали:
kuj>>Ты статью точно читал? Судя по комментарию — нет. Прочти тогда будет о чем поговорить. Заодно посмотри статью в MSDN. I>Вот ты её точно не читал. на самом деле эта статья для уровня обычного кодера, а вот как все это разрешить, как отинсталлить — ничего такого нет. вся статья только вокруг использования уже настроенного окружения, в котором все работает 100%. никаких проверок на доступность, верность итд.
Еще один читатель. Вас что нужно носом тыкать? Или подобная невнимательность характерна для всех дельфятников?
Здравствуйте, ironwit, Вы писали:
kuj>>Нет никакого слива. Конструктива от тебя тоже нет. Чтоб ввести самый используемый оператор в Delphi надо в несколько раз больше телодвижений, чем C/C++/C#/Java. Хорошо, если бы это позитивно сказывалось на читабельности кода, но не сказывается. Поэтому совершенно объективный вывод: использование = в качестве оператора присваивания более рационально, чем использование :=.
I>разговор начался с тебе в Delphi — зажать shift, нажать 6, отжать shift, нажать = — отсюда — Re[7]: Чем вам всем не угодил Delphi?
Только добавь сюда еще и постоянную необходимость следить за текущей выбранной раскладкой.
Очень чудно.
I>с тем комментарием я был не согласен. с данным в общем то да. но все равно по клавишам я барабаню меньше времени чем думаю что там написать поэтому мне не жалко чутьчуть времени на лишний символ. тем более что ИМХО символ := применяется чаще на этапе разработки, и реже на этапе рефакторинга. а я пишу меньше чем рефакторю.
Здравствуйте, wraithik, Вы писали:
W>А если дальше было написано: f2(x), которая куданить да засунула X. То же деструктор убьет X?
f2 не может никуда засунуть x.
Она может засунуть только указатель/ссылку или копию x.
W>Вообще то на С++ (как и у Дельфи) утечку памяти можно получить очень легко. Вот с этим как раз и борится шарп, ява и им подобные.
При использовании смартпоинтеров на С++ получить утечку памяти сильно труднее чем на дельфе.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandjustas, Вы писали:
W>>А что С++ гоняет через стек значения всех полей объекта? Не знал. G>Да, гоняет.
И не просто гоняет, а конструкторы копирования с деструкторами дергает.
Правда тяжелые объекты как правило таскают внутри какихнибудь смартпоинтеров которые только и делают что счетчиком ссылок щелкают.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, kuj, Вы писали:
kuj>Язык остался строго типизированным,
Понятие строгой типизации вобще какоето не понятное.
Язык может иметь статическую типизацию(хаскель), динамическую (смаллтолк) или ту или иную форму смешанной (когда преобладает либо та либо другая например C# в основном статически типизированный но там тожно делать придения типав от базового типа к потомку в рантайме).
Еще языки бывают типобезопасными (систему типов обойти нельзя например хаскль) и не типобезопасными (система типов обходится на раз например С/С++).
kuj>но получил многие элементы динамических языков:
Ваще бред.
kuj>type inference,
К динамической типизации отношения не имеет.
kuj>closures,
К динамической типизации отношения не имеет.
kuj>duck typing
К динамической типизации отношения не имеет.
kuj>(производная от dynamic typing: var something = new ClassA(...); ),
var вобщето недоделанный type inference
kuj>eval,
Ты про System.Reflection.Emit?
kuj>Такой .NET язык как Boo пошел еще дальше и взял такие элементы динамических языков как: syntactic macros (в отличии от макросов в C++, макросы в Boo имеют больше черт, характерных макросам в динамических языках — они модифицируют compiler pipeline) и generators.
На немерле посмотри да.
kuj>Полноценным динамическим языком в мире .NET на основе DLR станет IronRuby.
Вот уж что должно умереть это полноценные динамически типизированные языки ибо тормозной багодром по определению. И не лечится.
Короче иди поучи чтонибудь про системы типов.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Языки могут быть классифицированы как системы со статической типизацией и языки с динамической типизацией. Статически-типизированные языки могут быть в дальнейшем подразделены на языки с обязательной декларацией, где каждая переменная и объявление функции имеет обязательное объявление типа, и языки с выводимыми типами. Иногда динамически-типизированные языки называются латентно типизированными.
WH>Короче иди поучи чтонибудь про системы типов.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Здравствуйте, Don Reba, Вы писали:
DR>>А QIP даже не поддерживает Юникод. О каком качестве можно говорить?
ДГ>Юзал 2005-й. Глюкалово то ещё.
Про QIP и юникод скажу так: есть Infium, попробуйте его.
а насчет глюкалова и всего прочего — посидите на стандартной шестой асе
на каком часу Вы взвоете?
а писана она на сях насколько я понимаю
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, kuj, Вы писали:
kuj>>Здравствуйте, DOOM, Вы писали:
kuj>>Это не субъективизм, а реалии жизни. Вместо того, чтоб сделать нормальный строго типизированный язык, взяли самую худшую черту динамического языка и прилепили ее в виде специального типа Variant. DOO>В результате это существенно упростило некоторые задачи, что и позволило стать дельфи языком для непрограммистов. Значит с рыночной точки зрения решение было правильным
Ну ты пошутил. Языки с динамической типизацией гораздо более требовательны к квалификации программиста, чем языки со статической типизацией.
Более того, для программы на динамически типизируемом языке необходимо максимальное покрытие тестами для доказательства что она ВООБЩЕ РАБОТАЕТ.
Делфи никогда не станет языком для "непрограммистов" именно потому, что надо достаточно много знать и за многим следить чтобы программа заработала.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, ironwit, Вы писали:
kuj>Еще один читатель. Вас что нужно носом тыкать? Или подобная невнимательность характерна для всех дельфятников?
ткни. а то от тебя кроме грубостей и слива ничего нет.
Здравствуйте, kuj, Вы писали:
kuj>Языки могут быть классифицированы как системы со статической типизацией и языки с динамической типизацией.
Вобще говоря чистых представителей динамически типизированных и в особенности статически типизированных языков (ML с некоторыми потомками. Что еще?) не так много.
В основном преобладают смешенные. C#, жаба, С++...
kuj>Статически-типизированные языки могут быть в дальнейшем подразделены на языки с обязательной декларацией, где каждая переменная и объявление функции имеет обязательное объявление типа, и языки с выводимыми типами.
Тут вобще граница весьма размыта.
Например С++ выводит типы шаблонов функций. В новом стандарте бедет изменено значение ключевого слова auto.
Да и в C# появился var.
Но сравнивать их с какимнибудь хаскелем или хотябы немерлом в плане вывода типов.
kuj>Иногда динамически-типизированные языки называются латентно типизированными. http://en.wikipedia.org/wiki/Latent_typing
WH>>Короче иди поучи чтонибудь про системы типов. kuj>Начни с себя.
Я в отличии от некоторых не путаю вывод типов и динамическую типизацию.
А еще я знаю что утиная типизация бывает вполне себе статической.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Все мои знания по ООП говорят мне, что оба раза мы создали COM-объект, унаследовавшись от базового COM-интерфейса. То, что второй объект не имеет методов, доступных из других COM-обхектов (в частности, они не используют стандартные COM-типы), никак этому факту не противоречит
kuj>Это верно с одним но — оба интерфейса автоматически наследуют все методы родительского интерфейса IUnknown: AddRef, Release, QueryInterface.
Ну это естественно. С COM я ооочень долго не работал поэтому просто не помнил, что там в этих интерфейсах было
G>Ну ты пошутил. Языки с динамической типизацией гораздо более требовательны к квалификации программиста, чем языки со статической типизацией.
Зато, как ни странно, гораздо менее требовательны к квалификации непрограммиста. Доказано это уже давно — еще начиная с бэйсика.
G>Делфи никогда не станет языком для "непрограммистов".
Тот факт, что он им являлся лет дак дцать мы во внимание принимать, конечно, не будем.
Здравствуйте, hattab, Вы писали:
H>>>>>Семантика для работы с интерфейсными классами и с обычными может быть одинаковой (см. TComponent). Но все это тонкости дающие большую гибкость. И необъяснимые глюки это может вызвать только там, где программист работает сам незная с чем (или не до конца понимая механизм). G>>>>В C# люди работают, не зная с чем, и баги не возникают почему-то. H>>> уморил. G>>Может тебе и смешно, а я уже успел почуствовать насколько меньше люди ошибатся с использованием C# и Java, по сравнению с темже Delphi G>>Причем среднее всермя обучения C# гораздо меньше чем для Delphi
H>Да-да. Я это уже слышал и не раз. За короткий срок невозможно научиться грамотно программировать на чем-бы то нибыло. Я соглашусь, что двоечнику после Delphi-AccessViolation'ов будет легче под .Net/Java. Однако создавать качественного продукта он не сможет. Пердульки бухгалтерские его удел. Максимум.
Мне очень нравиться "пердульки бухгалтерские". Откуда такое пренебрежение к основным деженжым вещам? Ведь большиство действительно серьезных программ пишется для бизнеса являются "бухлагтерскими пердульками" И там качество специалиста определяет разницу в сотни тысячи долларов. Мне аж даже интересно стало, что вы считаете достойным делом программиста, если убрать "пердульки бухглатерские".
G>>>>Я ловил сотни ошибоки из-затого что люди забывали/не_знали_что_надо вызывать Free. В Управляемых средах вообще таких проблем нет. Придирки вполе по делу. Вы просто не понимаете, потому что не работали с этим. H>>>Если люди чего-то там не знали/забывали, это характеризует только их, но не инструмент. Если выражаться простым языком: не можешь срать -- не мучай жопу. В управляемых средах, таки, есть место ручной очистке (пусть даже семантически скрываемой) для объектов владеющих ресурсами. Что начнется, когда человек, который работает не зная с чем (с твоих же слов), будет следовать навязываемой идеологии... G>>Какой-то бред, в чем смысл вашего высказывания?
H>Ты теряешь не только нить...
Я тоже потерял нить, наверное кто то плохо свои мысли формулирует? Я, например их не понимаю, наверное не дозрел еще.
H>>>>>Какая разница кто-кого догоняет или откуда заимствуются те или иные фичи? Ты тут о минусах говорил, я же тебе на плюсы указываю. G>>>>Эти плюсы не перекрывают минусы. А в других языках и платформах минусов поменьше. H>>>В других платформах есть тормоза неизвестно откуда появляющиеся, но теория их существование отрицает G>>Что дороже покупка в два раза более мощногокомпьютера или в два раза больше времени работы программиста?
H>Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем.
Если требуется расширение функциональности, то за это надо платить, в том числе и сменой парка бухгалтерских машин. Вопрос окупится или нет, если новый функционал позволит выполнять те же оперции меньшим количеством операторов?
H>>>Мы тут, что С++ обсуждаем или Java? Ты сказал, что в Delphi чего-то нет. Я тебе говорю, что есть (может оно и в семерке уже было, я не помню). G>>Перечитай первые посты. Идет сравнение Delphi c другими популярными сейчас языками и платформами.
H>Уж не знаю, как ты, а я твои безосновательные выпады парирую.
G>>Если вам так нарвится делфи, то откройте ветк в которой опишите чем вам так нравится программировать на Delphi. Желательно в КУ.
H>Мне оно надо? У меня фетиша-то нету, в отличии от...
А как же Дельфи, разве в данном контексте не фетишь?
G>>ЗЫ Можем вспонить web. какие у делфи возможности создания web-приложений? Правильно — никаких!!!! Это удар ниже пояса.
H>Хотя Delphi и не среда для веб-разработчика, но имеется WebSnap, Intraweb, WebServices. Ты некомпетентен.
Ты не компетентен, спрашивается про WEB разработкe, а не слова где встречается WEB.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Да-да. Я это уже слышал и не раз. За короткий срок невозможно научиться грамотно программировать на чем-бы то нибыло. Я соглашусь, что двоечнику после Delphi-AccessViolation'ов будет легче под .Net/Java. Однако создавать качественного продукта он не сможет. Пердульки бухгалтерские его удел. Максимум. G>>Что в твоем понимании качественный продукт? G>>Я видел бухгалтерскую программу на C#, клон программы на Delphi. На шарпе она быстрее работала, была более стабильна и стоила в 2 раза дешевле.
H>Я тоже могу рассказать, что видел Ты мне поверишь? Читать здесь
H>>>Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем. G>>Ты не путай, для коробочного продукта примерные параметры по быстродействию известны заранее и продукт не выпустят если не программа не пройдет по этим параметрам. Для ПО, разрабатываемого на заказ бывает выгоднее поменять железо, чем оплачивать работу десятка программистов. G>>Тем боее саме серьезные потери производительности происходят в основном не по вине платформы, а вследствие неправльного выблора/реализации алгоритмов.
H>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно)
Конечно не на стороне .NET, цена владениа у Delphi окажется выше.
Здравствуйте, DOOM, Вы писали: DOO>Популярная библиотека Gtk является чисто сишной — на одних struct'ах построена и ничего, народ пользуется.
Но в Gtk+ реализован объектно-ориентированный поход, только классы там реализованы по-сишному: на структурах/указателях/макросах. А в биндингах Gtk+ к ОО-языкам — все это оборачивается в классы соответствующего языка.
M>>Все мои знания по ООП говорят мне, что оба раза мы создали COM-объект, унаследовавшись от базового COM-интерфейса. То, что второй объект не имеет методов, доступных из других COM-обхектов (в частности, они не используют стандартные COM-типы), никак этому факту не противоречит
H>У интерфейсов нет понятий видимости или невидимости методов. Интерфейс рассматривается только в целом. Тот факт, что второй интерфейс не совместим с типами COM, делает его не COM интерфейсом.
Тот факт, то второй интерфейс не совместим с типами COM означает обычно только то, что у программиста руки кривые.
При этом второй класс магическим образом становится COM-объектом как только в него добавляются функции с соответствующими сигнатурами?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, _d_m_, Вы писали:
H>>>Delphi не обязывает программиста иметь конфигурационные файлы, от которых будет зависеть работоспособность приложения. Вот и вся разница.
___>>Не понял разницы. ДотНет программы тоже не обязывают. А даже если бы обязывали: "также как считать, что пользователи могут залить клавиатуру кофе недостатком клавиатуры."
H>В смысле не обязывают? А эти конфиги упоминаемые тут для настройки ремотинга? Для пользователей любящих кофе давно есть клавы-"непромокайки" , и даже буки такие есть (видимо производитель счел, таки, недостатком )
Ээээ ты просто не в курсе, действительно не обязывают. Как хранить и использовать это секцальное дело программиста, может использовать конфиги стандартные, может свой велосипед изобрести, может для каждого компа в коде все прошить.
Здравствуйте, hattab, Вы писали: H>>>>>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java? G>>>>Хуже. В WCF можно параметры сервиса (протоколы и пр.) поменять в конфиге, не трогая код. H>>>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы G>>Когда я аботал на делфях клиент умудрился поудалять ini файлы с настройками. G>>От пользователя-дурака никто не застрахован.
H>Конечно никто. Но если у тебя софтина перестала от этого работать...
То надо трахать техподдержку. Разработчик тут не причем. Или ты вообще конфигами не пользуешься? Что для под каждый комп свою версию компилируешь?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, kuj, Вы писали:
kuj>>>>Какие еще мои тезисы? Давай уж конкретно с цитатами.
H>>>Да тебе бесполезно что-либо цитировать. Я тебя уже тыкал носом в твоиже слова, которые мне объяснить не смог (напоминаю, о минусах сборки мусора на управляемых kuj>>типах в Delphi). Ссылку на описание фризов нашел, не поленился, от тебя снова тишина. Оно мне надо так напрягаться Проще с тобой завязать и только. Будь здоров.
kuj>>Ну-ну. Научись читать сначала и в теме разберись хоть немного.
H>Я с Паскалем 13 лет. Спасибо.
А у меня вопрос, а что-нибудь кроме паскаля за плечами есть? Или не читал, но осуждаю?
H>Я тебе говорил про потерю ресурсов на dbconnection. Ты мне сказал, что FxCop тебе все покажет. Ы?
Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?
Здравствуйте, kuj, Вы писали:
kuj>Поэтому совершенно объективный вывод: использование = в качестве оператора присваивания более рационально, чем использование :=.
Предлагаю заменить во всех C-подобных язаках if на $, for на #, return на @.
А то ведь это дикий синтаксический оверхед!!!
Здравствуйте, Mamut, Вы писали:
kuj>>>>Это из разряда "на JS можно написать мощный интерфейс пользователя". DOO>>>Ну c JS слишком долго лазить за примерами, kuj>>Слив засчитан.
M>Долго и пристально посмотри на свой любимый браузер...
Что не так с моим любимым браузером? Ты разве не знаешь, что Firefox написан на C++, а не на Javascript?
Ты хоть разберись о чем речь, прежде чем влазить в спор.
kuj>>Поэтому совершенно объективный вывод: использование = в качестве оператора присваивания более рационально, чем использование :=.
С>Предлагаю заменить во всех C-подобных язаках if на $, for на #, return на @. С>А то ведь это дикий синтаксический оверхед!!!
-1
В отличии от := / = такая замена ухудшит читабельность кода => плохо.
kuj>>>>>Это из разряда "на JS можно написать мощный интерфейс пользователя". DOO>>>>Ну c JS слишком долго лазить за примерами, kuj>>>Слив засчитан.
M>>Долго и пристально посмотри на свой любимый браузер...
kuj>Что не так с моим любимым браузером? Ты разве не знаешь, что Firefox написан на C++, а не на Javascript?
kuj>Ты хоть разберись о чем речь, прежде чем влазить в спор.
Весь-весь на С++ написан? Со всеми расширениями? И XUL там вообще нигде-нигде не используется?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, int64, Вы писали:
I>>По своему опыту скажу, что низкокачественного кода было написано дохрена и больше, чем высококачественного, не зависимо от платформы.
G>Во всех программах на делфи, которые я видел, были утечки памяти. Для Java и .NET такого быть не может
В версии дотнета 1.1 были утечки, к сожалению — мы сталкивались совершенно явно с утечками. Но это скорее баги реализации, в 2.0 почти все убрали.
Здравствуйте, Сергей, Вы писали:
kuj>>В отличии от := / = такая замена ухудшит читабельность кода => плохо.
С>Это шутка такая была. С>Замена := на = читаемость кода не улучшит.
Не улучшит и не ухудшит, но привнесет "синтаксический оверхед".
Здравствуйте, Mr.Cat, Вы писали:
kuj>>duck typing (производная от dynamic typing: var something = new ClassA(...); )
MC>Это не duck typing. Я вообще нормальной утятины в C# не заметил.
Да уж, написал duck typing, подразумевая частичный type inference. Виноват.
Здравствуйте, Mamut, Вы писали:
kuj>>Ты хоть разберись о чем речь, прежде чем влазить в спор.
M>Весь-весь на С++ написан? Со всеми расширениями? И XUL там вообще нигде-нигде не используется?
Да при чем здесь это? Ты разберись о чем спор был.
kuj>>>Ты хоть разберись о чем речь, прежде чем влазить в спор.
M>>Весь-весь на С++ написан? Со всеми расширениями? И XUL там вообще нигде-нигде не используется?
kuj>Да при чем здесь это? Ты разберись о чем спор был.
Ты считаешь, что на процедурном языке невозможно написать корпоративную систему (хотя еще надо выяснить, что ты под этим понимаешь). И ты считаешь, что это так же невозможно, как и написать сложный GUI на Javascript'е.
Так вот, на JS сложный гуй написать можно
ЗЫ. Ядро Линукса — это достаточно корпоративно? А вполне себе на процедурном языке написано...
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>Ну ты пошутил. Языки с динамической типизацией гораздо более требовательны к квалификации программиста, чем языки со статической типизацией. DOO>Зато, как ни странно, гораздо менее требовательны к квалификации непрограммиста. Доказано это уже давно — еще начиная с бэйсика.
Тут ты неправ, без должной квалификации на бейсике можно написать программу (которая поставляется вместе с программистом), и практически невозможно написать продукт. Для серьезных задач приходится дописывать COM объекты на других языках, например на C++.
Низкий порог вхождения еще не означает легкость в использовании.
G>>Делфи никогда не станет языком для "непрограммистов". DOO>Тот факт, что он им являлся лет дак дцать мы во внимание принимать, конечно, не будем.
Может и является, но "непрограммисты" очень часто рожают просто ужасный код, с кучей утечек и багов. Все успешные проекты на делфи написаны профессионалами.
Здравствуйте, Mamut, Вы писали:
kuj>>>>Ты хоть разберись о чем речь, прежде чем влазить в спор.
M>>>Весь-весь на С++ написан? Со всеми расширениями? И XUL там вообще нигде-нигде не используется?
kuj>>Да при чем здесь это? Ты разберись о чем спор был.
M>Ты считаешь, что на процедурном языке невозможно написать корпоративную систему (хотя еще надо выяснить, что ты под этим понимаешь). И ты считаешь, что это так же невозможно, как и написать сложный GUI на Javascript'е.
Мамут в своем духе — перекручивает слова налево и направо. Чисто для справки: я НЕ говорил, что это невозможно. Мамут, в конце-то концов, научись читать.
kuj>>>Да при чем здесь это? Ты разберись о чем спор был.
M>>Ты считаешь, что на процедурном языке невозможно написать корпоративную систему (хотя еще надо выяснить, что ты под этим понимаешь). И ты считаешь, что это так же невозможно, как и написать сложный GUI на Javascript'е.
kuj>Мамут в своем духе — перекручивает слова налево и направо. Чисто для справки: я НЕ говорил, что это невозможно. Мамут, в конце-то концов, научись читать.
Встречное предложение: научись писать:
Хотелось бы посмотреть как ты будешь чисто процедурно писать средних размеров корпоративную систему. Это из разряда "на JS можно написать мощный интерфейс пользователя".
Поясняй, что ты имеешь в виду, раз тебя никто не понимает. Заодно объясни, что ты имеешь в виду, говоря "корпоративная система средних размеров"
Здравствуйте, Mamut, Вы писали:
kuj>>>>Да при чем здесь это? Ты разберись о чем спор был.
M>>>Ты считаешь, что на процедурном языке невозможно написать корпоративную систему (хотя еще надо выяснить, что ты под этим понимаешь). И ты считаешь, что это так же невозможно, как и написать сложный GUI на Javascript'е.
kuj>>Мамут в своем духе — перекручивает слова налево и направо. Чисто для справки: я НЕ говорил, что это невозможно. Мамут, в конце-то концов, научись читать.
M>Встречное предложение: научись писать: M>
M>Хотелось бы посмотреть как ты будешь чисто процедурно писать средних размеров корпоративную систему. Это из разряда "на JS можно написать мощный интерфейс пользователя".
M>Поясняй, что ты имеешь в виду, раз тебя никто не понимает.
Разницы между "нельзя" и "нецелесообразно трудоемко" ты, видимо, не знаешь? Ну и ладно. Теперь будешь знать.
M>Заодно объясни, что ты имеешь в виду, говоря "корпоративная система средних размеров" http://en.wikipedia.org/wiki/Enterprise_software
M>>ЗЫ. Ядро Линукса — это достаточно корпоративно?
kuj>Очень смешно.
И что ты этим хотел сказать?
1. Что ядро Линукса проще, чем некая сферовакуумная "корпоративная система среднего размера"?
2. Что ядро Линукса написано не на процедурном языке?
3. Что ядро Линукса нельзя сравнивать с некими сферовакуумными "корпоративными системами среднего уровня"?
Здравствуйте, Mamut, Вы писали:
M>>>ЗЫ. Ядро Линукса — это достаточно корпоративно?
kuj>>Очень смешно.
M>И что ты этим хотел сказать?
M>1. Что ядро Линукса проще, чем некая сферовакуумная "корпоративная система среднего размера"? M>2. Что ядро Линукса написано не на процедурном языке? M>3. Что ядро Линукса нельзя сравнивать с некими сферовакуумными "корпоративными системами среднего уровня"?
M>Что?
Только то, что банально не понимаешь разницы между "ядром линукса" и "корпоративной системой". Помочь ничем не могу — восполнять пробелы в твоем образовании задарма не собираюсь.
Здравствуйте, hattab, Вы писали:
H>Delphi программы в релизном варианте не поотлаживаешь. Отключи DebugInfo и отладчик работать перестанет. По поводу IntfClear... Ты сам понимаешь нелепость своего предложения об инлайне? Давай уже цифры.
Цифр у меня нет и не будет, ибо нет дельфей. Но в отличие от некоторых у меня есть логика, которая подсказывает мне, что инлайнинг коротких функций даст прирост производительности, особенно если эти короткие ф-ции вызываются часто...
M>>Поясняй, что ты имеешь в виду, раз тебя никто не понимает. kuj>Разницы между "нельзя" и "нецелесообразно трудоемко" ты, видимо, не знаешь? Ну и ладно. Теперь будешь знать.
Теперь ясно, что в данном конкретном случае ты имел ввиду "трудоемко", а не "невозможно". В любом случае, сравнение с GUI на Яваскрипте некорректно. Кури XUL
M>>Заодно объясни, что ты имеешь в виду, говоря "корпоративная система средних размеров" kuj>http://en.wikipedia.org/wiki/Enterprise_software
Сферический конь в вакууме, как и следовало ожидать. Ты предлагаешь написать весь пункт 4 на процедурном языке?
Здравствуйте, Mamut, Вы писали:
M>>>ЗЫ. Ядро Линукса — это достаточно корпоративно?
kuj>>Очень смешно.
M>И что ты этим хотел сказать?
M>1. Что ядро Линукса проще, чем некая сферовакуумная "корпоративная система среднего размера"? M>2. Что ядро Линукса написано не на процедурном языке? M>3. Что ядро Линукса нельзя сравнивать с некими сферовакуумными "корпоративными системами среднего уровня"?
M>Что?
Сколько ядро линукса людей пишет и дописывает? И сколько времени то происходит?
Для корпоративного ПО есть более-менее фиксированные сроки сдачи. При разработке корпоративного ПО надо еще уложиться в бюджет.
Без использования правильных\проверенных средств и подходов такое сделать не получится.
Никто не говорит о возможности и невозможности реализации чего-либо, вопрос в цене.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Mamut, Вы писали:
M>>>>ЗЫ. Ядро Линукса — это достаточно корпоративно?
kuj>>>Очень смешно.
M>>И что ты этим хотел сказать?
M>>1. Что ядро Линукса проще, чем некая сферовакуумная "корпоративная система среднего размера"? M>>2. Что ядро Линукса написано не на процедурном языке? M>>3. Что ядро Линукса нельзя сравнивать с некими сферовакуумными "корпоративными системами среднего уровня"?
M>>Что?
kuj>Только то, что банально не понимаешь разницы между "ядром линукса" и "корпоративной системой". Помочь ничем не могу — восполнять пробелы в твоем образовании задарма не собираюсь.
Корпоративная система — это очень большое и расплывчатое понятие. То есть ты предлагаешь написать сферовакуумного коня, а когда тебе скажут "ну... это сложно", то ты наверняка ответишь "ага, я же говорил!"
Здравствуйте, Mamut, Вы писали:
M>>>Поясняй, что ты имеешь в виду, раз тебя никто не понимает. kuj>>Разницы между "нельзя" и "нецелесообразно трудоемко" ты, видимо, не знаешь? Ну и ладно. Теперь будешь знать.
M>Теперь ясно, что в данном конкретном случае ты имел ввиду "трудоемко", а не "невозможно". В любом случае, сравнение с GUI на Яваскрипте некорректно. Кури XUL
Не курю.
M>>>Заодно объясни, что ты имеешь в виду, говоря "корпоративная система средних размеров" kuj>>http://en.wikipedia.org/wiki/Enterprise_software M>Сферический конь в вакууме, как и следовало ожидать. Ты предлагаешь написать весь пункт 4 на процедурном языке?
Софистика.
Здравствуйте, Mamut, Вы писали:
M>Корпоративная система — это очень большое и расплывчатое понятие. То есть ты предлагаешь написать сферовакуумного коня, а когда тебе скажут "ну... это сложно", то ты наверняка ответишь "ага, я же говорил!"
Ты действительно так глуп или только делаешь вид? Хорошо, специально для тебя уточню — Microsoft Dynamics NAV.
_>>Отвечал на ваш вопрос, если не понятно. Кроме формошлепства кое-что еще имеется. _>В Delphi тоже много чего имеется. И кроме формошлепства он позволяет писать и консольные приложения (по вашему посту у меня возникло очень стойкое ощущение что вы этого просто не знали) и сервисы (аналогично). Что касается горячелюбимого веба, то не нужно его сюда приплетать, ибо на джаве в отличие од делфей, win-сервис, например, тоже не напишешь.
Да причем тут Дельфи?! Ваш вопрос был — еще раз — "чем все современные визуальные IDE не формошлепство?". Я ответил чем.
Хорошо, что в Дельфи это есть. Но не о том речь.
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, Mamut, Вы писали:
G>>Без использования правильных\проверенных средств и подходов такое сделать не получится.
M>Я и не спорю Вернее спорю ради спора
В следующий раз постарайся конструктивнее без софистики и перекручивания слов. Ок?
M>>Теперь ясно, что в данном конкретном случае ты имел ввиду "трудоемко", а не "невозможно". В любом случае, сравнение с GUI на Яваскрипте некорректно. Кури XUL kuj>Не курю.
В фигуральном смысле стоило бы
M>>>>Заодно объясни, что ты имеешь в виду, говоря "корпоративная система средних размеров" kuj>>>http://en.wikipedia.org/wiki/Enterprise_software M>>Сферический конь в вакууме, как и следовало ожидать. Ты предлагаешь написать весь пункт 4 на процедурном языке? kuj>Софистика.
G>>>Без использования правильных\проверенных средств и подходов такое сделать не получится.
M>>Я и не спорю Вернее спорю ради спора
kuj>В следующий раз постарайся конструктивнее без софистики и перекручивания слов. Ок?
M>>Корпоративная система — это очень большое и расплывчатое понятие. То есть ты предлагаешь написать сферовакуумного коня, а когда тебе скажут "ну... это сложно", то ты наверняка ответишь "ага, я же говорил!"
kuj>Ты действительно так глуп или только делаешь вид? Хорошо, специально для тебя уточню — Microsoft Dynamics NAV.
Уже совсем другой компот. Теперь осталось решить, сложнее ли оно, чем ядро Линукса
Здравствуйте, Mamut, Вы писали:
M>>>Теперь ясно, что в данном конкретном случае ты имел ввиду "трудоемко", а не "невозможно". В любом случае, сравнение с GUI на Яваскрипте некорректно. Кури XUL kuj>>Не курю.
M>В фигуральном смысле стоило бы
Я рад, что ты знаешь что такое XUL. Но какое это имеет отношение к теме спора? Давай тогда уж и XAML с WPF и Silverlight сюда — за компанию.
Здравствуйте, Mamut, Вы писали:
kuj>>Ты действительно так глуп или только делаешь вид? Хорошо, специально для тебя уточню — Microsoft Dynamics NAV.
M>Уже совсем другой компот. Теперь осталось решить, сложнее ли оно, чем ядро Линукса
Здравствуйте, kuj, Вы писали:
kuj>Я рад, что ты знаешь что такое XUL. Но какое это имеет отношение к теме спора? Давай тогда уж и XAML с WPF и Silverlight сюда — за компанию.
XUL был упомянут в ответ на заявление о том, что яваскрипт не подходит для программирования сложного интерфейса.
Здравствуйте, kuj, Вы писали:
kuj>Ты действительно так глуп или только делаешь вид? Хорошо, специально для тебя уточню — Microsoft Dynamics NAV.
Не понимаю, к чему эти оскорбления на ровном месте.
Да и телепатов тут мало, поэтому не каждый догадался, что под словами "корпоративная система" ты имел ввиду Microsoft Dynamics NAV.
Здравствуйте, Сергей, Вы писали:
kuj>>Ты действительно так глуп или только делаешь вид? Хорошо, специально для тебя уточню — Microsoft Dynamics NAV.
С>Не понимаю, к чему эти оскорбления на ровном месте. С>Да и телепатов тут мало, поэтому не каждый догадался, что под словами "корпоративная система" ты имел ввиду Microsoft Dynamics NAV.
И снова софистика. Нет, я не имел в виду конкретно Microsoft Dynamics NAV. Я имел в виду любую корпоративную систему средней сложности.
Здравствуйте, kuj, Вы писали:
kuj>И снова софистика. Нет, я не имел в виду конкретно Microsoft Dynamics NAV. Я имел в виду любую корпоративную систему средней сложности.
Прекрасно. Какие критерии сложности ты имел ввиду при этом?
Здравствуйте, Сергей, Вы писали:
kuj>>И снова софистика. Нет, я не имел в виду конкретно Microsoft Dynamics NAV. Я имел в виду любую корпоративную систему средней сложности.
С>Прекрасно. Какие критерии сложности ты имел ввиду при этом?
Никакие. Это оборот речи. Неужели у всех дельфятников так туго с пониманием?
Здравствуйте, gandjustas, Вы писали:
H>>Вникать тут не во что. Я тебя попросил вполне конкретный пример: по аналогии с запросом ICanFly, сделать запрос объекта (без использования интерфейсов, это же, с твоих слов, криво). Ты мне приведения типов показываешь Это далеко не одно и то же. Ломай стены в своей голове. G>Что в твоем понимании "запрос объекта" и "запрос интерфейса" и чем оно отличается от приведения типа?
Запрос интерфейса: Obj.GetInterface(IIntf) или Obj As IIntf или Intf.QueryInterface(IIntf, IntfVar). Семантика as сводится к QueryInterface (семантика, не реализация). Вот теперь я хочу услышать от тебя, как, по аналогии с запросом интерфейса, ты сделаешь запрос объекта (еще раз: это не приведение типа и не проверка принадлежности объекта к одному из предком запрашиваемого). Это сродни множественному наследованию, не в чистом виде разумеется, но...
G>Сколько лет программированием занимаюсь, а подобного бреда еще не слышал.
Это, кстати, наибанальнейший пример для первокурсников или лицеистов 9-го класса
Здравствуйте, _d_m_, Вы писали:
___>Нет, этот факт характеризует Абрамс — да и никто не застрахован от неудачных решений и выбора. А с Interbase я знаком не понаслышке и мне есть с чем сравнивать. Даже ярые апологеты FB отзаваются об Interbase достаточно не лестно.
H>>Вот еще: H>>
Еще
H>> один малоизвестный факт — использование InterBase для хранения
H>> информации о кредитках в считывающих устройствах, которые используются
H>> на немецких железных дорогах — одной из самых быстрых и развитых
H>> транспортных систем в мире.
___>"никто не застрахован от неудачных решений и выбора". И это вероятно случилось после того, как исходники IB были выложены Богланд, видать сами рихтуют косяки.
Здравствуйте, hattab, Вы писали:
H>>>Вникать тут не во что. Я тебя попросил вполне конкретный пример: по аналогии с запросом ICanFly, сделать запрос объекта (без использования интерфейсов, это же, с твоих слов, криво). Ты мне приведения типов показываешь Это далеко не одно и то же. Ломай стены в своей голове. G>>Что в твоем понимании "запрос объекта" и "запрос интерфейса" и чем оно отличается от приведения типа?
H>Запрос интерфейса: Obj.GetInterface(IIntf) или Obj As IIntf или Intf.QueryInterface(IIntf, IntfVar). Семантика as сводится к QueryInterface (семантика, не реализация). Вот теперь я хочу услышать от тебя, как, по аналогии с запросом интерфейса, ты сделаешь запрос объекта (еще раз: это не приведение типа и не проверка принадлежности объекта к одному из предком запрашиваемого). Это сродни множественному наследованию, не в чистом виде разумеется, но...
Здравствуйте, koandrew, Вы писали:
H>>Delphi программы в релизном варианте не поотлаживаешь. Отключи DebugInfo и отладчик работать перестанет. По поводу IntfClear... Ты сам понимаешь нелепость своего предложения об инлайне? Давай уже цифры.
K>Цифр у меня нет и не будет, ибо нет дельфей. Но в отличие от некоторых у меня есть логика, которая подсказывает мне, что инлайнинг коротких функций даст прирост производительности, особенно если эти короткие ф-ции вызываются часто...
Без цифр стоило базар разводить? Мне твое бла-бла-бла не улыбается.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Вникать тут не во что. Я тебя попросил вполне конкретный пример: по аналогии с запросом ICanFly, сделать запрос объекта (без использования интерфейсов, это же, с твоих слов, криво). Ты мне приведения типов показываешь Это далеко не одно и то же. Ломай стены в своей голове. G>>Что в твоем понимании "запрос объекта" и "запрос интерфейса" и чем оно отличается от приведения типа?
H>Запрос интерфейса: Obj.GetInterface(IIntf) или Obj As IIntf или Intf.QueryInterface(IIntf, IntfVar). Семантика as сводится к QueryInterface (семантика, не реализация). Вот теперь я хочу услышать от тебя, как, по аналогии с запросом интерфейса, ты сделаешь запрос объекта (еще раз: это не приведение типа и не проверка принадлежности объекта к одному из предком запрашиваемого). Это сродни множественному наследованию, не в чистом виде разумеется, но...
А что мешает написать Obj As CSomeclass ?
Какой скаральный смысл в интерфейсах для тебя?
Здравствуйте, hattab, Вы писали:
H>Семантика as сводится к QueryInterface (семантика, не реализация).
Как раз наоборот. Семантика QueryInterface сводится к опреатору as, как он реализован во мноих языках.
Здравствуйте, gandjustas, Вы писали:
H>>>>Вникать тут не во что. Я тебя попросил вполне конкретный пример: по аналогии с запросом ICanFly, сделать запрос объекта (без использования интерфейсов, это же, с твоих слов, криво). Ты мне приведения типов показываешь Это далеко не одно и то же. Ломай стены в своей голове. G>>>Что в твоем понимании "запрос объекта" и "запрос интерфейса" и чем оно отличается от приведения типа?
H>>Запрос интерфейса: Obj.GetInterface(IIntf) или Obj As IIntf или Intf.QueryInterface(IIntf, IntfVar). Семантика as сводится к QueryInterface (семантика, не реализация). Вот теперь я хочу услышать от тебя, как, по аналогии с запросом интерфейса, ты сделаешь запрос объекта (еще раз: это не приведение типа и не проверка принадлежности объекта к одному из предком запрашиваемого). Это сродни множественному наследованию, не в чистом виде разумеется, но...
G>А что мешает написать Obj As CSomeclass ? G>Какой скаральный смысл в интерфейсах для тебя?
Давай я пример приведу:
...
HttpProxy := client As IHttpProxy;
SocksProxy := client As ISocksProxy;
HttpHeaders := client As IHttpHeaders;
Как по твоему, в случае приведения типа к объекту, client должен являться наследником и THttpProxy и TSocksProxy и THttpHeaders? Теперь понятно о чем речь?
H>...
H>HttpProxy := client As IHttpProxy;
H>SocksProxy := client As ISocksProxy;
H>HttpHeaders := client As IHttpHeaders;
H>
H>Как по твоему, в случае приведения типа к объекту, client должен являться наследником и THttpProxy и TSocksProxy и THttpHeaders? Теперь понятно о чем речь?
Открой для себя агрегирование.
class MyClient
{
public IProxy Proxy { get; set; }
public IList<IHttpHeader> HttpHeaders { get; set; }
...
}
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, wraithik, Вы писали:
W>>А что С++ гоняет через стек значения всех полей объекта? Не знал.
kuj>В C++: по указателю, по ссылке и по значению. В последнем случае применяется конструктор копирования.
Ну значит в последенм случае все таки по указателю. Сделай function TMyClass.Copy(): TMyClass и все.
Напомните, чем по ссылке от по указателю отличается.
Здравствуйте, Ведмедь, Вы писали:
H>>Да-да. Я это уже слышал и не раз. За короткий срок невозможно научиться грамотно программировать на чем-бы то нибыло. Я соглашусь, что двоечнику после Delphi-AccessViolation'ов будет легче под .Net/Java. Однако создавать качественного продукта он не сможет. Пердульки бухгалтерские его удел. Максимум.
В>Мне очень нравиться "пердульки бухгалтерские". Откуда такое пренебрежение к основным деженжым вещам? Ведь большиство действительно серьезных программ пишется для бизнеса являются "бухлагтерскими пердульками" И там качество специалиста определяет разницу в сотни тысячи долларов. Мне аж даже интересно стало, что вы считаете достойным делом программиста, если убрать "пердульки бухглатерские".
Улови основную мысль: человек бравирующий тем, что не знает устройства того на чем пишет/чем пользуется не способен написать качественного продукта. Учитывая тот факт, что .Net'а на десктопах что-то не видно, живет он в корпоративном секторе, где и трудятся сии умельцы крапающие свои пердульки.
H>>Ты теряешь не только нить...
В>Я тоже потерял нить, наверное кто то плохо свои мысли формулирует? Я, например их не понимаю, наверное не дозрел еще.
Очень трудно излагать одну и туже мысль нескольким опонентам одновременно. У меня только две руки и одна голова, уж извини.
H>>Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем.
В>Если требуется расширение функциональности, то за это надо платить, в том числе и сменой парка бухгалтерских машин. Вопрос окупится или нет, если новый функционал позволит выполнять те же оперции меньшим количеством операторов?
Расширять функционал можно и без таких затрат. Мне для отрисовки гуя игровая видюха не нужна.
G>>>Если вам так нарвится делфи, то откройте ветк в которой опишите чем вам так нравится программировать на Delphi. Желательно в КУ.
H>>Мне оно надо? У меня фетиша-то нету, в отличии от...
В>А как же Дельфи, разве в данном контексте не фетишь?
Для меня нет. Я уже тут пояснял свою позицию, можешь поискать
G>>>ЗЫ Можем вспонить web. какие у делфи возможности создания web-приложений? Правильно — никаких!!!! Это удар ниже пояса.
H>>Хотя Delphi и не среда для веб-разработчика, но имеется WebSnap, Intraweb, WebServices. Ты некомпетентен.
В>Ты не компетентен, спрашивается про WEB разработкe, а не слова где встречается WEB.
И этот вопрос я уже озвучивал ранее. Поищи. Мне не улыбается по десять раз повторять одно и то же.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, wraithik, Вы писали:
W>>А если дальше было написано: f2(x), которая куданить да засунула X. То же деструктор убьет X? WH>f2 не может никуда засунуть x. WH>Она может засунуть только указатель/ссылку или копию x.
Имелось ввиду ссылку (адрес, я дельфист в прошлом, пожтом у для меня указатель и ссылка синонимы) на объект Х.
W>>Вообще то на С++ (как и у Дельфи) утечку памяти можно получить очень легко. Вот с этим как раз и борится шарп, ява и им подобные. WH>При использовании смартпоинтеров на С++ получить утечку памяти сильно труднее чем на дельфе.
+1
Здравствуйте, Ведмедь, Вы писали:
H>>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно)
В>Конечно не на стороне .NET, цена владениа у Delphi окажется выше.
Здравствуйте, hattab, Вы писали:
H>Улови основную мысль: человек бравирующий тем, что не знает устройства того на чем пишет/чем пользуется не способен написать качественного продукта.
Смешно слышать это от тебя.
В>>А как же Дельфи, разве в данном контексте не фетишь?
H>Для меня нет.
Здравствуйте, Ведмедь, Вы писали:
H>>В смысле не обязывают? А эти конфиги упоминаемые тут для настройки ремотинга? Для пользователей любящих кофе давно есть клавы-"непромокайки" , и даже буки такие есть (видимо производитель счел, таки, недостатком )
В>Ээээ ты просто не в курсе, действительно не обязывают. Как хранить и использовать это секцальное дело программиста, может использовать конфиги стандартные, может свой велосипед изобрести, может для каждого компа в коде все прошить.
Вот и чудно что не обязывает. Какой вариант будет использован средним разработчик чаще всего? Посыл ясен?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали: G>>А что мешает написать Obj As CSomeclass ? G>>Какой скаральный смысл в интерфейсах для тебя?
H>Давай я пример приведу:
H>
H>...
H>HttpProxy := client As IHttpProxy;
H>SocksProxy := client As ISocksProxy;
H>HttpHeaders := client As IHttpHeaders;
H>
Что здесь не так?
Вполне корректный код как на делфи, так и на C# с точностью до синтаксиса.
H>Как по твоему, в случае приведения типа к объекту, client должен являться наследником и THttpProxy и TSocksProxy и THttpHeaders? Теперь понятно о чем речь?
Не понятно.
У любого класса базовый класс может быть только один. Это верно и для делфи, и для .NET, и для Java.
Соответственно приведение объекта к классу, не являющемуся базовым для типа объекта, вызвет ошибку или вернет null при использовании оператора as.
Ты уже написал порядка 10 постов про приведение типов, а еще НИКТО не понял что ты хочешь сказать. Может будешь учиться изъясняться понятнее?
Здравствуйте, Ведмедь, Вы писали:
В>Здравствуйте, hattab, Вы писали: H>>>>>>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java? G>>>>>Хуже. В WCF можно параметры сервиса (протоколы и пр.) поменять в конфиге, не трогая код. H>>>>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы G>>>Когда я аботал на делфях клиент умудрился поудалять ini файлы с настройками. G>>>От пользователя-дурака никто не застрахован.
H>>Конечно никто. Но если у тебя софтина перестала от этого работать...
В>То надо трахать техподдержку. Разработчик тут не причем. Или ты вообще конфигами не пользуешься? Что для под каждый комп свою версию компилируешь?
.Net — разработчик, как я уже понял, всегда ни при чем: за него все решили, за него все написали, ему показали дорогу в светлое будущее
Здравствуйте, kuj, Вы писали:
С>>Прекрасно. Какие критерии сложности ты имел ввиду при этом?
kuj>Никакие. Это оборот речи. Неужели у всех дельфятников так туго с пониманием?
Видимо, с пониманием смысла твоих сообщений туго не только у "дельфятников", поскольку к ним я не отношусь.
Ты бы поменьше использовал подобные обороты речи и побольше бы писал бы о том, что имеешь ввиду — глядишь, и понимать лучше начнут.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ведмедь, Вы писали:
H>Улови основную мысль: человек бравирующий тем, что не знает устройства того на чем пишет/чем пользуется не способен написать качественного продукта. Учитывая тот факт, что .Net'а на десктопах что-то не видно, живет он в корпоративном секторе, где и трудятся сии умельцы крапающие свои пердульки.
Это еще требует доказаельства.
Кстати .NET на десктопах очень даже видно, но .NET позволяет делать не только десктопные прилодения, но и Web. А Web зачастую удобнее в использовании и проще в реализации.
H>Расширять функционал можно и без таких затрат. Мне для отрисовки гуя игровая видюха не нужна.
А кому нужна?
Здравствуйте, Ведмедь, Вы писали:
H>>>>Да тебе бесполезно что-либо цитировать. Я тебя уже тыкал носом в твоиже слова, которые мне объяснить не смог (напоминаю, о минусах сборки мусора на управляемых kuj>>>типах в Delphi). Ссылку на описание фризов нашел, не поленился, от тебя снова тишина. Оно мне надо так напрягаться Проще с тобой завязать и только. Будь здоров.
kuj>>>Ну-ну. Научись читать сначала и в теме разберись хоть немного.
H>>Я с Паскалем 13 лет. Спасибо.
В>А у меня вопрос, а что-нибудь кроме паскаля за плечами есть? Или не читал, но осуждаю?
До паскаля много чего было, после него только Ada в ознакомительном режиме. Под .Net собирался, но не собрался. Я удовлетворил твой интерес к моей скромной персоне?
H>>Я тебе говорил про потерю ресурсов на dbconnection. Ты мне сказал, что FxCop тебе все покажет. Ы?
В>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?
Со временем... С каким? Сутки? Двое? В нативе оно конечно не освободится, но у натива и посыл другой: взял -- верни. Глубина проблемы ясна?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ведмедь, Вы писали:
H>>>В смысле не обязывают? А эти конфиги упоминаемые тут для настройки ремотинга? Для пользователей любящих кофе давно есть клавы-"непромокайки" , и даже буки такие есть (видимо производитель счел, таки, недостатком )
В>>Ээээ ты просто не в курсе, действительно не обязывают. Как хранить и использовать это секцальное дело программиста, может использовать конфиги стандартные, может свой велосипед изобрести, может для каждого компа в коде все прошить.
H>Вот и чудно что не обязывает. Какой вариант будет использован средним разработчик чаще всего? Посыл ясен?
Средний разработчик на Java и .NET будет использовать конфиги.
А на делфи — не будет. В делфи для этого средств маловато.
Можешь не спорить ибо .NET и Java ты не знаешь.
Здравствуйте, Сергей, Вы писали:
С>>>Прекрасно. Какие критерии сложности ты имел ввиду при этом?
kuj>>Никакие. Это оборот речи. Неужели у всех дельфятников так туго с пониманием?
С>Видимо, с пониманием смысла твоих сообщений туго не только у "дельфятников", поскольку к ним я не отношусь.
Ну-ну. С>Ты бы поменьше использовал подобные обороты речи и побольше бы писал бы о том, что имеешь ввиду — глядишь, и понимать лучше начнут.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ведмедь, Вы писали:
H>>>Я с Паскалем 13 лет. Спасибо.
В>>А у меня вопрос, а что-нибудь кроме паскаля за плечами есть? Или не читал, но осуждаю?
H>До паскаля много чего было, после него только Ada в ознакомительном режиме. Под .Net собирался, но не собрался. Я удовлетворил твой интерес к моей скромной персоне?
Сейчас 2008 год, когда ты начал заниматься паскалем был 1995, в то время в России мало чего было. Сейчас это уже все устарело.
H>>>Я тебе говорил про потерю ресурсов на dbconnection. Ты мне сказал, что FxCop тебе все покажет. Ы?
В>>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?
H>Со временем... С каким? Сутки? Двое? В нативе оно конечно не освободится, но у натива и посыл другой: взял -- верни. Глубина проблемы ясна?
Никто не мешает писать в стиле взял — верни в управляемых средах (на самом деле так писать даже лучше). С одной поправкой: в управляемых средах память не является таким ресурсом.
Где тут глубина проблемы?
Здравствуйте, gandjustas, Вы писали:
H>>Давай я пример приведу:
H>>
H>>...
H>>HttpProxy := client As IHttpProxy;
H>>SocksProxy := client As ISocksProxy;
H>>HttpHeaders := client As IHttpHeaders;
H>>
G>Что здесь не так? G>Вполне корректный код как на делфи, так и на C# с точностью до синтаксиса.
Отлично
H>>Как по твоему, в случае приведения типа к объекту, client должен являться наследником и THttpProxy и TSocksProxy и THttpHeaders? Теперь понятно о чем речь? G>Не понятно.
Мдя... Я устал твердить одно и тоже.
G>У любого класса базовый класс может быть только один. Это верно и для делфи, и для .NET, и для Java. G>Соответственно приведение объекта к классу, не являющемуся базовым для типа объекта, вызвет ошибку или вернет null при использовании оператора as.
Я показал запрос интерфейса. Но ты ранее сказал, что мое решение основанное на интерфейсах это следствие кривизны Delphi. Я от тебя видимо уже не дождусь примера на запрос объекта, ибо ты сказал, что и на объектах можно все реализовать. Причем, отдавать объекты посредством свойств нельзя, ибо противоречит условиям задачи (сущность не может знать чего от нее могут попросить).
G>Ты уже написал порядка 10 постов про приведение типов, а еще НИКТО не понял что ты хочешь сказать. Может будешь учиться изъясняться понятнее?
Ты сам просил задачу, а не решение. Я описал в терминах заказчика. Вопрос понимания -- твоя проблема.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, hattab, Вы писали:
H>>Здравствуйте, Ведмедь, Вы писали:
H>>Улови основную мысль: человек бравирующий тем, что не знает устройства того на чем пишет/чем пользуется не способен написать качественного продукта. Учитывая тот факт, что .Net'а на десктопах что-то не видно, живет он в корпоративном секторе, где и трудятся сии умельцы крапающие свои пердульки. G>Это еще требует доказаельства. G>Кстати .NET на десктопах очень даже видно, но .NET позволяет делать не только десктопные прилодения, но и Web. А Web зачастую удобнее в использовании и проще в реализации.
Академический интерес: что именно видно на десктопах, может я упустил что?
Я лично видел три вещи: Paint.NET (посмотрел только из за того, что его постоянно приводят в пример в подобных СВ), гуй от драйверов для видеокарт ATI, nLite.
Из этих трёх программ мне полезна была только последняя. И таки да, для того, чтобы ей воспользоваться, пришлось разориться на 20 Мб траффика (.NET FW).
H>>Расширять функционал можно и без таких затрат. Мне для отрисовки гуя игровая видюха не нужна. G>А кому нужна?
В WPF по рассказам наличествуют 3D-свистелки сомнительной нужности, не для них ли? Не наезда ради, хочу узнать.
Здравствуйте, gandjustas, Вы писали:
H>>Вот и чудно что не обязывает. Какой вариант будет использован средним разработчик чаще всего? Посыл ясен? G>Средний разработчик на Java и .NET будет использовать конфиги.
Ну вот и пришли к тому, с чего начали. Мои поздравления.
G>А на делфи — не будет. В делфи для этого средств маловато.
Я не знаю о каких ты средствах... Давно уже храню конфиги в XML и проблем не имею
G>.NET и Java ты не знаешь.
Заметь, я этого никогда не утверждал. В отличии от "знатоков", якобы знающих Delphi
Здравствуйте, hattab, Вы писали:
G>>А на делфи — не будет. В делфи для этого средств маловато.
H>Я не знаю о каких ты средствах... Давно уже храню конфиги в XML и проблем не имею
У тебя, у бедняги, конфиги небось каждый день куда-то "пропадают". Вот и наболело...
Здравствуйте, gandjustas, Вы писали:
В>>>А у меня вопрос, а что-нибудь кроме паскаля за плечами есть? Или не читал, но осуждаю?
H>>До паскаля много чего было, после него только Ada в ознакомительном режиме. Под .Net собирался, но не собрался. Я удовлетворил твой интерес к моей скромной персоне? G>Сейчас 2008 год, когда ты начал заниматься паскалем был 1995, в то время в России мало чего было. Сейчас это уже все устарело.
Какое мне дело до того, что устарело со времен 1995 года? Я на ObjectPascal (ну еще на асме, изредка и со справочником) пишу, и доволен жизнь.
В>>>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?
H>>Со временем... С каким? Сутки? Двое? В нативе оно конечно не освободится, но у натива и посыл другой: взял -- верни. Глубина проблемы ясна? G>Никто не мешает писать в стиле взял — верни в управляемых средах (на самом деле так писать даже лучше). С одной поправкой: в управляемых средах память не является таким ресурсом.
Конечно не мешает, но кто так пишет?
G>Где тут глубина проблемы?
Глубина проблемы в том, что сперва ты расслабился, а потом тебе говорят расслабляться нельзя. Человеческий фактор. В нативе никогда расслабляться нельзя, и это вырабатывает четкое поведение: create -- free, new-dispose.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>Я показал запрос интерфейса. Но ты ранее сказал, что мое решение основанное на интерфейсах это следствие кривизны Delphi. Я от тебя видимо уже не дождусь примера на запрос объекта, ибо ты сказал, что и на объектах можно все реализовать. Причем, отдавать объекты посредством свойств нельзя, ибо противоречит условиям задачи (сущность не может знать чего от нее могут попросить).
Твое решение с ПОДСЧЕТОМ ССЫЛОК вызвано кривизной делфи. Потому что в делфи все интерфейсы — COM интерфейсы.
Интерфейсы, как средство абстракции, тут вообще не при чем.
H>...
H>HttpProxy := client As IHttpProxy;
H>SocksProxy := client As ISocksProxy;
H>HttpHeaders := client As IHttpHeaders;
H>
H>Как по твоему, в случае приведения типа к объекту, client должен являться наследником и THttpProxy и TSocksProxy и THttpHeaders? Теперь понятно о чем речь?
Т.е. Вы хотите агрегировать внутри THttpClient (если client является членом этого класса) классы THttpProxy, TSocksProxy и THttpHeaders?
interface IHttpProxy {...}
...
interface ISocksProxy {...}
...
interface IHttpHeaders {...}
...
//Это классы с готовой реализациейclass THttpProxy: IHttpProxy {...}
...
class TSocksProxy: ISocksProxy {...}
...
class THttpHeaders: IHttpHeaders {...}
/*
Теперь мы хотим в классе THttpClient унаследовать реализацию THttpProxy, TSocksProxy и THttpHeaders. Т.к. в C# множественного наследования нет, применяем агрегирование. При этом мы можем поступить несколькими способами
*/class THttpClient
{
private IHttpProxy httpProxy;
private ISocksProxy socksProxy;
private IHttpHeaders httpHeaders
}
/*
Способ 1 - Не скрываем агрегирование. Утверждаем, что THttpClient - это не прокси и не заголовки, а именно клиент, просто он оперирует проксями и заголовками. Запрещаем "as", зато даем доступ к членам:
*/class THttpClient
{
...
public IHttpProxy HttpProxy { get {return httpProxy;} }
public ISocksProxy SocksProxy { get {return socksProxy;} }
public IHttpHeaders HttpHeaders { get {return httpProxy;} }
}
//Т.е. вместо
client as IHttpProxy
//пишем
client.HttpProxy
/*
Способ 2 - Утверждаем, что THttpClient - это прокси и заголовки в одном флаконе. Реализуем все 3 интерфейса
*/class THttpClient : IHttpProxy, ISocksProxy, IHttpHeader
{
/*
Далее в реализациях методов интерфейса обращаемся к соответствующим методам агрегированных членов
*/
}
//Здесь можно писать уже так, как Вы предлагали
client as IHttpProxy
/*
Теоретически можно было бы еще похимичить с операторами приведения типов, однако в C# они слишком сильно урезаны - решение получается кривое
*/
Здравствуйте, Сергей, Вы писали:
С>Академический интерес: что именно видно на десктопах, может я упустил что? С>Я лично видел три вещи: Paint.NET (посмотрел только из за того, что его постоянно приводят в пример в подобных СВ), гуй от драйверов для видеокарт ATI, nLite. С>Из этих трёх программ мне полезна была только последняя. И таки да, для того, чтобы ей воспользоваться, пришлось разориться на 20 Мб траффика (.NET FW).
А в гугле поискать? Я за несколько минут нашел несколько десятков шарованых/бесплатных программ.
С>В WPF по рассказам наличествуют 3D-свистелки сомнительной нужности, не для них ли? Не наезда ради, хочу узнать.
А кто-то заставляет использовать 3D в WPF?
H>Я показал запрос интерфейса. Но ты ранее сказал, что мое решение основанное на интерфейсах это следствие кривизны Delphi. Я от тебя видимо уже не дождусь примера на запрос объекта, ибо ты сказал, что и на объектах можно все реализовать. Причем, отдавать объекты посредством свойств нельзя, ибо противоречит условиям задачи (сущность не может знать чего от нее могут попросить).
Ты утомил своим невежеством. RTFM про Factory Method pattern.
Здравствуйте, hattab, Вы писали:
H>Глубина проблемы в том, что сперва ты расслабился, а потом тебе говорят расслабляться нельзя. Человеческий фактор. В нативе никогда расслабляться нельзя, и это вырабатывает четкое поведение: create -- free, new-dispose.
Здравствуйте, hattab, Вы писали:
H>Какое мне дело до того, что устарело со времен 1995 года? Я на ObjectPascal (ну еще на асме, изредка и со справочником) пишу, и доволен жизнь.
Маладец.
В>>>>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится? H>>>Со временем... С каким? Сутки? Двое? В нативе оно конечно не освободится, но у натива и посыл другой: взял -- верни. Глубина проблемы ясна? G>>Никто не мешает писать в стиле взял — верни в управляемых средах (на самом деле так писать даже лучше). С одной поправкой: в управляемых средах память не является таким ресурсом. H>Конечно не мешает, но кто так пишет?
Я так пишу, все кто со мной работает — так пишет. Примеры из MSDN и книг этому очень способствуют.
На самом деле большенство так пишет.
G>>Где тут глубина проблемы? H>Глубина проблемы в том, что сперва ты расслабился, а потом тебе говорят расслабляться нельзя. Человеческий фактор. В нативе никогда расслабляться нельзя, и это вырабатывает четкое поведение: create -- free, new-dispose.
Ну не говорил бы того, чего не знаешь.
На C# using написать совсем несложно. Он тебе Dispose и вызовет. Даже если где-то не напишешь — ничего критичного не произойдет в 99% случаев.
Здравствуйте, hattab, Вы писали:
H>Я не знаю о каких ты средствах... Давно уже храню конфиги в XML и проблем не имею
Ты же начал разговор что они пропадают. У тебя часто пропадают конфиги?
Здравствуйте, gandjustas, Вы писали:
H>>Улови основную мысль: человек бравирующий тем, что не знает устройства того на чем пишет/чем пользуется не способен написать качественного продукта. Учитывая тот факт, что .Net'а на десктопах что-то не видно, живет он в корпоративном секторе, где и трудятся сии умельцы крапающие свои пердульки. G>Это еще требует доказаельства.
Вот как ты заговорил...
G>Кстати .NET на десктопах очень даже видно, но .NET позволяет делать не только десктопные прилодения, но и Web. А Web зачастую удобнее в использовании и проще в реализации.
Это еще требует доказательства Marketing-bullshit.
H>>Расширять функционал можно и без таких затрат. Мне для отрисовки гуя игровая видюха не нужна. G>А кому нужна?
WPF на средних/офисных компах тормозит (на моей буке, даже не WPF GUI WindowsLiveWriter тормозной). Погугли на предмет: WPF тормоза.
Здравствуйте, gandjustas, Вы писали:
H>>Я показал запрос интерфейса. Но ты ранее сказал, что мое решение основанное на интерфейсах это следствие кривизны Delphi. Я от тебя видимо уже не дождусь примера на запрос объекта, ибо ты сказал, что и на объектах можно все реализовать. Причем, отдавать объекты посредством свойств нельзя, ибо противоречит условиям задачи (сущность не может знать чего от нее могут попросить).
G>Твое решение с ПОДСЧЕТОМ ССЫЛОК вызвано кривизной делфи. Потому что в делфи все интерфейсы — COM интерфейсы. G>Интерфейсы, как средство абстракции, тут вообще не при чем.
Ты и так уже доказал, что Delphi ты не знаешь. Не упорствуй.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, hattab, Вы писали: H>>
H>>...
H>>HttpProxy := client As IHttpProxy;
H>>SocksProxy := client As ISocksProxy;
H>>HttpHeaders := client As IHttpHeaders;
H>>
H>>Как по твоему, в случае приведения типа к объекту, client должен являться наследником и THttpProxy и TSocksProxy и THttpHeaders? Теперь понятно о чем речь?
MC>Т.е. Вы хотите агрегировать внутри THttpClient (если client является членом этого класса) классы THttpProxy, TSocksProxy и THttpHeaders? MC>
MC>interface IHttpProxy {...}
MC>...
MC>interface ISocksProxy {...}
MC>...
MC>interface IHttpHeaders {...}
MC>...
MC>//Это классы с готовой реализацией
MC>class THttpProxy: IHttpProxy {...}
MC>...
MC>class TSocksProxy: ISocksProxy {...}
MC>...
MC>class THttpHeaders: IHttpHeaders {...}
MC>/*
MC>Теперь мы хотим в классе THttpClient унаследовать реализацию THttpProxy, TSocksProxy и THttpHeaders. Т.к. в C# множественного наследования нет, применяем агрегирование. При этом мы можем поступить несколькими способами
MC>*/
MC>class THttpClient
MC>{
MC> private IHttpProxy httpProxy;
MC> private ISocksProxy socksProxy;
MC> private IHttpHeaders httpHeaders
MC>}
MC>/*
MC>Способ 1 - Не скрываем агрегирование. Утверждаем, что THttpClient - это не прокси и не заголовки, а именно клиент, просто он оперирует проксями и заголовками. Запрещаем "as", зато даем доступ к членам:
MC>*/
MC>class THttpClient
MC>{
MC> ...
MC> public IHttpProxy HttpProxy { get {return httpProxy;} }
MC> public ISocksProxy SocksProxy { get {return socksProxy;} }
MC> public IHttpHeaders HttpHeaders { get {return httpProxy;} }
MC>}
MC>//Т.е. вместо
MC>client as IHttpProxy
MC>//пишем
MC>client.HttpProxy
MC>/*
MC>Способ 2 - Утверждаем, что THttpClient - это прокси и заголовки в одном флаконе. Реализуем все 3 интерфейса
MC>*/
MC>class THttpClient : IHttpProxy, ISocksProxy, IHttpHeader
MC>{
MC> /*
MC> Далее в реализациях методов интерфейса обращаемся к соответствующим методам агрегированных членов
MC> */
MC>}
MC>//Здесь можно писать уже так, как Вы предлагали
MC>client as IHttpProxy
MC>/*
MC>Теоретически можно было бы еще похимичить с операторами приведения типов, однако в C# они слишком сильно урезаны - решение получается кривое
MC>*/
MC>
Ты зря старался С интерфейсами и так все ясно. Я просил запрос классов.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Сергей, Вы писали:
С>>Видимо, с пониманием смысла твоих сообщений туго не только у "дельфятников", поскольку к ним я не отношусь. kuj>Ну-ну.
Ну вот, опять я тебя не понял. Что здесь означает этот оборот речи?
С>>Ты бы поменьше использовал подобные обороты речи и побольше бы писал бы о том, что имеешь ввиду — глядишь, и понимать лучше начнут.
kuj>Я всегда пишу "о том, что имею в виду".
Не сомневаюсь. Тем не менее, если бы ты меньше использовал те самые "обороты речи", было бы много лучше.
Здравствуйте, hattab, Вы писали:
G>>Кстати .NET на десктопах очень даже видно, но .NET позволяет делать не только десктопные прилодения, но и Web. А Web зачастую удобнее в использовании и проще в реализации.
H>Это еще требует доказательства
Все уже давным-давно доказано.
H>Marketing-bullshit.
Нет, это пример банального невежества. Другого, впрочем, от тебя ожидать не приходится.
Здравствуйте, gandjustas, Вы писали:
H>>Я не знаю о каких ты средствах... Давно уже храню конфиги в XML и проблем не имею G>Ты же начал разговор что они пропадают. У тебя часто пропадают конфиги?
Всяко бывало. Но приложение от этого не имирает и не хиреет.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>Кстати .NET на десктопах очень даже видно, но .NET позволяет делать не только десктопные прилодения, но и Web. А Web зачастую удобнее в использовании и проще в реализации. H>Это еще требует доказательства Marketing-bullshit.
Это уже доказано.
H>>>Расширять функционал можно и без таких затрат. Мне для отрисовки гуя игровая видюха не нужна. G>>А кому нужна? H>WPF на средних/офисных компах тормозит (на моей буке, даже не WPF GUI WindowsLiveWriter тормозной). Погугли на предмет: WPF тормоза.
Обобщать не надо. Обычные формы, кнопки, списки и пр. достаточно быстро работают.
Мощная 3D графика может тормозить, но она вообще может тормозить независимо от платформы реализации.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Я показал запрос интерфейса. Но ты ранее сказал, что мое решение основанное на интерфейсах это следствие кривизны Delphi. Я от тебя видимо уже не дождусь примера на запрос объекта, ибо ты сказал, что и на объектах можно все реализовать. Причем, отдавать объекты посредством свойств нельзя, ибо противоречит условиям задачи (сущность не может знать чего от нее могут попросить).
G>>Твое решение с ПОДСЧЕТОМ ССЫЛОК вызвано кривизной делфи. Потому что в делфи все интерфейсы — COM интерфейсы. G>>Интерфейсы, как средство абстракции, тут вообще не при чем.
H>Ты и так уже доказал, что Delphi ты не знаешь. Не упорствуй.
Может ссылочку кинешь?
Здравствуйте, gandjustas, Вы писали:
G>Твое решение с ПОДСЧЕТОМ ССЫЛОК вызвано кривизной делфи.
Вот цитата твоих слов (62 страница):
H>У меня не набор классов. У меня набор интерфейсов.
Перестань повторять эту тупость порожденную кривостью делфи. В любом случае это будут какие-то объекты.
О ссылках тут речи не идет вообще. Ты загнался, парень.
Здравствуйте, gandjustas, Вы писали:
H>>>>Расширять функционал можно и без таких затрат. Мне для отрисовки гуя игровая видюха не нужна. G>>>А кому нужна? H>>WPF на средних/офисных компах тормозит (на моей буке, даже не WPF GUI WindowsLiveWriter тормозной). Погугли на предмет: WPF тормоза. G>Обобщать не надо. Обычные формы, кнопки, списки и пр. достаточно быстро работают.
Да оно (2D) вообще тормозить права не имеет...
G>Мощная 3D графика может тормозить, но она вообще может тормозить независимо от платформы реализации.
Судя по форумам на RSDN, может тормозить и не сильно мощная 2D (ссылок не дам, пару месяцев назад читал. Там, кстати, человек сравнивал именно быстродействие отрисовки в Delphi (уж не помню, чем он рисовал, может OGL) с отрисовкой WPF). А еще в WPF есть коряга со сглаживанием и смазанными шрифтами.
Здравствуйте, hattab, Вы писали:
G>>Мощная 3D графика может тормозить, но она вообще может тормозить независимо от платформы реализации.
H>Судя по форумам на RSDN, может тормозить и не сильно мощная 2D (ссылок не дам, пару месяцев назад читал. Там, кстати, человек сравнивал именно быстродействие отрисовки в Delphi (уж не помню, чем он рисовал, может OGL) с отрисовкой WPF). А еще в WPF есть коряга со сглаживанием и смазанными шрифтами.
Здравствуйте, hattab, Вы писали:
G>>Твое решение с ПОДСЧЕТОМ ССЫЛОК вызвано кривизной делфи.
H>Вот цитата твоих слов (62 страница): H>
H>>У меня не набор классов. У меня набор интерфейсов.
H>Перестань повторять эту тупость порожденную кривостью делфи. В любом случае это будут какие-то объекты.
H>О ссылках тут речи не идет вообще. Ты загнался, парень.
Ну-ну, ты уже сам не помнишь какую чушь писал тут? Когда из тебя несколько человек пытались клещами вытянуть что у тебя за задача такая, что тебе нужен ручной подсчет ссылок?
Здравствуйте, wraithik, Вы писали:
kuj>>Здравствуйте, wraithik, Вы писали:
W>>>А что С++ гоняет через стек значения всех полей объекта? Не знал.
kuj>>В C++: по указателю, по ссылке и по значению. В последнем случае применяется конструктор копирования.
W>Ну значит в последенм случае все таки по указателю. Сделай function TMyClass.Copy(): TMyClass и все.
Нет, по значению. В стэке конструируется новый объект.
W>Напомните, чем по ссылке от по указателю отличается.
Семантикой. Ссылка используется как обычная переменная и значение ссылки задается только при инициализации — в дальнейшем поменять ссылку нельзя.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Я не знаю о каких ты средствах... Давно уже храню конфиги в XML и проблем не имею G>>Ты же начал разговор что они пропадают. У тебя часто пропадают конфиги?
H>Всяко бывало. Но приложение от этого не имирает и не хиреет.
Спорить в разрезе Дельфи-ДотНет и приводить в качестве аргумента какие-то пропадающие конфиги — это либо — в споре все средства хороши, либо проблемы с неадекватным восприятием реальности.
Здравствуйте, hattab, Вы писали:
___>>"никто не застрахован от неудачных решений и выбора". И это вероятно случилось после того, как исходники IB были выложены Богланд, видать сами рихтуют косяки.
H>А судьи кто?
Попробую объяснить на аналогии. Вот есть, к примеру, автомобиль ВАЗ и есть аналогичный ему Toyota Corolla. Так вот, один из них ведро с гайками, однозначно. Ответь на вопрос: а судьи кто?
Здравствуйте, _d_m_, Вы писали:
___>Спорить в разрезе Дельфи-ДотНет и приводить в качестве аргумента какие-то пропадающие конфиги — это либо — в споре все средства хороши, либо проблемы с неадекватным восприятием реальности.
А слишком длинная лексема ":=" в качестве аргумента — это какой диагноз?
Здравствуйте, kuj, Вы писали:
kuj>>Понял теперь. Разный интервал между буквами. Да, забавный глюк (или таки фича?). На досуге попробую разобраться из-за чего это происходит.
kuj>Уточню только: все компоненты стандартные? Кнопка на скрине это System.Windows.Forms.Button?
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, _d_m_, Вы писали:
___>>Спорить в разрезе Дельфи-ДотНет и приводить в качестве аргумента какие-то пропадающие конфиги — это либо — в споре все средства хороши, либо проблемы с неадекватным восприятием реальности.
С>А слишком длинная лексема ":=" в качестве аргумента — это какой диагноз?
Ну чтож поработаю доктором, если уж ты спросил. Такой же.
Здравствуйте, Mamut, Вы писали:
M>ЗЫ. Ядро Линукса — это достаточно корпоративно? А вполне себе на процедурном языке написано...
Дык и ядро я ему приводил, и гном (вот специально скачал сурсы AbiWord, чтобы убедиться, что там голый C) — все бестолку. С этим человеком спор абсолютно непродуктивен и никакого смысла не несет
Здравствуйте, gandjustas, Вы писали:
G>Низкий порог вхождения еще не означает легкость в использовании.
Низкий порог вхождения означает то, что и должен — привлекательность для непрограммиста. Я сам видел, как на строительном факультете в одном вузе (ныне уже имени Ельцина) продавали книжки по дельфи, более того — их покупали! Не надо думать, что непрограммист начнет писать "корпоративные системы среднего уровня" (c), но где-то на работе может и блеснуть и попробовать что-то автоматизировать. Тут, кстати, он моментально оценить возможности работы с Variant'ом в дельфи потому что это будет самый простой для него способ сделать интеграцию с офисными приложениями. Я таких примеров просто достаточно видел.
DOO>>Тот факт, что он им являлся лет дак дцать мы во внимание принимать, конечно, не будем. G>Может и является, но "непрограммисты" очень часто рожают просто ужасный код, с кучей утечек и багов. Все успешные проекты на делфи написаны профессионалами.
Кто бы спорил. Но из-за того, что платформа активно используется непрограммистами не говорит, что это плохая платформа. Точно так же нет смысла мерить мощь платформы ее дуракоустойчивостью. В свое время дельфи давал то, чего та же VS дать не могла — реально хороший IDE (в VS 6 без асиста IDE просто ужасный, а 2003-я тогда тормозила на моем домашнем компе, на котором я позже легко играл в 3-й варкрафт) + простоту разработки гуевых приложений.
Здравствуйте, koandrew, Вы писали:
K>Цифр у меня нет и не будет, ибо нет дельфей. Но в отличие от некоторых у меня есть логика, которая подсказывает мне, что инлайнинг коротких функций даст прирост производительности, особенно если эти короткие ф-ции вызываются часто...
Кстати спор у вас ни о чем. Директива inline в C только рекомендует компилятору делать inline, реально он сам и так все поймет. Дак вот — в дельфи не было этой рекомендательной директивы, но был inline — просто целиком управляемый компилятором.
Я, конечно, понимаю, что SAP это не корпоративная система средних размеров — это корпоративная система крупных размеров, но все же — беглое исследование информации по ABAP показало, что ООП там нет (и не будет, потому что от ABAP'а SAP уходит к Java). Так что сидели мужики лет дак дцать — внедряли активно SAP по всему миру, где процентов 90 кода писано на этом ABAP'е и не знали они, что фигней страдают — без ООП тут и ловить нечего...
Здравствуйте, Mamut, Вы писали:
M>>>Корпоративная система — это очень большое и расплывчатое понятие. То есть ты предлагаешь написать сферовакуумного коня, а когда тебе скажут "ну... это сложно", то ты наверняка ответишь "ага, я же говорил!"
kuj>>Ты действительно так глуп или только делаешь вид? Хорошо, специально для тебя уточню — Microsoft Dynamics NAV.
M>Уже совсем другой компот. Теперь осталось решить, сложнее ли оно, чем ядро Линукса
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, Mamut, Вы писали:
M>>>>Корпоративная система — это очень большое и расплывчатое понятие. То есть ты предлагаешь написать сферовакуумного коня, а когда тебе скажут "ну... это сложно", то ты наверняка ответишь "ага, я же говорил!"
kuj>>>Ты действительно так глуп или только делаешь вид? Хорошо, специально для тебя уточню — Microsoft Dynamics NAV.
M>>Уже совсем другой компот. Теперь осталось решить, сложнее ли оно, чем ядро Линукса
DOO>Ну и чем самолет заодно
И ещё нужно наконец выяснить, взлетит ли этот самолёт с того самого транспортёра или нет
Здравствуйте, hattab, Вы писали:
M>>При этом второй класс магическим образом становится COM-объектом как только в него добавляются функции с соответствующими сигнатурами? H>Ни какой магии. Описал по требованиям COM, он стал COM-совместимым.
И какие требования COM ?
Здравствуйте, DOOM, Вы писали:
M>>>Заодно объясни, что ты имеешь в виду, говоря "корпоративная система средних размеров" kuj>>http://en.wikipedia.org/wiki/Enterprise_software
DOO>Я, конечно, понимаю, что SAP это не корпоративная система средних размеров — это корпоративная система крупных размеров, но все же — беглое исследование информации по ABAP показало, что ООП там нет (и не будет, потому что от ABAP'а SAP уходит к Java). Так что сидели мужики лет дак дцать — внедряли активно SAP по всему миру, где процентов 90 кода писано на этом ABAP'е и не знали они, что фигней страдают — без ООП тут и ловить нечего...
"Object orientation in ABAP is an extension of the ABAP language that makes available the advantages of object-oriented programming, such as encapsulation, interfaces, and inheritance. This helps to simplify applications and make them more controllable.
ABAP Objects is fully compatible with the existing language, so you can use existing statements and modularization units in programs that use ABAP Objects, and can also use ABAP Objects in existing ABAP programs. Note, however, that syntax checking is stronger in ABAP Objects programs, and some syntactical forms (usually older ones) of certain statements are not permitted."
Здравствуйте, Sinclair, Вы писали:
kuj>>Часом нет. Речь шла о Windows, а не о Web. S>Хм. Ну скопируй HTML из первого примера себе на диск C:\ — будет под Windows.
Мда, такой ахинеи я от тебя не ожидал.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>Низкий порог вхождения еще не означает легкость в использовании. DOO>Низкий порог вхождения означает то, что и должен — привлекательность для непрограммиста. Я сам видел, как на строительном факультете в одном вузе (ныне уже имени Ельцина) продавали книжки по дельфи, более того — их покупали! Не надо думать, что непрограммист начнет писать "корпоративные системы среднего уровня" (c), но где-то на работе может и блеснуть и попробовать что-то автоматизировать. Тут, кстати, он моментально оценить возможности работы с Variant'ом в дельфи потому что это будет самый простой для него способ сделать интеграцию с офисными приложениями. Я таких примеров просто достаточно видел.
Для этих целей как раз нужен VB. В нем отлично делается интеграция с офисными приложениями и багов меньше. Популярность делфи для таких задач вызвана повсеместным преподаванием паскаля в школе и универе.
Например у нас в универе 1,5 года читали курс по паскалю, и еще полгода обучали формоклепанию на делфи. Нормального курса по C++ не было, только спецкурсами у отдельных групп. Книжки по делфи продавали в книжном ларьке на факультете и эти книжки покупали.
Вообще то, о чем ты говоришь, к разработке имеет мало отношения. Это сродни писанию скриптов в *nix, то есть задача в основном админа\эникейщика.
Здравствуйте, Sinclair, Вы писали:
kuj>>Мда, такой ахинеи я от тебя не ожидал. S>Ты разверни тезис. Что тебя не устраивает?
Почему меня что-то должно не устраивать? Я просто сказал, что удивился, когда увидел какую чушь ты написал двумя постами выше.
Здравствуйте, kuj, Вы писали: kuj>Почему меня что-то должно не устраивать? Я просто сказал, что удивился, когда увидел какую чушь ты написал двумя постами выше.
Я имею в виду — разверни тезис про чушь. Или у тебя не получилось сохранить сэмпл SIMILE на диск?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Mamut, Вы писали:
kuj>>>Ты действительно так глуп или только делаешь вид? Хорошо, специально для тебя уточню — Microsoft Dynamics NAV.
M>>Уже совсем другой компот. Теперь осталось решить, сложнее ли оно, чем ядро Линукса
kuj>Ну давай выкладывай критерии сложности.
Это вопрос не ко мне, а к тебе. Это ты не захотел сравнивать ядро линукса с "корпоративной системой среднего размера". В МС Nav я вижу кучу формочек с примитивнейшем редактором отчетов (это на основе демо).
@task, с клиентской частью, выполненной на Яваскрипте (!) выглядит намного интереснее.
Здравствуйте, Sinclair, Вы писали:
kuj>>Почему меня что-то должно не устраивать? Я просто сказал, что удивился, когда увидел какую чушь ты написал двумя постами выше. S>Я имею в виду — разверни тезис про чушь. Или у тебя не получилось сохранить сэмпл SIMILE на диск?
Чушь это то, что ты написал, что сохранив HTML на диск, мы получим Windows-приложение. Давай запустим vmware, под ним mac os и скажем, что Mac OS — Windows-приложение?
Здравствуйте, kuj, Вы писали: kuj>Чушь это то, что ты написал, что сохранив HTML на диск, мы получим Windows-приложение.
Ок, и что же мы получим, сохранив HTML на диск?
Я вот увижу rich gui application на JS. В который ты как-то слабо веришь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
kuj>>Чушь это то, что ты написал, что сохранив HTML на диск, мы получим Windows-приложение. S>Ок, и что же мы получим, сохранив HTML на диск? S>Я вот увижу rich gui application на JS. В который ты как-то слабо веришь.
А я вижу веб браузер, рендерящий DHTML. Короче, Синклер иногда лучше жевать, чем говорить. Ага.
M>>Тот факт, то второй интерфейс не совместим с типами COM означает обычно только то, что у программиста руки кривые.
H> Учи матчасть.
Какую? Азы наследования? Так \это не мне их нао изучать
M>>При этом второй класс магическим образом становится COM-объектом как только в него добавляются функции с соответствующими сигнатурами?
H>Ни какой магии. Описал по требованиям COM, он стал COM-совместимым.
Знаешь, что ты здесь написал? По-твоему, класс становится наследником другого класса/интерфейса только потому, что он реализует какие-то методы???
Почитай про наследование, пожалуйста. И оъясни мне, чем отличаются следующие две строчки
class MyClass : TObject
// MyClass теперь является TObject
class MyClass : IInterface
// MyClass теперь является IInterface
Более того, поразмышляй над тем, почему у ICOMInterface, INonCOMInterface и ICOMInterface2 автоматом вдруг появились целых три COM-метода
M>>Это, извините, бред H>Интерфейсы в Delphi так сложны для понимания?
Азы ООП так сложны для понимания? Также можно почитать The Delphi Object Model, раздел про интерфейсы и особенное внимание уделить строчкам:
The compiler generates calls to _AddRef and _Release to manage the lifetime of interfaced objects.
Delphi calls QueryInterface as part of its implementation of the as operator for interfaces. You can use the as operator to cast an interface to any other interface type. Delphi calls QueryInterface to obtain the new interface reference. If QueryInterface returns an error, the as operator raises a runtime error.
Здравствуйте, kuj, Вы писали: kuj>А я вижу веб браузер, рендерящий DHTML. Короче, Синклер иногда лучше жевать, чем говорить. Ага.
Ага. Гляжу в книгу — вижу фигу.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Mamut, Вы писали:
M>>Ничего мегасложного в MS Nav я не увидел
kuj>Не видит тот, кто не знает куда смотреть.
ты ведь умный? подскажи куда смотреть? заодно и тут ответь
? S>>Я вот увижу rich gui application на JS. В который ты как-то слабо веришь.
kuj>А я вижу веб браузер, рендерящий DHTML. Короче, Синклер иногда лучше жевать, чем говорить. Ага.
В>>Мне очень нравиться "пердульки бухгалтерские". Откуда такое пренебрежение к основным деженжым вещам? Ведь большиство действительно серьезных программ пишется для бизнеса являются "бухлагтерскими пердульками" И там качество специалиста определяет разницу в сотни тысячи долларов. Мне аж даже интересно стало, что вы считаете достойным делом программиста, если убрать "пердульки бухглатерские".
H>Улови основную мысль: человек бравирующий тем, что не знает устройства того на чем пишет/чем пользуется не способен написать качественного продукта. Учитывая тот факт, что .Net'а на десктопах что-то не видно, живет он в корпоративном секторе, где и трудятся сии умельцы крапающие свои пердульки.
Как эта фраза связана с тем что я спрашивал? Получается в огороде бузина в а в Киеве дядька. В общем я спрашивал что считается достойным делом программиста, если убрать "пердульки бухгалтерские", то есть фактически весь корпоративный сектор?
А учитывая что .NET на дектопах прекрасно видно начиная с WinXP SP2, то фраза вообще странная,с учетом того, что мы разговариваем не про .NET, а про дельфи. Так какая область разработки ПО лучше подходит для "настоящих" программистов и где делфи показывает себя во всей красе?
H>>>Ты теряешь не только нить...
В>>Я тоже потерял нить, наверное кто то плохо свои мысли формулирует? Я, например их не понимаю, наверное не дозрел еще.
Не надо распыляться, надо ее изложить в одном месте, а то я прочем все посты, но нит потерял все равно.
H>>>Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем.
В>>Если требуется расширение функциональности, то за это надо платить, в том числе и сменой парка бухгалтерских машин. Вопрос окупится или нет, если новый функционал позволит выполнять те же оперции меньшим количеством операторов?
H>Расширять функционал можно и без таких затрат. Мне для отрисовки гуя игровая видюха не нужна.
Нельзя бесконечно расширять функциональность без этих затрат. Увеличивается обьем обрабатываемых данных, увеличивается сложоность обработки этих данных, изменяются требования к отображению информации и уже не возможно остаться на уровне железа 95-го года, ка бы не хотелось. А если функциональность не расширять, то проиграешь конкурентам.
G>>>>ЗЫ Можем вспонить web. какие у делфи возможности создания web-приложений? Правильно — никаких!!!! Это удар ниже пояса.
H>>>Хотя Delphi и не среда для веб-разработчика, но имеется WebSnap, Intraweb, WebServices. Ты некомпетентен.
В>>Ты не компетентен, спрашивается про WEB разработкe, а не слова где встречается WEB.
H>И этот вопрос я уже озвучивал ранее. Поищи. Мне не улыбается по десять раз повторять одно и то же.
Еще раз повторяю я просмотрел тред, прежде чем писать. И так как ваши ответы подобны лемовским сепульком ( когда требуется ответ посылается куда то еще, мол я уже отвечал, там иджет очередная ссылка куда та и так далее ), то и хотелось получить ответ, вы действительно не понимаете что есть WEB разработка и что не всякая технология в который есть WEB таковой является?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ведмедь, Вы писали:
H>>>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно)
В>>Конечно не на стороне .NET, цена владениа у Delphi окажется выше.
H>Бла-бла-бла. Наслушался уже. Завязывай.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ведмедь, Вы писали:
H>>>В смысле не обязывают? А эти конфиги упоминаемые тут для настройки ремотинга? Для пользователей любящих кофе давно есть клавы-"непромокайки" , и даже буки такие есть (видимо производитель счел, таки, недостатком )
В>>Ээээ ты просто не в курсе, действительно не обязывают. Как хранить и использовать это секцальное дело программиста, может использовать конфиги стандартные, может свой велосипед изобрести, может для каждого компа в коде все прошить.
H>Вот и чудно что не обязывает. Какой вариант будет использован средним разработчик чаще всего? Посыл ясен?
Тот который удобней ему или тот который ему навяжет архитектор системы.
Ты знаешь у нас КТС системы более 50-ти серверов, на каждом сервере более десятка источников конфигурации. И проблемы с конфигураций возникают только при глобальной смене функциональности... Ну не трогают адмимны то что работает, отучены совать свои ручки.
При чем сначала каждый ихобретал свою систему конфигурации, потом все пришло к той идеологии, что МС предлагала... Ведь работает.
А какой подход использует дельфи к конфигурации? Реестр? Писать в коде? Есть ли у дельфи идеология конфигурирования? Аналоги application block от МС?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ведмедь, Вы писали:
В>>Здравствуйте, hattab, Вы писали: H>>>>>>>SOAP-сервис Delphi чем-то хуже SOAP-сервиса на .Net/Java? G>>>>>>Хуже. В WCF можно параметры сервиса (протоколы и пр.) поменять в конфиге, не трогая код. H>>>>>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы G>>>>Когда я аботал на делфях клиент умудрился поудалять ini файлы с настройками. G>>>>От пользователя-дурака никто не застрахован.
H>>>Конечно никто. Но если у тебя софтина перестала от этого работать...
В>>То надо трахать техподдержку. Разработчик тут не причем. Или ты вообще конфигами не пользуешься? Что для под каждый комп свою версию компилируешь?
H>.Net — разработчик, как я уже понял, всегда ни при чем: за него все решили, за него все написали, ему показали дорогу в светлое будущее
Ага... а если кто то в дельфи удалит испольняемый файлы все будет работать нормально? Или покорежит конфиги? Или адреса для удаленным обращениям прошиваются в коде? Или виноват будет разработчик? Конфиги так же являются частью системы и за конфигураций отвечает тех поддержка.... И только в случае полных непоняток тех поддержка начнет дергать разработка...Или по твоему разработчик должен по первому крику заказчика мчаться на площадку и там быстро все переписывать?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ведмедь, Вы писали:
H>>>>>Да тебе бесполезно что-либо цитировать. Я тебя уже тыкал носом в твоиже слова, которые мне объяснить не смог (напоминаю, о минусах сборки мусора на управляемых kuj>>>>типах в Delphi). Ссылку на описание фризов нашел, не поленился, от тебя снова тишина. Оно мне надо так напрягаться Проще с тобой завязать и только. Будь здоров.
kuj>>>>Ну-ну. Научись читать сначала и в теме разберись хоть немного.
H>>>Я с Паскалем 13 лет. Спасибо.
В>>А у меня вопрос, а что-нибудь кроме паскаля за плечами есть? Или не читал, но осуждаю?
H>До паскаля много чего было, после него только Ada в ознакомительном режиме. Под .Net собирался, но не собрался. Я удовлетворил твой интерес к моей скромной персоне?
И ты в резюме бы так же написал "много чего до паскаля, после него Ада в ознакомительном режиме"?
Оссобенно инетересно какими языками ты зарабатывал на жизнь программированием? Или "много чего " было в школе, а потом только delphi?
H>>>Я тебе говорил про потерю ресурсов на dbconnection. Ты мне сказал, что FxCop тебе все покажет. Ы?
В>>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?
H>Со временем... С каким? Сутки? Двое? В нативе оно конечно не освободится, но у натива и посыл другой: взял -- верни. Глубина проблемы ясна?
Время запуска GC конечно не детерминировано? Очень не понятно что значит в нейтиве не освободиться? После того как пройдет сборка мусора освободятся все занятые ресурсы. А у нейтива посыл другой все что взял, то и верни... меньше вернул — лики и потери ресурсов, больше вернул — аксесвиолейщн. Управляемый код защищает от второго, уменьшает первую проблему.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Sinclair, Вы писали:
C>>>- все примеры, SDK и тому подобные вещи идут с примерами на СИ и Шарпе. Задолбался я переводить это все на паскаль. C>>>- begin, end C>>>- var S>>Возрадуйся, ибо в новом шарпе таки есть var
kuj>var в новом шарпе и в делфи несколько различаются, не находишь?
Здравствуйте, Ведмедь и hattab, Вы писали:
H>>Я тебе говорил про потерю ресурсов на dbconnection. Ты мне сказал, что FxCop тебе все покажет. Ы?
В>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?
В .NET ресурсы, для которых важна детерминированность времени освобождения (файлы, соединения) оборачиваются в объекты, реализующие интерфейс IDisposable (это даже можно считать паттерном). По команде Dispose() объект сразу освобождает ресурс, после чего переходит в состояние Disposed ("я ресурсом уже не владею") и спокойно себе дожидается, пока его соберет GC и освободит все оставшиеся ресурсы (память, в частности). В С# (за VB не скажу) есть даже специальная конструкция:
using(IDisposable obj = GetSomeDisposable()) //Тут не обязательно непосредственно IDisposable, подойдет что угодно, от него унаследованное
{
//Do something
}
//Что эквивалентно
{
IDisposable obj = GetSomeDisposable();
//Do something
obj.Dispose();
}
Здравствуйте, kuj, Вы писали:
I>>разговор начался с тебе в Delphi — зажать shift, нажать 6, отжать shift, нажать = — отсюда — Re[7]: Чем вам всем не угодил Delphi?
kuj>Только добавь сюда еще и постоянную необходимость следить за текущей выбранной раскладкой. kuj>Очень чудно.
Следить все равно придется. Например в румынской раскладке чтобы вставить символ = , нужно удержать Shift и жать на 0. Так что работаю только с английской раскладкой.
Что такого трудного с вводом знака := , не понимаю ажиотажа.
Здравствуйте, AnalogXP, Вы писали:
I>>>разговор начался с тебе в Delphi — зажать shift, нажать 6, отжать shift, нажать = — отсюда — Re[7]: Чем вам всем не угодил Delphi?
kuj>>Только добавь сюда еще и постоянную необходимость следить за текущей выбранной раскладкой. kuj>>Очень чудно.
AXP>Следить все равно придется. Например в румынской раскладке чтобы вставить символ = , нужно удержать Shift и жать на 0.
Всем не угодишь. Но даже так все равно меньше телодвижений.
AXP>Что такого трудного с вводом знака := , не понимаю ажиотажа.
Ничего трудного. Просто 5 нажатий менее удобно, чем одно нажатие.
Здравствуйте, Mr.Cat, Вы писали:
H>>>Я тебе говорил про потерю ресурсов на dbconnection. Ты мне сказал, что FxCop тебе все покажет. Ы?
В>>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?
MC>В .NET ресурсы, для которых важна детерминированность времени освобождения (файлы, соединения) оборачиваются в объекты, реализующие интерфейс IDisposable (это даже можно считать паттерном). По команде Dispose() объект сразу освобождает ресурс, после чего переходит в состояние Disposed ("я ресурсом уже не владею") и спокойно себе дожидается, пока его соберет GC и освободит все оставшиеся ресурсы (память, в частности). В С# (за VB не скажу) есть даже специальная конструкция: MC>
MC>using(IDisposable obj = GetSomeDisposable()) //Тут не обязательно непосредственно IDisposable, подойдет что угодно, от него унаследованное
MC>{
MC> //Do something
MC>}
MC>//Что эквивалентно
MC>{
MC> IDisposable obj = GetSomeDisposable();
MC> //Do something
MC> obj.Dispose();
MC>}
MC>
H>>>>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно)
В>>>Конечно не на стороне .NET, цена владениа у Delphi окажется выше.
H>>Бла-бла-бла. Наслушался уже. Завязывай.
В>Прекрасный аргумент! браво!
"Я привык вести тут неконструктивные споры" (c) hattab
Здравствуйте, Mamut, Вы писали:
S>>>Я вот увижу rich gui application на JS. В который ты как-то слабо веришь.
kuj>>А я вижу веб браузер, рендерящий DHTML. Короче, Синклер иногда лучше жевать, чем говорить. Ага.
M>Тогда расскажи, что для тебя rich gui application
S>>>>Я вот увижу rich gui application на JS. В который ты как-то слабо веришь.
kuj>>>А я вижу веб браузер, рендерящий DHTML. Короче, Синклер иногда лучше жевать, чем говорить. Ага.
M>>Тогда расскажи, что для тебя rich gui application
kuj>wmvare на котором запущен mac os, ясен пень.
kuj>Смешные вы ей богу.
система средств для взаимодействия пользователя с компьютером, основанная на представлении всех доступных пользователю системных объектов и функций в виде графических компонентов экрана (окон, значков, меню, кнопок, списков и т. п.). При этом, в отличие от интерфейса командной строки, пользователь имеет произвольный доступ (с помощью клавиатуры или устройства координатного ввода типа "мышь") ко всем видимым экранным объектам.
Теперь осталось понять, что тебе не понравилось в примере Синклера
Здравствуйте, _d_m_, Вы писали:
H>>>>Я не знаю о каких ты средствах... Давно уже храню конфиги в XML и проблем не имею G>>>Ты же начал разговор что они пропадают. У тебя часто пропадают конфиги?
H>>Всяко бывало. Но приложение от этого не имирает и не хиреет.
___>Спорить в разрезе Дельфи-ДотНет и приводить в качестве аргумента какие-то пропадающие конфиги — это либо — в споре все средства хороши, либо проблемы с неадекватным восприятием реальности.
Никто в таком разрезе не спорит. Я уже пояснял, кажется. Ну а конфиги... Ну ведь есть прблема, чего ее отрицать-то?
Здравствуйте, _d_m_, Вы писали:
___>>>"никто не застрахован от неудачных решений и выбора". И это вероятно случилось после того, как исходники IB были выложены Богланд, видать сами рихтуют косяки.
H>>А судьи кто?
___>Попробую объяснить на аналогии. Вот есть, к примеру, автомобиль ВАЗ и есть аналогичный ему Toyota Corolla. Так вот, один из них ведро с гайками, однозначно. Ответь на вопрос: а судьи кто?
Аналогии не катят. Ибо ты не пробовал проектировать Абрамс и ИС немецкой ЖД.
Здравствуйте, gandjustas, Вы писали:
M>>>При этом второй класс магическим образом становится COM-объектом как только в него добавляются функции с соответствующими сигнатурами? H>>Ни какой магии. Описал по требованиям COM, он стал COM-совместимым. G>И какие требования COM ?
Есть перечень типов, которые совместимы с маршалингом. Есть соглашение о вызовах.
Здравствуйте, hattab, Вы писали:
H>Никто в таком разрезе не спорит. Я уже пояснял, кажется. Ну а конфиги... Ну ведь есть прблема, чего ее отрицать-то?
Какая проблема?
У программы на Java\.NET конфиги пропадают чаще, чем у программы на делфи?
Здравствуйте, Mamut, Вы писали:
M>>>Тот факт, то второй интерфейс не совместим с типами COM означает обычно только то, что у программиста руки кривые.
H>> Учи матчасть.
M>Какую? Азы наследования? Так \это не мне их нао изучать
Наследование тут ни при чем. IUnknown и INonCOMInterface это разные интерфейсы. Еще раз говорю, учи матчасть.
Здравствуйте, Ведмедь, Вы писали:
H>>Улови основную мысль: человек бравирующий тем, что не знает устройства того на чем пишет/чем пользуется не способен написать качественного продукта. Учитывая тот факт, что .Net'а на десктопах что-то не видно, живет он в корпоративном секторе, где и трудятся сии умельцы крапающие свои пердульки.
В>Как эта фраза связана с тем что я спрашивал? Получается в огороде бузина в а в Киеве дядька. В общем я спрашивал что считается достойным делом программиста, если убрать "пердульки бухгалтерские", то есть фактически весь корпоративный сектор?
Ты так и не понял. Я четко обрисовал проблему: неграмотный человек не способен сделать ничего кроме пердулек. Человек разбирающийся в предмете, безусловно, может сделать качественный продукт (в том же корпоративном секторе).
В>А учитывая что .NET на дектопах прекрасно видно начиная с WinXP SP2, то фраза вообще странная,с учетом того, что мы разговариваем не про .NET, а про дельфи. Так какая область разработки ПО лучше подходит для "настоящих" программистов и где делфи показывает себя во всей красе?
.Net на десктопе, это Paint.NET наверное . Native Rich Desktop Application это и есть основной сегмент для Delphi.
H>>>>Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем.
В>>>Если требуется расширение функциональности, то за это надо платить, в том числе и сменой парка бухгалтерских машин. Вопрос окупится или нет, если новый функционал позволит выполнять те же оперции меньшим количеством операторов?
H>>Расширять функционал можно и без таких затрат. Мне для отрисовки гуя игровая видюха не нужна.
В>Нельзя бесконечно расширять функциональность без этих затрат. Увеличивается обьем обрабатываемых данных, увеличивается сложоность обработки этих данных, изменяются требования к отображению информации и уже не возможно остаться на уровне железа 95-го года, ка бы не хотелось. А если функциональность не расширять, то проиграешь конкурентам.
Бесконечно нельзя. Но пропустить несколько итераций это очень не маленькая экономия. Теперь об отображении информации. Чето изменилось с 95 года в бухгалтерии для отображения информации? Никак таблицы в 3D теперь правят? Ирония понятна, или нужно разжевать?
G>>>>>ЗЫ Можем вспонить web. какие у делфи возможности создания web-приложений? Правильно — никаких!!!! Это удар ниже пояса.
H>>>>Хотя Delphi и не среда для веб-разработчика, но имеется WebSnap, Intraweb, WebServices. Ты некомпетентен.
В>>>Ты не компетентен, спрашивается про WEB разработкe, а не слова где встречается WEB.
H>>И этот вопрос я уже озвучивал ранее. Поищи. Мне не улыбается по десять раз повторять одно и то же.
В>Еще раз повторяю я просмотрел тред, прежде чем писать. И так как ваши ответы подобны лемовским сепульком ( когда требуется ответ посылается куда то еще, мол я уже отвечал, там иджет очередная ссылка куда та и так далее ), то и хотелось получить ответ, вы действительно не понимаете что есть WEB разработка и что не всякая технология в который есть WEB таковой является?
А что такое Web-разработка? Можешь, впрочем, не отвечать, ибо люди даже о термине Web 2.0 договориться не могут, а уж мы тут (с куда более общим понятием) точно взаимопонимания не найдем.
Здравствуйте, Ведмедь, Вы писали:
H>>>>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно)
В>>>Конечно не на стороне .NET, цена владениа у Delphi окажется выше.
H>>Бла-бла-бла. Наслушался уже. Завязывай.
В>Прекрасный аргумент! браво!
Я тоже самое сказал о твоем аргументе. Ты разницу видишь? Я нет.
Здравствуйте, Ведмедь, Вы писали:
В>>>Ээээ ты просто не в курсе, действительно не обязывают. Как хранить и использовать это секцальное дело программиста, может использовать конфиги стандартные, может свой велосипед изобрести, может для каждого компа в коде все прошить.
H>>Вот и чудно что не обязывает. Какой вариант будет использован средним разработчик чаще всего? Посыл ясен?
В>Тот который удобней ему или тот который ему навяжет архитектор системы. В>Ты знаешь у нас КТС системы более 50-ти серверов, на каждом сервере более десятка источников конфигурации. И проблемы с конфигураций возникают только при глобальной смене функциональности... Ну не трогают адмимны то что работает, отучены совать свои ручки.
Ты знаешь, у Януса есть конфиг, который пользователся нужно править руками. И? Это что-то показало в целом? Не показало. Можно сделать хорошо, а можно по указателю проследовать и получить геморой. Теперь ясно?
В>А какой подход использует дельфи к конфигурации? Реестр? Писать в коде? Есть ли у дельфи идеология конфигурирования? Аналоги application block от МС?
Какой больше нравится тот и используй. Хочешь реестр, используй реестр. Нравятся ini'шки — бога ради. Нужен XML, тоже не вопрос... Я тут, вообще говоря, проблемы совсем ни какой не вижу.
Здравствуйте, Ведмедь, Вы писали:
В>>>То надо трахать техподдержку. Разработчик тут не причем. Или ты вообще конфигами не пользуешься? Что для под каждый комп свою версию компилируешь?
H>>.Net — разработчик, как я уже понял, всегда ни при чем: за него все решили, за него все написали, ему показали дорогу в светлое будущее
В>Ага... а если кто то в дельфи удалит испольняемый файлы все будет работать нормально? Или покорежит конфиги? Или адреса для удаленным обращениям прошиваются в коде? Или виноват будет разработчик? Конфиги так же являются частью системы и за конфигураций отвечает тех поддержка.... И только в случае полных непоняток тех поддержка начнет дергать разработка...Или по твоему разработчик должен по первому крику заказчика мчаться на площадку и там быстро все переписывать?
Знаешь, как бывает в жизни... У начальника отдела кадров, вдруг (практикант удалил шаблоны документов), перестали открываться анкетки сотрудников. Начальник ОК не звонит в тех.поддержку, не звонит разработчику, а звонит начальнику ИТ для высказывания своего фи в неличеприятной форме. Вопрос: кого после этого вы#бут (будь уверен, не практиканта)?
Здравствуйте, Ведмедь, Вы писали:
В>>>А у меня вопрос, а что-нибудь кроме паскаля за плечами есть? Или не читал, но осуждаю?
H>>До паскаля много чего было, после него только Ada в ознакомительном режиме. Под .Net собирался, но не собрался. Я удовлетворил твой интерес к моей скромной персоне?
В>И ты в резюме бы так же написал "много чего до паскаля, после него Ада в ознакомительном режиме"? В>Оссобенно инетересно какими языками ты зарабатывал на жизнь программированием? Или "много чего " было в школе, а потом только delphi?
Я к тебу на работу не нанимаюсь
В>>>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?
H>>Со временем... С каким? Сутки? Двое? В нативе оно конечно не освободится, но у натива и посыл другой: взял -- верни. Глубина проблемы ясна?
В>Время запуска GC конечно не детерминировано? Очень не понятно что значит в нейтиве не освободиться? После того как пройдет сборка мусора освободятся все занятые ресурсы. А у нейтива посыл другой все что взял, то и верни... меньше вернул — лики и потери ресурсов, больше вернул — аксесвиолейщн. Управляемый код защищает от второго, уменьшает первую проблему.
Здравствуйте, Mr.Cat, Вы писали:
MC>В .NET ресурсы, для которых важна детерминированность времени освобождения (файлы, соединения) оборачиваются в объекты, реализующие интерфейс IDisposable (это даже можно считать паттерном). По команде Dispose() объект сразу освобождает ресурс, после чего переходит в состояние Disposed ("я ресурсом уже не владею") и спокойно себе дожидается, пока его соберет GC и освободит все оставшиеся ресурсы (память, в частности). В С# (за VB не скажу) есть даже специальная конструкция:
Все верно Я говорил о другом. Cначала тебе говорят: Расслабься, ничего убирать не нужно, все само уберется. А потом говорят: Ну нифига ты расслабился, а ресурсы, кто за тобой убирать будет? Я только об этом
Здравствуйте, gandjustas, Вы писали:
H>>Никто в таком разрезе не спорит. Я уже пояснял, кажется. Ну а конфиги... Ну ведь есть прблема, чего ее отрицать-то? G>Какая проблема? G>У программы на Java\.NET конфиги пропадают чаще, чем у программы на делфи?
Уже описал десять раз и вижу, что ты не понимаешь. Либо перечитывай до просветления, либо давай завязывать, ибо ничего нового я тебе не напишу.
Здравствуйте, hattab, Вы писали:
В>>Тот который удобней ему или тот который ему навяжет архитектор системы. В>>Ты знаешь у нас КТС системы более 50-ти серверов, на каждом сервере более десятка источников конфигурации. И проблемы с конфигураций возникают только при глобальной смене функциональности... Ну не трогают адмимны то что работает, отучены совать свои ручки.
H>Ты знаешь, у Януса есть конфиг, который пользователся нужно править руками. И? Это что-то показало в целом? Не показало. Можно сделать хорошо, а можно по указателю проследовать и получить геморой. Теперь ясно?
То есть ты все .NET программы равняешь под одну гребенко по кривому янусу? Помню Delphi программу, которая при запуске падала с Access Violation! Вывод — Delphi отстой! программы на Delphi работать не будут.
Здравствуйте, hattab, Вы писали:
MC>>В .NET ресурсы, для которых важна детерминированность времени освобождения (файлы, соединения) оборачиваются в объекты, реализующие интерфейс IDisposable (это даже можно считать паттерном). По команде Dispose() объект сразу освобождает ресурс, после чего переходит в состояние Disposed ("я ресурсом уже не владею") и спокойно себе дожидается, пока его соберет GC и освободит все оставшиеся ресурсы (память, в частности). В С# (за VB не скажу) есть даже специальная конструкция:
H>Все верно Я говорил о другом. Cначала тебе говорят: Расслабься, ничего убирать не нужно, все само уберется. А потом говорят: Ну нифига ты расслабился, а ресурсы, кто за тобой убирать будет? Я только об этом
Если ты не понимаешь разницы между памятью и другими ресурсами системы, то это лишь квалифицирует тебя как непрофессионала.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ведмедь, Вы писали:
H>.Net на десктопе, это Paint.NET наверное . Native Rich Desktop Application это и есть основной сегмент для Delphi.
А примеры можно?
H>А что такое Web-разработка? Можешь, впрочем, не отвечать, ибо люди даже о термине Web 2.0 договориться не могут, а уж мы тут (с куда более общим понятием) точно взаимопонимания не найдем.
Договориться не могут, потому что Web 2.0 — маркетинговый термин, а не технический. http://en.wikipedia.org/wiki/World_Wide_Web — начинай определяться
Здравствуйте, hattab, Вы писали:
M>>Какую? Азы наследования? Так \это не мне их нао изучать
H>Наследование тут ни при чем. IUnknown и INonCOMInterface это разные интерфейсы. Еще раз говорю, учи матчасть.
IUnknown != INonCOMInterface, но INonCOMInterface == IUnknown, так как является непосредственным наследником.
INonCOMInterface можно скастить к IUnknown. Учи матчасть, нуб.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ведмедь, Вы писали:
H>Знаешь, как бывает в жизни... У начальника отдела кадров, вдруг (практикант удалил шаблоны документов), перестали открываться анкетки сотрудников. Начальник ОК не звонит в тех.поддержку, не звонит разработчику, а звонит начальнику ИТ для высказывания своего фи в неличеприятной форме. Вопрос: кого после этого вы#бут (будь уверен, не практиканта)?
Тебя наверное. Сколько работал — таким всегда техподдержка занималась.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Mamut, Вы писали:
M>>Теперь осталось понять, что тебе не понравилось в примере Синклера
kuj>Мне все понравилось кроме того, что его пример не имеет никакого отношения к теме спора.
M>>>>Тот факт, то второй интерфейс не совместим с типами COM означает обычно только то, что у программиста руки кривые.
H>>> Учи матчасть.
M>>Какую? Азы наследования? Так \это не мне их нао изучать
H>Наследование тут ни при чем. IUnknown и INonCOMInterface это разные интерфейсы. Еще раз говорю, учи матчасть.
Может, все же почитаешь про наследование, а?
INonCOMInterface наследуется от IUnknown. Более того (или, вернее, поэтому), INonCOMInterface может быть приведено к IUnknown. Более того, наследование от IUnknown означает, что для INonCOMInterface автоматически становятся доступны три базовых COM-метода: AddRef, Release и QueryInterface (потому что они реализованы в IUnknown)
Здравствуйте, Mamut, Вы писали:
M>>>Теперь осталось понять, что тебе не понравилось в примере Синклера
kuj>>Мне все понравилось кроме того, что его пример не имеет никакого отношения к теме спора.
M>К какой из них?
Здравствуйте, hattab, Вы писали: H>Все верно Я говорил о другом. Cначала тебе говорят: Расслабься, ничего убирать не нужно, все само уберется. А потом говорят: Ну нифига ты расслабился, а ресурсы, кто за тобой убирать будет? Я только об этом
Не совсем так. Если программисту не важно, когда будет закрыт(о) файл/соединение — он ничего не делает (при этом файлы и соединения будут закрываться в процессе финализации). Если ему это Важно — у него есть IDisposable. Вот и всё. Единственный источник возможных проблем — файл/соединение должно грамотно реализовывать этот IDisposable. Т.е. программист в этом вопросе не застрахован от чужих (ну или своих, если он сам разрабатывает disposable-объект) кривых рук. Впрочем, в MSDN есть пример корректной реализации.
Здравствуйте, hattab, Вы писали:
___>>Спорить в разрезе Дельфи-ДотНет и приводить в качестве аргумента какие-то пропадающие конфиги — это либо — в споре все средства хороши, либо проблемы с неадекватным восприятием реальности.
H>Никто в таком разрезе не спорит. Я уже пояснял, кажется. Ну а конфиги... Ну ведь есть прблема, чего ее отрицать-то?
Какая проблема? Что отрицать? Что у кого-то там пропали конфиги по вине юзеров и что это проблема ДотНет, а мол дельфины и без конфигов работают — ну это ахинея.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, _d_m_, Вы писали:
___>>>>"никто не застрахован от неудачных решений и выбора". И это вероятно случилось после того, как исходники IB были выложены Богланд, видать сами рихтуют косяки.
H>>>А судьи кто?
___>>Попробую объяснить на аналогии. Вот есть, к примеру, автомобиль ВАЗ и есть аналогичный ему Toyota Corolla. Так вот, один из них ведро с гайками, однозначно. Ответь на вопрос: а судьи кто?
H>Аналогии не катят. Ибо ты не пробовал проектировать Абрамс и ИС немецкой ЖД.
Жаль, что для тебя не катят. Но я проектировал многое другое, и знаком с другими проектами и эти проекты мне приходилось/приходится обслуживать. Плюс, есть опыт эксплуатации этих продуктов многими другими людьми. А теперь подумай про автомобили — аналогии катят.
skip G>А зачем знать? достаточно чтобы объект был сериализуемым (имел соответсвующий атрибут).
А смысл просто передачи объекта класса в метод, если его десериализовать в методе не получиться? G>В COM нельзя любой класс передать в метод.
Что в *.idl, по-моему там, опишешь, то и передашь
kuj>>>Мне все понравилось кроме того, что его пример не имеет никакого отношения к теме спора.
M>>К какой из них?
kuj>К той, о которой ты не имеешь представления.
Ню-ню. Про ГУИ, судя по всему, ты тоже не имеешь представления
Здравствуйте, Bigger, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
B>skip G>>А зачем знать? достаточно чтобы объект был сериализуемым (имел соответсвующий атрибут). B>А смысл просто передачи объекта класса в метод, если его десериализовать в методе не получиться?
Если вериализовать получилось, то и десереализовать получится.
G>>В COM нельзя любой класс передать в метод. B>Что в *.idl, по-моему там, опишешь, то и передашь
IDL далеко не все описывает.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Bigger, Вы писали:
B>>Здравствуйте, gandjustas, Вы писали:
B>>skip G>>>А зачем знать? достаточно чтобы объект был сериализуемым (имел соответсвующий атрибут). B>>А смысл просто передачи объекта класса в метод, если его десериализовать в методе не получиться? G>Если вериализовать получилось, то и десереализовать получится.
Ага, только тот, кто десериализует, должен знать к чему это приводить, хотя можно к Object, только толку ноль
G>>>В COM нельзя любой класс передать в метод. B>>Что в *.idl, по-моему там, опишешь, то и передашь G>IDL далеко не все описывает.
Дык и говорю, что описал, то и передал
H>>Delphi не обязывает программиста иметь конфигурационные файлы, от которых будет зависеть работоспособность приложения. Вот и вся разница.
B>А ДотНет, что обязывает или не судьба грамотно обрабатывать ситуацию их отсутствия
Судя по постам hattab`а Delphi, кроме всего прочего, не обязывает пользователя иметь мозги в голове.
Здравствуйте, gandjustas, Вы писали:
B>>skip G>>>А зачем знать? достаточно чтобы объект был сериализуемым (имел соответсвующий атрибут). B>>А смысл просто передачи объекта класса в метод, если его десериализовать в методе не получиться? G>Если вериализовать получилось, то и десереализовать получится.
Не факт — если твой ник hattab и ты пишешь xml-rpc на Delphi
Здравствуйте, Mamut, Вы писали:
kuj>>>>Мне все понравилось кроме того, что его пример не имеет никакого отношения к теме спора.
M>>>К какой из них?
kuj>>К той, о которой ты не имеешь представления.
M>Ню-ню. Про ГУИ, судя по всему, ты тоже не имеешь представления
Объясняю специально для Мамута:
HTML сохраненный на диск не является Windows-приложением.
Windows-приложением является браузер, который рендерит этот HTML.
Точно так же wmvare — Windows приложение, которое "рендерит" Mac OS — не Windows-приложение.
Дошло или надо еще десять постов этой ахинеи от тебя выслушать?
Здравствуйте, kuj, Вы писали:
kuj>Дошло или надо еще десять постов этой ахинеи от тебя выслушать?
Сценарий Javascript не является Windows приложением.
Windows приложением является его исполнительная система.
Примерами исполнительных систем для Javascript являются Windows Scripting Host и Internet Explorer.
Таким образом, Sinclair привел пример программы на Javascript, использующей исполнительную систему Internet Explorer. В твою постановку вопроса "программа на javascript с богатым гуем" это укладывается — ты не зафиксировал конкретную исполнительную систему.
Так что в очередной раз послушай совет: думай, прежде чем не то что говорить, а оскорблять собеседника. Знаний ты продемонстрировал пока ноль, зато понту выше крыши.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, Сергей, Вы писали:
С>>Здравствуйте, _d_m_, Вы писали:
___>>>Спорить в разрезе Дельфи-ДотНет и приводить в качестве аргумента какие-то пропадающие конфиги — это либо — в споре все средства хороши, либо проблемы с неадекватным восприятием реальности.
С>>А слишком длинная лексема ":=" в качестве аргумента — это какой диагноз?
___>Ну чтож поработаю доктором, если уж ты спросил. Такой же.
Ну как сказать... а если вместо := да заставят писать assign
Вспомни фортрановские LE, GE и как то там LT, кажется.... Как по мне , то гораздо проще <=, >=, <
Здравствуйте, Ведмедь, Вы писали:
В>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?
Что значит корректо? Для коннекции в одном случае корректно с ролбэком, а в другом с коммитом
Сам перешел (по необходимости) с С++ на С# и мне не хватает нормальной, контролируемой очистки ресурсов
Здравствуйте, iyura, Вы писали:
В>>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?
I>Что значит корректо? Для коннекции в одном случае корректно с ролбэком, а в другом с коммитом
Не путаешь с транзакцией?
I>Сам перешел (по необходимости) с С++ на С# и мне не хватает нормальной, контролируемой очистки ресурсов
Здравствуйте, iyura, Вы писали:
С>>>А слишком длинная лексема ":=" в качестве аргумента — это какой диагноз?
___>>Ну чтож поработаю доктором, если уж ты спросил. Такой же.
I>Ну как сказать... а если вместо := да заставят писать assign
Ну так не заставляют же.
I>Вспомни фортрановские LE, GE и как то там LT, кажется.... Как по мне , то гораздо проще <=, >=, <
Здравствуйте, gandjustas, Вы писали:
H>>.Net на десктопе, это Paint.NET наверное . Native Rich Desktop Application это и есть основной сегмент для Delphi. G>А примеры можно?
Здравствуйте, Mamut, Вы писали:
M>>>Какую? Азы наследования? Так \это не мне их нао изучать
H>>Наследование тут ни при чем. IUnknown и INonCOMInterface это разные интерфейсы. Еще раз говорю, учи матчасть.
M>Может, все же почитаешь про наследование, а?
Я не первый день живу и прекрасно в этом разбираюсь. К слову, наследование в вопросе "COM не COM" ни при чем совершенно.
M>INonCOMInterface наследуется от IUnknown. Более того (или, вернее, поэтому), INonCOMInterface может быть приведено к IUnknown. Более того, наследование от IUnknown означает, что для INonCOMInterface автоматически становятся доступны три базовых COM-метода: AddRef, Release и QueryInterface (потому что они реализованы в IUnknown)
Интерфейс есть декларация. Интерфейс ничего не реализует. Получение IUnknown от INonCOMInterface не делает последний COM'ом. Рассматривать несколько методов INonCOMInterface в отрыве от всего интерфейса -- идеологически неверно, ибо интерфейс есть единица неделимая. Какими словами это еще объяснять
Здравствуйте, gandjustas, Вы писали:
H>>Знаешь, как бывает в жизни... У начальника отдела кадров, вдруг (практикант удалил шаблоны документов), перестали открываться анкетки сотрудников. Начальник ОК не звонит в тех.поддержку, не звонит разработчику, а звонит начальнику ИТ для высказывания своего фи в неличеприятной форме. Вопрос: кого после этого вы#бут (будь уверен, не практиканта)? G>Тебя наверное. Сколько работал — таким всегда техподдержка занималась.
Эта история ко мне вообще ни какого отнощения не имеет.
Здравствуйте, _d_m_, Вы писали:
___>>>Спорить в разрезе Дельфи-ДотНет и приводить в качестве аргумента какие-то пропадающие конфиги — это либо — в споре все средства хороши, либо проблемы с неадекватным восприятием реальности.
H>>Никто в таком разрезе не спорит. Я уже пояснял, кажется. Ну а конфиги... Ну ведь есть прблема, чего ее отрицать-то?
___>Какая проблема? Что отрицать? Что у кого-то там пропали конфиги по вине юзеров и что это проблема ДотНет, а мол дельфины и без конфигов работают — ну это ахинея.
Проблема в практике использования таких конфигов. Заметь, я уже неоднократно писал, что можно и все правильно сделать.
Здравствуйте, _d_m_, Вы писали:
___>>>>>"никто не застрахован от неудачных решений и выбора". И это вероятно случилось после того, как исходники IB были выложены Богланд, видать сами рихтуют косяки.
H>>>>А судьи кто?
___>>>Попробую объяснить на аналогии. Вот есть, к примеру, автомобиль ВАЗ и есть аналогичный ему Toyota Corolla. Так вот, один из них ведро с гайками, однозначно. Ответь на вопрос: а судьи кто?
H>>Аналогии не катят. Ибо ты не пробовал проектировать Абрамс и ИС немецкой ЖД.
___>Жаль, что для тебя не катят. Но я проектировал многое другое, и знаком с другими проектами и эти проекты мне приходилось/приходится обслуживать. Плюс, есть опыт эксплуатации этих продуктов многими другими людьми. А теперь подумай про автомобили — аналогии катят.
И я проектировал многое другое, и знаком с другими проектами, и прочее и прочее. Что мне теперь можно сказать про .Net, мол, никто не застрахован от неудачных решений? (для тех кто не понял: это шутка)
Здравствуйте, Bigger, Вы писали:
B>Здравствуйте, hattab, Вы писали:
B>skip
H>>Delphi не обязывает программиста иметь конфигурационные файлы, от которых будет зависеть работоспособность приложения. Вот и вся разница.
B>А ДотНет, что обязывает или не судьба грамотно обрабатывать ситуацию их отсутствия
Я не понял, тут, что, не принято читать уже написанное? Я уже неоднократно ответил на подобный вопрос. Еще раз: можно и грамотно.
Здравствуйте, Bigger, Вы писали:
B>skip G>>>А то что они наследуют IUnknown ничего не значит уже?
H>>Конечно не значит. Учи матчасть.
B>Я валяюсь, а ответьте коллега, что в Вашем понятии COM Object, чем таким особенным он обладает?
Не нужно повторяться в вопросах, я на это уже отвечал: помимо IUnknown, это совместимые типы и соглашения о вызовах (но с соглашениями не все однозначно, как с типами).
Здравствуйте, kuj, Вы писали:
B>>>skip G>>>>А зачем знать? достаточно чтобы объект был сериализуемым (имел соответсвующий атрибут). B>>>А смысл просто передачи объекта класса в метод, если его десериализовать в методе не получиться? G>>Если вериализовать получилось, то и десереализовать получится.
kuj>Не факт — если твой ник hattab и ты пишешь xml-rpc на Delphi
Ты не зря у меня в игноре. Сам kuj, и аргументы твои kuj'евые...
Здравствуйте, hattab, Вы писали:
B>>>>skip G>>>>>А зачем знать? достаточно чтобы объект был сериализуемым (имел соответсвующий атрибут). B>>>>А смысл просто передачи объекта класса в метод, если его десериализовать в методе не получиться? G>>>Если вериализовать получилось, то и десереализовать получится.
kuj>>Не факт — если твой ник hattab и ты пишешь xml-rpc на Delphi
H>Ты не зря у меня в игноре. Сам kuj, и аргументы твои kuj'евые...
Здравствуйте, DOOM, Вы писали:
DOO>Кстати спор у вас ни о чем. Директива inline в C только рекомендует компилятору делать inline, реально он сам и так все поймет. Дак вот — в дельфи не было этой рекомендательной директивы, но был inline — просто целиком управляемый компилятором.
Вот мне и хотелось проверить, выполняет ли он инлайнинг в принципе. Для этого я и попросил автора скомпилить тот код с высшими настройками оптимизации. Ибо я не могу придумать другого более очевидного кандидата на инлайнинг. Если у вас есть какие-то идеи на эту тему — welcome
Здравствуйте, hattab, Вы писали:
B>>Я валяюсь, а ответьте коллега, что в Вашем понятии COM Object, чем таким особенным он обладает? H>Не нужно повторяться в вопросах, я на это уже отвечал: помимо IUnknown, это совместимые типы и соглашения о вызовах (но с соглашениями не все однозначно, как с типами).
Здравствуйте, gandjustas, Вы писали:
B>>>Я валяюсь, а ответьте коллега, что в Вашем понятии COM Object, чем таким особенным он обладает? H>>Не нужно повторяться в вопросах, я на это уже отвечал: помимо IUnknown, это совместимые типы и соглашения о вызовах (но с соглашениями не все однозначно, как с типами).
G>Ссылку на источник сего откровения.
Здравствуйте, iyura, Вы писали:
С>>>А слишком длинная лексема ":=" в качестве аргумента — это какой диагноз?
___>>Ну чтож поработаю доктором, если уж ты спросил. Такой же.
I>Ну как сказать... а если вместо := да заставят писать assign
Если бы у бабушки был х.. она была бы дедушкой.
I>Вспомни фортрановские LE, GE и как то там LT, кажется.... Как по мне , то гораздо проще <=, >=, <
Здравствуйте, iyura, Вы писали: I>Что значит корректо? Для коннекции в одном случае корректно с ролбэком, а в другом с коммитом
Предполагается, что Dispose технически корректно освобождает ресурсы. Если технически корректных способов несколько (как в случае с транзакциями) — то а)Чтобы узнать, что именно выполняет Dispose, читайте документацию к конкретному классу, либо эксперементируйте б)Всегда освобождайте такой ресурс явно (т.е. в случае транзакции делайте явный commit/rollback).
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, _d_m_, Вы писали:
___>>>>Спорить в разрезе Дельфи-ДотНет и приводить в качестве аргумента какие-то пропадающие конфиги — это либо — в споре все средства хороши, либо проблемы с неадекватным восприятием реальности.
H>>>Никто в таком разрезе не спорит. Я уже пояснял, кажется. Ну а конфиги... Ну ведь есть прблема, чего ее отрицать-то?
___>>Какая проблема? Что отрицать? Что у кого-то там пропали конфиги по вине юзеров и что это проблема ДотНет, а мол дельфины и без конфигов работают — ну это ахинея.
H>Проблема в практике использования таких конфигов. Заметь, я уже неоднократно писал, что можно и все правильно сделать.
Здравствуйте, hattab, Вы писали:
H>>>Аналогии не катят. Ибо ты не пробовал проектировать Абрамс и ИС немецкой ЖД.
___>>Жаль, что для тебя не катят. Но я проектировал многое другое, и знаком с другими проектами и эти проекты мне приходилось/приходится обслуживать. Плюс, есть опыт эксплуатации этих продуктов многими другими людьми. А теперь подумай про автомобили — аналогии катят.
H> И я проектировал многое другое, и знаком с другими проектами, и прочее и прочее. Что мне теперь можно сказать про .Net, мол, никто не застрахован от неудачных решений? (для тех кто не понял: это шутка)
Сказать то все что угодно можно. Можно в принципе и против ветра ссать, если нравится так. Ведь никтож не запрещает.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, DOOM, Вы писали:
DOO>>Кстати спор у вас ни о чем. Директива inline в C только рекомендует компилятору делать inline, реально он сам и так все поймет. Дак вот — в дельфи не было этой рекомендательной директивы, но был inline — просто целиком управляемый компилятором.
K>Вот мне и хотелось проверить, выполняет ли он инлайнинг в принципе.
Выполняет. Когда-то специально копался.
K>Для этого я и попросил автора скомпилить тот код с высшими настройками оптимизации. Ибо я не могу придумать другого более очевидного кандидата на инлайнинг. Если у вас есть какие-то идеи на эту тему — welcome
Эх. Не достать мне сейчас Дельфи, чтобы продемонстрировать
Сергей пишет: > Предлагаю заменить во всех C-подобных язаках if на $, for на #, return на @. > А то ведь это дикий синтаксический оверхед!!!
О чём–то таком создатели Cyclone и думали, когда делали спецификаторы
для указателей разных мастей.
gandjustas пишет: > Здравствуйте, OCTAGRAM, Вы писали: > > OCT>gandjustas пишет: >> > Я больше всего работал в Delphi7 — большенитсво впечатлений оттуда. > OCT>Delphi7 — это 2001й год. С тем же успехом можно ругать Windows за > OCT>дырявость, а IE — за отсутствие табов. > > Версии после Delphi 7 — с поддержкой .NET. Многие новшества, принесенные > в язык — заслуга .NET
Ну эта тенденция давно уже. Раньше вот за счёт COM появлялось.
Cyberax пишет: > Здравствуйте, OCTAGRAM, Вы писали: > > OCT>C++ позволяет часть вещей сместить на стек, но не до конца. В этих > OCT>случаях будет динамическая память. IIRC в C++ нельзя конструировать > OCT>результат прямо на месте. > То есть? > > Существует in-place new и RVO (return value optimization). В следующем > Стандарте RVO станет более мощной из-за move constructors.
В Аде понятия конструктора как такового нет. Есть Initialize, но только
для тех случаев, когда без инициализации будет некорректно. Initialize
дёргают только механизмы языка. А для внешних пользователей, если нужно
создать объект "не по умолчанию", нужно вызвать функцию, которая
возвращает объект. И в любом другом модуле можно сделать другую функцию,
возвращающую объект, и создавать ею объекты (почти) на тех же правах. То
есть, для new My_Func1 (...) без разницы, где была объявлена My_Func1. А
как сделать in-place new в C++ без дописывания конструктора в класс?
Да и RVO. Вот, допустим, есть у нас Image с потомками Image_PNG,
Image_JPEG, Image_GIF, Image_ICNS, ну всё как положено. Есть функция,
возвращающая объект одного из этих классов в зависимости от типа файла
на входе. Как тут RVO поможет? Как это вообще записать в C++, не
прибегая к указателям?
Marty пишет: > 5) Программисты дельфи. это самое мрачное. был грешок, работал долгое > время на поддержке дельфевых прилад. начальнег (мегакрутой спец по > дельфи и прикладной области), как то с трепетом мне показал > единственный! юнит, который он сделал, оформив его для повторного > использования. в юните была одна функция, разбивавшая строку по табам > вроде. в коде этой функции раз пять в разных местах было сравнение с > явно прописанной константой символа таб. на мое замечание, почему бы это > значение не вынести в аргументы и получить более универсальную функцию, > этот чел сказал — хм, интересная мысль.
There are some interesting corollaries here. For instance, if you're
writing a class to display some text in red (for some reason), don't add
a bunch of methods "for the future" that allow you to draw the text in
blue or green or purple. Because that's more code than you need right
now, and "less code is better."
But, if you suddenly realize you want to draw purple text, you could
write the red code again, except put in the color purple. But, "less
code is better," so you really need to abstract out the text-drawing
code and make it take a color parameter, so you can re-use the same code.
The lesson I'm getting at is, don't try to make code general until you
actually need it in more than one place. The worst libraries in the
world are the ones people write without actually writing any code that
uses them to do actual work for actual users.
Mr.Cat пишет: > 2)Рефлекшн — полезная штука как ни крути. Кстати, думаю, во многом > благодаря оному Java и .NET неплохо чувствуют себя в сфере > веб-программирования, в отличие от неуправляемых языков.
К слову о веб, там не только reflection, там и call/cc бы ещё
> 3)Простите за тавтологию, "управляемость". Согласитесь, тоже хорошая > такая задачка — организовать песочницу для неуправляемого кода. > Собственно, там, где нужна песочница (например, в том, что сейчас модно > называть rich internet application), и рулят управлемые платформы: > flash/flex, silverlight, java. > > Собственно, к чему я веду. Управляемость в целом ведет к расширению > области применения языка/платформы — и это есть гут. То есть используя > практически одну и ту же управляемую платформу
Называть .NET код управляемым — кощунство по отношению к Лиспу.
_d_m_ пишет: > Насчет минусов — ты вообще заметил смайлик? Шутка же. Сам к оценкам > отношусь двояко — ставлю когда ну уж совсем нравится или нет.
А иногда бывает, что не могу поставить несогласие, потому что тогда я
признаю, что в посте был смысл, было, с чем не согласиться. Ставлю
смайлы на дурацкие посты вроде тех, где критикуют := > Отрицательные оценки ставлю очень редко. Оценки своих сообщений не > смотрю, т.к. во первых, в Outlook Express-е их не видно, во вторых: > ибланов много, минусов наставят будь здоров — ну что мне из-за этого > настроение портить — не дождутся. Вобщем, живу по совести — остальное > все х..ня.
+1
kuj пишет:
> kuj>Вместо Delphi пора преподавать .NET технологии. > kuj>Вместо Prolog — Erlang. > kuj>и т.д. > > С чем г-н OCTAGRAM не согласен?
Во–первых, молотом .NET являются функциональные языки, а вовсе не
Delphi/C++/и т. д. Противопоставление с C++ и др. — это маркетинговый
ход. Любой лиспер поинтересовался бы, зачем, когда есть сборка мусора,
стековая архитектура? Стек ведь нужен, чтоб с него память эффективно
выделять, простым инкрементом (декрементом на Intel) указателя. В .NET
такой источник памяти уже есть — это куча, зачем тогда стек оставили?
Неоправданная недогрузка мощностей. Но лисперов мало, в целом никто и
ухом не повёл, что стековая архитектура при сборке мусора — это смешно.
Поэтому вместо Delphi можно и нужно Ada поставить, а .NET — это разговор
отдельный.
Во–вторых, непонятно, чем Prolog не угодил. И как его может заменить Erlang?
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Любой лиспер поинтересовался бы, зачем, когда есть сборка мусора, OCT>стековая архитектура? Стек ведь нужен, чтоб с него память эффективно OCT>выделять, простым инкрементом (декрементом на Intel) указателя. В .NET OCT>такой источник памяти уже есть — это куча, зачем тогда стек оставили? OCT>Неоправданная недогрузка мощностей. Но лисперов мало, в целом никто и OCT>ухом не повёл, что стековая архитектура при сборке мусора — это смешно.
А вопросы быстродействия и эффективного рахода памяти? Писатели он ФЯ не очень об этом задумываются
Тем более на уровне машинного кода стек есть, зачем пытаться скрыть этот факт?
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Во–первых, молотом .NET являются функциональные языки, а вовсе не OCT>Delphi/C++/и т. д. Противопоставление с C++ и др. — это маркетинговый OCT>ход. Любой лиспер поинтересовался бы, зачем, когда есть сборка мусора, OCT>стековая архитектура? OCT>Стек ведь нужен, чтоб с него память эффективно выделять,
И освобождать.
OCT>простым инкрементом (декрементом на Intel) указателя. В .NET OCT>такой источник памяти уже есть — это куча, зачем тогда стек оставили? OCT>Неоправданная недогрузка мощностей. Но лисперов мало, в целом никто и OCT>ухом не повёл, что стековая архитектура при сборке мусора — это смешно.
Здравствуйте, 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% случаев моветон.
Re[7]: .NET и спагетти стек (а точнее, его отсутствие там)
Здравствуйте, OCTAGRAM, Вы писали:
>> А вопросы быстродействия и эффективного рахода памяти? OCT>А этим уже должен заниматься оптимизатор.
Так он и занимается этим. Если бы не было стека, а была только куча, то какая бы тут могла быть оптимизация?
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>>В первом случае 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
Posted via RSDN NNTP Server 2.1 beta
Re[8]: .NET и спагетти стек (а точнее, его отсутствие там)
kuj пишет: > Здравствуйте, OCTAGRAM, Вы писали: > >> > А вопросы быстродействия и эффективного рахода памяти? > OCT>А этим уже должен заниматься оптимизатор. > Так он и занимается этим. Если бы не было стека, а была только куча, то > какая бы тут могла быть оптимизация?
На уровне семантики был бы спагетти стек, расположенный на куче. А при
исполнении был бы уже двойной стек+куча или что там оптимизатор придумает.
_d_m_ пишет: > А теперь ты смотри: у нас есть сначала компилятор в байт код, у него > есть времени столько, сколько понадобиться, никакаких ограничений не > накладывается, чтобы произвести оптимизированный байт код. А потом этот > код берет жит компилер и оптимизирует под конкретные: процессор/много > процессоров/архитектуру (32/64)/ОС/объем ОЗУ. Хотя время на жит > компиляцию конечно тратиться. Ну теперь яволь?
АФАИК профайлер+JIT оптимизация работают только на словах. Пока что это
успешно не применяется.
Здравствуйте, 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% случаев моветон.
Вот и я о том же. А ведь деструктор это
— централизованное место, где происходит разрушение объекта ( не будем вдаваться в рантайм и тонкости компиляторов)
— четкие правила, когда деструктор вызывается.
Как сладствие — более четкое управление ресурсами
Re[7]: .NET и спагетти стек (а точнее, его отсутствие там)
Здравствуйте, OCTAGRAM, Вы писали:
OCT>gandjustas пишет: >> А вопросы быстродействия и эффективного рахода памяти? OCT>А этим уже должен заниматься оптимизатор.
>> Тем более на уровне машинного кода стек есть, зачем пытаться скрыть этот >> факт? OCT>А управление памятью .NET не скрывает? А ведь оно тоже есть на машинном OCT>уровне.
Ничего не путаешь?
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, iyura, Вы писали: I>>А тебеб не кажется, что для задач не класса 24х7 проблема утечки памяти вообще преувеличена?
MC>А Вы считаете, что .NET не предназначен для разработки систем 24х7?
Нет, я этого не говорил. Я считаю, что для таких систем и проектирования и кодирование и тестирование должно быть на порядок качественнее. А это уже никакого отношения с .Net/Java/Delphi/C++.... не имеет
koandrew пишет: > Цифр у меня нет и не будет, ибо нет дельфей. Но в отличие от некоторых у > меня есть логика, которая подсказывает мне, что инлайнинг коротких > функций даст прирост производительности, особенно если эти короткие > ф-ции вызываются часто...
Но не в этом случае. IntfClear вызывает другой метод, IUnknown._Release.
IUnknown._Release при этом может быть заглушкой, вызывающей настоящую
реализацию _Release. Эта реализация, в свою очередь, уменьшает счётчик
ссылок, и, если он 0, то вызывает свой финализатор. Который, в свою
очередь...
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Во–первых, молотом .NET являются функциональные языки
.NET или VB.NET/C#? Функциональные языки вполне неплохо существуют и в рамках самого .NET.
OCT>Любой лиспер поинтересовался бы, зачем, когда есть сборка мусора, стековая архитектура?
Стековая архитектура чего? Вы имеете в виду, что IL-код предназначен для исполнения некой абстрактной стековой машиной?
OCT>В .NET такой источник памяти уже есть — это куча, зачем тогда стек оставили?
Где стек оставили? Покажите пример кода, явно указывающего на присутствие этого Вашего стека. Вы про stackalloc (интересно, а им кто-нить пользуется?) что-ли?
OCT>Поэтому вместо Delphi можно и нужно Ada поставить.
Welcome
Здравствуйте, iyura, Вы писали: I>Понимаю. У нас весь сырбор разгорелся из-за того, что в управляемых средах не особенно следует обращать внимание на очистку ресурсов — придет GC и все сделает. Так я как раз о том, что не все
Непонятно, откуда взялось заблуждение, что GC должен выполнять очистку всех ресурсов. Сборка мусора реализована для единственного ресурса — памяти. За остальными по-прежнему должен следить сам программист.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, iyura, Вы писали: I>>Понимаю. У нас весь сырбор разгорелся из-за того, что в управляемых средах не особенно следует обращать внимание на очистку ресурсов — придет GC и все сделает. Так я как раз о том, что не все
MC>Непонятно, откуда взялось заблуждение, что GC должен выполнять очистку всех ресурсов. Сборка мусора реализована для единственного ресурса — памяти. За остальными по-прежнему должен следить сам программист.
Я согласен, что это заблуждение. Но оно опасно тем, что порождает иллюзии. Это из личного опыта — пришел на проект, которым раньше занимались люди слепо верящие в GC. Об IDispose, using и.п. они не заботились. И что самое хреновое — это все как-то работало
Правда никого не заботило то, что при старте приложения при одном открытом окошке с маленькис списком 70Мб памяти было откушено. Мда...сумбурно получается. Короче, программист воспитаный на неуправляемой среде пишет качественнее
Здравствуйте, kuj, Вы писали:
kuj>А учитывая, что "морды к БД" сейчас обычно в виде web-интерфейса реализуются, то и тут Delphi курит бамбук.
Это скорее твое личное ощущение. Многие морды пишутся не в web
kuj>Про O/RM типа nHibernate или Entity Framework (LINQ for SQL) в Delphi и мечтать не приходится.
А, что есть nHibernate для NET 3.x? B c LINQ и EF тщательнее. Это разные вещи (LINQ for SQL и Entity Framework).
Кроме того EF еще и не вышел
kuj>Классика — пока в лагере Делфи глупые туземцы перебирают SAX парсеры, в лагере .NET уже давно все отпарсено и жители празднуют!
И что? Пока жители NY выбирают колбасу жители CCCP едят одну доступную. Улавливаешь?
Здравствуйте, OCTAGRAM, Вы писали:
OCT>kuj пишет: >> hattab, у тебя серьезные пробелы в знании ООП. OCT>ООП и COM — это разные вещи. Скажем так, use cases у COM больше, чем OCT>нужно для ООП.
А зачем в одну кучу варианты использования, ООП и СОМ.
Первое относится варианты использования системы, т.е. это проектирование системы, на этом этапе наплевать какую парадигму программирования использовать
Второе парадигма программирования
Третье технология взаимодействия различных объектов — черных ящиков с известным интерфейсом IUnknown?
Вы что курите, хотя больше похоже на тяжелые синтетические наркотики.
kuj пишет: > hattab, ты утопил своей глупостью. > > Повторяй как мантру: > > IUnknown — COM-интерфейс > Любой интерфейс-наследник IUnknown — COM-интерфейс > Любой интерфейс-наследник COM-интерфейса — COM-интерфейс
Не согласен. Я думаю, тут hattab как раз прав. COM, как модель,
определяет подмножество. Механизмы COM могут использоваться и для
решения не–COM объектов, но сам COM — это модель. Если интерфейс не
может быть описан в рамках COM, то это не COM–интерфейс. Это интерфейс,
использующий механизмы COM. CORBA объекты в Delphi, я так понимаю, тоже
от IUnknown происходят.
Но в любом случае это переливание из пустого в порожнее. COM–объект, не
COM–объект. Вот то, что у всех интерфейсов к механизмам COM привязка
появляется — это да, это играет роль.
--
ISO/IEC 8652:1995/Amd 1:2007
Posted via RSDN NNTP Server 2.1 beta
Re[13]: что именно видно на десктопах из .NET/Java
Сергей пишет: > Академический интерес: что именно видно на десктопах, может я упустил что?
Я только MathCad видел. Всё. А, ну Janus ещё местный. Итого 2 программы,
большая и маленькая. На Java у меня только toonel.net. Всё. Но это
скорее девиации, чем общее правило.
Аду на десктопах тоже не видно, хотя программисты и библиотеки есть.
Mr.Cat пишет: > Где стек оставили? Покажите пример кода, явно указывающего на > присутствие этого Вашего стека. Вы про stackalloc (интересно, а им > кто-нить пользуется?) что-ли?
А из метода можно выйти так, чтобы его кадр остался? Чтобы потом вернуться?
Bigger пишет: > Вы что курите, хотя больше похоже на тяжелые синтетические наркотики.
перечитай ещё раз
> А зачем в одну кучу варианты использования, ООП и СОМ. > Первое относится варианты использования системы, т.е. это проектирование > системы, на этом этапе наплевать какую парадигму программирования > использовать
в роли системы реализация COM
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Bigger пишет: >> Вы что курите, хотя больше похоже на тяжелые синтетические наркотики. OCT>перечитай ещё раз
Тут сколько не читай, ничего не понятно. >> А зачем в одну кучу варианты использования, ООП и СОМ. >> Первое относится варианты использования системы, т.е. это проектирование >> системы, на этом этапе наплевать какую парадигму программирования >> использовать OCT>в роли системы реализация COM
VB6 неполноценный ООП, а ком на нем писать так что в путь
Так чтоже сказать то хотел, медленно и по русски OCT>-- OCT>ISO/IEC 8652:1995/Amd 1:2007
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Mr.Cat пишет: >> Где стек оставили? Покажите пример кода, явно указывающего на >> присутствие этого Вашего стека. Вы про stackalloc (интересно, а им >> кто-нить пользуется?) что-ли? OCT>А из метода можно выйти так, чтобы его кадр остался? Чтобы потом вернуться?
Чтобы это значило, и где это возможно??????????????????????7
OCT>-- OCT>ISO/IEC 8652:1995/Amd 1:2007
Здравствуйте, OCTAGRAM, Вы писали: OCT>А из метода можно выйти так, чтобы его кадр остался? Чтобы потом вернуться?
В несколько ограниченном виде — да, с помощью yield. Замыкания (в принципе — из той же оперы — сохранение контекста вызова) в C# тоже имеются.
А теперь объясните, при чем здесь стек.
В принципе, я понимаю, к чему Вы клоните. Однако программист не оперирует такой абстракцией как "некоторый особенный стек, не расположенный на куче". Ограничения и особенности операций передачи управления являются следствием применяемой модели областей видимости и времен жизни объектов. А то, что технически такая модель может быть реализована с помощью стека — это ни о чем не говорит. Если Вы против такой концепции — мне придется Вас расстроить — Вы в меньшинстве. То же самое наблюдается во многих других языках/платформах.
Здравствуйте, iyura, Вы писали:
kuj>>Ты расскажи это тем, у кого проект "встает" из-за трудноуловимых утечек на недели, если не месяцы. При чем это не плод моего воображения, а вполне реальный факт из моей практики... Правда, случившийся не со мной лично, а в соседнем отделе, которые занимались разработкой на Delphi (год этак 2001-2002).
I>Возможно. Но проекты встают не только из-за утечек памяти. Но еще раз повторюсь — в большинстве случаев ИМХО проблема утечки сильно преувеличена. Из своего немалого опыта работы на С++ могу сказать, что с утечками сталкивался редко, ну, а аот так, чтобы из-за утечки что-то рушилось.... не припомню.
Так в C++ ты ведь наверно используешь smart pointers? Естественно smart pointers сильно снижают вероятность утечки.
Здравствуйте, OCTAGRAM, Вы писали:
>> hattab, у тебя серьезные пробелы в знании ООП. OCT>ООП и COM — это разные вещи. Скажем так, use cases у COM больше, чем OCT>нужно для ООП.
Здравствуйте, iyura, Вы писали:
kuj>>А учитывая, что "морды к БД" сейчас обычно в виде web-интерфейса реализуются, то и тут Delphi курит бамбук.
I>Это скорее твое личное ощущение. Многие морды пишутся не в web
Большинство пишется как раз в виде Web-интерфейса.
kuj>>Про O/RM типа nHibernate или Entity Framework (LINQ for SQL) в Delphi и мечтать не приходится.
I>А, что есть nHibernate для NET 3.x?
А что мешает использовать NH сборки под .NET 3? Есть даже LINQ to nHibernate.
kuj>>Классика — пока в лагере Делфи глупые туземцы перебирают SAX парсеры, в лагере .NET уже давно все отпарсено и жители празднуют!
I>И что? Пока жители NY выбирают колбасу жители CCCP едят одну доступную. Улавливаешь?
Здравствуйте, iyura, Вы писали:
MC>>А Вы считаете, что .NET не предназначен для разработки систем 24х7?
I>Нет, я этого не говорил. Я считаю, что для таких систем и проектирования и кодирование и тестирование должно быть на порядок качественнее. А это уже никакого отношения с .Net/Java/Delphi/C++.... не имеет
Еще и как имеет. Java и .NET позволяют бОльшую часть кода покрыть юнит-тестами, и позволяют применять более высокоуровневые техники: IoC, AOP, O/RM ect
Здравствуйте, iyura, Вы писали:
kuj>>>Стандартная практика использования IDbConnection в .NET — in-place. То есть по принципу открываем, выполнеяем CRUD операцию(и), закрываем (возвращаем в пул подключений). Даже если забыть закрыть, объект подключения почти тут же станет кандидатом на сборку, так как выйдет за scope. Аналогично с файлами.
I>Мы ведь говорим о "не совсем правильном" стиле программирования.
За не совсем правильный стиль у нас бьют. Больно. Если не помогает, то выгоняют в связи с профнепригодностью.
I>Ясен пень, что если все делать аккуратно, то и проблем не будет. Но степень аккуратности зависит не от наличия управляемой среды, а от наличия мозгов. Я, собственно, об этом
Да не об аккуратности речь. Речь о человеческом факторе — свойстве допускать ошибки. Все ошибаются. А когда сроки поджимают, то может появится желание "срезать углы".
kuj>>>При чем в отличии от Delphi все проще и читабельней благодаря оператору using — отпадает необходимость явно делать try finally.
I>А вот как себя поведет
I>
I>try
I>{
I> using(obj )
I> {
I> если тут облом с obj
I> }
I>}
I>catch(...........)
I>{
I> тут хочу рассказать об обломе с obj
I>}
I>
В смысле как? using не делает catch. Соответственно "твой" catch поймает эксепшн.
kuj>>Забыл упомянуть, что для доступа к БД фактически повсеместно используются O/RM, которые сами заботятся о подключениях. Единственное, где надо помнить о using — для TransactionScope`ов.
I>Весьма спорно.
Что именно спорно? Что надо TransactionScope оборачивать в using или явно вызывать Dispose, т.к. это IDisposable объект?
Здравствуйте, iyura, Вы писали:
kuj>>Тем не менее, не следует ассоциировать закрытие коннэкшн с логикой коммит/роллбэк транзакции. Когда требуется эта логика, то следует явно управлять транзакцией.
I>Понимаю. У нас весь сырбор разгорелся из-за того, что в управляемых средах не особенно следует обращать внимание на очистку ресурсов — придет GC и все сделает. Так я как раз о том, что не все
Здравствуйте, iyura, Вы писали:
MC>>Здравствуйте, iyura, Вы писали: I>>>Понимаю. У нас весь сырбор разгорелся из-за того, что в управляемых средах не особенно следует обращать внимание на очистку ресурсов — придет GC и все сделает. Так я как раз о том, что не все
MC>>Непонятно, откуда взялось заблуждение, что GC должен выполнять очистку всех ресурсов. Сборка мусора реализована для единственного ресурса — памяти. За остальными по-прежнему должен следить сам программист.
I>Я согласен, что это заблуждение. Но оно опасно тем, что порождает иллюзии. Это из личного опыта — пришел на проект, которым раньше занимались люди слепо верящие в GC. Об IDispose, using и.п. они не заботились. И что самое хреновое — это все как-то работало
Индусы, наверное, какие-то?
I>Правда никого не заботило то, что при старте приложения при одном открытом окошке с маленькис списком 70Мб памяти было откушено. Мда...сумбурно получается. Короче, программист воспитаный на неуправляемой среде пишет качественнее
I>Вот и я о том же. А ведь деструктор это
I>- централизованное место, где происходит разрушение объекта ( не будем вдаваться в рантайм и тонкости компиляторов) I>- четкие правила, когда деструктор вызывается.
Это не относится к управляемой среде.
I>Как сладствие — более четкое управление ресурсами
Здравствуйте, gandjustas, Вы писали:
H>>Получение IUnknown от INonCOMInterface не делает последний COM'ом. G>В этом ты неправ. Уже десять раз тебе сказали.
Да мне тут много чего говорили... Всему верить чтоль
Здравствуйте, gandjustas, Вы писали:
B>>>Я валяюсь, а ответьте коллега, что в Вашем понятии COM Object, чем таким особенным он обладает? H>>Не нужно повторяться в вопросах, я на это уже отвечал: помимо IUnknown, это совместимые типы и соглашения о вызовах (но с соглашениями не все однозначно, как с типами).
G>Ссылку на источник сего откровения.
Да какую ссылку тебе нужно? Роджерсона (Inside COM) можешь почитать. Только если ты сам выводы делать не будешь, то не найдешь в книге выводов.
Здравствуйте, _d_m_, Вы писали:
___>>>>>Спорить в разрезе Дельфи-ДотНет и приводить в качестве аргумента какие-то пропадающие конфиги — это либо — в споре все средства хороши, либо проблемы с неадекватным восприятием реальности.
H>>>>Никто в таком разрезе не спорит. Я уже пояснял, кажется. Ну а конфиги... Ну ведь есть прблема, чего ее отрицать-то?
___>>>Какая проблема? Что отрицать? Что у кого-то там пропали конфиги по вине юзеров и что это проблема ДотНет, а мол дельфины и без конфигов работают — ну это ахинея.
H>>Проблема в практике использования таких конфигов. Заметь, я уже неоднократно писал, что можно и все правильно сделать.
___>А причем здесь Дельфи или ДотНет?
Рекомендуемый/пропогандируемый/самый популярный/(подставь сам) подход может быть не идеальным. Если следуя ему легко сотворить корягу -- она таки будет сотворена (вспомним нападки на Delphi за то, что малограмотные кодеры размещали всю логику в обработчиках формы. Казалось бы, причем тут Delphi?). Еще пояснения нужны?
Здравствуйте, _d_m_, Вы писали:
H>>>>Аналогии не катят. Ибо ты не пробовал проектировать Абрамс и ИС немецкой ЖД.
___>>>Жаль, что для тебя не катят. Но я проектировал многое другое, и знаком с другими проектами и эти проекты мне приходилось/приходится обслуживать. Плюс, есть опыт эксплуатации этих продуктов многими другими людьми. А теперь подумай про автомобили — аналогии катят.
H>> И я проектировал многое другое, и знаком с другими проектами, и прочее и прочее. Что мне теперь можно сказать про .Net, мол, никто не застрахован от неудачных решений? (для тех кто не понял: это шутка)
___>Сказать то все что угодно можно. Можно в принципе и против ветра ссать, если нравится так. Ведь никтож не запрещает.
Здравствуйте, DOOM, Вы писали:
DOO>>>Кстати спор у вас ни о чем. Директива inline в C только рекомендует компилятору делать inline, реально он сам и так все поймет. Дак вот — в дельфи не было этой рекомендательной директивы, но был inline — просто целиком управляемый компилятором.
K>>Вот мне и хотелось проверить, выполняет ли он инлайнинг в принципе. DOO>Выполняет. Когда-то специально копался.
Некоторые операции она таки инлайнит. Например, операция получения интерфейса от объекта может быть выполнена без обращения к методу GetInterface.
K>>Для этого я и попросил автора скомпилить тот код с высшими настройками оптимизации. Ибо я не могу придумать другого более очевидного кандидата на инлайнинг. Если у вас есть какие-то идеи на эту тему — welcome
DOO>Эх. Не достать мне сейчас Дельфи, чтобы продемонстрировать
Эти функции не будут инлайниться ни при каких настройках, ибо смысла нет.
Здравствуйте, OCTAGRAM, Вы писали:
>> OCT>gandjustas пишет: >>> > Я больше всего работал в Delphi7 — большенитсво впечатлений оттуда. >> OCT>Delphi7 — это 2001й год. С тем же успехом можно ругать Windows за >> OCT>дырявость, а IE — за отсутствие табов. >> >> Версии после Delphi 7 — с поддержкой .NET. Многие новшества, принесенные >> в язык — заслуга .NET OCT>Ну эта тенденция давно уже. Раньше вот за счёт COM появлялось.
В Delphi, не то с 2006, не то с 2005 есть class helpers появившиеся в .Net 3.5, как методы расширения (так кажется)
Здравствуйте, hattab, Вы писали:
>>> Версии после Delphi 7 — с поддержкой .NET. Многие новшества, принесенные >>> в язык — заслуга .NET OCT>>Ну эта тенденция давно уже. Раньше вот за счёт COM появлялось.
H>В Delphi, не то с 2006, не то с 2005 есть class helpers появившиеся в .Net 3.5, как методы расширения (так кажется)
Helper classes were introduced in Delphi 8 as a way of binding the VCL to the .Net framework. To quote the Delphi help: “Class helpers are a way to extend a class without using inheritance. A class helper simply introduces a wider scope for the compiler to use when resolving identifiers.”
Здравствуйте, Mamut, Вы писали:
M>>>INonCOMInterface наследуется от IUnknown. Более того (или, вернее, поэтому), INonCOMInterface может быть приведено к IUnknown. Более того, наследование от IUnknown означает, что для INonCOMInterface автоматически становятся доступны три базовых COM-метода: AddRef, Release и QueryInterface (потому что они реализованы в IUnknown)
H>>Интерфейс есть декларация. Интерфейс ничего не реализует. Получение IUnknown от INonCOMInterface не делает последний COM'ом. Рассматривать несколько методов INonCOMInterface в отрыве от всего интерфейса -- идеологически неверно, ибо интерфейс есть единица неделимая. Какими словами это еще объяснять
M>Объясни следующее:
M>1. Чем отличаются две следующие строчки: M>
M>В первом случае MyClass наследуется от TObject. Во втором? M>Если во втором — это тоже наследование, то: M>- если родитель является TObject, является ли наследник TObject? M>- если родитель является COM-объектом, является ли наследник COM-объектом?
Если объект реализует хоть один COM-интерфейс, он является COM-объектом. Помимо этого, он может реализовывать интерфейсы не являющиеся COM-совместимыми. Само по себе наследование интерфейса от COM-совместимого не делает его COM-совместимым т.к., еще раз говорю, интерфейс нельзя рассматривать по частям, это неделимая единица.
M>2. Interface Keyword
M>Ключевое слово Interface является всего лишь способом получить множественное наследование от абстрактных классов.
M>
M>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.
M>При реализации интерфейсы вы обязаны реализовать стандартные методы QueryInterface, _AddRef and _Release, если ваш класс не будет создан на основе класса, который их уже реализует (примером такого класса может служить TInterfacedObject)
Зачем ты мне эти простыни цитируешь, думаешь я не знаю об этом?
Здравствуйте, hattab, Вы писали:
H>>>Получение IUnknown от INonCOMInterface не делает последний COM'ом. G>>В этом ты неправ. Уже десять раз тебе сказали.
H>Да мне тут много чего говорили... Всему верить чтоль
M>>>В первом случае MyClass наследуется от TObject. Во втором? M>>>Если во втором — это тоже наследование, то: M>>>- если родитель является TObject, является ли наследник TObject? M>>>- если родитель является COM-объектом, является ли наследник COM-объектом?
kuj>>Все верно только следует понимать, что интерфейс может быть унаследован только интерфейсом, а класс реализует (implement) интерфейс. Но это так.. вопрос терминологии.
M>ну это да. В дельфи интерфейсами банальные абстрактные классы обозваны
Вообще-то в Delphi интерфейсы, это интерфейсы, а абстрактные классы, это абстрактные классы (терминология C++ не катит). Абстрактные классы обозначаются по другому:
TAbstarctClass = Class Abstract (TObject)
...
End;
H>Если объект реализует хоть один COM-интерфейс, он является COM-объектом. Помимо этого, он может реализовывать интерфейсы не являющиеся COM-совместимыми. Само по себе наследование интерфейса от COM-совместимого не делает его COM-совместимым т.к., еще раз говорю, интерфейс нельзя рассматривать по частям, это неделимая единица.
Интерфейс IUnknown обяхывает меня реализовать в последубщих наследуемых классах QueryInterface, _AddRef и _Release — да или нет?
H>Зачем ты мне эти простыни цитируешь, думаешь я не знаю об этом?
То есть я все равно обязан реализовать методы QueryInterface, _AddRef и _Release или отнаследоваться от TInterfacedObject? Вне зависимости от того, отнаслеуюсь я своим классом от IUnknown или от INonCOMInterface? Если да, то я получу COM-Объект, потому что наличие этих методов, емнип, яляется необходимым и достаточным условием для сохдания COM-объекта
Здравствуйте, OCTAGRAM, Вы писали:
>> У Delphi 2006 офигительно быстрый менеджер памяти.
OCT>Я помню, один раз хорошо сэкономил своей команде время на кодинг, OCT>дописав type String = String[255] в начале, без этого не проходило по OCT>времени. А время в разы отличается, как ни крути.
Здравствуйте, OCTAGRAM, Вы писали:
>> OCT>Delphi 2007? >> >> C 2005.
>> OCT>тоже 2007? в 2006 не помню такого >> >> С 2005
OCT>А это точно не .NET всё?
M>>ну это да. В дельфи интерфейсами банальные абстрактные классы обозваны
H>Вообще-то в Delphi интерфейсы, это интерфейсы, а абстрактные классы, это абстрактные классы (терминология C++ не катит). Абстрактные классы обозначаются по другому: H>
H>TAbstarctClass = Class Abstract (TObject)
H> ...
H>End;
H>
Чем интерфейс в Дельфи отличается от абстрактного класса?
Здравствуйте, kuj, Вы писали:
>>>> Версии после Delphi 7 — с поддержкой .NET. Многие новшества, принесенные >>>> в язык — заслуга .NET OCT>>>Ну эта тенденция давно уже. Раньше вот за счёт COM появлялось.
H>>В Delphi, не то с 2006, не то с 2005 есть class helpers появившиеся в .Net 3.5, как методы расширения (так кажется)
kuj>
kuj>Helper classes were introduced in Delphi 8 as a way of binding the VCL to the .Net framework. To quote the Delphi help: “Class helpers are a way to extend a class without using inheritance. A class helper simply introduces a wider scope for the compiler to use when resolving identifiers.”
Я имел ввиду нативные версии, восьмерка была чисто .Net.
Здравствуйте, Mamut, Вы писали:
H>>Если объект реализует хоть один COM-интерфейс, он является COM-объектом. Помимо этого, он может реализовывать интерфейсы не являющиеся COM-совместимыми. Само по себе наследование интерфейса от COM-совместимого не делает его COM-совместимым т.к., еще раз говорю, интерфейс нельзя рассматривать по частям, это неделимая единица.
M>Интерфейс IUnknown обяхывает меня реализовать в последубщих наследуемых классах QueryInterface, _AddRef и _Release — да или нет?
Если ты определяешь класс реализующий IUnknown и ни один из его предков не реализует IUnknown, ты будешь обязан эти методы реализовать.
H>>Зачем ты мне эти простыни цитируешь, думаешь я не знаю об этом?
M>То есть я все равно обязан реализовать методы QueryInterface, _AddRef и _Release или отнаследоваться от TInterfacedObject? Вне зависимости от того, отнаслеуюсь я своим классом от IUnknown или от INonCOMInterface? Если да, то я получу COM-Объект, потому что наличие этих методов, емнип, яляется необходимым и достаточным условием для сохдания COM-объекта
Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown.
Здравствуйте, Mamut, Вы писали:
M>>>ну это да. В дельфи интерфейсами банальные абстрактные классы обозваны
H>>Вообще-то в Delphi интерфейсы, это интерфейсы, а абстрактные классы, это абстрактные классы (терминология C++ не катит). Абстрактные классы обозначаются по другому: H>>
H>>TAbstarctClass = Class Abstract (TObject)
H>> ...
H>>End;
H>>
M>Чем интерфейс в Дельфи отличается от абстрактного класса?
Интерфейс -- чистая декларация. Абстрактный класс -- класс, объекты которого нельзя создать (хотя в 2006 есть глюк, и такие объекты создать можно). При этом, абстрактный класс, может иметь любые поля/свойства/методы (не обязательно абстрактые).
M>>То есть я все равно обязан реализовать методы QueryInterface, _AddRef и _Release или отнаследоваться от TInterfacedObject? Вне зависимости от того, отнаслеуюсь я своим классом от IUnknown или от INonCOMInterface? Если да, то я получу COM-Объект, потому что наличие этих методов, емнип, яляется необходимым и достаточным условием для сохдания COM-объекта
H>Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown.
Здравствуйте, hattab, Вы писали:
H>Я имел ввиду нативные версии, восьмерка была чисто .Net.
Различие в том, что в .NET каждый extension method указывает какой именно класс он расширяет. Таким образом методы, расширяющие разные классы, можно поместить в один класс.
public static class MyExtensions
{
public static int WordCount(this String str)
{
...
}
public static int DaysToNewYear(this DateTime date)
{
...
}
...
}
Здравствуйте, hattab, Вы писали:
H>Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown.
Нет, ты работаешь с INonCOMObject, а не с IUnknown. INonCOMObject наследует эти методы от IUnknown.
Здравствуйте, hattab, Вы писали:
H>>>Не нужно повторяться в вопросах, я на это уже отвечал: помимо IUnknown, это совместимые типы и соглашения о вызовах (но с соглашениями не все однозначно, как с типами). G>>Ссылку на источник сего откровения. H>Да какую ссылку тебе нужно? Роджерсона (Inside COM) можешь почитать. Только если ты сам выводы делать не будешь, то не найдешь в книге выводов.
Ты действительно думаешь что твои выводы правильнее того что сказал человек, который COM придумал?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mamut, Вы писали: M>>То есть я все равно обязан реализовать методы QueryInterface, _AddRef и _Release или отнаследоваться от TInterfacedObject? Вне зависимости от того, отнаслеуюсь я своим классом от IUnknown или от INonCOMInterface? Если да, то я получу COM-Объект, потому что наличие этих методов, емнип, яляется необходимым и достаточным условием для сохдания COM-объекта
H>Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown.
Изучай ООП. Наследование моделирует отношение "является", то есть если INonCOMObject наследует IUnknown, то он в каком-то смысле является IUnknown. IUnknown в свою очередь является COM интерфейсом, следовательно INonCOMObject является COM интерфейсом.
Или для тебя ООП тоже не авторитет?
Здравствуйте, Mamut, Вы писали:
M>>>То есть я все равно обязан реализовать методы QueryInterface, _AddRef и _Release или отнаследоваться от TInterfacedObject? Вне зависимости от того, отнаслеуюсь я своим классом от IUnknown или от INonCOMInterface? Если да, то я получу COM-Объект, потому что наличие этих методов, емнип, яляется необходимым и достаточным условием для сохдания COM-объекта
H>>Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown.
M>Еще раз:
M>
M>Должен ли я в MyClass реализовывать QueryInterface, _AddRef и _Release. Если нет, то почему?
Должен, ибо это декларирует IUnknown от которого ты наследовал свой интерфейс. Тут есть еще очень важный момент. Если ты продекларируешь в классе реализуцию только одного интерфейса (MyInterface), от таких объектов нельзя будет получить IUnknown. Для получения IUnknown нужно декларировать реализацию обоих интерфейсов (или иметь предком класс реализующий IUnknown).
Здравствуйте, kuj, Вы писали:
H>>Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown.
kuj>Нет, ты работаешь с INonCOMObject, а не с IUnknown. INonCOMObject наследует эти методы от IUnknown.
Зависит от реализации. Если я наследуюсь от класса реализующего IUnknown, то и работать, дергая эти методы, буду c IUnknown. Если реализую сам и не продекларирую реализацию IUnknown, работать буду с INonCOMObject.
Здравствуйте, hattab, Вы писали:
M>>Должен ли я в MyClass реализовывать QueryInterface, _AddRef и _Release. Если нет, то почему?
H>Должен, ибо это декларирует IUnknown от которого ты наследовал свой интерфейс. Тут есть еще очень важный момент. Если ты продекларируешь в классе реализуцию только одного интерфейса (MyInterface), от таких объектов нельзя будет получить IUnknown. Для получения IUnknown нужно декларировать реализацию обоих интерфейсов (или иметь предком класс реализующий IUnknown).
....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
Здравствуйте, gandjustas, Вы писали:
H>>Здравствуйте, Mamut, Вы писали: M>>>То есть я все равно обязан реализовать методы QueryInterface, _AddRef и _Release или отнаследоваться от TInterfacedObject? Вне зависимости от того, отнаслеуюсь я своим классом от IUnknown или от INonCOMInterface? Если да, то я получу COM-Объект, потому что наличие этих методов, емнип, яляется необходимым и достаточным условием для сохдания COM-объекта
H>>Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown. G>Изучай ООП. Наследование моделирует отношение "является", то есть если INonCOMObject наследует IUnknown, то он в каком-то смысле является IUnknown. IUnknown в свою очередь является COM интерфейсом, следовательно INonCOMObject является COM интерфейсом. G>Или для тебя ООП тоже не авторитет?
INonCOMObject расширяет IUnknown. Говоря о INonCONObject мы говорим не только о трех методах. INonCOMObject не может являться COM-интерфейсом если имеет декларации несовместимые с требованиями COM. Это так сложно понять?
Здравствуйте, gandjustas, Вы писали:
H>>>>Не нужно повторяться в вопросах, я на это уже отвечал: помимо IUnknown, это совместимые типы и соглашения о вызовах (но с соглашениями не все однозначно, как с типами). G>>>Ссылку на источник сего откровения. H>>Да какую ссылку тебе нужно? Роджерсона (Inside COM) можешь почитать. Только если ты сам выводы делать не будешь, то не найдешь в книге выводов. G>Ты действительно думаешь что твои выводы правильнее того что сказал человек, который COM придумал?
Здравствуйте, kuj, Вы писали:
M>>>Должен ли я в MyClass реализовывать QueryInterface, _AddRef и _Release. Если нет, то почему?
H>>Должен, ибо это декларирует IUnknown от которого ты наследовал свой интерфейс. Тут есть еще очень важный момент. Если ты продекларируешь в классе реализуцию только одного интерфейса (MyInterface), от таких объектов нельзя будет получить IUnknown. Для получения IUnknown нужно декларировать реализацию обоих интерфейсов (или иметь предком класс реализующий IUnknown).
kuj>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
kuj>>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
H>Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
Объект, реализующий AddRef, Release и QueryInterface является чем?
M>>>>ну это да. В дельфи интерфейсами банальные абстрактные классы обозваны
H>>>Вообще-то в Delphi интерфейсы, это интерфейсы, а абстрактные классы, это абстрактные классы (терминология C++ не катит). Абстрактные классы обозначаются по другому: H>>>
H>>>TAbstarctClass = Class Abstract (TObject)
H>>> ...
H>>>End;
H>>>
M>>Чем интерфейс в Дельфи отличается от абстрактного класса?
H>Интерфейс -- чистая декларация. Абстрактный класс -- класс, объекты которого нельзя создать (хотя в 2006 есть глюк, и такие объекты создать можно). При этом, абстрактный класс, может иметь любые поля/свойства/методы (не обязательно абстрактые).
В общем, разницы никакой за двумя важными исключениями:
1. Interface позволяет множественное наследование
2. В классах, наследуемых от Interface СOM-совместимые методы гвоздями прибиваются в самое начало vtable для обеспечения COM-совместимости. Таким образом, любой класс, наследуемый (в цепочке любой длины) от IUnknown будет COM-объектом, потому что у него будет как минимум три COM-совместимых метода: AddRef, Rekease и QueryInterface
Все эти извращения нужны только для одного — облегчить создание COM-объектов в Delphi
M>>Должен ли я в MyClass реализовывать QueryInterface, _AddRef и _Release. Если нет, то почему?
H>Должен, ибо это декларирует IUnknown от которого ты наследовал свой интерфейс. Тут есть еще очень важный момент. Если ты продекларируешь в классе реализуцию только одного интерфейса (MyInterface), от таких объектов нельзя будет получить IUnknown. Для получения IUnknown нужно декларировать реализацию обоих интерфейсов (или иметь предком класс реализующий IUnknown).
Mr.Cat пишет: > Здравствуйте, OCTAGRAM, Вы писали: > OCT>А из метода можно выйти так, чтобы его кадр остался? Чтобы потом > вернуться? > > В несколько ограниченном виде — да, с помощью yield. Замыкания (в > принципе — из той же оперы — сохранение контекста вызова) в C# тоже имеются. http://www.thinkingms.com/pensieve/CommentView,guid,fd10bfa8-1aeb-4353-84c8-cd80e418424f.aspx
In the CLR, when a method returns its stack frame is torn down. So
there is no way that the local variables can actually preserve state.
The solution taken by the C# team is turn the method that implements the
yield statement into a class.
Судя по тому, что эта конструкция прозрачно вписана в язык, есть
надежда, что CLR поменяют, и это не будет хаком.
> А теперь объясните, при чем здесь стек.
При том, что http://en.wikipedia.org/wiki/Funarg_problem
Конкретно Upwards funarg problem.
Therefore, the activation record containing the called function's
state variables must not be deallocated when the function returns,
violating the stack-based function call paradigm.
> А то, что технически такая модель может быть реализована с помощью > стека — это ни о чем не говорит. Если Вы против такой концепции — мне > придется Вас расстроить
Я не против концепции, я против конкретной реализации.
Здравствуйте, OCTAGRAM, Вы писали:
>> А то, что технически такая модель может быть реализована с помощью >> стека — это ни о чем не говорит. Если Вы против такой концепции — мне >> придется Вас расстроить OCT>Я не против концепции, я против конкретной реализации.
Здравствуйте, iyura, Вы писали:
I>Здравствуйте, _d_m_, Вы писали:
I>>>Ну как сказать... а если вместо := да заставят писать assign
___>>Если бы у бабушки был х.. она была бы дедушкой.
I>Типа пошутил?
Нет. Пословица такая русская есть, здесь насчет "а если вместо..."
I>>>Вспомни фортрановские LE, GE и как то там LT, кажется.... Как по мне , то гораздо проще <=, >=, <
___>>Это ты к чему вообще?
I>К тому, что синтаксис должен быть, по возможности, немногословным. И одним из недостатков Delphi (сугубо с моей точки зрения) как раз и есть все эти "приколы" типа :=, begin/end, procedure....
Ну хорошо, теперь понятно. А то какие-то там фортрановские бла-бла-бла, которые еще я почему-то должен помнить . Я их не знал вовсе. Но если уж вопрос встал о многословности, то GE и >= имеют одинаковое кол-во символов, не находишь?
Здравствуйте, hattab, Вы писали:
H>>>Проблема в практике использования таких конфигов. Заметь, я уже неоднократно писал, что можно и все правильно сделать.
___>>А причем здесь Дельфи или ДотНет?
H>Рекомендуемый/пропогандируемый/самый популярный/(подставь сам) подход может быть не идеальным. Если следуя ему легко сотворить корягу -- она таки будет сотворена (вспомним нападки на Delphi за то, что малограмотные кодеры размещали всю логику в обработчиках формы. Казалось бы, причем тут Delphi?). Еще пояснения нужны?
Не помню таких нападок. Т.е. ты считаешь, что использование конфигов есть потенциальный путь сотворить корягу, и что это недостаток ДотНет?
Здравствуйте, iyura, Вы писали:
I>Правда никого не заботило то, что при старте приложения при одном открытом окошке с маленькис списком 70Мб памяти было откушено. Мда...сумбурно получается. Короче, программист воспитаный на неуправляемой среде пишет качественнее
Не надо путать память и workset. Воспользуйся поиском хотя бы по местному форуму дотнет. Вопрос этот уже набил аскомину.
Здравствуйте, iyura, Вы писали:
MC>>Предполагается, что Dispose технически корректно освобождает ресурсы.
I>Вот как-то не складывается у меня с этим. Не спорю, скорее по незнанию\отсутствию опыта. Но я бы хотел сазать, что, например в С++ такие вещи идеологически чище. Чего стоят деструкторы в шарпе — читаешь документацию и сразу выпить хочется
Выпить хочется — это по другой причине. А деструкторов в шарпе — нет. Есть финализаторы — а это огромная разница. Читать Рихтера.
Здравствуйте, _d_m_, Вы писали:
MC>>>Предполагается, что Dispose технически корректно освобождает ресурсы.
I>>Вот как-то не складывается у меня с этим. Не спорю, скорее по незнанию\отсутствию опыта. Но я бы хотел сазать, что, например в С++ такие вещи идеологически чище. Чего стоят деструкторы в шарпе — читаешь документацию и сразу выпить хочется
___>Выпить хочется — это по другой причине. А деструкторов в шарпе — нет. Есть финализаторы — а это огромная разница. Читать Рихтера.
Здравствуйте, Mamut, Вы писали:
kuj>>>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
H>>Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
M>Объект, реализующий AddRef, Release и QueryInterface является чем?
COM-совместимым. Но! Это не делает интерфейс INonCOMObject COM-совместимым. Еще раз: интерфейс это целое, делить его нельзя (говорить, что три метода у нас совместимы, и потому совместим он весь). То, что COM сможет использовать три его метода, не дает ему права считаться COM-совместимым.
Здравствуйте, Mamut, Вы писали:
M>>>Чем интерфейс в Дельфи отличается от абстрактного класса?
H>>Интерфейс -- чистая декларация. Абстрактный класс -- класс, объекты которого нельзя создать (хотя в 2006 есть глюк, и такие объекты создать можно). При этом, абстрактный класс, может иметь любые поля/свойства/методы (не обязательно абстрактые).
M>В общем, разницы никакой за двумя важными исключениями:
Да ты чего??? Абстрактный класс может иметь реализованные методы, может иметь поля. В то время, как интерфейс только декларирует набор методов.
M>1. Interface позволяет множественное наследование M>2. В классах, наследуемых от Interface СOM-совместимые методы гвоздями прибиваются в самое начало vtable для обеспечения COM-совместимости. Таким образом, любой класс, наследуемый (в цепочке любой длины) от IUnknown будет COM-объектом, потому что у него будет как минимум три COM-совместимых метода: AddRef, Rekease и QueryInterface
M>Все эти извращения нужны только для одного — облегчить создание COM-объектов в Delphi
Терминология твоя просто жуть. Классы не наследуются от интерфейсов, они их реализуют. Наличие в классе методов _AddRef, _Release, QueryInterface не делает его автоматически реализующим IUnknown.
M>>>Должен ли я в MyClass реализовывать QueryInterface, _AddRef и _Release. Если нет, то почему?
H>>Должен, ибо это декларирует IUnknown от которого ты наследовал свой интерфейс. Тут есть еще очень важный момент. Если ты продекларируешь в классе реализуцию только одного интерфейса (MyInterface), от таких объектов нельзя будет получить IUnknown. Для получения IUnknown нужно декларировать реализацию обоих интерфейсов (или иметь предком класс реализующий IUnknown).
M>Что за бредятина? В чем тогда смысл объявления M>
M>MyInterface : Interface(IUnknown)
M>
M>?
Смысл в том, что описываешь НОВЫЙ интерфейс расширяя его методами предка. Если ты реализуешь в классе MyInterface, но не продекларируешь, что класс реализует IUnknown, последний от класса получить не удастся (при условии, что ни один из предков не реализует IUnknown). Если не веришь мне, сам попробуй.
Здравствуйте, _d_m_, Вы писали:
H>>>>Проблема в практике использования таких конфигов. Заметь, я уже неоднократно писал, что можно и все правильно сделать.
___>>>А причем здесь Дельфи или ДотНет?
H>>Рекомендуемый/пропогандируемый/самый популярный/(подставь сам) подход может быть не идеальным. Если следуя ему легко сотворить корягу -- она таки будет сотворена (вспомним нападки на Delphi за то, что малограмотные кодеры размещали всю логику в обработчиках формы. Казалось бы, причем тут Delphi?). Еще пояснения нужны?
___>Не помню таких нападок. Т.е. ты считаешь, что использование конфигов есть потенциальный путь сотворить корягу, и что это недостаток ДотНет?
Нападки были не в этой ветке, я говорю обобщая те, что слышал. Я не только так считаю, я еще и пример приводил
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mamut, Вы писали:
kuj>>>>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
H>>>Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
M>>Объект, реализующий AddRef, Release и QueryInterface является чем?
H>COM-совместимым. Но! Это не делает интерфейс INonCOMObject COM-совместимым. Еще раз: интерфейс это целое, делить его нельзя (говорить, что три метода у нас совместимы, и потому совместим он весь). То, что COM сможет использовать три его метода, не дает ему права считаться COM-совместимым.
И какая разница? Зачем нам сферовакуумный интерфейс? Если конкретный класс, его реализующий, все равно становится COM-объектом? С этого и начинался весь сыр-бор, емнип — есть ли в Дельфи не-COM интерфейсы:
Каждый объект, реализующий интерфейс преобретает семантику COM-объекта. То есть при использовании становится фактически COM-объектом.
Поэтому итнерфейсы в Delphi — именно COM-интерфейсы.
Можешь не спорить, это факт.
Любой класс, реализующий твой якобы не-COM интерфейс вдруг автоматом становится COM-объектом. Это как это так это?
То есть пусть даже все методы в новом интерфейсе будут несовместимыми с COM, как миниум три метода у него всегда будут COM-совместимыми, что автоматом делает интерфейс — сюрприз-сюрприз — совместимым с COM
M>>>>Должен ли я в MyClass реализовывать QueryInterface, _AddRef и _Release. Если нет, то почему?
H>>>Должен, ибо это декларирует IUnknown от которого ты наследовал свой интерфейс. Тут есть еще очень важный момент. Если ты продекларируешь в классе реализуцию только одного интерфейса (MyInterface), от таких объектов нельзя будет получить IUnknown. Для получения IUnknown нужно декларировать реализацию обоих интерфейсов (или иметь предком класс реализующий IUnknown).
M>>Что за бредятина? В чем тогда смысл объявления M>>
M>>MyInterface : Interface(IUnknown)
M>>
M>>?
H>Смысл в том, что описываешь НОВЫЙ интерфейс расширяя его методами предка.
Но при этом методы предка в новом интерфейсе остаются?
H>Если ты реализуешь в классе MyInterface, но не продекларируешь, что класс реализует IUnknown, последний от класса получить не удастся (при условии, что ни один из предков не реализует IUnknown). Если не веришь мне, сам попробуй.
Это как это так это? Борланд решил похерить все принципы наследования для интерфейсов??
// IUnknown декларирует _AddRef, _Release, QueryInterface
IntermediateInterface : Interface(IUnknown)
begin// в дополнение к трем предыдущим методам мы добавляемfunction GetData() : AnsiString
end
FinalInterface : Interface(IntermediateInterface)
begin// в дополнение к четырем предыдущимprocedure DoSmth();
end
MyClass: Class(FinalInterface)
begin// какие методы должен реализовать MyClass?end
Здравствуйте, hattab, Вы писали:
kuj>>>>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
H>>>Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
M>>Объект, реализующий AddRef, Release и QueryInterface является чем?
H>COM-совместимым. Но! Это не делает интерфейс INonCOMObject COM-совместимым. Еще раз: интерфейс это целое, делить его нельзя (говорить, что три метода у нас совместимы, и потому совместим он весь). То, что COM сможет использовать три его метода, не дает ему права считаться COM-совместимым.
Дает вообще-то. Хаттаб ты утомил своим невежеством. Тебе три или четыре человека русским языком втолковывают, а ты продолжаешь слепо строить свою стену непонимания.
Здравствуйте, Mr.Cat, Вы писали:
kuj>>Вообще-то есть... http://msdn.microsoft.com/en-us/library/66x5fx1b.aspx
MC>Один фиг — финализаторы. Просто почему-то разработчикам языка C# захотелось использовать для них C++-like синтаксис.
Видимо старались придерживаться C++ alike синтаксиса... В VB деструктор-финализатор это именно Finalize(), afaik.
Здравствуйте, OCTAGRAM, Вы писали:
>> А теперь объясните, при чем здесь стек. OCT>При том, что http://en.wikipedia.org/wiki/Funarg_problem OCT>Я не против концепции, я против конкретной реализации.
Т.е. Вам не нравится существующая реализация .NET FW потому что для решения funarg problem в ней путем неявного оборачивания замыканий и yield-методов в классы "хакается" стековая архитектура, вместо того, чтобы изначально использовать механизмы, не приводящие к funarg problem?
Попробую ответить.
.NET развивался как платформа, изначально поддерживающая 3 языка: MC++, C# и VB.NET. Все эти языки изначально не имели funarg problem, можно даже сказать, что на дизайн этих языков стек оказал определенное влияние. Поэтому и в реализации FW был использован стек и стекоориентированный IL. Сейчас смысла что-либо переделывать никакого нет. Функциональные языки не являются основным направлением развития платформы: F# — пока только эксперементальная игрушка, Nemerle — пожалуй, еще не так широко известен и используется, чтобы стать мейнстримом в .NET. Мейнстрим в .NET — это императивные языки. Функциональные возможности, добавленные в C# не делают его функциональным языком, о том, что функция является first-class object говорить нельзя. Поэтому реализация сохранения контекста вызова в виде небольшого "хака" стека — вполне уместна. Т.е. к императивной основе .NET, полагающейся на стек "сбоку" приделали функциональные возможности и реализовали их в рамках имеющихся средств вот и все. Когда функциональность войдет в мейнстрим — вот тогда и полюбуемся на всякие functional language runtime и иже с ними.
Здравствуйте, Mamut, Вы писали:
kuj>>>>>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
H>>>>Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
M>>>Объект, реализующий AddRef, Release и QueryInterface является чем?
H>>COM-совместимым. Но! Это не делает интерфейс INonCOMObject COM-совместимым. Еще раз: интерфейс это целое, делить его нельзя (говорить, что три метода у нас совместимы, и потому совместим он весь). То, что COM сможет использовать три его метода, не дает ему права считаться COM-совместимым.
M>И какая разница? Зачем нам сферовакуумный интерфейс? Если конкретный класс, его реализующий, все равно становится COM-объектом? С этого и начинался весь сыр-бор, емнип — есть ли в Дельфи не-COM интерфейсы:
M>
M>Каждый объект, реализующий интерфейс преобретает семантику COM-объекта. То есть при использовании становится фактически COM-объектом.
M>Поэтому итнерфейсы в Delphi — именно COM-интерфейсы.
M>Можешь не спорить, это факт.
M>Любой класс, реализующий твой якобы не-COM интерфейс вдруг автоматом становится COM-объектом. Это как это так это?
Мамут, ты запарил, ей богу... Передай, пожалуйста, по DCOM, динамический массив из анси-строк. Если при этом у тебя проблем с маршалингом не возникнет, я съем свои носки, а ты сможешь сказать, что в Delphi все интерфейсы COM-совместимы. Еще раз тебе повторяю, INonCOMObject не будет являться COM-совместимым вне зависимости от того, реализует класс методы IUnknown или нет.
M>То есть пусть даже все методы в новом интерфейсе будут несовместимыми с COM, как миниум три метода у него всегда будут COM-совместимыми, что автоматом делает интерфейс — сюрприз-сюрприз — совместимым с COM
Я тебе уже наглядно продемонстрировал, что можно сделать класс недекларирующий реализацию IUnknown, но реализующий INonCOMObject (наследованый от IUnknown), и от объектов этого класса невозможно будет получить IUnknown. Думай.
Здравствуйте, Mamut, Вы писали:
H>>Смысл в том, что описываешь НОВЫЙ интерфейс расширяя его методами предка.
M>Но при этом методы предка в новом интерфейсе остаются?
Разумеется. Подумай вот над чем: можешь ли ты у интерфейса узнать, кто его предок. Не можешь (ну, не считая фокусов с RTTI). Думай дальше.
H>>Если ты реализуешь в классе MyInterface, но не продекларируешь, что класс реализует IUnknown, последний от класса получить не удастся (при условии, что ни один из предков не реализует IUnknown). Если не веришь мне, сам попробуй.
M>Это как это так это? Борланд решил похерить все принципы наследования для интерфейсов??
Прикол в том, что наследование интерфейсов это просто расширении деклараций потомков, декларациями предков. Это не ООП наследование, где потомок можно привести к любому из предков. Для интерфейсов еще важно, как их будет реализовывать класс.
M>
M>// IUnknown декларирует _AddRef, _Release, QueryInterface
M>IntermediateInterface : Interface(IUnknown)
M>begin
M>// в дополнение к трем предыдущим методам мы добавляем
M>function GetData() : AnsiString
M>end
M>FinalInterface : Interface(IntermediateInterface)
M>begin
M>// в дополнение к четырем предыдущим
M>procedure DoSmth();
M>end
M>MyClass: Class(FinalInterface)
M>begin
M> // какие методы должен реализовать MyClass?
M>end
M>
Смотря от чего наследуется. Если наследуется от класса реализующего IUnknown, то только методы GetData и DoSmth; Если от обычного класса, то реализовать необходимо все 5 методов. Вот еще посмотри:
// Объект реализующий только IMyInterface
TMyObject = Class(TObject, IMyInterface)
...
End;
// Объект реализующий, и IUnknown, и IMyInterface
TMyObject2 = Class(TObject, IUnknown, IMyInterface)
...
End;
В этом примере, от объекта класса TMyObject ты не сможешь получить IUnknown несмотря на то, что IMyInterface наследован от него.
Здравствуйте, kuj, Вы писали:
kuj>>>>>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
H>>>>Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
M>>>Объект, реализующий AddRef, Release и QueryInterface является чем?
H>>COM-совместимым. Но! Это не делает интерфейс INonCOMObject COM-совместимым. Еще раз: интерфейс это целое, делить его нельзя (говорить, что три метода у нас совместимы, и потому совместим он весь). То, что COM сможет использовать три его метода, не дает ему права считаться COM-совместимым.
kuj>Дает вообще-то. Хаттаб ты утомил своим невежеством. Тебе три или четыре человека русским языком втолковывают, а ты продолжаешь слепо строить свою стену непонимания.
Вообще-то не дает Я Мамуту развернуто ответил, прочитай.
Здравствуйте, hattab, Вы писали:
H>INonCOMObject расширяет IUnknown. Говоря о INonCONObject мы говорим не только о трех методах. INonCOMObject не может являться COM-интерфейсом если имеет декларации несовместимые с требованиями COM. Это так сложно понять?
А какие декларации несовместимы с COM? Ссыллку на авторитетный источник, лучше MSDN. Иначе вся твоя болтовня — фуфло.
Здравствуйте, hattab, Вы писали:
H>Терминология твоя просто жуть. Классы не наследуются от интерфейсов, они их реализуют. Наличие в классе методов _AddRef, _Release, QueryInterface не делает его автоматически реализующим IUnknown.
С чего ты взял?
COM можно писать на C (обычном, без плюсов). Там вообще нет понятия интерфейса. Так ДОСТАТОЧНО реализовать _AddRef, _Release, QueryInterface
Здравствуйте, hattab, Вы писали:
H>Мамут, ты запарил, ей богу... Передай, пожалуйста, по DCOM, динамический массив из анси-строк. Если при этом у тебя проблем с маршалингом не возникнет, я съем свои носки, а ты сможешь сказать, что в Delphi все интерфейсы COM-совместимы. Еще раз тебе повторяю, INonCOMObject не будет являться COM-совместимым вне зависимости от того, реализует класс методы IUnknown или нет.
Ты свсем тупой чтоли? Даже не понимаешь разнице между COM и DCOM? Кстати я тебе пост на эту тему кидал.
H>Я тебе уже наглядно продемонстрировал, что можно сделать класс недекларирующий реализацию IUnknown, но реализующий INonCOMObject (наследованый от IUnknown), и от объектов этого класса невозможно будет получить IUnknown. Думай.
Еще одна бага в делфи?
В других языках (в C++ к примеру) при таком раскладе можно получить IUnknown.
Re[8]: наши менеджеры памяти самые менеджеристые менеджеры п
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Я помню, один раз хорошо сэкономил своей команде время на кодинг, OCT>дописав type String = String[255] в начале, без этого не проходило по OCT>времени. А время в разы отличается, как ни крути.
Я бы очень удивился если бы было иначе. Особенно если используются конструкции типа Str:= Str + BlaBlaBla;
Здравствуйте, gandjustas, Вы писали:
H>>INonCOMObject расширяет IUnknown. Говоря о INonCONObject мы говорим не только о трех методах. INonCOMObject не может являться COM-интерфейсом если имеет декларации несовместимые с требованиями COM. Это так сложно понять? G>А какие декларации несовместимы с COM? Ссыллку на авторитетный источник, лучше MSDN. Иначе вся твоя болтовня — фуфло.
Здравствуйте, gandjustas, Вы писали:
H>>Терминология твоя просто жуть. Классы не наследуются от интерфейсов, они их реализуют. Наличие в классе методов _AddRef, _Release, QueryInterface не делает его автоматически реализующим IUnknown.
G>С чего ты взял?
G>COM можно писать на C (обычном, без плюсов). Там вообще нет понятия интерфейса. Так ДОСТАТОЧНО реализовать _AddRef, _Release, QueryInterface
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Терминология твоя просто жуть. Классы не наследуются от интерфейсов, они их реализуют. Наличие в классе методов _AddRef, _Release, QueryInterface не делает его автоматически реализующим IUnknown.
G>>С чего ты взял?
G>>COM можно писать на C (обычном, без плюсов). Там вообще нет понятия интерфейса. Так ДОСТАТОЧНО реализовать _AddRef, _Release, QueryInterface
H>Мы тут о Delphi говорим, если ты не понял
COM — банарный формат. Ком объекты в делфи не отличаются от COM объектов на C, на C++ и даже на ассемблере.
Если есть отличия, то это на совести компиляторов.
Здравствуйте, gandjustas, Вы писали:
H>>Мамут, ты запарил, ей богу... Передай, пожалуйста, по DCOM, динамический массив из анси-строк. Если при этом у тебя проблем с маршалингом не возникнет, я съем свои носки, а ты сможешь сказать, что в Delphi все интерфейсы COM-совместимы. Еще раз тебе повторяю, INonCOMObject не будет являться COM-совместимым вне зависимости от того, реализует класс методы IUnknown или нет. G>Ты свсем тупой чтоли? Даже не понимаешь разнице между COM и DCOM? Кстати я тебе пост на эту тему кидал.
DCOM -- distributed COM. Ну, сделай тоже самое средствами COM. Я посмотрю, как ты обделаешься.
H>>Я тебе уже наглядно продемонстрировал, что можно сделать класс недекларирующий реализацию IUnknown, но реализующий INonCOMObject (наследованый от IUnknown), и от объектов этого класса невозможно будет получить IUnknown. Думай. G>Еще одна бага в делфи? G>В других языках (в C++ к примеру) при таком раскладе можно получить IUnknown.
Я говорю вот о чем: получив от объекта IMyInterface, ты можешь присвоить его переменной типа IUnknown (собственно, это даже обсуждать глупо). Но! Сделав MyIntf.QueryInterface(IUnknown, UnknownIntf) ты обломаешься. Обломаешься ты у в случае попытки прямого получения IUnknown от объекта (UnknownIntf := TMyObject.Create).
Здравствуйте, hattab, Вы писали:
H>DCOM -- distributed COM. Ну, сделай тоже самое средствами COM. Я посмотрю, как ты обделаешься.
Ликбез. COM — бинарный формат повтороно используемых компонент. DCOM — стандарт для вызова COM объектов между процессами.
Если у тебя INPROC сервер, то на него ограничения DCOM не действют.
H>Я говорю вот о чем: получив от объекта IMyInterface, ты можешь присвоить его переменной типа IUnknown (собственно, это даже обсуждать глупо). Но! Сделав MyIntf.QueryInterface(IUnknown, UnknownIntf) ты обломаешься. Обломаешься ты у в случае попытки прямого получения IUnknown от объекта (UnknownIntf := TMyObject.Create).
Значит бага делфи, в на других языках тоже самое отлично работает.
Более того, если бы такое не работало в принцибе, не работал бы COM вообще.
Вот что Бокс пишет по этому поводу:
Свойство рефлективности QueryInterface гарантирует, что любой интерфейсный указатель сможет удовлетворить запросы на IUnknown, поскольку все интерфейсные указатели неявно принадлежат к типу IUnknown. Спецификация СОМ имеет немного больше ограничений при описании результатов запросов QueryInterface именно на IUnknown. Объект не только должен отвечать «да» на запрос, он должен также возвращать в ответ на каждый запрос в точности одно и то же значение указателя.
Здравствуйте, gandjustas, Вы писали:
H>>>>Терминология твоя просто жуть. Классы не наследуются от интерфейсов, они их реализуют. Наличие в классе методов _AddRef, _Release, QueryInterface не делает его автоматически реализующим IUnknown.
G>>>С чего ты взял?
G>>>COM можно писать на C (обычном, без плюсов). Там вообще нет понятия интерфейса. Так ДОСТАТОЧНО реализовать _AddRef, _Release, QueryInterface
H>>Мы тут о Delphi говорим, если ты не понял G>COM — банарный формат. Ком объекты в делфи не отличаются от COM объектов на C, на C++ и даже на ассемблере. G>Если есть отличия, то это на совести компиляторов.
Речь не о бинарной совместимости. Речь об особенностях реализации.
Здравствуйте, gandjustas, Вы писали:
H>>DCOM -- distributed COM. Ну, сделай тоже самое средствами COM. Я посмотрю, как ты обделаешься. G>Ликбез. COM — бинарный формат повтороно используемых компонент. DCOM — стандарт для вызова COM объектов между процессами. G>Если у тебя INPROC сервер, то на него ограничения DCOM не действют.
А у нас, что, примерение COM ограничено inproc-серверами? Давай пример с предачей динамического массива из анси-строк.
H>>Я говорю вот о чем: получив от объекта IMyInterface, ты можешь присвоить его переменной типа IUnknown (собственно, это даже обсуждать глупо). Но! Сделав MyIntf.QueryInterface(IUnknown, UnknownIntf) ты обломаешься. Обломаешься ты у в случае попытки прямого получения IUnknown от объекта (UnknownIntf := TMyObject.Create).
G>Значит бага делфи, в на других языках тоже самое отлично работает. G>Более того, если бы такое не работало в принцибе, не работал бы COM вообще.
Это не бага. Просто ты тут пытаешься натянуть свое видение на окружающий мир, а он многообразен.
G>Вот что Бокс пишет по этому поводу: G>
G> Свойство рефлективности QueryInterface гарантирует, что любой интерфейсный указатель сможет удовлетворить запросы на IUnknown, поскольку все интерфейсные указатели неявно принадлежат к типу IUnknown. Спецификация СОМ имеет немного больше ограничений при описании результатов запросов QueryInterface именно на IUnknown. Объект не только должен отвечать «да» на запрос, он должен также возвращать в ответ на каждый запрос в точности одно и то же значение указателя.
Я еще могу сказать, что в Delphi есть интерфейсы не имеющие GUID (правда под нативом они не сильно юзабельны)
G>>Значит бага делфи, в на других языках тоже самое отлично работает. G>>Более того, если бы такое не работало в принцибе, не работал бы COM вообще.
H>Это не бага. Просто ты тут пытаешься натянуть свое видение на окружающий мир, а он многообразен.
Угу, это не бага. Это очередной ляп в реализации Делфи (если это вообще так и ты не вешаешь нам лапшу на уши).
Вот этот код прекрасно выполняется на C#. При чем кастинг выполняется неявно:
interface IMyIntA
{
void GetA();
}
interface IMyIntB : IMyIntA
{
void GetB();
}
public class MyObjB : IMyIntB
{
public void GetB()
{
System.Console.WriteLine("IMyIntB.GetB");
}
public void GetA()
{
System.Console.WriteLine("IMyIntA.GetA");
}
}
class Program
{
static void Main(string[] args)
{
MyObjB obj = new MyObjB();
IMyIntA a = obj;
a.GetA();
}
}
M>>// IUnknown декларирует _AddRef, _Release, QueryInterface
M>>IntermediateInterface : Interface(IUnknown)
M>>begin
M>>// в дополнение к трем предыдущим методам мы добавляем
M>>function GetData() : AnsiString
M>>end
M>>FinalInterface : Interface(IntermediateInterface)
M>>begin
M>>// в дополнение к четырем предыдущим
M>>procedure DoSmth();
M>>end
M>>MyClass: Class(FinalInterface)
M>>begin
M>> // какие методы должен реализовать MyClass?
M>>end
M>>
H>Смотря от чего наследуется. Если наследуется от класса реализующего IUnknown, то только методы GetData и DoSmth; Если от обычного класса, то реализовать необходимо все 5 методов.
H>Вот еще посмотри:
H>
H>// Объект реализующий только IMyInterface
H>TMyObject = Class(TObject, IMyInterface)
H>...
H>End;
H>// Объект реализующий, и IUnknown, и IMyInterface
H>TMyObject2 = Class(TObject, IUnknown, IMyInterface)
H>...
H>End;
H>
H>В этом примере, от объекта класса TMyObject ты не сможешь получить IUnknown несмотря на то, что IMyInterface наследован от него.
Все. Дельфи идет в лес семимильными шагами. Настолько испоганить идею наследования — это надо постараться.
"Вот у вас наследование, но это не наследование". "Вот у вас цепочка предков, но вы можете забить на то, что обозначено в любом из их предков, кроме ближайшего". "Если я родитель класса, то класс обязан реализовывать мои методы, а если дед — то необязан"
О. Кстати. Последняя фраза очень четко показывает кривизну такой реализации. Почему класс обязан реализовывать только методы непосредственного предка, а не всех предков по цепочке? Куда подевались методы всех предков? Если мы расширяем базовый интерфейс, разве это не значит, что методы предков никуда не подевались?
То есть, какой смысл писать:
MyInterface : Interface(IUnknown)
если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
Здравствуйте, hattab, Вы писали:
H>>>Рекомендуемый/пропогандируемый/самый популярный/(подставь сам) подход может быть не идеальным. Если следуя ему легко сотворить корягу -- она таки будет сотворена (вспомним нападки на Delphi за то, что малограмотные кодеры размещали всю логику в обработчиках формы. Казалось бы, причем тут Delphi?). Еще пояснения нужны?
___>>Не помню таких нападок. Т.е. ты считаешь, что использование конфигов есть потенциальный путь сотворить корягу, и что это недостаток ДотНет?
H>Нападки были не в этой ветке, я говорю обобщая те, что слышал. Я не только так считаю, я еще и пример приводил
Здравствуйте, kuj, Вы писали:
___>>Выпить хочется — это по другой причине. А деструкторов в шарпе — нет. Есть финализаторы — а это огромная разница. Читать Рихтера.
kuj>Вообще-то есть... http://msdn.microsoft.com/en-us/library/66x5fx1b.aspx
Понятие слово "деструктор" было взято из С++. В .Net CLR это несколько другое. Вобщем, читать Рихтера.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Вообще, в Borland оставлены ниточки, чтобы инициализировать "File" OCT>своими методами Read/Write/Flush/Close. Но на практике работают чаще с OCT>TStream, просто используют функции–форматтеры.
Не покажите как выглядит код с использованием TStream?
___>>>Выпить хочется — это по другой причине. А деструкторов в шарпе — нет. Есть финализаторы — а это огромная разница. Читать Рихтера.
kuj>>Вообще-то есть... http://msdn.microsoft.com/en-us/library/66x5fx1b.aspx
___>Понятие слово "деструктор" было взято из С++. В .Net CLR это несколько другое. Вобщем, читать Рихтера.
Вообще-то не другое, а то же самое. Финализатор в C# называется деструктором. Вообщем, читать MSDN.
Здравствуйте, Mamut, Вы писали:
M>То есть, какой смысл писать: M>
M>MyInterface : Interface(IUnknown)
M>
M>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
Он не может ее похерить. Никак. MyInterface наследует методы IUnknown. Единственное различие, что в Delphi QueryInterface возвращает только интерфейс, который явно записан в таблицу COM (или как оно там в Делфи реализовано), а кривость дельфового RTTI не дает получить информацию про предков интерфейса...
Во всяком случае именно так получается со слов хаттаба...
M>>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
kuj>Он не может ее похерить. Никак. MyInterface наследует методы IUnknown. Единственное различие, что в Delphi QueryInterface возвращает только интерфейс, который явно записан в таблицу COM (или как оно там в Делфи реализовано), а кривость дельфового RTTI не дает получить информацию про предков интерфейса...
kuj>Во всяком случае именно так получается со слов хаттаба...
Здравствуйте, kuj, Вы писали:
___>>>>Выпить хочется — это по другой причине. А деструкторов в шарпе — нет. Есть финализаторы — а это огромная разница. Читать Рихтера.
kuj>>>Вообще-то есть... http://msdn.microsoft.com/en-us/library/66x5fx1b.aspx
___>>Понятие слово "деструктор" было взято из С++. В .Net CLR это несколько другое. Вобщем, читать Рихтера.
kuj>Вообще-то не другое, а то же самое. Финализатор в C# называется деструктором. Вообщем, читать MSDN.
Вобщем-то другое и не тоже самое. С С++, судя по всему, ты не знаком. А толку от того что называется — только путаница. А в MSDN я и тебя сам могу послать. Слово Рихтер тебе о чем-то говорит?
H>>// Объект реализующий только IMyInterface
H>>TMyObject = Class(TObject, IMyInterface)
H>>...
H>>End;
H>>// Объект реализующий, и IUnknown, и IMyInterface
H>>TMyObject2 = Class(TObject, IUnknown, IMyInterface)
H>>...
H>>End;
H>>
H>>В этом примере, от объекта класса TMyObject ты не сможешь получить IUnknown несмотря на то, что IMyInterface наследован от него.
M>Все. Дельфи идет в лес семимильными шагами. Настолько испоганить идею наследования — это надо постараться.
Ничего не испоганено. Ты просто не понимаешь того, что критикуешь.
M>"Вот у вас наследование, но это не наследование". "Вот у вас цепочка предков, но вы можете забить на то, что обозначено в любом из их предков, кроме ближайшего". "Если я родитель класса, то класс обязан реализовывать мои методы, а если дед — то необязан"
M>О. Кстати. Последняя фраза очень четко показывает кривизну такой реализации. Почему класс обязан реализовывать только методы непосредственного предка, а не всех предков по цепочке? Куда подевались методы всех предков? Если мы расширяем базовый интерфейс, разве это не значит, что методы предков никуда не подевались?
Мамут, ну сколько можно повторять: понятие наследования интерфейсов не соотносится с понятием наследования классов. Наследование интерфейсов есть суть расширение декларации.
M>То есть, какой смысл писать: M>
M>MyInterface : Interface(IUnknown)
M>
M>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
Здравствуйте, kuj, Вы писали:
G>>>Значит бага делфи, в на других языках тоже самое отлично работает. G>>>Более того, если бы такое не работало в принцибе, не работал бы COM вообще.
H>>Это не бага. Просто ты тут пытаешься натянуть свое видение на окружающий мир, а он многообразен.
kuj>Угу, это не бага. Это очередной ляп в реализации Делфи (если это вообще так и ты не вешаешь нам лапшу на уши).
Ты всегда можешь это проверить. У меня нет задачи расписать Delphi, чтоб в нее все повлюблялись
Здравствуйте, _d_m_, Вы писали:
___>>>>>Выпить хочется — это по другой причине. А деструкторов в шарпе — нет. Есть финализаторы — а это огромная разница. Читать Рихтера.
kuj>>>>Вообще-то есть... http://msdn.microsoft.com/en-us/library/66x5fx1b.aspx
___>>>Понятие слово "деструктор" было взято из С++. В .Net CLR это несколько другое. Вобщем, читать Рихтера.
kuj>>Вообще-то не другое, а то же самое. Финализатор в C# называется деструктором. Вообщем, читать MSDN.
___>Вобщем-то другое и не тоже самое. С С++, судя по всему, ты не знаком. А толку от того что называется — только путаница. А в MSDN я и тебя сам могу послать. Слово Рихтер тебе о чем-то говорит?
Еще раз для тех, кто в танке: в С# и C++ .NET деструкторами называются финализаторы. Что тебе не понятно? Сложно открыть и прочитать MSDN? Или в Рихтере по-другому написано?
Или ты пытаешься сказать своим "слово Рихтер", что деструктор в управляемой среде и деструктор в native различаются? Ну так ясное дело различаются. Тем, что в управляемой среде момент вызова деструктора и порядок вызова деструкторов связных объектов недетерминированные.
Здравствуйте, hattab, Вы писали:
G>>>>Значит бага делфи, в на других языках тоже самое отлично работает. G>>>>Более того, если бы такое не работало в принцибе, не работал бы COM вообще.
H>>>Это не бага. Просто ты тут пытаешься натянуть свое видение на окружающий мир, а он многообразен.
kuj>>Угу, это не бага. Это очередной ляп в реализации Делфи (если это вообще так и ты не вешаешь нам лапшу на уши).
H>Ты всегда можешь это проверить.
Не могу.
H>У меня нет задачи расписать Delphi, чтоб в нее все повлюблялись
Здравствуйте, kuj, Вы писали:
M>>То есть, какой смысл писать: M>>
M>>MyInterface : Interface(IUnknown)
M>>
M>>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
kuj>Он не может ее похерить. Никак. MyInterface наследует методы IUnknown. Единственное различие, что в Delphi QueryInterface возвращает только интерфейс, который явно записан в таблицу COM (или как оно там в Делфи реализовано), а кривость дельфового RTTI не дает получить информацию про предков интерфейса...
RTTI как раз таки позволяет (и много чего еще позволяет)
Здравствуйте, hattab, Вы писали:
M>>О. Кстати. Последняя фраза очень четко показывает кривизну такой реализации. Почему класс обязан реализовывать только методы непосредственного предка, а не всех предков по цепочке? Куда подевались методы всех предков? Если мы расширяем базовый интерфейс, разве это не значит, что методы предков никуда не подевались?
H>Мамут, ну сколько можно повторять: понятие наследования интерфейсов не соотносится с понятием наследования классов. Наследование интерфейсов есть суть расширение декларации.
Это только в недоязыках типа Delphi так. В нормальных языках есть полноценная иерархия интерфейсов.
Здравствуйте, hattab, Вы писали:
M>>>То есть, какой смысл писать: M>>>
M>>>MyInterface : Interface(IUnknown)
M>>>
M>>>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
kuj>>Он не может ее похерить. Никак. MyInterface наследует методы IUnknown. Единственное различие, что в Delphi QueryInterface возвращает только интерфейс, который явно записан в таблицу COM (или как оно там в Делфи реализовано), а кривость дельфового RTTI не дает получить информацию про предков интерфейса...
H>RTTI как раз таки позволяет (и много чего еще позволяет)
Что в таком случае мешает неявно добавить всех предков в таблицу COM (или что там в Delphi в этой роли)?
Bigger пишет: > Здравствуйте, OCTAGRAM, Вы писали: > > OCT>Bigger пишет: >> > Вы что курите, хотя больше похоже на тяжелые синтетические наркотики. > OCT>перечитай ещё раз > > Тут сколько не читай, ничего не понятно.
>> > А зачем в одну кучу варианты использования, ООП и СОМ. >> > Первое относится варианты использования системы, т.е. это проектирование >> > системы, на этом этапе наплевать какую парадигму программирования >> > использовать > OCT>в роли системы реализация COM > > Так чтоже сказать то хотел, медленно и по русски
В роли юзера — сам программист, использующий COM. Наследуя, агрегируя,
описывая интерфейсы, и т. д., программист задействует варианты
использования (use cases) COM.
> VB6 неполноценный ООП, а ком на нем писать так что в путь
???
M>>О. Кстати. Последняя фраза очень четко показывает кривизну такой реализации. Почему класс обязан реализовывать только методы непосредственного предка, а не всех предков по цепочке? Куда подевались методы всех предков? Если мы расширяем базовый интерфейс, разве это не значит, что методы предков никуда не подевались?
H>Мамут, ну сколько можно повторять: понятие наследования интерфейсов не соотносится с понятием наследования классов. Наследование интерфейсов есть суть расширение декларации.
Хорошо. Мы расширили декларацию:
MyInterface : Interface(IUnknown)
Почему, согласно твоим словам, я обязан писать:
MyClass : Class(MyInterface, IUnknown)
а не
MyClass : Class(MyInterface)
для реализации IUnknown, если MyInterface всего лишь расширяет, а не подменяет IUnknown?
M>>То есть, какой смысл писать: M>>
M>>MyInterface : Interface(IUnknown)
M>>
M>>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
H>Ничего он не может похерить.
То есть AddRef, Release и QueryInterface в нем все равно будут присутствовать? Тогда любой класс, преализующий любой интерфейс будет COM-объектом, потому что в нем есть три необходимых и достаточных для COM метода — AddRef, Release и QueryInterface
hattab пишет: > kuj>Только без generic`ов ОЙ как плохо. > > Не сильно, если честно Для Delphi 2006 есть неофициальный тул (по сути > препроцессор) который реализует много чего: и дженерики, и case по > строкам, и exit с возвратом результата. В общем кому нужно -- тот найдет.
Когда–то я просто горел идеей препроцессора для Delphi. Решил
посмотреть, что есть. Так, для протокола. Свято место пусто не бывает,
их оказалось целых два. Есть DEEX,
есть DLangExtensions.
Правда проблемы мои были вовсе не те, я хотел специальный синтаксис для
графов, ориентированных и не–, для сбалансированных деревьев и т. д.,
чтоб можно было грамматику менять, так что эти идеи скорее в Seed7.
Впрочем, ни с чем из этого не имел дела и не буду, скорее всего.
Здравствуйте, kuj, Вы писали:
kuj>Или ты пытаешься сказать своим "слово Рихтер", что деструктор в управляемой среде и деструктор в native различаются? Ну так ясное дело различаются. Тем, что в управляемой среде момент вызова деструктора и порядок вызова деструкторов связных объектов недетерминированные.
Здравствуйте, Mr.Cat, Вы писали:
MC>Попробую ответить. MC>.NET развивался как платформа, изначально поддерживающая 3 языка: MC++, C# и VB.NET. Все эти языки изначально не имели funarg problem, можно даже сказать, что на дизайн этих языков стек оказал определенное влияние. Поэтому и в реализации FW был использован стек и стекоориентированный IL. Сейчас смысла что-либо переделывать никакого нет.
Лично я не думаю, что и в будущем появится смысл что-либо переделывать.
Стековая ориентированность IL позволяет во-первых проводить дешевую верификацию кода, а во-вторых генерировать достаточно эффективный целевой код на современных архитектурах.
MC>Функциональные языки не являются основным направлением развития платформы: F# — пока только эксперементальная игрушка, Nemerle — пожалуй, еще не так широко известен и используется, чтобы стать мейнстримом в .NET. Мейнстрим в .NET — это императивные языки. Функциональные возможности, добавленные в C# не делают его функциональным языком, о том, что функция является first-class object говорить нельзя. Поэтому реализация сохранения контекста вызова в виде небольшого "хака" стека — вполне уместна. Т.е. к императивной основе .NET, полагающейся на стек "сбоку" приделали функциональные возможности и реализовали их в рамках имеющихся средств вот и все. Когда функциональность войдет в мейнстрим — вот тогда и полюбуемся на всякие functional language runtime и иже с ними.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: наши менеджеры памяти самые менеджеристые менеджеры п
Здравствуйте, OCTAGRAM, Вы писали: OCT>Я помню, один раз хорошо сэкономил своей команде время на кодинг, OCT>дописав type String = String[255] в начале, без этого не проходило по OCT>времени. А время в разы отличается, как ни крути.
Насколько я помню, был такой ключик компилятора, который дефайнил String как ShortString вместо AnsiString.
Именно с ним были скомпилированы все модули VCL, благодаря чему у компонентов строковые свойства были ShortString.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kuj, Вы писали:
M>>>>То есть, какой смысл писать: M>>>>
M>>>>MyInterface : Interface(IUnknown)
M>>>>
M>>>>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
kuj>>>Он не может ее похерить. Никак. MyInterface наследует методы IUnknown. Единственное различие, что в Delphi QueryInterface возвращает только интерфейс, который явно записан в таблицу COM (или как оно там в Делфи реализовано), а кривость дельфового RTTI не дает получить информацию про предков интерфейса...
H>>RTTI как раз таки позволяет (и много чего еще позволяет)
kuj>Что в таком случае мешает неявно добавить всех предков в таблицу COM (или что там в Delphi в этой роли)?
Мешает неявность. Язык требует явного указания реализуемых интерфейсов. Кстати, этот вопрос (иерархию) вполне можно разруливать в момент компиляции и без всякой RTTI.
Здравствуйте, Mamut, Вы писали:
H>>Мамут, ну сколько можно повторять: понятие наследования интерфейсов не соотносится с понятием наследования классов. Наследование интерфейсов есть суть расширение декларации.
M>Хорошо. Мы расширили декларацию: M>
M>MyInterface : Interface(IUnknown)
M>
M>Почему, согласно твоим словам, я обязан писать: M>
M>MyClass : Class(MyInterface, IUnknown)
M>
M>а не M>
M>MyClass : Class(MyInterface)
M>
M>для реализации IUnknown, если MyInterface всего лишь расширяет, а не подменяет IUnknown?
MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология.
M>>>То есть, какой смысл писать: M>>>
M>>>MyInterface : Interface(IUnknown)
M>>>
M>>>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
H>>Ничего он не может похерить.
M>То есть AddRef, Release и QueryInterface в нем все равно будут присутствовать? Тогда любой класс, преализующий любой интерфейс будет COM-объектом, потому что в нем есть три необходимых и достаточных для COM метода — AddRef, Release и QueryInterface
Все верно. С чем ты споришь? Класс будет COM-объектом (если таки продекларирует реализацию IUnknown), а MyInterface не будет COM-интерфейсом. Я это уже несколько раз написал.
Здравствуйте, OCTAGRAM, Вы писали:
>> Не сильно, если честно Для Delphi 2006 есть неофициальный тул (по сути >> препроцессор) который реализует много чего: и дженерики, и case по >> строкам, и exit с возвратом результата. В общем кому нужно -- тот найдет. OCT>Когда–то я просто горел идеей препроцессора для Delphi. Решил OCT>посмотреть, что есть. Так, для протокола. Свято место пусто не бывает, OCT>их оказалось целых два. Есть DEEX, OCT>есть DLangExtensions.
Я именно DLangExtensions и имел ввиду
OCT>Правда проблемы мои были вовсе не те, я хотел специальный синтаксис для OCT>графов, ориентированных и не–, для сбалансированных деревьев и т. д., OCT>чтоб можно было грамматику менять, так что эти идеи скорее в Seed7.
OCT>Впрочем, ни с чем из этого не имел дела и не буду, скорее всего.
Аналогично. Я посмотрел, вроде все приятно, но терять совместимость очень не хочется, да и не все желаемые языковые фичи он реализует. Есть надежда, что после покупки CodeGear компанией Embarcadero, развитие языка только продолжится. Кстати, в своем обращении к пользователям, CodeGear сообщает о намерениях вести разработки для гетерогенных платформ (пойдем на Linux, MacOS?)
Re[9]: наши менеджеры памяти самые менеджеристые менеджеры п
Здравствуйте, Sinclair, Вы писали:
OCT>>Я помню, один раз хорошо сэкономил своей команде время на кодинг, OCT>>дописав type String = String[255] в начале, без этого не проходило по OCT>>времени. А время в разы отличается, как ни крути. S>Насколько я помню, был такой ключик компилятора, который дефайнил String как ShortString вместо AnsiString. S>Именно с ним были скомпилированы все модули VCL, благодаря чему у компонентов строковые свойства были ShortString.
Здравствуйте, hattab, Вы писали:
H>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология.
Эта идеология расходится с ООП. При том, что COM сам по себе никак с ООП не конфликтует.
Это еще раз доказывает что делфи — плохой язык.
Re[10]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали: H>Все с точностью до наоборот
Ты хочешь сказать, что стандартные компоненты VCL скомпилированы с длинными строками в свойствах? Я, правда, не смотрел на Delphi после 7.0, но раньше были именно ShortString. Для совместимости с Delphi 1.0, афаир.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, hattab, Вы писали: H>>Все с точностью до наоборот S>Ты хочешь сказать, что стандартные компоненты VCL скомпилированы с длинными строками в свойствах?
Именно так. В самом сердце VCL (Controls.pas) явно указывается использование AnsiStirng (LongStrings) {$H+}.
S>Я, правда, не смотрел на Delphi после 7.0, но раньше были именно ShortString. Для совместимости с Delphi 1.0, афаир.
Во всех 32-битных версиях AnsiStrings используется по умолчанию.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mamut, Вы писали:
H>>>Мамут, ну сколько можно повторять: понятие наследования интерфейсов не соотносится с понятием наследования классов. Наследование интерфейсов есть суть расширение декларации.
M>>Хорошо. Мы расширили декларацию: M>>
M>>MyInterface : Interface(IUnknown)
M>>
M>>Почему, согласно твоим словам, я обязан писать: M>>
M>>MyClass : Class(MyInterface, IUnknown)
M>>
M>>а не M>>
M>>MyClass : Class(MyInterface)
M>>
M>>для реализации IUnknown, если MyInterface всего лишь расширяет, а не подменяет IUnknown?
H>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология.
Обьясни, что значит расширяется.
РАСШИРЯТЬ несов. перех.
1. Делать большим по площади.
2. Увеличивать в количестве, в объеме. 3. перен. Делать более обширным, распространять круг действия чего-л.
В любом нормальном понимании (даже не ЯП — а просто понимании) расширение это:
— мы сохраняем все свойства предыдущей сущности
— мы добавляем к предыдущей сущности новые свойства
И ООП здесь не причем.
M>>>>То есть, какой смысл писать: M>>>>
M>>>>MyInterface : Interface(IUnknown)
M>>>>
M>>>>если класс, реализующий MyInterface может спокойно похерить реализацию методов из IUnknown?
H>>>Ничего он не может похерить.
M>>То есть AddRef, Release и QueryInterface в нем все равно будут присутствовать? Тогда любой класс, преализующий любой интерфейс будет COM-объектом, потому что в нем есть три необходимых и достаточных для COM метода — AddRef, Release и QueryInterface
H>Все верно. С чем ты споришь? Класс будет COM-объектом (если таки продекларирует реализацию IUnknown), а MyInterface не будет COM-интерфейсом. Я это уже несколько раз написал.
Так как объект, реализующий MyInterface все равно обязан реализовать COM-методы AddRef, Release и QueryInterface, то MyInterface все равно является COM-интерфейсом, в котором есть три COM-совместимых метода
Здравствуйте, gandjustas, Вы писали:
H>>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология. G>Эта идеология расходится с ООП. При том, что COM сам по себе никак с ООП не конфликтует. G>Это еще раз доказывает что делфи — плохой язык.
Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
Здравствуйте, hattab, Вы писали:
H>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
Само понятие расширения однозначно соответствует наследованию в ООП. Во многих языках наследование обозначается ключевым словом extends — "расширяет".
Только в делфи как-то неправильно сделано.
Интерфейсы кстати имеют немалое значение в ООП.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология. G>>Эта идеология расходится с ООП. При том, что COM сам по себе никак с ООП не конфликтует. G>>Это еще раз доказывает что делфи — плохой язык.
H>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
Здравствуйте, hattab, Вы писали:
H>>>RTTI как раз таки позволяет (и много чего еще позволяет)
kuj>>Что в таком случае мешает неявно добавить всех предков в таблицу COM (или что там в Delphi в этой роли)?
H>Мешает неявность. Язык требует явного указания реализуемых интерфейсов. Кстати, этот вопрос (иерархию) вполне можно разруливать в момент компиляции и без всякой RTTI.
Вот я и говорю, что язык кривой, раз требует явно перечислять всех предков интерфейса... Это ж надо было додуматься
Здравствуйте, hattab, Вы писали:
H>>>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология. G>>Эта идеология расходится с ООП. При том, что COM сам по себе никак с ООП не конфликтует. G>>Это еще раз доказывает что делфи — плохой язык.
H>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
Слышал про одну из основных/фундаментальных техник ОО, называемой инкапсуляцией? Похоже, что нет...
Здравствуйте, _d_m_, Вы писали:
kuj>>Или ты пытаешься сказать своим "слово Рихтер", что деструктор в управляемой среде и деструктор в native различаются? Ну так ясное дело различаются. Тем, что в управляемой среде момент вызова деструктора и порядок вызова деструкторов связных объектов недетерминированные.
___>Ну наконец-то ты понял.
Что именно я понял? Что ты сморозил глупость "деструкторов в шарпе нет", а теперь пытаешься выкрутиться? Ну да... вроде понял.
kuj>>>Что в таком случае мешает неявно добавить всех предков в таблицу COM (или что там в Delphi в этой роли)?
H>>Мешает неявность. Язык требует явного указания реализуемых интерфейсов. Кстати, этот вопрос (иерархию) вполне можно разруливать в момент компиляции и без всякой RTTI.
kuj>Вот я и говорю, что язык кривой, раз требует явно перечислять всех предков интерфейса... Это ж надо было додуматься
В обоих классах мы обязаны реализовать методы _AddRef, _Release и QueryInterface, потому что так требует их наличие в IUnknown, но MyClass мы не сможем привести к IUnknown. Несмотря на то, что он является наследником IUnknown
Здравствуйте, hattab, Вы писали:
H>Передай, пожалуйста, по DCOM, динамический массив из анси-строк. Если при этом у тебя проблем с маршалингом не возникнет, я съем свои носки, а ты сможешь сказать, что в Delphi все интерфейсы COM-совместимы.
Думаю, с custom маршалером можно будет передать без проблем.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, _d_m_, Вы писали:
kuj>>>Или ты пытаешься сказать своим "слово Рихтер", что деструктор в управляемой среде и деструктор в native различаются? Ну так ясное дело различаются. Тем, что в управляемой среде момент вызова деструктора и порядок вызова деструкторов связных объектов недетерминированные.
___>>Ну наконец-то ты понял.
kuj>Что именно я понял? Что ты сморозил глупость "деструкторов в шарпе нет", а теперь пытаешься выкрутиться? Ну да... вроде понял.
Глупости морозишь здесь пока ты. Только глупцы упорствуют в своем невежестве.
Джеффри Рихтер, "CLR via C# программирование на платформе Microsoft .Net Framework 2.0 на языке C#", Microsoft Press, Русская редакция, Питер 2007, стр. 457:
Внимание! Разработчики, хорошо знакомые с С++, заметят, что специальный синтаксис, используемый в C# для определения метода Finalize, похож на синтаксис деструктора С++. Действительно, в предыдущих версиях спецификации С# этот метод назывался деструктором (destructor). Однако метод Finalize работает совсем не так, как неуправляемый деструктор С++, что приводит в замешательство многих разработчиков, переходящих с одного языка на другой.
Беда в том, что ... бла-бла-бла ...
Во второй версии спецификации C# метод с таким синтаксисом официально назван завершителем (finalizer). Группа разработчиков C# также рассматривала возможность изменения синтаксиса этого метода, чтобы отказаться от применения тильды (~), но это сделало бы непригодным синтаксис имеющихся программ. Поэтому изменилось лишь название, а синтаксис оставлен прежним.
The C# Language Specification is the authoritative source for C# grammar and syntax. It contains detailed information about all aspects of the language and many points not covered in the Visual C# product documentation. The C# 3.0 specification has been updated and merged with earlier versions into a single document.
То есть спецификация составлена из старых документов.
Теперь открываем Ecma-334 (C# Language Specification), написаный для второго шарпа
17.12 Finalizers
[Note: In the previous version of this standard, what is now referred to as a "finalizer" was called a
"destructor". Experience has shown that the term "destructor" caused confusion and often resulted to
incorrect expectations, especially to programmers knowing C++. In C++, a destructor is called in a
determinate manner, whereas, in C#, a finalizer is not. To get determinate behavior from C#, one should use
Dispose. end note]
1.6.7.6 Destructors
A destructor is a member that implements the actions required to destruct an instance of a class. Destructors cannot have parameters, they cannot have accessibility modifiers, and they cannot be invoked explicitly. The destructor for an instance is invoked automatically during garbage collection.
The garbage collector is allowed wide latitude in deciding when to collect objects and run destructors. Specifically, the timing of destructor invocations is not deterministic, and destructors may be executed on any thread. For these and other reasons, classes should implement destructors only when no other solutions are feasible.
The using statement provides a better approach to object destruction.
Здравствуйте, kuj, Вы писали:
kuj>Вообщем сам кури, умник.
Не курю, глупник. Тебе уже сто раз сказано и на пальцах показано, что тебе еще не понятно? Что, кроме документации по Visual Studio (ака MSDN) ты больше ничего не знаешь и знать не хочешь?
Здравствуйте, _d_m_, Вы писали:
___>Не курю, глупник. Тебе уже сто раз сказано и на пальцах показано, что тебе еще не понятно? Что, кроме документации по Visual Studio (ака MSDN) ты больше ничего не знаешь и знать не хочешь?
Есть конкретный документ — спецификация языка C# 3.0, в котором четко написано что такое деструкторы в C#. Если до тебя так туго доходит, то извини — ничем больше помочь не могу.
Здравствуйте, _d_m_, Вы писали:
___>Ну хорошо, теперь понятно. А то какие-то там фортрановские бла-бла-бла, которые еще я почему-то должен помнить . Я их не знал вовсе. Но если уж вопрос встал о многословности, то GE и >= имеют одинаковое кол-во символов, не находишь?
Ну про фортрановское бла-бла ты расскажи людям, которые вычислительной математикой занимаются Я,например, работал в проекте в котором половина всего был фортран (финансы, оценка рисков)
Вот не помню точно, но в фортране >= это Greate Or Equal, т.е. GOE (три знака точно, но могу и ошибаться)
Но речь-то не о фортране (дедушка живее всех живых )
Здравствуйте, kuj, Вы писали:
kuj>Еще и как имеет. Java и .NET позволяют бОльшую часть кода покрыть юнит-тестами, и позволяют применять более высокоуровневые техники: IoC, AOP, O/RM ect
Юнит тестами и С++ покрывается. IoC, AOP — не знаю, что это. ORM и С++ живет. И в чем уникальность .Net и Java?
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, iyura, Вы писали:
kuj>За не совсем правильный стиль у нас бьют. Больно. Если не помогает, то выгоняют в связи с профнепригодностью.
kuj>Да не об аккуратности речь. Речь о человеческом факторе — свойстве допускать ошибки. Все ошибаются. А когда сроки поджимают, то может появится желание "срезать углы".
Вот и я о том же. И NET тут не сильно поможет
I>>А вот как себя поведет
I>>
I>>try
I>>{
I>> using(obj )
I>> {
I>> если тут облом с obj
I>> }
I>>}
I>>catch(...........)
I>>{
I>> тут хочу рассказать об обломе с obj
I>>}
I>>
kuj>В смысле как? using не делает catch. Соответственно "твой" catch поймает эксепшн.
Не буду спорить, но сдается мне, что using эквивалентно блоку try{} finally{} и если это так, то не вполне понятно как эксепшн пробьется в мой кэтч
kuj>>>Забыл упомянуть, что для доступа к БД фактически повсеместно используются O/RM, которые сами заботятся о подключениях. Единственное, где надо помнить о using — для TransactionScope`ов.
I>>Весьма спорно.
kuj>Что именно спорно? Что надо TransactionScope оборачивать в using или явно вызывать Dispose, т.к. это IDisposable объект?
Здравствуйте, _d_m_, Вы писали:
___>Не надо путать память и workset. Воспользуйся поиском хотя бы по местному форуму дотнет. Вопрос этот уже набил аскомину.
Мнэ.....А в двух словах? Ну искать и вправду долго.
Здравствуйте, iyura, Вы писали:
kuj>>Еще и как имеет. Java и .NET позволяют бОльшую часть кода покрыть юнит-тестами, и позволяют применять более высокоуровневые техники: IoC, AOP, O/RM ect
I>Юнит тестами и С++ покрывается.
Пример interaction testing на C++ в студию.
I>IoC, AOP — не знаю, что это. ORM и С++ живет.
Пример O/RM для C++ (native) в студию.
I>И в чем уникальность .Net и Java?
Странный вопрос, учитывая, что ты банально их не знаешь.
Здравствуйте, iyura, Вы писали:
kuj>>За не совсем правильный стиль у нас бьют. Больно. Если не помогает, то выгоняют в связи с профнепригодностью.
kuj>>Да не об аккуратности речь. Речь о человеческом факторе — свойстве допускать ошибки. Все ошибаются. А когда сроки поджимают, то может появится желание "срезать углы".
I>Вот и я о том же. И NET тут не сильно поможет
Вообще-то поможет и сильно.
I>>>А вот как себя поведет
I>>>
I>>>try
I>>>{
I>>> using(obj )
I>>> {
I>>> если тут облом с obj
I>>> }
I>>>}
I>>>catch(...........)
I>>>{
I>>> тут хочу рассказать об обломе с obj
I>>>}
I>>>
kuj>>В смысле как? using не делает catch. Соответственно "твой" catch поймает эксепшн.
I>Не буду спорить, но сдается мне, что using эквивалентно блоку try{} finally{} и если это так, то не вполне понятно как эксепшн пробьется в мой кэтч
Ликбез: эксепшины обрабатываются блоком catch, а finally только гарантирует, что код в этом блоке будет выполнен даже, если вылетел эксепшн.
kuj>>>>Забыл упомянуть, что для доступа к БД фактически повсеместно используются O/RM, которые сами заботятся о подключениях. Единственное, где надо помнить о using — для TransactionScope`ов.
I>>>Весьма спорно.
kuj>>Что именно спорно? Что надо TransactionScope оборачивать в using или явно вызывать Dispose, т.к. это IDisposable объект?
I>Спорно повсеместное использование O/RM
В .NET/Java/Ruby (Ruby on Rails) ect O/RM используются повсеместно за очень редкими исключениями.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, iyura, Вы писали:
kuj>>>Еще и как имеет. Java и .NET позволяют бОльшую часть кода покрыть юнит-тестами, и позволяют применять более высокоуровневые техники: IoC, AOP, O/RM ect
I>>Юнит тестами и С++ покрывается.
kuj>Пример interaction testing на C++ в студию.
Ты и в правду считаешь технологии тестирования прерогативой управляемых сред?
I>>IoC, AOP — не знаю, что это. ORM и С++ живет.
kuj>Пример O/RM для C++ (native) в студию.
Погугли
I>>И в чем уникальность .Net и Java?
kuj>Странный вопрос, учитывая, что ты банально их не знаешь.
Здравствуйте, iyura, Вы писали:
kuj>>>>Еще и как имеет. Java и .NET позволяют бОльшую часть кода покрыть юнит-тестами, и позволяют применять более высокоуровневые техники: IoC, AOP, O/RM ect
I>>>Юнит тестами и С++ покрывается.
kuj>>Пример interaction testing на C++ в студию.
I>Ты и в правду считаешь технологии тестирования прерогативой управляемых сред?
Я тебя попросил пример. Покажи мне аналог Moq`а, но для C++.
I>>>IoC, AOP — не знаю, что это. ORM и С++ живет.
kuj>>Пример O/RM для C++ (native) в студию.
I>Погугли
Значит сам не знаешь? Все ясно.
I>>>И в чем уникальность .Net и Java?
kuj>>Странный вопрос, учитывая, что ты банально их не знаешь.
I>Хамишь
Констатирую факт. Чего только стоит твой вопрос про try finally.
Здравствуйте, iyura, Вы писали:
I>Юнит тестами и С++ покрывается.
Так можно говорить только с большой натяжкой.
I>IoC, AOP — не знаю, что это.
Неудивительно
I>ORM и С++ живет.
Не живет.
Покажи ORM хотябы издалека похожий на Linq2SQL
I>И в чем уникальность .Net и Java?
Может сам немного почитаешь?
Здравствуйте, iyura, Вы писали:
I>Здравствуйте, _d_m_, Вы писали:
___>>Не надо путать память и workset. Воспользуйся поиском хотя бы по местному форуму дотнет. Вопрос этот уже набил аскомину.
I>Мнэ.....А в двух словах? Ну искать и вправду долго.
Workset — количество страниц, находящихся в оперативной памяти. Именно эту величину показывает TaskManager. Эта величина никак не коррелирует с общим объемом COMMITED памяти процесса.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, iyura, Вы писали:
I>>Юнит тестами и С++ покрывается. G>Так можно говорить только с большой натяжкой.
Unit testing + C++ в гугле выдает 2 450 000 ссылок. Я не могу и не хочу заниматься анализом всего этого
I>>IoC, AOP — не знаю, что это. G>Неудивительно
Давай так — Aspect-oriented programming.
Тогда так, например, получается http://www.aspectc.org/
Здравствуйте, iyura, Вы писали:
I>>>Юнит тестами и С++ покрывается. G>>Так можно говорить только с большой натяжкой.
I>Unit testing + C++ в гугле выдает 2 450 000 ссылок. Я не могу и не хочу заниматься анализом всего этого
Можешь не стараться. Полноценный unit testing (interaction testing в частности) без reflection не возможен.
I>>>IoC, AOP — не знаю, что это. G>>Неудивительно
I>Давай так — Aspect-oriented programming. I>Тогда так, например, получается http://www.aspectc.org/
Базируется на генерации прокси для эмуляции reflection — костыль.
I>>>ORM и С++ живет. G>>Не живет. G>>Покажи ORM хотябы издалека похожий на Linq2SQL
I>MS не позиционирует LINQ как ORM
Здравствуйте, iyura, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>Unit testing + C++ в гугле выдает 2 450 000 ссылок. Я не могу и не хочу заниматься анализом всего этого
В unit-тестировании немаловажная часть — mock объекты. При отсутствии метаданных придется все писать ручками. Это очень большой оверхед.
I>Давай так — Aspect-oriented programming. I>Тогда так, например, получается http://www.aspectc.org/
Это статическая кодогенерация, при изменении некторых параметров надо перекомпилировать приложение.
В Java и .NET можно обойтись изменением конфига.
I>IoC I>http://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D1%89%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8F
Тут имелся ввиду не сам принцип IoC, а т.н. IoC-контейнеры. Для них верно тоже, что и для AOP.
I>>>ORM и С++ живет. G>>Не живет. G>>Покажи ORM хотябы издалека похожий на Linq2SQL I>MS не позиционирует LINQ как ORM
А какая разница? C++ные варианты даже близко не валались к не-до-ORM Linq2sql
I>>>И в чем уникальность .Net и Java? G>>Может сам немного почитаешь? I>Может и ты напряжешься?
Я вроде как на .NET пишу, Java знаю, да и C++ немного понимаю
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, _d_m_, Вы писали:
___>>Не курю, глупник. Тебе уже сто раз сказано и на пальцах показано, что тебе еще не понятно? Что, кроме документации по Visual Studio (ака MSDN) ты больше ничего не знаешь и знать не хочешь?
kuj>Есть конкретный документ — спецификация языка C# 3.0, в котором четко написано что такое деструкторы в C#. Если до тебя так туго доходит, то извини — ничем больше помочь не могу.
Тебе уже конкретно пояснили, что этот документ по Visual C# 3.0 составлен из документов ранних версий. Тебе дать ссылку на конкретный документ, стандарт языка ECMA C# 2.0 где слова деструктор нет вообще, а есть слово Finalizer? На вот, если уж с использованием гугля у тебя трудности.
Здравствуйте, Mamut, Вы писали:
H>>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология.
M>Обьясни, что значит расширяется.
M>
M>РАСШИРЯТЬ несов. перех.
M>1. Делать большим по площади.
M>2. Увеличивать в количестве, в объеме.
M>3. перен. Делать более обширным, распространять круг действия чего-л.
M>В любом нормальном понимании (даже не ЯП — а просто понимании) расширение это: M>- мы сохраняем все свойства предыдущей сущности M>- мы добавляем к предыдущей сущности новые свойства
M>И ООП здесь не причем.
Правильно, ООП тут ни при чем.
M>>>То есть AddRef, Release и QueryInterface в нем все равно будут присутствовать? Тогда любой класс, преализующий любой интерфейс будет COM-объектом, потому что в нем есть три необходимых и достаточных для COM метода — AddRef, Release и QueryInterface
H>>Все верно. С чем ты споришь? Класс будет COM-объектом (если таки продекларирует реализацию IUnknown), а MyInterface не будет COM-интерфейсом. Я это уже несколько раз написал.
M>Так как объект, реализующий MyInterface все равно обязан реализовать COM-методы AddRef, Release и QueryInterface, то MyInterface все равно является COM-интерфейсом, в котором есть три COM-совместимых метода
Мамут, ты не прав Для тебя, зебра черная или белая? (она полосатая)
Re[13]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Mamut, Вы писали:
H>>Во всех 32-битных версиях AnsiStrings используется по умолчанию.
M>Они уже научились Юникод содержать и выводить на экран?
Юникод присутствует очень давно. В VCL поддержки юникода нет. Есть сторонние компоненты, тот же TNT, с поддержкой юникода. Юникод в VCL будет в Тибуроне (Delphi 2008).
Здравствуйте, gandjustas, Вы писали:
H>>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП. G>Само понятие расширения однозначно соответствует наследованию в ООП. Во многих языках наследование обозначается ключевым словом extends — "расширяет". G>Только в делфи как-то неправильно сделано.
Все правильно сделано. Ты просто понять не можешь.
G>Интерфейсы кстати имеют немалое значение в ООП.
Здравствуйте, Mamut, Вы писали:
H>>>>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология. G>>>Эта идеология расходится с ООП. При том, что COM сам по себе никак с ООП не конфликтует. G>>>Это еще раз доказывает что делфи — плохой язык.
H>>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
M>Кто это такое сказал? M>Интерфейс (объектно-ориентированное программирование)
Здравствуйте, kuj, Вы писали:
H>>>>RTTI как раз таки позволяет (и много чего еще позволяет)
kuj>>>Что в таком случае мешает неявно добавить всех предков в таблицу COM (или что там в Delphi в этой роли)?
H>>Мешает неявность. Язык требует явного указания реализуемых интерфейсов. Кстати, этот вопрос (иерархию) вполне можно разруливать в момент компиляции и без всякой RTTI.
kuj>Вот я и говорю, что язык кривой, раз требует явно перечислять всех предков интерфейса... Это ж надо было додуматься
Ну так наследуйся от классов реализующих требуемые интерфейсы, в чем проблема?
Здравствуйте, kuj, Вы писали:
H>>>>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология. G>>>Эта идеология расходится с ООП. При том, что COM сам по себе никак с ООП не конфликтует. G>>>Это еще раз доказывает что делфи — плохой язык.
H>>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
kuj>Слышал про одну из основных/фундаментальных техник ОО, называемой инкапсуляцией? Похоже, что нет...
Прикол в том, что инкапсуляция достигается на уровне классов, а ни как не интерфейсов. Инкапсуляция относится к реализации, в то время, как интерфейсы есть суть чистейшая абстракция. Контракт. Интерфейсы повышают степень инкапсуляции? Как посмотреть. Свойства, в данном контексте, куда более значимы для увеличения степени инкапсуляции, но ни кто же не говорит, что они есть фундаментальная единица ООП.
Здравствуйте, Mamut, Вы писали:
kuj>>>>Что в таком случае мешает неявно добавить всех предков в таблицу COM (или что там в Delphi в этой роли)?
H>>>Мешает неявность. Язык требует явного указания реализуемых интерфейсов. Кстати, этот вопрос (иерархию) вполне можно разруливать в момент компиляции и без всякой RTTI.
kuj>>Вот я и говорю, что язык кривой, раз требует явно перечислять всех предков интерфейса... Это ж надо было додуматься
M>Там все гораздо хуже: M>
M>В обоих классах мы обязаны реализовать методы _AddRef, _Release и QueryInterface, потому что так требует их наличие в IUnknown, но MyClass мы не сможем привести к IUnknown. Несмотря на то, что он является наследником IUnknown
Мамут, класс не может являться наследником интерфейса.
M>И эта кривизна называется "идеологией"
Как ты можешь рассуждать об идеологии, в то время как, позволяешь себе подобные высказывания (выделено)
Здравствуйте, AndrewJD, Вы писали:
H>>Передай, пожалуйста, по DCOM, динамический массив из анси-строк. Если при этом у тебя проблем с маршалингом не возникнет, я съем свои носки, а ты сможешь сказать, что в Delphi все интерфейсы COM-совместимы.
AJD>Думаю, с custom маршалером можно будет передать без проблем.
Да. Только после этого называть такой интерфейс COM-совместимым, это все равно, что назвать танк летающим только потому, что он в транспортном самолете находится.
Здравствуйте, squid, Вы писали:
H>> ...CodeGear сообщает о намерениях вести разработки для гетерогенных платформ (пойдем на Linux, MacOS?)
S>они бы хидеры из Windows SDK хоть перевели на Delphi...
Это давно не проблема... У джедаев давно есть полный комплект (JWA), есть конверторы C2Pas.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП. G>>Само понятие расширения однозначно соответствует наследованию в ООП. Во многих языках наследование обозначается ключевым словом extends — "расширяет". G>>Только в делфи как-то неправильно сделано.
H>Все правильно сделано. Ты просто понять не можешь.
Это ты понять не можешь в силу ограниченности кругозора.
G>>Интерфейсы кстати имеют немалое значение в ООП. H>Конечно имеют, кто же спорит.
Ты споришь
Re[14]: наши менеджеры памяти самые менеджеристые менеджеры
H>>>Во всех 32-битных версиях AnsiStrings используется по умолчанию.
M>>Они уже научились Юникод содержать и выводить на экран?
H>Юникод присутствует очень давно. В VCL поддержки юникода нет.
Все. На этом на Дельфи можно ставить крест. Если они за нцать лет так и не удосужились в Юникодном мире в свои собственные стандартные компоненты не вставить Юникод
H> Есть сторонние компоненты, тот же TNT, с поддержкой юникода. Юникод в VCL будет в Тибуроне (Delphi 2008).
Внимательно смотри отличие:
Java — поддержка Юникода нативно
.NET — поддержка Юникода нативно
Qt — поддержка Юникода нативно
Delphi- а вот есть сторонние компоненты...
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, squid, Вы писали:
H>>> ...CodeGear сообщает о намерениях вести разработки для гетерогенных платформ (пойдем на Linux, MacOS?)
S>>они бы хидеры из Windows SDK хоть перевели на Delphi...
H>Это давно не проблема... У джедаев давно есть полный комплект (JWA), есть конверторы C2Pas.
простой пример — DirectShow. Видел 3 варианта, во всех куча багов и нет Вистовских фич вроде EVR в нормальном виде.
начнешь плотно работать — видно сколь криво это сделано. а чтото более бажное и громоздкое чем JVCL вообще сложно представить.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mamut, Вы писали:
kuj>>>>>Что в таком случае мешает неявно добавить всех предков в таблицу COM (или что там в Delphi в этой роли)?
H>>>>Мешает неявность. Язык требует явного указания реализуемых интерфейсов. Кстати, этот вопрос (иерархию) вполне можно разруливать в момент компиляции и без всякой RTTI.
kuj>>>Вот я и говорю, что язык кривой, раз требует явно перечислять всех предков интерфейса... Это ж надо было додуматься
M>>Там все гораздо хуже: M>>
M>>В обоих классах мы обязаны реализовать методы _AddRef, _Release и QueryInterface, потому что так требует их наличие в IUnknown, но MyClass мы не сможем привести к IUnknown. Несмотря на то, что он является наследником IUnknown
H>Мамут, класс не может являться наследником интерфейса.
M>>И эта кривизна называется "идеологией"
H>Как ты можешь рассуждать об идеологии, в то время как, позволяешь себе подобные высказывания (выделено)
Блин. Еще раз. В MyClass мы обязаны реализовывать методы из IUnknown? Да. Является ли он тогда совместимым с IUnknown? Да. Почему я не могу привести его к IUnknown?
H>>>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
M>>Кто это такое сказал? M>>Интерфейс (объектно-ориентированное программирование)
H>Мамут, ты сам подумай
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mamut, Вы писали:
H>>>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология.
M>>Обьясни, что значит расширяется.
M>>
M>>РАСШИРЯТЬ несов. перех.
M>>1. Делать большим по площади.
M>>2. Увеличивать в количестве, в объеме.
M>>3. перен. Делать более обширным, распространять круг действия чего-л.
M>>В любом нормальном понимании (даже не ЯП — а просто понимании) расширение это: M>>- мы сохраняем все свойства предыдущей сущности M>>- мы добавляем к предыдущей сущности новые свойства
M>>И ООП здесь не причем.
H>Правильно, ООП тут ни при чем.
MyClass обязан реализовывать методы из IUnknown. Потому что MyInterface не подменяет IUnknown, а расширяет. При этом он остается IUnknown. Почему? Потому что любой класс, реализующий MyInterface, обязан реализовать IUnknown.
MyClass обязан реализовать и IUnknown и MyInterface2. Потому что MyInterface2 остается как MyInterface, так и MyInterface. Почему? Потому что любой класс, реализующий MyInterface2 обязан реализовать все методы из всех интерфейсов. Это в чистом виде наследование от абстрактных классов.
Но при этом, несмотря на то, что мы уже реаизуем все методы всех интерфейсов по цепочке, мы должны все равно явно указывать компилятору, что мы реализуем эти интерфейсы в том или ином классе. Это ли не верх идиотизма:
Я уже реализовал IUnknown. Зачем мне его дополнительно указывать в декарации класса? Если я не могу класс привести к IUnknown, то зачем мне реализовывать методы из IUnknown? Чтобы просто так, тонны дополнительного кода писать?
Здравствуйте, hattab, Вы писали:
AJD>>Думаю, с custom маршалером можно будет передать без проблем.
H>Да. Только после этого называть такой интерфейс COM-совместимым, это все равно, что назвать танк летающим только потому, что он в транспортном самолете находится.
Он будет COM-совместимым . Ты путаешь бинарную COM совместимость с OLE Automation. Да, стандартный OLE automation маршалер работать не будет, ну и что с того?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
hattab пишет: > Это давно не проблема... У джедаев давно есть полный комплект (JWA), > есть конверторы C2Pas.
Из автоматических генераторов привязок более–менее продвинутый
cableswig. Но вот хотелось бы пусть не полностью автоматический, но с
возможностью специализации под каждую библиотеку. Потому что в пределах
одной библиотеки можно найти множество разных похожих приёмов. И вообще,
эти штуки, пусть не приёмы, а, назовём их, концепты нужно замаппить с
одного языка на другой, и тогда это будет удобная в использовании
привязка, а не просто калька с заголовочных файлов. Мне больше всего
нравится идея, когда есть тонкая привязка и толстая поверх тонкой. Вот,
например, какие в Win32 есть приёмы–концепты? Есть HRESULT. Его можно
было бы завернуть (для каждого вызова) в проверку на результат. Потому
что если проверять результат в Delphi, то это doesn't feel like Delphi,
а если вручную дописывать Succeded(вроде?), то это недостаточно толстые
привязки. А есть ещё особенность WinAPI, когда дополнительный параметр у
Callback пробрасывается через lParam. В других библиотеках параметр
Callback, скорее всего, будет void*. И вот как универсальный биндинг
генератор с этим универсально справится? Универсально можно только
оставить всё как есть, чтобы в привязках были всё те же lParam и void*.
Но это будет тонкая привязка. Толстая привязка давала бы использовать в
качестве Callback методы объектов в Delphi и нисходящие замыкания в Аде.
Я это к тому, что специализируемый генератор привязок может решить
проблему поддержки толстых привязок up to date. Чтобы сделать такой
генератор, нужно обратиться к какому–то динамическому языку. Можно,
конечно, создать с нуля механизм, достаточный для частичного решения
задачи. Вот только это всё равно получается мини–язык. Немало
специализированных мини–языков выросло в нечто большее. И все
несовместимы друг с другом. PHP начинался как несложный механизм HTML
шаблонов. XSLT изначально конвертировал XML в XML. А сейчас уже EXSLT и
FXSLT делают XSLT вполне себе высокоуровневым языком. Ну и GNU m4,
изначально препроцессор, на нём тоже можно писать. Целью родить новый
язык я не задавался, поэтому нужно прибиться к какому–то уже
существующему. Мне Пролог кажется более подходящим.
Хорошие толстые привязки нужны и для Delphi, и для Ada, и для .NET ( http://www.pinvoke.net/ ), и для D. Проблема общая. Пока что все делают
каждый отдельно, и справляются не очень хорошо. Это называется A*B.
Хотелось бы свести A*B к A+B, а, чтобы это произошло, нужно начать
описанный проект.
Sinclair пишет: > Здравствуйте, OCTAGRAM, Вы писали: > OCT>Я помню, один раз хорошо сэкономил своей команде время на кодинг, > OCT>дописав type String = String[255] в начале, без этого не проходило по > OCT>времени. А время в разы отличается, как ни крути. > Насколько я помню, был такой ключик компилятора
Ключики компилятора на сервере олимпиад мы менять, конечно, не могли,
поэтому так.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Ключики компилятора на сервере олимпиад мы менять, конечно, не могли, OCT>поэтому так.
Мы делали так: настраивали компилятор через настройки среды.
Потом — Ctrl-O дважды. Эта комбинация клавиш вставляет все настройки компилятора в виде директив в начало исходника.
Здравствуйте, gandjustas, Вы писали:
H>>>>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП. G>>>Само понятие расширения однозначно соответствует наследованию в ООП. Во многих языках наследование обозначается ключевым словом extends — "расширяет". G>>>Только в делфи как-то неправильно сделано.
H>>Все правильно сделано. Ты просто понять не можешь. G>Это ты понять не можешь в силу ограниченности кругозора.
Свои домыслы оставь при себе.
G>>>Интерфейсы кстати имеют немалое значение в ООП. H>>Конечно имеют, кто же спорит. G>Ты споришь
Это ты сон такой видел, да?
Re[15]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Mamut, Вы писали:
H>>>>Во всех 32-битных версиях AnsiStrings используется по умолчанию.
M>>>Они уже научились Юникод содержать и выводить на экран?
H>>Юникод присутствует очень давно. В VCL поддержки юникода нет.
M>Все. На этом на Дельфи можно ставить крест. Если они за нцать лет так и не удосужились в Юникодном мире в свои собственные стандартные компоненты не вставить Юникод
H>> Есть сторонние компоненты, тот же TNT, с поддержкой юникода. Юникод в VCL будет в Тибуроне (Delphi 2008).
M>Внимательно смотри отличие: M>Java — поддержка Юникода нативно M>.NET — поддержка Юникода нативно M>Qt — поддержка Юникода нативно M>Delphi- а вот есть сторонние компоненты...
Главное, решение-то есть. Да и язык сей факт ни как не характеризует.
Здравствуйте, squid, Вы писали:
H>>>> ...CodeGear сообщает о намерениях вести разработки для гетерогенных платформ (пойдем на Linux, MacOS?)
S>>>они бы хидеры из Windows SDK хоть перевели на Delphi...
H>>Это давно не проблема... У джедаев давно есть полный комплект (JWA), есть конверторы C2Pas.
S>простой пример — DirectShow. Видел 3 варианта, во всех куча багов и нет Вистовских фич вроде EVR в нормальном виде.
DSPack смотрел? Не знаю, как там на счет Вистовых плюшек, но хидеры DirectShow там есть. В крайнем случае, можно найти подходящий конвертор.
S>начнешь плотно работать — видно сколь криво это сделано. а чтото более бажное и громоздкое чем JVCL вообще сложно представить.
Здравствуйте, Mamut, Вы писали:
H>>>>>Мешает неявность. Язык требует явного указания реализуемых интерфейсов. Кстати, этот вопрос (иерархию) вполне можно разруливать в момент компиляции и без всякой RTTI.
kuj>>>>Вот я и говорю, что язык кривой, раз требует явно перечислять всех предков интерфейса... Это ж надо было додуматься
M>>>Там все гораздо хуже: M>>>
M>>>В обоих классах мы обязаны реализовать методы _AddRef, _Release и QueryInterface, потому что так требует их наличие в IUnknown, но MyClass мы не сможем привести к IUnknown. Несмотря на то, что он является наследником IUnknown
H>>Мамут, класс не может являться наследником интерфейса.
M>>>И эта кривизна называется "идеологией"
H>>Как ты можешь рассуждать об идеологии, в то время как, позволяешь себе подобные высказывания (выделено)
M>Блин. Еще раз. В MyClass мы обязаны реализовывать методы из IUnknown? Да. Является ли он тогда совместимым с IUnknown? Да. Почему я не могу привести его к IUnknown?
Нет, он не является совместимым с IUnknown т.к. IUnknown не продекларирован в списке реализуемых интерфейсов и реализуешь ты методы не IUnknown, а MyInterface. Я это повторил уже раз десять.
Здравствуйте, Mamut, Вы писали:
H>>>>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
M>>>Кто это такое сказал? M>>>Интерфейс (объектно-ориентированное программирование)
H>>Мамут, ты сам подумай
M>Ты становишься похожим на kuj'а.
Хочешь говорить предметно, будь добр приводить аргументы опровергающие мои слова, или явно указывай с чем конкретно ты не согласен.
Здравствуйте, hattab, Вы писали:
G>>>>Интерфейсы кстати имеют немалое значение в ООП. H>>>Конечно имеют, кто же спорит. G>>Ты споришь
H>Это ты сон такой видел, да?
Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
Не ты писал?
Re[16]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mamut, Вы писали:
M>>Внимательно смотри отличие: M>>Java — поддержка Юникода нативно M>>.NET — поддержка Юникода нативно M>>Qt — поддержка Юникода нативно M>>Delphi- а вот есть сторонние компоненты...
H>Главное, решение-то есть. Да и язык сей факт ни как не характеризует.
Зато платформу очень даже характеризует.
Здравствуйте, Mamut, Вы писали:
H>>>>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология.
M>>>Обьясни, что значит расширяется.
M>>>
M>>>РАСШИРЯТЬ несов. перех.
M>>>1. Делать большим по площади.
M>>>2. Увеличивать в количестве, в объеме.
M>>>3. перен. Делать более обширным, распространять круг действия чего-л.
M>>>В любом нормальном понимании (даже не ЯП — а просто понимании) расширение это: M>>>- мы сохраняем все свойства предыдущей сущности M>>>- мы добавляем к предыдущей сущности новые свойства
M>>>И ООП здесь не причем.
H>>Правильно, ООП тут ни при чем.
M>Дай свое оределение понятия расширяет
Я же специально для тебя выделил. Читай внимательно.
M>Вот, что я вижу:
M>
M>MyClass обязан реализовывать методы из IUnknown. Потому что MyInterface не подменяет IUnknown, а расширяет. При этом он остается IUnknown. Почему? Потому что любой класс, реализующий MyInterface, обязан реализовать IUnknown.
MyInterface расширяется декларацией IUnknown. MyInterface можно приводить к IUnknown. Это понятно?
M>Далее: M>
M>MyClass обязан реализовать и IUnknown и MyInterface2. Потому что MyInterface2 остается как MyInterface, так и MyInterface. Почему? Потому что любой класс, реализующий MyInterface2 обязан реализовать все методы из всех интерфейсов. Это в чистом виде наследование от абстрактных классов.
Перечитай свой абзац -- это абзац MyClass обязан реализовать MyInterface, не IUnknown. В Delphi интерфейсы полностью соответствуют идеологии и являются абсолютными абстракциями, перестань натягивать терминологию C++ с абстрактными классами.
M>Но при этом, несмотря на то, что мы уже реаизуем все методы всех интерфейсов по цепочке, мы должны все равно явно указывать компилятору, что мы реализуем эти интерфейсы в том или ином классе. Это ли не верх идиотизма:
Еще раз. Расширение ни есть наследование. Постарайся посмотреть на это под другим углом.
M>
M>Я уже реализовал IUnknown. Зачем мне его дополнительно указывать в декарации класса? Если я не могу класс привести к IUnknown, то зачем мне реализовывать методы из IUnknown? Чтобы просто так, тонны дополнительного кода писать?
Жаль, что ты так и не понял... Реализуешь ты тут только MyInterface полученый путем расширения декларации от IUnknown.
Здравствуйте, AndrewJD, Вы писали:
AJD>>>Думаю, с custom маршалером можно будет передать без проблем.
H>>Да. Только после этого называть такой интерфейс COM-совместимым, это все равно, что назвать танк летающим только потому, что он в транспортном самолете находится.
AJD>Он будет COM-совместимым . Ты путаешь бинарную COM совместимость с OLE Automation. Да, стандартный OLE automation маршалер работать не будет, ну и что с того?
Здравствуйте, hattab, Вы писали:
H>Нет, он не является совместимым с IUnknown т.к. IUnknown не продекларирован в списке реализуемых интерфейсов и реализуешь ты методы не IUnknown, а MyInterface. Я это повторил уже раз десять.
Поздравляю, ты стодвадцатьпервый раз показал кривость делфи. Хватит уже, все поняли что использование интерфейсов в делфи — огромные грабли.
Слава богу в других языках такого бреда нет.
Здравствуйте, gandjustas, Вы писали:
G>>>>>Интерфейсы кстати имеют немалое значение в ООП. H>>>>Конечно имеют, кто же спорит. G>>>Ты споришь
H>>Это ты сон такой видел, да?
G>
G>Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
G>Не ты писал?
И еще раз напишу, чтоб ты понял: Наследование, инкапсуляция и полиморфизм, вот фундамент ООП. Интерфейсы, да приятная штука снимающая зависимости кода, не более того.
Здравствуйте, hattab, Вы писали:
H>И еще раз напишу, чтоб ты понял: Наследование, инкапсуляция и полиморфизм, вот фундамент ООП. Интерфейсы, да приятная штука снимающая зависимости кода, не более того.
Интерфейсы не имеют отношения к наследованию и полиморфизму?
Здравствуйте, hattab, Вы писали:
AJD>>>>Думаю, с custom маршалером можно будет передать без проблем.
AJD>>Он будет COM-совместимым . Ты путаешь бинарную COM совместимость с OLE Automation. Да, стандартный OLE automation маршалер работать не будет, ну и что с того?
H>А про бинарную совместимость ни кто и не спорил
Да. Только после этого называть такой интерфейс COM-совместимым, это все равно, что назвать танк летающим только потому, что он в транспортном самолете находится. (c)hattab
А эту фразу как понимать?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
H>MyInterface расширяется декларацией IUnknown. MyInterface можно приводить к IUnknown. Это понятно?
H>Жаль, что ты так и не понял... Реализуешь ты тут только MyInterface полученый путем расширения декларации от IUnknown.
Так кто кого расширяет?
Давай еще раз, ок?
MyInterface : Interface(IUnknown)
someMethod()
end
MyClass : Class(MyInterface)
H>>> Есть сторонние компоненты, тот же TNT, с поддержкой юникода. Юникод в VCL будет в Тибуроне (Delphi 2008).
M>>Внимательно смотри отличие: M>>Java — поддержка Юникода нативно M>>.NET — поддержка Юникода нативно M>>Qt — поддержка Юникода нативно M>>Delphi- а вот есть сторонние компоненты...
H>Главное, решение-то есть.
Что будем делать, когда стоит ограничение на использование сторонних компонентов?
H>Да и язык сей факт ни как не характеризует.
Характеризуют и язык и платформу, как устаревшую и не соответствующую современным требованиям
Здравствуйте, Mamut, Вы писали: M>Какие классы обязан реализовать класс MyClass?
Да ладно тебе эту жвачку пережевывать. Ну не сделали в Дельфи отношение реализации интерфейсов транзитивным, ну и что? Такой был у Хейльсберга осознанный выбор.
А вот Страуструп вовсе разрешает делать приватное наследование от абстрактного класса, и что? Ты точно так же можешь сделать
class IMyInterface: private IUnknown
{
}
class myClass: public IMyInterface
{
...
}
И обломишься на приведении myСlass к IUnknown, хотя все методы будешь обязан реализовать. Делов-то.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
M>>Какие классы обязан реализовать класс MyClass? S>Да ладно тебе эту жвачку пережевывать. Ну не сделали в Дельфи отношение реализации интерфейсов транзитивным, ну и что? Такой был у Хейльсберга осознанный выбор. S>А вот Страуструп вовсе разрешает делать приватное наследование от абстрактного класса, и что? Ты точно так же можешь сделать
S>И обломишься на приведении myСlass к IUnknown, хотя все методы будешь обязан реализовать. Делов-то.
Но при этом мы же не будем настаивать, что IMyInterface — это не IUnknown и к IUnknown никакого отношения не имеет
Здравствуйте, Mamut, Вы писали: M>Но при этом мы же не будем настаивать, что IMyInterface — это не IUnknown и к IUnknown никакого отношения не имеет
Ну почему же. Компилятор будет со страшной силой настаивать, что IMyInterface не имеет никакого отношения к IUnknown. Для того и сделан private, чтобы дети могли скрывать своих родителей. Я не вполне уверен, что есть надежный способ зафорсить приведение не рискуя нарваться на проход по памяти — с множественным наследованием вроде были какие-то хитрости насчет реинтерпрет_каст, но это я просто плюсы очень плохо знаю.
К слову, в остальных местах схема наследования в Delphi вполне последовательна. В частности, понизить уровень видимости унаследованного мембера нельзя, в отличие от плюсов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, squid, Вы писали:
H>>>>> ...CodeGear сообщает о намерениях вести разработки для гетерогенных платформ (пойдем на Linux, MacOS?)
S>>>>они бы хидеры из Windows SDK хоть перевели на Delphi...
H>>>Это давно не проблема... У джедаев давно есть полный комплект (JWA), есть конверторы C2Pas.
S>>простой пример — DirectShow. Видел 3 варианта, во всех куча багов и нет Вистовских фич вроде EVR в нормальном виде.
H>DSPack смотрел? Не знаю, как там на счет Вистовых плюшек, но хидеры DirectShow там есть.
да. крайне бажный и несовременный. временами постю фиксы на их форуме.
H> В крайнем случае, можно найти подходящий конвертор.
линк?
S>>начнешь плотно работать — видно сколь криво это сделано. а чтото более бажное и громоздкое чем JVCL вообще сложно представить.
H>JWA <> JVCL.
Здравствуйте, Sinclair, Вы писали:
S>Стековая ориентированность IL позволяет во-первых проводить дешевую верификацию кода,
Я бы не сказал что наличие goto способствует скорости, простоте и надежности верификации кода.
S>а во-вторых генерировать достаточно эффективный целевой код на современных архитектурах.
Этому стековая модель ВМ тоже не помогает.
В любом случае funarg problem в C# появилась еще во второй версии и исчезать не соберается.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, gandjustas, Вы писали:
M>>>Внимательно смотри отличие: M>>>Java — поддержка Юникода нативно M>>>.NET — поддержка Юникода нативно M>>>Qt — поддержка Юникода нативно M>>>Delphi- а вот есть сторонние компоненты...
H>>Главное, решение-то есть. Да и язык сей факт ни как не характеризует. G>Зато платформу очень даже характеризует.
Это VCL, чтоль, платформа? Не смеши меня. Никогда амбиций "платформы" у VCL небыло, ибо слишком она мала для платформы. Изначальный посыл я ведь уже озвучивал: немаленькое ядро + компонентная модель. Сторонние компоненты всегда входили (и входят) в поставку Delphi (Indy, QuickReport/RaveReport, Intraweb).
Здравствуйте, gandjustas, Вы писали:
H>>Нет, он не является совместимым с IUnknown т.к. IUnknown не продекларирован в списке реализуемых интерфейсов и реализуешь ты методы не IUnknown, а MyInterface. Я это повторил уже раз десять.
G>Поздравляю, ты стодвадцатьпервый раз показал кривость делфи. Хватит уже, все поняли что использование интерфейсов в делфи — огромные грабли. G>Слава богу в других языках такого бреда нет.
Ты в очередной раз доказываешь свое непонимание Только и всего.
Здравствуйте, gandjustas, Вы писали:
H>>И еще раз напишу, чтоб ты понял: Наследование, инкапсуляция и полиморфизм, вот фундамент ООП. Интерфейсы, да приятная штука снимающая зависимости кода, не более того. G>Интерфейсы не имеют отношения к наследованию и полиморфизму?
Иметь отношение и являться фундаментальным, есть разница?
Здравствуйте, AndrewJD, Вы писали:
AJD>>>>>Думаю, с custom маршалером можно будет передать без проблем.
AJD>>>Он будет COM-совместимым . Ты путаешь бинарную COM совместимость с OLE Automation. Да, стандартный OLE automation маршалер работать не будет, ну и что с того?
H>>А про бинарную совместимость ни кто и не спорил
AJD>
AJD>Да. Только после этого называть такой интерфейс COM-совместимым, это все равно, что назвать танк летающим только потому, что он в транспортном самолете находится. (c)hattab
AJD>А эту фразу как понимать?
Поясняю. Про бинарную совместимость я говорил еще в самом начале разговора. Под COM-совместимостью я не имею ввиду бинарную (ибо об этом уже было сказано), а говорю о совместимости с зоопарком технологических надстроек над моделью COM. Только в таком контексте.
Здравствуйте, Mamut, Вы писали:
H>>MyInterface расширяется декларацией IUnknown. MyInterface можно приводить к IUnknown. Это понятно?
H>>Жаль, что ты так и не понял... Реализуешь ты тут только MyInterface полученый путем расширения декларации от IUnknown.
M>Так кто кого расширяет?
Декларация IMyInterface расширяется декларацией IUnknown.
M>Давай еще раз, ок?
M>
Здравствуйте, Mamut, Вы писали:
H>>>> Есть сторонние компоненты, тот же TNT, с поддержкой юникода. Юникод в VCL будет в Тибуроне (Delphi 2008).
M>>>Внимательно смотри отличие: M>>>Java — поддержка Юникода нативно M>>>.NET — поддержка Юникода нативно M>>>Qt — поддержка Юникода нативно M>>>Delphi- а вот есть сторонние компоненты...
H>>Главное, решение-то есть.
M>Что будем делать, когда стоит ограничение на использование сторонних компонентов?
Заказчик с такими претензиями пойдет туда, где солнце не светит (ибо это обостренный дибилизм в тяжелой форме) Для кого, спрашивается существует рынок компонентов/библиотек? Единственное требование к сторонним библиотеками -- это наличие исходников.
H>>Да и язык сей факт ни как не характеризует.
M>Характеризуют и язык и платформу, как устаревшую и не соответствующую современным требованиям
Развей (от развивать) мысль насчет языка, а то я что-то не уловил...
Здравствуйте, squid, Вы писали:
H>>>>>> ...CodeGear сообщает о намерениях вести разработки для гетерогенных платформ (пойдем на Linux, MacOS?)
S>>>>>они бы хидеры из Windows SDK хоть перевели на Delphi...
H>>>>Это давно не проблема... У джедаев давно есть полный комплект (JWA), есть конверторы C2Pas.
S>>>простой пример — DirectShow. Видел 3 варианта, во всех куча багов и нет Вистовских фич вроде EVR в нормальном виде.
H>>DSPack смотрел? Не знаю, как там на счет Вистовых плюшек, но хидеры DirectShow там есть.
S>да. крайне бажный и несовременный. временами постю фиксы на их форуме.
Ну, со всеми бывает
H>> В крайнем случае, можно найти подходящий конвертор.
S>линк?
Ой, я так давно этим пользовался (помню, что конвертор был от мужика в шляпе, dr.Bob'а)... Ну, вот, что первым попалось. Недавно на delphiplus.org, что-то аналогичное проскакивало в новостях.
Re[18]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
M>>Что будем делать, когда стоит ограничение на использование сторонних компонентов? H>Заказчик с такими претензиями пойдет туда, где солнце не светит (ибо это обостренный дибилизм в тяжелой форме) Для кого, спрашивается существует рынок компонентов/библиотек? Единственное требование к сторонним библиотеками -- это наличие исходников.
Рынок существет как раз потому что стнадартная библиотека не покрывает необходимости разработки.
А требование использования только стандартных компонент вполне часто встречается.
Короче устарел твой делфи. После выхода версии 2008 года можно будет подумать.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Нет, он не является совместимым с IUnknown т.к. IUnknown не продекларирован в списке реализуемых интерфейсов и реализуешь ты методы не IUnknown, а MyInterface. Я это повторил уже раз десять.
G>>Поздравляю, ты стодвадцатьпервый раз показал кривость делфи. Хватит уже, все поняли что использование интерфейсов в делфи — огромные грабли. G>>Слава богу в других языках такого бреда нет.
H>Ты в очередной раз доказываешь свое непонимание Только и всего.
Я-то очень хорошо понимаю, а ты — нет. Тебе не с чем сравнивать
Здравствуйте, iyura, Вы писали:
I>Вот не помню точно, но в фортране >= это Greate Or Equal, т.е. GOE (три знака точно, но могу и ошибаться)
Если быть точным, в Фортране операторы сравнения состояли из 4-х символов. .LT., .EQ., .GE. и т. д. Точки были частью оператора. Набивать на перфокартах было не очень удобно. А потому в Фортране часто использовали арифметический IF.
I>Но речь-то не о фортране (дедушка живее всех живых )
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>И еще раз напишу, чтоб ты понял: Наследование, инкапсуляция и полиморфизм, вот фундамент ООП. Интерфейсы, да приятная штука снимающая зависимости кода, не более того. G>>Интерфейсы не имеют отношения к наследованию и полиморфизму?
H>Иметь отношение и являться фундаментальным, есть разница?
Это словоблудие. Таким же образом классы "не являются фундаментом ООП".
Классы и интерфейсы являются реализацией принципов ООП.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, squid, Вы писали:
H>>>>>>> ...CodeGear сообщает о намерениях вести разработки для гетерогенных платформ (пойдем на Linux, MacOS?)
S>>>>>>они бы хидеры из Windows SDK хоть перевели на Delphi...
H>>>>>Это давно не проблема... У джедаев давно есть полный комплект (JWA), есть конверторы C2Pas.
S>>>>простой пример — DirectShow. Видел 3 варианта, во всех куча багов и нет Вистовских фич вроде EVR в нормальном виде.
H>>>DSPack смотрел? Не знаю, как там на счет Вистовых плюшек, но хидеры DirectShow там есть.
S>>да. крайне бажный и несовременный. временами постю фиксы на их форуме.
H>Ну, со всеми бывает
и в итоге — нужны ОФИЦИАЛЬНЫЕ хидеры. ПОДДЕРЖИВАЕМЫЕ! а иначе — фтопку!
H>>> В крайнем случае, можно найти подходящий конвертор.
S>>линк?
H>Ой, я так давно этим пользовался (помню, что конвертор был от мужика в шляпе, dr.Bob'а)... Ну, вот, что первым попалось. Недавно на delphiplus.org, что-то аналогичное проскакивало в новостях.
спасибо, гляну. но если брать сложные вещи вроде GDI+ он точно сольет. там моск нужен. а Борланду пофек на наши нужны. как обычно впрочем.
Здравствуйте, WolfHound, Вы писали: WH>Я бы не сказал что наличие goto способствует скорости, простоте и надежности верификации кода.
Он там ограниченный
WH>В любом случае funarg problem в C# появилась еще во второй версии и исчезать не соберается.
Дай ссылку на описание этой проблемы, чтоб я впечатлился на досуге.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: наши менеджеры памяти самые менеджеристые менеджеры
H>>>Главное, решение-то есть.
M>>Что будем делать, когда стоит ограничение на использование сторонних компонентов?
H>Заказчик с такими претензиями пойдет туда, где солнце не светит (ибо это обостренный дибилизм в тяжелой форме) Для кого, спрашивается существует рынок компонентов/библиотек? Единственное требование к сторонним библиотеками -- это наличие исходников.
Есть, например, гос. заказы, где существует строгое ограничение на использование сторонних компонент (это, конечно, не про Россию, но все же)
H>>>MyInterface расширяется декларацией IUnknown. MyInterface можно приводить к IUnknown. Это понятно?
H>>>Жаль, что ты так и не понял... Реализуешь ты тут только MyInterface полученый путем расширения декларации от IUnknown.
M>>Так кто кого расширяет?
H>Декларация IMyInterface расширяется декларацией IUnknown.
Здравствуйте, Mamut, Вы писали: M>Кстати, смысла такого кода не понимаю
Теперь уже мало кто понимает. Это побочная ветвь развития языков программирования — всякие штуки, которые казались крутыми в начале девяностых, оказались малопригодными на практике.
Ну вот как перегрузка операторов в C++ по отдельности: когда можно сделать так, что (a+=1) !== (a = a + 1). Спрашивается, нахрена?
Или отсутствие явной поддержки интерфейсов, и использование вместо этого абстрактных классов.
Или умение задавать тело для pure virtual method.
Сейчас ведущие языководы придерживаются мнения, что вместо могучих инструментов, побочные возможности которых пригодны для построения полезных эффектов, лучше давать программистам менее мощные, но удобные инструменты, у которых полезные эффекты являются основным назначением.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
WH>>Я бы не сказал что наличие goto способствует скорости, простоте и надежности верификации кода. S>Он там ограниченный
Я в курсе.
В любом случае полное его отсутствие сделало бы все проще.
Здравствуйте, WolfHound, Вы писали: WH>Первая ссылка http://en.wikipedia.org/wiki/Funarg_problem
Спасибо. Непонятно, чем дотнетовское решение так уж узлобляет funarg problem.
В статье написано, что очевидное решение — размещать "стек фреймы" в хипе, а не в стеке.
Это понижает производительность, поэтому умные компиляторы типа анализируют программу, и если нет upwards funarg problem, то оставляют фрейм стека на стеке.
На первый взгляд, шарп делает именно это: при конструировании замыканий захваченные переменные переезжают из стека в хип.
Не представляю, чем бы переписывание CLR смогло бы помочь решению funarg problem.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>На первый взгляд, шарп делает именно это: при конструировании замыканий захваченные переменные переезжают из стека в хип.
Именно это он и делает.
Другое дело что по уму этим должен заниматься не компилятор шарпа, а JIT.
Дабы компиляторы не изобретали эту оптимизацию каждый раз.
S>Не представляю, чем бы переписывание CLR смогло бы помочь решению funarg problem.
А где я говорил что поможет при решении funarg problem?
Другое дело что это может помочь сделать болие правильные корутины вместо костыля по имени yield return
Хотя чтоб решить этот вопрос совсем капитально и за компанию выкинуть на свалку костыль IDisposable нужно конкретно надругаться над системой типов.
Я сечас думаю несколько вариантов.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
S>Ну почему же. Компилятор будет со страшной силой настаивать, что IMyInterface не имеет никакого отношения к IUnknown. Для того и сделан private, чтобы дети могли скрывать своих родителей. Я не вполне уверен, что есть надежный способ зафорсить приведение не рискуя нарваться на проход по памяти —
Можно (сюрприз) сишным кастом.
S>с множественным наследованием вроде были какие-то хитрости насчет реинтерпрет_каст, но это я просто плюсы очень плохо знаю.
reinterpret_cast просто тупо говорит о том что нужно сменить тип и ничего больше не делать. И ему начхать на последствия.
Полезен этот каст разве что при реализации чегото совсем низкоуровневого.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
S>Сейчас ведущие языководы придерживаются мнения, что вместо могучих инструментов, побочные возможности которых пригодны для построения полезных эффектов, лучше давать программистам менее мощные, но удобные инструменты, у которых полезные эффекты являются основным назначением.
Ага. И потом у этих собаководов получаются генерики .NET... нука реализуй Point3D<T> где T любой тип включая int, float,... и пользовательские типы.
Что? Не можешь?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, OCTAGRAM, Вы писали:
OCT>К слову о веб, там не только reflection, там и call/cc бы ещё
У call/cc и его менее кровавого собрата shift/reset есть один фатальный недостаток: Они полностью уничтожают возможность анализа потока исполнения. Те совсем.
И как следствие ни о какой автоматической детерминированной финализации в их присутствии говорить не приходится.
Даже костыль типа IDisposable/using не сделать.
Про мелочи типа тормозного спагетти стека я вобще молчу.
Таким образом приходим к выводу что если нам таки нужна (а на практике она очень нужна) автоматическая детерминированная финализация то на континюэшены придется забить.
Впрочем корутин и исключений вполне достаточно для подавляющего большинства практических задач.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, gandjustas, Вы писали:
M>>>Что будем делать, когда стоит ограничение на использование сторонних компонентов? H>>Заказчик с такими претензиями пойдет туда, где солнце не светит (ибо это обостренный дибилизм в тяжелой форме) Для кого, спрашивается существует рынок компонентов/библиотек? Единственное требование к сторонним библиотеками -- это наличие исходников.
G>Рынок существет как раз потому что стнадартная библиотека не покрывает необходимости разработки.
Да ни одна библиотека не в состоянии покрыть все потребности...
G>А требование использования только стандартных компонент вполне часто встречается.
Статистика есть, или это очередное бла-бла-бла?
G>Короче устарел твой делфи. После выхода версии 2008 года можно будет подумать.
А что, если контролы получат Юникод, это значит уже модерн попер да?
Здравствуйте, gandjustas, Вы писали:
H>>>>Нет, он не является совместимым с IUnknown т.к. IUnknown не продекларирован в списке реализуемых интерфейсов и реализуешь ты методы не IUnknown, а MyInterface. Я это повторил уже раз десять.
G>>>Поздравляю, ты стодвадцатьпервый раз показал кривость делфи. Хватит уже, все поняли что использование интерфейсов в делфи — огромные грабли. G>>>Слава богу в других языках такого бреда нет.
H>>Ты в очередной раз доказываешь свое непонимание Только и всего.
G>Я-то очень хорошо понимаю, а ты — нет. Тебе не с чем сравнивать
Здравствуйте, gandjustas, Вы писали:
H>>>>И еще раз напишу, чтоб ты понял: Наследование, инкапсуляция и полиморфизм, вот фундамент ООП. Интерфейсы, да приятная штука снимающая зависимости кода, не более того. G>>>Интерфейсы не имеют отношения к наследованию и полиморфизму?
H>>Иметь отношение и являться фундаментальным, есть разница? G>Это словоблудие. Таким же образом классы "не являются фундаментом ООП". G>Классы и интерфейсы являются реализацией принципов ООП.
Классы, и только они, являют собой реализацию фундаментальных принципов (давай еще свойства выдели отдельно ). Если ты разницы не видишь, это не моя проблема.
Здравствуйте, squid, Вы писали:
S>>>>>простой пример — DirectShow. Видел 3 варианта, во всех куча багов и нет Вистовских фич вроде EVR в нормальном виде.
H>>>>DSPack смотрел? Не знаю, как там на счет Вистовых плюшек, но хидеры DirectShow там есть.
S>>>да. крайне бажный и несовременный. временами постю фиксы на их форуме.
H>>Ну, со всеми бывает
S>и в итоге — нужны ОФИЦИАЛЬНЫЕ хидеры. ПОДДЕРЖИВАЕМЫЕ! а иначе — фтопку!
Кому нужны? Одной десятой процента программирующих на ObjectPascal? Нужно же понимать, на что нацелен инструмент... Вот с выходом новых версий переориентируют его немного (а ведь процесс уже пошел), и кто знает, может и будут официальные хидеры (а может и не будет ).
H>>>> В крайнем случае, можно найти подходящий конвертор.
S>>>линк?
H>>Ой, я так давно этим пользовался (помню, что конвертор был от мужика в шляпе, dr.Bob'а)... Ну, вот, что первым попалось. Недавно на delphiplus.org, что-то аналогичное проскакивало в новостях.
S>спасибо, гляну. но если брать сложные вещи вроде GDI+ он точно сольет. там моск нужен. а Борланду пофек на наши нужны. как обычно впрочем.
Разумеется, автоматический конвертор не может обеспечить 100% идейно правильный перевод, но все же лучше чем ничего. Для GDI+ у тех же прогдигов есть классовые обертки, вполне работоспособные (а лучше выкинуть GDI+, а вместо него использовать GR32 + GraphicsEx).
Re[19]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Mamut, Вы писали:
H>>>>Главное, решение-то есть.
M>>>Что будем делать, когда стоит ограничение на использование сторонних компонентов?
H>>Заказчик с такими претензиями пойдет туда, где солнце не светит (ибо это обостренный дибилизм в тяжелой форме) Для кого, спрашивается существует рынок компонентов/библиотек? Единственное требование к сторонним библиотеками -- это наличие исходников.
M>Есть, например, гос. заказы, где существует строгое ограничение на использование сторонних компонент (это, конечно, не про Россию, но все же)
Много чего вообще есть... Есть, например, запрет на использование MS Trident (кажется так оно называется), ибо внутренняя секьюрити не позволяет. Будешь лисапед писать? Удачи.
Здравствуйте, Mamut, Вы писали:
H>>>>MyInterface расширяется декларацией IUnknown. MyInterface можно приводить к IUnknown. Это понятно?
H>>>>Жаль, что ты так и не понял... Реализуешь ты тут только MyInterface полученый путем расширения декларации от IUnknown.
M>>>Так кто кого расширяет?
H>>Декларация IMyInterface расширяется декларацией IUnknown.
M>То есть IUnknown никуда не девается?
M>Или дай свое определение понятия расширяется
MyInterface будет содержать декларации методов от IUnknown (но эти декларации будут его декларациями), плюс свои собственные. Мамут, тебе не надоело? Я уже сто раз это написал...
M>>>Давай еще раз, ок?
M>>>
M>>>Какие классы обязан реализовать класс MyClass?
H>>MyClass должен реализовать интерфейс MyInterface.
H>>з.ы. Это только у меня дежа вю?
M>То есть все методы MyInterface плюс все методы IUnknown?
Только методы MyInterface (имеется ввиду, что MyInterface это уже расширеная декларация). Вообще, вопрос реализации отношение имеет только ко классам. Это классу решать, какие интерфейсы он реализует. Вообще, возможен вариант, когда класс будет реализовать и IUnknown и MyInterface, но при этом реализация как-бы-общих-методов будет разной.
Re[20]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
M>>>>Что будем делать, когда стоит ограничение на использование сторонних компонентов? H>>>Заказчик с такими претензиями пойдет туда, где солнце не светит (ибо это обостренный дибилизм в тяжелой форме) Для кого, спрашивается существует рынок компонентов/библиотек? Единственное требование к сторонним библиотеками -- это наличие исходников.
G>>Рынок существет как раз потому что стнадартная библиотека не покрывает необходимости разработки. H>Да ни одна библиотека не в состоянии покрыть все потребности...
Только .NET и Java почему-то покрывает. Есть конечно некоторые нестандартные решения, о рынке говорить не приходится.
G>>А требование использования только стандартных компонент вполне часто встречается. H>Статистика есть, или это очередное бла-бла-бла?
Я работал на проекте для газпрома, было требование использования только стандартных компонент.
Пара моих знакомых пишут на делфях для военных, требование — не использовать нестандартные компоненты.
G>>Короче устарел твой делфи. После выхода версии 2008 года можно будет подумать. H>А что, если контролы получат Юникод, это значит уже модерн попер да?
Не показывай свое невежество.
Здравствуйте, hattab, Вы писали:
S>>и в итоге — нужны ОФИЦИАЛЬНЫЕ хидеры. ПОДДЕРЖИВАЕМЫЕ! а иначе — фтопку!
H>Кому нужны? Одной десятой процента программирующих на ObjectPascal? Нужно же понимать, на что нацелен инструмент... Вот с выходом новых версий переориентируют его немного (а ведь процесс уже пошел), и кто знает, может и будут официальные хидеры (а может и не будет ).
много кому нужны. Windows SDK посмотри скока народу скачали. хотя забей, ты просто фанатек. тока не линукса а дельфы.
H>>>>> В крайнем случае, можно найти подходящий конвертор.
S>>>>линк?
H>>>Ой, я так давно этим пользовался (помню, что конвертор был от мужика в шляпе, dr.Bob'а)... Ну, вот, что первым попалось. Недавно на delphiplus.org, что-то аналогичное проскакивало в новостях.
S>>спасибо, гляну. но если брать сложные вещи вроде GDI+ он точно сольет. там моск нужен. а Борланду пофек на наши нужны. как обычно впрочем.
H>Разумеется, автоматический конвертор не может обеспечить 100% идейно правильный перевод, но все же лучше чем ничего. Для GDI+ у тех же прогдигов есть классовые обертки, вполне работоспособные (а лучше выкинуть GDI+, а вместо него использовать GR32 + GraphicsEx).
вот-вот. в том виде в котором они выложены на сайт при создании ActiveX — косяк. regsvr32 при регистрации тупо виснет. опять пришлось кучу времени на эту неадекватность потратить.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[21]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, squid, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Пара моих знакомых пишут на делфях для военных...
S>ты меня только-что здорово напугал!
Не бойся, не системы наведения ракет они пишут.
Какие-то учетные программы всего лишь
Re[23]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, squid, Вы писали:
S>>Здравствуйте, gandjustas, Вы писали:
G>>>Пара моих знакомых пишут на делфях для военных...
S>>ты меня только-что здорово напугал!
G>Не бойся, не системы наведения ракет они пишут. G>Какие-то учетные программы всего лишь
успокоил
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[21]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, gandjustas, Вы писали:
M>>>>>Что будем делать, когда стоит ограничение на использование сторонних компонентов? H>>>>Заказчик с такими претензиями пойдет туда, где солнце не светит (ибо это обостренный дибилизм в тяжелой форме) Для кого, спрашивается существует рынок компонентов/библиотек? Единственное требование к сторонним библиотеками -- это наличие исходников.
G>>>Рынок существет как раз потому что стнадартная библиотека не покрывает необходимости разработки. H>>Да ни одна библиотека не в состоянии покрыть все потребности... G>Только .NET и Java почему-то покрывает. Есть конечно некоторые нестандартные решения, о рынке говорить не приходится.
Нестандартные, это не MS чтоли? Давай .Net'овское для CORBA, XML-RPC, Jabber и т.д. и т.п. От ORM'ов своих любимых откажитесь А рынок .Net компонент также существует, открой глаза (гугл тебе в помощь).
G>>>А требование использования только стандартных компонент вполне часто встречается. H>>Статистика есть, или это очередное бла-бла-бла? G>Я работал на проекте для газпрома, было требование использования только стандартных компонент.
Я знаю человека (лично не знаком), который продает XML-парсер... Написаный таки на ObjectPascal, и продает таки Газпрому (и не только ему разумеется)
G>Пара моих знакомых пишут на делфях для военных, требование — не использовать нестандартные компоненты.
Я бы тебе рассказал о своей службе, но не буду Скажу одно: таких дебильных требований, да еще для учетных задачь, не предъявлялось даже в РВСН.
Вообще этот аргумент (запрет сторонних компонентов) -- бред сивой кобылы. Еслиб речь шла о закрытых сторонних компонентах, я бы еще понял... Но, что страшного в сторонних компонентах, если они предоставлены в исходниках?
G>>>Короче устарел твой делфи. После выхода версии 2008 года можно будет подумать. H>>А что, если контролы получат Юникод, это значит уже модерн попер да? G>Не показывай свое невежество.
Не-не, ты за базар ответь. 2008 поимеет из новинок только юникод и дженерики под натив. Сие модерн? Процесс пошел?
Здравствуйте, squid, Вы писали:
S>>>и в итоге — нужны ОФИЦИАЛЬНЫЕ хидеры. ПОДДЕРЖИВАЕМЫЕ! а иначе — фтопку!
H>>Кому нужны? Одной десятой процента программирующих на ObjectPascal? Нужно же понимать, на что нацелен инструмент... Вот с выходом новых версий переориентируют его немного (а ведь процесс уже пошел), и кто знает, может и будут официальные хидеры (а может и не будет ).
S>много кому нужны. Windows SDK посмотри скока народу скачали. хотя забей, ты просто фанатек. тока не линукса а дельфы.
Вывод ты сделал неправильный. Я повторюсь, Delphi для меня не фетишь. А ты критикуешь инструмент за то, на что он никогда не был ориентирован...
H>>>>>> В крайнем случае, можно найти подходящий конвертор.
S>>>>>линк?
H>>>>Ой, я так давно этим пользовался (помню, что конвертор был от мужика в шляпе, dr.Bob'а)... Ну, вот, что первым попалось. Недавно на delphiplus.org, что-то аналогичное проскакивало в новостях.
S>>>спасибо, гляну. но если брать сложные вещи вроде GDI+ он точно сольет. там моск нужен. а Борланду пофек на наши нужны. как обычно впрочем.
H>>Разумеется, автоматический конвертор не может обеспечить 100% идейно правильный перевод, но все же лучше чем ничего. Для GDI+ у тех же прогдигов есть классовые обертки, вполне работоспособные (а лучше выкинуть GDI+, а вместо него использовать GR32 + GraphicsEx).
S>вот-вот. в том виде в котором они выложены на сайт при создании ActiveX — косяк. regsvr32 при регистрации тупо виснет. опять пришлось кучу времени на эту неадекватность потратить.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Sinclair, Вы писали:
S>>Сейчас ведущие языководы придерживаются мнения, что вместо могучих инструментов, побочные возможности которых пригодны для построения полезных эффектов, лучше давать программистам менее мощные, но удобные инструменты, у которых полезные эффекты являются основным назначением. WH>Ага. И потом у этих собаководов получаются генерики .NET... нука реализуй Point3D<T> где T любой тип включая int, float,... и пользовательские типы. WH>Что? Не можешь?
Почему не могу? Могу.
public struct Point3D<T>
{
private T x;
pricate T y;
private T z;
}
Или тебе арифметика нужна?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
H>Нестандартные, это не MS чтоли? Давай .Net'овское для CORBA, XML-RPC, Jabber и т.д. и т.п.
Ты зациклился на этих технологиях чтоли? Она нафиг не нужны для .NET.
H>От ORM'ов своих любимых откажитесь А рынок .Net компонент также существует, открой глаза (гугл тебе в помощь).
Из нестандартного используются (не очень часто) nHibernate, Spring.NET и логгеры. Компоненты сторонние есть, но рынка нет.
Можешь даже не спорить, просто ты не в теме.
H>Я знаю человека (лично не знаком), который продает XML-парсер... Написаный таки на ObjectPascal, и продает таки Газпрому (и не только ему разумеется)
Ну и пусть продает.
G>>Пара моих знакомых пишут на делфях для военных, требование — не использовать нестандартные компоненты. H>Я бы тебе рассказал о своей службе, но не буду Скажу одно: таких дебильных требований, да еще для учетных задачь, не предъявлялось даже в РВСН.
Ты уже с фактами спорить будешь?
H>Вообще этот аргумент (запрет сторонних компонентов) -- бред сивой кобылы. Еслиб речь шла о закрытых сторонних компонентах, я бы еще понял... Но, что страшного в сторонних компонентах, если они предоставлены в исходниках?
Не знаю, политикой не знаимаюсь.
H>Не-не, ты за базар ответь. 2008 поимеет из новинок только юникод и дженерики под натив. Сие модерн? Процесс пошел?
Делфи сильно отстает как ни крути.
Re[22]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, _d_m_, Вы писали: ___>Юникод модерном был лет так 8 назад.
Скажем так: игнорировать Unicode и TimeZone в 2008 — это вопиющий моветон. Примерно как спрашивать "зачем мне в языке встроенная поддержка строк?"
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, hattab, Вы писали:
S>>много кому нужны. Windows SDK посмотри скока народу скачали. хотя забей, ты просто фанатек. тока не линукса а дельфы.
H>Вывод ты сделал неправильный. Я повторюсь, Delphi для меня не фетишь. А ты критикуешь инструмент за то, на что он никогда не был ориентирован...
На возможность создания программ без ограничений как Visual C++ тот-же??? Супер. И на что тогда Delphi по твоему ориентирована?
S>>вот-вот. в том виде в котором они выложены на сайт при создании ActiveX — косяк. regsvr32 при регистрации тупо виснет. опять пришлось кучу времени на эту неадекватность потратить.
H>Давай по шагам. Я попробую воспроизвести
Создаешь обычный визуальный компонент, подключаешь юнит GDI+, юзаешь из него какую-нибудь структурку, чтобы его как-нибудь задействовать, создаешь из этого компонента ActiveX с помощью мастера. Все. Будет висеть.
Люди из progdigy на мой фикс никак положительно не отреагировали, потому что место которая я фиксил — фича а не бага
А были-бы официальные хидеры от Борланд — было-бы кому писать, кому жаловаться. А так — типичный опенсорс — кушай что дали бесплатно и не жалуйся, мы на этом не зарабатываем.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[24]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _d_m_, Вы писали: ___>>Юникод модерном был лет так 8 назад. S>Скажем так: игнорировать Unicode и TimeZone в 2008 — это вопиющий моветон. Примерно как спрашивать "зачем мне в языке встроенная поддержка строк?"
Ну теперь в этой ветке флуда ещё 66 страниц добавится
Re[20]: наши менеджеры памяти самые менеджеристые менеджеры
H>>>Заказчик с такими претензиями пойдет туда, где солнце не светит (ибо это обостренный дибилизм в тяжелой форме) Для кого, спрашивается существует рынок компонентов/библиотек? Единственное требование к сторонним библиотеками -- это наличие исходников.
M>>Есть, например, гос. заказы, где существует строгое ограничение на использование сторонних компонент (это, конечно, не про Россию, но все же)
H>Много чего вообще есть... Есть, например, запрет на использование MS Trident (кажется так оно называется), ибо внутренняя секьюрити не позволяет. Будешь лисапед писать? Удачи.
Да. Буду, если таковы условия заказчика. И писать, в частности, буду точно не надельфи, потому что неумение/нежелание добавить поддержку Юникода в полностью контролируемую тобой среду для меня поставило крест на этой технологии еще в 2003=м году
M>>>>Какие классы обязан реализовать класс MyClass?
M>>То есть все методы MyInterface плюс все методы IUnknown?
H>Только методы MyInterface (имеется ввиду, что MyInterface это уже расширеная декларация).
Если только методы MyInterface, то тогда в чем сакральный смысл записи
MyInterface : Interface(IUnknown)
если класс, реализующий MyInterface начхать хотел на методы из IUnknown?
ЗЫ. Это я не по сотому разу спрашиваю. Я пытаюсь добиться четкого и ясного ответа В чем смысл "расширять" IUnknown, если класс, реализующий MyInterface, имеет право похерить все методы IUnknown?
То есть, давай так. Вот интерфейс:
MyInterface : Interface(IUnknown)
someMethod() : AnsiString
end
Напиши, пожалуйста минимальный класс MyClass, который будет реализовывать MyInterface
Здравствуйте, gandjustas, Вы писали:
H>>Нестандартные, это не MS чтоли? Давай .Net'овское для CORBA, XML-RPC, Jabber и т.д. и т.п. G>Ты зациклился на этих технологиях чтоли? Она нафиг не нужны для .NET.
Аргумент, что надо Компрессоры, я так понимаю (GZip, BZip2 и пр.), тоже нафиг не нужны? В общем, сижу в своем болоте и квакаю в собственном хоре
H>>От ORM'ов своих любимых откажитесь А рынок .Net компонент также существует, открой глаза (гугл тебе в помощь). G>Из нестандартного используются (не очень часто) nHibernate, Spring.NET и логгеры. Компоненты сторонние есть, но рынка нет.
G>Можешь даже не спорить, просто ты не в теме.
Чья-бы корова мычала... Открой для себя гугл и посмотри на циферки и список рекламных объявлений
G>>>Пара моих знакомых пишут на делфях для военных, требование — не использовать нестандартные компоненты. H>>Я бы тебе рассказал о своей службе, но не буду Скажу одно: таких дебильных требований, да еще для учетных задачь, не предъявлялось даже в РВСН. G>Ты уже с фактами спорить будешь?
Мой личный опыт не согласуется со словами твоих товарищей (неожиданно пишущих под Delphi для вояк)
H>>Вообще этот аргумент (запрет сторонних компонентов) -- бред сивой кобылы. Еслиб речь шла о закрытых сторонних компонентах, я бы еще понял... Но, что страшного в сторонних компонентах, если они предоставлены в исходниках? G>Не знаю, политикой не знаимаюсь.
Ну ты подумай. Ты же используешь эту хрень в качестве аргумента...
H>>Не-не, ты за базар ответь. 2008 поимеет из новинок только юникод и дженерики под натив. Сие модерн? Процесс пошел? G> G>Делфи сильно отстает как ни крути.
А недавно говорил, что на 2008 можно уже посмотреть будет...
Re[23]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, _d_m_, Вы писали:
H>>Не-не, ты за базар ответь. 2008 поимеет из новинок только юникод и дженерики под натив. Сие модерн? Процесс пошел?
___>Юникод модерном был лет так 8 назад.
Ага, зашибись комментировать фразу вырвав ее из контекста (два предыдущих вопроса, один из которых ты похерил, был чистейший стеб, если ты не понял...)
Re[24]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Sinclair, Вы писали:
___>>Юникод модерном был лет так 8 назад. S>Скажем так: игнорировать Unicode и TimeZone в 2008 — это вопиющий моветон. Примерно как спрашивать "зачем мне в языке встроенная поддержка строк?"
Здравствуйте, squid, Вы писали:
S>>>много кому нужны. Windows SDK посмотри скока народу скачали. хотя забей, ты просто фанатек. тока не линукса а дельфы.
H>>Вывод ты сделал неправильный. Я повторюсь, Delphi для меня не фетишь. А ты критикуешь инструмент за то, на что он никогда не был ориентирован...
S>На возможность создания программ без ограничений как Visual C++ тот-же??? Супер. И на что тогда Delphi по твоему ориентирована?
Всем давно известна ориентированность Delphi на RAD разработку клиентских приложений для работы с БД. Это, впрочем, не означает, что ничего другого на ней сделать нельзя. По этой причине Борланд и не развивал прочие направления. Косяк Борланда? Конечно косяк и еще какой. Благо, в настоящее время (после выделения CodeGear) просматриваются тенденции именно на развитие прочих областей (в блогах CodeGear'овцев и лиц приближенных все чаще мелькает MicroSV). Посему, надежда есть
S>>>вот-вот. в том виде в котором они выложены на сайт при создании ActiveX — косяк. regsvr32 при регистрации тупо виснет. опять пришлось кучу времени на эту неадекватность потратить.
H>>Давай по шагам. Я попробую воспроизвести
S>Создаешь обычный визуальный компонент, подключаешь юнит GDI+, юзаешь из него какую-нибудь структурку, чтобы его как-нибудь задействовать, создаешь из этого компонента ActiveX с помощью мастера. Все. Будет висеть.
Проверил на шестерке -- ничего не виснет, все отлично работает. Контрол отрисовывается GDI+.
S>Люди из progdigy на мой фикс никак положительно не отреагировали, потому что место которая я фиксил — фича а не бага
Может и им воспроизвести не удалось...
S>А были-бы официальные хидеры от Борланд — было-бы кому писать, кому жаловаться. А так — типичный опенсорс — кушай что дали бесплатно и не жалуйся, мы на этом не зарабатываем.
Ну не знаю... По UIB'у они весьма отзывчивы.
Re[21]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Mamut, Вы писали:
H>>>>Заказчик с такими претензиями пойдет туда, где солнце не светит (ибо это обостренный дибилизм в тяжелой форме) Для кого, спрашивается существует рынок компонентов/библиотек? Единственное требование к сторонним библиотеками -- это наличие исходников.
M>>>Есть, например, гос. заказы, где существует строгое ограничение на использование сторонних компонент (это, конечно, не про Россию, но все же)
H>>Много чего вообще есть... Есть, например, запрет на использование MS Trident (кажется так оно называется), ибо внутренняя секьюрити не позволяет. Будешь лисапед писать? Удачи.
M>Да. Буду, если таковы условия заказчика.
Попробуй их хотя бы обосновать...
M>И писать, в частности, буду точно не надельфи, потому что неумение/нежелание добавить поддержку Юникода в полностью контролируемую тобой среду для меня поставило крест на этой технологии еще в 2003=м году
Проблема совершенно надумана Есть решение -- TNT, тебе мало? Я щас на .Net и Java крест поставлю за то, что нету у них нифига для XML-RPC/OpenGL/редактирования PDF (понимаешь маразматичность таких заявлений?)
M>>>>>Какие классы обязан реализовать класс MyClass?
M>>>То есть все методы MyInterface плюс все методы IUnknown?
H>>Только методы MyInterface (имеется ввиду, что MyInterface это уже расширеная декларация).
M>Если только методы MyInterface, то тогда в чем сакральный смысл записи M>
M>MyInterface : Interface(IUnknown)
M>
M>если класс, реализующий MyInterface начхать хотел на методы из IUnknown?
Мамут! Я для кого пояснения в скобках пишу?
M>ЗЫ. Это я не по сотому разу спрашиваю. Я пытаюсь добиться четкого и ясного ответа В чем смысл "расширять" IUnknown, если класс, реализующий MyInterface, имеет право похерить все методы IUnknown?
Расширяется не IUnknown. Расширяется MyInterface декларацией IUnknown.
M>То есть, давай так. Вот интерфейс: M>
M>Напиши, пожалуйста минимальный класс MyClass, который будет реализовывать MyInterface
Есть два варианта:
1. Реализует MyInterface (да-да, все методы -- это MyInterface).
TMyObject = Class(TObject, MyInterface)
function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
function _AddRef: Integer; stdcall;
function _Release: Integer; stdcall;
Function SomeMethod : AnsiString;
End;
2. Реализует и IUnknown (наследованием от реализуещего класса) и MyInterface.
TMyObject = Class(TInterfacedObject, MyInterface)
Function SomeMethod : AnsiString;
End;
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, squid, Вы писали:
S>>>>много кому нужны. Windows SDK посмотри скока народу скачали. хотя забей, ты просто фанатек. тока не линукса а дельфы.
H>>>Вывод ты сделал неправильный. Я повторюсь, Delphi для меня не фетишь. А ты критикуешь инструмент за то, на что он никогда не был ориентирован...
S>>На возможность создания программ без ограничений как Visual C++ тот-же??? Супер. И на что тогда Delphi по твоему ориентирована?
H>Всем давно известна ориентированность Delphi на RAD разработку клиентских приложений для работы с БД. Это, впрочем, не означает, что ничего другого на ней сделать нельзя. По этой причине Борланд и не развивал прочие направления. Косяк Борланда? Конечно косяк и еще какой. Благо, в настоящее время (после выделения CodeGear) просматриваются тенденции именно на развитие прочих областей (в блогах CodeGear'овцев и лиц приближенных все чаще мелькает MicroSV). Посему, надежда есть
чорт. а я совсем другой софт продаю. ушол вешаццо
S>>>>вот-вот. в том виде в котором они выложены на сайт при создании ActiveX — косяк. regsvr32 при регистрации тупо виснет. опять пришлось кучу времени на эту неадекватность потратить.
H>>>Давай по шагам. Я попробую воспроизвести
S>>Создаешь обычный визуальный компонент, подключаешь юнит GDI+, юзаешь из него какую-нибудь структурку, чтобы его как-нибудь задействовать, создаешь из этого компонента ActiveX с помощью мастера. Все. Будет висеть.
H>Проверил на шестерке -- ничего не виснет, все отлично работает. Контрол отрисовывается GDI+.
ActiveX? Загадка...
S>>Люди из progdigy на мой фикс никак положительно не отреагировали, потому что место которая я фиксил — фича а не бага
H>Может и им воспроизвести не удалось...
Они и не пытались. Их ActiveX вообще не волнует. Главное в Delphi работает, и, как им кажется, это правильнее.
S>>А были-бы официальные хидеры от Борланд — было-бы кому писать, кому жаловаться. А так — типичный опенсорс — кушай что дали бесплатно и не жалуйся, мы на этом не зарабатываем.
H>Ну не знаю... По UIB'у они весьма отзывчивы.
Не знаю, те же хидеры директшоу — перелопачиваешь форум и патчишь руками. В оригинальной версии правят раз в полгода.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[24]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали: H>Аргумент, что надо Компрессоры, я так понимаю (GZip, BZip2 и пр.), тоже нафиг не нужны?
gzip в .NET есть
H>В общем, сижу в своем болоте и квакаю в собственном хоре
Продолжай
H>Чья-бы корова мычала... Открой для себя гугл и посмотри на циферки и список рекламных объявлений
Ты бы сам почитал, а не циферки смотрел. Большенство компонентов — FTP и SMTP клиенты, которые при желании пишутся за час.
H>Мой личный опыт не согласуется со словами твоих товарищей (неожиданно пишущих под Delphi для вояк)
Считай тебе больше повезло.
H>Ну ты подумай. Ты же используешь эту хрень в качестве аргумента...
Эти требования не я приидумал, причин не знаю.
H>А недавно говорил, что на 2008 можно уже посмотреть будет...
Версия 2008 года еще не вышла.
Re[22]: наши менеджеры памяти самые менеджеристые менеджеры
H>>>Много чего вообще есть... Есть, например, запрет на использование MS Trident (кажется так оно называется), ибо внутренняя секьюрити не позволяет. Будешь лисапед писать? Удачи.
M>>Да. Буду, если таковы условия заказчика.
H>Попробуй их хотя бы обосновать...
Про государственные конторы тебе уже тут говорили
M>>И писать, в частности, буду точно не надельфи, потому что неумение/нежелание добавить поддержку Юникода в полностью контролируемую тобой среду для меня поставило крест на этой технологии еще в 2003=м году
H>Проблема совершенно надумана Есть решение -- TNT, тебе мало? Я щас на .Net и Java крест поставлю за то, что нету у них нифига для XML-RPC/OpenGL/редактирования PDF (понимаешь маразматичность таких заявлений?)
Юникод — это базовое требование, в отличие от XML-RPC и прочих
M>>ЗЫ. Это я не по сотому разу спрашиваю. Я пытаюсь добиться четкого и ясного ответа В чем смысл "расширять" IUnknown, если класс, реализующий MyInterface, имеет право похерить все методы IUnknown?
H>Расширяется не IUnknown. Расширяется MyInterface декларацией IUnknown.
Зачем? Что нам это дает, кроме необходимости писать дополнительный код, который все равно нигде не нжен и нигде не участвует?
M>>Напиши, пожалуйста минимальный класс MyClass, который будет реализовывать MyInterface
H>Есть два варианта:
H>1. Реализует MyInterface (да-да, все методы -- это MyInterface). H>
H> TMyObject = Class(TObject, MyInterface)
H> function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
H> function _AddRef: Integer; stdcall;
H> function _Release: Integer; stdcall;
H> Function SomeMethod : AnsiString;
H> End;
H>
Зачем мне реализовывать методы QueryInterface, _AddRef и _Release, если я их все равно в данном случае не буду использовать? Или это идеология такая — писать код ради кода? Почему я не могу написать:
MyInterface : Interface
function someMethod : AnsiString
end
MyClass : Class(TObject, MyInterface)
function someMethod : AnsiString
end
Захотели реализовать IUnknown? Пожалуйста:
MyInterface : Interface
function someMethod : AnsiString
end
MyClass : Class(TObject, MyInterface, IUnknown)
function someMethod : AnsiString
function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
function _AddRef: Integer; stdcall;
function _Release: Integer; stdcall;
end
M>Зачем мне реализовывать методы QueryInterface, _AddRef и _Release, если я их все равно в данном случае не буду использовать? Или это идеология такая — писать код ради кода? Почему я не могу написать:
M>
M>MyInterface : Interface
M> function someMethod : AnsiString
M>end
M>MyClass : Class(TObject, MyInterface)
M> function someMethod : AnsiString
M>end
M>
M>Захотели реализовать IUnknown? Пожалуйста: M>
M>MyInterface : Interface
M> function someMethod : AnsiString
M>end
M>MyClass : Class(TObject, MyInterface, IUnknown)
M> function someMethod : AnsiString
M> function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
M> function _AddRef: Integer; stdcall;
M> function _Release: Integer; stdcall;
M>end
M>
M>Зачем плодить лишние сущности?
Вы, наверное, этого нигде не видели, но вам не приходило в голову, что _AddRef, _Release и QueryInterface могут быть реализованы по разному? Или вы хотите, чтобы была какая-то реализация по-умолчанию? Ну, так для этого и есть, например, TInterfacedObject. Его реализация такая, что он само-пристреливается, когда из видимости уходит его интерфейс. А если, например, мне не нужно такое поведение, я беру и аккуратно реализую IUnknown, как мне надо и когда мне надо.
А по дефолту зачем? Для этого есть TInterfacedObject, TContainedObject и т д.
Я не сделаю открытия, если скажу, что в каждом(!) нормальном проекте есть базовые классы типа TMyImplementInterfacedObject.
Здравствуйте, int64, Вы писали:
I>Здравствуйте, Mamut, Вы писали:
M>>Зачем мне реализовывать методы QueryInterface, _AddRef и _Release, если я их все равно в данном случае не буду использовать? Или это идеология такая — писать код ради кода? Почему я не могу написать:
M>>
M>>MyInterface : Interface
M>> function someMethod : AnsiString
M>>end
M>>MyClass : Class(TObject, MyInterface)
M>> function someMethod : AnsiString
M>>end
M>>
M>>Захотели реализовать IUnknown? Пожалуйста: M>>
M>>MyInterface : Interface
M>> function someMethod : AnsiString
M>>end
M>>MyClass : Class(TObject, MyInterface, IUnknown)
M>> function someMethod : AnsiString
M>> function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
M>> function _AddRef: Integer; stdcall;
M>> function _Release: Integer; stdcall;
M>>end
M>>
M>>Зачем плодить лишние сущности?
I>Вы, наверное, этого нигде не видели, но вам не приходило в голову, что _AddRef, _Release и QueryInterface могут быть реализованы по разному? Или вы хотите, чтобы была какая-то реализация по-умолчанию?
Мне все равно, есть какая-то реализация по умолчанию или нет Я не могу поянть, зачем меня обязывают реализовывать эти функции, несмотря на то, что они имеют никакого смысла для какого-то данного объекта
I>А по дефолту зачем?
Вот и о том же Зачем, реализуя MyInterface я все равно должен (фактически) реализовать IUnknown, хотя от этого IUnknown мне ни холодно ни жарко?
Почему я не могу просто задекларировать интерфейс с методами, которые мне нужны, и не заморачивать себе голову реализацией дополнительных, никому не нужных методов?
Или.
Если я так или иначе фактически реализую интерфейс IUnknown, зачем мне дополнительно указывать, что я его реализую/не реализую? Вон они — методы из IUnknown, навязаные мне MyInterface'ом. Зачем они мне там? Так, чтобы лишнее место занимать?
Здравствуйте, squid, Вы писали:
S>>>>>много кому нужны. Windows SDK посмотри скока народу скачали. хотя забей, ты просто фанатек. тока не линукса а дельфы.
H>>>>Вывод ты сделал неправильный. Я повторюсь, Delphi для меня не фетишь. А ты критикуешь инструмент за то, на что он никогда не был ориентирован...
S>>>На возможность создания программ без ограничений как Visual C++ тот-же??? Супер. И на что тогда Delphi по твоему ориентирована?
H>>Всем давно известна ориентированность Delphi на RAD разработку клиентских приложений для работы с БД. Это, впрочем, не означает, что ничего другого на ней сделать нельзя. По этой причине Борланд и не развивал прочие направления. Косяк Борланда? Конечно косяк и еще какой. Благо, в настоящее время (после выделения CodeGear) просматриваются тенденции именно на развитие прочих областей (в блогах CodeGear'овцев и лиц приближенных все чаще мелькает MicroSV). Посему, надежда есть
S>чорт. а я совсем другой софт продаю. ушол вешаццо
Я в своей работе вообще только компилятором пользуюсь, да несколькими RTL классами (т.е. все остальное от VCL мне мало интересно), но истерик по этому поводу у меня нет
S>>>>>вот-вот. в том виде в котором они выложены на сайт при создании ActiveX — косяк. regsvr32 при регистрации тупо виснет. опять пришлось кучу времени на эту неадекватность потратить.
H>>>>Давай по шагам. Я попробую воспроизвести
S>>>Создаешь обычный визуальный компонент, подключаешь юнит GDI+, юзаешь из него какую-нибудь структурку, чтобы его как-нибудь задействовать, создаешь из этого компонента ActiveX с помощью мастера. Все. Будет висеть.
H>>Проверил на шестерке -- ничего не виснет, все отлично работает. Контрол отрисовывается GDI+.
S>ActiveX? Загадка...
Конечно ActiveX, ты же о нем говорил... Создал контрол от TCustomControl. Отрисовку сделал в GDI+. Потом сконвертил его в ActiveX контрол. Зарегистрировал (хоть средой, хоть regsvr32). Импортировал в среду. Бросил на форму. Компилирую. Запускаю. Ни каких висов нет.
S>>>Люди из progdigy на мой фикс никак положительно не отреагировали, потому что место которая я фиксил — фича а не бага
H>>Может и им воспроизвести не удалось...
S>Они и не пытались. Их ActiveX вообще не волнует. Главное в Delphi работает, и, как им кажется, это правильнее.
Как оказалось, оно и в ActiveX работает
S>>>А были-бы официальные хидеры от Борланд — было-бы кому писать, кому жаловаться. А так — типичный опенсорс — кушай что дали бесплатно и не жалуйся, мы на этом не зарабатываем.
H>>Ну не знаю... По UIB'у они весьма отзывчивы.
S>Не знаю, те же хидеры директшоу — перелопачиваешь форум и патчишь руками. В оригинальной версии правят раз в полгода.
Судя по changes.txt, обновляют они ее чуть не каждый месяц...
Re[25]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, gandjustas, Вы писали:
H>>Здравствуйте, gandjustas, Вы писали: H>>Аргумент, что надо Компрессоры, я так понимаю (GZip, BZip2 и пр.), тоже нафиг не нужны? G>gzip в .NET есть
Ну надо же Ладно, кончай придуриваться. Согласись, что был не прав
H>>В общем, сижу в своем болоте и квакаю в собственном хоре G>Продолжай
Посмотри на свой любимый Paint.Net, в окошке About. Три сторонних библиотеки заюзано для такого скромненького проекта. Кстати, эта гхм... хранит MRU миниатюры в реестре, да еще и в виде строки base64
H>>Чья-бы корова мычала... Открой для себя гугл и посмотри на циферки и список рекламных объявлений G>Ты бы сам почитал, а не циферки смотрел. Большенство компонентов — FTP и SMTP клиенты, которые при желании пишутся за час.
У тебя видимо гугль другой Куча компонентов, графики, гриды, всевозможные контролы... А сроки твои вообще умиляют...
H>>Мой личный опыт не согласуется со словами твоих товарищей (неожиданно пишущих под Delphi для вояк) G>Считай тебе больше повезло.
H>>Ну ты подумай. Ты же используешь эту хрень в качестве аргумента... G>Эти требования не я приидумал, причин не знаю.
Думается мне, что именно ты их и придумал...
H>>А недавно говорил, что на 2008 можно уже посмотреть будет... G>Версия 2008 года еще не вышла.
Ты в контексте разговора попробуй ответить. После добавления юникода в гуй и дженериков в язык, будет модерн?
Re[23]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Mamut, Вы писали:
H>>>>Много чего вообще есть... Есть, например, запрет на использование MS Trident (кажется так оно называется), ибо внутренняя секьюрити не позволяет. Будешь лисапед писать? Удачи.
M>>>Да. Буду, если таковы условия заказчика.
H>>Попробуй их хотя бы обосновать...
M>Про государственные конторы тебе уже тут говорили
Да мне тут и про вояк говорили... Вот только говорители даже обосновать такие требования не могут
M>>>И писать, в частности, буду точно не надельфи, потому что неумение/нежелание добавить поддержку Юникода в полностью контролируемую тобой среду для меня поставило крест на этой технологии еще в 2003=м году
H>>Проблема совершенно надумана Есть решение -- TNT, тебе мало? Я щас на .Net и Java крест поставлю за то, что нету у них нифига для XML-RPC/OpenGL/редактирования PDF (понимаешь маразматичность таких заявлений?)
M>Юникод — это базовое требование, в отличие от XML-RPC и прочих
Что значит базовое? В языке оно есть очень давно. В гуй-библиотеке не поддерживается пока. Неприятный факт? Конечно неприятный. Но для кого? Для корпоративной системы его наличие или отсутствие не упирается ни в одну точку (а Delphi на что ориентирована?). А тем кому уперлось уже сказали про TNT.
Здравствуйте, Mamut, Вы писали:
M>>>ЗЫ. Это я не по сотому разу спрашиваю. Я пытаюсь добиться четкого и ясного ответа В чем смысл "расширять" IUnknown, если класс, реализующий MyInterface, имеет право похерить все методы IUnknown?
H>>Расширяется не IUnknown. Расширяется MyInterface декларацией IUnknown.
M>Зачем? Что нам это дает, кроме необходимости писать дополнительный код, который все равно нигде не нжен и нигде не участвует?
Что значит зачем? Правило языка. Любой интерфейс, если не указано иное, наследуется (но наследование осуществляется расширением декларации) от IInterface.
M>>>То есть, давай так. Вот интерфейс: M>>>
M>>>Напиши, пожалуйста минимальный класс MyClass, который будет реализовывать MyInterface
H>>Есть два варианта:
H>>1. Реализует MyInterface (да-да, все методы -- это MyInterface). H>>
H>> TMyObject = Class(TObject, MyInterface)
H>> function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
H>> function _AddRef: Integer; stdcall;
H>> function _Release: Integer; stdcall;
H>> Function SomeMethod : AnsiString;
H>> End;
H>>
M>Зачем мне реализовывать методы QueryInterface, _AddRef и _Release, если я их все равно в данном случае не буду использовать? Или это идеология такая — писать код ради кода? Почему я не могу написать:
Ты можешь и не использовать, а вот компилятор использует, ссылки считает да интерфейсы получает...
M>
M>MyInterface : Interface
M> function someMethod : AnsiString
M>end
M>MyClass : Class(TObject, MyInterface)
M> function someMethod : AnsiString
M>end
M>
Можешь написать и так, только наследуйся от TInterfacedObject.
M>Захотели реализовать IUnknown? Пожалуйста: M>
M>MyInterface : Interface
M> function someMethod : AnsiString
M>end
M>MyClass : Class(TObject, MyInterface, IUnknown)
M> function someMethod : AnsiString
M> function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
M> function _AddRef: Integer; stdcall;
M> function _Release: Integer; stdcall;
M>end
M>
M>Зачем плодить лишние сущности?
Это ты сейчас предлагаешь писать лишнее Наследуйся от TInterfacedObject и всех делов.
Здравствуйте, Mamut, Вы писали:
M>>>Зачем мне реализовывать методы QueryInterface, _AddRef и _Release, если я их все равно в данном случае не буду использовать? Или это идеология такая — писать код ради кода? Почему я не могу написать:
M>>>
M>>>MyInterface : Interface
M>>> function someMethod : AnsiString
M>>>end
M>>>MyClass : Class(TObject, MyInterface)
M>>> function someMethod : AnsiString
M>>>end
M>>>
M>>>MyInterface : Interface
M>>> function someMethod : AnsiString
M>>>end
M>>>MyClass : Class(TObject, MyInterface, IUnknown)
M>>> function someMethod : AnsiString
M>>> function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
M>>> function _AddRef: Integer; stdcall;
M>>> function _Release: Integer; stdcall;
M>>>end
M>>>
M>>>Зачем плодить лишние сущности?
I>>Вы, наверное, этого нигде не видели, но вам не приходило в голову, что _AddRef, _Release и QueryInterface могут быть реализованы по разному? Или вы хотите, чтобы была какая-то реализация по-умолчанию?
M>Мне все равно, есть какая-то реализация по умолчанию или нет Я не могу поянть, зачем меня обязывают реализовывать эти функции, несмотря на то, что они имеют никакого смысла для какого-то данного объекта
А говорил, что ObjectPascal знаешь Эти методы нужны компилятору, чтоб он мог ссылки подсчитывать автоматически. К тому же, тебя никто не обязывает их реализовывать, наследуйся от TInterfacedObject.
I>>А по дефолту зачем?
M>Вот и о том же Зачем, реализуя MyInterface я все равно должен (фактически) реализовать IUnknown, хотя от этого IUnknown мне ни холодно ни жарко?
Ты так и не можешь отделить декларацию от реализации... Мамут, трудно с тобой
M>Почему я не могу просто задекларировать интерфейс с методами, которые мне нужны, и не заморачивать себе голову реализацией дополнительных, никому не нужных методов?
M>Или.
M>Если я так или иначе фактически реализую интерфейс IUnknown, зачем мне дополнительно указывать, что я его реализую/не реализую? Вон они — методы из IUnknown, навязаные мне MyInterface'ом. Зачем они мне там? Так, чтобы лишнее место занимать?
Здравствуйте, hattab, Вы писали:
H>Как оказалось, оно и в ActiveX работает
может пофиксили...
H>Судя по changes.txt, обновляют они ее чуть не каждый месяц...
EVR и прочих вистовских вещей как небыло так и нет. хотя один чувак на форуме частичный порт выкладывал. где ты обновления узрел я не знаю. стабильных версий не видно а качать билды непонятной стабильности с CVS — глупо. последней версии 2.3.4 уже пару лет. как минимум.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
H>Ну надо же Ладно, кончай придуриваться. Согласись, что был не прав
В чем?
В делфи стандартная практика — применение набора сторонних компонентов для каждого проекта. Например где я работал стабильно применялись fast report и какие-то навороченные гриды.
В .NET такого нету. Стандартная библиотке покрывает большенство необходимостей.
H>Посмотри на свой любимый Paint.Net, в окошке About. Три сторонних библиотеки заюзано для такого скромненького проекта. Кстати, эта гхм... хранит MRU миниатюры в реестре, да еще и в виде строки base64
Напиши лучше.
H>Думается мне, что именно ты их и придумал...
Не говори чушь.
H>Ты в контексте разговора попробуй ответить. После добавления юникода в гуй и дженериков в язык, будет модерн?
Контекст разговора в том, что делфи устарел. Если в 2008 году туда включат нативную поддержку юникода он модерновым не станет.
Re[24]: наши менеджеры памяти самые менеджеристые менеджеры
M>>Про государственные конторы тебе уже тут говорили
H>Да мне тут и про вояк говорили... Вот только говорители даже обосновать такие требования не могут
Мы — исполнители. Заказчик может требовать, что хочет. Блин, я в рассылке по jQuery (Javascript!) наткнулся на вопросы, связаные с тем, что для гос. сайта был прямой запрет на использование каких-лио сторонних Javascript-компонентов.
M>>Юникод — это базовое требование, в отличие от XML-RPC и прочих
H>Что значит базовое? В языке оно есть очень давно. В гуй-библиотеке не поддерживается пока. Неприятный факт? Конечно неприятный. Но для кого? Для корпоративной системы его наличие или отсутствие не упирается ни в одну точку (а Delphi на что ориентирована?).
Угу. Особнно, если в этой системе надо поддерживать турецкий, английский и русский. Good luck, как говорится.
M>>Мне все равно, есть какая-то реализация по умолчанию или нет Я не могу поянть, зачем меня обязывают реализовывать эти функции, несмотря на то, что они имеют никакого смысла для какого-то данного объекта
H>А говорил, что ObjectPascal знаешь Эти методы нужны компилятору, чтоб он мог ссылки подсчитывать автоматически. К тому же, тебя никто не обязывает их реализовывать, наследуйся от TInterfacedObject.
То сть от COM мы все равно никуда не уходим?
I>>>А по дефолту зачем?
M>>Вот и о том же Зачем, реализуя MyInterface я все равно должен (фактически) реализовать IUnknown, хотя от этого IUnknown мне ни холодно ни жарко?
H>Ты так и не можешь отделить декларацию от реализации... Мамут, трудно с тобой
Я не понимаю, почему такую кривизну называют идеологией
H>>>Расширяется не IUnknown. Расширяется MyInterface декларацией IUnknown.
M>>Зачем? Что нам это дает, кроме необходимости писать дополнительный код, который все равно нигде не нжен и нигде не участвует?
H>Что значит зачем? Правило языка. Любой интерфейс, если не указано иное, наследуется (но наследование осуществляется расширением декларации) от IInterface.
В пятый раз прошу: обьсни мне, что ты понимаешь под словом "расширяется" и что ты понимаешь под словом "наследуется"
M>>Зачем мне реализовывать методы QueryInterface, _AddRef и _Release, если я их все равно в данном случае не буду использовать? Или это идеология такая — писать код ради кода? Почему я не могу написать:
H>Ты можешь и не использовать, а вот компилятор использует, ссылки считает да интерфейсы получает...
Тогда зачем мне явно указывать, что тот или иной объект реализует IUnknown, если мы и так его реализуем?
M>>
M>>MyInterface : Interface
M>> function someMethod : AnsiString
M>>end
M>>MyClass : Class(TObject, MyInterface)
M>> function someMethod : AnsiString
M>>end
M>>
H>Можешь написать и так, только наследуйся от TInterfacedObject.
Если. Любой. Интерфейс. Наследуется. От. IUnknown. Зачем мне явно указывать, что мы реализуем IUnknown, если мы его все равно реализуем
M>>Захотели реализовать IUnknown? Пожалуйста: M>>
M>>MyInterface : Interface
M>> function someMethod : AnsiString
M>>end
M>>MyClass : Class(TObject, MyInterface, IUnknown)
M>> function someMethod : AnsiString
M>> function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
M>> function _AddRef: Integer; stdcall;
M>> function _Release: Integer; stdcall;
M>>end
M>>
M>>Зачем плодить лишние сущности?
H>Это ты сейчас предлагаешь писать лишнее Наследуйся от TInterfacedObject и всех делов.
Зачем? Зачем мне дополнительно еще указывать то, что мы реализуем IUnknown, если мы его так или иначе реализуем?
И разве любой класс, реализующий любой интерфейс не становится автоматически COM-объектом? Если да, то тогда любой интерфейс в Дельфи является COM-совместимым
Здравствуйте, Mamut, Вы писали:
M>Зачем? Зачем мне дополнительно еще указывать то, что мы реализуем IUnknown, если мы его так или иначе реализуем?
Интересно, когда ты успел его "так или иначе" зариализовать? Когда написал: MyInterface : Interface?
M>И разве любой класс, реализующий любой интерфейс не становится автоматически COM-объектом?
С какого перепуга?
Здравствуйте, Mamut, Вы писали:
H>>Ты так и не можешь отделить декларацию от реализации... Мамут, трудно с тобой
M>Я не понимаю, почему такую кривизну называют идеологией
Заведи отдельную тему: Абстракция — идеология или кривизна?
Полагаю, мнения не очень разделятся.
Здравствуйте, squid, Вы писали:
H>>Как оказалось, оно и в ActiveX работает
S>может пофиксили...
У меня версия от 2002 года... Можешь сказать в чем заключался твой фикс, я в исходниках погляжу
H>>Судя по changes.txt, обновляют они ее чуть не каждый месяц...
S>EVR и прочих вистовских вещей как небыло так и нет. хотя один чувак на форуме частичный порт выкладывал. где ты обновления узрел я не знаю. стабильных версий не видно а качать билды непонятной стабильности с CVS — глупо. последней версии 2.3.4 уже пару лет. как минимум.
Я же написал, changes.txt. Да, 2.3.4 с 2004 года обновлений небыло, но обновлялось оно почти каждый месяц. Можешь еще здесь глянуть, хидеры аж от 2007 года.
Re[27]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, gandjustas, Вы писали:
H>>Ну надо же Ладно, кончай придуриваться. Согласись, что был не прав G>В чем?
Вот в этом:
H>Да ни одна библиотека не в состоянии покрыть все потребности...
Только .NET и Java почему-то покрывает. Есть конечно некоторые нестандартные решения, о рынке говорить не приходится.
G>В делфи стандартная практика — применение набора сторонних компонентов для каждого проекта. Например где я работал стабильно применялись fast report и какие-то навороченные гриды.
Более того, применение сторонних библиотек это вообще общепринятая практика. Повторное использование кода относится не только к собственным решениям.
G>В .NET такого нету. Стандартная библиотке покрывает большенство необходимостей.
Угу. И Девэкспрессов нету для .Net'а... В общем твое упорство говорит только об одном -- тебе не приходилось писать ничего сложнее стандартных базаморд.
H>>Посмотри на свой любимый Paint.Net, в окошке About. Три сторонних библиотеки заюзано для такого скромненького проекта. Кстати, эта гхм... хранит MRU миниатюры в реестре, да еще и в виде строки base64 G>Напиши лучше.
Мне то оно зачем? Не я это тут рекомендовал к ознакомлению...
H>>Думается мне, что именно ты их и придумал... G>Не говори чушь.
Чушь -- это твои бездоказательные и немотивированные доводы.
H>>Ты в контексте разговора попробуй ответить. После добавления юникода в гуй и дженериков в язык, будет модерн? G>Контекст разговора в том, что делфи устарел. Если в 2008 году туда включат нативную поддержку юникода он модерновым не станет.
Вот! Теперь список требований для модерна в студию, плиз
Re[25]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Mamut, Вы писали:
M>>>Про государственные конторы тебе уже тут говорили
H>>Да мне тут и про вояк говорили... Вот только говорители даже обосновать такие требования не могут
M>Мы — исполнители. Заказчик может требовать, что хочет. Блин, я в рассылке по jQuery (Javascript!) наткнулся на вопросы, связаные с тем, что для гос. сайта был прямой запрет на использование каких-лио сторонних Javascript-компонентов.
Я фигею с таких доводов... Мы исполнители... Тебе заказчик банку с вазелином покажет, капустой похрустит и...? С заказчиком нужно диалог вести и, по меньшей мере, понять причины таких требований. Не, ну если тебе нравится получать деньги за переписывание того, что уже существует... в MS прямая дорога, они вот собираются IE8 с нуля писать (точнее уже собрались и пишут).
M>>>Юникод — это базовое требование, в отличие от XML-RPC и прочих
H>>Что значит базовое? В языке оно есть очень давно. В гуй-библиотеке не поддерживается пока. Неприятный факт? Конечно неприятный. Но для кого? Для корпоративной системы его наличие или отсутствие не упирается ни в одну точку (а Delphi на что ориентирована?).
M>Угу. Особнно, если в этой системе надо поддерживать турецкий, английский и русский. Good luck, как говорится.
Хе-хе-хе. Следуя логике твоих слов, для тебя аналог MS Trident'а написать проще, чем юникод на VCL повесить (а ведь это можно сделать и без написания аналогов VCL контролам, al'a TNT) . Ню-ню.
Здравствуйте, Mamut, Вы писали:
M>>>Мне все равно, есть какая-то реализация по умолчанию или нет Я не могу поянть, зачем меня обязывают реализовывать эти функции, несмотря на то, что они имеют никакого смысла для какого-то данного объекта
H>>А говорил, что ObjectPascal знаешь Эти методы нужны компилятору, чтоб он мог ссылки подсчитывать автоматически. К тому же, тебя никто не обязывает их реализовывать, наследуйся от TInterfacedObject.
M>То сть от COM мы все равно никуда не уходим?
Бинарная совместимость с COM обеспечивается, да.
I>>>>А по дефолту зачем?
M>>>Вот и о том же Зачем, реализуя MyInterface я все равно должен (фактически) реализовать IUnknown, хотя от этого IUnknown мне ни холодно ни жарко?
H>>Ты так и не можешь отделить декларацию от реализации... Мамут, трудно с тобой
M>Я не понимаю, почему такую кривизну называют идеологией
Это ты называешь кривизной то, чего не можешь понять.
Здравствуйте, Mamut, Вы писали:
H>>>>Расширяется не IUnknown. Расширяется MyInterface декларацией IUnknown.
M>>>Зачем? Что нам это дает, кроме необходимости писать дополнительный код, который все равно нигде не нжен и нигде не участвует?
H>>Что значит зачем? Правило языка. Любой интерфейс, если не указано иное, наследуется (но наследование осуществляется расширением декларации) от IInterface.
M>В пятый раз прошу: обьсни мне, что ты понимаешь под словом "расширяется" и что ты понимаешь под словом "наследуется"
Я для кого писал:
MyInterface будет содержать декларации методов от IUnknown (но эти декларации будут его декларациями), плюс свои собственные. Мамут, тебе не надоело? Я уже сто раз это написал...
Обрати внимание на выделенное.
M>>>Зачем мне реализовывать методы QueryInterface, _AddRef и _Release, если я их все равно в данном случае не буду использовать? Или это идеология такая — писать код ради кода? Почему я не могу написать:
H>>Ты можешь и не использовать, а вот компилятор использует, ссылки считает да интерфейсы получает...
M>Тогда зачем мне явно указывать, что тот или иной объект реализует IUnknown, если мы и так его реализуем?
Что значит и так реализуем? А ты не считаешь, что MyInterface может иметь собственную реализацию этих методов? Или ты думаешь, что получив от объекта IUnknown и дернув его метод _AddRef (например) ты имеешь тот же результат, что и в случае дергания метода _AddRef от интерфейса IMyInterface полученного от того же объекта?
M>>>
M>>>MyInterface : Interface
M>>> function someMethod : AnsiString
M>>>end
M>>>MyClass : Class(TObject, MyInterface)
M>>> function someMethod : AnsiString
M>>>end
M>>>
H>>Можешь написать и так, только наследуйся от TInterfacedObject.
M>Если. Любой. Интерфейс. Наследуется. От. IUnknown. Зачем мне явно указывать, что мы реализуем IUnknown, если мы его все равно реализуем
Выше смотри.
M>>>Захотели реализовать IUnknown? Пожалуйста: M>>>
M>>>MyInterface : Interface
M>>> function someMethod : AnsiString
M>>>end
M>>>MyClass : Class(TObject, MyInterface, IUnknown)
M>>> function someMethod : AnsiString
M>>> function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
M>>> function _AddRef: Integer; stdcall;
M>>> function _Release: Integer; stdcall;
M>>>end
M>>>
M>>>Зачем плодить лишние сущности?
H>>Это ты сейчас предлагаешь писать лишнее Наследуйся от TInterfacedObject и всех делов.
M>Зачем? Зачем мне дополнительно еще указывать то, что мы реализуем IUnknown, если мы его так или иначе реализуем?
M>И разве любой класс, реализующий любой интерфейс не становится автоматически COM-объектом? Если да, то тогда любой интерфейс в Дельфи является COM-совместимым
Объекты класса реализующего IUnknown становятся COM-объектами. А вот твое утверждение на COM-совместимость интерфейсов неверно.
Re[28]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Ну надо же Ладно, кончай придуриваться. Согласись, что был не прав G>>В чем?
H>Вот в этом: H>
H>>Да ни одна библиотека не в состоянии покрыть все потребности...
H>Только .NET и Java почему-то покрывает. Есть конечно некоторые нестандартные решения, о рынке говорить не приходится.
Еще раз. Сторонние компоненты есть всегда. Просто потому что их можно писать.
Для делфи существует рынок компонент, то есть на написании компонент многие зарабатывают деньги.
Для .NET и Java такого практически нет. Почти все полезные компоненты ((N)Hibernate, Spring(.NET) и прочие) бесплатны. Хотя это даже не компоненты.
G>>В .NET такого нету. Стандартная библиотке покрывает большенство необходимостей. H>Угу. И Девэкспрессов нету для .Net'а... В общем твое упорство говорит только об одном -- тебе не приходилось писать ничего сложнее стандартных базаморд.
Я кроме работы с БД много чего писал, но сторонние компоненты практически не использовал.
H>>>Посмотри на свой любимый Paint.Net, в окошке About. Три сторонних библиотеки заюзано для такого скромненького проекта. Кстати, эта гхм... хранит MRU миниатюры в реестре, да еще и в виде строки base64 G>>Напиши лучше. H>Мне то оно зачем? Не я это тут рекомендовал к ознакомлению...
Ксатти ты хоть проччитал что за компоненты использованы в Paint.NET? Это только для работы с разными форматами файлов — аименьшая часть всего приложения.
H>Вот! Теперь список требований для модерна в студию, плиз
Перечитай топик сначала, уже все написано.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, squid, Вы писали:
H>>>Как оказалось, оно и в ActiveX работает
S>>может пофиксили...
H>У меня версия от 2002 года... Можешь сказать в чем заключался твой фикс, я в исходниках погляжу
лень сравнивать
чото с инициализацией GDI+ и отсутствием вызова шатдауна изза бага.
H>>>Судя по changes.txt, обновляют они ее чуть не каждый месяц...
S>>EVR и прочих вистовских вещей как небыло так и нет. хотя один чувак на форуме частичный порт выкладывал. где ты обновления узрел я не знаю. стабильных версий не видно а качать билды непонятной стабильности с CVS — глупо. последней версии 2.3.4 уже пару лет. как минимум.
H>Я же написал, changes.txt. Да, 2.3.4 с 2004 года обновлений небыло, но обновлялось оно почти каждый месяц.
т.е. ты согласен что 5 лет нет обновлений это нормально?? ну нет там поддержи новых фич, не отрицай.
H> Можешь еще здесь глянуть, хидеры аж от 2007 года.
лишний раз подтверждает мою позицию — хидеры ДОЛЖНЫ быть официальные.
тут спорить больше небуду, тебя не убедить
я не один новый проект на дельфе не начну как-раз из-за вечных тупняков Борладна и забивания на просьбы разработчиков.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: наши менеджеры памяти самые менеджеристые менеджеры
H>>>Да мне тут и про вояк говорили... Вот только говорители даже обосновать такие требования не могут
M>>Мы — исполнители. Заказчик может требовать, что хочет. Блин, я в рассылке по jQuery (Javascript!) наткнулся на вопросы, связаные с тем, что для гос. сайта был прямой запрет на использование каких-лио сторонних Javascript-компонентов.
H>Я фигею с таких доводов... Мы исполнители... Тебе заказчик банку с вазелином покажет, капустой похрустит и...? С заказчиком нужно диалог вести и, по меньшей мере, понять причины таких требований. Не, ну если тебе нравится получать деньги за переписывание того, что уже существует... в MS прямая дорога, они вот собираются IE8 с нуля писать (точнее уже собрались и пишут).
Рассказываю. В гос. конторах любой сторонний компонент считается дополнительным послаблением безопасности. Все. Точка. Или всесторонний code review сторонних компонентов ты из своего кармана оплачивать будешь? Ну-ну, вперед.
M>>>>Юникод — это базовое требование, в отличие от XML-RPC и прочих
H>>>Что значит базовое? В языке оно есть очень давно. В гуй-библиотеке не поддерживается пока. Неприятный факт? Конечно неприятный. Но для кого? Для корпоративной системы его наличие или отсутствие не упирается ни в одну точку (а Delphi на что ориентирована?).
M>>Угу. Особнно, если в этой системе надо поддерживать турецкий, английский и русский. Good luck, как говорится.
H>Хе-хе-хе. Следуя логике твоих слов, для тебя аналог MS Trident'а написать проще, чем юникод на VCL повесить (а ведь это можно сделать и без написания аналогов VCL контролам, al'a TNT) . Ню-ню.
Как это следует из моих слов? И что-то я не припомню стандартного легкого способа заставить VCL понимать и выводить текст на разных языках.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mamut, Вы писали:
H>>>>>Расширяется не IUnknown. Расширяется MyInterface декларацией IUnknown.
M>>>>Зачем? Что нам это дает, кроме необходимости писать дополнительный код, который все равно нигде не нжен и нигде не участвует?
H>>>Что значит зачем? Правило языка. Любой интерфейс, если не указано иное, наследуется (но наследование осуществляется расширением декларации) от IInterface.
M>>В пятый раз прошу: обьсни мне, что ты понимаешь под словом "расширяется" и что ты понимаешь под словом "наследуется"
H>Я для кого писал: H>
H>MyInterface будет содержать декларации методов от IUnknown (но эти декларации будут его декларациями), плюс свои собственные. Мамут, тебе не надоело? Я уже сто раз это написал...
H>Обрати внимание на выделенное.
И? Какой смысл? M>>Тогда зачем мне явно указывать, что тот или иной объект реализует IUnknown, если мы и так его реализуем?
H>Что значит и так реализуем? А ты не считаешь, что MyInterface может иметь собственную реализацию этих методов?
Зачем?
H> Или ты думаешь, что получив от объекта IUnknown и дернув его метод _AddRef (например) ты имеешь тот же результат, что и в случае дергания метода _AddRef от интерфейса IMyInterface полученного от того же объекта?
А что, не тот же результат? С точки зрения COM'а — абсолютно тот же
M>>Зачем? Зачем мне дополнительно еще указывать то, что мы реализуем IUnknown, если мы его так или иначе реализуем?
M>>И разве любой класс, реализующий любой интерфейс не становится автоматически COM-объектом? Если да, то тогда любой интерфейс в Дельфи является COM-совместимым
H>Объекты класса реализующего IUnknown становятся COM-объектами. А вот твое утверждение на COM-совместимость интерфейсов неверно.
Как это неверно? Любой объект, реализующий любой интерфейс в дельфи обязан стать COM-объектом. Кривизна реализации в Дельфи от этого не избавляет.
Кстати, ты так и не объяснил, что значит фраза "интерфес MyInterface расширяется интерфейсом IUnknown". Какой от этого практичский смысл
Смешные вы, ей богу, столько времени толочь воду в ступе...
По порядку:
2hattab: в .NET есть XML-RPC (и binary-RPC), к твоему сведенью, называется он WCF.
.NET Framework действительно покрывает куда более широкий круг задач в отличии от VCL — в его составе есть даже реализации современных криптографических протоколов (блочный симметричный AES Rijndael, ассиметричный RSA, хеши MD5, SHAx и т.д. и т.д.).
Microsoft прилагает реальный усилия, постоянно дополняя функциональность .NET Framework. В 1.0 не было даже managed средств для вывода звука. В 3.5 появились: O/RM, MVC для ASP и т.д. В одной из следующих версий обещали наконец стандартный IoC-контейнер.
Да что говорить, SP1 для 3.5 тянет по перечню нововведений на 4.0: http://weblogs.asp.net/scottgu/archive/2008/05/12/visual-studio-2008-and-net-framework-3-5-service-pack-1-beta.aspx
Тем не менее, использование сторонних сборок в .NET практика довольно-таки стандартная. Например, как O/RM nHibernate все еще на целую голову впереди Linq to SQL и EntityFramework. ASP MVC, хотя и развиваяется семимильными шагами, тем не менее все еще несколько уступает тому же Castle Monorail.
Другое дело, что фактически все внешние сборки во-первых: поставляются с исходниками и зачастую имеют хорошее покрытие unit-тестами (кстати, MS открыла исходные коды самого .NET Framework), во-вторых: имеют за плечами сотни и тысячи успешных проектов, что в целом значительно лучше, чем "создание самопального XML-RPC на Delphi, используя ручной подсчет ссылок для разруливания циклической зависимости, и где конфиги сами собой не пропадают, а если и пропадают, то система продолжает работать как и работала (c)hattab".
Кстати, так как я знаком с разработкой ПО для госконтор не по наслышке, уверяю, что там почти нету специалистов, которые бы имели представление о разработке ПО достаточное, чтоб запретить использование или неиспользование каких-то сторонних компонент/библиотек.
Ну и наконец об "интерфейсах" в Delphi: интерфейсы в Delphi это костыль, который был добавлен исключительно для взаимодействия с COM и для создания .NET версии Delphi. Отсюда и требование наследоваться от IUnknown: вместо приведения типов еще на этапе компиляции в тех случаях, когда это возможно, всегда вызывается QueryInterface...
Если в нормальных языках интерфейсы играют не менее значимую роль в ООП, чем классы, и являются мощным механизмом для обеспечения принципов инкапсуляции, то в Delphi использование интерфейсов носит скорее вынужденный характер и в основном в случаях, когда надо обеспечить COM-совместимость объекта.
Поэтому и программирование в Delphi имеет вид скорее процедурного с элементами ООП, а не ООП с элементами процедурного (и функционального, кстати, что становится все более и более верно для .NET языков и платформы).
Re[29]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, gandjustas, Вы писали:
H>>>>Ну надо же Ладно, кончай придуриваться. Согласись, что был не прав G>>>В чем?
H>>Вот в этом: H>>
H>>>Да ни одна библиотека не в состоянии покрыть все потребности...
H>>Только .NET и Java почему-то покрывает. Есть конечно некоторые нестандартные решения, о рынке говорить не приходится.
G>Еще раз. Сторонние компоненты есть всегда. Просто потому что их можно писать. G>Для делфи существует рынок компонент, то есть на написании компонент многие зарабатывают деньги. G>Для .NET и Java такого практически нет. Почти все полезные компоненты ((N)Hibernate, Spring(.NET) и прочие) бесплатны. Хотя это даже не компоненты.
Ты чего с очевидными вещами споришь??? Я тебе ссылку давал.
G>>>В .NET такого нету. Стандартная библиотке покрывает большенство необходимостей. H>>Угу. И Девэкспрессов нету для .Net'а... В общем твое упорство говорит только об одном -- тебе не приходилось писать ничего сложнее стандартных базаморд. G>Я кроме работы с БД много чего писал, но сторонние компоненты практически не использовал.
Ну я и говорю, что это лишь показывает "сложность" тех проектов...
H>>>>Посмотри на свой любимый Paint.Net, в окошке About. Три сторонних библиотеки заюзано для такого скромненького проекта. Кстати, эта гхм... хранит MRU миниатюры в реестре, да еще и в виде строки base64 G>>>Напиши лучше. H>>Мне то оно зачем? Не я это тут рекомендовал к ознакомлению... G>Ксатти ты хоть проччитал что за компоненты использованы в Paint.NET? Это только для работы с разными форматами файлов — аименьшая часть всего приложения.
Ну я в курсе, что его наибольшая часть это FW на моем диске Только как это отрицает факт задействования сторонних библиотек/компонентов? И еще скажи, какой изощренный мегамозг умудрился хранить PNG-миниатюры в реестре (и это, блин, при развитых средствах работы с конфигами )
H>>Вот! Теперь список требований для модерна в студию, плиз G>Перечитай топик сначала, уже все написано.
Тут кроме нападок читать нечего. От вас, господа, критики по делу как небыло так и нет, сплошь "костыль" да "костыль"
Здравствуйте, squid, Вы писали:
H>>>>Как оказалось, оно и в ActiveX работает
S>>>может пофиксили...
H>>У меня версия от 2002 года... Можешь сказать в чем заключался твой фикс, я в исходниках погляжу
S>лень сравнивать
Я так и думал
H>>>>Судя по changes.txt, обновляют они ее чуть не каждый месяц...
S>>>EVR и прочих вистовских вещей как небыло так и нет. хотя один чувак на форуме частичный порт выкладывал. где ты обновления узрел я не знаю. стабильных версий не видно а качать билды непонятной стабильности с CVS — глупо. последней версии 2.3.4 уже пару лет. как минимум.
H>>Я же написал, changes.txt. Да, 2.3.4 с 2004 года обновлений небыло, но обновлялось оно почти каждый месяц.
S>т.е. ты согласен что 5 лет нет обновлений это нормально?? ну нет там поддержи новых фич, не отрицай.
Ну да, давно не обновлялось... Очевидно, впрочем, что Борланду это было нужно еще меньше чем прогдигам...
H>> Можешь еще здесь глянуть, хидеры аж от 2007 года.
S>лишний раз подтверждает мою позицию — хидеры ДОЛЖНЫ быть официальные.
S>тут спорить больше небуду, тебя не убедить
Меня убеждать не нужно. Ты сам попробуй понять ситуацию исходя из позиционирования продукта разработчиком.
Re[27]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Mamut, Вы писали:
H>>>>Да мне тут и про вояк говорили... Вот только говорители даже обосновать такие требования не могут
M>>>Мы — исполнители. Заказчик может требовать, что хочет. Блин, я в рассылке по jQuery (Javascript!) наткнулся на вопросы, связаные с тем, что для гос. сайта был прямой запрет на использование каких-лио сторонних Javascript-компонентов.
H>>Я фигею с таких доводов... Мы исполнители... Тебе заказчик банку с вазелином покажет, капустой похрустит и...? С заказчиком нужно диалог вести и, по меньшей мере, понять причины таких требований. Не, ну если тебе нравится получать деньги за переписывание того, что уже существует... в MS прямая дорога, они вот собираются IE8 с нуля писать (точнее уже собрались и пишут).
M>Рассказываю. В гос. конторах любой сторонний компонент считается дополнительным послаблением безопасности. Все. Точка. Или всесторонний code review сторонних компонентов ты из своего кармана оплачивать будешь? Ну-ну, вперед.
Т.е. ты считаешь, что написание твоего велосипеда с последующим всесторонним тестированием, отладкой, доводкой, да еще в условиях изменяющихся требований будет стоить дешевле нежели ревью кода? Насмешил.
M>>>>>Юникод — это базовое требование, в отличие от XML-RPC и прочих
H>>>>Что значит базовое? В языке оно есть очень давно. В гуй-библиотеке не поддерживается пока. Неприятный факт? Конечно неприятный. Но для кого? Для корпоративной системы его наличие или отсутствие не упирается ни в одну точку (а Delphi на что ориентирована?).
M>>>Угу. Особнно, если в этой системе надо поддерживать турецкий, английский и русский. Good luck, как говорится.
H>>Хе-хе-хе. Следуя логике твоих слов, для тебя аналог MS Trident'а написать проще, чем юникод на VCL повесить (а ведь это можно сделать и без написания аналогов VCL контролам, al'a TNT) . Ню-ню.
M>Как это следует из моих слов?
Очень просто: ты критикуешь необходимость самостоятельного написания поддержки Юникода в VCL, но при этом тебя не пугает перспектива написания движка аля Трайдент.
M>И что-то я не припомню стандартного легкого способа заставить VCL понимать и выводить текст на разных языках.
Здравствуйте, Mamut, Вы писали:
M>>>В пятый раз прошу: обьсни мне, что ты понимаешь под словом "расширяется" и что ты понимаешь под словом "наследуется"
H>>Я для кого писал: H>>
H>>MyInterface будет содержать декларации методов от IUnknown (но эти декларации будут его декларациями), плюс свои собственные. Мамут, тебе не надоело? Я уже сто раз это написал...
H>>Обрати внимание на выделенное.
M>И? Какой смысл?
Ты безнадежен
M>>>Тогда зачем мне явно указывать, что тот или иной объект реализует IUnknown, если мы и так его реализуем?
H>>Что значит и так реализуем? А ты не считаешь, что MyInterface может иметь собственную реализацию этих методов?
M>Зачем?
За хлебом. Посмотри на исходник TComObject, может поймешь зачем...
H>> Или ты думаешь, что получив от объекта IUnknown и дернув его метод _AddRef (например) ты имеешь тот же результат, что и в случае дергания метода _AddRef от интерфейса IMyInterface полученного от того же объекта?
M>А что, не тот же результат? С точки зрения COM'а — абсолютно тот же
Зависит от реализации. Результат может отличаться.
M>>>Зачем? Зачем мне дополнительно еще указывать то, что мы реализуем IUnknown, если мы его так или иначе реализуем?
M>>>И разве любой класс, реализующий любой интерфейс не становится автоматически COM-объектом? Если да, то тогда любой интерфейс в Дельфи является COM-совместимым
H>>Объекты класса реализующего IUnknown становятся COM-объектами. А вот твое утверждение на COM-совместимость интерфейсов неверно.
M>Как это неверно? Любой объект, реализующий любой интерфейс в дельфи обязан стать COM-объектом. Кривизна реализации в Дельфи от этого не избавляет.
Что, на второй круг собрался? Мамут, я устал с тобой спорить...
Re[30]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
H>Ты чего с очевидными вещами споришь??? Я тебе ссылку давал.
Я тебе говорю: компоненты есть. Но это не рынок, это по большей части наколеночные поделки, кроме десятка серьезных фреймворков, которые пришли из Java.
Ты мне: ну смотри же, есть компоненты!
H>Ну я и говорю, что это лишь показывает "сложность" тех проектов...
В чем-то ты прав. На C# (и .NET вообще) все проекты гораздо проще, чем аналогичные на делфи.
Здравствуйте, kuj, Вы писали:
kuj>2hattab: в .NET есть XML-RPC (и binary-RPC), к твоему сведенью, называется он WCF.
WCF это не оно
kuj>.NET Framework действительно покрывает куда более широкий круг задач в отличии от VCL — в его составе есть даже реализации современных криптографических протоколов (блочный симметричный AES Rijndael, ассиметричный RSA, хеши MD5, SHAx и т.д. и т.д.).
VCL глупо сравнивать с FW, ибо VCL не есть фреймвок. С шифрами все прикольнее... Ты в курсе, что криптография в Windows намеренно ослаблена? Какой в таком случае в них смысл...
kuj>Microsoft прилагает реальный усилия, постоянно дополняя функциональность .NET Framework. В 1.0 не было даже managed средств для вывода звука. В 3.5 появились: O/RM, MVC для ASP и т.д. В одной из следующих версий обещали наконец стандартный IoC-контейнер. kuj>Да что говорить, SP1 для 3.5 тянет по перечню нововведений на 4.0: http://weblogs.asp.net/scottgu/archive/2008/05/12/visual-studio-2008-and-net-framework-3-5-service-pack-1-beta.aspx
Да я только рад этому Опухнет в конец и лопнет раньше, чем доберется до моего HDD
kuj>Тем не менее, использование сторонних сборок в .NET практика довольно-таки стандартная. Например, как O/RM nHibernate все еще на целую голову впереди Linq to SQL и EntityFramework. ASP MVC, хотя и развиваяется семимильными шагами, тем не менее все еще несколько уступает тому же Castle Monorail.
kuj>Другое дело, что фактически все внешние сборки во-первых: поставляются с исходниками и зачастую имеют хорошее покрытие unit-тестами (кстати, MS открыла исходные коды самого .NET Framework)
Наличием исходников трудно кого то удивить... У меня в сборнике (очень скромном) Delphi сурсов, 210 бесплатных библиотек и юнитов общим весом в 365 мегабайт исходного кода.
kuj>, во-вторых: имеют за плечами сотни и тысячи успешных проектов, что в целом значительно лучше, чем
Коли уж цифрами бросаешься, давай и ссылки.
kuj>"создание самопального XML-RPC на Delphi, используя ручной подсчет ссылок для разруливания циклической зависимости, и где конфиги сами собой не пропадают, а если и пропадают, то система продолжает работать как и работала (c)hattab".
Не нужно мне приписывать свою интерпретацию моих слов Если решил цитировать, цитируй до буквы.
kuj>Кстати, так как я знаком с разработкой ПО для госконтор не по наслышке, уверяю, что там почти нету специалистов, которые бы имели представление о разработке ПО достаточное, чтоб запретить использование или неиспользование каких-то сторонних компонент/библиотек.
kuj>Ну и наконец об "интерфейсах" в Delphi: интерфейсы в Delphi это костыль, который был добавлен исключительно для взаимодействия с COM и для создания .NET версии Delphi. Отсюда и требование наследоваться от IUnknown: вместо приведения типов еще на этапе компиляции в тех случаях, когда это возможно, всегда вызывается QueryInterface...
Иногда лучше жевать.
kuj>Если в нормальных языках интерфейсы играют не менее значимую роль в ООП, чем классы, и являются мощным механизмом для обеспечения принципов инкапсуляции, то в Delphi использование интерфейсов носит скорее вынужденный характер и в основном в случаях, когда надо обеспечить COM-совместимость объекта.
kuj>Поэтому и программирование в Delphi имеет вид скорее процедурного с элементами ООП, а не ООП с элементами процедурного (и функционального, кстати, что становится все более и более верно для .NET языков и платформы).
А этот бред даже комментировать не буду...
Re[28]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
M>>И что-то я не припомню стандартного легкого способа заставить VCL понимать и выводить текст на разных языках.
H>Можно обойтись класс-хелперами и перехватом API.
"Перехват API" это что еще за зверь?
Кстати, откуда информация о том, что Paint.NET хранит thumbnails в системном реестре Windows?
Здравствуйте, gandjustas, Вы писали:
H>>Ты чего с очевидными вещами споришь??? Я тебе ссылку давал. G>Я тебе говорю: компоненты есть. Но это не рынок, это по большей части наколеночные поделки, кроме десятка серьезных фреймворков, которые пришли из Java. G>Ты мне: ну смотри же, есть компоненты!
Здравствуйте, hattab, Вы писали:
kuj>>2hattab: в .NET есть XML-RPC (и binary-RPC), к твоему сведенью, называется он WCF.
H>WCF это не оно
Чегой? WCF на SOAP это именно XML-RPC.
kuj>>.NET Framework действительно покрывает куда более широкий круг задач в отличии от VCL — в его составе есть даже реализации современных криптографических протоколов (блочный симметричный AES Rijndael, ассиметричный RSA, хеши MD5, SHAx и т.д. и т.д.).
H>VCL глупо сравнивать с FW, ибо VCL не есть фреймвок.
Конечно не есть. А другого у Delphi все-равно нет.
H>С шифрами все прикольнее... Ты в курсе, что криптография в Windows намеренно ослаблена? Какой в таком случае в них смысл...
Что значит ослаблена? Давай уж конкретнее и по пунктам.
kuj>>Другое дело, что фактически все внешние сборки во-первых: поставляются с исходниками и зачастую имеют хорошее покрытие unit-тестами (кстати, MS открыла исходные коды самого .NET Framework)
H>Наличием исходников трудно кого то удивить... У меня в сборнике (очень скромном) Delphi сурсов, 210 бесплатных библиотек и юнитов общим весом в 365 мегабайт исходного кода.
365MB в исходном кодах 210 библиотек? Что-то очень слабо верится.
kuj>>, во-вторых: имеют за плечами сотни и тысячи успешных проектов, что в целом значительно лучше, чем
H>Коли уж цифрами бросаешься, давай и ссылки.
Ссылки на что тебе давать?
kuj>>"создание самопального XML-RPC на Delphi, используя ручной подсчет ссылок для разруливания циклической зависимости, и где конфиги сами собой не пропадают, а если и пропадают, то система продолжает работать как и работала (c)hattab".
H>Не нужно мне приписывать свою интерпретацию моих слов Если решил цитировать, цитируй до буквы.
А что не так? Поправь, если я что не верно сказал.
kuj>>Кстати, так как я знаком с разработкой ПО для госконтор не по наслышке, уверяю, что там почти нету специалистов, которые бы имели представление о разработке ПО достаточное, чтоб запретить использование или неиспользование каких-то сторонних компонент/библиотек.
kuj>>Ну и наконец об "интерфейсах" в Delphi: интерфейсы в Delphi это костыль, который был добавлен исключительно для взаимодействия с COM и для создания .NET версии Delphi. Отсюда и требование наследоваться от IUnknown: вместо приведения типов еще на этапе компиляции в тех случаях, когда это возможно, всегда вызывается QueryInterface...
H>Иногда лучше жевать.
Аргументировать слабо?
H>kuj>Если в нормальных языках интерфейсы играют не менее значимую роль в ООП, чем классы, и являются мощным механизмом для обеспечения принципов инкапсуляции, то в Delphi использование интерфейсов носит скорее вынужденный характер и в основном в случаях, когда надо обеспечить COM-совместимость объекта.
kuj>>Поэтому и программирование в Delphi имеет вид скорее процедурного с элементами ООП, а не ООП с элементами процедурного (и функционального, кстати, что становится все более и более верно для .NET языков и платформы).
H>А этот бред даже комментировать не буду...
Здравствуйте, squid, Вы писали:
H>>Меня убеждать не нужно. Ты сам попробуй понять ситуацию исходя из позиционирования продукта разработчиком.
S>если дельфи не позиционировать сколько-нибудь широко она окончательно помрет.
Да она уже померла... Сейчас на стадии разложения.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, kuj, Вы писали:
kuj>>Да что говорить, SP1 для 3.5 тянет по перечню нововведений на 4.0: http://weblogs.asp.net/scottgu/archive/2008/05/12/visual-studio-2008-and-net-framework-3-5-service-pack-1-beta.aspx
H>Да я только рад этому Опухнет в конец и лопнет раньше, чем доберется до моего HDD
H>Наличием исходников трудно кого то удивить... У меня в сборнике (очень скромном) Delphi сурсов, 210 бесплатных библиотек и юнитов общим весом в 365 мегабайт исходного кода.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, squid, Вы писали:
H>>>Меня убеждать не нужно. Ты сам попробуй понять ситуацию исходя из позиционирования продукта разработчиком.
S>>если дельфи не позиционировать сколько-нибудь широко она окончательно помрет.
kuj>Да она уже померла... Сейчас на стадии разложения.
ну, у меня проекту пару лет, не соскочишь уже...
Да и Delphi vs C++ для довольно простого невизуального unmanaged кода — для меня Delphi вполне разумный выбор. Был во всяком случае.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[28]: наши менеджеры памяти самые менеджеристые менеджеры
M>>Рассказываю. В гос. конторах любой сторонний компонент считается дополнительным послаблением безопасности. Все. Точка. Или всесторонний code review сторонних компонентов ты из своего кармана оплачивать будешь? Ну-ну, вперед.
H>Т.е. ты считаешь, что написание твоего велосипеда с последующим всесторонним тестированием, отладкой, доводкой, да еще в условиях изменяющихся требований будет стоить дешевле нежели ревью кода? Насмешил.
Все вопросы — к заказчику.
H>>>Хе-хе-хе. Следуя логике твоих слов, для тебя аналог MS Trident'а написать проще, чем юникод на VCL повесить (а ведь это можно сделать и без написания аналогов VCL контролам, al'a TNT) . Ню-ню.
M>>Как это следует из моих слов?
H>Очень просто: ты критикуешь необходимость самостоятельного написания поддержки Юникода в VCL, но при этом тебя не пугает перспектива написания движка аля Трайдент.
Кто говорит о необходимости переписывания Трайдента МС-овского? Он является стандартным компонентом системы. В отличие от.
M>>И что-то я не припомню стандартного легкого способа заставить VCL понимать и выводить текст на разных языках.
H>Можно обойтись класс-хелперами и перехватом API.
Какими-какими хелперами? Каким-каким перехватом?
Вот у меня есть список клиентов:
Tuğba Özay
Abdülhamîd Kılıçarslan
Сергей Иванов
Иван Сергеев
Хранятся они меня в базе данных. Для каждого имени рядом хранить еще и идентификатор языка, на котром они написаны? И так — для каждого текстового поля? А если мне надо их вывести одни списком? Чтобы рядом и Abdülhamîd и Иван оказались?
M>>>>В пятый раз прошу: обьсни мне, что ты понимаешь под словом "расширяется" и что ты понимаешь под словом "наследуется"
H>>>Я для кого писал: H>>>
H>>>MyInterface будет содержать декларации методов от IUnknown (но эти декларации будут его декларациями), плюс свои собственные. Мамут, тебе не надоело? Я уже сто раз это написал...
H>>>Обрати внимание на выделенное.
M>>И? Какой смысл?
H>Ты безнадежен
Это не я безнадежен, не надейся. У меня просто кругозор не зашорен гениальным словом "идеология"
Итак:
— MyInterface расширяется декларациями IUnknown (c) hattab
— MyInterface будет содержать декларации методов от IUnknown (но эти декларации будут его декларациями), плюс свои собственные
Это — наследование в чистом виде. Причем — наследование одного абстрактного класса от другого (да, именно абстрактного класса)
Именно поэтому объект, "реализующий" MyInterface, обязан реализовать методы всех интерфейсов-предков MyInterface.
Интерфейсы существуют в Дельфи ровно по одной причине: обеспечить легкую работу с COM'ом. Именно поэтому любой объект, реализующий любой интерфейс, является COM-объектом и обязан реализовать IUnknown. При этом необходимость явной декларации IUnknown является ничем иным, как костылем, непонятно зачем прикрученым.
Второй возможный вариант использования интерфейсов — эмуляция множественнного наследования (как это седлано в Java). Но в Дельфи вся эта множественная наследованность тупо гвоздями прибита к COM'у, поэтому польза от интерфейсов вне COM'а в Дельфи стремится к нулю.
Вопрос на засыпку: почему я в Дельфи не могу объявить интерфейс, не прибитый гвоздями к IUnknown?
Здравствуйте, kuj, Вы писали:
AXP>>Что такого трудного с вводом знака := , не понимаю ажиотажа. kuj>Ничего трудного. Просто 5 нажатий менее удобно, чем одно нажатие.
Дело привычки. У меня уже руки этот символ как макрос воспринимают
Re[29]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
M>>>И что-то я не припомню стандартного легкого способа заставить VCL понимать и выводить текст на разных языках.
H>>Можно обойтись класс-хелперами и перехватом API.
kuj>"Перехват API" это что еще за зверь?
Ты прикалываешься чтоль? В общем, смотри ответ Мамуту, я там пример приведу.
kuj>Кстати, откуда информация о том, что Paint.NET хранит thumbnails в системном реестре Windows?
Смотришь HKEY_CURRENT_USER\Software\Paint.NET и видишь MRU0Thumb, MRU1Thumb и так далее
Здравствуйте, squid, Вы писали:
S>Здравствуйте, hattab, Вы писали:
H>>Ну да, давно не обновлялось... Очевидно, впрочем, что Борланду это было нужно еще меньше чем прогдигам...
S>в том и проблема.
Странно слышать, что такая мелочь явилась проблемой... Впрочем
H>>Меня убеждать не нужно. Ты сам попробуй понять ситуацию исходя из позиционирования продукта разработчиком.
S>если дельфи не позиционировать сколько-нибудь широко она окончательно помрет.
Спорный тезис. Хотя, следует заметить, что в настоящее время намечаются определенные шаги к расширению и рынков и применений.
Здравствуйте, kuj, Вы писали:
kuj>>>2hattab: в .NET есть XML-RPC (и binary-RPC), к твоему сведенью, называется он WCF.
H>>WCF это не оно
kuj>Чегой? WCF на SOAP это именно XML-RPC.
Переведи на русский. А вообще, SOAP это не XML-RPC.
kuj>>>.NET Framework действительно покрывает куда более широкий круг задач в отличии от VCL — в его составе есть даже реализации современных криптографических протоколов (блочный симметричный AES Rijndael, ассиметричный RSA, хеши MD5, SHAx и т.д. и т.д.).
H>>VCL глупо сравнивать с FW, ибо VCL не есть фреймвок.
kuj>Конечно не есть. А другого у Delphi все-равно нет.
Вот и не нужно их сравнивать, говоря всем известные факты типа выделенного... Кто с этим спорил?
H>>С шифрами все прикольнее... Ты в курсе, что криптография в Windows намеренно ослаблена? Какой в таком случае в них смысл...
kuj>Что значит ослаблена? Давай уж конкретнее и по пунктам.
Ты не читал о применении 40 бит вместо 56 в DES (правда, я об этом тоже давненько читал)? Ты не читал о чудном генераторе случайных чисел имеющем прикольную частоту повторения? К сожалению ссылок дать не могу, не коллекционирую... Можешь на "Компьютерре" почитать статьи за авторством Киви Берд'а.
kuj>>>Другое дело, что фактически все внешние сборки во-первых: поставляются с исходниками и зачастую имеют хорошее покрытие unit-тестами (кстати, MS открыла исходные коды самого .NET Framework)
H>>Наличием исходников трудно кого то удивить... У меня в сборнике (очень скромном) Delphi сурсов, 210 бесплатных библиотек и юнитов общим весом в 365 мегабайт исходного кода. kuj>365MB в исходном кодах 210 библиотек? Что-то очень слабо верится.
Там написано "библиотек и юнитов". Больших библиотек от силы штук 10 (это на глаз), остальное соломка на всякие случаи жизненные.
kuj>>>, во-вторых: имеют за плечами сотни и тысячи успешных проектов, что в целом значительно лучше, чем
H>>Коли уж цифрами бросаешься, давай и ссылки.
kuj>Ссылки на что тебе давать?
Ну, где-то же ты почерпнул цифры эти... Ссылки на саксесс стори...
kuj>>>"создание самопального XML-RPC на Delphi, используя ручной подсчет ссылок для разруливания циклической зависимости, и где конфиги сами собой не пропадают, а если и пропадают, то система продолжает работать как и работала (c)hattab".
H>>Не нужно мне приписывать свою интерпретацию моих слов Если решил цитировать, цитируй до буквы.
kuj>А что не так? Поправь, если я что не верно сказал.
Я уже сказал что не так. Цитировать нужно конкретные фразы, еще бы неплохо и контексте разговора...
kuj>>>Кстати, так как я знаком с разработкой ПО для госконтор не по наслышке, уверяю, что там почти нету специалистов, которые бы имели представление о разработке ПО достаточное, чтоб запретить использование или неиспользование каких-то сторонних компонент/библиотек.
kuj>>>Ну и наконец об "интерфейсах" в Delphi: интерфейсы в Delphi это костыль, который был добавлен исключительно для взаимодействия с COM и для создания .NET версии Delphi. Отсюда и требование наследоваться от IUnknown: вместо приведения типов еще на этапе компиляции в тех случаях, когда это возможно, всегда вызывается QueryInterface...
H>>Иногда лучше жевать.
kuj>Аргументировать слабо?
Да что тут аргументировать? Ты читать умеешь? Я уже писал, что Delphi умеет делать приведение к интерфейсным типам без вызова QueryInterface. А твои слова показывают только уровень твоих познаний
H>>kuj>Если в нормальных языках интерфейсы играют не менее значимую роль в ООП, чем классы, и являются мощным механизмом для обеспечения принципов инкапсуляции, то в Delphi использование интерфейсов носит скорее вынужденный характер и в основном в случаях, когда надо обеспечить COM-совместимость объекта.
kuj>>>Поэтому и программирование в Delphi имеет вид скорее процедурного с элементами ООП, а не ООП с элементами процедурного (и функционального, кстати, что становится все более и более верно для .NET языков и платформы).
H>>А этот бред даже комментировать не буду...
kuj>Конечно не будешь, так как знаешь что это правда.
Я знаю, что это бред. И комментировать бред... Это бред.
Здравствуйте, gandjustas, Вы писали:
kuj>>>Да что говорить, SP1 для 3.5 тянет по перечню нововведений на 4.0: http://weblogs.asp.net/scottgu/archive/2008/05/12/visual-studio-2008-and-net-framework-3-5-service-pack-1-beta.aspx
H>>Да я только рад этому Опухнет в конец и лопнет раньше, чем доберется до моего HDD
H>>Наличием исходников трудно кого то удивить... У меня в сборнике (очень скромном) Delphi сурсов, 210 бесплатных библиотек и юнитов общим весом в 365 мегабайт исходного кода.
G>И этот человек не хочет себе ставить .NET FW.
Мне, в отличии от нетеров, не требуется за собой все это таскать
Re[30]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
M>>>>И что-то я не припомню стандартного легкого способа заставить VCL понимать и выводить текст на разных языках.
H>>>Можно обойтись класс-хелперами и перехватом API.
kuj>>"Перехват API" это что еще за зверь?
H>Ты прикалываешься чтоль? В общем, смотри ответ Мамуту, я там пример приведу.
Ты собрался перехватывать интерфейс программирования? Надо точнее выражаться — перехват API-вызовов.
kuj>>Кстати, откуда информация о том, что Paint.NET хранит thumbnails в системном реестре Windows?
H>Смотришь HKEY_CURRENT_USER\Software\Paint.NET и видишь MRU0Thumb, MRU1Thumb и так далее
Мда. Ну, как говорится, в семье не без урода.
Re[29]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Mamut, Вы писали:
M>>>Рассказываю. В гос. конторах любой сторонний компонент считается дополнительным послаблением безопасности. Все. Точка. Или всесторонний code review сторонних компонентов ты из своего кармана оплачивать будешь? Ну-ну, вперед.
H>>Т.е. ты считаешь, что написание твоего велосипеда с последующим всесторонним тестированием, отладкой, доводкой, да еще в условиях изменяющихся требований будет стоить дешевле нежели ревью кода? Насмешил.
M>Все вопросы — к заказчику.
Ха-ха-ха. Значит как только речь о ревью, так дорого. А как только выясняется, что писать велосипед еще дороже, так сразу к заказчику... Все ясно с твоей аргументацией, можешь больше не напрягаться.
H>>>>Хе-хе-хе. Следуя логике твоих слов, для тебя аналог MS Trident'а написать проще, чем юникод на VCL повесить (а ведь это можно сделать и без написания аналогов VCL контролам, al'a TNT) . Ню-ню.
M>>>Как это следует из моих слов?
H>>Очень просто: ты критикуешь необходимость самостоятельного написания поддержки Юникода в VCL, но при этом тебя не пугает перспектива написания движка аля Трайдент.
M>Кто говорит о необходимости переписывания Трайдента МС-овского? Он является стандартным компонентом системы. В отличие от.
Речь о чем была? Ты сказал о существовании требований не использовать сторонние компоненты (хотя я в это вообще слабо верю, а ты убедительных доводов не имеешь). Я сказал о реальном запрете на использование Трайдента (коий не чаcть системы, не гони. То, что его запихали в эксплорер еще ничего не значит). Ты сказал, что будешь его писать коли заказчик того хочет (ведь сторонний код использовать нельзя).
M>>>И что-то я не припомню стандартного легкого способа заставить VCL понимать и выводить текст на разных языках.
H>>Можно обойтись класс-хелперами и перехватом API.
M>Какими-какими хелперами? Каким-каким перехватом?
Я уже понял, что ты не в курсе...
M>Вот у меня есть список клиентов: M>
M>Tuğba Özay
M>Abdülhamîd Kılıçarslan
M>Сергей Иванов
M>Иван Сергеев
M>Хранятся они меня в базе данных. Для каждого имени рядом хранить еще и идентификатор языка, на котром они написаны? И так — для каждого текстового поля? А если мне надо их вывести одни списком? Чтобы рядом и Abdülhamîd и Иван оказались?
Вот тебе пример:
А вот код:
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, GenCodeHook;
type
TForm1 = class(TForm)
Label1: TLabel;
Button1: TButton;
procedure Button1Click(Sender: TObject);
end;
var
Form1: TForm1;
implementation{$R *.dfm}Type
TLabelHelper = Class Helper For TLabel
Function GetWideCaption : WideString;
Procedure SetWideCaption(Const Value : WideString);
Property Caption : WideString Read GetWideCaption Write SetWideCaption;
End;
Var
OldDrawText : function(hDC: HDC; lpString: PAnsiChar; nCount: Integer; var lpRect: TRect; uFormat: UINT): Integer; stdcall;
procedure TForm1.Button1Click(Sender: TObject);
begin
Label1.Caption := 'Tuğba Özay'#10 +
'Abdülhamîd Kılıçarslan'#10 +
'Сергей Иванов'#10 +
'Иван Сергеев';
end;
{ TLabelHelper }Function TLabelHelper.GetWideCaption : WideString;
Begin
Result := UTF8Decode(Inherited Caption);
End;
Procedure TLabelHelper.SetWideCaption(Const Value : WideString);
Begin
Inherited Caption := UTF8Encode(Value);
End;
Function NewDrawText(hDC: HDC; lpString: PAnsiChar; nCount: Integer; Var lpRect: TRect; uFormat: UINT): Integer; stdcall;
Var
Caption : WideString;
Begin
Caption := UTF8Decode(lpString);
Result := DrawTextW(hDC, PWideChar(Caption), Length(Caption), lpRect, uFormat);
End;
Initialization
CreateGenericCodeHook(@DrawText, @NewDrawText, @OldDrawText);
Finalization
RemoveGenericCodeHook(@OldDrawText);
end.
Здравствуйте, Mamut, Вы писали:
M>>>>>В пятый раз прошу: обьсни мне, что ты понимаешь под словом "расширяется" и что ты понимаешь под словом "наследуется"
H>>>>Я для кого писал: H>>>>
H>>>>MyInterface будет содержать декларации методов от IUnknown (но эти декларации будут его декларациями), плюс свои собственные. Мамут, тебе не надоело? Я уже сто раз это написал...
H>>>>Обрати внимание на выделенное.
M>>>И? Какой смысл?
H>>Ты безнадежен
M>Это не я безнадежен, не надейся. У меня просто кругозор не зашорен гениальным словом "идеология"
Твой кругозор сводится к абстрактным классам и реализации интерфейсов на их основе
M>Итак: M>- MyInterface расширяется декларациями IUnknown (c) hattab M>- MyInterface будет содержать декларации методов от IUnknown (но эти декларации будут его декларациями), плюс свои собственные
M>Это — наследование в чистом виде. Причем — наследование одного абстрактного класса от другого (да, именно абстрактного класса)
M>Именно поэтому объект, "реализующий" MyInterface, обязан реализовать методы всех интерфейсов-предков MyInterface.
M>Интерфейсы существуют в Дельфи ровно по одной причине: обеспечить легкую работу с COM'ом. Именно поэтому любой объект, реализующий любой интерфейс, является COM-объектом и обязан реализовать IUnknown. При этом необходимость явной декларации IUnknown является ничем иным, как костылем, непонятно зачем прикрученым.
Еще раз, для тех кто в танке. Компилятор осуществляет автоматический подсчет ссылок, поэтому и требования такие. Это так сложно для понимания?
M>Второй возможный вариант использования интерфейсов — эмуляция множественнного наследования (как это седлано в Java). Но в Дельфи вся эта множественная наследованность тупо гвоздями прибита к COM'у, поэтому польза от интерфейсов вне COM'а в Дельфи стремится к нулю.
Расскажи об этом писателям VCL А то они, бедняги, юзают интерфейсы без всякого COM'а и даже не подозревают о твоих откровениях... Мамут, кончай дурака валять, я уже и так понял, что ты не можешь или не хочешь въехать в понимание интерфейсов, и в то, как это реализовано в Delphi. Удачи.
M>Вопрос на засыпку: почему я в Дельфи не могу объявить интерфейс, не прибитый гвоздями к IUnknown?
Потому же, почему ты даже неявно наследуешься от TObject. Требование компилятора.
Здравствуйте, hattab, Вы писали:
kuj>>>>2hattab: в .NET есть XML-RPC (и binary-RPC), к твоему сведенью, называется он WCF.
H>>>WCF это не оно
kuj>>Чегой? WCF на SOAP это именно XML-RPC.
H>Переведи на русский.
Я по-русски вроде с тобой общаюсь.
H>А вообще, SOAP это не XML-RPC.
SOAP это XML-RPC. Учи матчасть.
http://ru.wikipedia.org/wiki/SOAP
kuj>>>>.NET Framework действительно покрывает куда более широкий круг задач в отличии от VCL — в его составе есть даже реализации современных криптографических протоколов (блочный симметричный AES Rijndael, ассиметричный RSA, хеши MD5, SHAx и т.д. и т.д.).
H>>>VCL глупо сравнивать с FW, ибо VCL не есть фреймвок.
kuj>>Конечно не есть. А другого у Delphi все-равно нет.
H>Вот и не нужно их сравнивать, говоря всем известные факты типа выделенного... Кто с этим спорил?
А что сравнивать-то?
H>>>С шифрами все прикольнее... Ты в курсе, что криптография в Windows намеренно ослаблена? Какой в таком случае в них смысл...
kuj>>Что значит ослаблена? Давай уж конкретнее и по пунктам.
H>Ты не читал о применении 40 бит вместо 56 в DES (правда, я об этом тоже давненько читал)?
Ну ты вспомнил... Шифр, которому уже лет эдак 40... FYI, стандартным (нет, не ГОСТ, но AES) блочным симметричным шифром уже много лет как является Rijndael.
H>Ты не читал о чудном генераторе случайных чисел имеющем прикольную частоту повторения? К сожалению ссылок дать не могу, не коллекционирую... Можешь на "Компьютерре" почитать статьи за авторством Киви Берд'а.
Взялся за куш не говори, что не дюж — урлы на статьи в студию.
Да, кстати, никто не мешает использовать любой другой генератор случайного шума вплоть до железного генератора белого шума.
kuj>>>>Другое дело, что фактически все внешние сборки во-первых: поставляются с исходниками и зачастую имеют хорошее покрытие unit-тестами (кстати, MS открыла исходные коды самого .NET Framework)
H>>>Наличием исходников трудно кого то удивить... У меня в сборнике (очень скромном) Delphi сурсов, 210 бесплатных библиотек и юнитов общим весом в 365 мегабайт исходного кода. kuj>>365MB в исходном кодах 210 библиотек? Что-то очень слабо верится.
H>Там написано "библиотек и юнитов". Больших библиотек от силы штук 10 (это на глаз), остальное соломка на всякие случаи жизненные.
Перечень больших библиотек в студию.
kuj>>>>, во-вторых: имеют за плечами сотни и тысячи успешных проектов, что в целом значительно лучше, чем
H>>>Коли уж цифрами бросаешься, давай и ссылки.
kuj>>Ссылки на что тебе давать?
H>Ну, где-то же ты почерпнул цифры эти... Ссылки на саксесс стори...
Откуда я тебе эти ссылки возьму?
У тебя есть сомнения, что тот же nHibernate не имеет за плечами тысячь успешных проектов? Ну так это исключительно от незнания enterprise программирования.
kuj>>>>Ну и наконец об "интерфейсах" в Delphi: интерфейсы в Delphi это костыль, который был добавлен исключительно для взаимодействия с COM и для создания .NET версии Delphi. Отсюда и требование наследоваться от IUnknown: вместо приведения типов еще на этапе компиляции в тех случаях, когда это возможно, всегда вызывается QueryInterface...
H>>>Иногда лучше жевать.
kuj>>Аргументировать слабо?
H>Да что тут аргументировать? Ты читать умеешь? Я уже писал, что Delphi умеет делать приведение к интерфейсным типам без вызова QueryInterface. А твои слова показывают только уровень твоих познаний
Тогда какой сакральный смысл в обязательном наследовании от IUnknown?
Re[30]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
H>Вот тебе пример: H>
Думаю, теперь ни у кого больше не возникнет вопрос "чем вам не угодил Delphi". В далеком 99м году еще на C++ писал с полной поддержкой юникод и в мыслях не было, что может потребоваться перехватывать API-вызовы для вывода юникод текста.
Re[31]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, kuj, Вы писали:
M>>>>>И что-то я не припомню стандартного легкого способа заставить VCL понимать и выводить текст на разных языках.
H>>>>Можно обойтись класс-хелперами и перехватом API.
kuj>>>"Перехват API" это что еще за зверь?
H>>Ты прикалываешься чтоль? В общем, смотри ответ Мамуту, я там пример приведу.
kuj>Ты собрался перехватывать интерфейс программирования? Надо точнее выражаться — перехват API-вызовов.
А ты решил к словам по-цепляться? Я расчивал, что разговариваю, как минимум, с людьми которые в теме...
kuj>>>Кстати, откуда информация о том, что Paint.NET хранит thumbnails в системном реестре Windows?
H>>Смотришь HKEY_CURRENT_USER\Software\Paint.NET и видишь MRU0Thumb, MRU1Thumb и так далее
kuj>Мда. Ну, как говорится, в семье не без урода.
Теперь нетерам придется нового идола для поклонения и предъявления искать
Re[32]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
kuj>>>>Кстати, откуда информация о том, что Paint.NET хранит thumbnails в системном реестре Windows?
H>>>Смотришь HKEY_CURRENT_USER\Software\Paint.NET и видишь MRU0Thumb, MRU1Thumb и так далее
kuj>>Мда. Ну, как говорится, в семье не без урода.
H>Теперь нетерам придется нового идола для поклонения и предъявления искать
Угу, пора переходить на Делфи и писать перехватчики вызовов для вывода Unicode. Посыпаю голову пеплом
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, squid, Вы писали:
S>>Здравствуйте, hattab, Вы писали:
H>>>Ну да, давно не обновлялось... Очевидно, впрочем, что Борланду это было нужно еще меньше чем прогдигам...
S>>в том и проблема.
H>Странно слышать, что такая мелочь явилась проблемой... Впрочем
Здравствуйте, kuj, Вы писали:
kuj>>>>>2hattab: в .NET есть XML-RPC (и binary-RPC), к твоему сведенью, называется он WCF.
H>>>>WCF это не оно
kuj>>>Чегой? WCF на SOAP это именно XML-RPC.
H>>Переведи на русский.
kuj>Я по-русски вроде с тобой общаюсь.
Поясни смысл фразы "WCF на SOAP". Следует понимать, как SOAP под WCF?
H>>А вообще, SOAP это не XML-RPC.
kuj>SOAP это XML-RPC. Учи матчасть.
kuj>http://ru.wikipedia.org/wiki/SOAP
Протокол XML-RPC был изначально разработан Дэйвом Винером из компании «UserLand Software» в сотрудничестве с Майкрософт в 1995 году. Однако корпорация Майкрософт вскоре сочла этот протокол слишком упрощённым, и начала расширять его функциональность. После нескольких циклов по расширению функциональности, появилась система, ныне известная как SOAP. Позднее Майкрософт начала широко рекламировать и внедрять SOAP, а изначальный XML-RPC был отвергнут. Но, несмотря на отвержение Майкрософт, стандарт XML-RPC очаровал многих программистов своей необычайной простотой и, за счёт этого, существует по сей день и даже постепенно набирает популярность.
XML-RPC c SOAP имеют из общего, только пакеты в формате XML. SOAP это не XML-RPC, а XML-RPC не SOAP.
H>>>>С шифрами все прикольнее... Ты в курсе, что криптография в Windows намеренно ослаблена? Какой в таком случае в них смысл...
kuj>>>Что значит ослаблена? Давай уж конкретнее и по пунктам.
H>>Ты не читал о применении 40 бит вместо 56 в DES (правда, я об этом тоже давненько читал)?
kuj>Ну ты вспомнил... Шифр, которому уже лет эдак 40... FYI, стандартным (нет, не ГОСТ, но AES) блочным симметричным шифром уже много лет как является Rijndael.
Дело не в том, сколько лет прошло. Дело в тенденциях.
H>>Ты не читал о чудном генераторе случайных чисел имеющем прикольную частоту повторения? К сожалению ссылок дать не могу, не коллекционирую... Можешь на "Компьютерре" почитать статьи за авторством Киви Берд'а.
kuj>Взялся за куш не говори, что не дюж — урлы на статьи в студию.
Нашел одну. Но она не единственная.
kuj>Да, кстати, никто не мешает использовать любой другой генератор случайного шума вплоть до железного генератора белого шума.
Мы говорим о средствах уже включенных в FW (и которыми большинство и будет пользоваться).
kuj>>>>>Другое дело, что фактически все внешние сборки во-первых: поставляются с исходниками и зачастую имеют хорошее покрытие unit-тестами (кстати, MS открыла исходные коды самого .NET Framework)
H>>>>Наличием исходников трудно кого то удивить... У меня в сборнике (очень скромном) Delphi сурсов, 210 бесплатных библиотек и юнитов общим весом в 365 мегабайт исходного кода. kuj>>>365MB в исходном кодах 210 библиотек? Что-то очень слабо верится.
H>>Там написано "библиотек и юнитов". Больших библиотек от силы штук 10 (это на глаз), остальное соломка на всякие случаи жизненные.
kuj>Перечень больших библиотек в студию.
ToolBar2000, TBX, HTMLDisplay, UIB, GLScene, TNT, DCPCrypt (19 криптеров и 10 хешей), GR32, GraphicsEx, Synapse. Достаточно?
kuj>>>>>, во-вторых: имеют за плечами сотни и тысячи успешных проектов, что в целом значительно лучше, чем
H>>>>Коли уж цифрами бросаешься, давай и ссылки.
kuj>>>Ссылки на что тебе давать?
H>>Ну, где-то же ты почерпнул цифры эти... Ссылки на саксесс стори...
kuj>Откуда я тебе эти ссылки возьму?
Ну... Взялся за гуж...
kuj>У тебя есть сомнения, что тот же nHibernate не имеет за плечами тысячь успешных проектов? Ну так это исключительно от незнания enterprise программирования.
С чего ты взял, что я сомневаюсь? Я тебя прошу слова свои подтвердить.
kuj>>>>>Ну и наконец об "интерфейсах" в Delphi: интерфейсы в Delphi это костыль, который был добавлен исключительно для взаимодействия с COM и для создания .NET версии Delphi. Отсюда и требование наследоваться от IUnknown: вместо приведения типов еще на этапе компиляции в тех случаях, когда это возможно, всегда вызывается QueryInterface...
H>>>>Иногда лучше жевать.
kuj>>>Аргументировать слабо?
H>>Да что тут аргументировать? Ты читать умеешь? Я уже писал, что Delphi умеет делать приведение к интерфейсным типам без вызова QueryInterface. А твои слова показывают только уровень твоих познаний
kuj>Тогда какой сакральный смысл в обязательном наследовании от IUnknown?
Ссылки подсчитывать нужно. К тому же QueryInterface позволяет делать очень интересные вещи, типа получения интерфейса от объекта, который об этом интерфейсе ни сном ни духом и никогда его не реализовывал.
Re[31]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, kuj, Вы писали:
H>>Вот тебе пример: H>>
kuj>Думаю, теперь ни у кого больше не возникнет вопрос "чем вам не угодил Delphi". В далеком 99м году еще на C++ писал с полной поддержкой юникод и в мыслях не было, что может потребоваться перехватывать API-вызовы для вывода юникод текста.
На С++ с легкостью визуального построения фейса, как в Delphi? Не смеши меня (Билдер не рассматриваем, ибо тот же VCL). А этот пример только для того, чтоб показать Мамуту, что такое хелперы перехват API. Для реальной работы есть TNT.
Здравствуйте, hattab, Вы писали:
H>>>>>WCF это не оно
kuj>>>>Чегой? WCF на SOAP это именно XML-RPC.
H>>>Переведи на русский.
kuj>>Я по-русски вроде с тобой общаюсь.
H>Поясни смысл фразы "WCF на SOAP". Следует понимать, как SOAP под WCF?
Ну хорошо, если придерживаться терминологии SOAP это не XML-RPC, хотя технически имеет те же характеристики и покрывает все варианты применения, что и XML-RPC. В составе .NET FW нет реализации XML-RPC банально потому, что есть SOAP — более функциональный и удобный.
К тому же, есть полноценный XML-сериализатор. В отличии от...
H>>>>>С шифрами все прикольнее... Ты в курсе, что криптография в Windows намеренно ослаблена? Какой в таком случае в них смысл...
kuj>>>>Что значит ослаблена? Давай уж конкретнее и по пунктам.
H>>>Ты не читал о применении 40 бит вместо 56 в DES (правда, я об этом тоже давненько читал)?
kuj>>Ну ты вспомнил... Шифр, которому уже лет эдак 40... FYI, стандартным (нет, не ГОСТ, но AES) блочным симметричным шифром уже много лет как является Rijndael.
H>Дело не в том, сколько лет прошло. Дело в тенденциях.
В каких еще тенденциях?
Еще раз повторяю DES уж много лет как не применяется в свете наличия гораздо лучших шифров, как например Rijndael.
H>>>Ты не читал о чудном генераторе случайных чисел имеющем прикольную частоту повторения? К сожалению ссылок дать не могу, не коллекционирую... Можешь на "Компьютерре" почитать статьи за авторством Киви Берд'а.
kuj>>Взялся за куш не говори, что не дюж — урлы на статьи в студию.
H>Нашел одну. Но она не единственная.
Там, где требуется сверхнадежность в любом случае не будет использоваться стандартный генератор случайных чисел. В общем же случае, встроенного достаточно.
kuj>>Да, кстати, никто не мешает использовать любой другой генератор случайного шума вплоть до железного генератора белого шума.
H>Мы говорим о средствах уже включенных в FW (и которыми большинство и будет пользоваться).
Что, тем не менее, не мешает использовать другую реализацию генератора случайных чисел тогда, когда это требуется.
kuj>>Перечень больших библиотек в студию.
H>ToolBar2000, TBX, HTMLDisplay, UIB, GLScene, TNT, DCPCrypt (19 криптеров и 10 хешей), GR32, GraphicsEx, Synapse. Достаточно?
Больше 300 MB исходных кодов в этих относительно бедных функционально библиотеках? Честно-честно? Да уж, про DRY-принцип в Delphi мире явно не слышали.
kuj>>>>>>, во-вторых: имеют за плечами сотни и тысячи успешных проектов, что в целом значительно лучше, чем
H>>>>>Коли уж цифрами бросаешься, давай и ссылки.
kuj>>>>Ссылки на что тебе давать?
H>>>Ну, где-то же ты почерпнул цифры эти... Ссылки на саксесс стори...
kuj>>Откуда я тебе эти ссылки возьму?
H>Ну... Взялся за гуж...
Не брался. Я же не говорил "я прочитал на таком то сайте, что X успешно применили в Y проектах".
kuj>>У тебя есть сомнения, что тот же nHibernate не имеет за плечами тысячь успешных проектов? Ну так это исключительно от незнания enterprise программирования.
H>С чего ты взял, что я сомневаюсь? Я тебя прошу слова свои подтвердить.
kuj>>Тогда какой сакральный смысл в обязательном наследовании от IUnknown?
H>Ссылки подсчитывать нужно.
Зачем?
H>К тому же QueryInterface позволяет делать очень интересные вещи, типа получения интерфейса от объекта, который об этом интерфейсе ни сном ни духом и никогда его не реализовывал.
В любом случае один из предков реализовал.
Почему можно скастить объект к абстрактному предку без всяких QueryInterface`ов?
Что делать, если нужно написать интерфейс для класса, который не был унаследован от TInterfacedObject?
Re[32]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
H>>>Вот тебе пример: H>>>
kuj>>Думаю, теперь ни у кого больше не возникнет вопрос "чем вам не угодил Delphi". В далеком 99м году еще на C++ писал с полной поддержкой юникод и в мыслях не было, что может потребоваться перехватывать API-вызовы для вывода юникод текста.
H>На С++ с легкостью визуального построения фейса, как в Delphi?
У Microsoft Office достаточно сложный интерфейс? А у Visual Studio?..
WPF и Silverlight интерфейсы видел?
Re[32]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
H>На С++ с легкостью визуального построения фейса, как в Delphi?
hattab, а можно взглянуть на скриншоты ваших разработок. Что-то мне кажется, что там нет никакого навороченного UI. Сколько видел программ на Delphi — это обычно нагромождение контролов на формах, сложное в восприятии, но без принципиальных сложностей в поведении.
kuj пишет: > Думаю, теперь ни у кого больше не возникнет вопрос "чем вам не угодил > Delphi". В далеком 99м году еще на C++ писал с полной поддержкой юникод > и в мыслях не было, что может потребоваться перехватывать API-вызовы для > вывода юникод текста.
Microsoft тоже молодцы, не могли поставить UTF-8 вместо ANSI, как в
юниксе. Вот и получилась шоковая терапия.
Здравствуйте, OCTAGRAM, Вы писали:
>> Думаю, теперь ни у кого больше не возникнет вопрос "чем вам не угодил >> Delphi". В далеком 99м году еще на C++ писал с полной поддержкой юникод >> и в мыслях не было, что может потребоваться перехватывать API-вызовы для >> вывода юникод текста.
OCT>Microsoft тоже молодцы, не могли поставить UTF-8 вместо ANSI, как в OCT>юниксе. Вот и получилась шоковая терапия.
Ну-ну. Уже давно как поставили. Как минимум со времен Windows 2000 (а то и NT).
Например, CreateWindowEx, вызываемая с ANSI-строками должна выделить доп. блоки памяти в куче процесса, преобразовать ANSI-строки в Unicode и, сохранив результат, вызвать Unicode-версию CreateWindowExW... Так что Delphi со своими ANSI-строками еще и лишние ресурсы системы тратит каждый раз вызывая API-функцию с ANSI строкой в качестве параметра...
kuj пишет: > Здравствуйте, OCTAGRAM, Вы писали: > >> > Думаю, теперь ни у кого больше не возникнет вопрос "чем вам не угодил >> > Delphi". В далеком 99м году еще на C++ писал с полной поддержкой юникод >> > и в мыслях не было, что может потребоваться перехватывать API-вызовы для >> > вывода юникод текста. > > OCT>Microsoft тоже молодцы, не могли поставить UTF-8 вместо ANSI, как в > OCT>юниксе. Вот и получилась шоковая терапия. > > Ну-ну. Уже давно как поставили. Как минимум со времен Windows 2000 (а то > и NT). > > Например, CreateWindowEx, вызываемая с ANSI-строками
Здравствуйте, OCTAGRAM, Вы писали:
>>> > Думаю, теперь ни у кого больше не возникнет вопрос "чем вам не угодил >>> > Delphi". В далеком 99м году еще на C++ писал с полной поддержкой юникод >>> > и в мыслях не было, что может потребоваться перехватывать API-вызовы для >>> > вывода юникод текста. >> >> OCT>Microsoft тоже молодцы, не могли поставить UTF-8 вместо ANSI, как в >> OCT>юниксе. Вот и получилась шоковая терапия. >> >> Ну-ну. Уже давно как поставили. Как минимум со времен Windows 2000 (а то >> и NT). >> >> Например, CreateWindowEx, вызываемая с ANSI-строками
OCT>Вот именно, что ANSI, а не UTF-8
Так а MS тут при чем? Microsoft давно уж сделали все необходимое для перехода на unicode, а Borland за 10 лет так и не удосужились перейти на unicode.
Re[30]: наши менеджеры памяти самые менеджеристые менеджеры
kuj>>Кстати, откуда информация о том, что Paint.NET хранит thumbnails в системном реестре Windows?
H>Смотришь HKEY_CURRENT_USER\Software\Paint.NET и видишь MRU0Thumb, MRU1Thumb и так далее
И они там таки хранят двоичные данные этих тамбов или это все таки MRU — Most Recent Used?
Здравствуйте, Mamut, Вы писали:
kuj>>>Кстати, откуда информация о том, что Paint.NET хранит thumbnails в системном реестре Windows?
H>>Смотришь HKEY_CURRENT_USER\Software\Paint.NET и видишь MRU0Thumb, MRU1Thumb и так далее
M>И они там таки хранят двоичные данные этих тамбов или это все таки MRU — Most Recent Used?
Это most recent used. Thumbnails последних открытых файлов. То есть до 5-10 максимум.
M>>Это не я безнадежен, не надейся. У меня просто кругозор не зашорен гениальным словом "идеология"
H>Твой кругозор сводится к абстрактным классам и реализации интерфейсов на их основе
Объясни мне, какая принципиальная разница между интерфейсом и абстрактным классом? И почитай, наконец, Abstract Type.
In many object oriented programming languages, abstract types are known as abstract base classes, interfaces, traits, mixins, flavors, or roles. Note that these names refer to different language constructs which are (or may be) used to implement abstract types.
Интерфейсы в Дельфи существуют ровно по двум причинам:
— COM
— Множественное наследование, необходимое для COM
M>>Интерфейсы существуют в Дельфи ровно по одной причине: обеспечить легкую работу с COM'ом. Именно поэтому любой объект, реализующий любой интерфейс, является COM-объектом и обязан реализовать IUnknown. При этом необходимость явной декларации IUnknown является ничем иным, как костылем, непонятно зачем прикрученым.
H>Еще раз, для тех кто в танке. Компилятор осуществляет автоматический подсчет ссылок, поэтому и требования такие. Это так сложно для понимания?
Если нам не нужен COM, то зачем нам подсчет ссылок?
M>>Второй возможный вариант использования интерфейсов — эмуляция множественнного наследования (как это седлано в Java). Но в Дельфи вся эта множественная наследованность тупо гвоздями прибита к COM'у, поэтому польза от интерфейсов вне COM'а в Дельфи стремится к нулю.
H>Расскажи об этом писателям VCL А то они, бедняги, юзают интерфейсы без всякого COM'а и даже не подозревают о твоих откровениях...
И каждый из них обязательно реализует IUnknown или TInterfacedObject? Зачем?
H>Мамут, кончай дурака валять, я уже и так понял, что ты не можешь или не хочешь въехать в понимание интерфейсов, и в то, как это реализовано в Delphi. Удачи.
Нефиг прикрываться словом идеология, если идеология крива
M>>Вопрос на засыпку: почему я в Дельфи не могу объявить интерфейс, не прибитый гвоздями к IUnknown?
H>Потому же, почему ты даже неявно наследуешься от TObject. Требование компилятора.
Идиотское требование, причем непонятно, зачем существующее
Здравствуйте, Mamut, Вы писали:
H>>Потому же, почему ты даже неявно наследуешься от TObject. Требование компилятора.
M>Идиотское требование, причем непонятно, зачем существующее
Да не, наследование от TObject вполне нормальная практика. В .NET — System.Object, в Java — java.lang.Object, в Ruby — Object, и т.д.
Re[32]: наши менеджеры памяти самые менеджеристые менеджеры
H>>>Смотришь HKEY_CURRENT_USER\Software\Paint.NET и видишь MRU0Thumb, MRU1Thumb и так далее
M>>И они там таки хранят двоичные данные этих тамбов или это все таки MRU — Most Recent Used?
kuj>Это most recent used. Thumbnails последних открытых файлов. То есть до 5-10 максимум.
ххх: Купил ноутбук АСЕР. На нем стоит операционка Виста. Столкнулся с проблемой подключения к интернету. Помогите!!
ууу: Ты более подробно суть изложи. Какой способ подключения к инету? Модем? GPRS? ADSL? Локалка? Как ты настраивал подключение? Что тебе комп говорит?
ххх: спуниковый инет, кажется ADSL, в общем несколько компьютеров к одному спутнику подключены(видимо локалка)...
H>>>Потому же, почему ты даже неявно наследуешься от TObject. Требование компилятора.
M>>Идиотское требование, причем непонятно, зачем существующее
kuj>Да не, наследование от TObject вполне нормальная практика. В .NET — System.Object, в Java — java.lang.Object, в Ruby — Object, и т.д.
K>В выделенной строке будет аксесс виолейшн, если переменная уже nil.
Присваивание интерфейсной переменной значения nil неявно вызывает деструктор объекта, реализующего интерфес. Если, как Вы пишете, переменная уже = nil, вот Вам и Access Violation.
kuj пишет: > OCT>Вот именно, что ANSI, а не UTF-8 > > Так а MS тут при чем? Microsoft давно уж сделали все необходимое для > перехода на unicode, а Borland за 10 лет так и не удосужились перейти на > unicode.
Ну вот и в Windows, и в Юниксах было сделано всё необходимое, чтобы
перейти на unicode, вот только сделано это было как–то по–разному.
Учитывая переносимость в представлении Microsoft ... http://www.cs.kuleuven.be/~dirk/quotes.html
Portable: code that requires the user to port to the latest release of
our operating system and utility libraries.
AlBa пишет: > Присваивание интерфейсной переменной значения nil неявно вызывает > деструктор объекта, реализующего интерфес. Если, как Вы пишете, > переменная уже = nil, вот Вам и Access Violation.
Оно вызывает _IntfClear, который ничего не сделает с nil.
>> OCT>Вот именно, что ANSI, а не UTF-8 >> >> Так а MS тут при чем? Microsoft давно уж сделали все необходимое для >> перехода на unicode, а Borland за 10 лет так и не удосужились перейти на >> unicode.
OCT>Ну вот и в Windows, и в Юниксах было сделано всё необходимое, чтобы OCT>перейти на unicode, вот только сделано это было как–то по–разному. OCT>Учитывая переносимость в представлении Microsoft ... OCT>http://www.cs.kuleuven.be/~dirk/quotes.html
OCT>Portable: code that requires the user to port to the latest release of OCT>our operating system and utility libraries.
OCT>... я думаю, это закономерно :D
А я думаю, что не надо перекладывать с больной головы на здоровую...
Здравствуйте, kuj, Вы писали:
H>>>>>>WCF это не оно
kuj>>>>>Чегой? WCF на SOAP это именно XML-RPC.
H>>>>Переведи на русский.
kuj>>>Я по-русски вроде с тобой общаюсь.
H>>Поясни смысл фразы "WCF на SOAP". Следует понимать, как SOAP под WCF?
kuj>Тяжело в гугле набрать WCF и открыть первую ссылку wiki? http://en.wikipedia.org/wiki/Windows_Communication_Foundation
Я читал о WCF, не беспокойся. Ты поясни мне смысл слов "WCF на SOAP".
kuj>>>SOAP это XML-RPC. Учи матчасть.
kuj>>>http://ru.wikipedia.org/wiki/SOAP
H>>А ты историю учи . Вот тебе цитата:
H>>XML-RPC c SOAP имеют из общего, только пакеты в формате XML. SOAP это не XML-RPC, а XML-RPC не SOAP.
kuj>Ну хорошо, если придерживаться терминологии SOAP это не XML-RPC, хотя технически имеет те же характеристики и покрывает все варианты применения, что и XML-RPC.
...и имеет чудное свойство -- несовместимость реализаций от разных вендоров Вроде разговаривают по SOAP, а понять друг-друга не могут Совместимость же со всея .Net, мне мало интересна.
kuj>В составе .NET FW нет реализации XML-RPC банально потому, что есть SOAP — более функциональный и удобный.
Очередной marketing-bullshit. Это ты расскажешь заказчику, у которого бизнес-процессы построены и на CORBA, и на SOAP, и на XML-RPC (большие системы имеют очень долгий цикл развития и целый зоопарк решений).
kuj>К тому же, есть полноценный XML-сериализатор. В отличии от...
А парсить умеете без загрузки всего дока в память? Распарсишь гиговый XML на машинке с 512 Мб на борту?
H>>>>>>С шифрами все прикольнее... Ты в курсе, что криптография в Windows намеренно ослаблена? Какой в таком случае в них смысл...
kuj>>>>>Что значит ослаблена? Давай уж конкретнее и по пунктам.
H>>>>Ты не читал о применении 40 бит вместо 56 в DES (правда, я об этом тоже давненько читал)?
kuj>>>Ну ты вспомнил... Шифр, которому уже лет эдак 40... FYI, стандартным (нет, не ГОСТ, но AES) блочным симметричным шифром уже много лет как является Rijndael.
H>>Дело не в том, сколько лет прошло. Дело в тенденциях. kuj>В каких еще тенденциях?
Реализация алгоритмов закрыта (с чего бы вдруг, алгоритмы-то известны ). Над безопасностью в Висте МС работала с АНБ. С чего вдруг? Тенденции однако...
kuj>Еще раз повторяю DES уж много лет как не применяется в свете наличия гораздо лучших шифров, как например Rijndael.
Да хоть каким современным будь здание, но если у него фундамент гнилой...
Кстати, Rijndael не был лучшим по результам тестов на потенциальные уязвимости см. руководство TrueCrypt (там есть ссылочки на первоисточники).
H>>>>Ты не читал о чудном генераторе случайных чисел имеющем прикольную частоту повторения? К сожалению ссылок дать не могу, не коллекционирую... Можешь на "Компьютерре" почитать статьи за авторством Киви Берд'а.
kuj>>>Взялся за куш не говори, что не дюж — урлы на статьи в студию.
H>>Нашел одну. Но она не единственная.
kuj>Там, где требуется сверхнадежность в любом случае не будет использоваться стандартный генератор случайных чисел. В общем же случае, встроенного достаточно.
В общем случае??? Будем юзать и надеяться, что мы никому не нужны
kuj>>>Да, кстати, никто не мешает использовать любой другой генератор случайного шума вплоть до железного генератора белого шума.
H>>Мы говорим о средствах уже включенных в FW (и которыми большинство и будет пользоваться).
kuj>Что, тем не менее, не мешает использовать другую реализацию генератора случайных чисел тогда, когда это требуется.
Конечно не мешает, да только речь не о сторонних...
kuj>>>Перечень больших библиотек в студию.
H>>ToolBar2000, TBX, HTMLDisplay, UIB, GLScene, TNT, DCPCrypt (19 криптеров и 10 хешей), GR32, GraphicsEx, Synapse. Достаточно?
kuj>Больше 300 MB исходных кодов в этих относительно бедных функционально библиотеках? Честно-честно? Да уж, про DRY-принцип в Delphi мире явно не слышали.
С чего ты взял что основная масса кода приходится на этот десяток (кстати, только GLScene весит 23 Мб)? Там еще осталось 200 библиотек/юнитов/компонентов.
kuj>>>>>>>, во-вторых: имеют за плечами сотни и тысячи успешных проектов, что в целом значительно лучше, чем
H>>>>>>Коли уж цифрами бросаешься, давай и ссылки.
kuj>>>>>Ссылки на что тебе давать?
H>>>>Ну, где-то же ты почерпнул цифры эти... Ссылки на саксесс стори...
kuj>>>Откуда я тебе эти ссылки возьму?
H>>Ну... Взялся за гуж...
kuj>Не брался. Я же не говорил "я прочитал на таком то сайте, что X успешно применили в Y проектах".
Да, ты всего лишь сказал о десятках тысяч успешных внедрений... Абсолютно спотолочная цифра.
kuj>>>У тебя есть сомнения, что тот же nHibernate не имеет за плечами тысячь успешных проектов? Ну так это исключительно от незнания enterprise программирования.
H>>С чего ты взял, что я сомневаюсь? Я тебя прошу слова свои подтвердить.
kuj>http://forum.hibernate.org/ Больше 50000 топиков, больше 200000 сообщений.
kuj>http://forum.hibernate.org/viewtopic.php?t=952439
Хе-хе-хе. Да уж, форум это очень компетентный источник И из чего тут может следовать существование десятков тысяч успешных внедрений?
kuj>>>Тогда какой сакральный смысл в обязательном наследовании от IUnknown?
H>>Ссылки подсчитывать нужно.
kuj>Зачем?
Для обеспечения управляемого времени жизни интерфейсных переменных и для совместимости с уже существующей COM.
H>>К тому же QueryInterface позволяет делать очень интересные вещи, типа получения интерфейса от объекта, который об этом интерфейсе ни сном ни духом и никогда его не реализовывал.
kuj>В любом случае один из предков реализовал.
А вот и нет (даже не агрегирует ни кто). Сурпрайз? Я тут уже писал, что так построена работа с SOAP веб-сервисами в Delphi. Можешь поискать по "RIO". У меня для XML-RPC используется похожий вариант, только гибче и проще
kuj>Почему можно скастить объект к абстрактному предку без всяких QueryInterface`ов?
kuj>Что делать, если нужно написать интерфейс для класса, который не был унаследован от TInterfacedObject?
Реализовать три тривиальнейших метода от IInterface/Iunknown.
Re[33]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, kuj, Вы писали:
H>>>>Вот тебе пример: H>>>>
kuj>>>Думаю, теперь ни у кого больше не возникнет вопрос "чем вам не угодил Delphi". В далеком 99м году еще на C++ писал с полной поддержкой юникод и в мыслях не было, что может потребоваться перехватывать API-вызовы для вывода юникод текста.
H>>На С++ с легкостью визуального построения фейса, как в Delphi?
kuj>У Microsoft Office достаточно сложный интерфейс? А у Visual Studio?..
Тебе ключевые слова чтоль выделить? Ладно, выделяю: "с легкостью визуального построения фейса".
kuj>WPF и Silverlight интерфейсы видел?
Видел Видел WPF с размытыми шрифтами А, это вообще вопрос к чему?
Re[33]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, abibok, Вы писали:
H>>На С++ с легкостью визуального построения фейса, как в Delphi?
A>hattab, а можно взглянуть на скриншоты ваших разработок. Что-то мне кажется, что там нет никакого навороченного UI.
И правильно кажется. Я уж года два, как не занимаюсь гуем Ближайший гуевый проект будет через пол-года/год.
A>Сколько видел программ на Delphi — это обычно нагромождение контролов на формах, сложное в восприятии, но без принципиальных сложностей в поведении.
Я тут ссылочку на вики с Delphi-софтом давал. Поинтересуйтесь.
Re[31]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Mamut, Вы писали:
kuj>>>Кстати, откуда информация о том, что Paint.NET хранит thumbnails в системном реестре Windows?
H>>Смотришь HKEY_CURRENT_USER\Software\Paint.NET и видишь MRU0Thumb, MRU1Thumb и так далее
M>И они там таки хранят двоичные данные этих тамбов или это все таки MRU — Most Recent Used?
Таки сами миниатюры, ажно до 8 штук в моем конфиге. Но только не двоичные, они их еще в base64 завернули (видимо для полного safe)
Так что Delphi со своими ANSI-строками еще и лишние ресурсы системы тратит каждый раз вызывая API-функцию с ANSI строкой в качестве параметра...
Чья бы корова мычала, а нетеры бы почаще смотрели на счетчики .NET Interop #marshaling. Банальное возюканье мышой над меню/тулбаром Paint.NET, WLV приводит к офигительной накрутке этого счетчика
Здравствуйте, Mamut, Вы писали:
M>>>Это не я безнадежен, не надейся. У меня просто кругозор не зашорен гениальным словом "идеология"
H>>Твой кругозор сводится к абстрактным классам и реализации интерфейсов на их основе
M>Объясни мне, какая принципиальная разница между интерфейсом и абстрактным классом? И почитай, наконец, Abstract Type.
Мамут, заниматься твоим образованием у меня нет ни желания ни времени. Если для тебя это одно и тоже, пребывай в своем мире и не парь мне мозг.
M>
M> In many object oriented programming languages, abstract types are known as abstract base classes, interfaces, traits, mixins, flavors, or roles. Note that these names refer to different language constructs which are (or may be) used to implement abstract types.
Нафига мне эти мэни лэнгвиджы? Я тебе говорю об идеологии, да еще и в конкретном языке, где абстрактный класс сравнивать с интерфейсом могут только личности с весьма оригинальным способом мышления.
M>Интерфейсы в Дельфи существуют ровно по двум причинам: M>- COM M>- Множественное наследование, необходимое для COM
Ты слеп и не хочешь прозреть.
M>>>Интерфейсы существуют в Дельфи ровно по одной причине: обеспечить легкую работу с COM'ом. Именно поэтому любой объект, реализующий любой интерфейс, является COM-объектом и обязан реализовать IUnknown. При этом необходимость явной декларации IUnknown является ничем иным, как костылем, непонятно зачем прикрученым.
H>>Еще раз, для тех кто в танке. Компилятор осуществляет автоматический подсчет ссылок, поэтому и требования такие. Это так сложно для понимания?
M>Если нам не нужен COM, то зачем нам подсчет ссылок?
Обеспечить управляемое время жизни. Кстати, и строки и динамические массивы -- все это управляется подсчетом ссылок.
M>>>Второй возможный вариант использования интерфейсов — эмуляция множественнного наследования (как это седлано в Java). Но в Дельфи вся эта множественная наследованность тупо гвоздями прибита к COM'у, поэтому польза от интерфейсов вне COM'а в Дельфи стремится к нулю.
H>>Расскажи об этом писателям VCL А то они, бедняги, юзают интерфейсы без всякого COM'а и даже не подозревают о твоих откровениях...
M>И каждый из них обязательно реализует IUnknown или TInterfacedObject? Зачем?
Все печально. Очень.
H>>Мамут, кончай дурака валять, я уже и так понял, что ты не можешь или не хочешь въехать в понимание интерфейсов, и в то, как это реализовано в Delphi. Удачи.
M>Нефиг прикрываться словом идеология, если идеология крива
Это не она крива, это ты на нее через призму своих познаний смотришь. Очистись и возрадуйся
M>>>Вопрос на засыпку: почему я в Дельфи не могу объявить интерфейс, не прибитый гвоздями к IUnknown?
H>>Потому же, почему ты даже неявно наследуешься от TObject. Требование компилятора.
M>Идиотское требование, причем непонятно, зачем существующее
Ы-ы-ы. Тебе, как я вижу, вообще многое непонятно...
Здравствуйте, hattab, Вы писали:
kuj>>К тому же, есть полноценный XML-сериализатор. В отличии от... H>А парсить умеете без загрузки всего дока в память? Распарсишь гиговый XML на машинке с 512 Мб на борту?
Класс XmlReader (точнее его реализации XmlTextReader, XmlValidatingReader, XmlNodeReader) — тот же SAX, только лучше.
H> Тебе ключевые слова чтоль выделить? Ладно, выделяю: "с легкостью визуального построения фейса".
В чем заключается эта самая легкость? Накидать контролов на формочки легко и в Visual Studio. Когда речь заходит про что-нибудь сложнее диалоговых приложений вся эта мнимая легкость куда-то улетучивается.
kuj>WPF и Silverlight интерфейсы видел? H> Видел Видел WPF с размытыми шрифтами А, это вообще вопрос к чему?
Можно нам пример такого же на Delphi?
A>hattab, а можно взглянуть на скриншоты ваших разработок. Что-то мне кажется, что там нет никакого навороченного UI. H> И правильно кажется. Я уж года два, как не занимаюсь гуем.
Т.е. основное "преимущество" Delphi — легкость визуального построения фейса — в ваших проектах не использовалась. Тогда в чем смысл выбора Delphi?
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Portable: code that requires the user to port to the latest release of OCT>our operating system and utility libraries.
OCT>... я думаю, это закономерно :D
Здравствуйте, hattab, Вы писали:
H>Так что Delphi со своими ANSI-строками еще и лишние ресурсы системы тратит каждый раз вызывая API-функцию с ANSI строкой в качестве параметра...
H>Чья бы корова мычала, а нетеры бы почаще смотрели на счетчики .NET Interop #marshaling. Банальное возюканье мышой над меню/тулбаром Paint.NET, WLV приводит к офигительной накрутке этого счетчика
Ты хоть разберись сначала что это за счетчик.
Да, кстати, где? Где графический редактор с такой же функциональностью и интерфейсом, но написанный на Delphi?
Re[34]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
kuj>>>>Думаю, теперь ни у кого больше не возникнет вопрос "чем вам не угодил Delphi". В далеком 99м году еще на C++ писал с полной поддержкой юникод и в мыслях не было, что может потребоваться перехватывать API-вызовы для вывода юникод текста.
H>>>На С++ с легкостью визуального построения фейса, как в Delphi?
kuj>>У Microsoft Office достаточно сложный интерфейс? А у Visual Studio?..
H>Тебе ключевые слова чтоль выделить? Ладно, выделяю: "с легкостью визуального построения фейса".
Что является критерием простоты построения интерфейса? И почему самые сложные интерфейсы пишутся в основном на C++?
kuj>>WPF и Silverlight интерфейсы видел?
H>Видел Видел WPF с размытыми шрифтами
Ась?
H>А, это вообще вопрос к чему?
К тому, что Делфи уже давно как не лучший инструмент для построения пользовательских интерфейсов. Отсутствие поддержки юникод лишь усугубляет ситуацию.
provided separate APIs for SOAP-based communications for maximum interoperability (Web Services), binary-optimized communications between applications running on Windows machines (.NET Remoting), transactional communications (Distributed Transactions), and asynchronous communications (Message Queues).
H>>>XML-RPC c SOAP имеют из общего, только пакеты в формате XML. SOAP это не XML-RPC, а XML-RPC не SOAP.
kuj>>Ну хорошо, если придерживаться терминологии SOAP это не XML-RPC, хотя технически имеет те же характеристики и покрывает все варианты применения, что и XML-RPC.
H>...и имеет чудное свойство -- несовместимость реализаций от разных вендоров Вроде разговаривают по SOAP, а понять друг-друга не могут Совместимость же со всея .Net, мне мало интересна.
Полная чушь. Вот веб-сервис на Java, вот клиент .NET — никаких проблем с маршалингом.
kuj>>В составе .NET FW нет реализации XML-RPC банально потому, что есть SOAP — более функциональный и удобный.
H>Очередной marketing-bullshit. Это ты расскажешь заказчику, у которого бизнес-процессы построены и на CORBA, и на SOAP, и на XML-RPC (большие системы имеют очень долгий цикл развития и целый зоопарк решений).
http://www.xml-rpc.net/
kuj>>К тому же, есть полноценный XML-сериализатор. В отличии от...
H>А парсить умеете без загрузки всего дока в память?
Конечно умеет. StreamReader -> TextReader -> XmlSerializer
H>Распарсишь гиговый XML на машинке с 512 Мб на борту?
Это нереальная ситуация. Если у тебя XML растет до 1 GB и это не из-за base64 вставок, то пора править руки программистам.
H>>>>>>>С шифрами все прикольнее... Ты в курсе, что криптография в Windows намеренно ослаблена? Какой в таком случае в них смысл...
kuj>>>>>>Что значит ослаблена? Давай уж конкретнее и по пунктам.
H>>>>>Ты не читал о применении 40 бит вместо 56 в DES (правда, я об этом тоже давненько читал)?
kuj>>>>Ну ты вспомнил... Шифр, которому уже лет эдак 40... FYI, стандартным (нет, не ГОСТ, но AES) блочным симметричным шифром уже много лет как является Rijndael.
H>>>Дело не в том, сколько лет прошло. Дело в тенденциях. kuj>>В каких еще тенденциях?
H>Реализация алгоритмов закрыта (с чего бы вдруг, алгоритмы-то известны ).
Исходники Windows закрыты. И что?
H>Над безопасностью в Висте МС работала с АНБ.
И что?
H>С чего вдруг?
Американская компания работает с американской службой. С чего вдруг? Сложный вопрос, что ни говори...
H>Тенденции однако...
Маразм однако...
kuj>>Еще раз повторяю DES уж много лет как не применяется в свете наличия гораздо лучших шифров, как например Rijndael.
H>Да хоть каким современным будь здание, но если у него фундамент гнилой...
Аргументируй.
H>Кстати, Rijndael не был лучшим по результам тестов на потенциальные уязвимости см. руководство TrueCrypt (там есть ссылочки на первоисточники).
Ссылки в студию.
H>>>>>Ты не читал о чудном генераторе случайных чисел имеющем прикольную частоту повторения? К сожалению ссылок дать не могу, не коллекционирую... Можешь на "Компьютерре" почитать статьи за авторством Киви Берд'а.
kuj>>>>Взялся за куш не говори, что не дюж — урлы на статьи в студию.
H>>>Нашел одну. Но она не единственная.
kuj>>Там, где требуется сверхнадежность в любом случае не будет использоваться стандартный генератор случайных чисел. В общем же случае, встроенного достаточно.
H>В общем случае??? Будем юзать и надеяться, что мы никому не нужны
Это не имеет значения, если нет сверхмощностей, доступных только некоторым странам.
kuj>>>>Да, кстати, никто не мешает использовать любой другой генератор случайного шума вплоть до железного генератора белого шума.
H>>>Мы говорим о средствах уже включенных в FW (и которыми большинство и будет пользоваться).
kuj>>Что, тем не менее, не мешает использовать другую реализацию генератора случайных чисел тогда, когда это требуется.
H>Конечно не мешает, да только речь не о сторонних...
Да ну, а о чем же речь?
kuj>>Не брался. Я же не говорил "я прочитал на таком то сайте, что X успешно применили в Y проектах".
H>Да, ты всего лишь сказал о десятках тысяч успешных внедрений... Абсолютно спотолочная цифра.
Не говорил. Не перекручивай слова. Впрочем, в случее (n)Hibernate весьма вероятно что десятки тысяч.
kuj>>>>У тебя есть сомнения, что тот же nHibernate не имеет за плечами тысячь успешных проектов? Ну так это исключительно от незнания enterprise программирования.
H>>>С чего ты взял, что я сомневаюсь? Я тебя прошу слова свои подтвердить.
kuj>>http://forum.hibernate.org/ Больше 50000 топиков, больше 200000 сообщений.
kuj>>http://forum.hibernate.org/viewtopic.php?t=952439
H>Хе-хе-хе. Да уж, форум это очень компетентный источник И из чего тут может следовать существование десятков тысяч успешных внедрений?
(n)Hibernate самая популярная O/RM уже много лет как. Если у тебя есть сомнения, то это лишь значит, что ты не имеешь представления об Enterprise-level проектах.
kuj>>>>Тогда какой сакральный смысл в обязательном наследовании от IUnknown?
H>>>Ссылки подсчитывать нужно.
kuj>>Зачем?
H>Для обеспечения управляемого времени жизни интерфейсных переменных и для совместимости с уже существующей COM.
Совершенно верно. Для совместимости с COM. Наконец до тебя дошло.
H>>>К тому же QueryInterface позволяет делать очень интересные вещи, типа получения интерфейса от объекта, который об этом интерфейсе ни сном ни духом и никогда его не реализовывал.
kuj>>В любом случае один из предков реализовал.
H>А вот и нет (даже не агрегирует ни кто). Сурпрайз?
Класс, наследующий интерфейс, обязан этот интерфейс реализовать. Если ты ломаешь идеологию, возвращая в QueryInterface ссылки на внешние объекты, то это характеризует платформу как абсолютно бредовую.
kuj>>Почему можно скастить объект к абстрактному предку без всяких QueryInterface`ов?
Здравствуйте, abibok, Вы писали:
A>>hattab, а можно взглянуть на скриншоты ваших разработок. Что-то мне кажется, что там нет никакого навороченного UI. H>> И правильно кажется. Я уж года два, как не занимаюсь гуем. A>Т.е. основное "преимущество" Delphi — легкость визуального построения фейса — в ваших проектах не использовалась. Тогда в чем смысл выбора Delphi?
Ну как же, как же... писать реализацию XML-RPC с разруливанием циклических зависимостей между агрегированными объектами путем усложнения логики AddRef/Release.
Re[32]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, abibok, Вы писали:
kuj>>>К тому же, есть полноценный XML-сериализатор. В отличии от... H>>А парсить умеете без загрузки всего дока в память? Распарсишь гиговый XML на машинке с 512 Мб на борту? A>Класс XmlReader (точнее его реализации XmlTextReader, XmlValidatingReader, XmlNodeReader) — тот же SAX, только лучше.
Поверю наслово.
H>> Тебе ключевые слова чтоль выделить? Ладно, выделяю: "с легкостью визуального построения фейса". A>В чем заключается эта самая легкость? Накидать контролов на формочки легко и в Visual Studio. Когда речь заходит про что-нибудь сложнее диалоговых приложений вся эта мнимая легкость куда-то улетучивается.
Не просто накидать, а связать воедино с помощью экшенов. Использовать визуальное наследование форм. И кстати, не забываем, что человек говорил о 99 годе.
kuj>>WPF и Silverlight интерфейсы видел? H>> Видел Видел WPF с размытыми шрифтами А, это вообще вопрос к чему? A>Можно нам пример такого же на Delphi?
Чего? Размытых шрифтов?
A>>hattab, а можно взглянуть на скриншоты ваших разработок. Что-то мне кажется, что там нет никакого навороченного UI. H>> И правильно кажется. Я уж года два, как не занимаюсь гуем. A>Т.е. основное "преимущество" Delphi — легкость визуального построения фейса — в ваших проектах не использовалась. Тогда в чем смысл выбора Delphi?
Если я пишу для Delphi программистов, мне странно писать на каком-либо другом языке... К тому же я написал, что с гуем работать скоро придется. Плюс мой опыт, плюс наработки, плюс мне нравятся Виртовские языки. Вам то какое дело до моего выбора?
H>>>Твой кругозор сводится к абстрактным классам и реализации интерфейсов на их основе
M>>Объясни мне, какая принципиальная разница между интерфейсом и абстрактным классом? И почитай, наконец, Abstract Type.
H>Мамут, заниматься твоим образованием у меня нет ни желания ни времени. Если для тебя это одно и тоже, пребывай в своем мире и не парь мне мозг.
M>>
M>> In many object oriented programming languages, abstract types are known as abstract base classes, interfaces, traits, mixins, flavors, or roles. Note that these names refer to different language constructs which are (or may be) used to implement abstract types.
H>Нафига мне эти мэни лэнгвиджы? Я тебе говорю об идеологии, да еще и в конкретном языке, где абстрактный класс сравнивать с интерфейсом могут только личности с весьма оригинальным способом мышления.
Перевожу дословно:
Во многих объектно-ориентированх языках абстракные типы данных известны под названием абстрактных баовых классов, интерфейсов, трейтов, миксинов или ролей. Обратите внимание, что эти имена относятся к языковым конструкциям, которые являются абстрактными типами или могут быть использованы для их реализации
Где ты в этой цитате нашел хоть слово про "миниязыки" — убей меня, не пойму.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
H>>Так что Delphi со своими ANSI-строками еще и лишние ресурсы системы тратит каждый раз вызывая API-функцию с ANSI строкой в качестве параметра...
H>>Чья бы корова мычала, а нетеры бы почаще смотрели на счетчики .NET Interop #marshaling. Банальное возюканье мышой над меню/тулбаром Paint.NET, WLV приводит к офигительной накрутке этого счетчика
kuj>Ты хоть разберись сначала что это за счетчик.
Там и разбираться не с чем, perfmon имеет имеет описание, читай. Маршалинг менеджед-анменеджед нифига не дешев, а там циферки в районе 23000 буквально сразу после запуска.
kuj>Да, кстати, где? Где графический редактор с такой же функциональностью и интерфейсом, но написанный на Delphi?
Глухим (а в данном случае слепым) два раза обедню не служат. Я уже давал ссылку для ganjustas. Кстати фейс аля Office2003 (и пара десятков других тем) делается TBX'ом на раз. А если взять AlphaControls, так и вообще под все что угодно заскинить можно, хоть под халву.
Re[35]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, kuj, Вы писали:
kuj>>>>>Думаю, теперь ни у кого больше не возникнет вопрос "чем вам не угодил Delphi". В далеком 99м году еще на C++ писал с полной поддержкой юникод и в мыслях не было, что может потребоваться перехватывать API-вызовы для вывода юникод текста.
H>>>>На С++ с легкостью визуального построения фейса, как в Delphi?
kuj>>>У Microsoft Office достаточно сложный интерфейс? А у Visual Studio?..
H>>Тебе ключевые слова чтоль выделить? Ладно, выделяю: "с легкостью визуального построения фейса".
kuj>Что является критерием простоты построения интерфейса? И почему самые сложные интерфейсы пишутся в основном на C++?
Большинство софта вообще (для десктопов в частности), пишется на C/C++ и что?
kuj>>>WPF и Silverlight интерфейсы видел?
H>>Видел Видел WPF с размытыми шрифтами
kuj>Ась?
H>>А, это вообще вопрос к чему?
kuj>К тому, что Делфи уже давно как не лучший инструмент для построения пользовательских интерфейсов. Отсутствие поддержки юникод лишь усугубляет ситуацию.
Да-да, все передовые технологии построения гуя это разумеется тормоз WPF и серебрянная пародия на Flex/Air.
Здравствуйте, kuj, Вы писали:
H>>>>XML-RPC c SOAP имеют из общего, только пакеты в формате XML. SOAP это не XML-RPC, а XML-RPC не SOAP.
kuj>>>Ну хорошо, если придерживаться терминологии SOAP это не XML-RPC, хотя технически имеет те же характеристики и покрывает все варианты применения, что и XML-RPC.
H>>...и имеет чудное свойство -- несовместимость реализаций от разных вендоров Вроде разговаривают по SOAP, а понять друг-друга не могут Совместимость же со всея .Net, мне мало интересна.
kuj>Полная чушь. Вот веб-сервис на Java, вот клиент .NET — никаких проблем с маршалингом.
Об этой полной чуши написано даже по ссылке которую ты сам и давал
kuj>>>В составе .NET FW нет реализации XML-RPC банально потому, что есть SOAP — более функциональный и удобный.
H>>Очередной marketing-bullshit. Это ты расскажешь заказчику, у которого бизнес-процессы построены и на CORBA, и на SOAP, и на XML-RPC (большие системы имеют очень долгий цикл развития и целый зоопарк решений).
kuj>http://www.xml-rpc.net/
А кто-то говорил, что оно и нафиг не нужно ибо есть SOAP
kuj>>>К тому же, есть полноценный XML-сериализатор. В отличии от...
H>>А парсить умеете без загрузки всего дока в память?
kuj>Конечно умеет. StreamReader -> TextReader -> XmlSerializer
А веб-сервис парсит пакет по мере поступления или сперва полностью получит, а затем парсит?
H>>Распарсишь гиговый XML на машинке с 512 Мб на борту?
kuj>Это нереальная ситуация. Если у тебя XML растет до 1 GB и это не из-за base64 вставок, то пора править руки программистам.
Вполне реальная. Пусть даже с base64, какая разница.
H>>>>>>>>С шифрами все прикольнее... Ты в курсе, что криптография в Windows намеренно ослаблена? Какой в таком случае в них смысл...
kuj>>>>>>>Что значит ослаблена? Давай уж конкретнее и по пунктам.
H>>>>>>Ты не читал о применении 40 бит вместо 56 в DES (правда, я об этом тоже давненько читал)?
kuj>>>>>Ну ты вспомнил... Шифр, которому уже лет эдак 40... FYI, стандартным (нет, не ГОСТ, но AES) блочным симметричным шифром уже много лет как является Rijndael.
H>>>>Дело не в том, сколько лет прошло. Дело в тенденциях. kuj>>>В каких еще тенденциях?
H>>Реализация алгоритмов закрыта (с чего бы вдруг, алгоритмы-то известны ).
kuj>Исходники Windows закрыты. И что?
Никто и не просит открывать код Windows. Достаточно открыть код криптеров для ознакомления и анализа.
H>>Над безопасностью в Висте МС работала с АНБ.
kuj>И что?
Ты точно статью по ссылке читал?
H>>С чего вдруг?
kuj>Американская компания работает с американской службой. С чего вдруг? Сложный вопрос, что ни говори...
Вдумчиво перечитать
kuj>>>Еще раз повторяю DES уж много лет как не применяется в свете наличия гораздо лучших шифров, как например Rijndael.
H>>Да хоть каким современным будь здание, но если у него фундамент гнилой...
kuj>Аргументируй.
Я для кого тут ссылки приводил?
H>>Кстати, Rijndael не был лучшим по результам тестов на потенциальные уязвимости см. руководство TrueCrypt (там есть ссылочки на первоисточники).
kuj>Ссылки в студию.
Иди на TrueCrypt.org и читай. Мне не хочется из PDF'а ссылки выцарапывать.
H>>>>>>Ты не читал о чудном генераторе случайных чисел имеющем прикольную частоту повторения? К сожалению ссылок дать не могу, не коллекционирую... Можешь на "Компьютерре" почитать статьи за авторством Киви Берд'а.
kuj>>>>>Взялся за куш не говори, что не дюж — урлы на статьи в студию.
H>>>>Нашел одну. Но она не единственная.
kuj>>>Там, где требуется сверхнадежность в любом случае не будет использоваться стандартный генератор случайных чисел. В общем же случае, встроенного достаточно.
H>>В общем случае??? Будем юзать и надеяться, что мы никому не нужны
kuj>Это не имеет значения, если нет сверхмощностей, доступных только некоторым странам.
Да какие там сверхмощности... Ты статью читал??? Там ясно сказано, что ослабленные криптеры можно крошить чуть не на лету (и ведь, блин, авторы то из АНБ).
kuj>>>>>Да, кстати, никто не мешает использовать любой другой генератор случайного шума вплоть до железного генератора белого шума.
H>>>>Мы говорим о средствах уже включенных в FW (и которыми большинство и будет пользоваться).
kuj>>>Что, тем не менее, не мешает использовать другую реализацию генератора случайных чисел тогда, когда это требуется.
H>>Конечно не мешает, да только речь не о сторонних...
kuj>Да ну, а о чем же речь?
Ты начал рассказывать о имеющихся в FW средствах шифрования. Забыл?
kuj>>>Не брался. Я же не говорил "я прочитал на таком то сайте, что X успешно применили в Y проектах".
H>>Да, ты всего лишь сказал о десятках тысяч успешных внедрений... Абсолютно спотолочная цифра.
kuj>Не говорил. Не перекручивай слова. Впрочем, в случее (n)Hibernate весьма вероятно что десятки тысяч.
Другое дело, что фактически все внешние сборки во-первых: поставляются с исходниками и зачастую имеют хорошее покрытие unit-тестами (кстати, MS открыла исходные коды самого .NET Framework), во-вторых: имеют за плечами сотни и тысячи успешных проектов
Прошу прощения, ты тут о сотнях тысяч говорил, а я похерил на порядок...
kuj>>>>>У тебя есть сомнения, что тот же nHibernate не имеет за плечами тысячь успешных проектов? Ну так это исключительно от незнания enterprise программирования.
H>>>>С чего ты взял, что я сомневаюсь? Я тебя прошу слова свои подтвердить.
kuj>>>http://forum.hibernate.org/ Больше 50000 топиков, больше 200000 сообщений.
kuj>>>http://forum.hibernate.org/viewtopic.php?t=952439
H>>Хе-хе-хе. Да уж, форум это очень компетентный источник И из чего тут может следовать существование десятков тысяч успешных внедрений?
kuj>(n)Hibernate самая популярная O/RM уже много лет как. Если у тебя есть сомнения, то это лишь значит, что ты не имеешь представления об Enterprise-level проектах.
Повторяешься уже.
kuj>>>>>Тогда какой сакральный смысл в обязательном наследовании от IUnknown?
H>>>>Ссылки подсчитывать нужно.
kuj>>>Зачем?
H>>Для обеспечения управляемого времени жизни интерфейсных переменных и для совместимости с уже существующей COM.
kuj>Совершенно верно. Для совместимости с COM. Наконец до тебя дошло.
И для совместимости с COM. Разве это плохо?
H>>>>К тому же QueryInterface позволяет делать очень интересные вещи, типа получения интерфейса от объекта, который об этом интерфейсе ни сном ни духом и никогда его не реализовывал.
kuj>>>В любом случае один из предков реализовал.
H>>А вот и нет (даже не агрегирует ни кто). Сурпрайз?
kuj>Класс, наследующий интерфейс, обязан этот интерфейс реализовать. Если ты ломаешь идеологию, возвращая в QueryInterface ссылки на внешние объекты, то это характеризует платформу как абсолютно бредовую.
Никаких внешних объектов нет. Я вижу, что нападающие тут ты не сильно изобретательны (один про хэлперы не въезжает, другой мыслит шаблонно...)
kuj>>>Почему можно скастить объект к абстрактному предку без всяких QueryInterface`ов?
kuj>Значит не знаешь?
Просто вопрос бредовый... ибо наследование.
Re[33]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Mamut, Вы писали:
H>>>>А вот код: H>>>>
M>>>Тонна кода поскипана
H>>>>
M>>>Это называется легко и просто? Ну его нафиг.
H>>Два примитивнейших метода и еще одна процедура... Сложность аж зашкаливает
M>Зачем? Зачем мне писать системные хуки для простейших операций?
Ты хотел пример? Ты его получил. А я буду юзать TNT без зазрения совести.
M>>> In many object oriented programming languages, abstract types are known as abstract base classes, interfaces, traits, mixins, flavors, or roles. Note that these names refer to different language constructs which are (or may be) used to implement abstract types.
H>>Нафига мне эти мэни лэнгвиджы? Я тебе говорю об идеологии, да еще и в конкретном языке, где абстрактный класс сравнивать с интерфейсом могут только личности с весьма оригинальным способом мышления.
M>Перевожу дословно: M>
M>Во многих объектно-ориентированх языках абстракные типы данных известны под названием абстрактных баовых классов, интерфейсов, трейтов, миксинов или ролей. Обратите внимание, что эти имена относятся к языковым конструкциям, которые являются абстрактными типами или могут быть использованы для их реализации
M>Где ты в этой цитате нашел хоть слово про "миниязыки" — убей меня, не пойму.
Протри окуляры. Там написано "мэни". Убейся сам.
M>Весь остальной бред про "идеологию" поскипан
H>Если я пишу для Delphi программистов, мне странно писать на каком-либо другом языке... К тому же я написал, что с гуем работать скоро придется. Плюс мой опыт, плюс наработки, плюс мне нравятся Виртовские языки. Вам то какое дело до моего выбора?
А можно подробнее про ваш "опыт плюс наработки"? Выполненные проекты, скриншоты, кусочки исходников. Я, конечно, понимаю это были суперсекретные разработки, ноухау, NDA. Но все же, можно нам хоть издалека посмотреть на результаты, достигнутые с помощью этого супер-Delphi?
Просто после ваших рассуждений об интерфейсах... В общем, попробуйте понять почему все вокруг дураки а вы один такой в белом.
Delphi не любят, в том числе, за то, что слабые программисты пишут на нем не очень хорошие программы, пахнущие Delphi.
Re[36]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
kuj>>>>>>Думаю, теперь ни у кого больше не возникнет вопрос "чем вам не угодил Delphi". В далеком 99м году еще на C++ писал с полной поддержкой юникод и в мыслях не было, что может потребоваться перехватывать API-вызовы для вывода юникод текста.
H>>>>>На С++ с легкостью визуального построения фейса, как в Delphi?
kuj>>>>У Microsoft Office достаточно сложный интерфейс? А у Visual Studio?..
H>>>Тебе ключевые слова чтоль выделить? Ладно, выделяю: "с легкостью визуального построения фейса".
kuj>>Что является критерием простоты построения интерфейса? И почему самые сложные интерфейсы пишутся в основном на C++?
H>Большинство софта вообще (для десктопов в частности), пишется на C/C++ и что?
Подумай почему происходит так.
kuj>>>>WPF и Silverlight интерфейсы видел?
H>>>Видел Видел WPF с размытыми шрифтами
kuj>>Ась?
H>Двась. здесь
Это ClearType. В эпоху LCD вполне естественное решение включить его по-умолчанию.
H>>>А, это вообще вопрос к чему?
kuj>>К тому, что Делфи уже давно как не лучший инструмент для построения пользовательских интерфейсов. Отсутствие поддержки юникод лишь усугубляет ситуацию.
H>Да-да, все передовые технологии построения гуя это разумеется тормоз WPF и серебрянная пародия на Flex/Air.
Здравствуйте, abibok, Вы писали:
H>>Если я пишу для Delphi программистов, мне странно писать на каком-либо другом языке... К тому же я написал, что с гуем работать скоро придется. Плюс мой опыт, плюс наработки, плюс мне нравятся Виртовские языки. Вам то какое дело до моего выбора?
A>А можно подробнее про ваш "опыт плюс наработки"? Выполненные проекты, скриншоты, кусочки исходников. Я, конечно, понимаю это были суперсекретные разработки, ноухау, NDA. Но все же, можно нам хоть издалека посмотреть на результаты, достигнутые с помощью этого супер-Delphi?
Прикол в том, что к NDA тут прибегала как раз нападающая сторона, причем неоднократно Свой код я уже приводил (трижды), или нужен куcок библиотеки? А больше ничего не нужно? Скрины не коллекционирую, и как я уже писал, последний раз это было два года назад, и в другой конторе. А вообще попытка перейти на личность это признак слабой аргументной базы, а посему адью.
Re[37]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
H> H>Вот это ClearType???? А на моем буке тогда что, не ClearType чтоль? Чего-то я такого жопного замыливания не наблюдаю.
Похоже на несоответствие порядка субпикселей (на мониторе BGR, а ClearType думает, что RGB).
Здравствуйте, hattab, Вы писали:
H>>>>>XML-RPC c SOAP имеют из общего, только пакеты в формате XML. SOAP это не XML-RPC, а XML-RPC не SOAP.
kuj>>>>Ну хорошо, если придерживаться терминологии SOAP это не XML-RPC, хотя технически имеет те же характеристики и покрывает все варианты применения, что и XML-RPC.
H>>>...и имеет чудное свойство -- несовместимость реализаций от разных вендоров Вроде разговаривают по SOAP, а понять друг-друга не могут Совместимость же со всея .Net, мне мало интересна.
kuj>>Полная чушь. Вот веб-сервис на Java, вот клиент .NET — никаких проблем с маршалингом.
H>Об этой полной чуши написано даже по ссылке которую ты сам и давал
Еще раз для тех кто в танке: вот веб-сервис на Java, вот клиент .NET — никаких проблем с маршалингом. Что я делаю не так?
kuj>>>>В составе .NET FW нет реализации XML-RPC банально потому, что есть SOAP — более функциональный и удобный.
H>>>Очередной marketing-bullshit. Это ты расскажешь заказчику, у которого бизнес-процессы построены и на CORBA, и на SOAP, и на XML-RPC (большие системы имеют очень долгий цикл развития и целый зоопарк решений).
kuj>>http://www.xml-rpc.net/
H>А кто-то говорил, что оно и нафиг не нужно ибо есть SOAP
Естественно, оно не нужно в составе Framework — его и нет.
kuj>>>>К тому же, есть полноценный XML-сериализатор. В отличии от...
H>>>А парсить умеете без загрузки всего дока в память?
kuj>>Конечно умеет. StreamReader -> TextReader -> XmlSerializer
H>А веб-сервис парсит пакет по мере поступления или сперва полностью получит, а затем парсит?
RFTM про StreamReader, чтоли.
H>>>Распарсишь гиговый XML на машинке с 512 Мб на борту?
kuj>>Это нереальная ситуация. Если у тебя XML растет до 1 GB и это не из-за base64 вставок, то пора править руки программистам.
H>Вполне реальная. Пусть даже с base64, какая разница.
XML-RPC, поди? SOAP давно умеет бинарные данные передавать отдельно — бинарным потоком не кодируя в base64.
kuj>>Исходники Windows закрыты. И что?
H>Никто и не просит открывать код Windows. Достаточно открыть код криптеров для ознакомления и анализа.
H>>>Над безопасностью в Висте МС работала с АНБ.
kuj>>И что?
H>Ты точно статью по ссылке читал?
H>>>С чего вдруг?
kuj>>Американская компания работает с американской службой. С чего вдруг? Сложный вопрос, что ни говори...
H>Вдумчиво перечитать
Перечитал. При чем тут АНБ и какие-то там тенденции?
kuj>>>>Еще раз повторяю DES уж много лет как не применяется в свете наличия гораздо лучших шифров, как например Rijndael.
H>>>Да хоть каким современным будь здание, но если у него фундамент гнилой...
kuj>>Аргументируй.
H>Я для кого тут ссылки приводил?
В чем "гнилость фундамента" шифра Rijndael? Давай по пунктам.
H>>>Кстати, Rijndael не был лучшим по результам тестов на потенциальные уязвимости см. руководство TrueCrypt (там есть ссылочки на первоисточники).
kuj>>Ссылки в студию.
H>Иди на TrueCrypt.org и читай. Мне не хочется из PDF'а ссылки выцарапывать.
Ясно. Значит пустозвонство.
kuj>>Это не имеет значения, если нет сверхмощностей, доступных только некоторым странам.
H>Да какие там сверхмощности... Ты статью читал??? Там ясно сказано, что ослабленные криптеры можно крошить чуть не на лету (и ведь, блин, авторы то из АНБ).
Вот шифртекст. Не имея сверхмощностей, в приемлимые сроки дешифровать его ты не сможешь. Конец истории.
kuj>>>>Что, тем не менее, не мешает использовать другую реализацию генератора случайных чисел тогда, когда это требуется.
H>>>Конечно не мешает, да только речь не о сторонних...
kuj>>Да ну, а о чем же речь?
H>Ты начал рассказывать о имеющихся в FW средствах шифрования. Забыл?
Генератор случайных чисел не является средством шифрования. Не знал?
kuj>>>>Не брался. Я же не говорил "я прочитал на таком то сайте, что X успешно применили в Y проектах".
H>>>Да, ты всего лишь сказал о десятках тысяч успешных внедрений... Абсолютно спотолочная цифра.
kuj>>Не говорил. Не перекручивай слова. Впрочем, в случее (n)Hibernate весьма вероятно что десятки тысяч.
H>
H>Другое дело, что фактически все внешние сборки во-первых: поставляются с исходниками и зачастую имеют хорошее покрытие unit-тестами (кстати, MS открыла исходные коды самого .NET Framework), во-вторых: имеют за плечами сотни и тысячи успешных проектов
H>Прошу прощения, ты тут о сотнях тысяч говорил, а я похерил на порядок...
Так и запишем: hattab не умеет читать. Прочти чтоли вдумчиво то, что ты выделил.
kuj>>(n)Hibernate самая популярная O/RM уже много лет как. Если у тебя есть сомнения, то это лишь значит, что ты не имеешь представления об Enterprise-level проектах.
H>Повторяешься уже.
Констатирую факт.
kuj>>>>>>Тогда какой сакральный смысл в обязательном наследовании от IUnknown?
H>>>>>Ссылки подсчитывать нужно.
kuj>>>>Зачем?
H>>>Для обеспечения управляемого времени жизни интерфейсных переменных и для совместимости с уже существующей COM.
kuj>>Совершенно верно. Для совместимости с COM. Наконец до тебя дошло.
H>И для совместимости с COM. Разве это плохо?
Плохо то, как их реализовали — ОЧЕНЬ плохо, что не возможен кастинг объектов к любому из предков интерфейса. Плохо то, что надо либо наследоваться от TInterfacedObject, либо реализовывать AddRef, Release, QueryInterface — плохо, т.к. оверхид и лишняя работа.
Интерфейсы в Делфи это жалкий костыль добавленный исключительно для работы с COM, а не как полноценная сущность ООП.
kuj>>Класс, наследующий интерфейс, обязан этот интерфейс реализовать. Если ты ломаешь идеологию, возвращая в QueryInterface ссылки на внешние объекты, то это характеризует платформу как абсолютно бредовую.
H>Никаких внешних объектов нет. Я вижу, что нападающие тут ты не сильно изобретательны (один про хэлперы не въезжает, другой мыслит шаблонно...)
Просвяти, будь так добр.
kuj>>>>Почему можно скастить объект к абстрактному предку без всяких QueryInterface`ов?
kuj>>Значит не знаешь?
H>Просто вопрос бредовый... ибо наследование.
Наследование это сферический конь в банаховом пространстве. Почему в случае наследования не нужен QueryInterface?
Re[38]: наши менеджеры памяти самые менеджеристые менеджеры
kuj>>Это ClearType. В эпоху LCD вполне естественное решение включить его по-умолчанию.
H>
H>Вот это ClearType???? А на моем буке тогда что, не ClearType чтоль? Чего-то я такого жопного замыливания не наблюдаю.
Посмотришь на ЭЛТ мониторе — увидишь.
Re[34]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
M>>>>Это называется легко и просто? Ну его нафиг.
H>>>Два примитивнейших метода и еще одна процедура... Сложность аж зашкаливает
M>>Зачем? Зачем мне писать системные хуки для простейших операций?
H>Ты хотел пример? Ты его получил. А я буду юзать TNT без зазрения совести.
То есть чтоб в Delphi получить unicode надо еще по 60 евро за лицензию TNT выкладывать? Зашибись.
Re[39]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Cyberax, Вы писали:
H>> H>>Вот это ClearType???? А на моем буке тогда что, не ClearType чтоль? Чего-то я такого жопного замыливания не наблюдаю. C>Похоже на несоответствие порядка субпикселей (на мониторе BGR, а ClearType думает, что RGB).
Это же не фотография экрана... К тому же в той теме автор писал:
но при ресайзе окна и быстром однократном нажатии на кнопку текст на ней замыливается, а потом трансформируется обратно в читаемое состояние
Здравствуйте, kuj, Вы писали:
H>>>>>>XML-RPC c SOAP имеют из общего, только пакеты в формате XML. SOAP это не XML-RPC, а XML-RPC не SOAP.
kuj>>>>>Ну хорошо, если придерживаться терминологии SOAP это не XML-RPC, хотя технически имеет те же характеристики и покрывает все варианты применения, что и XML-RPC.
H>>>>...и имеет чудное свойство -- несовместимость реализаций от разных вендоров Вроде разговаривают по SOAP, а понять друг-друга не могут Совместимость же со всея .Net, мне мало интересна.
kuj>>>Полная чушь. Вот веб-сервис на Java, вот клиент .NET — никаких проблем с маршалингом.
H>>Об этой полной чуши написано даже по ссылке которую ты сам и давал
kuj>Еще раз для тех кто в танке: вот веб-сервис на Java, вот клиент .NET — никаких проблем с маршалингом. Что я делаю не так?
У тебя работает и ты спокоен. У твоего заказчика перестанет и станешь в неудобную позу. Вот и все дела.
kuj>>>>>В составе .NET FW нет реализации XML-RPC банально потому, что есть SOAP — более функциональный и удобный.
H>>>>Очередной marketing-bullshit. Это ты расскажешь заказчику, у которого бизнес-процессы построены и на CORBA, и на SOAP, и на XML-RPC (большие системы имеют очень долгий цикл развития и целый зоопарк решений).
kuj>>>http://www.xml-rpc.net/
H>>А кто-то говорил, что оно и нафиг не нужно ибо есть SOAP
kuj>Естественно, оно не нужно в составе Framework — его и нет.
kuj>>>>>К тому же, есть полноценный XML-сериализатор. В отличии от...
H>>>>А парсить умеете без загрузки всего дока в память?
kuj>>>Конечно умеет. StreamReader -> TextReader -> XmlSerializer
H>>А веб-сервис парсит пакет по мере поступления или сперва полностью получит, а затем парсит?
kuj>RFTM про StreamReader, чтоли.
В следующий раз я тебя к исходникам VCL отправлю, ты не удивляйся.
H>>>>Распарсишь гиговый XML на машинке с 512 Мб на борту?
kuj>>>Это нереальная ситуация. Если у тебя XML растет до 1 GB и это не из-за base64 вставок, то пора править руки программистам.
H>>Вполне реальная. Пусть даже с base64, какая разница.
kuj>XML-RPC, поди? SOAP давно умеет бинарные данные передавать отдельно — бинарным потоком не кодируя в base64.
XML-RPC с рождения умеет бинарные данные передавать без base64. Ну так ответь на вопрос-то.
H>>>>Над безопасностью в Висте МС работала с АНБ.
kuj>>>И что?
H>>Ты точно статью по ссылке читал?
H>>>>С чего вдруг?
kuj>>>Американская компания работает с американской службой. С чего вдруг? Сложный вопрос, что ни говори...
H>>Вдумчиво перечитать
kuj>Перечитал. При чем тут АНБ и какие-то там тенденции?
Мдя...
kuj>>>>>Еще раз повторяю DES уж много лет как не применяется в свете наличия гораздо лучших шифров, как например Rijndael.
H>>>>Да хоть каким современным будь здание, но если у него фундамент гнилой...
kuj>>>Аргументируй.
H>>Я для кого тут ссылки приводил?
kuj>В чем "гнилость фундамента" шифра Rijndael? Давай по пунктам.
Ппц... Про рандомные генераторы читал?
H>>>>Кстати, Rijndael не был лучшим по результам тестов на потенциальные уязвимости см. руководство TrueCrypt (там есть ссылочки на первоисточники).
kuj>>>Ссылки в студию.
H>>Иди на TrueCrypt.org и читай. Мне не хочется из PDF'а ссылки выцарапывать.
kuj>Ясно. Значит пустозвонство.
Я тебе адрес дал. Интересно -- иди и читай.
kuj>>>Это не имеет значения, если нет сверхмощностей, доступных только некоторым странам.
H>>Да какие там сверхмощности... Ты статью читал??? Там ясно сказано, что ослабленные криптеры можно крошить чуть не на лету (и ведь, блин, авторы то из АНБ).
kuj>Вот шифртекст. Не имея сверхмощностей, в приемлимые сроки дешифровать его ты не сможешь. Конец истории.
Т.е. не читал таки...
kuj>>>>>Что, тем не менее, не мешает использовать другую реализацию генератора случайных чисел тогда, когда это требуется.
H>>>>Конечно не мешает, да только речь не о сторонних...
kuj>>>Да ну, а о чем же речь?
H>>Ты начал рассказывать о имеющихся в FW средствах шифрования. Забыл?
kuj>Генератор случайных чисел не является средством шифрования. Не знал?
Без него они не обходятся, не знал?
kuj>>>>>Не брался. Я же не говорил "я прочитал на таком то сайте, что X успешно применили в Y проектах".
H>>>>Да, ты всего лишь сказал о десятках тысяч успешных внедрений... Абсолютно спотолочная цифра.
kuj>>>Не говорил. Не перекручивай слова. Впрочем, в случее (n)Hibernate весьма вероятно что десятки тысяч.
H>>
H>>Другое дело, что фактически все внешние сборки во-первых: поставляются с исходниками и зачастую имеют хорошее покрытие unit-тестами (кстати, MS открыла исходные коды самого .NET Framework), во-вторых: имеют за плечами сотни и тысячи успешных проектов
H>>Прошу прощения, ты тут о сотнях тысяч говорил, а я похерил на порядок...
kuj>Так и запишем: hattab не умеет читать. Прочти чтоли вдумчиво то, что ты выделил.
Мой косяк, признаю
kuj>>>Совершенно верно. Для совместимости с COM. Наконец до тебя дошло.
H>>И для совместимости с COM. Разве это плохо?
kuj>Плохо то, как их реализовали — ОЧЕНЬ плохо, что не возможен кастинг объектов к любому из предков интерфейса. Плохо то, что надо либо наследоваться от TInterfacedObject, либо реализовывать AddRef, Release, QueryInterface — плохо, т.к. оверхид и лишняя работа.
Кастить можно к любому заявленному реализованным предку интерфейса. Написано об этом раз десять уже. В чем проблема наследования от TInterfacedObject? Религия?
kuj>Интерфейсы в Делфи это жалкий костыль добавленный исключительно для работы с COM, а не как полноценная сущность ООП.
Весьма полноценная абстракция коей они и являются.
kuj>>>Класс, наследующий интерфейс, обязан этот интерфейс реализовать. Если ты ломаешь идеологию, возвращая в QueryInterface ссылки на внешние объекты, то это характеризует платформу как абсолютно бредовую.
H>>Никаких внешних объектов нет. Я вижу, что нападающие тут ты не сильно изобретательны (один про хэлперы не въезжает, другой мыслит шаблонно...)
kuj>Просвяти, будь так добр.
Ну вот, я говорил про исходиники VCL... Ознакомься с RIO.pas
kuj>>>>>Почему можно скастить объект к абстрактному предку без всяких QueryInterface`ов?
kuj>>>Значит не знаешь?
H>>Просто вопрос бредовый... ибо наследование.
kuj>Наследование это сферический конь в банаховом пространстве. Почему в случае наследования не нужен QueryInterface?
На момент компиляции все известно, чего там запрашивать? Ты попробуй обойтись без QueryInterface при работе с интерфейсом полученныйм от внешнего источника в виде базового IUnknown.
Re[39]: наши менеджеры памяти самые менеджеристые менеджеры
kuj>>>Это ClearType. В эпоху LCD вполне естественное решение включить его по-умолчанию.
H>>
H>>Вот это ClearType???? А на моем буке тогда что, не ClearType чтоль? Чего-то я такого жопного замыливания не наблюдаю.
kuj>Посмотришь на ЭЛТ мониторе — увидишь.
Я и на ЭЛТ такого не видел при включенном ClearType. А у автора вовсе не ЭЛТ, да и проверял он на нескольких машинках.
Re[35]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
M>>>>>Это называется легко и просто? Ну его нафиг.
H>>>>Два примитивнейших метода и еще одна процедура... Сложность аж зашкаливает
M>>>Зачем? Зачем мне писать системные хуки для простейших операций?
H>>Ты хотел пример? Ты его получил. А я буду юзать TNT без зазрения совести.
kuj>То есть чтоб в Delphi получить unicode надо еще по 60 евро за лицензию TNT выкладывать? Зашибись.
Они бесплатные были до 2.3.0. Сейчас их TMS купила, но бесплатную версию скачать можно. Да и вообще, к осени 2008 выйдет с юникодом.
hattab пишет: > kuj>К тому же, есть полноценный XML-сериализатор. В отличии от... > > А парсить умеете без загрузки всего дока в память? Распарсишь гиговый > XML на машинке с 512 Мб на борту?
Сдаётся мне, в .NET для XML есть как DOM, так и SAX.
abibok пишет: > Просто после ваших рассуждений об интерфейсах... В общем, попробуйте > понять почему все вокруг дураки а вы один такой в белом. > Delphi не любят, в том числе, за то, что слабые программисты пишут на > нем не очень хорошие программы, пахнущие Delphi.
C++ не люблю в том числе и за то, что в университетах спаунят толпы
леммингов++, а потом они пишут на нём не очень хорошие программы,
пахнущие C++
OCT>abibok пишет: >> Просто после ваших рассуждений об интерфейсах... В общем, попробуйте >> понять почему все вокруг дураки а вы один такой в белом. >> Delphi не любят, в том числе, за то, что слабые программисты пишут на >> нем не очень хорошие программы, пахнущие Delphi. OCT>C++ не люблю в том числе и за то, что в университетах спаунят толпы OCT>леммингов++, а потом они пишут на нём не очень хорошие программы, OCT>пахнущие C++
1. Обратите внимание на выделенное. Не люблю — ваше личное отношение к языку и только. Не любят — это когда возникают вот такие темы "Чем вам всем не угодил Delphi".
2. При чем здесь университеты? Мы говорим о тех, у кого программирование является профессией. Новичков и леммингов хватает и в Delphi, и в C++. Но на С++ есть огромное количество отличных программистов, а про Delphi я бы такого не сказал.
abibok пишет: > 2. При чем здесь университеты? Мы говорим о тех, у кого программирование > является профессией. Новичков и леммингов хватает и в Delphi, и в C++. > Но на С++ есть огромное количество отличных программистов, а про Delphi > я бы такого не сказал.
На Delphi тоже есть огромное количество отличных программистов. Правда,
со временем они имеют тендецию уходят на Аду или Оберон–2.
OCT>На Delphi тоже есть огромное количество отличных программистов. Правда, OCT>со временем они имеют тендецию уходят на Аду или Оберон–2.
Очень может быть, люди набираются опыта, учатся новому, начинают видеть недостатки старых инструментов и преимущества новых. А кто-то так и остается на Delphi.
Что-то я не вижу отличных дельфистов на RSDN. А те что есть показывают дремучее незнание ООП и современных технологий + странные амбиции. Лично я непосредственно общался с несколькими программистами на Delphi. Видимо где-то мы друг друга не поняли, потому что к себе в проект я бы их не взял. Все по той же причине.
abibok пишет: > Что-то я не вижу отличных дельфистов на RSDN. А те что есть показывают > дремучее незнание ООП и современных технологий + странные амбиции. Лично > я непосредственно общался с несколькими программистами на Delphi. Видимо > где-то мы друг друга не поняли, потому что к себе в проект я бы их не > взял. Все по той же причине.
"Отличные" можно понимать по–разному. На Паскале много олимпиадников
выросло. В школьные годы все, как один, писали олимпиады на этом языке.
Вот только не знаю, сколько из них [олимпиадников] вообще сидят на
форумах, в том числе RSDN.
OCT>"Отличные" можно понимать по–разному. На Паскале много олимпиадников OCT>выросло. В школьные годы все, как один, писали олимпиады на этом языке.
OCT>Вот только не знаю, сколько из них [олимпиадников] вообще сидят на OCT>форумах, в том числе RSDN.
Ну я был олимпиадником. Областные — на GW-BASIC, республиканские — на Turbo Pascal. На первых курсах университета писал на Delphi и С++ Builder. Потом полностью перешел на С++, а сейчас — на C#.
Здравствуйте, hattab, Вы писали:
kuj>>То есть чтоб в Delphi получить unicode надо еще по 60 евро за лицензию TNT выкладывать? Зашибись.
H>Они бесплатные были до 2.3.0. Сейчас их TMS купила, но бесплатную версию скачать можно. Да и вообще, к осени 2008 выйдет с юникодом.
Ну мы очень рады. Только припоздали они лет так на 8.
kuj>>Еще раз для тех кто в танке: вот веб-сервис на Java, вот клиент .NET — никаких проблем с маршалингом. Что я делаю не так?
H>У тебя работает и ты спокоен. У твоего заказчика перестанет и станешь в неудобную позу. Вот и все дела.
Я говорю про production, которому уже 4 года. "Вот и все дела".
kuj>>>>>>В составе .NET FW нет реализации XML-RPC банально потому, что есть SOAP — более функциональный и удобный.
H>>>>>Очередной marketing-bullshit. Это ты расскажешь заказчику, у которого бизнес-процессы построены и на CORBA, и на SOAP, и на XML-RPC (большие системы имеют очень долгий цикл развития и целый зоопарк решений).
kuj>>>>http://www.xml-rpc.net/
H>>>А кто-то говорил, что оно и нафиг не нужно ибо есть SOAP
kuj>>Естественно, оно не нужно в составе Framework — его и нет.
H>
Что тебя так насмешило? Расскажи я тоже хочу посмеяться.
kuj>>>>>>К тому же, есть полноценный XML-сериализатор. В отличии от...
H>>>>>А парсить умеете без загрузки всего дока в память?
kuj>>>>Конечно умеет. StreamReader -> TextReader -> XmlSerializer
H>>>А веб-сервис парсит пакет по мере поступления или сперва полностью получит, а затем парсит?
kuj>>RFTM про StreamReader, чтоли.
H>В следующий раз я тебя к исходникам VCL отправлю, ты не удивляйся.
При чем тут исходники? hattab, Delphi оказывает паршивое влияние на мыслительные процессы.
kuj>>>>Это нереальная ситуация. Если у тебя XML растет до 1 GB и это не из-за base64 вставок, то пора править руки программистам.
H>>>Вполне реальная. Пусть даже с base64, какая разница.
kuj>>XML-RPC, поди? SOAP давно умеет бинарные данные передавать отдельно — бинарным потоком не кодируя в base64.
H>XML-RPC с рождения умеет бинарные данные передавать без base64.
Да ну, серьезно? Ну-ка, ну-ка, ссылку на место в спецификации, где описано как XML-RPC передает бинарные данные без кодирования их в один из текстовых форматов.
H>>>>>Над безопасностью в Висте МС работала с АНБ.
kuj>>>>И что?
H>>>Ты точно статью по ссылке читал?
H>>>>>С чего вдруг?
kuj>>>>Американская компания работает с американской службой. С чего вдруг? Сложный вопрос, что ни говори...
H>>>Вдумчиво перечитать
kuj>>Перечитал. При чем тут АНБ и какие-то там тенденции?
H>Мдя...
Ты сам хоть понимаешь какую чушь несешь? По твоей ссылке лишь сказано, что в какой-то старой версии Windows был криво реализованный генератор случайных чисел, цепочки которого можно с помощью специальной атаки предугадывать наперед, имея доступ к компьютеру. Потом было сказано, что они не знают точно справедливо ли это для Windows XP и уж тем более ничего не сказано о Vista, АНБ, реализации генератора в .NET (исходники которой открыты, FYI) и каких-то там тенденциях.
Random Class
Represents a pseudo-random number generator, a device that produces a sequence of numbers that meet certain statistical requirements for randomness.
Namespace: System
Assembly: mscorlib (in mscorlib.dll)
Pseudo-random numbers are chosen with equal probability from a finite set of numbers. The chosen numbers are not completely random because a definite mathematical algorithm is used to select them, but they are sufficiently random for practical purposes. The current implementation of the Random class is based on Donald E. Knuth's subtractive random number generator algorithm. For more information, see D. E. Knuth. "The Art of Computer Programming, volume 2: Seminumerical Algorithms". Addision-Wesley, Reading, MA, second edition, 1981."
Если у тебя есть сомнения по поводу .NET реализации генератора случайных чисел рисуешь трехмерную систему координат и куб со стороной 1, заполняешь этот куб точками, координаты которых получены с помощью данного генератора. Любую существенную неравномерность распределения можно будет увидеть на глаз, если таковая имеет место быть.
kuj>>>>>>Еще раз повторяю DES уж много лет как не применяется в свете наличия гораздо лучших шифров, как например Rijndael.
H>>>>>Да хоть каким современным будь здание, но если у него фундамент гнилой...
kuj>>>>Аргументируй.
H>>>Я для кого тут ссылки приводил?
kuj>>В чем "гнилость фундамента" шифра Rijndael? Давай по пунктам.
H>Ппц... Про рандомные генераторы читал?
Какое они имеют отношение к шифру Rijndael? Представь себе, я могу подставить любую реализацию ГСЧ.
H>>>>>Кстати, Rijndael не был лучшим по результам тестов на потенциальные уязвимости см. руководство TrueCrypt (там есть ссылочки на первоисточники).
kuj>>>>Ссылки в студию.
H>>>Иди на TrueCrypt.org и читай. Мне не хочется из PDF'а ссылки выцарапывать.
kuj>>Ясно. Значит пустозвонство.
H>Я тебе адрес дал. Интересно -- иди и читай.
google.com тебе противоречит. Интересно? Иди и читай.
kuj>>>>Это не имеет значения, если нет сверхмощностей, доступных только некоторым странам.
H>>>Да какие там сверхмощности... Ты статью читал??? Там ясно сказано, что ослабленные криптеры можно крошить чуть не на лету (и ведь, блин, авторы то из АНБ).
kuj>>Вот шифртекст. Не имея сверхмощностей, в приемлимые сроки дешифровать его ты не сможешь. Конец истории.
H>Т.е. не читал таки...
hattab тебе стоит почитать больше о криптографии.
kuj>>>>>>Что, тем не менее, не мешает использовать другую реализацию генератора случайных чисел тогда, когда это требуется.
H>>>>>Конечно не мешает, да только речь не о сторонних...
kuj>>>>Да ну, а о чем же речь?
H>>>Ты начал рассказывать о имеющихся в FW средствах шифрования. Забыл?
kuj>>Генератор случайных чисел не является средством шифрования. Не знал?
H>Без него они не обходятся, не знал?
Алгоритмы шифрования в .NET FW не завязаны на конкретной реализации ГСЧ. Не знал?
kuj>>>>Совершенно верно. Для совместимости с COM. Наконец до тебя дошло.
H>>>И для совместимости с COM. Разве это плохо?
kuj>>Плохо то, как их реализовали — ОЧЕНЬ плохо, что не возможен кастинг объектов к любому из предков интерфейса. Плохо то, что надо либо наследоваться от TInterfacedObject, либо реализовывать AddRef, Release, QueryInterface — плохо, т.к. оверхид и лишняя работа.
H>Кастить можно к любому заявленному реализованным предку интерфейса. Написано об этом раз десять уже.
Какой смысл в наследовании интерфейсов, в таком случае? Ведь все-равно, чтоб обратиться к методам и свойствам предка придется явно указывать, что класс реализует конкретно этого предка.
H>В чем проблема наследования от TInterfacedObject? Религия?
legacy код.
kuj>>Интерфейсы в Делфи это жалкий костыль добавленный исключительно для работы с COM, а не как полноценная сущность ООП.
H>Весьма полноценная абстракция коей они и являются.
Продолжай повторять себе это. Ты зациклен в своем ограниченном мирке и даже представления не имеешь что такое настоящее ООП с применением таких техник как IoC/DI.
kuj>>>>Класс, наследующий интерфейс, обязан этот интерфейс реализовать. Если ты ломаешь идеологию, возвращая в QueryInterface ссылки на внешние объекты, то это характеризует платформу как абсолютно бредовую.
H>>>Никаких внешних объектов нет. Я вижу, что нападающие тут ты не сильно изобретательны (один про хэлперы не въезжает, другой мыслит шаблонно...)
kuj>>Просвяти, будь так добр.
H>Ну вот, я говорил про исходиники VCL... Ознакомься с RIO.pas
Мда, значит очередное пустозвонство. Так и запишем.
kuj>>>>>>Почему можно скастить объект к абстрактному предку без всяких QueryInterface`ов?
kuj>>>>Значит не знаешь?
H>>>Просто вопрос бредовый... ибо наследование.
kuj>>Наследование это сферический конь в банаховом пространстве. Почему в случае наследования не нужен QueryInterface?
H>На момент компиляции все известно, чего там запрашивать? Ты попробуй обойтись без QueryInterface при работе с интерфейсом полученныйм от внешнего источника в виде базового IUnknown.
Представь себе за "базовым IUnknown" всегда лежит конкретный объект, который его реализует. Продолжать?..
Mamut пишет: > OCT>На Delphi тоже есть огромное количество отличных программистов. Правда, > OCT>со временем они имеют тендецию уходят на Аду или Оберон–2. > > Ну или на .NET
Если только на Зоннон. Иначе что может наш статистический олимпиадник
найти в .NET?
Я просто помню, как Delphi 8 в штыки встретили. Совсем не то, что от неё
ожидалось. Ну вообще не то. Тошнотворная
псевдообъектно–ориентированность. Совершенно извращённый взгляд на мир.
Классами называются всё, что ни попадя. Классы–утилиты, ну где это
видано? Классы–утилиты у нормальных людей называются модулями или
пакетами, финальные классы называются типами. Обычными типами, а не
классами. Не помню, чтоб кого–то в ту неделю пропёрло с этой дряни.
Здравствуйте, OCTAGRAM, Вы писали:
>> kuj>К тому же, есть полноценный XML-сериализатор. В отличии от... >> >> А парсить умеете без загрузки всего дока в память? Распарсишь гиговый >> XML на машинке с 512 Мб на борту? OCT>Сдаётся мне, в .NET для XML есть как DOM, так и SAX.
В том, что там есть SAX сомнений нет. Вопрос в другом: что используется по умолчанию в веб-сервисах (т.е. без ковыряния ручками).
Здравствуйте, Mamut, Вы писали:
M>>>Где ты в этой цитате нашел хоть слово про "миниязыки" — убей меня, не пойму.
H>>Протри окуляры. Там написано "мэни". Убейся сам.
M>Мэни — это не мини. Иди учи английский
У меня было написано "мэни". У МЕНЯ!!! Протри окуляры, уже.
M>>>Весь остальной бред про "идеологию" поскипан
H>>Вот и думаю, а мож послать вас?
M>Пошли, если бана не боишься
Здравствуйте, kuj, Вы писали:
kuj>>>Еще раз для тех кто в танке: вот веб-сервис на Java, вот клиент .NET — никаких проблем с маршалингом. Что я делаю не так?
H>>У тебя работает и ты спокоен. У твоего заказчика перестанет и станешь в неудобную позу. Вот и все дела.
kuj>Я говорю про production, которому уже 4 года. "Вот и все дела".
Я тебе уже сказал, где ты можешь почитать о существующих несовместимостях. Чего ты мне своим продакшеном тычешь? Твои личные проекты это твое дело. Я сказал о существующих проблемах SOAP, как протокола, а ты мне "но у меня же работает"...
H>>>>А кто-то говорил, что оно и нафиг не нужно ибо есть SOAP
kuj>>>Естественно, оно не нужно в составе Framework — его и нет.
H>>
kuj>Что тебя так насмешило? Расскажи я тоже хочу посмеяться.
Если оно действительно ненужно, зачем тогда сторонние тулы? MS'у понятное дело ничего кроме своего ненужно...
kuj>>>>>>>К тому же, есть полноценный XML-сериализатор. В отличии от...
H>>>>>>А парсить умеете без загрузки всего дока в память?
kuj>>>>>Конечно умеет. StreamReader -> TextReader -> XmlSerializer
H>>>>А веб-сервис парсит пакет по мере поступления или сперва полностью получит, а затем парсит?
kuj>>>RFTM про StreamReader, чтоли.
H>>В следующий раз я тебя к исходникам VCL отправлю, ты не удивляйся.
kuj>При чем тут исходники? hattab, Delphi оказывает паршивое влияние на мыслительные процессы.
Вместо нескольких предложений с объяснением, легче сказать RTFM. Вот и я тебе скажу RTFM или в исходники пошлю. Мысль понятна?
kuj>>>>>Это нереальная ситуация. Если у тебя XML растет до 1 GB и это не из-за base64 вставок, то пора править руки программистам.
H>>>>Вполне реальная. Пусть даже с base64, какая разница.
kuj>>>XML-RPC, поди? SOAP давно умеет бинарные данные передавать отдельно — бинарным потоком не кодируя в base64.
H>>XML-RPC с рождения умеет бинарные данные передавать без base64.
kuj>Да ну, серьезно? Ну-ка, ну-ка, ссылку на место в спецификации, где описано как XML-RPC передает бинарные данные без кодирования их в один из текстовых форматов.
What characters are allowed in strings? Non-printable characters? Null characters? Can a "string" be used to hold an arbitrary chunk of binary data?
Any characters are allowed in a string except < and &, which are encoded as < and &. A string can be used to encode binary data.
Экранируем требуемое и все.
H>>>>>>Над безопасностью в Висте МС работала с АНБ.
kuj>>>>>И что?
H>>>>Ты точно статью по ссылке читал?
H>>>>>>С чего вдруг?
kuj>>>>>Американская компания работает с американской службой. С чего вдруг? Сложный вопрос, что ни говори...
H>>>>Вдумчиво перечитать
kuj>>>Перечитал. При чем тут АНБ и какие-то там тенденции?
H>>Мдя...
kuj>Ты сам хоть понимаешь какую чушь несешь? По твоей ссылке лишь сказано, что в какой-то старой версии Windows был криво реализованный генератор случайных чисел, цепочки которого можно с помощью специальной атаки предугадывать наперед, имея доступ к компьютеру. Потом было сказано, что они не знают точно справедливо ли это для Windows XP и уж тем более ничего не сказано о Vista, АНБ, реализации генератора в .NET (исходники которой открыты, FYI) и каких-то там тенденциях.
kuj>
kuj>Random Class
kuj>Represents a pseudo-random number generator, a device that produces a sequence of numbers that meet certain statistical requirements for randomness.
kuj>Namespace: System
kuj>Assembly: mscorlib (in mscorlib.dll)
kuj>Pseudo-random numbers are chosen with equal probability from a finite set of numbers. The chosen numbers are not completely random because a definite mathematical algorithm is used to select them, but they are sufficiently random for practical purposes. The current implementation of the Random class is based on Donald E. Knuth's subtractive random number generator algorithm. For more information, see D. E. Knuth. "The Art of Computer Programming, volume 2: Seminumerical Algorithms". Addision-Wesley, Reading, MA, second edition, 1981."
kuj>Если у тебя есть сомнения по поводу .NET реализации генератора случайных чисел рисуешь трехмерную систему координат и куб со стороной 1, заполняешь этот куб точками, координаты которых получены с помощью данного генератора. Любую существенную неравномерность распределения можно будет увидеть на глаз, если таковая имеет место быть.
Ладно. Не напрягайся. Я вижу, что ты ничего не хочешь видеть и веришь всему что тебе преподносит МС. Крепкого сна.
kuj>>>>>>>Еще раз повторяю DES уж много лет как не применяется в свете наличия гораздо лучших шифров, как например Rijndael.
H>>>>>>Да хоть каким современным будь здание, но если у него фундамент гнилой...
kuj>>>>>Аргументируй.
H>>>>Я для кого тут ссылки приводил?
kuj>>>В чем "гнилость фундамента" шифра Rijndael? Давай по пунктам.
H>>Ппц... Про рандомные генераторы читал?
kuj>Какое они имеют отношение к шифру Rijndael? Представь себе, я могу подставить любую реализацию ГСЧ.
Да что ты пристал к этому AES??? Криптография AES'ом не ограничивается. Я же тебе сразу сказал о тенденциях...
H>>>>>>Кстати, Rijndael не был лучшим по результам тестов на потенциальные уязвимости см. руководство TrueCrypt (там есть ссылочки на первоисточники).
kuj>>>>>Ссылки в студию.
H>>>>Иди на TrueCrypt.org и читай. Мне не хочется из PDF'а ссылки выцарапывать.
kuj>>>Ясно. Значит пустозвонство.
H>>Я тебе адрес дал. Интересно -- иди и читай.
kuj>google.com тебе противоречит. Интересно? Иди и читай.
Я тебе вполне конкретный сайт указал, там найдешь руководство пользователя и вперед.
kuj>>>>>>>Что, тем не менее, не мешает использовать другую реализацию генератора случайных чисел тогда, когда это требуется.
H>>>>>>Конечно не мешает, да только речь не о сторонних...
kuj>>>>>Да ну, а о чем же речь?
H>>>>Ты начал рассказывать о имеющихся в FW средствах шифрования. Забыл?
kuj>>>Генератор случайных чисел не является средством шифрования. Не знал?
H>>Без него они не обходятся, не знал?
kuj>Алгоритмы шифрования в .NET FW не завязаны на конкретной реализации ГСЧ. Не знал?
И сколько раз мне повторить, что обсуждаются тут встроенные средства, а не сторонние?
kuj>>>>>Совершенно верно. Для совместимости с COM. Наконец до тебя дошло.
H>>>>И для совместимости с COM. Разве это плохо?
kuj>>>Плохо то, как их реализовали — ОЧЕНЬ плохо, что не возможен кастинг объектов к любому из предков интерфейса. Плохо то, что надо либо наследоваться от TInterfacedObject, либо реализовывать AddRef, Release, QueryInterface — плохо, т.к. оверхид и лишняя работа.
H>>Кастить можно к любому заявленному реализованным предку интерфейса. Написано об этом раз десять уже.
kuj>Какой смысл в наследовании интерфейсов, в таком случае? Ведь все-равно, чтоб обратиться к методам и свойствам предка придется явно указывать, что класс реализует конкретно этого предка.
Я проблемы понять не могу... Сложно вместо MyInterface написать IInterface, MyInterface? Причем только в том классе, которые его действительно реализует, потомки также будут его реализовать, но декларировать это от них не требуется.
H>>В чем проблема наследования от TInterfacedObject? Религия?
kuj>legacy код.
Какое еще наследие? Ты что? Этот TInterfacedObject существует с 3 версии...
kuj>>>>>Класс, наследующий интерфейс, обязан этот интерфейс реализовать. Если ты ломаешь идеологию, возвращая в QueryInterface ссылки на внешние объекты, то это характеризует платформу как абсолютно бредовую.
H>>>>Никаких внешних объектов нет. Я вижу, что нападающие тут ты не сильно изобретательны (один про хэлперы не въезжает, другой мыслит шаблонно...)
kuj>>>Просвяти, будь так добр.
H>>Ну вот, я говорил про исходиники VCL... Ознакомься с RIO.pas
kuj>Мда, значит очередное пустозвонство. Так и запишем.
Твоя картина мира снова дала трещину? Сочувствую.
kuj>>>>>>>Почему можно скастить объект к абстрактному предку без всяких QueryInterface`ов?
kuj>>>>>Значит не знаешь?
H>>>>Просто вопрос бредовый... ибо наследование.
kuj>>>Наследование это сферический конь в банаховом пространстве. Почему в случае наследования не нужен QueryInterface?
H>>На момент компиляции все известно, чего там запрашивать? Ты попробуй обойтись без QueryInterface при работе с интерфейсом полученныйм от внешнего источника в виде базового IUnknown.
kuj>Представь себе за "базовым IUnknown" всегда лежит конкретный объект, который его реализует. Продолжать?..
Я тебе повторю, что если ты получишь интерфейс из внешнего источника, куда .net со своей рефлексией не доползет, то уж придется таки дергать QueryInterface. Впрочем, если для тебя весь мир это .Net... Сочувствую.
Здравствуйте, abibok, Вы писали:
OCT>>"Отличные" можно понимать по–разному. На Паскале много олимпиадников OCT>>выросло. В школьные годы все, как один, писали олимпиады на этом языке.
OCT>>Вот только не знаю, сколько из них [олимпиадников] вообще сидят на OCT>>форумах, в том числе RSDN.
A>Ну я был олимпиадником. Областные — на GW-BASIC, республиканские — на Turbo Pascal. На первых курсах университета писал на Delphi и С++ Builder. Потом полностью перешел на С++, а сейчас — на C#.
У меня первое место по республике среди выпусных классов.
Здравствуйте, hattab, Вы писали:
H>>>У тебя работает и ты спокоен. У твоего заказчика перестанет и станешь в неудобную позу. Вот и все дела.
kuj>>Я говорю про production, которому уже 4 года. "Вот и все дела".
H>Я тебе уже сказал, где ты можешь почитать о существующих несовместимостях. Чего ты мне своим продакшеном тычешь? Твои личные проекты это твое дело. Я сказал о существующих проблемах SOAP, как протокола, а ты мне "но у меня же работает"...
Называется слышал звон, да не знаю где он. hattab ты смешон.
H>>>>>А кто-то говорил, что оно и нафиг не нужно ибо есть SOAP
kuj>>>>Естественно, оно не нужно в составе Framework — его и нет.
H>>>
kuj>>Что тебя так насмешило? Расскажи я тоже хочу посмеяться.
H>Если оно действительно ненужно, зачем тогда сторонние тулы? MS'у понятное дело ничего кроме своего ненужно...
Оно не нужно в составе Framework. Что тебе еще не понятно?
H>>>В следующий раз я тебя к исходникам VCL отправлю, ты не удивляйся.
kuj>>При чем тут исходники? hattab, Delphi оказывает паршивое влияние на мыслительные процессы.
H>Вместо нескольких предложений с объяснением, легче сказать RTFM. Вот и я тебе скажу RTFM или в исходники пошлю. Мысль понятна?
Я тебе дал название конкретного класса, документация по которому находится за минуту на MSDN. Или тебе все надо разжевать и в рот положить?
H>>>XML-RPC с рождения умеет бинарные данные передавать без base64.
kuj>>Да ну, серьезно? Ну-ка, ну-ка, ссылку на место в спецификации, где описано как XML-RPC передает бинарные данные без кодирования их в один из текстовых форматов.
H>
H>What characters are allowed in strings? Non-printable characters? Null characters? Can a "string" be used to hold an arbitrary chunk of binary data?
H>Any characters are allowed in a string except < and &, which are encoded as < and &. A string can be used to encode binary data.
Те же яйца только в профиль — кодирование в любом случае потребуется. SOAP же умеет передавать бинарные данные как есть в виде аттача — без оверхида и без конвертации.
Добро пожаловать в 2008ой год хаттаб.
H>>>Мдя...
kuj>>Ты сам хоть понимаешь какую чушь несешь? По твоей ссылке лишь сказано, что в какой-то старой версии Windows был криво реализованный генератор случайных чисел, цепочки которого можно с помощью специальной атаки предугадывать наперед, имея доступ к компьютеру. Потом было сказано, что они не знают точно справедливо ли это для Windows XP и уж тем более ничего не сказано о Vista, АНБ, реализации генератора в .NET (исходники которой открыты, FYI) и каких-то там тенденциях.
kuj>>
kuj>>Random Class
kuj>>Represents a pseudo-random number generator, a device that produces a sequence of numbers that meet certain statistical requirements for randomness.
kuj>>Namespace: System
kuj>>Assembly: mscorlib (in mscorlib.dll)
kuj>>Pseudo-random numbers are chosen with equal probability from a finite set of numbers. The chosen numbers are not completely random because a definite mathematical algorithm is used to select them, but they are sufficiently random for practical purposes. The current implementation of the Random class is based on Donald E. Knuth's subtractive random number generator algorithm. For more information, see D. E. Knuth. "The Art of Computer Programming, volume 2: Seminumerical Algorithms". Addision-Wesley, Reading, MA, second edition, 1981."
kuj>>Если у тебя есть сомнения по поводу .NET реализации генератора случайных чисел рисуешь трехмерную систему координат и куб со стороной 1, заполняешь этот куб точками, координаты которых получены с помощью данного генератора. Любую существенную неравномерность распределения можно будет увидеть на глаз, если таковая имеет место быть.
H>Ладно. Не напрягайся. Я вижу, что ты ничего не хочешь видеть и веришь всему что тебе преподносит МС. Крепкого сна.
Значит по существу сказать нечего. Ясно. Слив засчитан.
kuj>>>>>>>>Еще раз повторяю DES уж много лет как не применяется в свете наличия гораздо лучших шифров, как например Rijndael.
H>>>>>>>Да хоть каким современным будь здание, но если у него фундамент гнилой...
kuj>>>>>>Аргументируй.
H>>>>>Я для кого тут ссылки приводил?
kuj>>>>В чем "гнилость фундамента" шифра Rijndael? Давай по пунктам.
H>>>Ппц... Про рандомные генераторы читал?
kuj>>Какое они имеют отношение к шифру Rijndael? Представь себе, я могу подставить любую реализацию ГСЧ.
H>Да что ты пристал к этому AES??? Криптография AES'ом не ограничивается. Я же тебе сразу сказал о тенденциях...
Ты сказал, что у Rijndael гнилой фундамент я попросил аргументировать, ты дал ссылку на желтопрессную статейку о том, что стандартный ГСЧ в старых версиях Windows имел проблемы. Так вот в .NET FW класс Random реализует алгоритм, описанный Кнутом в 1981 году и его исходники общедоступны. Все еще не дошло? мда... Делфи реально отупляет.
H>>>>>>>Кстати, Rijndael не был лучшим по результам тестов на потенциальные уязвимости см. руководство TrueCrypt (там есть ссылочки на первоисточники).
kuj>>>>>>Ссылки в студию.
H>>>>>Иди на TrueCrypt.org и читай. Мне не хочется из PDF'а ссылки выцарапывать.
kuj>>>>Ясно. Значит пустозвонство.
H>>>Я тебе адрес дал. Интересно -- иди и читай.
kuj>>google.com тебе противоречит. Интересно? Иди и читай.
H>Я тебе вполне конкретный сайт указал, там найдешь руководство пользователя и вперед.
Слив засчитан.
H>>>Кастить можно к любому заявленному реализованным предку интерфейса. Написано об этом раз десять уже.
kuj>>Какой смысл в наследовании интерфейсов, в таком случае? Ведь все-равно, чтоб обратиться к методам и свойствам предка придется явно указывать, что класс реализует конкретно этого предка.
H>Я проблемы понять не могу... Сложно вместо MyInterface написать IInterface, MyInterface?
Во-первых, сложно. Во-вторых, это банально бред перечислять предков. Что если интерфейс в пятом поколении, а класс должен реализовать 4 подобных интерфейса?
H>>>В чем проблема наследования от TInterfacedObject? Религия?
kuj>>legacy код.
H>Какое еще наследие? Ты что? Этот TInterfacedObject существует с 3 версии...
Мда, ты не знаешь что такое legacy код? Смешно.
H>>>>>Никаких внешних объектов нет. Я вижу, что нападающие тут ты не сильно изобретательны (один про хэлперы не въезжает, другой мыслит шаблонно...)
kuj>>>>Просвяти, будь так добр.
H>>>Ну вот, я говорил про исходиники VCL... Ознакомься с RIO.pas
kuj>>Мда, значит очередное пустозвонство. Так и запишем.
H>Твоя картина мира снова дала трещину? Сочувствую.
Слив засчитан.
kuj>>>>>>>>Почему можно скастить объект к абстрактному предку без всяких QueryInterface`ов?
kuj>>>>>>Значит не знаешь?
H>>>>>Просто вопрос бредовый... ибо наследование.
kuj>>>>Наследование это сферический конь в банаховом пространстве. Почему в случае наследования не нужен QueryInterface?
H>>>На момент компиляции все известно, чего там запрашивать? Ты попробуй обойтись без QueryInterface при работе с интерфейсом полученныйм от внешнего источника в виде базового IUnknown.
kuj>>Представь себе за "базовым IUnknown" всегда лежит конкретный объект, который его реализует. Продолжать?..
H>Я тебе повторю, что если ты получишь интерфейс из внешнего источника, куда .net со своей рефлексией не доползет,
.NET прекрасно взаимодействует с COM-объектами и без бредового перечисления предков вплоть до IUnknown. Не знал?
H>то уж придется таки дергать QueryInterface. Впрочем, если для тебя весь мир это .Net... Сочувствую.
kuj пишет: > Продолжай повторять себе это. Ты зациклен в своем ограниченном мирке и > даже представления не имеешь что такое настоящее ООП с применением таких > техник как IoC/DI.
А что в DI такого особенного, что это преподносится как существенный
плюс? С тем же успехом существенным плюсом можно назвать mix-in.
Почему DI?
Здравствуйте, hattab, Вы писали:
A>>Ну я был олимпиадником. Областные — на GW-BASIC, республиканские — на Turbo Pascal. На первых курсах университета писал на Delphi и С++ Builder. Потом полностью перешел на С++, а сейчас — на C#.
H>У меня первое место по республике среди выпусных классов.
Наверное, это было настолько сильное впечатление для тебя, что тебя просто заклинило на Delphi
>> Продолжай повторять себе это. Ты зациклен в своем ограниченном мирке и >> даже представления не имеешь что такое настоящее ООП с применением таких >> техник как IoC/DI.
OCT>А что в DI такого особенного, что это преподносится как существенный OCT>плюс? С тем же успехом существенным плюсом можно назвать mix-in. OCT>Почему DI?
Потому что IoC/DI позволяет сделать 100% decoupling реализаций.
Здравствуйте, _d_m_, Вы писали:
A>>>Ну я был олимпиадником. Областные — на GW-BASIC, республиканские — на Turbo Pascal. На первых курсах университета писал на Delphi и С++ Builder. Потом полностью перешел на С++, а сейчас — на C#.
H>>У меня первое место по республике среди выпусных классов.
___>Наверное, это было настолько сильное впечатление для тебя, что тебя просто заклинило на Delphi
Свои откровения можешь оставить при себе... "Не судить... Жить по совести..." трепло
Здравствуйте, OCTAGRAM, Вы писали:
>> Потому что IoC/DI позволяет сделать 100% decoupling реализаций.
OCT>13 лет уже как позволяет, сейчас–то чего вдруг вспомнили?
Вспомнили в контексте разговора. Существующая реализация Делфи не позволяет создать полноценный IoC-контейнер.
Здравствуйте, hattab, Вы писали:
A>>>>Ну я был олимпиадником. Областные — на GW-BASIC, республиканские — на Turbo Pascal. На первых курсах университета писал на Delphi и С++ Builder. Потом полностью перешел на С++, а сейчас — на C#.
H>>>У меня первое место по республике среди выпусных классов.
___>>Наверное, это было настолько сильное впечатление для тебя, что тебя просто заклинило на Delphi
H>Свои откровения можешь оставить при себе... "Не судить... Жить по совести..." трепло
Если такие кадры как ты побеждают на олимпиадах, то я начинаю откровенно сомневаться в уровне заданий на этих "олимпиадах". Чего только стоит твои гениальные алгоритмы, где парент и чайлд зависят друг от друга и должны в определенном порядке во время дестракшина производить еще какие-то вычисления... /моя плакать...
Про качество кода, писанного тобой я лучше вообще промолчу...
kuj пишет: > Вспомнили в контексте разговора. Существующая реализация Делфи не > позволяет создать полноценный IoC-контейнер.
Вот mix-in Delphi точно не позволяет сделать. А DI?
Constructor Injection, Setter Injection, Interface Injection — это всё
возможно в Delphi. Классы можно по их имени создавать, свойства можно по
их имени присваивать. Я потерял нить (к слову о том, как хорошо менять
тему), где начинается "нельзя"?
H>>>Протри окуляры. Там написано "мэни". Убейся сам.
M>>Мэни — это не мини. Иди учи английский
H>У меня было написано "мэни". У МЕНЯ!!! Протри окуляры, уже.
Аааа... Ну тогда учти, Дельфи входит в разряд этих многих языков.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>kuj пишет: >> Вспомнили в контексте разговора. Существующая реализация Делфи не >> позволяет создать полноценный IoC-контейнер. OCT>Вот mix-in Delphi точно не позволяет сделать. А DI?
OCT>Constructor Injection, Setter Injection, Interface Injection — это всё OCT>возможно в Delphi. Классы можно по их имени создавать, свойства можно по OCT>их имени присваивать. Я потерял нить (к слову о том, как хорошо менять OCT>тему), где начинается "нельзя"?
1. Отсутствие generic`ов.
2. Отсутствие полноценной иерархии интерфейсов.
3. Невозможность реализации механизма interception, на котором базируется AoP.
продолжать?
Или лучше задай себе вопрос — почему за столько лет в Delphi не появилось ни одного IoC/DI-контейнера, тогда как в Java и .NET их очень много (счет идет на десятки)?
Здравствуйте, kuj, Вы писали:
kuj>Если такие кадры как ты побеждают на олимпиадах, то я начинаю откровенно сомневаться в уровне заданий на этих "олимпиадах". Чего только стоит твои гениальные алгоритмы, где парент и чайлд зависят друг от друга и должны в определенном порядке во время дестракшина производить еще какие-то вычисления... /моя плакать...
Это нормально. Подумай что такое вообще олимпиады про программированию: человек решает абстрактную (!) вычислительную (!) задачу в очень ограниченное время (!) с жесткими требованиями по быстродействию (!) (хотя иногда без таких требований).
При таких исходных данных никакой архитектурой и не пахнет.
У тех кто часто участвует в таких олимпиадах появляется привычка писать код "быстро" и "оптимально". О качестве такого кода промолчу.
gandjustas пишет: > Это нормально. Подумай что такое вообще олимпиады про программированию: > человек решает абстрактную (!) вычислительную (!) задачу в очень > ограниченное время (!) с жесткими требованиями по быстродействию (!) > (хотя иногда без таких требований).
> У тех кто часто участвует в таких олимпиадах появляется привычка писать > код "быстро" и "оптимально".
И это не единственные ограничения. Сверху спускаются языки, которые
можно использовать. Сверху спускаются библиотеки (как правило, только
стандартные), которые можно использовать. Таковы правила игры.
> О качестве такого кода промолчу.
Да какое там может быть качество? Вся программа умещается в голове.
> При таких исходных данных никакой архитектурой и не пахнет.
Я из–за этого и ушёл, и большинство уходит. Однако же не сказать, что
это было неинтересное прошлое.
Здравствуйте, hattab, Вы писали:
H>>>У меня первое место по республике среди выпусных классов.
___>>Наверное, это было настолько сильное впечатление для тебя, что тебя просто заклинило на Delphi
H>Свои откровения можешь оставить при себе... "Не судить... Жить по совести..." трепло
Я не вижу нарушений своих принципов. hattab, не надо подменять понятия. И обижаться тоже не надо.
Здравствуйте, hattab, Вы писали:
kuj>>>>>>>>Еще раз повторяю DES уж много лет как не применяется в свете наличия гораздо лучших шифров, как например Rijndael.
H>>>>>>>Да хоть каким современным будь здание, но если у него фундамент гнилой...
kuj>>>>>>Аргументируй.
H>>>>>Я для кого тут ссылки приводил?
kuj>>>>В чем "гнилость фундамента" шифра Rijndael? Давай по пунктам.
Присоединяюсь к вопросу.
H>>>Ппц... Про рандомные генераторы читал?
Выделенное — лежит в основе "фундамента" всей криптографии. Причем тут конкретно rijndael?
kuj>>Какое они имеют отношение к шифру Rijndael? Представь себе, я могу подставить любую реализацию ГСЧ. H>Да что ты пристал к этому AES??? Криптография AES'ом не ограничивается. Я же тебе сразу сказал о тенденциях...
Не будет откровением, если я скажу, что AES — это вообще-то не Rijndael в том смысле, что между ними есть небольшая, но существенная разница? Ты о каком из них сейчас говоришь?
H>>>>>>>Кстати, Rijndael не был лучшим по результам тестов на потенциальные уязвимости см. руководство TrueCrypt (там есть ссылочки на первоисточники).
Что никоим образом не говорит о "гнилости" его "фундамента", IMO.
KV>Не будет откровением, если я скажу, что AES — это вообще-то не Rijndael в том смысле, что между ними есть небольшая, но существенная разница? Ты о каком из них сейчас говоришь?
Хмм? Какая разница? Вроде именно Rijndael был принят в качестве AES сколько-то лет тому назад.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Не будет откровением, если я скажу, что AES — это вообще-то не Rijndael в том смысле, что между ними есть небольшая, но существенная разница? Ты о каком из них сейчас говоришь?
kuj>Хмм? Какая разница? Вроде именно Rijndael был принят в качестве AES сколько-то лет тому назад.
В AES, по сравнению с Rijndael, были введены ограничения на размер блока и ключа. А так — да, по сути — это один и тот же алгоритм.
Здравствуйте, kuj, Вы писали: kuj>Вообще говоря, коммерческих "наборов компонентов" для .NET тоже хватает. Навскидку: http://www.infragistics.com/, http://www.businessobjects.com/, http://www.devexpress.com/ и т.д. kuj>Кто и в каких проектах их использует я, правда, без понятия...
Джентльмены, я не очень понимаю ваш спор.
Граница между платформой и сторонними компонентами должна проводиться на основе интероперабельности.
Вот к примеру тип "строка" обязан быть в платформе (привет, C/C++) просто потому, что 99% сторонних библиотек будут использовать строки; отсутствие стандартного типа приведет к зоопарку неинтероперабельных CString/std::string.
Вот к примеру работа с HTTP обязана быть в платформе, заточенной для веба, потому что иначе опять будет зоопарк несовместимых между собой библиотек веб-компонентов.
И так далее.
С точки зрения визуальных компонентов крайне полезно наличие в платформе таких штук, как ITextControl, ICheckBoxControl, IValidator. Потому что они обеспечивают интероперабельность контролов от разных производителей.
А вот наличие в платформе контрола, сочетающего в себе дерево с таблицей, непринципиально. Если он потребуется, а платформа позаботилась о вышеперечисленном, то его можно будет легко докупить, имея 100% гарантию, что он заработает совместно с кодом от других производителей.
Получить платформу, которая не нуждается в сторонних компонентах, невозможно и не нужно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, Sinclair, Вы писали:
S>>Получить платформу, которая не нуждается в сторонних компонентах, невозможно и не нужно.
DOO>Точнее даже, если и возможно, то изучать такой framework придется бесконечно долгое время
Здравствуйте, iyura, Вы писали:
I>Здравствуйте, _d_m_, Вы писали:
___>>Ну хорошо, теперь понятно. А то какие-то там фортрановские бла-бла-бла, которые еще я почему-то должен помнить :xz: . Я их не знал вовсе. Но если уж вопрос встал о многословности, то GE и >= имеют одинаковое кол-во символов, не находишь?
I>Ну про фортрановское бла-бла ты расскажи людям, которые вычислительной математикой занимаются ;) Я,например, работал в проекте в котором половина всего был фортран (финансы, оценка рисков)
I>Вот не помню точно, но в фортране >= это Greate Or Equal, т.е. GOE (три знака точно, но могу и ошибаться)
.GE. — четыре знака.
Например, так: IF(A.GE.B) ...
I>Но речь-то не о фортране (дедушка живее всех живых :) )
Пять лет назад — да. Сейчас что-то уже хуже — вижу его вымывание из расчётных задач.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Sinclair, Вы писали:
S>>Стековая ориентированность IL позволяет во-первых проводить дешевую верификацию кода, WH>Я бы не сказал что наличие goto способствует скорости, простоте и надежности верификации кода.
Зачем подымаете замшелые мифы? Любой код с goto _автоматом_ может быть трансформирован в "структурный" без знания используемого алгоритма. И опытный программист обычно пишет так (даже не задаваясь этой целью), что подобная трансформация может быть проведена с получением внятной конструкции, а не странной путаницы.
S>>а во-вторых генерировать достаточно эффективный целевой код на современных архитектурах. WH>Этому стековая модель ВМ тоже не помогает.
И чем она мешает?
WH>В любом случае funarg problem в C# появилась еще во второй версии и исчезать не соберается.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, kuj, Вы писали:
kuj>>Если такие кадры как ты побеждают на олимпиадах, то я начинаю откровенно сомневаться в уровне заданий на этих "олимпиадах". Чего только стоит твои гениальные алгоритмы, где парент и чайлд зависят друг от друга и должны в определенном порядке во время дестракшина производить еще какие-то вычисления... /моя плакать... G>Это нормально. Подумай что такое вообще олимпиады про программированию: человек решает абстрактную (!) вычислительную (!) задачу в очень ограниченное время (!) с жесткими требованиями по быстродействию (!) (хотя иногда без таких требований). G>При таких исходных данных никакой архитектурой и не пахнет.
Ну почему же.;) Совсем без архитектуры даже олимпиадная задача не заработает.
G>У тех кто часто участвует в таких олимпиадах появляется привычка писать код "быстро" и "оптимально". О качестве такого кода промолчу.
Умение быстро написать чтобы заработало — тоже полезно. А вот дальше должен быть опыт перевода такого результата без постороннего пинания в пристойный сопровождаемый вид. Вот этому уже действительно учатся не на олимпиадах.
Здравствуйте, netch80, Вы писали:
WH>>Я бы не сказал что наличие goto способствует скорости, простоте и надежности верификации кода. N>Зачем подымаете замшелые мифы? Любой код с goto _автоматом_ может быть трансформирован в "структурный" без знания используемого алгоритма.
Я в курсе. Более того его даже в функциональщину (хоть и грязную) трансформировать можно.
Но как это способствует выделеному?
N>И опытный программист обычно пишет так (даже не задаваясь этой целью), что подобная трансформация может быть проведена с получением внятной конструкции, а не странной путаницы.
А некоторые пишут на немерле... с паттернматчингом... Можешь посмотреть во что это превращатеся. Да и C# начиная с версии 2.0 тоже местами не подарок. Иди попробуй yield return реверснуть...
Да и стековая модель байткода не единственная проблема MSIL.
Его модель ничего не говорит про детерминированную финализацию. try/finally тот еще костыль.
Защита данных в многопоточной среде тоже мягко говоря не на высоте.
...
Знаю, знаю. Критикуя предлагай.
Я думаю. Красивая, практичная и при этом эффективно реализуемая модель ВМ задачка не простая.
WH>>Этому стековая модель ВМ тоже не помогает. N>И чем она мешает?
Большей сложностью анализа чем альтернативы.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, misha_irpen, Вы писали:
_>Сам я от большого программинга уже отошел, хотя по прежнему могу считать себя профессионалом Delphi и ASM. И у меня приактически никогда не возникало проблем из-за каких-то ограничений языка. Я с уверенностью могу сказать, что могу написать на нем абсолютно все что угодно в рамках имеющихся API и математических моделей. При этом практически никогда не приходится изобретать велосипедов и извращаться чтобы обойти ограничения языка или стандартных библиотек. В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин?
Здравствуйте, _d_m_, Вы писали:
SB>>Не знаю как другим, но мне не нравится: SB>>1. SB>>
SB>>:=
SB>>
___>А по моему, так все правильно. По идее семантика оператора сравнения должна отличаться от оператора присваивания.
... ___>Ну да, несколько громоздко. Особено для тех, кто избалован С-подобным синтаксисом.
Ваш уровень, господа, поражает. Ты бы хоть на смайлик внимание обратил. Если разница между языками ограничивается разницей между лексемами, то языки идентичны, а споры кто из них лучше — это споры о вкусах.
Основная разница в языках заключается в их выразительности. Вот скажем реализуй на Дельфи следующую функцию:. На входе список строк содержащий слова русского языка. Слова дублируются. Задача подсчитать количество вхождений каждого слова и вывести их в формате: строка: количество вхождений. При этом все должно быть отсортировано по частоте вхождений. Потом я приведу тоже самое на C# 3.0 и ты поймешь, что твоя любимая Дельфи просто более низкоуровневый язык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kuj, Вы писали:
kuj>Вместо Prolog — Erlang.
Это все равно, что вместо самолетов автомобили изучать. Prolog — это другоая (и более высокоуровневая) парадигма. Так что "вместо" не надо. Но можно "вместе".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Впрочем корутин и исключений вполне достаточно для подавляющего большинства практических задач.
Не, ну, я бы не отказался бы от быстрых и полноценных континюэйшонов. В некоторых задачах они бы дали хороший эффект. Но если помнить, что за все приходится платить, то я бы предпочел остановится на продвинутом варианте итераторов Шарпа. Таких чтобы позволяли использовать yield из вложенных вызовов и замыкания на класс в которых эти методы реализованы. Это (как я думаю) можно реализовать эффективно (переведя в конечный автомат).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Не, ну, я бы не отказался бы от быстрых и полноценных континюэйшонов. В некоторых задачах они бы дали хороший эффект.
Полноценные континюэйшены и детерминированная финализация не совместимы.
Вобще.
А детерминированная финализация в реальной жизни штука необходимая.
VD>Но если помнить, что за все приходится платить,
Во-во.
Плата совершенно неприемлима.
VD>то я бы предпочел остановится на продвинутом варианте итераторов Шарпа. Таких чтобы позволяли использовать yield из вложенных вызовов и замыкания на класс в которых эти методы реализованы. Это (как я думаю) можно реализовать эффективно (переведя в конечный автомат).
А это и есть корутина.
Только их можно сделать мощьнее чем тупые итераторы.
Например на корутину можно повесить протокол что-то типа того что использован в сингулярити для каналов. Тогда можно вместо монолога устроить диалог.
Ну и естественно никаких ограничений на рекурсию.
Плюс оптимизация вобще всех хвостовых вызовов.
Таким образом нам и goto не нужно.
Можно будет конечные автоматы на хвостовых вызовах делать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _d_m_, Вы писали:
SB>>>Не знаю как другим, но мне не нравится: SB>>>1. SB>>>
SB>>>:=
SB>>>
___>>А по моему, так все правильно. По идее семантика оператора сравнения должна отличаться от оператора присваивания. VD>... ___>>Ну да, несколько громоздко. Особено для тех, кто избалован С-подобным синтаксисом.
VD>Ваш уровень, господа, поражает. Ты бы хоть на смайлик внимание обратил. Если разница между языками ограничивается разницей между лексемами, то языки идентичны, а споры кто из них лучше — это споры о вкусах.
Я всего лишь сказал то, что сказал. Это у тебя почему то фантазия разыгралась.
VD>Основная разница в языках заключается в их выразительности. Вот скажем реализуй на Дельфи следующую функцию:. На входе список строк содержащий слова русского языка. Слова дублируются. Задача подсчитать количество вхождений каждого слова и вывести их в формате: строка: количество вхождений. При этом все должно быть отсортировано по частоте вхождений. Потом я приведу тоже самое на C# 3.0 и ты поймешь, что твоя любимая Дельфи просто более низкоуровневый язык.
Моя любимая дельфи ?!! Афигеть. Я не то что дельфи, я и паскаля не знаю. Но в свое время юзал Borland C++ Builder, после чего зарекся использовать продукты Богланда. По необходимости приходится сталкиваться с Interbase — лишний раз убеждаюсь в своей правоте.
Я знал: QuickBasic, ассемблер, С, C++, 1C.
Сейчас работаю с C# 2, TSQL.
Потом я приведу тоже самое на C# 3.0
А как же Nemerle?
На SQL-е твоя задача решается в один простейший запросик.
Здравствуйте, WolfHound, Вы писали: VD>>Не, ну, я бы не отказался бы от быстрых и полноценных континюэйшонов. В некоторых задачах они бы дали хороший эффект. WH>Полноценные континюэйшены и детерминированная финализация не совместимы. WH>Вобще.
Хм. А вот Рихтер так не думает.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
WH>>Полноценные континюэйшены и детерминированная финализация не совместимы. WH>>Вобще. S>Хм. А вот Рихтер так не думает.
Ну пусть Рихтер покажет как совместить call/cc и любой вид детерминированной финализации.
А я посмеюсь...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>Ну пусть Рихтер покажет как совместить call/cc и любой вид детерминированной финализации.
Я не уверен, что прямо таки call/cc, но вот совместить асинхронный ввод-вывод Рихтеру вполне удается: http://msdn.microsoft.com/ru-ru/magazine/cc546608.aspx WH>А я посмеюсь...
Давай уж вместе
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
WH>>Ну пусть Рихтер покажет как совместить call/cc и любой вид детерминированной финализации. S>Я не уверен, что прямо таки call/cc, но вот совместить асинхронный ввод-вывод Рихтеру вполне удается: S>http://msdn.microsoft.com/ru-ru/magazine/cc546608.aspx
Это корутины.
Частный случай реализуемый через континюэйшены.
Вобще через континюэйшены можно реализовать любую конструкцию передачи управления. Корутины, исключения....
Но в общем случае континюэйшены несовместимы с детерминированной финализацией.
ЗЫ Больше не давай ссылки на русский перевод.
ЗЗЫ А вобще асинхронный ввод-вывод сам по себе тот еще костыль. Он нужен чисто из-за того что в классических ОС потоки очень тяжолые.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>Это корутины. WH>Частный случай реализуемый через континюэйшены.
Ну, а если подумать — чем он так радикально отличается от континьюэйшнов? Ведь у нас фактически начало try выполняется в одном контексте, а finally — в другом. Тем не менее, все гарантии нам предоставлены. Просто совершенно случайно "красивый" синтаксис детерминистической финализации в шарпе оказался совместимым с корутинами. Компилятор делает уличную магию, скукоживая красивый код в стейт машину. В итоге, закрытие блока using (а точнее, того, что выглядит как блок using) происходит совсем в другом блоке finally, чем в "прямолинейном" случае. WH>Но в общем случае континюэйшены несовместимы с детерминированной финализацией.
Почему нельзя добиться того же для continuation? WH>ЗЫ Больше не давай ссылки на русский перевод.
ну я полагал, что любой RSDNщик способен заменить ru-ru на en-us в урле, если не доверяет переводам не от Гоблина. WH>ЗЗЫ А вобще асинхронный ввод-вывод сам по себе тот еще костыль. Он нужен чисто из-за того что в классических ОС потоки очень тяжолые.
Это-то понятно. Но на тех же примитивах строят и просто параллельные алгоритмы, навроде PLinq, где смысл уже не сводится к экономии системных потоков.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
WH>>Это корутины. WH>>Частный случай реализуемый через континюэйшены. S>Ну, а если подумать — чем он так радикально отличается от континьюэйшнов?
Да вот отличается.
На корутинах ты вот это не сделаешь:
(define theContinuation #f)
(define (test)
(let ((i 0))
; call/cc calls its first function argument, passing
; a continuation variable representing this point in
; the program as the argument to that function.
;
; In this case, the function argument assigns that
; continuation to the variable theContinuation.
;
(call/cc (lambda (k) (set! theContinuation k)))
;
; The next time theContinuation is called, we start here.
(set! i (+ i 1))
i))
> (test)
1
> (theContinuation)
2
> (theContinuation)
3
> (define anotherContinuation theContinuation)
> (test)
1
> (theContinuation)
2
> (anotherContinuation)
4
S>Ведь у нас фактически начало try выполняется в одном контексте, а finally — в другом. Тем не менее, все гарантии нам предоставлены.
Ты гдето запутался.
Не стоит смотреть на то как это реализовано.
Нужно смотреть в корень.
По факту yield просто прерывает поток исполнения после чего можно продолжить с этого места ровно один раз.
В случае с континюэйшеном продолжать можно много раз.
S>Просто совершенно случайно "красивый" синтаксис детерминистической финализации в шарпе оказался совместимым с корутинами.
Не случайно.
Вот тебе простейший код:
Если выделеное условие выполняется то его семантика проста и понятна.
А если нет?
Если yield return может несколько раз вернуть управление?
В каком состоянии будет файл во второй раз?
И ровно эта же проблема будет при любой модели детерминированой финализации.
Ибо смысл детерминированной финализации в том чтобы прибить объект в строго определенной точке кода.
А континюэйшены позволяют попасть в эту точку больше одного раза.
Корутины этой проблемой не страдают. Ибо они по факту просто кооперативная многозадачность.
S>ну я полагал, что любой RSDNщик способен заменить ru-ru на en-us в урле, если не доверяет переводам не от Гоблина.
Да я и заменил.
Просто не сразу догадался.
Ну не часто я бываю на MSDN.
Делать мне там особо нечего...
S>Это-то понятно. Но на тех же примитивах строят и просто параллельные алгоритмы, навроде PLinq, где смысл уже не сводится к экономии системных потоков.
Ну и PLink можно построить на чем угодно...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, DOOM, Вы писали:
C>>>Это неверно. GCC транслирует программу на С++ в общее представление (в GIMPLE, а потом в RTL). Чистый С идёт точно по такому же пути. DOO>>Я имел ввиду, что не сам gcc — как компилятор C++ так делает, а была какая-то отдельная программка (я ее ни разу не смотрел в работе), которая именно переводила C++ в С путем препроцессинга. Вроде она до сих пор имеется в пакете gcc — надо бы поискать. C>Да, была — сfront (на ней ещё куча компиляторов было основано). Но С++98 уже не осиливала.
Разрабатывая Си с классами (позднее Си++), Страуструп также написал программу Cfront, транслятор, перерабатывающий исходный код Си с классами в исходный код простого Си. Новый язык, неожиданно для автора, приобрёл большую популярность среди коллег и вскоре Страуструп уже не мог лично поддерживать его, отвечая на тысячи вопросов.
В 1983 г. произошло переименование языка из Си с классами в Си++ по соображениям маркетинга
интервью с ведущим разработчиком Microsoft — Андерсом Хейлсбергом (Anders Hejlsberg)
В июле, редактор O`Reilly Джон Осборн посетил конференцию профессиональных разработчиков Microsoft, где взял интервью у Андерса Хейлсберга, выдающегося специалиста и ведущего разработчика C#, о платформе Microsoft .NET и языке программирования C#. Андерс Хейлсберг известен как человек, который разрабатывал Turbo Pascal, один из первых языков доступных на PC. Андерс лицензировал Turbo Pascal корпорации Borland и впоследствии возглавил команду, создавшую Delphi, действительно удачное визуальное средство разработки клиент-серверных приложений. Также в интервью принимали участие Тони Гудхью (Tony Goodhew) — Microsoft менеджер C#, и редактор раздела Windows в O`Reilly — Рон Петруша (Ron Petrusha).
Здравствуйте, gandjustas, Вы писали:
G>Класс TThread.
1)Не позволяет узнать завершился ли поток — надо использовать WinAPI.
...execute
begin
try
...
finally
// поток завершился
end
end;
2)Непонятен в использовании (из-за наследования), на первой работе неделю ловили баг из-за неправильного использования Thread. Человек банально скопировал код из примера и сам чего-то дописал.
В смысле?
TMyThread = class(Thread)
в чём отличие от остальных классов?
Проблема России не в том, что она не может накормить бедных, а в том, что богатые никак не нажрутся
Здравствуйте, siberia2, Вы писали:
DR>>Не нравится Дельфи из за типично чрезвычайно низкого качества написанных на ней программ.
S>А тот же увалень на C++ сразу пишет высококачественный код. Или ему платят жалование лет 5, но выхода не требуют?
Минимальный "Привет Мир!" на MFC будет нормальной программой. На Дельфи он будет показывать вопросительные знаки в нерусифицированном Windows. Программы на Дельфи сломаны по умолчанию и нужно хорошо разбираться в нём, чтобы обходить грабли даже в простейших проектах.
И че вам так хочется пободаться...
G>>невозможно указать типа указателя в месте использования. S>В смысле? Приведение типа не работает?
В смысле нельзя написать (по крайней мере в 7 версии)
(byte^)(<выражение>)
G>>Класс TThread. S>1)Не позволяет узнать завершился ли поток — надо использовать WinAPI.
S>...execute S>begin S> try S> ... S> finally S> // поток завершился S> end S>end;
А вызывающий код как узнает?
Также куча проблем возникает из за втойства FreeOnTerminate
S>2)Непонятен в использовании (из-за наследования), на первой работе неделю ловили баг из-за неправильного использования Thread. Человек банально скопировал код из примера и сам чего-то дописал. S>В смысле? S>TMyThread = class(Thread) S>в чём отличие от остальных классов?
В смысле до многих не сразу доходит в каком потоке вызывается какой код.
За месяц работы дважды отлавливал баги с неправильным вызовом методов UI из других потоков.
Прежде чем спорить стоит изучить не только делфи, но и другие языки/технологии.