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

КД>Здравствуйте, VladD2, Вы писали:

VD>>А уж использовать КОМ+С++ для разработки каких-ниьбудь копоративных решений — это вообще очень и очень странно.

КД>Ты уж добавлял бы — для новых корпоративных проектов.

Само собой разумеется. О каком дотнете можно было говорить, например, в 1998 году?

КД>Для старых — мне кажется, это вполне нормально. Ну не на Delphi+COM из же писать.

А вот тут бы я поспорил. С++ + ATL, конечно, позволяют получить больший контроль над компонетом, но для прикладных решений это не обязательно. В то же время Дельфи в последних версиях получил отличную поддержку КОМ-а. Так что писать КОМ-приложения на Дельфи намноно проще и быстрее.

КД> Уж на что у меня с дисциплиной кодирования хорошо, но я точно знаю — c Delphi рано или поздно пришла бы смерть в виде нескончаемых AV.

А где связь между дисциплиной, Дельфи и AV?

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

K>Жаль, вот просто придется с этим работать Хотя для общего развития я думаю не помешает.

Для общего развития КОМ, конечно, не повредит. Более того, если знаком с КОМ-ом, то изучить дотнет намного проще. Ведь концепции компонентной разработки те же самые.

VD>>А на чем основано такое желание? Или это просто каприз?

K>Просто меня не устраивает сама филисофия GC. Мне больше близка по духу анменеджед программирование.

Думаю, это у тебя от недостатка информации. Начнем хотя бы с того, что GC и управляемый код — это не совсем одно и тоже. Например, Лисп никак не назовешь управляемой средой, но он имеет ЖЦ.

В общем, ЖЦ — это средство устранения груза ручного управления памятью. Не более, но и не менее того.

K>Но хотелось бы идти в ногу со временем, ведь никто же щас под ДОС не пишет, хотя ДОС поддерживается Виндами

Пишут, конечно. Но в основном, те кто в свое время цеплялись за него объясняя, что мол "этот Виндовс очень прожорлив и ограничивает мои возможности". Ну, и те кто вынужден создавать софт для совсем морально устаревшего железа. В общем, доли процента.

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

КД>COM — это технология для настоящих пацанов

Ох уж эти "настаящие пацаны"...

КД>Я просто хорошо понимаю тех людей которые купились на ATL.OLEDB

Поверь, мы в свое время трахались с ОЛЕ ДБ намного глубже. И никаких светлых чувств к этому извращению не испытваем. Хотя я об этом уже сто раз говорил.

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

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

C>>В текущей бэте Vista никакого .NETа по умолчанию вообще нет

AVK>5231 — вшит .NET фреймворк версии 2.0.50727.27. Кроме того, что я успел заметить — на управляемом коде написан снапин EventViewer, Migration Table Editor, какая то утилита управления криптованием сетей, всем известный Narrator, снапин для управления сервисом at (scheduled tasks начиная с ХР), какой то апдейтер драйверов, снапин управления групповой политикой, снапин для управления TPM и куча каких то библиотек.

В общем некие частные сервис утилиты не критичные ко времени исполнения.
И не "вшит" а поставляется а то что будет если какая-то беда попросит 2.1?

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

VD>Само собой разумеется. О каком дотнете можно было говорить, например, в 1998 году?

Да и в 2001 году — тоже. Естественно, речь идет о создании кода, а не экспериментировании с ним.

КД>>Для старых — мне кажется, это вполне нормально. Ну не на Delphi+COM из же писать.

VD>А вот тут бы я поспорил. С++ + ATL, конечно, позволяют получить больший контроль над компонетом, но для прикладных решений это не обязательно. В то же время Дельфи в последних версиях получил отличную поддержку КОМ-а. Так что писать КОМ-приложения на Дельфи намноно проще и быстрее.

Я плохо представляю себе в чем выражается эта отличная поддержка КОМ-а, поэтому спорить не буду. В моем понимании, эта поддержка ничем не отличается от нормальной поддержки управления ресурсами. А здесь, делая выбор между C++ и паскалем, лично для меня плюсы — неоспаримый фаворит.

Да вообще фигня все это. Кто на чем хочет, тот на том и пишет. Однозначно существуют плюсо-писатели, чей "гениальный" код повергнет в шок профессионала на Delphi.

КД>> Уж на что у меня с дисциплиной кодирования хорошо, но я точно знаю — c Delphi рано или поздно пришла бы смерть в виде нескончаемых AV.

VD>А где связь между дисциплиной, Дельфи и AV?

Она в моей голове

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

КД>>Я просто хорошо понимаю тех людей которые купились на ATL.OLEDB

VD>Поверь, мы в свое время трахались с ОЛЕ ДБ намного глубже. И никаких светлых чувств к этому извращению не испытваем. Хотя я об этом уже сто раз говорил.

Мне сложно представлить на сколько глубже можно, чем это делал я — написать сам провайдер (сделано, считай три полных итерации) и написать клиентскую библиотеку на C++. Не говоря о море прикладного компонентного кода который работает с базой данных через все это. И поняв, идеологию всей этой вертикали, сказать — что все это натуральная порнография.

