Hello MouseTail, you wrote:

> Давайте всё же будем рассматривать языки, имеющие примерно равные
> возможности... На Прологе вы сможете написать win32-сервис?

Так вы языки сравниваете, или же компиляторы?

--
Всего хорошего, Слава

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Хорош пример

>>Компиляция данного примера возможна только с Delphi 3. Delphi 2 не был опробован в связи с его отсутствием, объектные фалы созданные Delphi 4 отвергаются Microsoft ® Linker 5.12.8181 как файлы неизвестного формата.

SM>Мило, ничего не скажешь. Небось из-за COMDEF-записей и отвергаются "фалы". Я уж как-нибудь буду на D6 или D7 писать

SM>А насчет того, что я написал — переходник был нужен вроде бы именно для вырезания несовместимых записей в OBJ, тогда и уродовать RTL не надо. Впрочем, подробный отзыв напишу, только когда увижу журнал. Пока не прислали, и даже не запрос не ответили.

SM>Slicer

ну во-первых сейчас линкер в поставке ХР ДДК 7.00.9210
во-вторых он имеет оч много разных опций
ну и в третьих надобы конкретно узнать, чего ему не хватает.

могет и возможно сделать спецтулзу для патча дельфовых обжей.
всежтаки иде от 7-го рулит!

и еще — когда на выложат полный вариант?
когда выйдет след номер, т.е. после нового года ?

Здравствуйте, Slava Antonov, Вы писали:

>> Давайте всё же будем рассматривать языки, имеющие примерно равные
>> возможности... На Прологе вы сможете написать win32-сервис?

SA>Так вы языки сравниваете, или же компиляторы?

Я комментирую не совсем корректное сравнение Delphi и Пролога.

Здравствуйте, Slicer [Mirkwood], Вы писали:

MT>>Давайте всё же будем рассматривать языки, имеющие примерно равные возможности... На Прологе вы сможете написать win32-сервис? Или, скажем, user-mode sniffer/firewall? Наверное, нет. А среди равных по возможностям языков выдвинутый мною тезис вполне справедлив.
SM>Спору нет, какие-то задачи из подобных (т.е. написания драйверов, сервисов etc.) я решу на C++ не быстрее, чем на Delphi. А какие-то — быстрее. И красивее. Или вот взять ту же разработку игр.

Вы знаете, я очень часто в подобных дискуссиях слышу ссылки на разработку игр... До тех пор, пока очередной сторонник С\С++ не узнает, какие из достаточно известных игр были написаны на Delphi

SM>К сожалению, какие-то — медленнее, потому что, несмотря на весь потенциал C++, дурная поддержка COM — самое слабое, на мой взгляд, место в этом языке. Так что я бы свел результаты сравнения языков к формуле выбора: либо красиво решенная работа с COM и интерфейсами, либо наличие шаблонов. Все остальное — мелочи.

Собственно, об этом я уже говорил несколько сообщений назад, в ответ на заявление об "очевидном факте" — количество недостатков и достоинств у них примерно одинаково и взаимно скомпенсировано

MT>>Вы таки хотите поднять волну флейма? Придумайте, пожалуйста, аналоги для WITH, SET, AS, IN, PROPERTY, модификаторам CONST/VAR/OUT, или скажем для INTERFACE (который тип), ARRAY OF. Продолжать?
SM>Для with аналога действительно нет, это минус, но — совсем малюсенький, из-за возможности объявлять локальные переменные где угодно в коде.

Ну нифига себе однако. Знаете, как оно задалбывает — постоянно копи-пастить при заполнении полей какой-нибудь структуры вроде MIB_IFROW ?

SM>Set вроде уже воспроизведен (-но?) хотя бы в Builder, да и потом — в подавляющем большинстве случаев он (оно) равноценен набору констант.

Ну да По вашему запись вида

((ClassRoom&&Vasya)!=0)&&((ClassRoom&&Petya)!=0)

более очевидна, чем

((Vasya in ClassRoom) and (Petya in ClassRoom))

? Даже если в машинных кодах это совершенно одно и то же.

SM>Property, из моего опыта в последнее время, приносит больше вреда, чем пользы, как раз из-за скрытых от программиста действий: то ли мы просто получаем значения поля, то ли вызывается какой-то метод...

Хм. А вас не пугает скрытость от программиста действий некоторой функции, которую вы вызываете????

