Здравствуйте, Cyberax, Вы писали:
>> C>COM-клиентов — может быть. Но COM-сервера на Дельфи получались очень >> C>нестабильными и постоянно падали. >> Это голословные утверждения.
C>К сожалению, это выстраданая многими программистами истина
Так как есть программисты не страдающие от этого, то резонно предположить, что у этих многих просто не хватало опыта.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В МСДН есть только механизм фильтрации. Если ты при инсталляции студии выбирашь, например, C# Developer, то по-умолчанию включается фльтр по околодотнетным разделам. Вможно именно так обстоят дела в твоем случае.
Жалко, что механизм фильтрации, встроенный в MS Help 2.xx польностью доступен только через API. Например, часто хочется наоборот — исключить некие подразделы из поиска. Это можно сделать обратным методом — задать фильтр как множество разделов, но через GUI dexplore.exe такая фича недоступна.
Здравствуйте, VladD2, Вы писали:
КД>>Я плохо представляю себе в чем выражается эта отличная поддержка КОМ-а, поэтому спорить не буду.
VD>Интерефейсы реализованы на уровне языка. Подсчет ссылок автоматизирован. Синтаксис резко упращен.
Поучаствовал я как-то в качестве консультанта в одном из проктов на Дельфи. Дело в том, что обрабатывались в памяти очень большие объемы данных, использовалась дельфийская обертка над ADO. Быстродействие — ни к черту. К счастью, эти обертки делают так же доступными "нативные" интерфейсы (которые программисты на Дельфи почти никогда не используют). В общем, скорость выросла в разы, правда пришлось вручную следить за COM-ресурсами, где-то недослеживали, слишком много разных обеъктов... в итоге вычислительную часть я им переписал на С++ и открыл DLL-экспорт для основной программы на Дельфи. Все остались довольны.
Здравствуйте, GlebZ, Вы писали: GZ>Проблема в том, что OleDB (как клиент так и провайдер) — это только набор интерфейсов которые нужно реализовать. Что касается провайдера к MS SQL Reporting Services — то это расширение существующего механизма. Здесь многое делается за тебя.
Ну, мне как раз показалось, что там тоже ровно набор интерфейсов, которые ты обязан реализовать. Просто устроены они так удачно, что реализуются легко.
Для сравнения: в рендеринг екстеншн (для тех же SSRS) ровно один интерфейс с тремя методами. Независимых реализаций неизвестно.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Kisloid, Вы писали:
K>Вот собственно сабж, кто что думает по этому поводу... Ведь появился .NET (COM 2), а лично я к примеру считаю, что .NET в основном пригоден для веб-сервисов, веб-служб. Вот если например я пишу анменеджед код и не хочу менеджед код писать, то думаю мне прямая дорога в COM. Но меня терзают сомнения, что это устаревает и вроде даже в след версиях виндов (Виста например) МС не собираются поддерживать анменеджед код (Вин Апи) и все такое...
Вообще сейчас есть серьезный аргумент в пользу .net, это 64-битные процессоры или точнее 64-битный Windows, в котором win32api является оберткой и, как следствие, медленно работает, так что надо поддерживать две версии 32-битную и 64-битную.
С другой стороны как писать на .net кроссплатформенный код непонятно
Здравствуйте, Рома Мик, Вы писали:
РМ>Вообще сейчас есть серьезный аргумент в пользу .net, это 64-битные процессоры или точнее 64-битный Windows, в котором win32api является оберткой и, как следствие, медленно работает, так что надо поддерживать две версии 32-битную и 64-битную.
+1
РМ>С другой стороны как писать на .net кроссплатформенный код непонятно
Кроссплатформенный между 32-битной платформой и 64-битной платформой
Где-то, в какам-то из интервью на Channel 9 ребята из МС говорили, что под кроссплатформенностью они имеют ввиду независимость от железа.
Здравствуйте, xbit, Вы писали:
РМ>>С другой стороны как писать на .net кроссплатформенный код непонятно X>Кроссплатформенный между 32-битной платформой и 64-битной платформой
Это-то выходит само собой. Кстати и без .net, больших проблем нет, про два разных экзешника в рамках одной платформы (windows) не очень-то здорово. А вот портировать написанное под .net приложение на мак непонятно как.
РМ>64-битный Windows, в котором win32api является оберткой
Не совсем верно. РМ> и, как следствие, медленно работает.
Не факт. 64битная ахитектура пока хромает.
Здравствуйте, vdimas, Вы писали:
V>Поучаствовал я как-то в качестве консультанта в одном из проктов на Дельфи. Дело в том, что обрабатывались в памяти очень большие объемы данных, использовалась дельфийская обертка над ADO. Быстродействие — ни к черту. К счастью, эти обертки делают так же доступными "нативные" интерфейсы (которые программисты на Дельфи почти никогда не используют). В общем, скорость выросла в разы, правда пришлось вручную следить за COM-ресурсами, где-то недослеживали, слишком много разных обеъктов... в итоге вычислительную часть я им переписал на С++ и открыл DLL-экспорт для основной программы на Дельфи. Все остались довольны.
Это говорит только о том, что С++ ты знашь намного лучше чем Дельфи.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: V>>Поучаствовал я как-то в качестве консультанта в одном из проктов на Дельфи. Дело в том, что обрабатывались в памяти очень большие объемы данных, использовалась дельфийская обертка над ADO. Быстродействие — ни к черту.
VD>Это говорит только о том, что С++ ты знашь намного лучше чем Дельфи.
ADOExpress действительно выглядит и работает как недоделанная вещь
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Рома Мик, Вы писали:
РМ>Вообще сейчас есть серьезный аргумент в пользу .net, это 64-битные процессоры или точнее 64-битный Windows, в котором win32api является оберткой и, как следствие, медленно работает, так что надо поддерживать две версии 32-битную и 64-битную.
Как раз по этому поводу я бы не беспокоился. На NT все A функции это обёртки на W функциями, но пока никто не замечал диких тормозов ANSI приложений. Кроме того 64битные процессоры имеют совсем другие скорости, так что по-любому выйдет быстрее.
1.1.4 stable rev. 510
