Re[4]: шаблоны С++ и дженерики С#
От: snaphold  
Дата: 23.09.09 06:15
Оценка:
А скажите для несведующих, что имеется ввиду под фразой

VD>А вот в С++ компонентности не было, нет и, похоже, уже не будет.


и под этой

VD>Когда же язык и его рантайм исходно поддерживают компонентность, то костыли не требуются. Любой класс является компонентом и может быть использован в рантайме без дополнительных приседаний.


Спасибо
Re[5]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.09 12:52
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Как раз бэйсике она была заложена в язык начиная с 3-ей версии.


ГВ>Угу, на основе инфраструктуры COM.


А не странно, что с помощью препроцессора к С Страуструп создал С++, а помощью полноценного отдельного компилятора-генератора кода (midl) получается всего лишь инфраструктура? Мидл и из С делает "компонентный язык".

VD>>А вот в С++ компонентности не было, нет и, похоже, уже не будет.


ГВ>И это есть хорошо и хорошо весьма.


Агащазблин.

ГВ> Поскольку выбор компонентных инфраструктур весьма велик.


А что в этом хорошего? Компонентность нужна сама по себе. А инфраструктура она нужна только потому, что без нее нельзя. В общем, костыли они и есть остыли.

ГВ> В общем, в этом и прелесть C++ по сравнению с навороченными вагонами всех-правильных-практик в одном флаконе.


Как отсутствие чего-то может быть преимуществом? Другие языки и технологии точно так же могут подерживать разные ифраструктуры и т.п. Делать это или нет определяется исключительно необходимостью оных. Скажем то что в дотнет встроена поддержка COM-а не запрещает использовать дотнет в Корба-приложениях.

ГВ>(Язвительне комментарии по поводу того, что в C++ совсем нет правильных практик ==> /dev/null/please)


Есть, конечно. Только, как показала практика, это тоже по большей части костыли. Скажем, нет в языке мультиметодов и/или паттерн-матчинга и нужны разные шаблоны вроде Посетителя. Нет событий и/или функциональных типов и нужны Обозреватели... Но это уже другой разговор.

VD>>Дженерике же проектировались с расчетом на компонентные решения.


ГВ>Читай: в расчёте на инфраструктуру .Net.


Не читай. Дженерики — это весьма абстрактное проектное решение. То что они были разработаны для платформы CLI (они, между прочем поддерживаются в Моно ни чем не хуже) ни как не мешает использованию их в других языках. Та же Ява имеет очень похожее решение.

VD>>В общем, сам ты несешь... заблуждения в массы. Наличие COM-а а так же разных ATL-ов и расширений MFC четко демонстрирует, что сам язык не компонентный и ему требуется "инфрастркутура" (читай, костыли) чтобы добиться оной.


ГВ>COM — это одна из возможных инфрастуктур. Понимаешь?


Понимаю. Но понимаю и то, что родилась она (как и альтернатива, коих кот наплакал) в основном потому, что в С++ не было нужных возможностей.
Обратимся к близкой аналогии к C API. До его укоренения в качестве стандарта де-факто ведь была туча других языков каждый из которых имел схожий процедурный API. Можно было создать много разных стандартов и балдеть от наличия альтернативы. Только вот в данном случае наличие альтернативы — это зло! C API победил и всем от этого хорошо. И это при том, что C API — это весьма кривое и не полноценное решение. Скажем, такие вопросы как безопасность данных/памяти в нем вообще не рассматривается. При этом С++ который, казалось бы, на голову круче так и не смог предложить ничего стандартного. Теперь обратимся к DLL. Это — корпоративный стандарт Майкрософта. Он конечно хорош для своих целей. Но плох он в первую очередь тем, что не коросплатформен. В линукс свои динамические библиотеки где-то еще — свои. Кроме того формат не предлагает никаких решений для переноса кода в машинах/СО с разной разрядностью.
Теперь вернемся к сборкам дотнета. Точнее к сборкам CLI. Это своего рода такой же стандарт библиотек заменяющий C API, DLL, SO и т.п. Он переносим между платформами. Модуль скомпилированный с помощью Моно можно запустить на Windows 7, Windows Mobile, Linux, FreeBSD и т.д. Нет никаких проблем если целевая платформа отличается разрядностью. Главное чтобы для нее существовала виртуальная машина.
В общем, это идеальный API. Ну, а для связи с предыдущими API существуют поддержка тех самых C API, COM-а, Корбы и т.п.