Ведь как раз в этих двух возможностях и состоит прелесть механизма свойства — разделения процессов чтения и записи свойства (соответственно, возможность создания как ReadOnly так и WriteOnly свойств) и прозрачность процесса обращения к свойству, как к полю, вне зависимости от того, что на самом деле происходит при этом. Называть это недостатком может только тот, кто не понимает преимущества такого подхода Я уж молчу про default, stored, published и прочих вкусностях свойств.

SM>CONST/VAR/OUT... Для const и var долго искать не надо, причем их смысл в C++ не в пример очевиднее,

Да, знаете в чём эта очевидность? Для констатнтых параметров передаётся само значение, а для переменных — указатель на область памяти, где находится переменная. Причём "указательность" параметра порой настолько неочевидна что приходится рыться в туевой хуче typedef'ов, выискивая что же это за тип на самом деле передаётся. В этом смысле непосредственный модификатор обьявления параметра куда как нагляднее.

SM> чем в Delphi (я о счетчиках ссылок и проч.),

Минуточку. О каких таких счётчиках ссылок идёт речь?

SM> с Out сложнее, его и правда до сих пор нет.

Жаль, а я думал что Вы напишете что-то вроде "Очищать переменную можно и прямо в коде и незачем для этого придумывать модификатор".

SM>Array of... А чем так плохи STL-контейнеры? Скажете, это не часть языка? Да, но это часть стандарта Если уж придираться к словам, то — да, этого в C++ нет. Хотя опять же можно красиво реализовать.

Да реализовать можно всё, что угодно. Даже, например, такую совершенно безобидную вещь как нумерацию массивов не с 0. Я был просто потрясён однажды .

Ладно, а вот вам ещё задачка.

Как вот это записать в синтаксисе С\С++ ?

var BasePtr : Pointer;
    OffSet : Cardinal;
...
Result:=Pointer(Cardinal(BasePtr)+OffSet);

SM>>> Еще что-то можно сделать возможным, введя базовый класс и потребовав у всех от него наследоваться.
MT>>Это костыль, вы же понимаете. Введением класса можно добиться любой функциональности, которой нет в языке, но это доказывает лишь то, что такой функциональности нет в языке.
SM>Но язык построен так, что она воспроизводима в его рамках,

Так построен любой нормальный язык высокого уровня! В том числе и Delphi, конечно. А то так можно договориться и до того, что ООП и прочие фишки вполне реализуемы средствами чистого ассемблера. Конечно реализуемы, но ведь удобнее иметь это уже в реализации самого языка.

MouseTail

Здравствуйте, Ihor Osovyak, Вы писали:

MT>> Если взять обычного программера, владеющего в достаточной мере, допустим, Delphi, BCB, MSVC и т.п. и поставить перед ним такое ТЗ, то он для реализации выберет Delphi в последнюю очередь. Всё потому, что Delphi окружена целой стеной мифов и предрассудков, порождённых гуёвыми мышевозильщиками и бросателями компонентов на формы.
IO>Хм. А почему такая увереность за всех. Я, кстати, для аналогичной задачи выбрал бы делфи.
IO>На си проект делал бы только в том случае, если бы заказчик очень настаивал. И то, после повышения расценок.

Ну я очень рад за Вас

IO>Да, но самолеятельностью с подменой RTL я бы не занимался. Хотя бы потому, что на полке стоят не до конца проработанные A.Jones,J. Ohlund, D. Iseminger. Чтение последних заметно больше пользы приносит для программирования сетей в Делфи, чем переработка RTL.

Могу Вас заверить, что вдумчивое чтение MSDN помогает в программировании для сетей заметно больше И, честно говоря, разработка собственной невизуальной RTL очень сильно сократила мне время на решение многих типовых задач такого плана.

Hello MouseTail, you wrote:

> Вы знаете, я очень часто в подобных дискуссиях слышу ссылки на
> разработку игр... До тех пор, пока очередной сторонник С\С++ не узнает,
> какие из достаточно известных игр были написаны на Delphi

Поделитесь, плиз, информацией.

--
Всего хорошего, Слава

Здравствуйте, MouseTail, Вы писали:

