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

IT>>>>>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.
1 — DCOM, 2 -Remoting
Так что гонишь ты все.

VD>Я имею в виду, что AVK сказал "то сравнение будет не в пользу первого", а первым у него был .NET.

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

S>>Это IT и ты не поняли, что я говорил не про C#, а отвечал вот на это:
S>>"Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен."

VD>Вообще-то это был не вопрос, а ответ. Подколка, тык сызыть.

Я типа повелся Ну не согласен я с тем, что быстродействие сейчас лишним стало.

S>>Угу, только на С++ я кой-чего сделаю с шаблонами, а на шарпе придется выкручиваться без них.

VD>Ну, это ты зря. Шаблоны в шарпе все равно в ближайшее время появятся. Ты же про вычисления говоришь? Или я тебя не правильно понял?

Вот когда появятся, тогда и можно будет их обсудить.

VD>>>Вот Мишка.Нэт уже пытался это сделать. Может и ты попробуешь? Если удастся без гемороя я тебе $300 подарю.

S>>Маловато будет

VD>Ладно 350.99

Тебя готовый (из gcc выдеру) не устроит?

S>>Mishka<T> изначально поставил неправильную цель — обеспечить запрет создания некоторых классов не GC-методами. Вот оттуда и геморрой.

VD>Он такой цели не ставил. Ты его статью читал? У него как раз попытка реализации GC средствами C++. Кстит, на VC6 он тоже забил (шаблон слабые...).

Он перед статьей в форуме трепался на эту тему. И цель такая ставилась. Когда с ней облом вышел, видать и GC писать расхотелось


S>>Аллокатор быстрый, не гарбадж-коллекнутый там не слишком легко сделать

VD>Про value-типы слышал? Вот они как раз для оптимизации добавленны. К тому же ты не правильно себе понимаель .NET и возможности MSIL. На том же C# в ансэйф-режиме ты можешь занимать память где угодно и делать с ней что угодно. В том же шустрике есть пример быстрой сортировки на базе указателей.

Ну а переходы safe-unsafe, надо полагать, бесплатные? А что касаемо value-типов, так классы ими вроде быть не могут? А от структур наследовать нельзя. Вот и выходит геморроя поболее, чем в С++.

VD>>>В Шустриках сравнен одинаковый код, но он тебе не нарвится потому что не дает С++ глобального превосходства.

S>>Там примитивный код, в жизни такой редко нужен.

VD>В жизни код еще приметивней. Просто его много. Не думаю, что ты каждый день пишишь крутые алгоритмы. По крайней мнер 99 их процентов уже давно написаны.

Я не про крутые алгоритмы. Я про иерархии классов, с экземплярами которых приходится работать. Короче, value-типы обычно не катят. И, кстати, 90% из тех 99 алгоритмов, что уже написаны, нахаляву никто не раздает.

VD>>>Ну, тогда задумайся хоть над тем, что на Шарпе просто проще писать "хороший" код.

Мне — сложнее. Появятся шаблоны, посмотрим.

S>>Без шаблонов неизбежны либо повторы кода, либо падение быстродействия (если избегать повторов через делегаты).

VD>Тут ты прав. Но, во-первых, не настолько уж он замедляется, и, во-вторых, судя по всему такое положение вещей скоро изменится. Слышал, что для Ротора (CLI) шаблоны уже сделаны и доступны для скачивания?

Их кто-то умеет компилировать? Или самому язык писать придется?

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

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

S>>Насчет того, что GC работает быстрее чем сишный хип — ты уверен, что это справедливо для любого сишного рантайма и самописных хипов? На любых задачах? Речь вроде не шла о конкретном компиляторе.

VD>Вот смотри! Ты сказал ключевые слова "любого сишного рантайма". Т.е. ты и сам понимаешь, что многие рантаймы могут оказаться менее эффективным.

Так само собой. Реализаций C++ куча (в отличие от NET), некоторые из них вполне могут быть левой ногой писаны.

VD>А пример твой и проверить то тяжело, так как ты рандом используешь. а рандом в .NET и STL разный (я уже не говрю о разных реализациях STL).

Ну выкинь этот rand нафиг, числа заранее подготовь. Главное, чтоб наследование было и массивы переменного размера, а сами объекты достаточно мелкие.

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

IT>Ы, ты всё прикалываешься. Мне бы сейчас где-нибудь надыбать нормальное честное сравнение DCOM и Remoting для применения этого хозяйства в борьбе с остатками неверующих, точнее не хотящих и цепляющихся за последнее

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

Так вот, а для DCOM есть COM+. Скоро выйдет 1.5-шка под Windows.NET Srv. Там туева хуча полезных вещей. Делать тоже самое под дотнэт прсто самоубийство. Так что я бы еще рассмотрел дотнэт-фрэймворк в качестве клиента и сервер для COM+. Ну и естественно сравнил бы это дело с ремоутенгом и вэб-сервисами. Причем сравнил бы как функционально, так и по скоростным характеристикам.