ГВ>Одна из мириад возможных.


Ерунду говоришь.
Перечисли, плиз эти мириады. Увидишь, что их все на пальцах одной руки посчитать можно. Более того. Основная часть — это сабсэты COM-а. Скажем тот же XCOM — это фактически COM абстрагированный от "инфраструктуры" МС и упрощенный до предела. Особняком стоит Корба. Но она вымирает.

И это не просто так. COM ко всему прочему — это интерфейс взаимодействия программ. А тут стандартны намного важнее чем конкуренция.

ГВ> Чтобы ввести в язык "компонентность" сначала необходим некоторый набор соглашений, соответствующий этой самой инфраструктуре. Что за чем создаётся, что чем управляет, кто кому и как сигналит и т.п.


Ты пошел не в ту степь. Любой стандарт — это соглашения. Компонентный или нет уже не важно.

ГВ>Любая ОС — это компонентная инфраструктура, кстати (соглашения о формате файлов, о файловых системах и т.п.). Отсюда мораль: COM-приблуды MFC, ATL и вся остальная требуха свидетельствует только о том, что C++ может поддерживать, в числе прочих и такую компонентную инфраструктуру (привет капитану Очевидность).


ОС есть ОС. Она так же стандарт, но компонентной она быть не обязана. Отличный прмер — MS DOS. Большая часть возможностей встроена в ядро.

ГВ>Угу, угу. Осталось только уточнить, какая именно компонентность полагается самой правильной — вплоть до ABI.


Компетентность нужна для самих программ. И им по фигу как она получена. Главное чтобы по проще.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.09 15:07
Оценка:
Здравствуйте, snaphold, Вы писали:

S>А скажите для несведующих, что имеется ввиду под фразой


VD>>А вот в С++ компонентности не было, нет и, похоже, уже не будет.


То что сказано. Если это непонятно, то наверно стоит начать с общих сведений о компонентах и КООП:
http://en.wikipedia.org/wiki/Component-oriented_programming

С++ не имеет встроенных средств поддержки КООП. В нем нет таких понятий как:
1. Отчуждаемые модули которые можно передавать в бинарном виде и из которых можно создавать экзепляры классов (компонентов).
2. Системы динамического создания экзепляров. Тип создаваемого объекта должен быть известен заранее.
3. Метаинформации позволяющей выявлять наличие компонентов и анализировать их свойства (возможности).

Для решения этих проблем были созданы разные технологии. Самая известная из них — это MS COM.

S>и под этой


VD>>Когда же язык и его рантайм исходно поддерживают компонентность, то костыли не требуются. Любой класс является компонентом и может быть использован в рантайме без дополнительных приседаний.


Опять же то что написано. Все перечисленные возможности уже встроены в язык и его рантайм. Скажем в дотнете и яве можно:
1. Размещать код компонентов в отдельных модулях (сорки дотнета и jar-архивы явы и class-файлы).
2. Экземпляры типом можно создавать на основании их текстовых имен или другой информаци.
3. О каждом типе и модуле можно получить исчерпывающую информацию даже если нет их исходников.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: шаблоны С++ и дженерики С#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.09.09 20:02
Оценка: +1
Здравствуйте, Хвост, Вы писали:

Х>и не надо строить из себя интеллект. Лично по твоим постам (и по твоим мегаисходникам столетней давности в которых ты осилил RAII в С++ и смог обернуть хендлы win32) у меня абсолютно стойкое убеждение что ты С++ знаешь максимум на уровне "Си с классами". Т.к. других сведений о твоей компетенции в С++ у меня нет, то и слушать твои росказни о С++(никах) нет желания.


Продолжишь обсуждать квалификацию собеседника, тем более в таком тоне — получишь по шапке, уж извини.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[6]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 02:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Как раз бэйсике она была заложена в язык начиная с 3-ей версии.

ГВ>>Угу, на основе инфраструктуры COM.
VD>А не странно, что с помощью препроцессора к С Страуструп создал С++, а помощью полноценного отдельного компилятора-генератора кода (midl) получается всего лишь инфраструктура? Мидл и из С делает "компонентный язык".

