Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, DOOM, Вы писали:
DOO>>2. Delphi иногда очень сильно обходит других CC>Насколько я помню все преимущества дельфи заключались в том, что аллокатор памяти в дельфином рантайме был написан с упором на быструю аллокацию.
В общем-то пора бы уже наверное перечитать эту статью, но еще по-моему Дельфи на каких-то тестах с деревом объектов рулил.
L>Ну и надо всё время проверять, что в этом месте процедуры этот tmp ещё нужен, а чуть ниже по тексту уже нет.
Неужели это такая проблема помнить свои переменные в рамках одной синтаксической конструкции?
Попиши на асме какое-то время — дисциплина подтянется
L>>>>>Во-вторых — оно в каких случаях нужно-то? DOO>>>>Что конкретно? Понять, что это перегруженный оператор? Это нужно когда читаешь/модифицируешь чужой код. L>>>Писать в каких слуаях это нужно: когда нужно явно вызывать неявное приведение типов? DOO>>Ты о чем? О том примере — это было так, что ввспомнилось из смутного прошлого. В общем и целом перегрузка операторов делает код write only. DOO>>P.S. А я еще и ООП в целом не люблю
L>Ну так написать везде можно так, что потом 100 лет не расхлебаешь.
В общем случае программа написанная на контекстно свободном языке читается легче (человеку банально сложно искать границы контекстов и учитывать их при чтении, лучше, чтобы все нужные данные были здесь и сейчас) — таким образом стандартная процедурная программа на голом C читается элементарно, а навороченная вся из себя шалонно-объектная на C++ вообще никак не читается — тебе надо всегда куда-то отматывать, много всего держать в голове и т.д.
Кстати, Дельфийские программы читались очень неплохо, правда с очень большой помощью IDE, которая безошибочно (в отличие от VS 6.0) определяла, что
это за функция или метод объекта.
L>Одну. От Борланда. Вы назовёте ту, где есть препроцессор?
Еще раз — я могу использовать внешний препроцессор. Меня же не ломает писать программки на C в Vim'е и собирать их make'ом с gcc
DOO>>А теперь замени на ABigComplexData на ABigComplexData * — и пойми, что в Дельфи объект это всегда указатель на объект.
L>Ну и что в этом хорошего? Кстати, kuj про shared/scoped_ptr не зря вспомнил. В дельфи как их реализовать?
Никак
Чтобы язык был простым от чего-то надо отказываться.
Этих shared/scoped_ptr нет, например, и в Javascript, но это не мешает последнему занимать свою нишу...
DOO>>>>Шаблоны — на вкус и цвет. Мне они как-то не нравились в свое время. L>>>Ну хорошо, вопрос в лоб — нужен список элементов T, которые мы только что придумали. Аналог std::list<T> какой? DOO>>Tlist, потому что все классы наследники TObject. Сейчас ты мне скажешь, что мне компилятор ни фига не проверит, что в моем TList'е все объекти одного класса, но я, сильно поднатужившись, приведу тебе примеры, какую динамику это дает — просто программер на C++ с шаблонами не мыслит о своей программе как о чем-то меняющемся во время выполнения.
L>Это дает лишний уровень косвенности, хранятся-то там тогда не объекты, а указатели на них. На маленьких по размеру теряем, это ж каждый раз надо из кучи дергать по несколько байт.
Можно это даже не комментировать? Обсуждая таких монстров экономить по паре байт...
L>Но намного важнее то, что в реальных задачах нужны списки чего-то, а не всего чего угодно. В С++ с шаблонами за этим следит компилятор и дает по рукам при попытке это нарушить. Кроме того не надо делать лишних и опасных движений, вроде приведения типов. При этом в С++ не запрещено выделить некоторую сущность и хранить список [умных] указателей на неё, приводя по мере надобности. Гибкость есть. И свобода выбора.
Это зависит от архитектуры — еще раз, я в свое время убедился насколько различны подходы в проектировании у дельфиста и C++'ника — дельфист пишет динамическую программу, а C++'ник статическую, поэтому для тебя строгая типизация — преимущество, для дельфиста — ограничение.
А вся твоя пресловутая свобода выбора в C++ сильно ограничивается поддержкой со стороны IDE.
DOO>>>>Про оптимизатор на уровне Intel C++ — ну и сколько процентов народу используют этот компилятор? А у остальных тоже не такие уж выдающиеся результаты по сравнению с ним.
L>>>А фокус в том, что он есть. И если нужно — можно использовать. А в дельфи — нужно, не нужно, а про качественную машинную оптимизацию можно забыть.
Фокус в том, что то же ядро линукса я, например, Intel C++ так запросто не соберу (когда-то, кстати, были патчи позволявшие сделать это...) — у серьезных проектов один фиг есть привязка к конкретным фичам компилятора.
kuj>Ты не понял. Во-первых, в C++ можно и std::list< void * >, во-вторых, это дает не гибкость, а широкое поле для ошибок и проблем с приведением типов.
И снова мы упираемся в различные подходы — для тебя программа во время выполнения статична, для дельфиста — нет.
kuj>И конечно же негативно сказывается на производительности.
Это почему? Потому что надо будет поддержку RTTI включить? Ну в дельфи ее просто не выключить
Здравствуйте, WolfHound, Вы писали:
WH>Но даже на том что есть можно творить очень веселые и иногда даже практичные вещи.
Это, как правило, не есть тезис в пользу промышленного языка
У нас один преподаватель в университете про языки с очень большим числом степеней свободы говорил, что это миры: мир ассемблера, мир перла и т.п. Изучать эти миры можно хоть всю жизнь, но суровая действительность требует практических скучных решений
H>>В Delphi их тоже нет. То что обсуждалось с DX, это ни какая не проблема. Это нарушений правил языка. G>В C# не надо таких правил даже знать не надо. Просто нет особенностей работы с COM.
Интересно, пишущих на басике всегда чморили за то, что они ни фига ни в чем не понимают, но пишут — а теперь это уже плюсом стало... Любое незнание раон или поздно вылезет тебе боком.
H>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов.
Угу... А какие протоколы обмена используются? А какие порты? А как там с безопасностью?
H>>Не SQL'ем единым, как говорится. Применение Delphi не ограничивается мордами к БД. G>Морда к БД — как раз основное применение делфи. Сложную логику там реализовывать напряжно. G>Работа с БД — одна из основных частей бизнес-приложений. Это чуть ли не самый большой рынок сейчас.
G>1)SAX и DOM рядом не валялись новой билиотекой по работе XML в .NET 3.5
На вкус и цвет фломастеры разные. Как ты будешь писать Jabber сервер, используя DOM?
G>// Client.cs
G>using System;
G>using System.Runtime.Remoting;
G>using TestObject;
G>namespace Client
G>{
G> class Client
G> {
G> [STAThread]
G> static void Main(string[] args)
G> {
G> RemotingConfiguration.Configure("Client.exe.config");
G> Test test = new Test();
G> Console.WriteLine(test.GetAppName()); //Здесь test.GetAppName() вызовется на сервере!!!!
G> }
G> }
G>}
G>
G>Такое на делфи возможно?
Такое возможно даже на VBScript. DCOM называется. Вот только вся твоя красота может быть (да точно будет!) обломана настройками безопасности. Ты хоть сможешь это корректно обработать?
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, lifrsdn, Вы писали:
L>>Ну и что в этом хорошего? Кстати, kuj про shared/scoped_ptr не зря вспомнил. В дельфи как их реализовать? DOO>Никак DOO>Чтобы язык был простым от чего-то надо отказываться. DOO>Этих shared/scoped_ptr нет, например, и в Javascript, но это не мешает последнему занимать свою нишу...
В Javascript есть GC. Там поинтеры вообще не нужны. А в делфи нет.
Короче -1
G>>// Client.cs
G>>using System;
G>>using System.Runtime.Remoting;
G>>using TestObject;
G>>namespace Client
G>>{
G>> class Client
G>> {
G>> [STAThread]
G>> static void Main(string[] args)
G>> {
G>> RemotingConfiguration.Configure("Client.exe.config");
G>> Test test = new Test();
G>> Console.WriteLine(test.GetAppName()); //Здесь test.GetAppName() вызовется на сервере!!!!
G>> }
G>> }
G>>}
G>>
G>>Такое на делфи возможно? DOO>Такое возможно даже на VBScript. DCOM называется.
Какие еще языки поддерживают такуюже легкость работы с COM? Что-то мне кажется что никакие.
Если попробовать написать подобное с DCOM на С++ или Delphi, то получится в разы больше кода, не считая автогенерных Proxy и Stub.
А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие)
DOO>Вот только вся твоя красота может быть (да точно будет!) обломана настройками безопасности. Ты хоть сможешь это корректно обработать?
Remoting можно настроить чтобы он работал через HTTP c помощью SOAP. Все это в конфиге, как на клиенте, так и на сервере
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
H>>>В Delphi их тоже нет. То что обсуждалось с DX, это ни какая не проблема. Это нарушений правил языка. G>>В C# не надо таких правил даже знать не надо. Просто нет особенностей работы с COM. DOO>Интересно, пишущих на басике всегда чморили за то, что они ни фига ни в чем не понимают, но пишут — а теперь это уже плюсом стало... Любое незнание раон или поздно вылезет тебе боком.
А может все-такие "чморили" за результат? (Лично я всегда им завидовал. То что они берут и делают не заморачиваясь всякой ерундой.) Если язык позволяет получать качественный результат без знания чего-то то это языку определенно в плюс.
H>>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов. DOO>Угу... А какие протоколы обмена используются? А какие порты? А как там с безопасностью?
Здравствуйте, _d_m_, Вы писали:
___>Неа. Только не стоит забывать, что JIT компилятор работает с байт кодом, а не с исходниками. Яволь?
Вот смотри: у нас есть обычный компилятор и JIT. У первого — времени столько, сколько понадобится, никаких ограничений не накладывается.
У второго — ограничение на время генерации машинного кода. При прочих равных, у первого больше возможностей породить более оптимизированный код.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, DOOM, Вы писали:
DOO>>Такое возможно даже на VBScript. DCOM называется. G>Какие еще языки поддерживают такуюже легкость работы с COM? Что-то мне кажется что никакие.
Да почему — в Дельфях можно было подрубать те же IDispatch'и и превращать программу в какое-то подобие скрипта... Абсолютно аналогично VBScript'у.
G>Если попробовать написать подобное с DCOM на С++ или Delphi, то получится в разы больше кода, не считая автогенерных Proxy и Stub. G>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие)
В Дельфи можно было этого избежать.
DOO>>Вот только вся твоя красота может быть (да точно будет!) обломана настройками безопасности. Ты хоть сможешь это корректно обработать? G>Remoting можно настроить чтобы он работал через HTTP c помощью SOAP. Все это в конфиге, как на клиенте, так и на сервере
Вопрос даже не в протоколе передачи — вопрос в настройках безопасности для сборок .Net, в настройках DCOM на целевом компьютере (ну тут стоит отметить, даже MS'овский софт не способен адекватно обработать ситуацию с кривыми правами на DCOM).
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>В C# не надо таких правил даже знать не надо. Просто нет особенностей работы с COM. DOO>Интересно, пишущих на басике всегда чморили за то, что они ни фига ни в чем не понимают, но пишут — а теперь это уже плюсом стало... Любое незнание раон или поздно вылезет тебе боком.
Во-первых .NET и С# позволяет решать гораздо больший круг задач чем вбасик. Во-вторых интероп на .NET гораздо проще. В-третьих С# полноценный ОО-язык, в отличие от VB 6.0.
Может в .NET незнание и вылезкт боком, но гораздо позже, чем в VB. А за это время программист сможет изучить все что надо.
H>>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов. DOO>Угу... А какие протоколы обмена используются? А какие порты? А как там с безопасностью?
Читайте доки, все в конфигах указывается.
Если мало вожможностей Remoting, то используйте WCF, там очень много всего поддерживается. Только модель программирования там менее лаконичная.
G>>1)SAX и DOM рядом не валялись новой билиотекой по работе XML в .NET 3.5 DOO>На вкус и цвет фломастеры разные. Как ты будешь писать Jabber сервер, используя DOM?
Когда мне понадобится Jabber сервер я найду готовую реализацию на .NET
КБ>А может все-такие "чморили" за результат?
Может. Но когда ты связан по рукам и ногам и должен идти единственно верной дорогой — результат и начинает хромать (ты не всегда понимаешь эту верную дорогу и начинаешь выдумывать какие-то жуткие костыли). К слову сказать, мне как-то приходилось пописывать на VB приложения для Access'а — ощущение, что тебя заперли в комнате со стенами обитыми матрасами, по другому не назвать.
H>>>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>>>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>>>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов. DOO>>Угу... А какие протоколы обмена используются? А какие порты? А как там с безопасностью?
КБ>А как в конфиге напишешь так и будет
Только подавляющее большинство пользователей этого Remoting'а даже не подозревают про существование этого конфига?
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, DOOM, Вы писали:
DOO>>>Такое возможно даже на VBScript. DCOM называется. G>>Какие еще языки поддерживают такуюже легкость работы с COM? Что-то мне кажется что никакие. DOO>Да почему — в Дельфях можно было подрубать те же IDispatch'и и превращать программу в какое-то подобие скрипта... Абсолютно аналогично VBScript'у.
И получать Runtime error на коде, который выглядит как обычный статический.
G>>Если попробовать написать подобное с DCOM на С++ или Delphi, то получится в разы больше кода, не считая автогенерных Proxy и Stub. G>>А еще добавитсявозня с DCOM совместимыми типами (Variant и прочие) DOO>В Дельфи можно было этого избежать.
Ну да, использовать простые типы
DOO>>>Вот только вся твоя красота может быть (да точно будет!) обломана настройками безопасности. Ты хоть сможешь это корректно обработать? G>>Remoting можно настроить чтобы он работал через HTTP c помощью SOAP. Все это в конфиге, как на клиенте, так и на сервере DOO>Вопрос даже не в протоколе передачи — вопрос в настройках безопасности для сборок .Net, в настройках DCOM на целевом компьютере (ну тут стоит отметить, даже MS'овский софт не способен адекватно обработать ситуацию с кривыми правами на DCOM).
Remoting вообще не использует DCOM. Для сборок на компе по-умолчанию FullTrust. При работе через 80 порт по протоколу HTTP все будет пучком.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, Константин Б., Вы писали:
КБ>>А может все-такие "чморили" за результат? DOO>Может. Но когда ты связан по рукам и ногам и должен идти единственно верной дорогой — результат и начинает хромать (ты не всегда понимаешь эту верную дорогу и начинаешь выдумывать какие-то жуткие костыли). К слову сказать, мне как-то приходилось пописывать на VB приложения для Access'а — ощущение, что тебя заперли в комнате со стенами обитыми матрасами, по другому не назвать.
Ну на C# такого ощущения нет.
H>>>>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS. G>>>>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов? G>>>>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов. DOO>>>Угу... А какие протоколы обмена используются? А какие порты? А как там с безопасностью?
КБ>>А как в конфиге напишешь так и будет DOO>Только подавляющее большинство пользователей этого Remoting'а даже не подозревают про существование этого конфига?
А им и не надо. Ты видел хоть раз чтобы пользователи распределенного приложения сами правили конфиги (про линукс молчать, там другого пути нет)?
Тем более никто не мешает написать красивый графический конфигуратор.
Если ты имеешь ввиду программситов, которые используют распределенные объекты, то им незнание не мешает. Достаточно чтобы один программист знал это написать.
G>Remoting вообще не использует DCOM.
Что бы он там не использовал, но у меня все равно должен быть инструмент, который скажет — вот эту бяку запускать только локлаьно и только админом, эту вообще не запускать и т.п.
G>Для сборок на компе по-умолчанию FullTrust.
Настройки по умолчанию это неинтересно. Надо знать какие конкретно права необходимы сборке локально и удаленно, чтобы remoting работал как надо. Иначе будут непонятки (сменятся умолчания с выходом очередного SP и все — приехали).
Вообще проблема не надумана — после установки ISA Server 2004 SP2 на W2k3 SP1 R2 некоторые инструменты администрирования MS перестают работать (например, настройка NLB кластера) — в чем конкретно проблема
G>При работе через 80 порт по протоколу HTTP все будет пучком.
А MS RPC тоже частенько работает только по 445-му порту (ну или 139-му), но это не значит, что нет грамотных МЭ, которые не отсекут конкретный интерфейс...
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>Remoting вообще не использует DCOM. DOO>Что бы он там не использовал, но у меня все равно должен быть инструмент, который скажет — вот эту бяку запускать только локлаьно и только админом, эту вообще не запускать и т.п.
Есть такое.
G>>Для сборок на компе по-умолчанию FullTrust. DOO>Настройки по умолчанию это неинтересно. Надо знать какие конкретно права необходимы сборке локально и удаленно, чтобы remoting работал как надо. Иначе будут непонятки (сменятся умолчания с выходом очередного SP и все — приехали).
В MSDN все это есть. Если не хватает каких-то прав, то .NET очень адекватно выругается с указанием чего конкретно не хватает.
DOO>Вообще проблема не надумана — после установки ISA Server 2004 SP2 на W2k3 SP1 R2 некоторые инструменты администрирования MS перестают работать (например, настройка NLB кластера) — в чем конкретно проблема
Причем здесь .NET и языки?
G>>При работе через 80 порт по протоколу HTTP все будет пучком. DOO> DOO>А MS RPC тоже частенько работает только по 445-му порту (ну или 139-му), но это не значит, что нет грамотных МЭ, которые не отсекут конкретный интерфейс...
Товарищ, 80 порт открыт на 99,9% машин. По умолчанию все фаерволы оставляют 80 порт открытым.
Здравствуйте, gandjustas, Вы писали:
G>В MSDN все это есть. Если не хватает каких-то прав, то .NET очень адекватно выругается с указанием чего конкретно не хватает.
Хотелось бы верить.
DOO>>Вообще проблема не надумана — после установки ISA Server 2004 SP2 на W2k3 SP1 R2 некоторые инструменты администрирования MS перестают работать (например, настройка NLB кластера) — в чем конкретно проблема G>Причем здесь .NET и языки?
Это демонстрация. Пусть тут DCOM и RPC — но смысл в том же. Все это хорошо работает, пока не пытаешься что-то поменять.
DOO>>А MS RPC тоже частенько работает только по 445-му порту (ну или 139-му), но это не значит, что нет грамотных МЭ, которые не отсекут конкретный интерфейс... G>Товарищ, 80 порт открыт на 99,9% машин. По умолчанию все фаерволы оставляют 80 порт открытым.
Товарищ, открытый порт еще ничего не значит. Давно уже все используют МЭ прикладного уровня, особенно для Web-трафика. Я тебе специально в пример привел RPC — на ISA сервере я могу перекрыть конкретные RPC интерфейсы, даже если используется транспорт nc_acn_named_pipes — который гуляет поверх SMB, т.е. 445-го или 139-го порта.
Здравствуйте, DOOM, Вы писали:
DOO>>>А MS RPC тоже частенько работает только по 445-му порту (ну или 139-му), но это не значит, что нет грамотных МЭ, которые не отсекут конкретный интерфейс... G>>Товарищ, 80 порт открыт на 99,9% машин. По умолчанию все фаерволы оставляют 80 порт открытым. DOO>Товарищ, открытый порт еще ничего не значит. Давно уже все используют МЭ прикладного уровня, особенно для Web-трафика. Я тебе специально в пример привел RPC — на ISA сервере я могу перекрыть конкретные RPC интерфейсы, даже если используется транспорт nc_acn_named_pipes — который гуляет поверх SMB, т.е. 445-го или 139-го порта.
Это из тойже оперы что поудалять конфиги,а потом жаловаться на .NET.