Кстати, нам сейчас нужны статьи. А из этого может получиться хорошая статья. Может займешся, а я AVK и другие тебе поможем (как советом, так и делом).

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

VD>Боюсь у твоих аппонентов есть серьезный козырь. Под дотнэт нет ни одного сервера приложений. Ну, разве что IIS. Но сам пониаешь он применим только для вэба.

Это я в курсе

VD>Так вот, а для DCOM есть COM+. Скоро выйдет 1.5-шка под Windows.NET Srv. Там туева хуча полезных вещей. Делать тоже самое под дотнэт прсто самоубийство. Так что я бы еще рассмотрел дотнэт-фрэймворк в качестве клиента и сервер для COM+. Ну и естественно сравнил бы это дело с ремоутенгом и вэб-сервисами. Причем сравнил бы как функционально, так и по скоростным характеристикам.

Тем не менее насчёт удобства это как посмотреть. Комплюсовые компоненты нужно будет ещё деплоить, да и отлаживать их сложнее, к тому же чтобы передать, допустим массив байт, нужно постараться.

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

VD>Кстати, нам сейчас нужны статьи. А из этого может получиться хорошая статья. Может займешся, а я AVK и другие тебе поможем (как советом, так и делом).

С удовольсьвием, только видимо во второй номер не поспею, видишь сайт глюкает, поиск отвалился...

ЗЫ. Хлопчик этот которому нужно pdf на сайт передать COM'а в глаза не видел. Я ему как-то пытался азы растолковать, только время потерял. Веб-сервисы он взял за пару дней, а ремотиг может ещё за три. Вот такие пироги. А апликейшин сервер... да пока он как-то и на фиг не нужен, пишем свои сервисы и в них всё что надо хостим. Хотя я конечно от него бы не отказался.

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

IT>С удовольсьвием, только видимо во второй номер не поспею, видишь сайт глюкает, поиск отвалился...

Давай. Ремоутинг вариант я напишу. Только для начала нужно определиться что и как тестировать будем.

IT>ЗЫ. Хлопчик этот которому нужно pdf на сайт передать COM'а в глаза не видел. Я ему как-то пытался азы растолковать, только время потерял. Веб-сервисы он взял за пару дней, а ремотиг может ещё за три.
Не, ремоутинг все же заметно посложнее сервисов. Хотя конечно если не заморачиваться то можно и за 3 дня. А копать там глубоко можно. Я до сих пор некоторых вещей не понимаю, хотя с ремоутингом довольно много ковыряюсь. С веб сервисами намного проще, хотя и возможности не те совсем.

IT> Вот такие пироги. А апликейшин сервер... да пока он как-то и на фиг не нужен, пишем свои сервисы и в них всё что надо хостим. Хотя я конечно от него бы не отказался.
Я думаю родные апп-сервера должны появиться. Тот же Борланд наверняка не упустит возможность, тем более что политика MS в этом плане какая то невнятная.

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

IT>>С удовольсьвием, только видимо во второй номер не поспею, видишь сайт глюкает, поиск отвалился...

AVK>Давай. Ремоутинг вариант я напишу. Только для начала нужно определиться что и как тестировать будем.

А сколько у нас времени есть?

AVK>Не, ремоутинг все же заметно посложнее сервисов. Хотя конечно если не заморачиваться то можно и за 3 дня. А копать там глубоко можно. Я до сих пор некоторых вещей не понимаю, хотя с ремоутингом довольно много ковыряюсь. С веб сервисами намного проще, хотя и возможности не те совсем.

Сложнее и копать там много, но начать применять хоть как-то довольно легко.

AVK>Я думаю родные апп-сервера должны появиться. Тот же Борланд наверняка не упустит возможность, тем более что политика MS в этом плане какая то невнятная.

То-то и оно. Причём никакой информации от MS

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

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

AVK>>Я думаю родные апп-сервера должны появиться. Тот же Борланд наверняка не упустит возможность, тем более что политика MS в этом плане какая то невнятная.

IT>То-то и оно. Причём никакой информации от MS

Это ответы Девида Чаппела с www.gotdotnet.ru

==============================================
Вопрос: Как Вы считаете, как долго COM/COM+ будет использоваться для построения бизнес-приложений?

Ответ: COM и COM+ — это не одно и тоже, так что ответ зависит от того, что Вы имеете в виду. Службы COM+ доступны в .NET Framework под названием "Enterprise Services", так что они без сомнения будут использоваться. Стандартный COM, в то же время, не используется для новых .NET Framework приложений. Как только Framework станет выбором по умолчанию для разработки Windows приложений, роль COM и LOB приложений будет существенно снижена.
==============================================

Вот так — ничего в общем то и не сказал.

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