SM>>CONST/VAR/OUT... Для const и var долго искать не надо, причем их смысл в C++ не в пример очевиднее,
MT>Да, знаете в чём эта очевидность? Для констатнтых параметров передаётся само значение, а для переменных — указатель на область памяти, где находится переменная. Причём "указательность" параметра порой настолько неочевидна что приходится рыться в туевой хуче typedef'ов, выискивая что же это за тип на самом деле передаётся. В этом смысле непосредственный модификатор обьявления параметра куда как нагляднее.
Пардон, но при чем тут Typedef? Речь о

int func(const int& i);

MT>Как вот это записать в синтаксисе С\С++ ?

MT>

MT>var BasePtr : Pointer;
MT>    OffSet : Cardinal;
MT>...
MT>Result:=Pointer(Cardinal(BasePtr)+OffSet);
MT>

Гм. А в чем прикол?

return BasePtr+OffSet;

Здравствуйте, MouseTail, Вы писали:

MT>Вы знаете, я очень часто в подобных дискуссиях слышу ссылки на разработку игр... До тех пор, пока очередной сторонник С\С++ не узнает, какие из достаточно известных игр были написаны на Delphi
Наверное, писали такие же фанатичные (скорее в положительном смысле) товарищи, как Вы. Это не выпад, это констатация возможности, основываясь на Вашем примере

SM>>К сожалению, какие-то — медленнее, потому что, несмотря на весь потенциал C++, дурная поддержка COM — самое слабое, на мой взгляд, место в этом языке. Так что я бы свел результаты сравнения языков к формуле выбора: либо красиво решенная работа с COM и интерфейсами, либо наличие шаблонов. Все остальное — мелочи.
MT>Собственно, об этом я уже говорил несколько сообщений назад, в ответ на заявление об "очевидном факте" — количество недостатков и достоинств у них примерно одинаково и взаимно скомпенсировано
Количество, но не качество. В Delphi удобнее синтаксис работы с интерфейсами, но если вам при всех этих красивостях ни разу не приходилось вызывать _AddRef и _Release, просто "для гарантии", что очередная версия Delphi не сделает код нерабочим, изменив механизм инкремента-декремента ссылок на интерфейс при входе в функцию, причем и так разный при передаче по var, сonst, out и просто так, я буду удивлен. На одном синтаксисе далеко не уедешь. Впрочем, согласен, можно попробовать включить в сферу применимости Delphi еще и жесткую работу с IDispath (помимо создания UI). Обычно, правда, все юзают раннее связывание, а с ним в C++ все не так глухо.

MT> Ну нифига себе однако. Знаете, как оно задалбывает — постоянно копи-пастить при заполнении полей какой-нибудь структуры вроде MIB_IFROW ?

CMyObject* pMyObj = MyRoot->MyFn()->MyContainer->ContainedObject;
pMyObj->DoSmth();
pMyObj->DoSmthElse()

И никаких глюков с указателями, которыми изобилует With Или пастить "pMyObj->" тоже напрягает? Генацвале, а макрокоманды на что? Если их можно успешно юзать в Delphi, почему не пользоваться ими в Visual C++? (Не путать с макросами, которые, кстати, в Delphi реализованы УЖАСНО). Написали без копипастов, потом нажали n раз и получили требуемое. Это скорее мелкий недостаток, нежели существенный.

SM>>Set вроде уже воспроизведен (-но?) хотя бы в Builder, да и потом — в подавляющем большинстве случаев он (оно) равноценен набору констант.
MT>Ну да По вашему запись вида... [skipped] Даже если в машинных кодах это совершенно одно и то же.
Нет, я имею в виду что-то из объявлений функций в D7 в хелпе, там есть билдерский вариант и интересное словечко Set в названии типов; сам я в билдере не работал, Вы, похоже, тоже — раз это написали. Так что тут вопрос остается открыт. Если что — можно написать свой Set; а есть, кстати, битовый контейнер из STL (остается прописать константы для индексов). Насчет своего set — будете говорить, что написать можно что угодно. Но — см. последний пункт — многие вещи, которые на Delphi написать, безусловно, можно, будут либо неуниверсальны, либо чужеродно смотреться среди остальных конструкций языка. Опять же возвращаюсь к наиболее яркому примеру "шаблонов" путем инклудов.

