Здравствуйте, 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]: наши менеджеры памяти самые менеджеристые менеджеры
А то они, бедняги, юзают интерфейсы без всякого COM'а и даже не подозревают о твоих откровениях... 
FYI, стандартным (нет, не ГОСТ, но AES) блочным симметричным шифром уже много лет как является Rijndael. 