А так, я после последней нашей с тобой беседы стал внимательно относиться к другим спецификациям. Блин, по-моему — OLEDB ни чем не хуже остальных технологий. Просто на волне всеобщего воодушевления (которое намного опередило уровень текущего мышления) начавшейся в конце 90x, почему то очень многие решили, что это им по зубам. По ним же и получили Это относится не только к OLEDB-провайдерам, но и к очень большому количеству других направлений.

Короче говоря, в основе многих проблем лежит недооценка сложности поставленной задачи и переоценка своих способностей

Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Короче говоря, в основе многих проблем лежит недооценка сложности поставленной задачи и переоценка своих способностей

Тут еще вопрос, кто виноват в этой недооценке. Вот, к примеру, для прикручивания своего провайдера данных к MS SQL Reporting Services достаточно нескольких часов. Потому, что интерфейс так продуман. Там просто не введено никаких сложностей. Там нечего недооценивать.

Нет, я понимаю, что OLE DB скорее всего умеет намного больше, чем просто отдавать данные по запросу. Но тем не менее, пропасть слишком велика.

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

CS>В общем некие частные сервис утилиты не критичные ко времени исполнения.

Говорить пока о конкретике рано, в Vista еще много чего не перетащили из наработок. Я просто продемонстрировал, что те ранние билды еще очень далеки от того что в итоге будет.
Что же касается теперешнего консерватизма, то я бы не стал этому радоваться. Технарь Олчин уходит в отставку, а на его место пришел на редкость мутный маркетоид. Так что еще не известно что мы вобще в итоге получим.

CS>И не "вшит" а поставляется а то что будет если какая-то беда попросит 2.1?

Пока что попытка поставить более свежий фреймворк (у релизного последняя цифра 47, у RC 37) инсталлятор говорит, что мол в ОС фреймворк уже встроен и ничего ставить нельзя. Это связано с хитрой штукой — managed вариантом WinSxS. Дело в том что МС гарантирует, что рантайм 2.0 на 100% совместим сверху вниз со всеми предыдущими, поэтому старых рантаймов и возможности их поставить в Висте нет. Зато есть полный комплект всех старых библиотек.
Что касается 2.1, то, если такой появится, то либо он будет ставится без проблем параллельно, либо будет специальный вариант дистрибутива для Висты, замещающий существующий..

AndrewVK wrote:

> C>В текущей бэте Vista никакого .NETа по умолчанию вообще нет
> 5231 — вшит .NET фреймворк версии 2.0.50727.27.

Я имел в виду, что по умолчанию после загрузки нет ни одного процесса с
загруженным .NET

> Кроме того, что я успел заметить — на управляемом коде написан снапин
> EventViewer, Migration Table Editor, какая то утилита управления
> криптованием сетей, всем известный Narrator, снапин для управления
> сервисом at (scheduled tasks начиная с ХР), какой то апдейтер
> драйверов, снапин управления групповой политикой, снапин для
> управления TPM и куча каких то библиотек.

То есть мелочи, на самом-то деле.

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 wrote:

> А вот тут бы я поспорил. С++ + ATL, конечно, позволяют получить
> больший контроль над компонетом, но для прикладных решений это не
> обязательно. В то же время Дельфи в последних версиях получил отличную
> поддержку КОМ-а. Так что писать КОМ-приложения на Дельфи намноно проще
> и быстрее.

COM-клиентов — может быть. Но COM-сервера на Дельфи получались очень
нестабильными и постоянно падали.

У моего знакомого был анекдотичный случай — у него у жены на компе
стояла местная поделка для бухгалтерии на Дельфи, сделанная в виде
клиент-серверной архитектуры. После ее установки через некоторое время
заметили странности — Photoshop стал падать во время длинных операций.
Естественно, сразу стали проверять железо — поменяли блок питания,
память. Все равно все глючило.

Оказалось, что крутая бухгалтерская программа поставила специальный
сервис, который следил за процессами, чтобы они не отъедали слишком
много памяти или процессорного времени. В случае нарушения процесс
безжалостно прибивался. Сделано это было из-за того, что иногда
дельфовый сервер без всяких видимых причин уходил в кому.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Оказалось, что крутая бухгалтерская программа поставила специальный
C>сервис, который следил за процессами, чтобы они не отъедали слишком
C>много памяти или процессорного времени.

Это про таких говорят "кульные хацкеры" ?

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

C>Естественно, сразу стали проверять железо — поменяли блок питания,
C>память. Все равно все глючило.

C>Оказалось, что крутая бухгалтерская программа поставила специальный
C>сервис, который следил за процессами, чтобы они не отъедали слишком
C>много памяти или процессорного времени. В случае нарушения процесс
C>безжалостно прибивался. Сделано это было из-за того, что иногда
C>дельфовый сервер без всяких видимых причин уходил в кому.

О! Это 5. Натурально.

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