SM>>Property, из моего опыта в последнее время, приносит больше вреда, чем пользы, как раз из-за скрытых от программиста действий: то ли мы просто получаем значения поля, то ли вызывается какой-то метод...
MT>Хм. А вас не пугает скрытость от программиста действий некоторой функции, которую вы вызываете????
Обычно нет, т.к. я знаю, что это функция. Впрочем, на самом деле я так не думаю Просто со зла сорвалось: как раз недавно с этим мучился. А вообще, стоит раз и навсегда положить, что чтение свойства — это вызов функции, которая делает еще что-то (например, опрашивает API). Хотя для многих свойств было бы приятно быть уверенным, что их чтение — это простое чтение поля, и не извращаться с потокобезопасностью.

SM>>CONST/VAR/OUT... Для const и var долго искать не надо, причем их смысл в C++ не в пример очевиднее,
MT>Да, знаете в чём эта очевидность? Для констатнтых параметров передаётся само значение, а для переменных — указатель на область памяти, где находится переменная. Причём "указательность" параметра порой настолько неочевидна что приходится рыться в туевой хуче typedef'ов, выискивая что же это за тип на самом деле передаётся. В этом смысле непосредственный модификатор обьявления параметра куда как нагляднее.
Уже ответили А вот в Delphi, где передача объекта по const вовсе не означает константности объекта, зато передача по var почему-то автоматом правит счетчик ссылок, очевидностью и не пахнет.

Я, кстати, забыл злобно пнуть отстутствие статических объектов в Delphi — точнее, отсутствие их автодеструкции. Try-Finally вечно нарушает логику "абзацных" отступов (indentation).

SM>> чем в Delphi (я о счетчиках ссылок и проч.),
MT>Минуточку. О каких таких счётчиках ссылок идёт речь?
Как — о каких? Об ANSI- и WideChar- строках, о динамических массивах, об интерфейсах.

SM>> с Out сложнее, его и правда до сих пор нет.
MT>Жаль, а я думал что Вы напишете что-то вроде "Очищать переменную можно и прямо в коде и незачем для этого придумывать модификатор".
Как и в случае с Set, я не пытаюсь утверждать, что замена одной конструкции на другую с потерей семантики — равнозначна. Но без потери — вполне. Явная очистка вместо out — это потеря семантики. А обращение к Set через [] — не &, и уж тем более не && — вполне ее сохраняет.

SM>>Array of... А чем так плохи STL-контейнеры? Скажете, это не часть языка? Да, но это часть стандарта Если уж придираться к словам, то — да, этого в C++ нет. Хотя опять же можно красиво реализовать.
MT>Да реализовать можно всё, что угодно. Даже, например, такую совершенно безобидную вещь как нумерацию массивов не с 0. Я был просто потрясён однажды .
И будет она смотреться вполне естественно. А можно поинтересоваться, как Вы реализуете в Delphi массив с индексом типа double, ограниченным диапазоном от A до B, где A и B задаются? Чтобы доступ автоматом выполнял округление. Разумеется, вы это сделаете!!! Но! Одна запись создаст ссылку на массив, а другая — сам массив (и задаст индексы). В отличие от C, где такой "массив" можно будет объявить статически, хотя бы так: "MyDoubleIndexedArray<MyA,MyB> array;", прямо среди остальных переменных.

MT>Ладно, а вот вам ещё задачка.
MT>Как вот это записать в синтаксисе С\С++ ?

MT>

MT>var BasePtr : Pointer;
MT>    OffSet : Cardinal;
MT>...
MT>Result:=Pointer(Cardinal(BasePtr)+OffSet);
MT>

Итак, вы таки паскалист Как раз-таки гораздо короче это будет именно на C++, и с этим у меня было достаточно мороки, когда я писал здесь, на RSDN, статью о PE-загрузчике. Там через каждые три строки идет такое обращение. Более того, при желании можно наделить BasePtr семантикой указателя на массив, и писать BasePtr[Offset], что иногда выглядит более естественно.

SM>>>> Еще что-то можно сделать возможным, введя базовый класс и потребовав у всех от него наследоваться.
MT>>>Это костыль, вы же понимаете. Введением класса можно добиться любой функциональности, которой нет в языке, но это доказывает лишь то, что такой функциональности нет в языке.
SM>>Но язык построен так, что она воспроизводима в его рамках,
MT>Так построен любой нормальный язык высокого уровня! В том числе и Delphi, конечно. А то так можно договориться и до того, что ООП и прочие фишки вполне реализуемы средствами чистого ассемблера. Конечно реализуемы, но ведь удобнее иметь это уже в реализации самого языка.
В его рамках — это не совсем точно. Имелось в виду — использование рукотворного подобия чего-либо выглядит столь же естественно, как и само это что-то. И я привел выше достаточно типичный пример попытки введения в Delphi нового базового элемента, со вполне очевидными последствиями.

