Здравствуйте, vdimas, Вы писали:
V>Заблуждение и пропаганда. Программы все так же кишат ошибками (наблюдаю много их на C#). Разница лишь в том, что приложение не просто падает, а перед этим имеет возможность вывести сообщение об ошибке (опять же — если программист позаботился, а заботятся далеко не все). А с т.з. юзера — однофигственно, упало и упало, уже не поднять.
Не устаю напоминать что это верно только для однопользоательских приложений. Тут, конечно, пользователю стек трейс не всунешь. Но как только речь заходит про сервер...
Решения с изоляцией пользовательских процессов — тяжелы. Процессы не могут разделять общий кэш и все такое.
Выполнение пользовательских запросов в рамках одного процесса — страшный риск в неуправляемой среде. Маленький завал — и все, остальные три тыщи пользователей падают ни за что ни про что. Утечки памяти в 10 байт на пользователя в минуту не имеют практического значения в настольной системе. В сервере это означает, что 30000 пользователей за час съедят 18 метров. Что в свою очередь означает еженедельный перезапуск сервера с привлечением админа.

Я поигрался с Yukon и Reporting Services. Кто отлаживал что-нибудь типа расширения для Windows Explorer? Конечно, при соблюдении культуры программирования все зашибись. Но как только она несоблюдена — все, труба. Ты даже поотлаживаться не сможешь (потому, что студия, как и все, использует Open Dialog, расположенный в том самом шелле, который только что упал или завис). Положить этих товарищей путем подсовывания в них чего попало вообще невозможно. Пытаюсь бесконечную рекурсию в UDT в Yukon засунуть — упс, при селекте мне просто приезжает нормальный такой Message типа stack overflow все дела. Транзакция откатилась, остальные пользователи прекрасно себя чувствуют. Попробовал в репортинг сервисе каку в екстеншене сделать — хрен. Все работает, только мой екстеншн нигде не светится. Посмотрел я на логи — ага, секурити его не пропустила. Ничего, все остальное работает! Да, лично мне не менее обидно, чем если бы весь репортинг нафиг упал — я-то своего не добился. Нет, вру — менее обидно. Потому как AV или прочий низкоуровневый стуфф мне ничего не скажет о том, где я напортачил. А управляемая среда меня носом тыкает ровно в то место, где свалилось. И заботливо все в лог кладет, вместо тупого падения в дамп.
Ну да ладно. Я не об этом, а о том, что все остальные пользователи этого же сервера ничего даже не заметят!

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

V>Тебе давно пора согласится, что код бывает разного качества.

С этим утверждением я не спорил.

V> И этот факт, к сожалению, никак не зависит ни от языка, ни от фреймворка. Ты же пытаешься обнаружить корреляцию.

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

V>Ну, где как.

Я так понимаю у вас код идеальный.

V>Я и в проектах на VB видел тонны мусора. В противовес этому — наблюдал красивые и стройные программы и на Forth-e и на Asm-e.

Ясно. Во всем виноват ВБ.

V>Ну, используем CORBA в проекте. Там получаем сначала общую объектную ссылку по URI на клиенте, а потом выполняем статический метод MyClass_ptr MyClass::narrow(Object_ptr); Этот метод весьма типизирован и описан стандартным маппингом CORBA на C++. Не требуется обход защиты.

Т.е. ты считашь, что приведение засунутое в narrow кошернее чем вызванное напрямую?

V>Я не могу сказать, что готов писать только на плюсах. Скорее так — я сторонник выбора наилучшего инструментария под конкретную задачу. И я не собираюсь доказывать, что на С++ удобно решать ВСЕ задачи (хотя, единственный язык, пожалуй, на котором ВОЗМОЖНО решать практически любые задачи, даже Лиспоподобный синтаксис можно вывести).

Хм... Я тоже для некоторых задач наверно предпочту С++. Разница у нас в том, что я предпочту С++ для 1% задач, а ты для 99%.

V>Ты же считаешь, что дотнет покрывает все нужды современного программинга, да еще пошел в крестовый поход на плюсы.

Я так не считаю. Что я считаю я уже сказал.

V> Похоже, ожесточенные дисскуссии на эту тему сотрясают только rsdn. Как Java никуда не особо-то потеснила плюсы, так и дотнет не вытеснит.

Да ява с дотнетом уже очень сильно их потеснила. Но дело не в этом. Меня не интиресуют пристрастия миллионов. Меня интересует надежный софт и комфортные условия его создания.

Как тут кто-то очень хорошо сказал "безопасный язык является одной из обязательных составляющих получения надежного ПО".

V> Просто эти платформы корчуют "новые" рынки (распределенные приложения, например), и теснят всякие Дельфи и ActiveX с территории GUI.

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

V>Кстати, а на какой технологии Microsoft собралась делать следующий офис?

Чего не знаю, того не знаю. Слышал о перекомпиляции части Офиса в менеджед-режиме на МС++. Но какова цель этого действа непонятно.

А ведь именно офис, точнее Ворд, я хотел бы видеь в менеджед-виде в первую очередь. Уж больгл сильно он ключит.

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

V>Ты хотел сказать — по лучшим подсчетом. Ибо у меня упорно получается разница в среднем примерно 3 раза. В 2 раза я получал разницу лишь на простейших 2-х строчных циклах for(int i= blah, blah), но и это удивительно, ибо подобные алгоритмы джит должен был бы вообще переводить идеально в машинный вариант и показывать идентичное быстродействие (где он там в 3-х соснах заблудился?). Отчего-то не показывает.


Позволю себе усомниться в данных утверждениях.

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

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

V>странно... у меня это выходило на раз...

Пока что только на словах.

V>вызываю ф-ию API в которую надо передать адрес буфера, куда данные возвращаются. Малость "недоигрался" со StringBuilder и аттрибутами — и приплыли.

Как тут правильно заметил один товарищь: код в студию!

V>Они разные бывают, эти call convertions, иногда отличаются лишь порядком следования аргументов, а не только стороной ответственности за прочистку стека.

Ты под АПИ что имел в виду? И какое по-твоему саглашение использует ВиньАпи?

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

VD>>C# уже в версии 1.1 даст фору плюсам по надежности и устойчивости. Не идеал конечно, но все же не дырявое корыто.

V>Заблуждение и пропаганда.

В некоторых кругах это называют фактами. А вот как назвать твои голословные утверждения я даже не знаю.

V> Программы все так же кишат ошибками (наблюдаю много их на C#).

Кишат, но не так же.

V> Разница лишь в том, что приложение не просто падает, а перед этим имеет возможность вывести сообщение об ошибке (опять же — если программист позаботился, а заботятся далеко не все). А с т.з. юзера — однофигственно, упало и упало, уже не поднять.

Разница в том, что многих ошибок сделать то нельзя, а если таки ошибка сделана, то ее отловить можно без особых проблем.

VD>>Ну, завали его в безопасном режиме, а потом и поговорим.

V>Знаешь, играл как-то и экспериментировал с RFD пол-года назад (там генерирование типов налету). Ну, по неопытности применял команды, предназначенные для объектных ссылок, к структурам. Самое интересное, что приложение работало полностью в безопасном режиме.

Самому то не смешно?

V> И при генерации типов никаких ошибок не было. Но вот при создании экземпляров неоднократно получал сообщения типа "Virtual Machine .Net разрушена и не может продолжать свою работу. Приложение будет закрыто.".

В безопасном режиме без вызова небезопасного кода это невозможно в принципе (ну, разве что ошибка в рантайм-коде). У тебя же был просто небезопасный код сгенерирован.

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

V>Наблюдаю вылеты и глюки и в программах на C#. В чем суть твоего аргумента?

И разницы с плюсовыми программами не видишь? Ну, тут говорить не о чем. Опровергать оспаривание очевидного работа не для меня.

V>Ошибки делает не среда, а люди.

Люди, люди. Вопрос в том, помогает ли это делать язык и рантайм, или препятствует. Ну, и в результате получаемом в конце.

V>Именно. Под названием — "системное + прикладное программирование эффективных решений".

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

V>А ты не делай безусловные приведения. Тебе уже 100 раз об этом сказали.

Я и не делаю. Для этого лучшим решением является отказ от плюсов.
Оглянить вокруг. Погляди на примеры кода на этом сайте. Приведения всюду и тоннами. Неинициализированные переменные вообще песня без слов.

VD>>Просто нет человеческого контроля за инициализированностью переменных.

V>В дотнете тоже нет. Там контроль на уровне компилятора.

Сможешь доказать это утверждение?

V> VC 7.1 прекрасно ругается в аналогичных случаях. Если очень надо — задай опцию: "warnings as errors".

И в релизе? И даже кода объекты создаются разными хитрыми спосабами?

V>Ошибки есть в большом количестве (и будут впредь) и в программах на C#.

Старая песня...

V>Да не там ошибки обычно, где ты говоришь. Если мы и встречали ошибки, связанные с вылетом за диапазон массива или неправильной адресной арифметикой, то этих ошибок и 10% не набирается

Найденных? А не найденных?

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

V>Ой-ли???

Ой, ой...

V>Я достаточно трахался с чужим C# кодом. Были случаи по многопоточной синхронизации. Мне в тот момент было абсолютно все-равно на чем проект, ибо ошибки были обще-алгоритмического плана. В общем, как обычно, все пришлось переделывать нах.

Многпоточность есть многопоточность. Но опять же разница огромная. Одно дело когда это управляемый код с гарантией того что память не портится и отличным колфрэймом, а другое гадание в плюсовая прогармма скомпилированная в релиз в которй черт знает что случилось.

Что же до многопоточности... тут замечательно подходят функциональные языки. В них данные не перезаписываются что практически исключает необходимость в синхронизации.

VD>>Покажи, плиз приемущества статической типизации в С++ в необобщенном коде.

V>Кто-то кого-то не понимает (похоже, преднамеренно). В С++ используют типизацию/обертки на каждый чих, и правильно делают, ибо в run-time это ничего не стоит. Есть куча compile-time проверок. А в C# 2.0 мы даже не сможем обощить алгоритмы на различные типы int, floаt, double и т.д. Я не могу элементарно сложить 2 числа и подсчитать сумму "обощенного" типа. Я уже молчу о еще более мелкой типизации и подстройке алгоритмов — стратегиях и св-вах, управление которыми доступно нам через выводимые и зависимые типы.

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

V>Ты называешь подобные вещи ненужными трюками — но ты ошибаешься в классификации. Эти механизмы позволяют декларативно привязывать структуры данных и алгоритмы по их обработке к конкретным выводимым типам. Похоже, в этой области конкурентов пока нет. (из mainstream так уж точно)



V>>>>>Да, "шаблонность" нам малость поможет потом частично разрулить эти безобразия, однако, прежнего удобства от наличия сильной статической модели кода, какую привык наблюдать в С++, все-равно не получим даже в 2.0. (У меня Express, все ограничения дженериков уже просек).

VD>>>>Что-то говорит мне, что обосновать это утверждение тебе не удастся. Но попробовать стоит. Это будет интересно.

VD>>Даже пытаться не будешь?

V>Тебе же уже неоднократно все эти аргументы приводили. И даже еще больше. В предыдущем абзаце я повторил немногое.

Аргументы? Нда. Ты бы хоть один пример привел.

V>Прекрасный совет, спасибо. Но все же, бизнес-сущность — это самодостаточная единица, данная сверху. И ей наплевать на все паттерны а даже (о ужас) на ООП. На этих паттернах и ООП я могу лишь обвеску вокруг этой сущности соорудить, не более. Но саму ее аннулировать, извини, не получается. Вместе с ней аннулируется задача (есть такой побочный эффект)

Аннулировать? Ты о чем? ООП для проектирования нужно применять, и для замены кривых прямолинейных решений.

V>У нас не коллекции, а имплементации, но сути не меняет.

Что такое "имплементации" я не знаю.

V> Я уже ручками давно все сделал, просто показал явное место, где у нас куча динамических приведений. И это явно не на пользу эффективности.

За-то я знаю что кучи приведений говорит о качестве проектирования.

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

D>Смотрим IL (сборка Release):

Инлайнит JIT! Смотреть в msil бессмысленно.

D>Может в FW v.2.0 допускается inline-оптимизация?

Доступны начиная с 1.0. Запускать надо не под отладчиком. Можешь убедиться в моих словах запустив программу под cordbg с включенной опцией оптимизации. При этом ты увидишь реальный ассемблерный код сгенерированный джитом.

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

D>...я знаю поведение JIT-компилятора MS особо не регламентирует.

Все он регламентирует, вернее документирует. О инлайнинге сто раз уже писалось в МСДН-е.

D> Меня интересует возможно ли то, что в след. версиях встраивание станет возможным (опционально) на уровне Code -> MSIL.

Никогда в жизни. Инлайнинг реализован на уровне джита.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>По-моему C++/CLI должен это уметь.

Это умел и МС++ 1.0. Это заслуга не менеджед-расширения, а побочный продукт того факта что исходный компилятор имеет оптимизатор на уровне собственного промежуточного кода.

Смысла в этом практически нет. Но за счет того, что эвристики у VC по лучше и результат иногда получается более впечатляющий. Думаю, точку над i поставит Феникс.

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

S>Пытаюсь бесконечную рекурсию в UDT в Yukon засунуть — упс, при селекте мне просто приезжает нормальный такой Message типа stack overflow все дела.

А хвостовая рекурсия там не оптимизируется?

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

V>>вызываю ф-ию API в которую надо передать адрес буфера, куда данные возвращаются. Малость "недоигрался" со StringBuilder и аттрибутами — и приплыли.

VD>Как тут правильно заметил один товарищь: код в студию!

Повторяю опять — в функцию передаем адрес буфера, куда данные возвращаются (из этой ф-ии). Подойдет любой пример.

V>>Они разные бывают, эти call convertions, иногда отличаются лишь порядком следования аргументов, а не только стороной ответственности за прочистку стека.

VD>Ты под АПИ что имел в виду? И какое по-твоему саглашение использует ВиньАпи?

Кто сказал, что мне нужен только вынь-апи?

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

Я не понял смысла туманной фразы "с ручной возней с типами в С++". Если сигнатуры типизированы (без всяких void*), то возни нет в принципе.


VD>>>C# уже в версии 1.1 даст фору плюсам по надежности и устойчивости. Не идеал конечно, но все же не дырявое корыто.

V>>Заблуждение и пропаганда.

VD>В некоторых кругах это называют фактами. А вот как назвать твои голословные утверждения я даже не знаю.

Замечательно подходит абсолютно под все твои утверждения. Кстати весь предыдущий пост был написан в твоем стиле, не заметил?
Ты постоянно твердишь: "сахар, сахар", думая, что у кого-то станет от этого слаще во рту. Такие же сплошь голословные утверждения. В крайнем случае, выводы из собственного опыта. Причем этот опыт весьма необычный — ты работаешь практически в одиночку.

V>> Программы все так же кишат ошибками (наблюдаю много их на C#).

VD>Кишат, но не так же.

Нет так же. Кишат.

V>> Разница лишь в том, что приложение не просто падает, а перед этим имеет возможность вывести сообщение об ошибке (опять же — если программист позаботился, а заботятся далеко не все). А с т.з. юзера — однофигственно, упало и упало, уже не поднять.

VD>Разница в том, что многих ошибок сделать то нельзя, а если таки ошибка сделана, то ее отловить можно без особых проблем.

Хорошо. Реальная статистика. Проект делали примерно 2 года примерно 20 чел. Около 500 баг-репортов накопилось во время разработки. Из них записей "про падения — крэш" примерно 15 шт (3%). Остальная масса ошибок — не так перерисовывается контрол, не туда что-то пишется, ошибка логики при таких-то входных данных и т.д. и т.п.

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

Продолжая озвучивать свой опыт скажу, что отлов тех 15 ошибок, приводящих к крэшу — весьма легок. Лично я нахожу их мгновенно. Ну сразу в глаза бросаются места, где может быть ошибка. А вот ошибки логики приходится "пилить" порой долго и нудно. Тут затрачиваемый объем усилий совершенно несравним.

В общем, о чем я хотел сказать — что ты не правильно акценты расставляешь. Несомненно, дотнет — удобный фреймворк, но ты тут выставляешь на первый план явно незначащие аргументы.

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

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

VD>>>Ну, завали его в безопасном режиме, а потом и поговорим.

V>>Знаешь, играл как-то и экспериментировал с RFD пол-года назад (там генерирование типов налету). Ну, по неопытности применял команды, предназначенные для объектных ссылок, к структурам. Самое интересное, что приложение работало полностью в безопасном режиме.

VD>Самому то не смешно?

Нет. Ты же говорил про опции unsafe?

V>> И при генерации типов никаких ошибок не было. Но вот при создании экземпляров неоднократно получал сообщения типа "Virtual Machine .Net разрушена и не может продолжать свою работу. Приложение будет закрыто.".

VD>В безопасном режиме без вызова небезопасного кода это невозможно в принципе (ну, разве что ошибка в рантайм-коде). У тебя же был просто небезопасный код сгенерирован.

А какого хрена TypeBuilder позволил нагенерить несовместимые инструкции??? (код был не безопасный, он был принципиально неккоректный — в фомирование команд, предназначенных для классов, я подал тип структуры, и это никак не проверилось)

VD>И разницы с плюсовыми программами не видишь? Ну, тут говорить не о чем. Опровергать оспаривание очевидного работа не для меня.

О, опять ты про "очевидное". Ну я тебе в ответ напоминаю про реальную стоимость твоего "очевидного" — 3%.

V>>Ошибки делает не среда, а люди.

VD>Люди, люди. Вопрос в том, помогает ли это делать язык и рантайм, или препятствует. Ну, и в результате получаемом в конце.

Если ты рисуешь неправильно контрол, или у тебя логика в цикле пропускает последний/первый элемент, и т.д. и т.п. То результат будет одинаков, независимо от среды. Мне уже интересно, что у тебя там произошло с плюсами, что ты настойчиво повторяешь одно и то же? Ну не существенно это.

Кстати, а в плане рисования тех же контролов. Несмотря на то, что объектная модель и GDI+ более удобен, чем вынь-апи, я наблюдая гораздо больше ошибок и неккоректностей в реализайии контролов на C#. (Просмотри форум .Net GUI). Как ты подобну странность прокоментируешь???


V>>Именно. Под названием — "системное + прикладное программирование эффективных решений".

VD>Оставим системное. (Хотя тут тоже большой вопрос нужно ли для него С++. Про Сингулярити думаю слышал?) Но прикладное то, да еще критическое к сбоям и серверное закаким писать на средстве не обеспечивющем полноценный контроль типов?

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

V>>В дотнете тоже нет. Там контроль на уровне компилятора.

VD>Сможешь доказать это утверждение?

В смысле, сгенерить через TypeBuilder метод с переменной в стеке, например int, и вывести ее значение в Console без предварительного присвоения? Самому не смешно?

V>> VC 7.1 прекрасно ругается в аналогичных случаях. Если очень надо — задай опцию: "warnings as errors".

VD>И в релизе? И даже кода объекты создаются разными хитрыми спосабами?

Если у меня в C# переменная объявлена как член класса, то ее инициализацию даже компилятор не проверяет. Разве что Решарпер.

VD>Многпоточность есть многопоточность. Но опять же разница огромная. Одно дело когда это управляемый код с гарантией того что память не портится и отличным колфрэймом, а другое гадание в плюсовая прогармма скомпилированная в релиз в которй черт знает что случилось.

Как это память не портится при многопоточности. Именно в этом ошибки и проявляются. (Например, пишем в буфер что-то).

VD>Что же до многопоточности... тут замечательно подходят функциональные языки. В них данные не перезаписываются что практически исключает необходимость в синхронизации.

На функциональных языках нелегко делать числодробилки. А любой бизнес-приложение, где есть хоть какая-то отчетность или промежуточная статистика того требуют.

V>>Кто-то кого-то не понимает (похоже, преднамеренно). В С++ используют типизацию/обертки на каждый чих, и правильно делают, ибо в run-time это ничего не стоит. Есть куча compile-time проверок. А в C# 2.0 мы даже не сможем обощить алгоритмы на различные типы int, floаt, double и т.д. Я не могу элементарно сложить 2 числа и подсчитать сумму "обощенного" типа. Я уже молчу о еще более мелкой типизации и подстройке алгоритмов — стратегиях и св-вах, управление которыми доступно нам через выводимые и зависимые типы.

VD>Ясно опять пустые слова. Показать ты никаких приемуществ не можешь. Оно и понятно. Не может иметь приемуществ нетипобезопасный язык над типобезопасным.

По-моему все сказал.

VD>Аргументы? Нда. Ты бы хоть один пример привел.

V>>Прекрасный совет, спасибо. Но все же, бизнес-сущность — это самодостаточная единица, данная сверху. И ей наплевать на все паттерны а даже (о ужас) на ООП. На этих паттернах и ООП я могу лишь обвеску вокруг этой сущности соорудить, не более. Но саму ее аннулировать, извини, не получается. Вместе с ней аннулируется задача (есть такой побочный эффект)

VD>Аннулировать? Ты о чем? ООП для проектирования нужно применять, и для замены кривых прямолинейных решений.

Я вот не пойму о чем ты. Ты экстрасенс, способен выдавать решения не видя постановки? Могу прислать на мыло небольшую часть постановки, а ты нам попытаешься количество сущностей уменьшить вдвое, ok?

V>>У нас не коллекции, а имплементации, но сути не меняет.

VD>Что такое "имплементации" я не знаю.

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

V>> Я уже ручками давно все сделал, просто показал явное место, где у нас куча динамических приведений. И это явно не на пользу эффективности.

VD>За-то я знаю что кучи приведений говорит о качестве проектирования.

Это говорит о невозможности обощенного программирования в среде, которую используем прямо сейчас для коммерческих проектов.

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

V>>Ну, используем CORBA в проекте. Там получаем сначала общую объектную ссылку по URI на клиенте, а потом выполняем статический метод MyClass_ptr MyClass::narrow(Object_ptr); Этот метод весьма типизирован и описан стандартным маппингом CORBA на C++. Не требуется обход защиты.

VD>Т.е. ты считашь, что приведение засунутое в narrow кошернее чем вызванное напрямую?

Да, там достаточно логики, т.к. иногда вызывается внутрення команда протокола у удаленного серверного объекта, этот метод протокола — "_is_a()", и позволяет получить другой интерфес объекта. Кстати, в CORBA этот момент проработан немного лучше, чем в .Net Remoting. Попробуй в дотнете получить произвольный интерфейс у удаленного объекта, если явно не описано, что он этот интерфейс поддерживает. А ведь вполне используемая техника (Interface1 -> Interface2) в локальных задачах, по крайней мере регулярно наблюдаю в коде на .Net.

V>>Я не могу сказать, что готов писать только на плюсах. Скорее так — я сторонник выбора наилучшего инструментария под конкретную задачу. И я не собираюсь доказывать, что на С++ удобно решать ВСЕ задачи (хотя, единственный язык, пожалуй, на котором ВОЗМОЖНО решать практически любые задачи, даже Лиспоподобный синтаксис можно вывести).

VD>Хм... Я тоже для некоторых задач наверно предпочту С++. Разница у нас в том, что я предпочту С++ для 1% задач, а ты для 99%.

Если пошло такое оценивание, то я бы был более скурпулезен:

— формочки GUI -> .Net
— серверы бизнес-приложений (слово "бизнес" — ключевое, т.е. задачи типа — отсюда взять, туда положить) -> .Net
— вычисления -> C++
— компиляторы -> С++ (на машине с Resharper у меня две студии просто входят в ступор при обычной работе, с VA такого не было)
— "продвинутые" текстовые редакторы -> С++
— редакторы графики -> С++
— САПР-ы -> С++
— движки БД -> С++
— движки 3D (не роперы, типа Managed DirectX, а именно движки) -> C+
— сетевые протоколы и фильтры -> С++
— маааленькие GUI приложения/утилитки -> все-таки С++, из-за того, что дотнетные приложения стартуют довольно долго независимо от размера, а маленькие GUI приложения на С++ — мгновенно.
— серверные приложения, предназначенные для переливки и обработки больших объемов данных (напр. CVS сервер) -> C++
— моделирование объемных вещей (например, волнений моря или аэродинамика) -> C++
— для маленьких моделей допустим .Net , например, промоделировать картину общего доступа к радиоточкам при количестве абонентов не более нескольких тысяч, если речь о многих миллионах, то я бы не рискнул выбрать .Net в качестве платформы.


V>>Как Java никуда не особо-то потеснила плюсы, так и дотнет не вытеснит.

VD>Да ява с дотнетом уже очень сильно их потеснила.

VD>Как тут кто-то очень хорошо сказал "безопасный язык является одной из обязательных составляющих получения надежного ПО".

V>> Просто эти платформы корчуют "новые" рынки (распределенные приложения, например), и теснят всякие Дельфи и ActiveX с территории GUI.

По моим наблюдениям Java и дотнет гораздо более теснят весь остальной рынок: Дельфи, PHP/Perl и кучу другой всякой экзотики.
По сути, в живых остается Java, .Net и С++. Меж ними и раздел.

VD>А ведь именно офис, точнее Ворд, я хотел бы видеь в менеджед-виде в первую очередь. Уж больгл сильно он ключит.

Насколько я знаю, в основном плагины под него глючат. Но не в этом суть. Какой объем памяти потребует ворд для документа объемом > 2M, хотя бы???

Т.е., пока не все так гладко, как хотелось бы.

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

V>Попробуй в дотнете получить произвольный интерфейс у удаленного объекта, если явно не описано, что он этот интерфейс поддерживает.

Чего то не понял о чем ты. Объект либо реализует интерфейс, либо не реализует. Что такое "явно описано"?

V>- компиляторы -> С++ (на машине с Resharper у меня две студии просто входят в ступор при обычной работе, с VA такого не было)

А у меня не входят даже 4. Что я делаю не так?

V>- "продвинутые" текстовые редакторы -> С++

Почему?

V>- серверные приложения, предназначенные для переливки и обработки больших объемов данных (напр. CVS сервер) -> C++

Почему?

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

V>>Кстати, а на какой технологии Microsoft собралась делать следующий офис?

VD>Чего не знаю, того не знаю. Слышал о перекомпиляции части Офиса в менеджед-режиме на МС++. Но какова цель этого действа непонятно.

VD>А ведь именно офис, точнее Ворд, я хотел бы видеь в менеджед-виде в первую очередь. Уж больгл сильно он ключит.
Лично я не связываю особых надежд с менеджед офисом. Дело в том, что глюки ворда, раздражающие лично меня, связаны вовсе не с низкоуровневой безопасностью. Там проблемы в архитектуре. То, что у него сейчас периодически срывает крышу при разметке таблиц — ну так и будет срывать. То, что у него сейчас применение стиля "список" сшибает все форматирование — ну так там достаточно заскриптовать то, что они делают. Если люди вместо прямой смены свойства "продолжать нумерацию предыдущего списка" вызывают метод типа "применить шаблон списка с такими-то параметрами" — ну так они и на дотнете будут его вызывать. И проблем типа "ой, у нас что-то не получилось, так что мы пожалуй закроемся и напишем в микрософт" меньше не станет — это ж либо InvaligOperationException либо NullReferenceException. Документы сохранять при падении они уже и так научились.

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

S>Лично я не связываю особых надежд с менеджед офисом. Дело в том, что глюки ворда, раздражающие лично меня, связаны вовсе не с низкоуровневой безопасностью. Там проблемы в архитектуре. То, что у него сейчас периодически срывает крышу при разметке таблиц — ну так и будет срывать. То, что у него сейчас применение стиля "список" сшибает все форматирование — ну так там достаточно заскриптовать то, что они делают. Если люди вместо прямой смены свойства "продолжать нумерацию предыдущего списка" вызывают метод типа "применить шаблон списка с такими-то параметрами" — ну так они и на дотнете будут его вызывать. И проблем типа "ой, у нас что-то не получилось, так что мы пожалуй закроемся и напишем в микрософт" меньше не станет — это ж либо InvaligOperationException либо NullReferenceException. Документы сохранять при падении они уже и так научились.

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

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

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

Так вот за все время я не вылитил ни разу. И вообще писать было куда проще, так как мой редактор на моей машине еще и работал куда быстрее (без тормозов).

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

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

V>Повторяю опять — в функцию передаем адрес буфера, куда данные возвращаются (из этой ф-ии). Подойдет любой пример.

Повторюсь, еще раз. Код в студию! И не нужно вешать лапшу на уши.

VD>>Ты под АПИ что имел в виду? И какое по-твоему саглашение использует ВиньАпи?

V>Кто сказал, что мне нужен только вынь-апи?

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

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

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

V>Я не понял смысла туманной фразы "с ручной возней с типами в С++". Если сигнатуры типизированы (без всяких void*), то возни нет в принципе.

И как ты хочешь вызвать АПИ типизированно? Даже при возне с КОМ-ом типизация то и дело идет лесом. Тут и там появляется код живущий на предположениях о совпадении типов. А уж при возне с разными handle-ами о типизации и речи быть не может.

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

V>Замечательно подходит абсолютно под все твои утверждения. Кстати весь предыдущий пост был написан в твоем стиле, не заметил?

Не заметил. Видимо ты постоянно пишешь "в моем стиле". Вот этот пост видимо тоже.

В общем, кончай сотрясать воздух и попробуй поэксперементировать с интеропом. Уверяю тебя ждет немало интересного.


V>>> Программы все так же кишат ошибками (наблюдаю много их на C#).

VD>>Кишат, но не так же.

V>Нет так же. Кишат.

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

V>Хорошо. Реальная статистика.

Где?

V>Продолжая озвучивать свой опыт скажу, что отлов тех 15 ошибок, приводящих к крэшу — весьма легок. Лично я нахожу их мгновенно. Ну сразу в глаза бросаются места, где может быть ошибка. А вот ошибки логики приходится "пилить" порой долго и нудно. Тут затрачиваемый объем усилий совершенно несравним.

Ну, ты просто крут и этим все объясняется. А то что ваши продукты не заткнули всех конкурентов — так это происки врагов.

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

V>В общем, о чем я хотел сказать — что ты не правильно акценты расставляешь. Несомненно, дотнет — удобный фреймворк, но ты тут выставляешь на первый план явно незначащие аргументы.

Да, совершенно не значимый. Типобезопасность это сказка и блеф. А фрэймворк удобный по каким-то загадочным причинам. Ну, а то что МС и Сан выпячивают эту типобезопасность на передний план, так это рекламная шумиха.

V>Я согласен лишь с тем, что при наличии ошибок дотнет помогает изолировать их от общего процесса (в серверах). Но он практически никак не помогает эти ошибки не делать (3% — это абсолютно несущественно).

Сдается мне, что твои 3% высасаны из пальца.

V> Повторю так же мысль о том, что нам гораздо больше помогает тонна прикладного функционала, который не надо писать, а значит не надо делать свои ошибки.

А ты не задумывался над тем, почему эта тонна написана на C#, а не на С++ и не оформлена в виде С++-ных файлов или библиотек?

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

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

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

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

Просто ребята из МС взяли и реализовали в одном продукте те передовые идеи которые они смогли заметить. А ты пыташся свалить все на банальный объем библиотек, путая причину со следствием. Типа, ветер дует от того что деревья качаются.

V>Нет. Ты же говорил про опции unsafe?

Я говорил про безопасный код. Код сгенерированный Emit-ом не гарантированно безопасен.

V>А какого хрена TypeBuilder позволил нагенерить несовместимые инструкции???

Несовместимые с чем? Он позволяет сгенерировать любой msil-код. В том числе и небезопасный. Что видимо и произошло.

V> (код был не безопасный, он был принципиально неккоректный — в фомирование команд, предназначенных для классов, я подал тип структуры, и это никак не проверилось)

Что значит "я подал". Безопасный значит типобезопасный! В таком коде просто не должно быть возможности подсунуть один тип вместо другого. Код обяазан быть рассчитанн на определенные типы. Ну, нельзя подсунуть структуру туда где ожидается ссылка на класс. А если это можно, то код автоматически не типобезопасный.

VD>>И разницы с плюсовыми программами не видишь? Ну, тут говорить не о чем. Опровергать оспаривание очевидного работа не для меня.

V>О, опять ты про "очевидное". Ну я тебе в ответ напоминаю про реальную стоимость твоего "очевидного" — 3%.

А я о высосаности этого процента из пальца.

V>Если ты рисуешь неправильно контрол, или у тебя логика в цикле пропускает последний/первый элемент, и т.д. и т.п. То результат будет одинаков, независимо от среды. Мне уже интересно, что у тебя там произошло с плюсами, что ты настойчиво повторяешь одно и то же? Ну не существенно это.

Не факт что одинаков. Очень велика возможность того, что ошибка логическая превратится в ошибку при работе с типами. И если язык и рантайм рассчитан на контроль подобных ошибок, то она будет найдена, а если нет, то велика вероятность получить ошибки второго и т.д. порядка. Неверный рассчет привел к невреному индексу, невреный индекс к порче памяти, та к случаным действиям, а те к вылету приложения. Далее следуют бессонные ночи в поиске истинной ошибки. Если ошибка ловится верификаторами, то хорошо, а если они не были заточены на нее, то приплыли. Если же контрольк встроен в язык, то ты создаещь всю нужную аннотацию чтобы компилятор или рантайм автоматически поймали эту ошибку и предотвратили повышение ее уровня.

V>Кстати, а в плане рисования тех же контролов. Несмотря на то, что объектная модель и GDI+ более удобен, чем вынь-апи, я наблюдая гораздо больше ошибок и неккоректностей в реализайии контролов на C#. (Просмотри форум .Net GUI). Как ты подобну странность прокоментируешь???

А я как раз вижу только уменьшение количества ошибок и их проблематичности при использовании GDI+. Это очередное твое голословное утвержедение. Хотя тут язык в общем-то не причем. GDI+ — это С-шная библиотека. Просто она спроектирована в очень похожих на дотнет манере и заточена на паттерны работы с ресурсами используемые в дотнете.

V>Да про серверные понятно. Я же уже говорил, что не согласен с тем, что дотнет помогает делать меньше ошибок. Он их может помочь хоть как-то изолировать, в тех же серверах.

Очередной спор с очевидным. Да еще и загадочные фразы вроде "как-то изолировать".

Типобезопасность и есть та самая изоляция. Типобезопасные объекты не могут воздействать на другие объекты случайно.

V>>>В дотнете тоже нет. Там контроль на уровне компилятора.

VD>>Сможешь доказать это утверждение?

V>В смысле, сгенерить через TypeBuilder метод с переменной в стеке, например int, и вывести ее значение в Console без предварительного присвоения? Самому не смешно?

С локальными переменными я не прав. Однако первое же требование к безопсному коду — это полная инициализированность. Так что код порожденный компилятором не инициализирующим стековую переменную не будет проходить верификацию и не бует типобезопасным.

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

V>Если у меня в C# переменная объявлена как член класса, то ее инициализацию даже компилятор не проверяет. Разве что Решарпер.

Если переменная член класса, то она инициализируется нулевыми значениями еще при выделении памяти из хипа.

V>Как это память не портится при многопоточности. Именно в этом ошибки и проявляются. (Например, пишем в буфер что-то).

Так. У тебя может быть случай двойной записи в один объект, но никогда не будет случайной записи в произвольный объект (область памяти).

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

V>На функциональных языках нелегко делать числодробилки. А любой бизнес-приложение, где есть хоть какая-то отчетность или промежуточная статистика того требуют.

Все с точносью до наоборот. Для рассчетов ФЯ подходят изумительно. Они же из математики свои корни берут. Не даром половина примеров в ФЯ — это вычислительная математика.

Ну и, функциональный код еще более безопасен чем даже управляемый императивный, так как он не имеет побочных эффектов и не модифицирует переменные. Собственно похоже, что ФЯ единственные из известных языков дотигли полной статической типобзопасности.

VD>>Ясно опять пустые слова. Показать ты никаких приемуществ не можешь. Оно и понятно. Не может иметь приемуществ нетипобезопасный язык над типобезопасным.

V>По-моему все сказал.

А ты покажи. Что языком то трепать? Ты "Покажи, плиз приемущества статической типизации в С++ в необобщенном коде." на примере. Ну, создай не обобщенный код который будет типобезопасным на С++ и который нельзя будет сделать типобезопасным на C#.


V>>>Прекрасный совет, спасибо. Но все же, бизнес-сущность — это самодостаточная единица, данная сверху. И ей наплевать на все паттерны а даже (о ужас) на ООП. На этих паттернах и ООП я могу лишь обвеску вокруг этой сущности соорудить, не более. Но саму ее аннулировать, извини, не получается. Вместе с ней аннулируется задача (есть такой побочный эффект)

VD>>Аннулировать? Ты о чем? ООП для проектирования нужно применять, и для замены кривых прямолинейных решений.

V>Я вот не пойму о чем ты.

Это я не понимаю. Что все же значит "ее аннулировать"?

V> Ты экстрасенс, способен выдавать решения не видя постановки? Могу прислать на мыло небольшую часть постановки, а ты нам попытаешься количество сущностей уменьшить вдвое, ok?

ОК. Заплатите денег — сделаю.

V>>> Я уже ручками давно все сделал, просто показал явное место, где у нас куча динамических приведений. И это явно не на пользу эффективности.

VD>>За-то я знаю что кучи приведений говорит о качестве проектирования.

V>Это говорит о невозможности обощенного программирования в среде, которую используем прямо сейчас для коммерческих проектов.

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

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

VD>Я сейчас пишу статью про редактор кода написанный на шарпе, так вот в процессе ее написания я вылетел такое количество раз, что в какой-то момент я плюнул на ворд, написал для своего редактора автозамену (так как эта фича ворда мне нужна больше всего) и продолжил писать статью в своем редакторе. Причем сделал это я точно зная, что в редакторе есть ошибка приводящая к вызоду за границу массива! Я не сколько не испугался этого (смертельного для программ написанных на С++) глюка, так как максим что может произойти — вылетит диалог с сообщением об ошибке. Нажав "Continue" я спокойно продолжу работу.
Значит у нас с тобой разные паттерны использования ворда. Мой 2003 конечно падает, но ооочень редко. И с ревиженами он у нас отлично работал (правда, на объемах в пределах 50 страниц). Тока тормозил. А вот ошибок алгоритмического рода в нем великое множество.

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

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

V>>Попробуй в дотнете получить произвольный интерфейс у удаленного объекта, если явно не описано, что он этот интерфейс поддерживает.

AVK>Чего то не понял о чем ты. Объект либо реализует интерфейс, либо не реализует. Что такое "явно описано"?

Например, на клиенте известен некий тип (наследник MBR), поддерживающий некий интерфейс, и клиент запрашивает этот объект по удаленному URI. На сервере реально сидит очередной его наследник, имплеиментирующий так же и другие интерфейсы, но этот тип наследника неизвестен на клиенте. Как их запросить на клиенте те другие интерфейсы?

V>>- компиляторы -> С++ (на машине с Resharper у меня две студии просто входят в ступор при обычной работе, с VA такого не было)

AVK>А у меня не входят даже 4. Что я делаю не так?

А у тебя гиг или больше памяти или проекты небольшие.

V>>- "продвинутые" текстовые редакторы -> С++

AVK>Почему?

V>>- серверные приложения, предназначенные для переливки и обработки больших объемов данных (напр. CVS сервер) -> C++

AVK>Почему?

Оба ответа — из-за потребляемой памяти. Экономнее, чем в С++, вряд ли удасться обойтись с этим ресурсом.

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

V>Да, там достаточно логики, т.к. иногда вызывается внутрення команда протокола у удаленного серверного объекта, этот метод протокола — "_is_a()", и позволяет получить другой интерфес объекта. Кстати, в CORBA этот момент проработан немного лучше, чем в .Net Remoting. Попробуй в дотнете получить произвольный интерфейс у удаленного объекта, если явно не описано, что он этот интерфейс поддерживает. А ведь вполне используемая техника (Interface1 -> Interface2) в локальных задачах, по крайней мере регулярно наблюдаю в коде на .Net.

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

V>Если пошло такое оценивание, то я бы был более скурпулезен:

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

V>- вычисления -> C++

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

V>- компиляторы -> С++ (на машине с Resharper у меня две студии просто входят в ступор при обычной работе, с VA такого не было)

Хм. А у меня последние версии Resharper работают изумительно. И от количества студий вообще не зависят. Может у тебя просто с памятью проблемы? Что до VA — это это изумительный пример превосходства кода написанного на дотнете над родным. VA супротив Resharper просто полное ничтожество.

Безосновательность этого утверждения так же подтверждается тем, что R# и компилятор Моно написаны на чистом C#. При этом особых проблем не заметно. А вот удобство видно сразу. АСТ на C# просто иделно в отличии от плюсового.

V>- "продвинутые" текстовые редакторы -> С++

Это типа Синтилы и редатора VS? Спешу тебя огорчить. Я как раз тут по случаю один написал. Особых пролем не заметил. Наоборот получилось намного проще.

V>- редакторы графики -> С++

Опять же есть реализации на C# и опять же не вдино неприодалимых трудностей.

V>- САПР-ы -> С++

А здесь, то что?

V>- движки БД -> С++

Движки БД даже на Яве есть. А уж на шарпе, на котором ОС делать пытаются и подавно это осуществимо.

V>- движки 3D (не роперы, типа Managed DirectX, а именно движки) -> C+

3D-движки работают поверх DirectX или OpenGL. И есть не одна реализация менеджед-движка. Некоторые по проивзодительности обходят родителей.

V>- сетевые протоколы и фильтры -> С++

Для каких ОС? Есл для написанных на С, то конечно. Если для какой-нить Сингулярити, то однозначно нет.

V>- маааленькие GUI приложения/утилитки -> все-таки С++, из-за того, что дотнетные приложения стартуют довольно долго независимо от размера, а маленькие GUI приложения на С++ — мгновенно.

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

V>- серверные приложения, предназначенные для переливки и обработки больших объемов данных (напр. CVS сервер) -> C++

У нас на сервере бэкапы дифятся программкой написанной на C# первой версии. Объем БД под 4 гига. И ничего справляется. Сайт весь на C# и перекачивает десятки гиг в день отвечая на запросы 15 тысяч пользователей. И при этом CVS на дотнете написат нельзя. Не уж-то исходники такие огромные? Ну, не поверю я в команду программистов состоящую из 15 000 человек комитящую исходники по 400 штук за раз.

V>- моделирование объемных вещей (например, волнений моря или аэродинамика) -> C++

Тут то что за проблемы? Оптимизатор? Тогда см. выше.

V>- для маленьких моделей допустим .Net , например, промоделировать картину общего доступа к радиоточкам при количестве абонентов не более нескольких тысяч, если речь о многих миллионах, то я бы не рискнул выбрать .Net в качестве платформы.

В общем, попытайся обосновать хотя эти свои утверждения. Лично для меня они выглядят смехотворно.

Мой список задач не для дотнета:
1. Код создаваемый для систем где проблематично встраивание CLR (например, встраеваемые системы написанные на С).
2. Создание модулей расширения ОС написанных на неуправляемых языках (драйверы, перехватчики клавиатурных нажатий и т.п.).
3. Системы рельного времени (и то до тех пор пока не создан RTS-CLR).
4. Мелкие утилиты предназначенные для скачивания через слабые Интернет-каналы. И то до тех пор пока фрэймворк не расползется на все машины. Полсе того как Лонгхорн стане основной ОС и этот фактор уйдет в прошлое. Даже на поборот, дотнетные модули будут существнно меньше по объему.
5. Применение при разработке ПО опасного для жизни и здоровья людей. Ну, это потому что фрэймворк от МС на С++ частично написан. Если какая нибудь Сингулярити дойдет до релиза и в ней реализуют RTS-CLR, то и это будет возможно. (мечты-мечты). Однако этот пункт для С++-программ принципиально должен быть закрыт.

V>>> Просто эти платформы корчуют "новые" рынки (распределенные приложения, например), и теснят всякие Дельфи и ActiveX с территории GUI.

V>По моим наблюдениям Java и дотнет гораздо более теснят весь остальной рынок: Дельфи, PHP/Perl и кучу другой всякой экзотики.
V>По сути, в живых остается Java, .Net и С++. Меж ними и раздел.

О! Ты уже сам с собой споришь. Кстати, ActiveX-рынок — это С++-рынок. Еще немгого и С++ на рынке ПО для бизнеса будет нонсоном. Глядишь через 10 лет останутся только низкоуровневые феньки для ОС. Даже расширения ОС будут на дотнете, так как в Лонгхорне пол Эксплорера на нем.

V>Насколько я знаю, в основном плагины под него глючат. Но не в этом суть.

Ну, если ревижены — это плагины, то возможно. Меня вот этот режим больше всего напрягает.

V> Какой объем памяти потребует ворд для документа объемом > 2M, хотя бы???

Предположим даже 100 метров. Мне плевать. У меня ее гиг. 10% я переживу. А 2 метра — это очень большой документ.

V>Т.е., пока не все так гладко, как хотелось бы.

Вот тут нельзя не согласиться. До золотых гор еще далеко. Ворд похоже еще долго будет глючить. Но прогресс на лицо.

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

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

V>>Повторяю опять — в функцию передаем адрес буфера, куда данные возвращаются (из этой ф-ии). Подойдет любой пример.

VD>Повторюсь, еще раз. Код в студию! И не нужно вешать лапшу на уши.

Просто облом было писать эти 2 строки, неужели непонятно выразился???

держи:

p2.cpp

#include "stdafx.h"
BOOL APIENTRY DllMain( HANDLE hModule, 
                       DWORD  ul_reason_for_call, 
                       LPVOID lpReserved
                     )
{
    return TRUE;
}

__declspec(dllexport)
int __stdcall f1(wchar_t *str) {
    static wchar_t str1[] = L"HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!"
        L"HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!"
        L"HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!"
        L"HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!"
        L"HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!";

    memcpy(str, str1, sizeof(str1));

    return sizeof(str1)/sizeof(wchar_t);
}

f1() — возвращает данные в буфер, аналогично работают все API-функции связанные с глобализацией. (возвращают форматы, строки и т.д.)

p2.def

EXPORTS
f1

(это чтобы подавить name-mangling)

C#

    class Class1
    {
        static void Main(string[] args)
        {
            string s;
            f1(out s);
            Console.WriteLine(s.ToString());
        }

        [DllImport("p2", CallingConvention = CallingConvention.Cdecl)]
        static extern int f1(out string sb);
    }

До команды Console.WriteLine(s.ToString()); программа не доходит. Приложение молча схлопывается без единого сообщения об ошибке.

Я получал еще более интересные эффекты пару лет назад (ну нет ТОГО кода, он давно исправлен и работает). Так вот эффект заключался в том, что у меня в строке был мусор ооочень большой длины. Не иначе как проход по памяти, откуда взяться мусору длиной в несколько килобайт, если АПИ ф-ии глобализации возвращают самое длинное слово "Понедельник".

V>>Кто сказал, что мне нужен только вынь-апи?

VD>Ну, мне так ничего больше и не нужно. Но если тебе нужно, то приведи пример.

Z-lib, да и вообще, интероп он именно интероп — взаимодействие с унаследованным кодом, а не с вынь-апи. Они предполагали, что с ней, родимой, как раз возится и не надо — фреймворк по идее на себя все взять должен был.

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

Что-то логика отсутствует.

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

V>>Я не понял смысла туманной фразы "с ручной возней с типами в С++". Если сигнатуры типизированы (без всяких void*), то возни нет в принципе.

VD>И как ты хочешь вызвать АПИ типизированно? А уж при возне с разными handle-ами о типизации и речи быть не может.

Windows.h в опцией STRICT дает именно типизированное АПИ, т.е. хендлы именно типизированы, перепутать невозможно без явного обхода защиты.

VD>Даже при возне с КОМ-ом типизация то и дело идет лесом. Тут и там появляется код живущий на предположениях о совпадении типов.

Бинарная сериализация тоже исходит из предположения о совпадении типов. COM работает из предположения, что контракт на интерфейс соблюдается всеми сторонами. Что не так? (Более того, однажды введенный интерфейс не подлежит модернизации)

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

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

VD>В общем, кончай сотрясать воздух и попробуй поэксперементировать с интеропом. Уверяю тебя ждет немало интересного.

Я уже прошел через немало интересного. Чем вызвано твое недоверие к сообщениям коллег — непонятно.


V>>Хорошо. Реальная статистика.

VD>Где?

В предыдущем посте.

V>>Продолжая озвучивать свой опыт скажу, что отлов тех 15 ошибок, приводящих к крэшу — весьма легок. Лично я нахожу их мгновенно. Ну сразу в глаза бросаются места, где может быть ошибка. А вот ошибки логики приходится "пилить" порой долго и нудно. Тут затрачиваемый объем усилий совершенно несравним.

VD>Ну, ты просто крут и этим все объясняется. А то что ваши продукты не заткнули всех конкурентов — так это происки врагов.

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

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

Ну и пусть они выпячивают, тебе-то чего? Тебе за рекламу платят?

Существует мнение, что программ без ошибок не бывает. Далее, я привел тебе РЕАЛЬНУЮ статистику распределений ошибок немаленького проекта, где участвовал весьма разношерстный коллектив в плане скилов. Ты продолжаешь брыкаться и все отрицать совершенно беспричинно.

V>>Я согласен лишь с тем, что при наличии ошибок дотнет помогает изолировать их от общего процесса (в серверах). Но он практически никак не помогает эти ошибки не делать (3% — это абсолютно несущественно).

VD>Сдается мне, что твои 3% высасаны из пальца.

Надо писать так: высосаны.
И желательно по другому поводу. Корректней тебе было бы сказать: "меня твоя статистика не устраивает".

V>> Повторю так же мысль о том, что нам гораздо больше помогает тонна прикладного функционала, который не надо писать, а значит не надо делать свои ошибки.

VD>А ты не задумывался над тем, почему эта тонна написана на C#, а не на С++ и не оформлена в виде С++-ных файлов или библиотек?

Блин, ну в рефлектор загляни, а??? Как ни интересный момент — так ф-ия с внутренней линковкой. А на чем написаны остальные A+B это вообще не важно. Учитывая, что C# от VB.Net недалеко ушел, то я и говорить не стану, почему...

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

Все да не все. Встали новые задачи и они потребовали поддержки рантаймом и средой исполнения. (Рефлексия, тут же сериализация-ремоутинг + компонентность). Есть класс задач, где это весьма востребовано.

К тому же, не забывай про настпление Java и метод "ответных ходов".

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

VD>То что мои аргументы тебя не удовлетворяют еще ничего не означает. Твои аргументы удовлетворяют в основном ярых адептов С++. Так что это просто разные точки зрения.

Мои аргументы — реальная статистика. А твои — лишь личные ощущения. Я вообще ввязался в ветку с целью хоть как-то уравновесить твои огульные высказывания и попытаться расставить акценты более правильно.

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

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

VD>Просто ребята из МС взяли и реализовали в одном продукте те передовые идеи которые они смогли заметить. А ты пыташся свалить все на банальный объем библиотек, путая причину со следствием. Типа, ветер дует от того что деревья качаются.

Мдааа... Идеи ради идей... приплыли.
Этот аспект не продвигает даже сама Microsoft. Они как раз прикладную платформу с тонной функционала и двигают. Или, по твоему, можно двигать голые идеи сейчас, когда есть мегатонны унаследованного кода.

Только предоставив готовую реализацию многого из того самого унаследованного кода, можно пытаться хоть как-то это двигать.

И про язык C# они говорят вполне скромно — mainstream for .Net. А в самом дотнете более выделяют его потенциальную роль как связующего элемента для проектов на различных языках и его возможность быстро строить сложные приложения, ввиду мощной поддержки фреймворком.

V>> (код был не безопасный, он был принципиально неккоректный — в фомирование команд, предназначенных для классов, я подал тип структуры, и это никак не проверилось)

VD>Что значит "я подал". Безопасный значит типобезопасный! В таком коде просто не должно быть возможности подсунуть один тип вместо другого. Код обяазан быть рассчитанн на определенные типы. Ну, нельзя подсунуть структуру туда где ожидается ссылка на класс. А если это можно, то код автоматически не типобезопасный.

Я имел ввиду тот факт, что генерирование неверной IL-команды могло быть предотвращено самим TypeBulder-ом (MethodBuilder-ом), если бы потщательнее подошли к вопросу.

VD>>>И разницы с плюсовыми программами не видишь? Ну, тут говорить не о чем. Опровергать оспаривание очевидного работа не для меня.

V>>О, опять ты про "очевидное". Ну я тебе в ответ напоминаю про реальную стоимость твоего "очевидного" — 3%.

VD>А я о высосаности этого процента из пальца.

Правильно писать так: высосанности.

V>>Если ты рисуешь неправильно контрол, или у тебя логика в цикле пропускает последний/первый элемент, и т.д. и т.п. То результат будет одинаков, независимо от среды. Мне уже интересно, что у тебя там произошло с плюсами, что ты настойчиво повторяешь одно и то же? Ну не существенно это.

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

Ладно, это лирика все. Если у тебя операция записи зависит от расчитанного индекса, то используй контейнер с проверкой диапазонов.

VD>Далее следуют бессонные ночи в поиске истинной ошибки. Если ошибка ловится верификаторами, то хорошо, а если они не были заточены на нее, то приплыли.

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

V>>Кстати, а в плане рисования тех же контролов. Несмотря на то, что объектная модель и GDI+ более удобен, чем вынь-апи, я наблюдая гораздо больше ошибок и неккоректностей в реализайии контролов на C#. (Просмотри форум .Net GUI). Как ты подобну странность прокоментируешь???

VD>А я как раз вижу только уменьшение количества ошибок и их проблематичности при использовании GDI+. Это очередное твое голословное утвержедение. Хотя тут язык в общем-то не причем. GDI+ — это С-шная библиотека. Просто она спроектирована в очень похожих на дотнет манере и заточена на паттерны работы с ресурсами используемые в дотнете.

Ты не понял. Я просил тебя просмотреть топик .Net GUI и оценить общий уровень контролописательства сейчас. (несмотря на более удобную объектную модель контрола и GDI+ как листа для рисования). Когда я только познакомился с дотнетом, то воспринял задачу написания контролов в этой среде как разновидность развлечения (настолько это было проще чем в вынь АПИ и даже в MFC/ATL).

Так что же не так, а? Почему так туго-то?

А может быть, С++ дает (вернее — требует, а оттого и дает) больше понимания в сути происходящих вещей?

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

Кстати, я более чем уверен, что посади тебя после дотнета опять на С++ (ну мало ли, вообразим ситуацию, что тебе за это стали платить $100к в месяц), то ты будешь писать совсем не так, как раньше (до дотнета). И ты будешь искать способы писать безопасный софт и найдешь их, никуда не денешься.

V>>Да про серверные понятно. Я же уже говорил, что не согласен с тем, что дотнет помогает делать меньше ошибок. Он их может помочь хоть как-то изолировать, в тех же серверах.

VD>Очередной спор с очевидным. Да еще и загадочные фразы вроде "как-то изолировать".

Что тут загадочного? Логические ошибки могут портить общие данные, например.

VD>Типобезопасность и есть та самая изоляция. Типобезопасные объекты не могут воздействать на другие объекты случайно.

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

VD>С локальными переменными я не прав. Однако первое же требование к безопсному коду — это полная инициализированность. Так что код порожденный компилятором не инициализирующим стековую переменную не будет проходить верификацию и не бует типобезопасным.

Хммм. посмотрим

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

Если неважно кто обеспечивает типобезопасность, то мне VC7.1 достаточно

V>>Если у меня в C# переменная объявлена как член класса, то ее инициализацию даже компилятор не проверяет. Разве что Решарпер.

VD>Если переменная член класса, то она инициализируется нулевыми значениями еще при выделении памяти из хипа.

В С++ аналогично.

V>>На функциональных языках нелегко делать числодробилки. А любой бизнес-приложение, где есть хоть какая-то отчетность или промежуточная статистика того требуют.

VD>Все с точносью до наоборот. Для рассчетов ФЯ подходят изумительно. Они же из математики свои корни берут. Не даром половина примеров в ФЯ — это вычислительная математика.

Я имел ввиду Лисп, когда писал это. Не подходит он для числодробилок из-за своего быстродействия. Пролог аналогично.


VD>А ты покажи. Что языком то трепать? Ты "Покажи, плиз приемущества статической типизации в С++ в необобщенном коде." на примере. Ну, создай не обобщенный код который будет типобезопасным на С++ и который нельзя будет сделать типобезопасным на C#.

Ага, кажется я понял, где тебя зацепило. Слово необобщенный - лишнее, я это не имел ввиду, иначе речь у нас шла бы не о С++. Позволь, все-таки, говорить об обощенном коде и о том, где я вижу бенефиты С++ даже по сравнению с C# 2.0.

Тут регулярно говорят о всяких DSL. Так вот, как я себе представляю "правильное" решение задач ср-вами С++:
— определение абстракций прикладной области
— определение операций над абстракциями
— выражение операций доступными операторами языка
— написание прикладной логики в терминах введенных типов и операций над ними.

Например, у нас стоит задача эмулировать нечто из фиизики. Я могу вводить обощенные типы-заместители элементарным типам, которые не отберут ни тика в runtime. Затем вводить более конкретные типы, например Velocity, Mass, Time и т.д.

Затем могу переопределять глобальные операторы так, чтобы Time * Velocity возвращала тип Distance. Суть понятна?

Это один из примеров, показывающих бенефиты статической типизации. Я не смогу без "хаков" написать семантически неккоректные физические формулы и не смогу сохранить результат "не там".

Могу я аналогичное сделать на C#? — НЕТ!!!
Насчет обобщенных вычислений и value-типов там какая-то непродуманность. Мне придется многое копипейстить ручками, чтобы получить "нормальный" синтаксис.

А в С++ я один раз опишу тип, например:

template<typename numberT, typename uniqT>
struct number_wrapper {
// тут операции
};

Затем сделаю что-то типа такого:

struct Kind{ struct Time{}; struct Velocity {}; }

typedef number_wrapper<double, Kind::Time> Time;
typedef number_wrapper<double, Kind::Velocity> Velocity;

inline Distance operator*(const Time& t, const Velocity& v) 
{ return Distance(t.value * v.value); }

(последнюю ф-ию можно сделать шаблонной, не стал писать лишнее, хочу показать суть)

V>> Ты экстрасенс, способен выдавать решения не видя постановки? Могу прислать на мыло небольшую часть постановки, а ты нам попытаешься количество сущностей уменьшить вдвое, ok?

VD>ОК. Заплатите денег — сделаю.

Уверен, что уменьшишь?

V>>Это говорит о невозможности обощенного программирования в среде, которую используем прямо сейчас для коммерческих проектов.

VD>Всегда можно найти приемлемое решение. Выкладывай примеры... поглядим.

Пример простой.

Есть сами бизнес-объекты. Есть сущность фабрика-дескриптор-хранилище для него. CRUD выполнен в базовом классе этих фабрик в общем виде (у нас есть генераторы запросов SQL под различные диалекты из объектной модели запроса, которая строится по структуре типа и .т.д и т.п.).

Я не хочу в коде приводить результаты/агрументы методов фабрик и десткрипторов к конкретному типу бизнес-объекта, т.е. нужны типизированные методы — обертки. Про них речь и шла.

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

V>Например, на клиенте известен некий тип (наследник MBR), поддерживающий некий интерфейс, и клиент запрашивает этот объект по удаленному URI. На сервере реально сидит очередной его наследник, имплеиментирующий так же и другие интерфейсы, но этот тип наследника неизвестен на клиенте. Как их запросить на клиенте те другие интерфейсы?

А в чем проблема? В ObjRef передаются все публичные интерфейсы, которые реализует объект. Следовательно если локально эти интерфейсы доступны, то и приведение к ним работает. Если же хочется каких то извращений, то можно отказаться от стандартной механики и формировать сообщения собственным способом. Только вот непонятно зачем это может понадобиться. Я конечно не сторонник SOA, но мысль о том, что не стоит слишком уж сильно равнять локальные и удаленные вызовы вполне здравая.

AVK>>А у меня не входят даже 4. Что я делаю не так?

V>А у тебя гиг или больше памяти

Гиг. А у тебя что, меньше?

V> или проекты небольшие.

17 мег исходников в 3.5К файлов. Достаточно?

V>>>- "продвинутые" текстовые редакторы -> С++

AVK>>Почему?

V>>>- серверные приложения, предназначенные для переливки и обработки больших объемов данных (напр. CVS сервер) -> C++

AVK>>Почему?

V>Оба ответа — из-за потребляемой памяти. Экономнее, чем в С++, вряд ли удасться обойтись с этим ресурсом.

А оно надо? Мне лично от экономии пары мег оперативки ни холодно ни жарко.

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

VD>Несовместимые с чем? Он позволяет сгенерировать любой msil-код. В том числе и небезопасный. Что видимо и произошло.

Да не, небезопасный бог бы с ним. Он позволяет сгенерировать код невалидный (к примеру позвать приватный метод извне напрямую, без рефлекшена). А попытка выполнить невалидный код приводит к тому что JIT выкидывает тот самый ужасный ExecutionEngineException.