Здравствуйте, 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 и даже С++ с адекватным инструментарием.
MIDAS, это Delphi трехзвенка, делала это еще в далеком 99 году. И по DCOM, и по CORBA, и OLEEnterprise (была у Inprise такая фенька), и по сокетам. Потом еще SOAP появился, но он вроде не очень юзабельный был.
Чаще всего, на Delphi, вообще не приходится применять ручное управление подсчетом ссылок. Но если уж берешься -- будь добр соответствовать. С этим тезисом ты станешь спорить? В .Net небходимость использования using тоже далеко не очевидна, что мне теперь накинуться на нее с криками MD?
Я и не удивлен даже, после претензий высказываемых в адресс Delphi.