ГВ>Я понимаю под эти словом объём кода, который будет заниматься трансляцией COM-овских соглашений и типов данных в данные и соглашения, принятые при разработке прикладной логики.

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

SS>>>>Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу:
SS>>>>"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"

ГВ>>>Это от объёма задачи зависит. Чем она больше — тем важнее унификация внутренней структуры и глубина проработки абстракций. Тем адекватнее там C++.

VD>>Софистика чистой воды.

ГВ>Почему?

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

ГВ>...запоздалым выделением абстракций, либо — превентивным анализом и структурированием абстракций. Последний вариант — ИМХО, самый разумный как раз в контексте большой программы (ну, или такой программы, от которой ожидается, что она станет большой).

Понимаю... нефть ищите... (с). Вот только один вопрос! К чему ты все это говоришь? Тебе был задан конкретный вопрос: "...реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET". Ты же ответил на другой. И сейчас пытаешся доказать свою правоту.

Пойми, никто с тобой не будет спорить о том, что крамотная декомпозиция это одна из важных составляющих успеха в программировании. Но это здесь было вообще не причем. На Шарпе и Яве абстракции делаются ни чуть не хуже чем на С++. Конечно отсутствие шаблонов в некоторых случаях приводит к менее эффективному коду и к лишним рантайм-проверкам (отсуствие которых может привести к некорректному поведению), но в других областях Шарп и Ява делают С++ как катенка.

Вот тебе пример... Реализуй на С++ контейнер содержащий заранее не известные типы. И ты увидишь всю слабость обычного С++. Он ведь умее или контролировать типы только на стадии компиляции. Тебе ридется городить море кода производящего боксинг простых типов и структур в конструкции типа VARIANT (хронящии некое описание хранимого типа и ссылку на экземпляр). Или привести все к указателю на void переложив заботу о типах с компилятора на конечного программисто (того что будет использовать твой контейнер). Многие перепрограммировшие на С++ скажут, что в этом нет ничего страшного. Подумаешь нужно подумать... А я скажу, что это то место где идеологически зараждаются ошибки. Причем ошибки трудноуловимые.

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

Безусловно такая проверка медленнее чем ее аналог сделанный в период компиляции и наличие шаблонов резко упросило бы дело. Но все в компайл-тайме не проверишь. А С++ практически лишен рантайм проверок (только динамик_каст, но он очень ограничен). Кстати, в MC++ динамик_каст резко расширил свои возможности. Это заслуга рантайма .NET.


ГВ>C++ как раз и адекватен, поскольку у него, в частности, развиты механизмы комбинирования абстракций и средства оптимизации (inline).

То что эти заявления безосновательны тебе уже говорили. Но ты никого не слышиш.

1. inline — это наследие уродливого прошлого. Инлайнинг функций — это самое мошьное средство оптимизации, но им должен управлять не человек, а компилятор. Легко доказывается простыми тестами с автоинлайнингом и хорошими скоростными показателями .NET и Явы.

Комбирирование абстракций в Шарпе не просто развито. Она перешло на качественно новый уровень. Там разговор идет в терминах коллекций, объектов и ссылок между ними, а не на уровне байтов и битов к которому тяготеет С++. Да реализация местами является не столь эффективной по сравнению с тем что можно достичь на С++ с использованием шаблонов. Но качественная реализация на С++ это нетривиальная работа. Сделать ее может не каждый, да и самые крутые программисты из-за больших объемов работы плюют на оптимальность алгоритмов и вибырают более "легкие" решения. А они в разы проигрываю тем универсальным решениям применяемых в Яве и Шарпе.

В конце концов есть только три алгоритма хранения множества: массив, связанный список и хэш-таблица. Остальные (и даже дерево) являются разнаыидностями и реализуются на этих базовых приметивах. В Шарпе и Яве программист с первых шагов приучается их использовать. А в С++ уровень разработки, за частую не дает программисту подняться над мелочами и осознать, что вот здесь нужно использовать хэшь-таблицу, а вот здесь связанный список, а здесь динамический массив. В большинстве реализаций STL хэшь-таблица вообще отсуствует, а писать свою многие просто не могут или нехотят. Отдельная проблема хэш-функции. В той же Яве и .NET любой объект имеет дефолтную реализацию хэшь функции которую можно легко заменить на собственную.

ГВ>Ну, только не передёргивай, я говорил о том, что а) COM — не единственный в своём роде способ реализации компонентного подхода к deployment;

Тебе уже сказали, что компоненты к деплойменту отностся так же как классы или методы. И сказали, что на С++ нет ни одного промышленного аналога COM (имеющего те же возможности).

ГВ>б) соглашения COM устанавливают очень неприятные и глупые ограничения для программистов на C++;

А кто виноват? В С++ нет ни одной потуги к той самой компонентности. Вот и приходится создавать упрощенную модель. Так чтобы она подходила ко всем компиляторам и всем языкам.


