Здравствуйте, 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ок библиотеки? А больше ничего не нужно? Скрины не коллекционирую, и как я уже писал, последний раз это было два года назад, и в другой конторе. А вообще попытка перейти на личность это признак слабой аргументной базы, а посему адью.
Все печально. Очень.
). 
