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, как в
юниксе. Вот и получилась шоковая терапия.
Если решил цитировать, цитируй до буквы.
Все ясно с твоей аргументацией, можешь больше не напрягаться.
FYI, стандартным (нет, не ГОСТ, но AES) блочным симметричным шифром уже много лет как является Rijndael. 
В далеком 99м году еще на C++ писал с полной поддержкой юникод и в мыслях не было, что может потребоваться перехватывать API-вызовы для вывода юникод текста. 