ГВ>в) что нет необходимости каждый класс программы делать компонентом в смысле компонентов/объектов COM/CORBA; г) что нет нужды ради "компонентизации" корёжить хороший язык C++.

Хреновый язык. Тебе уже не раз показывали вещи которые нельзя сделать на С++Ю, которые приводят на нем к повышенной опастности или неадекватным задаче размерам кода. Ты же долдонишь одно и тоже не приводия аргументов. Вернее приводя, но против своих же выводов.

Я тебя уже спрашивал: "Что плохого если без сущесвенного оверхеда ты получишь возможность работать с любым объектом как с компонентом?". В ответ "нет необходимости каждый класс"... Несерьезно.

ГВ>Теперь о том, о чём "речь не о том" . Речь как раз о привлекательности C++ потому что а) язык позволяет очень глубоко структурировать программу

Согласен! Но 90% других языков позволяет структурировать программу как минимум не хуже чем С++. А то же Шарп иногда и лучше. И внось в ответ безпочвенные заявления являющиеся слествием того, что ты влюблен в С++ и не хочешь смотреть вокруг.


ГВ>..., что в контексте неоспоримого довода о важности декомпозиции и проектировании выглядит очень привлекательным;

И опять же тебе уже на слабо говорят, что большинство выбравших Яву и Шарп выберают эти языки/платформы в виду того, что проектирование на них в разы проще чем на С++. И опять в ответ расказ о правильности проектирования перед кодированием...


ГВ> б) этого никогда не позволят "компонентные технологии"

Т.е. они не позволят проектировать и структурировать програмы.

ГВ>, базирующиеся на унификации языковой модели; в) он очень привлекателен как средство "работающей" реализации сложных идей.

Да на нем и простые идеи иногда сложно реализовать. А сложные идеи можно и на асм-е реализовывать. Так что это просто демогогия. Безосновательные выводы и итверждения апелирующие к чувствам и эмоциям.

ГВ>В твоих словах сквозит попытка смешать понятия "COM" (или "CLR"?) и "компонентные технологии вообще".

В моих словах свквозит утверждение, что COM и CLR являются реализациями компонентных технологий доведенных до приемлего качества и способных применяться в промышленном производстве ПО.

ГВ>Поправь меня, если я ошибаюсь.

Поправил.

ГВ> Если же нет, тогда скажу, что хотя в каком-то контексте такое смешение и возможно (особенно — в контексте маркетингового оболванивания)

Во. Сново демогогия! Так кто из нас занимается оболваниваением?

ГВ>, но не в даннном споре (я не позволю ). Это — неправомерное смешение понятий. Конкретно, смешивается концепция ("компоненты") и конкретная спецификация (COM).

Ты хоть сам то понял, что сказал?

ГВ>И ещё. Объясни, плиз., что именно я с трудом могу объяснить?

Похоже что ты и сам не можешь объяснить, то что пытаешься. Получается размыто и не убедительно... Как же я это могу объяснить, если я утверждаю обратное?

VD>>Чего? Твоего отношения сложившегося из-за нежелания разобраться в критикуемых тобой технологиях?

ГВ>Нет, не только моего мнения. Это не меняет того, что COM/ORB/.NET/<вписать> являются частными случаями реализации компонентного (модульного с описанными выше расширениями) подхода.

А что кто-то утверждал обратное? Я только утверждаю, что С++ не содержит ни грамма возможностей облегчающий работу в рантайме и тем самым разработку компонентных технологий. И я так же утверждаю, что подход избранный в .NET (забота о рантайме и учитывание этого фактора при проектировании и рантайма, и зыков) является верным и дает свои плоды.

VD>>Доживет. Как C и asm. А .NET конечно мутирует. Или сдохнет. Например, ему точно нужна мутация в области дженерик-программирования.

ГВ>Ну вот, мутирует, там и посмотрим Только, ИМХО, он ещё и в плане рантайма мутировать будет. То-то веселуха начнётся с бинарной совместимостью.

Опять же, не нужна она там. Там промежуточный язык есть и система контроля версий. Просто на одной машине будут жить две разные версии рантайма. И старые программы будут работать со старым, а новые...

ГВ>Впрочем, последнее — злостный стёб. Ничего архисложного в JIT-компиляции старого кода в новый нет.

Да и не нужно это делать.

VD>>Вот ты и даказал своей реализацией делегатов, что С++ хреновый инструмент для реализации абстракций. Помнишь свое описание метода? Да и переносимость кода доказал замечательно. Иди скомпилируй свой код где-нибудь под Sun-ом.

ГВ>Интересно ты выводы делаешь

Да когда вижу можре нечитаемого кода который не может скомпилировать 80% компиляторов, то как-то выводы направшиваются сами собой. Мой код почему-то и на Интеле и на борланде компилируется, хотя в принципе это и не ружно.