---

Поскольку профессиональная гордость ни одному из нас не позволит признать публично свою неправоту, предлагаю на этом закрыть дискуссию. Это относится ко всем участникам — а то у нас уже давно оффтоп идет

Slicer

Здравствуйте, Slava Antonov, Вы писали:

>> Вы знаете, я очень часто в подобных дискуссиях слышу ссылки на
>> разработку игр... До тех пор, пока очередной сторонник С\С++ не узнает,
>> какие из достаточно известных игр были написаны на Delphi
SA>Поделитесь, плиз, информацией.

Точно знаю про Venom http://www.deep-shadows.com/hax/#Venom

Где-то в fido7.ru.delphi недавно была дискуссия по этому поводу, упоминали несколько известных стратегий. В любом случае, Гугл в помощь

Здравствуйте, MouseTail, Вы писали:

MT>Точно знаю про Venom http://www.deep-shadows.com/hax/#Venom
Сходил по ссылке ради интереса.

Language: Microsoft Visual C++ 6.0, Borland Delphi 5.0, Assembler

Так что еще вопрос, какую часть игры писали на Delphi. Возможно, что только меню. Тем более, что с FPU студия работает не в пример лучше.

Slicer

Здравствуйте, Геннадий Порев, Вы писали:

Накопал линкер, который понимает одновременно и OMF от delphi 7 и COFF от MS DDK.
Брать здесь

Здравствуйте, Tonal-, Вы писали:

T>Здравствуйте, Геннадий Порев, Вы писали:

T>Накопал линкер, который понимает одновременно и OMF от delphi 7 и COFF от MS DDK.
T>Брать здесь

http://здесь/ — server not found

Здравствуйте, MouseTail, Вы писали:

/*Поскипано*/


MT>Могу Вас заверить, что вдумчивое чтение MSDN помогает в программировании для сетей заметно больше И, честно говоря, разработка собственной невизуальной RTL очень сильно сократила мне время на решение многих типовых задач такого плана.

Я не любитель Delphi/Pascal и не сторонник перевода заголовков DDK на паскаль, просто потому, что сам давно ушел от Deplhi к MS VS и не перестаю регулярно убеждаться в его (Delphi/Pascal) ущербности. Я считаю, что Delphi — для ваятелей форм, а ести ты хочешь написать что-то системное-используй для этого профессиональную среду и язык.

Sorry, если обидел любителей паскаля- я не нарочно, честно

MT>В целом согласен. Но. Целью данного материала являлось лишь показать принципиальную возможность. Застолбить первенство на непаханом поле, обеспечить приоритет, как это принято в научном мире. В данный момент последующая жизнь этой отрасли под моим руководством весьма сомнительна — временных ресурсов катастрофически не хватает. Но если найдутся энтузиасты, всё же пусть на одном из первых кирпичиков там будет надпись — "Здесь был я"

MT>Собственно, никаких более масштабных целей этой публикацией я не преследовал.

В который раз видим, что миром правит тщеславие
Простите, но прореха в средствах разработки драйверов, о которой Вы говорите, на самом деле куда больше, чем кажется. Не так сложно написать драйвер, как отладить его. И тут уж гораздо бОльшим подспорьем был бы каой-то фреймворк с хорошими возможностями протоколирования, поиска ошибок. И вообще замечательно, если бы ыэтот фреймворк перегружал драйвер без перезагрузки системы на любой разновидности Windows.
И, поверьте старому маразматику, никто не вспомнит того кирпича, на котором было написано "Здесь был я, MouseTail", ибо было это один раз и вначале. А если Вы напишете толковый фреймворк — его будут видеть ежедневно на экране тысячи программистов и говорить: "крутую фичу замутил этот MouseTail".
Соразмеряйте усилия

Здравствуйте, MouseTail, Вы писали:

T>>Накопал линкер, который понимает одновременно и OMF от delphi 7 и COFF от MS DDK.
T>>Брать здесь

MT>http://здесь/ — server not found
Извиняюсь, таки здесь

Hello ArtemGorikov, you wrote:

> Sorry, если обидел любителей паскаля- я не нарочно, честно