Ничего странного не вижу. MIDL не делает из C "компонентный язык" (к счастью). MIDL помогает подвязать COM API к программам на C. Компонентным от этого C не становится (обратно таки — это хорошо).

ГВ>> Поскольку выбор компонентных инфраструктур весьма велик.

VD>А что в этом хорошего? Компонентность нужна сама по себе. А инфраструктура она нужна только потому, что без нее нельзя. В общем, костыли они и есть остыли.

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

ГВ>> В общем, в этом и прелесть C++ по сравнению с навороченными вагонами всех-правильных-практик в одном флаконе.

VD>Как отсутствие чего-то может быть преимуществом?

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

VD>Другие языки и технологии точно так же могут подерживать разные ифраструктуры и т.п. Делать это или нет определяется исключительно необходимостью оных. Скажем то что в дотнет встроена поддержка COM-а не запрещает использовать дотнет в Корба-приложениях.


Конечно же не запрещает. Только если мне понадобится исключительно корба, то я выбирать буду между Java и C++, а отнюдь не между C# и F#. С другой стороны, если будет предполагаться обилие COM, то выбор будет из C++ и C#. А вот если потребуется и то, и другое и ещё что-то третье... Ну ты понял. И произойдёт это ровно потому, что C++ не содержит каких-то встроенных "компонентизирующих" средств, которые, к тому же, нельзя оторвать от языка.

VD>>>Дженерике же проектировались с расчетом на компонентные решения.

ГВ>>Читай: в расчёте на инфраструктуру .Net.
VD>Не читай. Дженерики — это весьма абстрактное проектное решение. То что они были разработаны для платформы CLI (они, между прочем поддерживаются в Моно ни чем не хуже) ни как не мешает использованию их в других языках. Та же Ява имеет очень похожее решение.

Угу, ключевое слово — "похожее". Только не надо говорить, что дженерики CLI проектировались в расчёте на JVM. И тогда зачем тут вообще Java упоминать?

VD>>>В общем, сам ты несешь... заблуждения в массы. Наличие COM-а а так же разных ATL-ов и расширений MFC четко демонстрирует, что сам язык не компонентный и ему требуется "инфрастркутура" (читай, костыли) чтобы добиться оной.

ГВ>>COM — это одна из возможных инфрастуктур. Понимаешь?
VD>Понимаю. Но понимаю и то, что родилась она (как и альтернатива, коих кот наплакал) в основном потому, что в С++ не было нужных возможностей.

Ага, и поэтому не только унаследовала от C++ такую штуку, как VMT, но ещё и прямо заявлялась всегда как инфраструктура взаимодействия программ на разных языках, а отнюдь не как метод борьбы мифическими недостатками C++. Влад, по-моему только ты всё время борешься с C++ за светлое будущее.

VD>Обратимся к близкой аналогии к C API. До его укоренения в качестве стандарта де-факто ведь была туча других языков каждый из которых имел схожий процедурный API. Можно было создать много разных стандартов и балдеть от наличия альтернативы. Только вот в данном случае наличие альтернативы — это зло! C API победил и всем от этого хорошо. И это при том, что C API — это весьма кривое и не полноценное решение. Скажем, такие вопросы как безопасность данных/памяти в нем вообще не рассматривается.


Ну ты смешал всё в одну кучу... Во-первых, не надо путать интерфейс взаимодействия программы на языках X и Y (коих может быть N^2/2, где N — общее количество языков), и обобщённый интерфейс взаимодействия программ (коих, само собой, много меньше, но и то они друг с другом перегрызутся). Они решают несколько разные задачи.

Во-вторых, ключевые "соглашения C API" оговаривают только одну вещь в смысле управления ресурсами — кто и когда освобождает стек после вызова (не считая имени точки входа). Просто и понятно, может запросто поддерживаться микропроцессорами. Потому, вероятно, API с бинарным интерфейсом в стиле C и распространились так широко — они практически ничего не требуют для своей реализации: нужно только очистить стек от помещённых туда параметров после вызова процедуры. Всё остальное — дело взаимодействующих программ: политика управления памятью, соглашения о порядке вызова, согласование жизненных циклов данных и всё, что заблагорассудится. Ключевой момент, без которого ни хрена работать не будет, то есть бинарное согласование — проще некуда.

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


