Вот собственно сабж, кто что думает по этому поводу... Ведь появился .NET (COM 2), а лично я к примеру считаю, что .NET в основном пригоден для веб-сервисов, веб-служб. Вот если например я пишу анменеджед код и не хочу менеджед код писать, то думаю мне прямая дорога в COM. Но меня терзают сомнения, что это устаревает и вроде даже в след версиях виндов (Виста например) МС не собираются поддерживать анменеджед код (Вин Апи) и все такое...
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Kisloid wrote: > > Вот собственно сабж, кто что думает по этому поводу... Ведь появился > .NET (COM 2), а лично я к примеру считаю, что .NET в основном пригоден > для веб-сервисов, веб-служб. Вот если например я пишу анменеджед код и > не хочу менеджед код писать, то думаю мне прямая дорога в COM. Но меня > терзают сомнения, что это устаревает и вроде даже в след версиях виндов > (Виста например) МС не собираются поддерживать анменеджед код (Вин Апи) > и все такое...
Разумеется, они будут поддерживать совместимость еще сто лет. Они же не
психи полные
Их метод переводить население на новые технологии заключается в том, что
когда ищешь в MSDN'е ответ на вопрос, как сделать то-то, то получаешь
ответ, как правило, в терминах новомодных технологий, без отсылки к
старым (при этом статьи про старые технологии никуда не деваются, но
надо знать, по каким словам их искать). Тем самым, наивные программеры,
которым избыток кругозора не свойственен, переходят на новые технологии
автоматически.
Здравствуйте, Kisloid, Вы писали:
K>Вот собственно сабж, кто что думает по этому поводу...
Про COM не скажу, а вот работу на COBOL'е
все еще можно найти. Не в России правда, хотя кто его знает.
А ведь этот самый COBOL, если верить гуглу,
был придуман аж в 1959, когда моей маме только 10 лет было
Здравствуйте, Kisloid, Вы писали:
K>Вот собственно сабж, кто что думает по этому поводу... Ведь появился .NET (COM 2), а лично я к примеру считаю, что .NET в основном пригоден для веб-сервисов, веб-служб.
Это потому что ты не писал на managed. Ты так рассуждаешь по тому что не понимаешь что такое managed. И это не замена COM. Его основной конкурент — unmanaged языки в целом. K>Вот если например я пишу анменеджед код и не хочу менеджед код писать, то думаю мне прямая дорога в COM.
Брось эти мысли. Пиши так как тебе удобно. COM — технология очень плохая и имеющая только один плюс — она стандартизована. Ее применять хорошо только там, где она нужна. K>Но меня терзают сомнения, что это устаревает и вроде даже в след версиях виндов (Виста например) МС не собираются поддерживать анменеджед код (Вин Апи) и все такое...
Будет поддерживать.
Здравствуйте, GlebZ, Вы писали:
GZ>Это потому что ты не писал на managed. Ты так рассуждаешь по тому что не понимаешь что такое managed. И это не замена COM. Его основной конкурент — unmanaged языки в целом.
Писал, около года, хотя может плохо писал Вот никак не могу понять, как манаджед код может вытеснить анменеджед, по мне так лучше и удобнее пользоваться обычным хипом чем управяемым. Хотя конечно понимаю, что GC супер умная вещь которая дефрагментирует память и все такое, а в С++ при работе с большими объемами как мне известно как раз и начинаются проблемы из за фрагментации памяти.
GZ>Брось эти мысли. Пиши так как тебе удобно. COM — технология очень плохая и имеющая только один плюс — она стандартизована. Ее применять хорошо только там, где она нужна.
А чем она так плоха? Я пока что знаю тока один минус, то что она очень сложная
GZ>Будет поддерживать.
Угу, как в Винде ДОС. но тока ведь никто под ДОС не пишет.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Kisloid wrote:
> Вот собственно сабж, кто что думает по этому поводу... Ведь появился > .NET (COM 2), а лично я к примеру считаю, что .NET в основном пригоден > для веб-сервисов, веб-служб. Вот если например я пишу анменеджед код и > не хочу менеджед код писать, то думаю мне прямая дорога в COM. Но меня > терзают сомнения, что это устаревает и вроде даже в след версиях > виндов (Виста например) МС не собираются поддерживать анменеджед код > (Вин Апи) и все такое...
В текущей бэте Vista никакого .NETа по умолчанию вообще нет — все на
COMе. Так что он "живее всех живых"...
Здравствуйте, Cyberax, Вы писали:
C>В текущей бэте Vista никакого .NETа по умолчанию вообще нет — все на C>COMе. Так что он "живее всех живых"...
Йессссс!!! Я так и знал
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Kisloid, Вы писали:
GZ>>Это потому что ты не писал на managed. Ты так рассуждаешь по тому что не понимаешь что такое managed. И это не замена COM. Его основной конкурент — unmanaged языки в целом. K>Писал, около года, хотя может плохо писал Вот никак не могу понять, как манаджед код может вытеснить анменеджед, по мне так лучше и удобнее пользоваться обычным хипом чем управяемым. Хотя конечно понимаю, что GC супер умная вещь которая дефрагментирует память и все такое, а в С++ при работе с большими объемами как мне известно как раз и начинаются проблемы из за фрагментации памяти.
Китайскую сказку про золотого льва помнишь? Ты сам начал сравнивать с COM. Начиная c компонентности, managed или ему подобные, значительно лучше. Притом я беру в рассчет сравнение не только с С++.
GZ>>Брось эти мысли. Пиши так как тебе удобно. COM — технология очень плохая и имеющая только один плюс — она стандартизована. Ее применять хорошо только там, где она нужна. K>А чем она так плоха? Я пока что знаю тока один минус, то что она очень сложная
Нуу, минусов значительно больше. Намного это еще мягко сказано. Начиная от цикличных ссылок, оканчивая адом при сопровождении из-за чудовищной регистрации. А мысль о том, что ты вместо интерфейса можешь получить шиш(борьбу с Ole DB провайдерами я никогда в жизни не забуду ) вообще убивает.
GZ>>Будет поддерживать. K>Угу, как в Винде ДОС. но тока ведь никто под ДОС не пишет.
В managed тоже не все пока спокойно. Покамест компиляторы JIT отстают по возможностям оптимизации от компиляторов unmanaged.
Несомненно!
K>Вот собственно сабж, кто что думает по этому поводу... Ведь появился .NET (COM 2), а лично я к примеру считаю, что .NET в основном пригоден для веб-сервисов, веб-служб.
Значит тебе нужно перестать читать пресрелизы и смотреть рекламу. Они на тебя плохо влияют.
K> Вот если например я пишу анменеджед код и не хочу менеджед код писать,
А на чем основано такое желание? Или это просто каприз?
K> Но меня терзают сомнения, что это устаревает и вроде даже в след версиях виндов (Виста например) МС не собираются поддерживать анменеджед код (Вин Апи) и все такое...
Это полная ерунда. Конечно КОМ, как и ВыньАПИ никуда не денутся. Если тебе хочется использовать их, то ты сможешь их использовать еще лет 10-15.
Так почему же .NET? Да, все очень просто. Дотнет — это КОМ на стеройдах. Бесшовный, удобный, быстрый и надежный. Создание компонентов с помощью КОМ, да еще и на С++ это форменный мазахизм. И лично я бы начал этим заниматься, только при наличии очень серьезных проектных требований. А уж использовать КОМ+С++ для разработки каких-ниьбудь копоративных решений — это вообще очень и очень странно.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Pzz>Их метод переводить население на новые технологии заключается в том, что Pzz>когда ищешь в MSDN'е ответ на вопрос, как сделать то-то, то получаешь Pzz>ответ, как правило, в терминах новомодных технологий, без отсылки к Pzz>старым (при этом статьи про старые технологии никуда не деваются, но Pzz>надо знать, по каким словам их искать). Тем самым, наивные программеры, Pzz>которым избыток кругозора не свойственен, переходят на новые технологии Pzz>автоматически.
Ты серьезно считашь, что в МС занимаются подтасовками результатов поиска?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Это потому что ты не писал на managed. Ты так рассуждаешь по тому что не понимаешь что такое managed. И это не замена COM. Его основной конкурент — unmanaged языки в целом.
Нет, все же это и замена КОМ-у. Причем изумительная замена. Дотнет и компонентный подход почти синонимы.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
GZ>>Это потому что ты не писал на managed. Ты так рассуждаешь по тому что не понимаешь что такое managed. И это не замена COM. Его основной конкурент — unmanaged языки в целом.
VD>Нет, все же это и замена КОМ-у. Причем изумительная замена. Дотнет и компонентный подход почти синонимы.
В том числе. Я и не возражал.
Здравствуйте, GlebZ, я увидел знакомые слова:
GZ>А мысль о том, что ты вместо интерфейса можешь получить шиш(борьбу с Ole DB провайдерами я никогда в жизни не забуду ) вообще убивает.
А я вот как-то работаю с одним и почему-то не парюсь
COM — это технология для настоящих пацанов
Сегодня как раз затеял новый проект с компонентами в качестве дополнения к WSH
---
Просьба не принимать мои слова близко к сердцу
Я просто хорошо понимаю тех людей которые купились на ATL.OLEDB
To GlebZ: ведь так?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, VladD2, Вы писали:
VD>А уж использовать КОМ+С++ для разработки каких-ниьбудь копоративных решений — это вообще очень и очень странно.
Ты уж добавлял бы — для новых корпоративных проектов.
Для старых — мне кажется, это вполне нормально. Ну не на Delphi+COM из же писать. Уж на что у меня с дисциплиной кодирования хорошо, но я точно знаю — c Delphi рано или поздно пришла бы смерть в виде нескончаемых AV.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Я просто хорошо понимаю тех людей которые купились на ATL.OLEDB КД>To GlebZ: ведь так?
Нет, не так.
OleDB (а я с ним работал как при ATL так и до оного) позволяет максимально стандартизованно построить собственный источник данных. Именно этим свойством я пользовался. К тому же он меньше не тормозил как ADO. Ну а потом, нужно всегда выбирать среди аналогичных, интерфейс который хорошо знаешь. По сравнению с остальными, я знал его хорошо.
VladD2 wrote: > > Pzz>Их метод переводить население на новые технологии заключается в том, что > Pzz>когда ищешь в MSDN'е ответ на вопрос, как сделать то-то, то получаешь > Pzz>ответ, как правило, в терминах новомодных технологий, без отсылки к > Pzz>старым (при этом статьи про старые технологии никуда не деваются, но > Pzz>надо знать, по каким словам их искать). Тем самым, наивные программеры, > Pzz>которым избыток кругозора не свойственен, переходят на новые технологии > Pzz>автоматически. > > Ты серьезно считашь, что в МС занимаются подтасовками результатов поиска?
Подтасовками — нет. Но информация организована таким образом, чтобы
наивный поиск куда-то вел (что можно даже назвать заботой о
пользователях). И ведет он по тому пути, который МС считает правильным.
А правильным они считают использование новых технологий, как только они
становятся доступными.
Здравствуйте, GlebZ, Вы писали:
КД>>Я просто хорошо понимаю тех людей которые купились на ATL.OLEDB КД>>To GlebZ: ведь так? GZ>Нет, не так. GZ>OleDB (а я с ним работал как при ATL так и до оного) позволяет максимально стандартизованно построить собственный источник данных. Именно этим свойством я пользовался.
Хм, а я подумал что речь шла о создании клиента к провайдерам. Построение клиентов к БД — это тоже моя любимая тема
Ну а проблемы с реализацией провайдеров они скорее всего относятся к начальной недооценке сложности, нет, не самой технологии, а всей инфрастуктуры (о какое слово замочил!) этого набора компонент. И я тоже не был исключением из этого правила
Смешно, но мой провайдер больше exe-шника самого FB-сервера Хотя, возможно, здесь проблема в используемом компиляторе.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, VladD2, Вы писали:
K>>COM устарел ?
VD>Несомненно!
Жаль, вот просто придется с этим работать Хотя для общего развития я думаю не помешает.
VD>Значит тебе нужно перестать читать пресрелизы и смотреть рекламу. Они на тебя плохо влияют.
Так и знал...
VD>А на чем основано такое желание? Или это просто каприз?
Просто меня не устраивает сама филисофия GC. Мне больше близка по духу анменеджед программирование.
VD>Это полная ерунда. Конечно КОМ, как и ВыньАПИ никуда не денутся. Если тебе хочется использовать их, то ты сможешь их использовать еще лет 10-15.
Но хотелось бы идти в ногу со временем, ведь никто же щас под ДОС не пишет, хотя ДОС поддерживается Виндами
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Cyberax, Вы писали:
C>В текущей бэте Vista никакого .NETа по умолчанию вообще нет
5231 — вшит .NET фреймворк версии 2.0.50727.27. Кроме того, что я успел заметить — на управляемом коде написан снапин EventViewer, Migration Table Editor, какая то утилита управления криптованием сетей, всем известный Narrator, снапин для управления сервисом at (scheduled tasks начиная с ХР), какой то апдейтер драйверов, снапин управления групповой политикой, снапин для управления TPM и куча каких то библиотек.
... << RSDN@Home 1.2.0 alpha rev. 620 on Windows XP 5.1.2600.131072>>
Здравствуйте, Pzz, Вы писали:
Pzz>Подтасовками — нет. Но информация организована таким образом, чтобы Pzz>наивный поиск куда-то вел (что можно даже назвать заботой о Pzz>пользователях).
Не выдумывай.
Pzz> И ведет он по тому пути, который МС считает правильным.
И как ты себе это представляешь?
Pzz>А правильным они считают использование новых технологий, как только они Pzz>становятся доступными.
Еще раз. Не выдумывай. Ни кто специально тебе ничего не подсовывает. Возможно то что ты чаще наталкивашся на помощь для дотнета связано с тем, что в нем намного больше уделяется внимания выбору названий и структурированию информации. В остальном же разделы дотнета ничем от остальных не отличаются.
В МСДН есть только механизм фильтрации. Если ты при инсталляции студии выбирашь, например, C# Developer, то по-умолчанию включается фльтр по околодотнетным разделам. Вможно именно так обстоят дела в твоем случае.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, VladD2, Вы писали:
VD>>А уж использовать КОМ+С++ для разработки каких-ниьбудь копоративных решений — это вообще очень и очень странно.
КД>Ты уж добавлял бы — для новых корпоративных проектов.
Само собой разумеется. О каком дотнете можно было говорить, например, в 1998 году?
КД>Для старых — мне кажется, это вполне нормально. Ну не на Delphi+COM из же писать.
А вот тут бы я поспорил. С++ + ATL, конечно, позволяют получить больший контроль над компонетом, но для прикладных решений это не обязательно. В то же время Дельфи в последних версиях получил отличную поддержку КОМ-а. Так что писать КОМ-приложения на Дельфи намноно проще и быстрее.
КД> Уж на что у меня с дисциплиной кодирования хорошо, но я точно знаю — c Delphi рано или поздно пришла бы смерть в виде нескончаемых AV.
А где связь между дисциплиной, Дельфи и AV?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kisloid, Вы писали:
K>Жаль, вот просто придется с этим работать Хотя для общего развития я думаю не помешает.
Для общего развития КОМ, конечно, не повредит. Более того, если знаком с КОМ-ом, то изучить дотнет намного проще. Ведь концепции компонентной разработки те же самые.
VD>>А на чем основано такое желание? Или это просто каприз?
K>Просто меня не устраивает сама филисофия GC. Мне больше близка по духу анменеджед программирование.
Думаю, это у тебя от недостатка информации. Начнем хотя бы с того, что GC и управляемый код — это не совсем одно и тоже. Например, Лисп никак не назовешь управляемой средой, но он имеет ЖЦ.
В общем, ЖЦ — это средство устранения груза ручного управления памятью. Не более, но и не менее того.
K>Но хотелось бы идти в ногу со временем, ведь никто же щас под ДОС не пишет, хотя ДОС поддерживается Виндами
Пишут, конечно. Но в основном, те кто в свое время цеплялись за него объясняя, что мол "этот Виндовс очень прожорлив и ограничивает мои возможности". Ну, и те кто вынужден создавать софт для совсем морально устаревшего железа. В общем, доли процента.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>COM — это технология для настоящих пацанов
Ох уж эти "настаящие пацаны"...
КД>Я просто хорошо понимаю тех людей которые купились на ATL.OLEDB
Поверь, мы в свое время трахались с ОЛЕ ДБ намного глубже. И никаких светлых чувств к этому извращению не испытваем. Хотя я об этом уже сто раз говорил.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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 скорее всего умеет намного больше, чем просто отдавать данные по запросу. Но тем не менее, пропасть слишком велика.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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 и куча каких то библиотек.
VladD2 wrote:
> А вот тут бы я поспорил. С++ + ATL, конечно, позволяют получить > больший контроль над компонетом, но для прикладных решений это не > обязательно. В то же время Дельфи в последних версиях получил отличную > поддержку КОМ-а. Так что писать КОМ-приложения на Дельфи намноно проще > и быстрее.
COM-клиентов — может быть. Но COM-сервера на Дельфи получались очень
нестабильными и постоянно падали.
У моего знакомого был анекдотичный случай — у него у жены на компе
стояла местная поделка для бухгалтерии на Дельфи, сделанная в виде
клиент-серверной архитектуры. После ее установки через некоторое время
заметили странности — Photoshop стал падать во время длинных операций.
Естественно, сразу стали проверять железо — поменяли блок питания,
память. Все равно все глючило.
Оказалось, что крутая бухгалтерская программа поставила специальный
сервис, который следил за процессами, чтобы они не отъедали слишком
много памяти или процессорного времени. В случае нарушения процесс
безжалостно прибивался. Сделано это было из-за того, что иногда
дельфовый сервер без всяких видимых причин уходил в кому.
Здравствуйте, Cyberax, Вы писали:
C>Оказалось, что крутая бухгалтерская программа поставила специальный C>сервис, который следил за процессами, чтобы они не отъедали слишком C>много памяти или процессорного времени.
Это про таких говорят "кульные хацкеры" ?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Cyberax, Вы писали:
C>Естественно, сразу стали проверять железо — поменяли блок питания, C>память. Все равно все глючило.
C>Оказалось, что крутая бухгалтерская программа поставила специальный C>сервис, который следил за процессами, чтобы они не отъедали слишком C>много памяти или процессорного времени. В случае нарушения процесс C>безжалостно прибивался. Сделано это было из-за того, что иногда C>дельфовый сервер без всяких видимых причин уходил в кому.
Здравствуйте, Sinclair, Вы писали:
S>Тут еще вопрос, кто виноват в этой недооценке. Вот, к примеру, для прикручивания своего провайдера данных к MS SQL Reporting Services достаточно нескольких часов. Потому, что интерфейс так продуман. Там просто не введено никаких сложностей. Там нечего недооценивать. S>Нет, я понимаю, что OLE DB скорее всего умеет намного больше, чем просто отдавать данные по запросу. Но тем не менее, пропасть слишком велика.
Проблема в том, что OleDB (как клиент так и провайдер) — это только набор интерфейсов которые нужно реализовать. Что касается провайдера к MS SQL Reporting Services — то это расширение существующего механизма. Здесь многое делается за тебя.
Здравствуйте, Cyberax, Вы писали:
C>COM-клиентов — может быть. Но COM-сервера на Дельфи получались очень C>нестабильными и постоянно падали.
Это голословные утверждения.
C>У моего знакомого был анекдотичный случай — у него у жены на компе C>стояла местная поделка для бухгалтерии на Дельфи, сделанная в виде C>клиент-серверной архитектуры. После ее установки через некоторое время C>заметили странности — Photoshop стал падать во время длинных операций. C>Естественно, сразу стали проверять железо — поменяли блок питания, C>память. Все равно все глючило.
C>Оказалось, что крутая бухгалтерская программа поставила специальный C>сервис, который следил за процессами, чтобы они не отъедали слишком C>много памяти или процессорного времени. В случае нарушения процесс C>безжалостно прибивался. Сделано это было из-за того, что иногда C>дельфовый сервер без всяких видимых причин уходил в кому.
А это пример кривых рук. Такое можно на чем угодно сделать.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Я плохо представляю себе в чем выражается эта отличная поддержка КОМ-а, поэтому спорить не буду.
Интерефейсы реализованы на уровне языка. Подсчет ссылок автоматизирован. Синтаксис резко упращен.
КД> В моем понимании, эта поддержка ничем не отличается от нормальной поддержки управления ресурсами. А здесь, делая выбор между C++ и паскалем, лично для меня плюсы — неоспаримый фаворит.
Еще раз повторюсь. С++ дает больший контроль. Дельфи простоту разработки сравнимую с VB6.
КД>Да вообще фигня все это. Кто на чем хочет, тот на том и пишет.
В общем, да. Но это если говорить о том, на чем можно делать КОМ. Если же отойти от КОМ-а, и задуматься над тем на чем лучше делать компоненты для прикладной системы, то я бы однозначно выбрал дотнет. КОМ тут ни в какое сравнение не идет. Достаточно сравнить возможности и ту простоту с которой они доступны. Например, сравни TypeInfo COM-а и Reflection.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Cyberax, Вы писали:
C>>COM-клиентов — может быть. Но COM-сервера на Дельфи получались очень C>>нестабильными и постоянно падали.
VD>Это голословные утверждения.
Вынужден констатировать что это правда. При сложной TLB все не так радостно. До VB там еще как до Марса. Были также в одной из версий глюки с вариантом.
VD>А это пример кривых рук. Такое можно на чем угодно сделать.
Ага. У нас есть сервис который отслеживает жизнеспособность и перегружает другой сервис. А зависы из-за глючности outlook.
VladD2 wrote:
> C>COM-клиентов — может быть. Но COM-сервера на Дельфи получались очень > C>нестабильными и постоянно падали. > Это голословные утверждения.
К сожалению, это выстраданая многими программистами истина
Здравствуйте, VladD2, Вы писали:
КД>>Да вообще фигня все это. Кто на чем хочет, тот на том и пишет.
VD>Если же отойти от КОМ-а, и задуматься над тем на чем лучше делать компоненты для прикладной системы, то я бы однозначно выбрал дотнет. КОМ тут ни в какое сравнение не идет. Достаточно сравнить возможности и ту простоту с которой они доступны. Например, сравни TypeInfo COM-а и Reflection.
Влад, я хорошо себе представляю основные преимущества дотнета.
Но, к сожалению, когда делался выбор — его не было как такового. Тогда много чего не было. Пришлось писать самостоятельно
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Но, к сожалению, когда делался выбор — его не было как такового. Тогда много чего не было. Пришлось писать самостоятельно
Про выбор в прошлом вроде как других мнений быть и не может. Но сейчас ведь речь идет о выборе в настоящее время.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Вынужден констатировать что это правда. При сложной TLB все не так радостно. До VB там еще как до Марса. Были также в одной из версий глюки с вариантом.
Это не менее голословные утверждения. Хорошо бы привести какие-нибудь факты. Что до ВБ (6), то мы на нем ого-го сколько кода отгрохали и проблем с варинтами не встречали.
VD>>А это пример кривых рук. Такое можно на чем угодно сделать. GZ>Ага. У нас есть сервис который отслеживает жизнеспособность и перегружает другой сервис. А зависы из-за глючности outlook.
У меня с Аутлуком проблем нет. Ну, да даже если они есть, то разумно перегружать конкретное прилоежние, а не все подряд, как это было сказано. А еще разумнее выявить и устранить проблему. Если четко доказно, что дело в Аутлуке, то заменить его на что-то другое.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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битные процессоры имеют совсем другие скорости, так что по-любому выйдет быстрее.
Ты так рассуждаешь по тому что не понимаешь что такое managed. И это не замена COM. 
в виде нескончаемых AV.
Хотя для общего развития я думаю не помешает.
1.1.4 stable rev. 510