Ага. Сначала скажут, что все козлы, а потом: "я не хотел никого обидеть"

ЗЫ: А что вы в этом форуме тогда потеряли, раз на MS VS пишете?

--
Всего хорошего, Слава

Здравствуйте, Аноним, Вы писали:

MT>>В целом согласен. Но. Целью данного материала являлось лишь показать принципиальную возможность. Застолбить первенство на непаханом поле, обеспечить приоритет, как это принято в научном мире. В данный момент последующая жизнь этой отрасли под моим руководством весьма сомнительна — временных ресурсов катастрофически не хватает. Но если найдутся энтузиасты, всё же пусть на одном из первых кирпичиков там будет надпись — "Здесь был я"

MT>>Собственно, никаких более масштабных целей этой публикацией я не преследовал.

А>В который раз видим, что миром правит тщеславие
А>Простите, но прореха в средствах разработки драйверов, о которой Вы говорите, на самом деле куда больше, чем кажется. Не так сложно написать драйвер, как отладить его. И тут уж гораздо бОльшим подспорьем был бы каой-то фреймворк с хорошими возможностями протоколирования, поиска ошибок. И вообще замечательно, если бы ыэтот фреймворк перегружал драйвер без перезагрузки системы на любой разновидности Windows.

Необходимость ребута системы зависит только от класса драйвера, и никаким образом от фреймворка . И кроме того, Вы же понимаете особенности драйверостроения : какая-нибудь ошибочка и — BSOD. Отлаживают драйвера SoftICE'ом и это правильно. Дублировать его функциональность я не считаю нужным, да и возможным для себя в разумные сроки .

А>И, поверьте старому маразматику, никто не вспомнит того кирпича, на котором было написано "Здесь был я, MouseTail", ибо было это один раз и вначале. А если Вы напишете толковый фреймворк — его будут видеть ежедневно на экране тысячи программистов и говорить: "крутую фичу замутил этот MouseTail".
А>Соразмеряйте усилия

Насчёт "никто не вспомнит" это Вы преувеличиваете. Конечно, Уильям Генри Гейтс III — персонаж более известный, чем Марк Збиковский, однако же количеству автографов последнего по всему миру можно только позавидовать, не так ли?

Здравствуйте, ArtemGorikov, Вы писали:

MT>>Могу Вас заверить, что вдумчивое чтение MSDN помогает в программировании для сетей заметно больше И, честно говоря, разработка собственной невизуальной RTL очень сильно сократила мне время на решение многих типовых задач такого плана.

AG>Я не любитель Delphi/Pascal и не сторонник перевода заголовков DDK на паскаль, просто потому, что сам давно ушел от Deplhi к MS VS и не перестаю регулярно убеждаться в его (Delphi/Pascal) ущербности. Я считаю, что Delphi — для ваятелей форм, а ести ты хочешь написать что-то системное-используй для этого профессиональную среду и язык.

Вы только что очень наглядно продемонстрировали именно то заблуждение, про которое и была написана данная статья . Знаете, я уже очень давно не ваял никаких форм на дельфях, а пишу всё время совершенно, как вы говорите, "системные" вещи. И я уверен, что у Вас на студии решение моих задач займёт не меньше времени и не меньше кода, чем у меня, а "профессиональность" языка тут вообще ни при чём.

AG>Sorry, если обидел любителей паскаля- я не нарочно, честно

Здравствуйте, MouseTail, Вы писали:

MT>Здравствуйте, ArtemGorikov, Вы писали:

MT>>>Могу Вас заверить, что вдумчивое чтение MSDN помогает в программировании для сетей заметно больше И, честно говоря, разработка собственной невизуальной RTL очень сильно сократила мне время на решение многих типовых задач такого плана.

AG>>Я не любитель Delphi/Pascal и не сторонник перевода заголовков DDK на паскаль, просто потому, что сам давно ушел от Deplhi к MS VS и не перестаю регулярно убеждаться в его (Delphi/Pascal) ущербности. Я считаю, что Delphi — для ваятелей форм, а ести ты хочешь написать что-то системное-используй для этого профессиональную среду и язык.

MT>Вы только что очень наглядно продемонстрировали именно то заблуждение, про которое и была написана данная статья . Знаете, я уже очень давно не ваял никаких форм на дельфях, а пишу всё время совершенно, как вы говорите, "системные" вещи. И я уверен, что у Вас на студии решение моих задач займёт не меньше времени и не меньше кода, чем у меня, а "профессиональность" языка тут вообще ни при чём.