Ну скажем так, интеловский ABI, он всё же есть.

VD>Теперь обратимся к DLL. Это — корпоративный стандарт Майкрософта. Он конечно хорош для своих целей. Но плох он в первую очередь тем, что не коросплатформен. В линукс свои динамические библиотеки где-то еще — свои. Кроме того формат не предлагает никаких решений для переноса кода в машинах/СО с разной разрядностью.


Хорош-плох, это всегда очень спорная дихотомия. DLL так или иначе связаны с Майкрософтовскими ОС в силу требований к бинарному формату, это верно. Но также очевидно, что для того, чтобы DLL можно было переносить между разными ОС (от MS и нет), необходима всего лишь поддержка со стороны загрузчиков библиотек. Теоретически нет никакой проблемы в загрузке DLL под Unix-ом или любой другой гипотетической ОС, которая работает на интеловском процессоре, если сама эта библиотека не привязана к другим библиотекам, существующим только в Windows. По сути библиотека — это просто размеченный файл с машинным кодом. Поддержать его загрузку можно без особых проблем, если, конечно, не слишком озабочиваться вопросами "мирового зла", исходящего от Майкрософт.

VD>Теперь вернемся к сборкам дотнета. Точнее к сборкам CLI. Это своего рода такой же стандарт библиотек заменяющий C API, DLL, SO и т.п.


Заменяющий? Чёрта-с-два он заменяет. Он использует эти самые DLL, SO и т.п. Вот когда .Net будет работать сам по себе, тогда и будет что-то заменять. Тут скорее уместно упомянуть явовские JAR-ы.

VD>Он переносим между платформами. Модуль скомпилированный с помощью Моно можно запустить на Windows 7, Windows Mobile, Linux, FreeBSD и т.д. Нет никаких проблем если целевая платформа отличается разрядностью. Главное чтобы для нее существовала виртуальная машина.


Правильно. Виртуальная машина — тоже часть инфраструктуры.

VD>В общем, это идеальный API. Ну, а для связи с предыдущими API существуют поддержка тех самых C API, COM-а, Корбы и т.п.


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

ГВ>>Одна из мириад возможных.

VD>Ерунду говоришь.
VD>Перечисли, плиз эти мириады. Увидишь, что их все на пальцах одной руки посчитать можно.

Не перечислю. Мне для своих-то собственных моделей пальцев на обоих руках не хватит.

VD>Более того. Основная часть — это сабсэты COM-а. Скажем тот же XCOM — это фактически COM абстрагированный от "инфраструктуры" МС и упрощенный до предела.


Так XCOM своего наследия от COM и не скрывает. А ещё есть XPCOM от Mozilla, а ещё есть GObject из GTK+. Он тоже похож в чём-то на COM-овский объект, но ведь даже не C++-ный.

VD>Особняком стоит Корба. Но она вымирает.


Корба вымирает? Это новость. Пруфлинк не дашь?

VD>И это не просто так.


Угу, и даже причина понятна: концепция объектного интерфейса, почти повсеместно положенная в основу компонентной инфраструктуры. Потому распространённые компонентные инфраструктуры можно в той или иной степени уподобить COM. Кто у кого что позаимствовал сейчас уже не разберёшься.

VD>COM ко всему прочему — это интерфейс взаимодействия программ. А тут стандартны намного важнее чем конкуренция.


Вот именно, что борьба с недостатками C++ — это как раз прочее, по большей части вымышленное. В основном COM — интерфейсная технология для разных языков.

ГВ>> Чтобы ввести в язык "компонентность" сначала необходим некоторый набор соглашений, соответствующий этой самой инфраструктуре. Что за чем создаётся, что чем управляет, кто кому и как сигналит и т.п.

VD>Ты пошел не в ту степь. Любой стандарт — это соглашения. Компонентный или нет уже не важно.

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

ГВ>>Любая ОС — это компонентная инфраструктура, кстати (соглашения о формате файлов, о файловых системах и т.п.). Отсюда мораль: COM-приблуды MFC, ATL и вся остальная требуха свидетельствует только о том, что C++ может поддерживать, в числе прочих и такую компонентную инфраструктуру (привет капитану Очевидность).