ГВ> Ты мне говорил, что аналога делегатов C# на C++ сделать нельзя, я предметно доказал обратное.

Вот жаль, толко аналога не вышло и код твой комплируется только на Интеле.

ГВ>ИМХО, доказав гибкость C++ как инструментального средства.

Уродство это, а не доказательство. Ты сделал самы приметивный вариант использовв конструкции которые еще не появились в половине компиляторов и все равно создал море кода, да еще вынуждающего делать декларации методов размером со страницу. Нам такой хоккей не нужен. А ведь твои делегаты грохнутся даже при вызове между потоками, а чтобы сделать вызов между процессами тебе нужно будет создать подобие собственного кода, а это уже такая гора кода что в нем можно захлебнуться. Но нужно это в большинстве современных программ, и совершенно непонятно, почему нельзя расширить возможности сзяка, ну хотя бы чтобы такие возможности можно было делать меньшей кровью. Я тебе уже сто раз коворил, что в С — это делалось двумя строчками кода и было 100% типобезопастно. В С++ такое нагромождение является следствие неправильного дизайна языка, а вернее ошибкой в проектировании. Нужо было вместо уродских указателей на методы класса, противоречащих кононам ООП сделаь сдвоеный указатель указывающий на объект и на метод, ну и естественно сделать их как и в С независимыми от конкретного класса... совпадает сигнатура — значит можно вызвать. Ты же нечинаешь разводить демогогию о стройности языка. Чем решение изложенное мной менее стройно чем придуманное Страуструпом? Да в амбициях последнего и не желании признавать свои ошибки!

ГВ> Реализацию можно сделать и по-другому, вопросов нет. Можешь сам этим заняться, если интересно.

Ухе не интересно. Для мнея С++ — это низкоуровневый язык предназраченый для всякого рода хаков и совместимости с кодом времет эры С/С++.

ГВ>Мне лично — уже нет, по причинам, изложенным чуть ниже. Кстати, об "описании метода". Я думаю, что если бы ты почитал реальное описание того, как работает CLR — то выводов класса "ужас", "монстр" и т.п. сделал бы ещё больше.

Я как бы его рассмотрел очень внимательно и под отладчиком, и под анакриной, и представлении Рихтера... И вижу скорость работы этого дела... Очень даже приемлимую для современного железа.

ГВ>У меня тут появилась замечательная мысль, которая ускользала на протяжении всех этих баталий. А на хрена в C++ вообще делегаты с евентами нужны? Всё, что можно сделать делегатами/евентами зашибись как решается интерфейсом с единственным методом

Вот и подумай сколько тебе нужно будет прадить липовых наследований из-за пустекового дела решаемого в С одной строкой кода. Достаточно просто сравнить количество кода...

ГВ>..., принимающим объект-сообщение нужного типа плюс множественным наследованием объекта-приёмника от нужного набора таких интерфейсов (можно — с частичной реализацией оных). От ипостаси "евентов" как от варианта диспетчера сообщений никуда не денешься, но зачем тянуть за собой процедурно-ориентированный интерфейс?

Он более чем ОО-ый.

ГВ> Это же совсем не объектный стиль в принципе!

Это удобный, краткий и эффективный метод. И не менее ОО, чем наследование.

ГВ>То есть, оцени прикол: я что-то доказываю тебе, ты — мне, тогда как сам по себе объект обсуждения выбран некорректно!

Можешь посмотреть на Яву. Она решает проблему событий (неизбежную в современном мире) очень похожим образом. Но для простоты они ввели вложенные классы имеющие ссылку на родителя. Получатеся проще чем на С++ но все рвано криво и громоздко. Когда сравнивешь код Явы и .NET, то сразу тановится все ясно.


На С++ я лично для себя нашел еще более банальное и довольно эффективное решение:

template<class T>
struct Base
{
protected:
   void Fire()
   {
      T * pT = (T*)this;
      pT->Event1();
   }
};

struct MyClass : Base<MyClass>
{
public:
  void Event1()
  { ... }
};

Решение более удобное чем интерфейсы, но имеющее недостоток. Нелья динамически подключиться к событиям дугого объекта. Ну, а с интерфесами, можно и так, но неудобно. Что мелало сдалать нормальные указатели на ОО-функции?

ГВ>И, кстати, теперь я чуть больше, чем раньше согласен с теми высказываниями, которые сопоставляют C# и "чистый" C. Он-таки на самом деле близок к C!

Вот ты ёрничаешь, я на практике ощутил насколько подход старого С проще и удобнее. В новой реинкорнации он позволяет прозрачно вызыватать удаленные методы и круппировать вызовы в одном контейнере (делегате). Вывод — это проще, удобнее, эффективнее и любые слова не поменяют этого расклада. Про использование иттерфейсов я тебе говорил с самого начала, и в самом начале объяснил почему это неудобно.