AG>>Sorry, если обидел любителей паскаля- я не нарочно, честно

MT>

Есть тонкий нюанс : мне не надо в студии писать свою RTL, — она уже есть... Кроме того, в C++ есть такие вкусные вещи, как стандартные алгоритмы и контейнеры из STL, куча всяких полезных вещей из ATL, атрибуты (Attributed ATL), перегрузка операторов, встраиваемые (inline) функции, оптимизирующий компилятор, эффективно отсекающий никогда не вызываемые ветви кода, плюс быстрый код с для FPU. Перегрузка операторов, кроме того, позволяет перегрузить стандартные операции типа сложение-вычитание и реализовать их, скажем, на inline asm с MMX и SSE инструкциями. А так — почти одно и то же

Здравствуйте, ArtemGorikov, Вы писали:

MT>>>>Могу Вас заверить, что вдумчивое чтение MSDN помогает в программировании для сетей заметно больше И, честно говоря, разработка собственной невизуальной RTL очень сильно сократила мне время на решение многих типовых задач такого плана.
AG>>>Я не любитель Delphi/Pascal и не сторонник перевода заголовков DDK на паскаль, просто потому, что сам давно ушел от Deplhi к MS VS и не перестаю регулярно убеждаться в его (Delphi/Pascal) ущербности. Я считаю, что Delphi — для ваятелей форм, а ести ты хочешь написать что-то системное-используй для этого профессиональную среду и язык.
MT>>Вы только что очень наглядно продемонстрировали именно то заблуждение, про которое и была написана данная статья . Знаете, я уже очень давно не ваял никаких форм на дельфях, а пишу всё время совершенно, как вы говорите, "системные" вещи. И я уверен, что у Вас на студии решение моих задач займёт не меньше времени и не меньше кода, чем у меня, а "профессиональность" языка тут вообще ни при чём.
AG>>>Sorry, если обидел любителей паскаля- я не нарочно, честно
MT>>
AG>Есть тонкий нюанс : мне не надо в студии писать свою RTL, — она уже есть...

Есть ещё более тонкий нюанс. В дельфи тоже не надо писать свою RTL , потому что она тоже уже есть.

То что лично мне понадобилось отказаться от её использования и создавать что-то своё — так это лично мои проблемы, связанные с лично моим стилем проектирования программ.

AG> Кроме того, в C++ есть такие вкусные вещи, как стандартные алгоритмы и контейнеры из STL, куча всяких полезных вещей из ATL,

А в дельфи есть VCL

AG> атрибуты (Attributed ATL), перегрузка операторов, встраиваемые (inline) функции, оптимизирующий компилятор, эффективно отсекающий никогда не вызываемые ветви кода, плюс быстрый код с для FPU. Перегрузка операторов, кроме того, позволяет перегрузить стандартные операции типа сложение-вычитание и реализовать их, скажем, на inline asm с MMX и SSE инструкциями. А так — почти одно и то же

Не хотите ли Вы сказать, что в Delphi нет оптимизирующего компилятора? Или что в последних дельфях нет перегрузки операторов и инлайна?

---

Уважаемый Артём!!!! У меня нет совершенно никакого желания начинать с Вами по стонадцатому кругу бесконечный спор (Delphi-MSVS)!!! Убедить Вас в Вашей слепоте и предвзятости мне не удастся. Убеждать Вас в том, что Delphi круче, я не собираюсь, потому что это неправда. Убедиться самому в том, что MSVS круче я не смогу, потому что это тоже неправда. Мне искренне и до боли жаль тех людей, которые уже много лет пытаются друг друга убедить в крутизне любимых средств разработки, потому что их бесполезный спор идёт в совершенно другой плоскости чем следовало бы. Вот именно сейчас мне просто впадлу перечислить Вам аналогичный список из вещей, которые есть в Delphi, и которые не снились студии. Впадлу потому, что я уже это неоднократно делал и в том числе в этой ветке. Но ещё и потому, что это бесполезно, так как я совершенно уверен, что на качество программирования влияет не средство разработки а только личные таланты программиста, а как называется его IDE — на самом деле до глубокой задницы.

Не провоцируйте меня, пожалуйста.