VD>ОС есть ОС. Она так же стандарт, но компонентной она быть не обязана. Отличный прмер — MS DOS. Большая часть возможностей встроена в ядро.

Плохой пример — DOS. Из-за достославного INT 21H И ещё из-за обилия резидентных программ. ОС, которая пишется для поддержки прикладного программирования (а больше она ни для чего не нужна), вообще не может быть в том или ином смысле "не компонентной". Вопрос только в том, какие обязанности она делегирует загружаемым программам. Короче, это всё совпадает с компонентной инфраструктурой "с точностью до изоморфизма". Там — порядок управления ресурсами, тут — порядок управления ссылками и т.п.

ГВ>>Угу, угу. Осталось только уточнить, какая именно компонентность полагается самой правильной — вплоть до ABI.

VD>Компетентность нужна для самих программ. И им по фигу как она получена. Главное чтобы по проще.

Я сказал не "кому?", а "какая?" Давай без абстракций менеджерского пошиба. И кстати, о том, что "проще всего" я тут уже выше высказался.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: ошибка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 03:16
Оценка:
ГВ>интерфейс взаимодействия программы на языках X и Y (коих может быть N^2/2, где N — общее количество языков)

Хе-хе, N^2-N, разумеется, если считать, что средства взаимодействия встраиваются в соответствующие языки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: Довесок
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 03:34
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>А скажите для несведующих, что имеется ввиду под фразой

VD>>>А вот в С++ компонентности не было, нет и, похоже, уже не будет.

VD>То что сказано. Если это непонятно, то наверно стоит начать с общих сведений о компонентах и КООП:

VD>http://en.wikipedia.org/wiki/Component-oriented_programming

Я уж от себя добавлю, для полноты картины: http://www.rsdn.ru/forum/philosophy/133200.1.aspx
Автор: Геннадий Васильев
Дата: 17.11.02


Обрати внимание на дату.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: шаблоны С++ и дженерики С#
От: FR  
Дата: 24.09.09 06:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Теперь вернемся к сборкам дотнета. Точнее к сборкам CLI. Это своего рода такой же стандарт библиотек заменяющий C API, DLL, SO и т.п. Он переносим между платформами. Модуль скомпилированный с помощью Моно можно запустить на Windows 7, Windows Mobile, Linux, FreeBSD и т.д. Нет никаких проблем если целевая платформа отличается разрядностью. Главное чтобы для нее существовала виртуальная машина.

VD>В общем, это идеальный API. Ну, а для связи с предыдущими API существуют поддержка тех самых C API, COM-а, Корбы и т.п.

Для C++ и других нативных языков такая среда тоже уже есть http://llvm.org/
В общем-то есть большой шанс что она станет еще одной крупной платформой.
Re[7]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.09.09 14:01
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:
VD>>Как отсутствие чего-то может быть преимуществом?

ГВ>Хламу меньше. И меньше встроенных ограничений.


Ты сам то часто писал КОМ-объекты на С?
Хламу там получается ужас сколько. И это по сравнению с чем? С тем, что просто любой объект дотнета — это уже автоматом компонент!
Для С++ для борьбы с халмом были разработаны библоитеки которые все равно не смогли полностью скрыть хлам от разработчика. В Дельфи и дотнете поддержку кома встроели в рантайм и языки. Результа — писать КОМ-объекты на Дельфи или ВБ в десятки раз проще чем на С++.

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


Не ограниченными возможностями. А костылями, да еще и с огромной болью в заднице.

ГВ>Конечно же не запрещает. Только если мне понадобится исключительно корба, то я выбирать буду между Java и C++, а отнюдь не между C# и F#.


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

ГВ> С другой стороны, если будет предполагаться обилие COM, то выбор будет из C++ и C#. А вот если потребуется и то, и другое и ещё что-то третье... Ну ты понял. И произойдёт это ровно потому, что C++ не содержит каких-то встроенных "компонентизирующих" средств, которые, к тому же, нельзя оторвать от языка.


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

ГВ>Угу, ключевое слово — "похожее". Только не надо говорить, что дженерики CLI проектировались в расчёте на JVM. И тогда зачем тут вообще Java упоминать?