S>Тут еще вопрос, кто виноват в этой недооценке. Вот, к примеру, для прикручивания своего провайдера данных к MS SQL Reporting Services достаточно нескольких часов. Потому, что интерфейс так продуман. Там просто не введено никаких сложностей. Там нечего недооценивать.
S>Нет, я понимаю, что OLE DB скорее всего умеет намного больше, чем просто отдавать данные по запросу. Но тем не менее, пропасть слишком велика.
Проблема в том, что OleDB (как клиент так и провайдер) — это только набор интерфейсов которые нужно реализовать. Что касается провайдера к MS SQL Reporting Services — то это расширение существующего механизма. Здесь многое делается за тебя.

С уважением, Gleb.

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

C>COM-клиентов — может быть. Но COM-сервера на Дельфи получались очень
C>нестабильными и постоянно падали.

Это голословные утверждения.

C>У моего знакомого был анекдотичный случай — у него у жены на компе
C>стояла местная поделка для бухгалтерии на Дельфи, сделанная в виде
C>клиент-серверной архитектуры. После ее установки через некоторое время
C>заметили странности — Photoshop стал падать во время длинных операций.
C>Естественно, сразу стали проверять железо — поменяли блок питания,
C>память. Все равно все глючило.

C>Оказалось, что крутая бухгалтерская программа поставила специальный
C>сервис, который следил за процессами, чтобы они не отъедали слишком
C>много памяти или процессорного времени. В случае нарушения процесс
C>безжалостно прибивался. Сделано это было из-за того, что иногда
C>дельфовый сервер без всяких видимых причин уходил в кому.

А это пример кривых рук. Такое можно на чем угодно сделать.

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

КД>Я плохо представляю себе в чем выражается эта отличная поддержка КОМ-а, поэтому спорить не буду.

Интерефейсы реализованы на уровне языка. Подсчет ссылок автоматизирован. Синтаксис резко упращен.

КД> В моем понимании, эта поддержка ничем не отличается от нормальной поддержки управления ресурсами. А здесь, делая выбор между C++ и паскалем, лично для меня плюсы — неоспаримый фаворит.

Еще раз повторюсь. С++ дает больший контроль. Дельфи простоту разработки сравнимую с VB6.

КД>Да вообще фигня все это. Кто на чем хочет, тот на том и пишет.

В общем, да. Но это если говорить о том, на чем можно делать КОМ. Если же отойти от КОМ-а, и задуматься над тем на чем лучше делать компоненты для прикладной системы, то я бы однозначно выбрал дотнет. КОМ тут ни в какое сравнение не идет. Достаточно сравнить возможности и ту простоту с которой они доступны. Например, сравни TypeInfo COM-а и Reflection.

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

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

C>>COM-клиентов — может быть. Но COM-сервера на Дельфи получались очень
C>>нестабильными и постоянно падали.

VD>Это голословные утверждения.
Вынужден констатировать что это правда. При сложной TLB все не так радостно. До VB там еще как до Марса. Были также в одной из версий глюки с вариантом.

VD>А это пример кривых рук. Такое можно на чем угодно сделать.
Ага. У нас есть сервис который отслеживает жизнеспособность и перегружает другой сервис. А зависы из-за глючности outlook.

С уважением, Gleb.
ЗЫ. Стоит вспомнить про программиста Васю.http://www.rsdn.ru/article/mag/humour0302.xml

Автор(ы):

VladD2 wrote:

> C>COM-клиентов — может быть. Но COM-сервера на Дельфи получались очень
> C>нестабильными и постоянно падали.
> Это голословные утверждения.

К сожалению, это выстраданая многими программистами истина

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

КД>>Да вообще фигня все это. Кто на чем хочет, тот на том и пишет.

VD>Если же отойти от КОМ-а, и задуматься над тем на чем лучше делать компоненты для прикладной системы, то я бы однозначно выбрал дотнет. КОМ тут ни в какое сравнение не идет. Достаточно сравнить возможности и ту простоту с которой они доступны. Например, сравни TypeInfo COM-а и Reflection.

Влад, я хорошо себе представляю основные преимущества дотнета.

Но, к сожалению, когда делался выбор — его не было как такового. Тогда много чего не было. Пришлось писать самостоятельно

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

КД>Но, к сожалению, когда делался выбор — его не было как такового. Тогда много чего не было. Пришлось писать самостоятельно

Про выбор в прошлом вроде как других мнений быть и не может. Но сейчас ведь речь идет о выборе в настоящее время.

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

GZ>Вынужден констатировать что это правда. При сложной TLB все не так радостно. До VB там еще как до Марса. Были также в одной из версий глюки с вариантом.

Это не менее голословные утверждения. Хорошо бы привести какие-нибудь факты. Что до ВБ (6), то мы на нем ого-го сколько кода отгрохали и проблем с варинтами не встречали.

VD>>А это пример кривых рук. Такое можно на чем угодно сделать.
GZ>Ага. У нас есть сервис который отслеживает жизнеспособность и перегружает другой сервис. А зависы из-за глючности outlook.

У меня с Аутлуком проблем нет. Ну, да даже если они есть, то разумно перегружать конкретное прилоежние, а не все подряд, как это было сказано. А еще разумнее выявить и устранить проблему. Если четко доказно, что дело в Аутлуке, то заменить его на что-то другое.