VD>>Тебе не кажется, что твоя реализация просто монстроидальна и что она явно проигрывает тому что было на дремучем С (как по краткости и элегантности, так и по эффективности)?

ГВ>Нет проблем — можно поманипулировать с регистрами, можно и от типобезопасности избавиться. Только я этого делать не буду. Если считать void* верхом достижения программистской мысли, то это не есть правильное считание.

Ну, и кто из нас передергивает? Думаю ты прекрасно меня понял.

ГВ>Ну, перечитай ещё раз. А если без стёба, то сформулируй вопрос — отвечу.

Уже устал. Ты все равно отвечаешь на другие вопросы... которые я не задовал.

ГВ>>>Интересно, рефлексия в форумах наверное никогда не прекратится. Не, ребята, я больше в мыльных операх не участвую.
VD>>Гы-гы.
ГВ>Banzai!
Ну, в общем действительно я тоже подустал.

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

VD>>Я имею в виду, что AVK сказал "то сравнение будет не в пользу первого", а первым у него был .NET.

Цитирую:

IT>>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.
AVK>Я думаю что если использовать TcpChannel и BinaryFormatter то сравнение будет не в пользу первого. Плюс у ремоутинга гибкость и удобство использования в разы больше.

Здесть это легкто читаеться как:

Я думаю что если использовать TcpChannel и BinaryFormatter то сравнение будет не в пользу первого (.NET — он же первый встречается). Плюс у ремоутинга гибкость и удобство использования в разы больше.

Когда много сущьностей лучше выделять нужную отдельно.

PS

Но это я так... прикалывался.

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

S>Ну не согласен я с тем, что быстродействие сейчас лишним стало.

Дык и я нет. Но до маньячества то доводить зачем? Там не если и есть просад производительности, то совершенно линейный (на проценты, а не в разы). Да и связан он в основном с тремя вещеми:

1. Отсуствие дженерик-программирвания. Уже сейчас частично решается на МС++. В Версии 2 скорее всего шаблоны введут в язык и CLR.

2. Интероп со старым кодом. Если задача связана с частым дерганьем интеропа, то есть только одно решение МС++. Но во многих случаях можно вообще обойтись без обращения к анменэджет коду, ну или сократить эти обращения до не критичного минимума.

3.Не полный набор оптимзаций. Это вообще временное явление. При должном упорстве можно добиться большей оптимизации за счет использования информации о конкретной системе.

S>Вот когда появятся, тогда и можно будет их обсудить.

Ротор видел? К нему уже патч есть. Три мега и шаблоны в твоем распоряжении.

S>Тебя готовый (из gcc выдеру) не устроит?

Если он встроин в компилятор, то нет. А если как классы/шаблон совместимые с другими компилятрами и если все будет так же удобно и шустро как на менеджет языках, то может и устроит.

VD>>Он такой цели не ставил. Ты его статью читал? У него как раз попытка реализации GC средствами C++. Кстит, на VC6 он тоже забил (шаблон слабые...).

S>Он перед статьей в форуме трепался на эту тему. И цель такая ставилась. Когда с ней облом вышел, видать и GC писать расхотелось

Ну, прочти статью... там все предельно ясно... пока дело до кода не доходит.

S>>>Аллокатор быстрый, не гарбадж-коллекнутый там не слишком легко сделать

VD>>Про value-типы слышал? Вот они как раз для оптимизации добавленны. К тому же ты не правильно себе понимаель .NET и возможности MSIL. На том же C# в ансэйф-режиме ты можешь занимать память где угодно и делать с ней что угодно. В том же шустрике есть пример быстрой сортировки на базе указателей.

S>Ну а переходы safe-unsafe, надо полагать, бесплатные?

Приводят к копированию пиннутых данных. Но сам переход ничего не стоит. В МС++ все можно обойтись без пинов и скорость такая же как при работе на обычном VC. Я сам проверял... писал отрисовку контрола на С++.

S>А что касаемо value-типов, так классы ими вроде быть не могут? А от структур наследовать нельзя. Вот и выходит геморроя поболее, чем в С++.

Зато их можно вкладывать друг в друга.

S>Я не про крутые алгоритмы. Я про иерархии классов, с экземплярами которых приходится работать.

Дык а скорость то кода как от этого зависит? Ну, вон терерь весь сайт на C# и что? Этот проект маленький что ли? И все работает.

S>Короче, value-типы обычно не катят. И, кстати, 90% из тех 99 алгоритмов, что уже написаны, нахаляву никто не раздает.

Да в общем они почти все в стандарных библиотеках .NET и Явы.

VD>>>>Ну, тогда задумайся хоть над тем, что на Шарпе просто проще писать "хороший" код.

S>Мне — сложнее. Появятся шаблоны, посмотрим.