Денерики явы и дотнета проектировались в расчете на использование в компонентной среде. И это очень важно. Я не могу объявить обобщенный интерфейс в С++. При этом я спокойно могу сделать это как в яве, так и в дотнете.

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


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


Дык это аргумент против твоей теории. Сам видишь, что для разработки универсального компонентного АПИ были взяты средства специфичные для конкретного языка, что сделано другие языки спроектированные без расчета на КОМ менее удобными для использования КОМ-а. В дальнейшем все языки которым было важно поддерживать КОМ тем или иным образом включили в себя поддержку аналога ВМТ. Только С эмулирует его на массивах.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: шаблоны С++ и дженерики С#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.09.09 14:43
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Что ты несёшь... заблуждения в массы? Компонентность реализуется инфраструктурой, а не классами, шаблонами или дженериками.


Коль скоро так — продемонстрируй дженерик СОМ интерфейс, чтобы он был доступен из любого клиента СОМ именно как дженерик.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[8]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 15:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Как отсутствие чего-то может быть преимуществом?

ГВ>>Хламу меньше. И меньше встроенных ограничений.
VD>Ты сам то часто писал КОМ-объекты на С?
VD>Хламу там получается ужас сколько. И это по сравнению с чем? С тем, что просто любой объект дотнета — это уже автоматом компонент!

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

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


Хм. У меня сложилось устойчивое ощущение, что библиотеки (это ты про ATL/MFC?) никогда и не пытались что-то кардинально скрывать от разработчика. Тут скорее другая позиция — оставить все возможные пути использования и слегка упростить то, что по-разному использовать нельзя. Высокая идея спасения всех от десятка лишних строчек, похоже, разработчиков ATL трогает мало — важнее дать некий "концептуальный каркас", дальше специалисты прекрасно разберутся, что можно и чего нельзя. Но это на правах имхи.

VD>В Дельфи и дотнете поддержку кома встроели в рантайм и языки. Результа — писать КОМ-объекты на Дельфи или ВБ в десятки раз проще чем на С++.


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

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


VD>Не ограниченными возможностями. А костылями, да еще и с огромной болью в заднице.


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

ГВ>>Конечно же не запрещает. Только если мне понадобится исключительно корба, то я выбирать буду между Java и C++, а отнюдь не между C# и F#.


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


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

ГВ>> С другой стороны, если будет предполагаться обилие COM, то выбор будет из C++ и C#. А вот если потребуется и то, и другое и ещё что-то третье... Ну ты понял. И произойдёт это ровно потому, что C++ не содержит каких-то встроенных "компонентизирующих" средств, которые, к тому же, нельзя оторвать от языка.


VD>А зачем отрывать средства от языка? Ты пишешь не программу на С++, а просто программу. Если язык или рантайм позволяет решить стоящие перед тобой задачи максимально просто, то разумно этим воспользоваться, а не тянуть черти-что с боку бантик (например, корбу) обосновывая это какими-то там идеями вроде универсальности стандарта.


А это ты, вероятно, никогда не сталкивался с необходимостью поддерживать несколько разных интерфейсов для одной программы. Иными словами, составляющая задачи — поддержка COM, CORBA, SOAP, C API, и т.п. При том COM-ов может быть несколько вариантов.

ГВ>>Угу, ключевое слово — "похожее". Только не надо говорить, что дженерики CLI проектировались в расчёте на JVM. И тогда зачем тут вообще Java упоминать?

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

Хм. Почему я могу объявить обобщённый интерфейс в C++? Разница только в моменте инстанцирования, но это к компонентности, мягко говоря, ортогонально. Обратно аргументы из серии "пришёл неизвестный ранее тип, под который мы резко инстанцировались и утонули в шоколаде" тоже отпраляются в /dev/trash — никогда ничего "совершенно неизвестного" компьютерные системы не обрабатывают.

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

