Здравствуйте, WolfHound, Вы писали:
WH>3)Жесткое реальное время
[...]
WH>С пунктом 3 пока не все ясно но думаю что и там тоже чтонибудь придумают...
Для обработки звука, например, уже вполне всего хватает.
Я вот недавно баловался с реал-тайм эффектами для гитары на своем компе. Пробовал и на С++ и на С#. В первом случае загрузка проца 5%, во втором — 7..9%.
Здравствуйте, VladD2, Вы писали:
VD>К тому же можно объяснить, что за непреодалимые пробелмы в реализации OLE 2 на дотнете?
В 1.1 не было такого:
public static int Marshal::FinalReleaseComObject(object o);
И еще не поддерживалась агрегация в должной мере.
Поэтому, обыгрывать агрегацию и следить за использованием COM-объектов надо было вручную, что практически невозможно было адекватно сделать на C# (вспомнишь о смарт-поинтерах С++ сразу)
Сейчас же достаточно просто освободить все ссылки и принудительно вызвать полную сборку мусора — все сработает OK, ибо фреймворк взял на себя труд контоллировать ссылки на COM-объекты, и агрегированные в т.ч..
VD>И кстати, очень интересен следующий вопрос... Вот в Линукс в принципе невозможно использовать OLE 2.
Почему невозможно? В либу WINe входит его реализация.
OLE2 важен своей критической массой серверных (с т.з. технологии OLE2) полезных приложений. Очень удобно иметь возможность управлять обработкой документов в своих приложениях.
Я до сих пор не понимаю, почему MS не выпустило OLE2-библиотек клиента и сервера, а сделало это лишь частично (в виде частичной внутренней реализации) и только для своих Word и Excel?
>>> Я вот пользуюсь и Visio, и Word, а OLE 2 не ползуюсь. C>>То есть не вставляете диаграммы из Visio в Word?
VD>Да. Я сохраняю их как файлы и вставляю в Ворд уже готовые файлы. И делаю я это по сображениям надежности и удобста.
Это тоже OLE2.
VD>Кого нет? OLE 2 — это COM-спецификация! Каждый может реализовать ее.
Были трудности на 1.1
>>> И кстати, очень интересен следующий вопрос... Вот в Линукс в принципе >>> невозможно использовать OLE 2. C>>Ну во-первых, под Линукс есть по крайней мере две реализации OLE2 и DCOM
VD>OLE2? Можно ссылкочку? Они как минимум не законны.
Законны. Спецификации OLE открыты. Вот если они использовали исходники MS, то это было бы незаконно.
VD>А DCOM никакого отношения к OLE2 не имеет. И его без каких либо трудов можно использовать из C#.
vdimas wrote: > Я до сих пор не понимаю, почему MS не выпустило OLE2-библиотек клиента и > сервера, а сделало это лишь частично (в виде частичной внутренней > реализации) и только для своих Word и Excel?
То есть? Полная спека по OLE2 — в MSDN, а в MFC вполне неплохая
реализация контейнеров и клиентов.
VD>Еще рез. OLE 2 — это COM-спецификация. Нет никакой разницы на чем ее реализовывать. И она не реализована на 100% на C# только потому, что это никому не нужно. Хотел бы я поглядеть как кто-то реализует OLE 2 без MFC.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, alexeiz, Вы писали:
A>>Т.е. ты считаешь язык, в котором есть и высокоуровневые возможности и низкоуровневые, низкоуровневым?
Д>Нельзя сделать инструмент, который позволяет одинаково хорошо и гвозди забивать, и микробов разглядывать.
Меня уже достали твои общие слова. Ты отрицаешь наличие высокоуровневых возможностей в C++?
Здравствуйте, Cyberax, Вы писали:
C>vdimas wrote: >> Я до сих пор не понимаю, почему MS не выпустило OLE2-библиотек клиента и >> сервера, а сделало это лишь частично (в виде частичной внутренней >> реализации) и только для своих Word и Excel? C>То есть? Полная спека по OLE2 — в MSDN, а в MFC вполне неплохая C>реализация контейнеров и клиентов.
vdimas wrote: > C>То есть? Полная спека по OLE2 — в MSDN, а в MFC вполне неплохая > C>реализация контейнеров и клиентов. > Я говорил о либе для .Net, конечно
А, тут согласен. Хотят к 2010 году что-то новое сделать, наверное.
Клиентский OLE2, кстати, без особых проблем делается. А вот серверный....
Дарней wrote: > C>Но ведь еще не сделали? > а тебя так сильно беспокоит HP-UX? Ты хочешь об этом поговорить?
Любят некоторые заказчики его, к сожалению. А система эта еще
извращеннее Винды.
> Я уверен, что Аутлука там совершенно точно нет
Зато есть сервера
> C>Они его собираются заменить уже года три. А воз и ныне там — у них > C>слишком много заточено под консервативную сборку. > читал где-то у них в ньюсах, что это уже практически закончено
Странно, я слежу за их списком рассылки. Они тестировали GC из ORP, но
до прикручивания им еще далеко.
> C>Он простой и удобный. Для определенных целей. > Вот-вот. Главное — не пытаться доказывать, что он рулит еще и как язык > для прототипирования
Эээээ... А я это где-то говорил?
Здравствуйте, Cyberax, Вы писали:
C>vdimas wrote: >> C>То есть? Полная спека по OLE2 — в MSDN, а в MFC вполне неплохая >> C>реализация контейнеров и клиентов. >> Я говорил о либе для .Net, конечно C>А, тут согласен. Хотят к 2010 году что-то новое сделать, наверное.
C>Клиентский OLE2, кстати, без особых проблем делается. А вот серверный....
Да примерно одинаковый объем работы, ИМХО, если речь идет об библиотеке.
Здравствуйте, Дарней, Вы писали:
Д>я раньше тоже думал в точности, как ты
Я, кстати, тоже. Только в то время С++ еще только обзавелся шаблонами и ими еще учились пользоваться. А без шаблонов плюсы из себя ничего выдающегося не представляют.
Здравствуйте, eao197, Вы писали:
E>Вероятно, в этом все дело. C++ -- это отличный язык. А вот то, что он высокого уровня -- об этом можно поспорить. Имхо, у той же Java или Ruby уровень гораздо выше. И есть масса задач, для которых C++ не является языком, на котором решения строятся легко и просто. Разработка Web-приложений, например.
ИМХО дело не в высокости уровня, дело в подходе к проектированию.
Здравствуйте, vdimas, Вы писали:
V>Для обработки звука, например, уже вполне всего хватает. V>Я вот недавно баловался с реал-тайм эффектами для гитары на своем компе. Пробовал и на С++ и на С#. В первом случае загрузка проца 5%, во втором — 7..9%.
А когда доделают оптимизатор то разници вобще не будет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alexeiz, Вы писали:
A>Меня уже достали твои общие слова. Ты отрицаешь наличие высокоуровневых возможностей в C++?
А меня достал ты со своей уверенностю в том, что ты здесь лучше всех знаешь С++.
Там нет:
1. Стандарта на массивы и строковый тип. std::vector и std::string на эту роль не подходят, потому что все равно авторы каждой библиотеки изобретают собственные велосипеды.
2. Стандарта на политику обработки ошибок
3. Нормальной возможности использовать функциональные типы (заменители на килобайтах шаблонов и макросов — не считаются)
4. Замыканий
5. Уверенности в том, что безобидный на вид код не окажется злостным UB
Там есть:
1. Хреновая поддержка стандарта в распространенных компиляторах
2. Необходимость писать килограммы оберток каждый раз, когда тебе нужно использовать чужую библиотеку (см п.1 и п.2)
3. Заботливо разложенные на каждом шагу грабли, в качестве ярких примеров — vector<bool>, auto_ptr в котейнерах, и прочие радости.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Дарней, Вы писали:
Д>>я раньше тоже думал в точности, как ты
AVK>Я, кстати, тоже. Только в то время С++ еще только обзавелся шаблонами и ими еще учились пользоваться. А без шаблонов плюсы из себя ничего выдающегося не представляют.
Когда трюки с шаблонами только придумали, я вообще был в полной эйфоии. Это уже потом пришло горькое разочарование
Здравствуйте, Дарней, Вы писали:
Д>1. Стандарта на массивы и строковый тип. std::vector и std::string на эту роль не подходят, потому что все равно авторы каждой библиотеки изобретают собственные велосипеды.
Изобретали, я бы сказал. Многие библиотеки (например, Qt, wxWidgets, ACE) начали развиваться еще до появления данных классов и до их стандартизации. Сейчас, к тому же, идет процесс добавления поддержки стандартных классов во многие старые библиотеки. В частности, Qt нормально дружит с std::string.
Д>2. Стандарта на политику обработки ошибок
А он вообще возможен в мультипарадигменном языке.
Если же речь идет об исключениях, то есть std::exception, а все, что std::exception не поддерживает -- см.п.1.
Д>3. Нормальной возможности использовать функциональные типы (заменители на килобайтах шаблонов и макросов — не считаются)
+1
Д>4. Замыканий
+1
Д>5. Уверенности в том, что безобидный на вид код не окажется злостным UB
+1
Д>Там есть: Д>1. Хреновая поддержка стандарта в распространенных компиляторах
В распространенных?
Д>2. Необходимость писать килограммы оберток каждый раз, когда тебе нужно использовать чужую библиотеку (см п.1 и п.2)
Уже практически не нужно.
Д>3. Заботливо разложенные на каждом шагу грабли, в качестве ярких примеров — vector<bool>, auto_ptr в котейнерах, и прочие радости.
auto_ptr в контейнера -- это элементарное не знание языка.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Дарней wrote: > C>Эээээ... А я это где-то говорил? > это я про то, с чего начиналась эта ветка. А то, что С++ рулит в > /некоторых/ областях, никто не станет оспаривать
Флейм начался после того, как я включил десктопные приложения в эти области.
(вспомнишь о смарт-поинтерах С++ сразу)