Можешь уже попробыать на Роторе.

S>Их кто-то умеет компилировать? Или самому язык писать придется?

Умеет компилировать C#-компилятор из CLI и Jit-омпилятор от туда же.

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

S>Ну выкинь этот rand нафиг, числа заранее подготовь. Главное, чтоб наследование было и массивы переменного размера, а сами объекты достаточно мелкие.

Сейчас нет времени, но позже обязательно попробую. Пример я твой уже отложил.

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

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

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

IT>С удовольсьвием, только видимо во второй номер не поспею, видишь сайт глюкает, поиск отвалился...

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

IT>ЗЫ. Хлопчик этот которому нужно pdf на сайт передать COM'а в глаза не видел. Я ему как-то пытался азы растолковать, только время потерял. Веб-сервисы он взял за пару дней, а ремотиг может ещё за три. Вот такие пироги. А апликейшин сервер... да пока он как-то и на фиг не нужен, пишем свои сервисы и в них всё что надо хостим. Хотя я конечно от него бы не отказался.

Ну, вот когда начнешь ядро с ком-а снимать, вот тогда раскажишь...

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

IT>А сколько у нас времени есть?

Ну, 2-е недели точно. Нам нужно еще Клиент-Сервер сдать.

IT>Сложнее и копать там много, но начать применять хоть как-то довольно легко.

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

IT>То-то и оно. Причём никакой информации от MS

К сожалению информация есть. И она говрит перебьетес COM+-ом 1.5.

Первой нетовской ласточкой будет следующий релиз SQL Server-а. В него вместо Явы запихнут .Net. На нем и увидем как это будет выглядеть. Может другого сервера приложений и не понадобится.

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

AVK>Вот так — ничего в общем то и не сказал.

Да в обще-то открыто сказал, что хрен вам вместо сервера приложений только для .NET. Ну, и море демогогии.

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

IT>>А сколько у нас времени есть?

VD>Ну, 2-е недели точно. Нам нужно еще Клиент-Сервер сдать.

Тогда ок.

IT>>Сложнее и копать там много, но начать применять хоть как-то довольно легко.

VD>Дык и COM... это применять начать не сложно. Вот ты мне скажи как ты без защиты обойдешся, без тразакций, без котроля загрузки... Мы вон на сайте так и не нашли код грузяций процессор.

Ну ты сравнил. За три дня начала применения COM ты откомпилируешь разве что пару примеров, да позапускаешь визард. Потом ещё неделю будешь репу чесать и решать надо оно тебе или не надо. Я же говорю о том что человек (правда уже хорошо знакомый с .NET) просто разобрал пару примеров и начал писать вполне рабочие задачи, не задумываясь о том что такое QueryInterface, AddRef, Release и какие его ждут глюки в будущем при неправильном применении этой святой троицы.

IT>>То-то и оно. Причём никакой информации от MS

VD>К сожалению информация есть. И она говрит перебьетес COM+-ом 1.5.

Тогда потестируем ещё и .NET внутри COM+. А шо делать?

VD>Первой нетовской ласточкой будет следующий релиз SQL Server-а. В него вместо Явы запихнут .Net. На нем и увидем как это будет выглядеть. Может другого сервера приложений и не понадобится.

А разве в него Ява уже запихана? Или ты про Оракл?
Не думаю что это будет хороший сервер приложений, он заточен совсем под другое. К тому же как раз этому зверю я бы меньше всего доверил хостить объекты, данные важнее. При всей надёжности CLR мне бы не хотелось их терять из-за какого-нибудь нерадивого компонента. А для SP и UDF это как раз самое оно.

Я думаю так. Если MS не сделает нормальный сервер приложений в ближайшем будущем, то его сделает кто-то другой, благо исходные коды ремотинга есть. В данном случае ситуация кардинально отличается от случая с COM+. Возможно, что это будет и какой-нибудь открытый проект

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

IT>Я думаю так. Если MS не сделает нормальный сервер приложений в ближайшем будущем, то его сделает кто-то другой, благо исходные коды ремотинга есть. В данном случае ситуация кардинально отличается от случая с COM+. Возможно, что это будет и какой-нибудь открытый проект

Да, скорее всего так и будет. Причем проект такой будет не один. Если для COM+ это сложно, мало информации, да и часть сервером MS поставляет бесплатно то для ремоутинга он оставил сладкий кусочек пирога, я не верю что никто не соблазниться.

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

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

S>>Ну не согласен я с тем, что быстродействие сейчас лишним стало.

VD>Дык и я нет. Но до маньячества то доводить зачем? Там не если и есть просад производительности, то совершенно линейный (на проценты, а не в разы).

Вот насчет процентов я пока не уверен. Кое-где, скорее всего, в разы.

VD>Да и связан он в основном с тремя вещеми:

