Здравствуйте, WolfHound, Вы писали:
WH>Вот взять хотябы R# на сколько я знаю ты рание не имел дела с компиляторами но смог создать C# фронтенд соответствующий стандарту.
Ничего подобного там нет, там только парсер с зачатками ресолвинга имен. Единственная альтернативная реализация шарпа — моновская, содержит ошибки, в том числе и в парсинге.
Здравствуйте, degor, Вы писали:
SYG>>тот же Windows с Unix-ом не модульные и ничего вроде, нормально работают. D>Вот только не надо валить в одну кучу современные Windows системы и технологию тридцатилетней давности.
О-о-о! Оценил. Уважаю.
По поводу COM-ов:
Я сказал что Windows не модульная система и еще сказал что под Windows нельзя писать модульные программы. Вы удивились и спросили, а как же тогда COM? Не беспокойтесь, все очень просто. Дело в том что среда Win32 и среда COM — разные вещи. Среда COM существует поверх среды Win32, точно также как среда BlackBox от Oberon Microsystems тоже существует поверх среды Win32.
Кстати, под названием COM можно даже понимать ее последнюю версию COM3, которая носит гордое название ".NET".
Цитата:
"Среда CLR применяется в качестве первичного загрузчика кода вместо команды CoCreateInstance среды COM или команды LoadLibrary среды Win32"
Основы платформы .NET, Том 1, Общеязыковая исполняющая среда, Д. Бокс, К Селлз.
SYG>>>Единственным выходом из этой ситуации является наличие единого на всю операционную систему полноценного сборщика мусора. Сборщик мусора — это не роскошь, и не фича придуманная для ленивых программистов. Сборщик мусора — это осознанная необходимость. Существование многомодульныех систем, модули которых обмениваются друг с другом объектами, невозможно без одного на всех полноценного сборщика мусора.
D>Не понял, откуда это следует.
На примерах чтоли объяснять?
Пусть есть три модуля:
MODULE M0;
TYPE
T0* = POINTER TO ABSTRACT RECORD
Value*: T1;
Next* : T0;
END;
T1* = POINTER TO ABSTRACT RECORD
Value*: T0;
Next* : T1;
END;
END M0.
MODULE M0T0;
IMPORT M0;
PROCEDURE Create*(): M0.T0;
END M0T0.
MODULE M0T1;
IMPORT M0;
PROCEDURE Create*(): M0.T1;
END M0T1.
Модули M0T0 и M0T1 создают объекты и отдают их каким угодно другим модулям, те отдают третьим, те четвертым и т.д. Кто должен заботится об уничтожении более не нужных объектов? Разумеется сборщик мусора, потому что счетчик ссылок в общем случае не сработает
VAR t0: M0.T0;
t1: M0.T1;
BEGIN
t0 := M0T0.Create();
t1 := M0T1.Create();
(* А теперь запутаем ссылки друг на друга: *)
t0.Next := t0;
t0.Value := t1;
t1.Next := t1;
t1.Value := t0;
(* Сборщик мусора это запутывание вмиг распутает, а вот счетчики ссылок - будут отдыхать *)END;
Здравствуйте, VladD2, Вы писали:
SYG> На обычном С++ модульные программы писать невозможно. VD>Ну, ну, так уж не невозможно.
Приношу свои извинения. Эту мою фразу прошу понимать так: "Язык С++ не поддерживает модульное программирование, и компонентно ориентированную парадигму программирования тоже не поддерживает".
VD>Тяжело — да. Но КОМ пока никто не отменял.
Здравствуйте, WolfHound, Вы писали:
WH>Вот взять хотябы R# на сколько я знаю ты рание не имел дела с компиляторами но смог создать C# фронтенд соответствующий стандарту. А теперь давай вспомним про то что не существует ни одного С++ фронтенда соответствующего стандарту. Даже в EDG ошибки находят и микрософт со своими миллиардами не может довести VC++ до стандарта.
Дык это только говорит, о непродуманности стандарта. И о том, что он не во всем отвечае рельным потребностям.
А потом, если очень приспичило бы, то создали бы и для С++ граматику. Граматика как раз там плевая.
WH>Короче твои заявления о том что C# сложнее С++ до того как ты напишешь С++ фронтенд полностью соответствующий стандарту идут лесом.
А мне сдается, что твое условия идут лесом.
Граматику С++ я хорошо изучил. Нет там ничего сложного. Вот в разрешении имен там каша. А граматика простая.
VD>>3. Разумно говорить о недостатках и приемуществах, а не о тотальном превосходстве. Все же работать с БД на С++ — это такой же мазохизм, как пытаться писать драйверы на Шарпе. WH>Вот с этим в принципе согласен. Хотя работать с БД на плюсах не такой уж и мазахизм.
Да, такой. За то время пока ты на плюсах будешь все МС-ные кракозябры от КОМ-объектов разбирать, я на шарпе уже приложение допишу. А R# доведем до ума, и во многих других областях смысла в плюсах не будет.
ЗЫ
Ты кстати, подмогнеш нам на поприще языкостроения или уже передумал?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
SYG>По поводу COM-ов: SYG>Я сказал что Windows не модульная система и еще сказал что под Windows нельзя писать модульные программы. SYG>Вы удивились и спросили, а как же тогда COM? Не беспокойтесь, все очень просто. Дело в том что среда Win32 и среда COM — разные вещи. Среда COM существует поверх среды Win32, точно также как среда BlackBox от Oberon Microsystems тоже существует поверх среды Win32.
OK. Будем понимать под Windows не только ядро системы, но и COM. На COMе нельзя делать модульные программы? COM нельзя использовать в С++? COM, да и Windows вообще имеет какое-то отношение к языкам программирования?
SYG>Кстати, под названием COM можно даже понимать ее последнюю версию COM3, которая носит гордое название ".NET".
Нельзя.
SYG>Цитата: SYG>"Среда CLR применяется в качестве первичного загрузчика кода вместо команды CoCreateInstance среды COM или команды LoadLibrary среды Win32" SYG>Основы платформы .NET, Том 1, Общеязыковая исполняющая среда, Д. Бокс, К Селлз.
Написали два чувака глупость. Теперь все будем повторять?
Вы бы тоже признались, что сморозили глупость и дело с концом.
SYG>>>>Единственным выходом из этой ситуации является наличие единого на всю операционную систему полноценного сборщика мусора. Сборщик мусора — это не роскошь, и не фича придуманная для ленивых программистов. Сборщик мусора — это осознанная необходимость. Существование многомодульныех систем, модули которых обмениваются друг с другом объектами, невозможно без одного на всех полноценного сборщика мусора.
D>>Не понял, откуда это следует.
SYG>На примерах чтоли объяснять?
Такое сильное заявлений хорошо бы поддержать чем-то более серьезным (академичным, я б сказал ).
Примеров не надо — я циклические зависимости разрываю силой воли. К тому же надуманный пример с циклическими ссылками не опровергает тезиса о возможности программирования _без_ создания циклических ссылок.
Здравствуйте, degor, Вы писали:
D>К тому же надуманный пример с циклическими ссылками не опровергает тезиса о возможности программирования _без_ создания циклических ссылок.
Правильно, зачем нам в программировании нужны циклические ссылки. Да нам даже и не циклические не нужны. Можно вообще без ссылок программировать...
SELECT object WHERE (name = 'MyObject') AND (year = 2004) AND ...
Здравствуйте, Ael, Вы писали:
Ael>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.
Ael>Спасибо!
Одно — и иногда (в редких случаях) довольно сущесвенное — это возможность выполнения произвольного кода и работа с железои на прямую, что существенно при написании некоторых драйверов и специфического софта. Так же это может пригодиться для написания специфических библиотек для обработки видео, например, или математических расчётов (быстрого фурье преобразования и т.п.).
В остальных случаях, как мне кажется, удобнее и выгоднее использовать управляемый код.
Здравствуйте, VladD2, Вы писали:
VD>Граматику С++ я хорошо изучил. Нет там ничего сложного. Вот в разрешении имен там каша. А граматика простая. Re[4]: Граматика С++
Ну хорошо. Я согласен с новой формулировкой заяввления о C++ и модульном программировании. C++ позволяет делать несовместимые с ним вещи, но писать на С++ модульные программы можно, выполняя определенные правила.
Так и COM является компонентной системой, работоспособность которой поддерживается не внутренними средствами, а набором правил, одно из которых — запрет циклических ссылок.
Да, если система не желает полагаться на выполнение правил разработчиками компонентов, единственным средством контролировать время жизни объектов остается общесистемный GC.
А циклические/перекрестные ссылки все-таки зло. И в системах c GC с ними можно огрести проблем.
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Я допускаю что Вы не вкурсе, что уже десятилетие как существуют модульные операционные системы (разные клоны Оберонов).
SYG>Я допускаю, что Вы не вкурсе того как можно проектировать большие модульные системы и поэтому сомневаетесь в возможности этого: "такую систему и написать-то будет очень проблемматично", "это мертворожденнные проекты".
Может их и можно проектировать, только зачем? Я еще не встречал ни одной системы имеющей сетевую (циклическую) архитектуру, которую вы тут проповедуете. Все что я видел, было древовидным (в крайнем случае), а обычно двух или трех уровневым. В такой архиетктуре проблеммы циклических ссылок просто нет. И такая архитектура вообщем всегда предпочтительнее сетевой. Чем проще тем лучше (проще не в смысле примитивнее).
SYG>Так же я допускаю, что Вы не вкурсе того что ноги .NET, Java, Inferno+Limbo растут из копирования академически грамотных систем — Оберонов. Я допускаю, что Вы не понимаете почему в модульных системах всегда есть сборщик мусора. Но если Вы этого не знаете или не понимаете, то почему бы Вам вместо того чтобы кидаться словами — "Бред сивой кобылы", просто по человечески спокойно поинтересоваться о том что не знаете?
Люди которые делали НЕТ и Яву — практики с огромным опытом и с огромным числом набитых шишек и со знанием подводных камней и течений, им до этих академических поделок просто нет никакого дела. Более того академические поделки как правило не выдерживают проверки на практике. Сразу обнажается куча непонятно откуда взявшихся проблем в дизайне, недостатков и т.д. и т.п.
Здравствуйте, WolfHound, Вы писали:
VD>>Ты кстати, подмогнеш нам на поприще языкостроения или уже передумал? WH>Блин еслиб 48 часов в сутках и спать не хотелось
Та если бы спать не хотелось бы, то и 48 часов в сутках не нужно было бы .
WH>Попробую найти время.
Было бы здорово! Молодые и толковые нам нужны!
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kluev, Вы писали:
K>Может их и можно проектировать, только зачем? Я еще не встречал ни одной системы имеющей сетевую (циклическую) архитектуру, которую вы тут проповедуете. Все что я видел, было древовидным (в крайнем случае), а обычно двух или трех уровневым. В такой архиетктуре проблеммы циклических ссылок просто нет. И такая архитектура вообщем всегда предпочтительнее сетевой. Чем проще тем лучше (проще не в смысле примитивнее).
Архитектура — это одно, а ссылки между объектами — это другое. Архитектура — это то как модули друг друга импортируют. Модули всегда друг друга импортируют без циклов, стараются конечно — древовидно, но это не обязательно, главное что циклически модули не умеют импортироваться. А ссылки между объектами во время выполнения программы могут быть произвольные хоть циклические, хоть сами на себя — эти связи диктуются не архитектурой программы, а предметной областью для которой была написана программа. Если программа, например, написана для работы с графами, то понятно, что объекты этой программы ссылаются друг на друга так как в том графе нужно, к архитектуре же это отношения не имеет.
K>Люди которые делали НЕТ и Яву — практики с огромным опытом и с огромным числом набитых шишек и со знанием подводных камней и течений, им до этих академических поделок просто нет никакого дела. Более того академические поделки как правило не выдерживают проверки на практике. Сразу обнажается куча непонятно откуда взявшихся проблем в дизайне, недостатков и т.д. и т.п.
Здравствуйте, degor, Вы писали:
SYG>>Кстати, под названием COM можно даже понимать ее последнюю версию COM3, которая носит гордое название ".NET". D>Нельзя.
Вообще-то рабочее название дотнета как раз КОМ+. Могу ссылку МСДН-Маг дать...
SYG>>Цитата: SYG>>"Среда CLR применяется в качестве первичного загрузчика кода вместо команды CoCreateInstance среды COM или команды LoadLibrary среды Win32" SYG>>Основы платформы .NET, Том 1, Общеязыковая исполняющая среда, Д. Бокс, К Селлз. D>Написали два чувака глупость. Теперь все будем повторять?
А в чем тут глупость? Абстрактно, но совершенно верно. Аналогия прямая.
D>Примеров не надо — я циклические зависимости разрываю силой воли.
D> К тому же надуманный пример с циклическими ссылками не опровергает тезиса о возможности программирования _без_ создания циклических ссылок.
Не. Не опровергает. Но мы вот в свое время в доволь потрахались рвыя училием воли циклические ссылки на АТЛ-ных синглтонах. Правда и в дотнете словить цикл можно. На событиях например. Забыл отписаться и приплыли тапочки к дивану.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ну, кроме правил у КОМ был еще рантайм и разные фичи типа мидл-а и тлб.
Все вместе это называется технологией. В принципе базовые вещи можно делать и без КОМ-а или его аналогов. Но траху несоизмеримо больше.
По этому можно смело заявлять, что С++, как язык, не поддерживает компонентную разработку. И компоненты на нем можно делать не благодаря его возможностям, а вопреки им.
Вот список фич С++ которые КОМ намеренно отключает, запрещает и подменяет своей реализацией:
1. Наличие не виртуального публичного интерфейса.
2. Множественное наследование.
3. Приведение типов.
4. Создание объектов.
5. Импорт типов.
В общем, пол языка заменяется сурогатами. В том же дотнете компонентность встроена в языки и выглядт так как будтно это часть языка.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Если программа, например, написана для работы с графами, то понятно, что объекты этой программы ссылаются друг на друга так как в том графе нужно, к архитектуре же это отношения не имеет. Есть объект граф. Есть объект вершина графа. Граф владеет вершинами. Если убить граф то то он убьет вершины ибо он их владелец. Следовательно вершины могут как угодно ссылатся друг на друга от смерти в нужный момент это их не спасет. Врешина одного графа ссылающаяся на вершину другого графа есть ошибка ибо это не имеет смысла. Интерфейс графа не должен допускать такой возможности. Без объекта граф в общем случае обойтись нельзя ибо ни кто не отменял не связанные графы и тем болие ориентированные.
Проблемы нет. Еще примеры?
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
VD>Ну, кроме правил у КОМ был еще рантайм и разные фичи типа мидл-а и тлб. VD>Все вместе это называется технологией. В принципе базовые вещи можно делать и без КОМ-а или его аналогов. Но траху несоизмеримо больше.
Согласен, но это никак не опровергает мое мнение, а дополняет его.
VD>По этому можно смело заявлять, что С++, как язык, не поддерживает компонентную разработку. И компоненты на нем можно делать не благодаря его возможностям, а вопреки им.
Можно подумать, я не писал COM-объектов. С++ можно использовать на полную катушку, сделав всего две вещи — унаследоваться от IUnknown, и правильно его имплементировать. А то, что плюсы — это бесконечное поле засеянное граблями известно всем.
VD>Вот список фич С++ которые КОМ намеренно отключает, запрещает и подменяет своей реализацией:
VD>1. Наличие не виртуального публичного интерфейса.
Это проблема? И как COM должен получать адреса функций без vtlb?
VD>2. Множественное наследование.
Во-первых, это общепризнанный источник неприятностей . Во-вторых, я не вижу применимости множественного наследования от _чужих_ компонентов. Для компонентов/объектов в одном проекте никто не мешает им пользоваться.
VD>3. Приведение типов. VD>4. Создание объектов. VD>5. Импорт типов.
Вот эти пункты я совсем не понял.
VD>В общем, пол языка заменяется сурогатами. В том же дотнете компонентность встроена в языки и выглядт так как будтно это часть языка.
Так за это и боролись.
Я совершенно не собираюсь доказывать, что C++ — идеальный язык для компонентно-ориентированного программирования. Это не так. Но и в обиду его не дам.
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Здравствуйте, Kluev, Вы писали:
K>>Может их и можно проектировать, только зачем? Я еще не встречал ни одной системы имеющей сетевую (циклическую) архитектуру, которую вы тут проповедуете. Все что я видел, было древовидным (в крайнем случае), а обычно двух или трех уровневым. В такой архиетктуре проблеммы циклических ссылок просто нет. И такая архитектура вообщем всегда предпочтительнее сетевой. Чем проще тем лучше (проще не в смысле примитивнее).
SYG>Архитектура — это одно, а ссылки между объектами — это другое. Архитектура — это то как модули друг друга импортируют.Модули всегда друг друга импортируют без циклов, стараются конечно — древовидно, но это не обязательно, главное что циклически модули не умеют импортироваться. А ссылки между объектами во время выполнения программы могут быть произвольные хоть циклические, хоть сами на себя — эти связи диктуются не архитектурой программы, а предметной областью для которой была написана программа. Если программа, например, написана для работы с графами, то понятно, что объекты этой программы ссылаются друг на друга так как в том графе нужно, к архитектуре же это отношения не имеет.
И где здесь проблемма в сылках между обьектами? Возьмите реальную жизнь — человеческое тело: почки, печень и т.п. на своих местах и в никаком сборщике мусора не нуждаются. Сборшик мусора прийдет в конце один для всех "обьектов" . А плагины — часы, майки и рубашки, контактируют только с малой частью системы и ниаких циклических ссылок нет. Ссылка на футболку из печени — это нонсенс. Сетевая архитектура как правило реализуется внутри модуля и особо не вылазит наружу. Взять к примеру геометрическое моделирование. Структуры данных настолько переплетены друг с другом что просто абсурдно разбивать — это на модули и компоненты. А наружу торчит весьма тонкий и простой интерфейс.
А гипотетическая ситуация когда все на все ссылается и без сборщикак мусора не как, помоему может родится только в академических умах или в воображении схоластов далеких от практической жизни.
).
Попробую найти время.