ГВ>>Ага, и поэтому не только унаследовала от C++ такую штуку, как VMT, но ещё и прямо заявлялась всегда как инфраструктура взаимодействия программ на разных языках, а отнюдь не как метод борьбы мифическими недостатками C++. Влад, по-моему только ты всё время борешься с C++ за светлое будущее.
VD>Дык это аргумент против твоей теории. Сам видишь, что для разработки универсального компонентного АПИ были взяты средства специфичные для конкретного языка, что сделано другие языки спроектированные без расчета на КОМ менее удобными для использования КОМ-а. В дальнейшем все языки которым было важно поддерживать КОМ тем или иным образом включили в себя поддержку аналога ВМТ. Только С эмулирует его на массивах.

Это аргумент в пользу тезиса о странностях, присущих Майкрософт. COM за эту самую VMT поругивали ещё в девяностолохматом году. И уж никак это не пришивается к рассуждениям о необходимости вставить поддержку компонентной среды в C++.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 15:12
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ГВ>>Что ты несёшь... заблуждения в массы? Компонентность реализуется инфраструктурой, а не классами, шаблонами или дженериками.


AVK>Коль скоро так — продемонстрируй дженерик СОМ интерфейс, чтобы он был доступен из любого клиента СОМ именно как дженерик.


Чего-чего? Как это соотносится с моим высказыванием?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: шаблоны С++ и дженерики С#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.09.09 15:22
Оценка: +2
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Чего-чего? Как это соотносится с моим высказыванием?


Того. Влад совершенно понятно сказал, что шаблоны не компонентны. А уж как это соотносится с твоим высказыванием — ты сам решай.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[6]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 15:31
Оценка: -2 :))
Здравствуйте, AndrewVK, Вы писали:

ГВ>>Чего-чего? Как это соотносится с моим высказыванием?


AVK>Того. Влад совершенно понятно сказал, что шаблоны не компонентны. А уж как это соотносится с твоим высказыванием — ты сам решай.


Нет уж, твои ассоциации, ты и разъясняй. Что до меня, то на мой взгляд, твоя реплика никак не связана с нашей с Владом дискуссией.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.09.09 16:25
Оценка:
Здравствуйте, FR, Вы писали:

FR>Для C++ и других нативных языков такая среда тоже уже есть http://llvm.org/

FR>В общем-то есть большой шанс что она станет еще одной крупной платформой.

Такая да не такая. Компонентным она язык не сделает. Но согласен, что именно на таких бэкэндах имеет смысл строить современные компиляторы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.09.09 16:44
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:
VD>>Ты сам то часто писал КОМ-объекты на С?
VD>>Хламу там получается ужас сколько. И это по сравнению с чем? С тем, что просто любой объект дотнета — это уже автоматом компонент!

ГВ>На C — да, лишнего кода много больше, чем на C++. Но и то в основном из-за отсутствия поддержки исключений и автоматических деструкторов.


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

ЗЫ

В общем, это бесполезный разговор который пора завершать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: шаблоны С++ и дженерики С#
От: FR  
Дата: 24.09.09 16:59
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Такая да не такая. Компонентным она язык не сделает. Но согласен, что именно на таких бэкэндах имеет смысл строить современные компиляторы.


Угу, но кроме бакэндов дает две важные вещи интероперабельность и кроссплатформенность, этого достаточно чтобы сформировать платформу.
Re[10]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 17:04
Оценка: +1 -2 :)
Здравствуйте, VladD2, Вы писали:

VD>В общем, это бесполезный разговор который пора завершать.


Угу, всё равно у тебя по делу одна мысль: "C++ — отстой и маздай потому что отстой и маздай, .Net рулит потому что рулит". Хорошо, что есть что-то постоянное в этом мире.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.09.09 17:10
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Угу, всё равно у тебя по делу одна мысль: "C++ — отстой и маздай потому что отстой и маздай, .Net рулит потому что рулит". Хорошо, что есть что-то постоянное в этом мире.


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

Скажем, если у компании есть много денег и ей нужно выпустить продукт критичный к объему используемых ресурсов и сильно оптимизированный под аппаратуру, а алгоритмически задачи не очень сложные, то С++ вполне себе инструмент. Но нужно понимать, что это альтернатива ассемблеру. Эдакий ассемблер с классами и шаблонами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: А есле не согласен...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 17:11
Оценка:
...то дай, будь добр пруфлинк на "загибающуюся корбу" и сформулируй требования к идеальной компонентной среде. Требования должны быть получены каким-то иным путём, отличным от индукции из того, что ты увидел в .Net и JVM.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.