VD>1. Отсуствие дженерик-программирвания. Уже сейчас частично решается на МС++. В Версии 2 скорее всего шаблоны введут в язык и CLR.

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

VD>2. Интероп со старым кодом. Если задача связана с частым дерганьем интеропа, то есть только одно решение МС++. Но во многих случаях можно вообще обойтись без обращения к анменэджет коду, ну или сократить эти обращения до не критичного минимума.

Это фигня, критичным быть не должно. Никто не собирается из нового кода isalpha дергать.

VD>3.Не полный набор оптимзаций. Это вообще временное явление. При должном упорстве можно добиться большей оптимизации за счет использования информации о конкретной системе.

Оптимизация — это вообще мелочи. А вот запрет наследования для value-типов — это уже серьезно.

S>>Вот когда появятся, тогда и можно будет их обсудить.

VD>Ротор видел? К нему уже патч есть. Три мега и шаблоны в твоем распоряжении.

И чем они компиляются, если не секрет?

S>>Тебя готовый (из gcc выдеру) не устроит?

VD>Если он встроин в компилятор, то нет. А если как классы/шаблон совместимые с другими компилятрами и если все будет так же удобно и шустро как на менеджет языках, то может и устроит.

Он встороен в компилятор, поскольку этим компялятором "для себя" используется. Впрочем, гугель говорит, что этот же самый GC и отдельно доступен — даже выдирать ничего не надо : http://www.hpl.hp.com/personal/Hans_Boehm/gc

VD>>>Он такой цели не ставил. Ты его статью читал? У него как раз попытка реализации GC средствами C++. Кстит, на VC6 он тоже забил (шаблон слабые...).

S>>Он перед статьей в форуме трепался на эту тему. И цель такая ставилась. Когда с ней облом вышел, видать и GC писать расхотелось

VD>Ну, прочти статью... там все предельно ясно... пока дело до кода не доходит.

Да читал я эту статью, успокойся. Даже критику писал

S>>>>Аллокатор быстрый, не гарбадж-коллекнутый там не слишком легко сделать

VD>>>Про value-типы слышал? Вот они как раз для оптимизации добавленны. К тому же ты не правильно себе понимаель .NET и возможности MSIL. На том же C# в ансэйф-режиме ты можешь занимать память где угодно и делать с ней что угодно. В том же шустрике есть пример быстрой сортировки на базе указателей.

S>>Ну а переходы safe-unsafe, надо полагать, бесплатные?

VD>Приводят к копированию пиннутых данных. Но сам переход ничего не стоит. В МС++ все можно обойтись без пинов и скорость такая же как при работе на обычном VC. Я сам проверял... писал отрисовку контрола на С++.

Мы ж про кастом мемори аллокаторы говорим, так? И какой мне прок память в ансэйфе выделять, если при переходе в сэйф она копироваться будет?

S>>А что касаемо value-типов, так классы ими вроде быть не могут? А от структур наследовать нельзя. Вот и выходит геморроя поболее, чем в С++.

VD>Зато их можно вкладывать друг в друга.

Тоже выход, но уж больно убого.

S>>Я не про крутые алгоритмы. Я про иерархии классов, с экземплярами которых приходится работать.

VD>Дык а скорость то кода как от этого зависит? Ну, вон терерь весь сайт на C# и что? Этот проект маленький что ли? И все работает.

Форумы тормозят изрядно.

S>>Короче, value-типы обычно не катят. И, кстати, 90% из тех 99 алгоритмов, что уже написаны, нахаляву никто не раздает.

VD>Да в общем они почти все в стандарных библиотеках .NET и Явы.

Блин, ну ткни меня носом в исходники реализации алгоритма SMACOF... Или хоть что-нибудь готовое для multi dimensional scaling.
Я нигде не нашел, хотя он, безусловно, написан. Вот и придется самому писать, похоже.

VD>>>>>Ну, тогда задумайся хоть над тем, что на Шарпе просто проще писать "хороший" код.

S>>Мне — сложнее. Появятся шаблоны, посмотрим.

VD>Можешь уже попробыать на Роторе.

Забыл написать — возможность размещать полноценные объекты на стеке тоже хочу, и чтоб деструкторы для них были и сами вызывались.

S>>Их кто-то умеет компилировать? Или самому язык писать придется?

VD>Умеет компилировать C#-компилятор из CLI и Jit-омпилятор от туда же.

Ок, посмотрим че они там сваяли.

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

AVK>Да, скорее всего так и будет. Причем проект такой будет не один. Если для COM+ это сложно, мало информации, да и часть сервером MS поставляет бесплатно то для ремоутинга он оставил сладкий кусочек пирога, я не верю что никто не соблазниться.

Дык, давай доделывай быстрее Янус, я пока баги на сайте почищу и будем соблазняться

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

IT>Дык, давай доделывай быстрее Янус, я пока баги на сайте почищу и будем соблазняться

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