Господа! Хочу заняться программированием на С++. Посоветуйте с чего начать: VS6, либо С# (.Net). Последняя версия посовременнее будет, но, возможно, и посложнее. Посоветуйте. Заранее благодарен, спасибо.

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

RSDN>Господа! Хочу заняться программированием на С++. Посоветуйте с чего начать: VS6, либо С# (.Net). Последняя версия посовременнее будет, но, возможно, и посложнее. Посоветуйте. Заранее благодарен, спасибо.

C++ — Страуструп

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

RSDN>Господа! Хочу заняться программированием на С++. Посоветуйте с чего начать: VS6, либо С# (.Net). Последняя версия посовременнее будет, но, возможно, и посложнее. Посоветуйте. Заранее благодарен, спасибо.

Изучай С#. Позно уже за С++ браться. Ну уж если очень хочется, то берём Страуструпа, Мейерса, Александреску и пр.

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

RSDN>Господа! Хочу заняться программированием на С++. Посоветуйте с чего начать: VS6, либо С# (.Net).

ИМХО, вопрос так стоять не может. Правильнее будет так —

Господа! Нужно написать справочник абонентов (драйвер к железяке, игрушку-стрелялку, бухгалтерию и т.д., не нужное вычеркнуть, нужное добавить) на чем это лучше сделать? Использовать .Net или хватит и VC6?

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

RSDN>Господа! Хочу заняться программированием на С++. Посоветуйте с чего начать: VS6, либо С# (.Net). Последняя версия посовременнее будет, но, возможно, и посложнее. Посоветуйте. Заранее благодарен, спасибо.

А что вы уже знаете? Если вы новичок, то (совет студента)) начните с Кернигана и Ритчи "Язык программирования С", замечательная книга с остроумнейшими примерами и дельными заданиями для самост. работы. Потом можно уже браться за Страуструпа "Я. пр. С++", начинать с него тяжеловато. Хвататься за С# новичку имхо не стоит, нужна классическая база. Или я ошибся на ващ счет и вы дока в Паскале? Тогда извиняюсь).

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

[skipped]

M.NET>Изучай С#. Позно уже за С++ браться. Ну уж если очень хочется, то берём Страуструпа, Мейерса, Александреску и пр.

А последний, интересно, в переводе есть (а то за english-версию такие бабки... )

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

RSDN>Господа! Хочу заняться программированием на С++. Посоветуйте с чего начать: VS6, либо С# (.Net). Последняя версия посовременнее будет, но, возможно, и посложнее. Посоветуйте. Заранее благодарен, спасибо.

Если в смысле изучения, то начинай с C++ (я думаю, что лучше с .Net, поскольку народ утверждает, что VС7 поближе к стандарту, чем VС6, а сам я ещё с семёркой не работал). Что C#, что Java — попытки кастрации C++ под нужды менеджеров, которые никак не могли разобраться с таким сложным языком. (Ладно, это уж я со зла , хотя и небезосновательно) Поймешь C++ — с остальными C++ — подобными языками проблем будет намного меньше. А если начнёшь с кастрированного объектного языка, то заморочаешься потом.

Во как

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

ГВ>Если в смысле изучения, то начинай с C++ (я думаю, что лучше с .Net, поскольку народ утверждает, что VС7 поближе к стандарту, чем VС6, а сам я ещё с семёркой не работал). Что C#, что Java — попытки кастрации C++ под нужды менеджеров, которые никак не могли разобраться с таким сложным языком. (Ладно, это уж я со зла , хотя и небезосновательно) Поймешь C++ — с остальными C++ — подобными языками проблем будет намного меньше. А если начнёшь с кастрированного объектного языка, то заморочаешься потом.

Я думаю что при первом же достаточно крупном проекте ты поймешь что не все ладно в королевстве датском, т.е. С++. Гемороя и нелогичности в нем более чем достаточно. Так что таки C# или Java для современного новичка получше будут, если конечно он потом чем то низкоуровневым заниматься не собирается.

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

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

ГВ>>Если в смысле изучения, то начинай с C++ (я думаю, что лучше с .Net, поскольку народ утверждает, что VС7 поближе к стандарту, чем VС6, а сам я ещё с семёркой не работал). Что C#, что Java — попытки кастрации C++ под нужды менеджеров, которые никак не могли разобраться с таким сложным языком. (Ладно, это уж я со зла :), хотя и небезосновательно) Поймешь C++ — с остальными C++ — подобными языками проблем будет намного меньше. А если начнёшь с кастрированного объектного языка, то заморочаешься потом.

AVK>Я думаю что при первом же достаточно крупном проекте ты поймешь что не все ладно в королевстве датском, т.е. С++. Гемороя и нелогичности в нем более чем достаточно. Так что таки C# или Java для современного новичка получше будут, если конечно он потом чем то низкоуровневым заниматься не собирается.

Чаще, правда, это нелогичность программистов при употреблении C++. (ИМХО ;) ) Концептуально язык весьма логичен. Просто, мне кажется, что начав с Java-like языков новичку труднее будет перешагнуть определённый психологический порог в развитии способности выделять сущности и концепции (как устойчивые совокупности требований), и уверенно выражать их на языке программирования. Я полагаю, что для таких целей C++ содержит больше выразительных средств, чем Java. Соглашусь, что сложностей и тонких мест у него навалом, но лучше уж наличие возможности, пусть и "труднопостижимой", чем её отсутствие.

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

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

ГВ>Чаще, правда, это нелогичность программистов при употреблении C++. (ИМХО ) Концептуально язык весьма логичен.
В чем логика отсутствия нормальных property или event? Почему это сложно ввести в состав языка? В чем логика отсутствия нормального рефлекшена?

ГВ> Просто, мне кажется, что начав с Java-like языков новичку труднее будет перешагнуть определённый психологический порог в развитии способности выделять сущности и концепции (как устойчивые совокупности требований), и уверенно выражать их на языке программирования.
Как раз реализация определенных концепций на таких языках оказывается зачастую более понятной, простой и красивой. Сравни к примеру COM и объекты дотнета или джавы.


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

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

ГВ> Или зачем там так развиты средства комбинирования абстракций? Так что, думаю, что если современный новичок и не столкнётся с C++, то только в том случае, если никогда не будет заниматься сложными программами.
Чтобы создавать большие проекты на С++ нужно быть совсем не новичком.

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

ГВ>Также не согласен с доводом, что C++ — это язык для низкоуровневых систем. C++ — язык для сложных и больших программ, а не только низкоровневых. Или зачем там так развиты средства комбинирования абстракций? Так что, думаю, что если современный новичок и не столкнётся с C++, то только в том случае, если никогда не будет заниматься сложными программами.

Не бывает языков для систем, бывают языки для слоев!

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

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

ГВ>>Чаще, правда, это нелогичность программистов при употреблении C++. (ИМХО ;) ) Концептуально язык весьма логичен.
AVK>В чем логика отсутствия нормальных property или event? Почему это сложно ввести в состав языка? В чем логика отсутствия нормального рефлекшена?

Сразу вопрос. Что такое нормальные property и event? Какая реализация, например, событий, была бы "логичной"? Каким, например, должен быть механизм передачи событий? Должен ли он предусматривать межпроцессную передачу данных? Должна ли принимающая сторона уметь идентифицировать отправителя события? Должна ли создаваться очередь событий? Варианты ответов на эти вопросы прекрасно можно оформить библиотеками классов на C++! Зачем навязывать самим себе "единственно правильную" модель реализации?

Для C# и Java эти вопросы решались исходя из целей этих языков. C# — поддержание амбиций Microsoft (т.е., внедрение поддержки модели COM), а Java... кстати, в Java event-ов и property на уровне языка нет! Есть библиотеки!

ГВ>> Просто, мне кажется, что начав с Java-like языков новичку труднее будет перешагнуть определённый психологический порог в развитии способности выделять сущности и концепции (как устойчивые совокупности требований), и уверенно выражать их на языке программирования.
AVK>Как раз реализация определенных концепций на таких языках оказывается зачастую более понятной, простой и красивой. Сравни к примеру COM и объекты дотнета или джавы.

Ну, во-первых. Сравнивать COM (в сущности — способ структурирования коммуникаций) с моделью объектов в языках реализации не совсем корректно.

Реализация COM для C++ в Miscrosoft-овском варианте обладает теми же чертами, что и плоский API на C с небольшими вкраплениями объектного подхода. То есть — можно было бы и лучше. Потом, не надо забывать о том, что, действительно, по сравнению с C++ (что, впрочем, ИМХО, справедливо для любого языка общего назначения) языки специального назначения обладают преимуществами в специальных областях. Ну, например, VBS или Perl лучше подходят для скриптования идиотской модели объектов ClearQuest, нежели C++, хотя и там время от времени приходится использовать его.

Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun, а C# + CLR — как противовес Java в той же области, то, естественно, они в этом смысле обладают преимуществами перед C++. Тогда как C++ создан для упрощения решения проблем программирования. Что называется — почувствуйте разницу ;)

И здесь я действительно согласен с тем, что на C# проще реализовать что-то на базе модели COM. Но, ёлки-палки, COM — это не способ построения абстракций уровня реализации, он слишком ограничен для этого!
:crash:

ГВ>> Я полагаю, что для таких целей C++ содержит больше выразительных средств, чем Java.
AVK>Например?

Итак, цели: выделение абстракций и их комбинирование.
Чего нет в Java: а) множественное наследование; б) шаблоны; в) инлайнирование (как инструмент совмещения структурированных абстракций и эффективности исполнения).

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

ГВ>>Также не согласен с доводом, что C++ — это язык для низкоуровневых систем. C++ — язык для сложных и больших программ, а не только низкоровневых.
AVK>Вот как раз для сложных и болшьших программ С++ подходит хуже нежели шарп и джава.

Абсолютно не согласен. Вопрос в том — что именно называть большой и сложной программой. Собственно, к чему я клоню: если под "большой системой" понимать систему состоящую из большого количества наивно реализованных элементов (то есть, по минимуму использующих общесистемные абстракции), то — да: Java, C#, VBS, xxxScript. Соответственно, потери на сопровождение такой системы — экспонента от количества её "возможностей", которыми часто называются функциональные точки (экраны, отчёты и пр.). Мне, например, приходилось сталкиваться с "большими и сложными" биллинговыми программами, написанными на SQL+VB, где основная сложность — поддержание адекватности структуры отчётов структуре БД, что суть прямое нарушение принципа абстракции пользовательского интерфейса (отчётов) от деталей реализации (структуры БД). Так основное время команды уходило на вот это самое бестолкове сопровождение.

Прикол как раз в том, что когда работаешь со скриптовыми языками, часто даже не задаёшь себе тех вопросов, которые не боишься ставить, используя C++. А C# и Java я как раз и считаю разновидностью скриптовых языков, посольку ИМХО они апеллируют к реализации каких-то элементов системы на других языках.

К примеру, именно отсутствие в Java (и в C#) шаблонов и приведёт либо к разбуханию большой и сложной программы, либо к снижению эффективности её работы, за счёт необходимости run-time-приведения типов (виртуальные функции). Не считая уже того, что в Java невозможно будет перенести на транслятор такую же часть контроля корректности программирования, как и в C++. Т.е., Java-программы будет сложнее сопровождать, если конечно, не требовать от пользователя поставить 4-х процессорный сервер P4-2200 под 10-пользовательскую CRM. ;)

ГВ>> Или зачем там так развиты средства комбинирования абстракций? Так что, думаю, что если современный новичок и не столкнётся с C++, то только в том случае, если никогда не будет заниматься сложными программами.
AVK>Чтобы создавать большие проекты на С++ нужно быть совсем не новичком.

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

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

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

ГВ>>Также не согласен с доводом, что C++ — это язык для низкоуровневых систем. C++ — язык для сложных и больших программ, а не только низкоровневых. Или зачем там так развиты средства комбинирования абстракций? Так что, думаю, что если современный новичок и не столкнётся с C++, то только в том случае, если никогда не будет заниматься сложными программами.

A>Не бывает языков для систем, бывают языки для слоев!

А слой, по-твоему, не система? :no: Как раз-таки, большая и сложная система. ;)

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

ГВ>Сразу вопрос. Что такое нормальные property и event? Какая реализация, например, событий, была бы "логичной"?
Такая как в шарпе.


ГВ>Каким, например, должен быть механизм передачи событий? Должен ли он предусматривать межпроцессную передачу данных? Должна ли принимающая сторона уметь идентифицировать отправителя события? Должна ли создаваться очередь событий? Варианты ответов на эти вопросы прекрасно можно оформить библиотеками классов на C++! Зачем навязывать самим себе "единственно правильную" модель реализации?
Во, начинается. Во многих современных языках события реализуются на уровне языка, а в С++ можно библиотеками. Можно конечно, но не удобно.

ГВ>Для C# и Java эти вопросы решались исходя из целей этих языков. C# — поддержание амбиций Microsoft (т.е., внедрение поддержки модели COM),
Гы.

ГВ>а Java... кстати, в Java event-ов и property на уровне языка нет! Есть библиотеки!
Я в курсе. Ничего хорошего в этом нет.

AVK>>Как раз реализация определенных концепций на таких языках оказывается зачастую более понятной, простой и красивой. Сравни к примеру COM и объекты дотнета или джавы.
ГВ>Ну, во-первых. Сравнивать COM (в сущности — способ структурирования коммуникаций)
COM это COM, т.е. компонентная модель. И не надо никаких лишних сущностей придумывать. Принцип бритвы Оккама помнишь?

ГВ> с моделью объектов в языках реализации не совсем корректно.
Очень даже корректно. Решаемые задачи абсолютно идентичны.

ГВ>Реализация COM для C++ в Miscrosoft-овском варианте обладает теми же чертами, что и плоский API на C с небольшими вкраплениями объектного подхода. То есть — можно было бы и лучше.
В рамках С++, при оставлении самого языка неизменным, вряд ли.

ГВ> Потом, не надо забывать о том, что, действительно, по сравнению с C++ (что, впрочем, ИМХО, справедливо для любого языка общего назначения) языки специального назначения обладают преимуществами в специальных областях. Ну, например, VBS или Perl лучше подходят для скриптования идиотской модели объектов ClearQuest, нежели C++, хотя и там время от времени приходится использовать его.

ГВ>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun, а C# + CLR — как противовес Java в той же области,
Это твои домыслы. И джава и дотнет созданы как средства разработки приложений.

ГВ> то, естественно, они в этом смысле обладают преимуществами перед C++. Тогда как C++ создан для упрощения решения проблем программирования. Что называется — почувствуйте разницу ;)
Программировать на шарпе и джаве на порядок проще чем на плюсах. Так что ты попробуй для начала и почувствуй разницу. А разница действительно существенна. В отсутствие рефлекшена и получаются монстры вроде COM с его IUnknown,QueryInterface и IDispatch.

ГВ>И здесь я действительно согласен с тем, что на C# проще реализовать что-то на базе модели COM. Но, ёлки-палки, COM — это не способ построения абстракций уровня реализации, он слишком ограничен для этого!
Не, ты не понял. В шарпе COM оставлен только для совместимости. У него своя собственная объектная модель.

ГВ>Итак, цели: выделение абстракций и их комбинирование.
ГВ>Чего нет в Java: а) множественное наследование; б) шаблоны; в) инлайнирование (как инструмент совмещения структурированных абстракций и эффективности исполнения).
Тебе списочек того что нет в плюсах привести? Именно в плане абстрагирования. Тем паче что к собственно абстракциям имеет отношении только первый пункт. Остальные это только способ решить проблемы производительности путем усложнения модели. Виртуальные контейнеры понятнее и проще в использовании чем темплейты, единственный их недостаток это производительность. Что же касается инлайнирования, то, если верить VladD2, то VC при включении оптимизации на него просто кладет и сам решает где и что инлайнить.

ГВ>Предлагать назвать что-то, имеющееся в Java, что нельзя сделать в C++ — было бы подставой тебя с моей стороны, поскольку ничего такого нет, за исключением возможности переноса байт-кода.
Рефлекшен я уже приводил. Для дотнета это еще Reflection.Emit, CodeDOM. А самое главное — встроенная в язык компонентная модель. Для того чтобы подгружать на лету объекты не нужно воротить COM.

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

ГВ>Вопрос в том — что именно называть большой и сложной программой.
Большую и сложную программу. Например ERP.

ГВ>Прикол как раз в том, что когда работаешь со скриптовыми языками, часто даже не задаёшь себе тех вопросов, которые не боишься ставить, используя C++. А C# и Java я как раз и считаю разновидностью скриптовых языков, посольку ИМХО они апеллируют к реализации каких-то элементов системы на других языках.
Глупости это все. Скриптами обычно называют языки в которых невозможно конструировать новые типы(объекты).

ГВ>К примеру, именно отсутствие в Java (и в C#) шаблонов и приведёт либо к разбуханию большой и сложной программы, либо к снижению эффективности её работы, за счёт необходимости run-time-приведения типов (виртуальные функции). Не считая уже того, что в Java невозможно будет перенести на транслятор такую же часть контроля корректности программирования, как и в C++.
В джаве в разы больше контроля над рантаймом. И сопровождение джавовских программ в разы проще. В сях даже стек-трейса нет.

ГВ> Т.е., Java-программы будет сложнее сопровождать, если конечно, не требовать от пользователя поставить 4-х процессорный сервер P4-2200 под 10-пользовательскую CRM. ;)
Через пару лет такой сервер будет считаться минимальной и дешевой конфигурацией :)

AVK>>Чтобы создавать большие проекты на С++ нужно быть совсем не новичком.

ГВ>Хммм... Просто голову не надо забивать "быстрым р-р-результатом" :maniac: и читать соответствующую литературу, тогда и не будет проблем с построением абстракций. И, кстати, результатов получается больше и в целом — быстрее, если учесть необходимое сопровождение. Впрочем, соглашусь, что какой-никакой опыт "шишек" необходим.
Знаешь, мой опыт показывает обратное. При написании программ на плюсах или Дельфи ошибок получается в разы больше чем на джаве или дотнете, особенно если программеры только учаться.
Еще можешь посмотреть средний процент успешных проектов на джаве и плюсах, статистика общедоступна.

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

AVK>>В чем логика отсутствия нормальных property или event? Почему это сложно ввести в состав языка? В чем логика отсутствия нормального рефлекшена?

ГВ>Сразу вопрос. Что такое нормальные property и event? Какая реализация, например, событий, была бы "логичной"? Каким, например, должен быть механизм передачи событий? Должен ли он предусматривать межпроцессную передачу данных? Должна ли принимающая сторона уметь идентифицировать отправителя события? Должна ли создаваться очередь событий? Варианты ответов на эти вопросы прекрасно можно оформить библиотеками классов на C++! Зачем навязывать самим себе "единственно правильную" модель реализации?

Как раз не на уровне языка сделать это элегантно весьма проблематично. Получится какой-нибудь уродский набор классов или макросов.

Мне, кстати, тоже совершенно непонятно, и даже обидно, почему язык, на котором я программирую более 10 лет, остановился в своём развитии. Кто помнит, когда последний раз произошли существенные изменения в языке? Это были шаблоны и RTTI, но это было тоже около 10 лет назад. С тех пор — ничего. Очень жаль. Если в C++ не произойдёт никаких существенных изменений в ближайшие пару лет, то можно будет уверенно заявлять, что этот язык мёртв и давать сабжевые советы просто глупо и даже в какой то степени преступно.

Все основные отличия C++ от других языков на самом деле заключаются лишь в трёх следующих вещах:

1. Шаблоны — которые, будем надеятся, скоро появятся и в C# и в Java.
2. Множественное наследование — которое является синонимом плохого дизайна.
3. Адресной арифметикой — которая наследована от C.

В основном все пальцы C++ программеров в отношении других языков относятся к третьему пункту. Я так крут что знаю как использовать указатели, и я даже знаю, как работает memcpy :super:

Это очень круто, только у меня есть вопрос — а зачем? 95% современных задач требуют умения работы с базами данных, а не с указателями.

ГВ>Для C# и Java эти вопросы решались исходя из целей этих языков. C# — поддержание амбиций Microsoft (т.е., внедрение поддержки модели COM)

Совершенно неверное и некомпетентное утверждение. Более того, как правило все инсинуации в отношении MS либо безосновательны, либо не выдерживают элементарной критики, либо основаны на том, что я бы тоже срубил пару лимонов в своей деревне, если бы я был Бил Гатес.

Аргументы, плиз, в студию. Мы их рассмотрим и может быть согласимся, может просто посмеёмся, но скорее всего поспорим.

AVK>>Как раз реализация определенных концепций на таких языках оказывается зачастую более понятной, простой и красивой. Сравни к примеру COM и объекты дотнета или джавы.

ГВ>Ну, во-первых. Сравнивать COM (в сущности — способ структурирования коммуникаций) с моделью объектов в языках реализации не совсем корректно.

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

[skip]

ГВ>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun,

Проблемы переносимости не существует, всё это всего лишь маркетинг.

ГВ>а C# + CLR — как противовес Java в той же области,

возмножно это можно включить в список причин...

ГВ>то, естественно, они в этом смысле обладают преимуществами перед C++. Тогда как C++ создан для упрощения решения проблем программирования. Что называется — почувствуйте разницу ;)

Не чувствую ни одой разницы. Что такое в C++ "упрощение решения проблем программирования"?

Я как-то сделал маленький эксперимент. Распечатал все тексты одного COM объекта, включая idl-файлы, h-файлы и всякие разные cpp. Получилось 14 листов печатного текста. Затем я переписал тот же COM объект на C#. Результат — 4 страницы печатного текста. Причем, если убрать бизнес логику, то размер заготовки будет 1 к 7. Где тут нафиг C++ упрощает проблемы? Не смешите мои тапочки (c) Один из посетителей RSDN.

ГВ>И здесь я действительно согласен с тем, что на C# проще реализовать что-то на базе модели COM. Но, ёлки-палки, COM — это не способ построения абстракций уровня реализации, он слишком ограничен для этого!
ГВ>:crash:

Он не ограничен, он — мёртв. COM is dead, that thing is really dead! COM больше не нужнен самой MS, для неё это отработанный шлак. В десктоп программах он возможно ещё может найти своё место, но что касается распределённых приложений, то MS на него забила конкретно. И это правильно!

ГВ>>> Я полагаю, что для таких целей C++ содержит больше выразительных средств, чем Java.
AVK>>Например?

ГВ>Итак, цели: выделение абстракций и их комбинирование.
ГВ>Чего нет в Java: а) множественное наследование; б) шаблоны; в) инлайнирование (как инструмент совмещения структурированных абстракций и эффективности исполнения).

а) в большиестве случаев решается использованием интерфейсов,
б) необходимо по жизни в основном для типизированных контейнеров, и в том же C# многие вещи запросто решаются при помощи foreach + ждем следующей версии языка.
в) интересный термин — инлайнирование . По сути, перекладывание задач оптимизации на плечи программиста. Временные издержки нашего времени, ничего более.

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

Не надо обольщаться и делать поспешные заявления. Хотите пример, получите — приведите код безапасной работы с файлом на Java, например, открытие файла, запись строки данных и закрытие. При этом мы учитывем возможность возникновения исключительных ситуаций. На C++ это делается в 2 строки кода. Хотелось бы увидеть более простой код на Java.

ГВ>Прикол как раз в том, что когда работаешь со скриптовыми языками, часто даже не задаёшь себе тех вопросов, которые не боишься ставить, используя C++. А C# и Java я как раз и считаю разновидностью скриптовых языков, посольку ИМХО они апеллируют к реализации каких-то элементов системы на других языках.

Кто именно считает? Я слышу такое утверждение первый раз.

ГВ>К примеру, именно отсутствие в Java (и в C#) шаблонов и приведёт либо к разбуханию большой и сложной программы, либо к снижению эффективности её работы, за счёт необходимости run-time-приведения типов (виртуальные функции).

Да нормально пока... Кроме того ждём следующих версий языков. К тому же C#'у всего лишь полгода, C++ уже 20 лет, но мне пока больше не нравяться недостатки последноего.

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

Я пишу на C++ более 10 лет, т.е. мне не надо рассказывать о его достоинствах и недостатках. Я знаю и использую COM примерно 5 лет, соответсвенно знаком не только с базовыми концепциями и основами, но и деталями этой технологии. Я не знаю Java совсем, поэтому всё приму на веру. Я больше года работаю с C# и .NET, соответственно могу, как минимум, рассуждать об их достоинствах и недостатках. Давайте разговаривать по существу. Если .NET в вашем понимании полное фуфло, а C++ is cool forever и для новичка это как раз то что надо, то я бы хотел услышать аргументированные доводы почему. В противном случае, мягко говоря, это введение в заблуждение подрастающего поколения. Что может оказаться непростительным ;)

AVK>Глупости это все. Скриптами обычно называют языки в которых невозможно конструировать новые типы(объекты).

-- Подонок — значит, человек без денег
-- Никогда не слышал такой формулировки. Но если так, можете считать меня подонком
(К.Саймак."Денежное дерево")

Это я к тому, что высшей странности определение скрипта Если так, то можно считать скриптами C и классический Паскаль.

мне казалось, что скриптами обычно назвыают простые программы, используемые с утилитарной целью и интрепретируемые простым интертрепатором. Но, с другой стороны, есть perl. Который и не очень простой и даже не очень интертрепатор, да и программы на нем навороченные иногда пишут. А все-же "скрипт". Поди — разберись

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

IT>Это я к тому, что высшей странности определение скрипта Если так, то можно считать скриптами C и классический Паскаль.
Это кто тебе сказал что в сях и паскале нельзя конструировать новые типы?

IT>мне казалось, что скриптами обычно назвыают простые программы, используемые с утилитарной целью и интрепретируемые простым интертрепатором. Но, с другой стороны, есть perl. Который и не очень простой и даже не очень интертрепатор, да и программы на нем навороченные иногда пишут. А все-же "скрипт". Поди — разберись
Вот потому я и написал "обычно". Четкого определения скрипта наверное не существует.

IT>>Это я к тому, что высшей странности определение скрипта Если так, то можно считать скриптами C и классический Паскаль.
AVK>Это кто тебе сказал что в сях и паскале нельзя конструировать новые типы?

Хм... если ты имеешь в виду struct и record и другие составные типы, то тогда php — тоже не скрипт и javascript (как ни странно) — тоже не скрипт

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

M.NET>Здравствуйте RSDNer, Вы писали:

RSDN>>Господа! Хочу заняться программированием на С++. Посоветуйте с чего начать: VS6, либо С# (.Net). Последняя версия посовременнее будет, но, возможно, и посложнее. Посоветуйте. Заранее благодарен, спасибо.

M.NET>Изучай С#. Позно уже за С++ браться. Ну уж если очень хочется, то берём Страуструпа, Мейерса, Александреску и пр.

С# не позиционируется как замена C++. Какое может быть "поздно"?

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

IT>Мне, кстати, тоже совершенно непонятно, и даже обидно, почему язык, на котором я программирую более 10 лет, остановился в своём развитии. Кто помнит, когда последний раз произошли существенные изменения в языке? Это были шаблоны и RTTI, но это было тоже около 10 лет назад.

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

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

Не канает. Я тебе могу точно сказать что C++ не будет меняться
до 2004 года. Пока не кончится immutability time, как записано в
стандарте.

IT>Все основные отличия C++ от других языков на самом деле заключаются лишь в трёх следующих вещах:

IT>1. Шаблоны — которые, будем надеятся, скоро появятся и в C# и в Java.
IT>2. Множественное наследование — которое является синонимом плохого дизайна.

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

Я не считаю множественное наследование синонимом плохого дизайна. Есть очень много задач которые с его помощью решаются гораздо красивее чем без него(если кто-то хочет поспорить то welcome). Кончено любое мощное средство может быть использовано неправильно.

IT>3. Адресной арифметикой — которая наследована от C.

IT>В основном все пальцы C++ программеров в отношении других языков относятся к третьему пункту. Я так крут что знаю как использовать указатели, и я даже знаю, как работает memcpy
IT>Это очень круто, только у меня есть вопрос — а зачем? 95% современных задач требуют умения работы с базами данных, а не с указателями.

Адесная арифметика действительно очень удобно, но не более. Например в Delphi ее нет и почти никто не страдает. Но и в Delphi и в C++ есть ручное управление памятью, вот это все-таки рулит. Я понимаю что это же и вызывает некоторые проблемы, как утечка памяти.Но не смотря на все утечки память занимаемая програмами на C++ меньше в десятки раз чем у программ на Java и с .net видимо то же самое.

ГВ>>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun,

IT>Проблемы переносимости не существует, всё это всего лишь маркетинг.

Да практика порказывает что переносить исходники проще чем саму программу.
Кроссплатформенных библиотек достаточно много.

A>Ты знаешь несколько лет назад все спорили нужно множественное наследование или нет. Поклонники pascal сказали что нет, и не сделали его там, и вроде как всех запинали. Но тут стала популярной микрософтовская технология COM, и все
A>противники множественного наследования как-то хором заткнулись. И под шумок оно появилось и в Delphi. Правда там оно появилось в слегка обрезаной форме т.е. там в данный момент есть множественное наследование интерфейса, но не реализации.

Странное толкование. Множественное наследование ввел Страуструп и это было именно наследование реализаций.
COM предполагает предоставление объектом нескольких интерфейсов и это не очень похоже на множественное наследование. Нужны интерфейсы, легко реализуются, просты для понимания — ну вот они и появляются в object pascal и java.

Я считаю, что их нельзя рассматривать как "урезанную версию" множественного наследования, несмотря на то, что в C++ интерфесы соответствуют множественному наследованию абстрактных классов.

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

A>Адесная арифметика действительно очень удобно, но не более. Например в Delphi ее нет и почти никто не страдает. Но и в Delphi и в C++ есть ручное управление памятью, вот это все-таки рулит. Я понимаю что это же и вызывает некоторые проблемы, как утечка памяти.Но не смотря на все утечки память занимаемая програмами на C++ меньше в десятки раз чем у программ на Java и с .net видимо то же самое.
Вот представь себе что в сервере, написанном на С++ есть утечка скажем в 10К в минуту. Пусть сам сервер занимает 1М в памяти. Пусть тот же сервер на джаве занимет уже 10М. Через неделю работы плюсовый сервер отожрет 100М. Идея понятна?

A>>Адесная арифметика действительно очень удобно, но не более. Например в Delphi ее нет и почти никто не страдает.

Хм... sure? Или что мы понимаем под адресной арифметикой? Арифметику над указателями? Да за ради бога — прибавляй, вычитай... Сколько влезет. Преобразуй в integer и вообщее... хоть в степень возводи

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

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

AVK>Вот представь себе что в сервере, написанном на С++ есть утечка скажем в 10К в минуту. Пусть сам сервер занимает 1М в памяти. Пусть тот же сервер на джаве занимет уже 10М. Через неделю работы плюсовый сервер отожрет 100М. Идея понятна?

программа на Java с 3 окнами уже занимает 50M, ты просто не сможешь написать
прогу на Java занимающей 10M в памяти. Т.е. получается что если сервер перезагружается раз в неделю то даже 10K в минуту терпимо

Кроме того сервера на C++ обычно пишутся квалифицированными людьми и они пишут без утечек. Стабильная утечка памяти 10K в минуту элементарно отлавливается(Bounds checker еще никто не отменял)

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

A>>>Адесная арифметика действительно очень удобно, но не более. Например в Delphi ее нет и почти никто не страдает.

IT>Хм... sure? Или что мы понимаем под адресной арифметикой? Арифметику над указателями? Да за ради бога — прибавляй, вычитай... Сколько влезет. Преобразуй в integer и вообщее... хоть в степень возводи

Ключевое слово "преобразуй в integer". Это сразу на тебя накладывает ограничения
1) рамер указателя равен размеру integer-а, это не на всех платформах так
2) Компилятор просто умывает руки и не собирается проверять правильность
твоих действий, ты можешь случайно преобразовать указатель в int, а потом
преобразовать его в указатель другого типа что будет неверно, но компилятор
ничего тебе не скажет. Вот после этого и думай какой язык строже типизирован.

Вообщем это методы обхода отсутствия адресной арифметики, а не сама адресная арифметика.

На самом деле под этим понимается то что к указателю можно прибавлять числа и
что их можно исполдьзовать как массивы. Меня до сих пор забавляет как на Delphi реализуется массив неопределенного размера (на сырой памяти, втроенный тип не в счет его в WinAPI нельзя передавать)

Идея такова: описывает тип массива в 10000000 элементов. Описываем на него
указатель. А потом присваиваем этому указателю участок памяти например на n=1000
элементов(притом присвоить просто нельзя, надо применить преобразование которое компилятор не может проверить на правильность) и работаем. При этом если включен Range Check компилятор проверяет чтобы индекс массива не был больше 10000000 ,
хотя при привышении 1000 будет AV.

Всетаки идея из C чуть естественней там берешь указатель на первый элемент
и применяешь к нему скобки []. Т.е. в теории предполагается что любой указатель
показывает не на 1 элемент, а на массив элементов и его можно сдвигать по массиву.

A>Ключевое слово "преобразуй в integer".

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

A>2) Компилятор просто умывает руки и не собирается проверять правильность
A>твоих действий, ты можешь случайно преобразовать указатель в int, а потом
A>преобразовать его в указатель другого типа что будет неверно, но компилятор
A>ничего тебе не скажет. Вот после этого и думай какой язык строже типизирован.

А что — в С/C++ этого нельзя сделать?
И что — в C/C++ пожно напрямую указатели взять да перемножить, какой бы смысл в этом ни был?

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

A>Идея такова: описывает тип массива в 10000000 элементов. Описываем на него
A>указатель

A>Всетаки идея из C чуть естественней там берешь указатель на первый элемент
A>и применяешь к нему скобки [].

Да нет разницы-то.. Просто в паскале не так близко сведены указатель и массив, вот и все. А смысл тот-же.
И техника работы по сути та же. Ты берешь и присваиваешь указателю нужный адрес после чего работаешь как с массивом А уж [] у тебя или ^array — ну какая разница?

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

A>>2) Компилятор просто умывает руки и не собирается проверять правильность
A>>твоих действий, ты можешь случайно преобразовать указатель в int, а потом
A>>преобразовать его в указатель другого типа что будет неверно, но компилятор
A>>ничего тебе не скажет. Вот после этого и думай какой язык строже типизирован.

IT>А что — в С/C++ этого нельзя сделать?

Можно но никто не делает т.к. не нужно. А вообще по стандарту
преобразовывать указатели в int нельзя т.к. может получится
компилятор C++ со сборщиком мусора который твой объект соберет
т.к. на него нет нормальных указателей. Правда коммерческих
применений сборщик месора в C++ не нашел. Так экперименты.

IT>И что — в C/C++ пожно напрямую указатели взять да перемножить, какой бы смысл в этом ни был?

Нет нельзя. Можно вычитать указатели одного типа(получится расстояние между
элементами) и складывать/вычитать указатель и число(получится указатель на
элемент +-n )

IT>Да нет разницы-то.. Просто в паскале не так близко сведены указатель и массив, вот и все. А смысл тот-же.
IT>И техника работы по сути та же. Ты берешь и присваиваешь указателю нужный адрес после чего работаешь как с массивом А уж [] у тебя или ^array — ну какая разница?

Да на самом деле то никакой. Я же сказал в самом первом сообщении
что в Pascal почти никого не расстраивает отсутствие адресной арифметики.

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

A>программа на Java с 3 окнами уже занимает 50M, ты просто не сможешь написать
A>прогу на Java занимающей 10M в памяти.
Ну это ты загнул. 50М это уже EJB-серверы. Типичный десктоп 10-20 метров и будет.


A>Т.е. получается что если сервер перезагружается раз в неделю то даже 10K в минуту терпимо
10К в минуту это я взял по минимуму. При приличной нагрузке может быть намного больше. Да и перегружать сервер раз в неделю не всегда возможно.

A>Кроме того сервера на C++ обычно пишутся квалифицированными людьми и они пишут без утечек.
Вот о том я и говорю — чтобы качественно писать на плюсах нужна высокая квалификация. А про отсутствие утечек не надо — обычно проходит несколько версий прежде чем все утечки удается пофиксить.

A>Стабильная утечка памяти 10K в минуту элементарно отлавливается(Bounds checker еще никто не отменял)
Увы, это не так.

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

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

ГВ>>Сразу вопрос. Что такое нормальные property и event? Какая реализация, например, событий, была бы "логичной"?
AVK>Такая как в шарпе.

Проясни, пожалуйста, в чём ты видишь её особенную логичность?

ГВ>>Каким, например, должен быть механизм передачи событий? Должен ли он предусматривать межпроцессную передачу данных? Должна ли принимающая сторона уметь идентифицировать отправителя события? Должна ли создаваться очередь событий? Варианты ответов на эти вопросы прекрасно можно оформить библиотеками классов на C++! Зачем навязывать самим себе "единственно правильную" модель реализации?
AVK>Во, начинается. Во многих современных языках события реализуются на уровне языка, а в С++ можно библиотеками. Можно конечно, но не удобно.

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

Два. Не согласен. Именно это (наличие возможности) как раз и удобно. ИМХО, всегда удобнее, если тебе не навязывают некое решение как единственно верное. Напоминаю, что топик начинался с обсуждения развития начинающего программиста и выбираемых для этого средств. Так вот, я полагаю, что C++ косвенно способствует развитию культуры программистского мышления, нежели C# или Java. Кроме того, я вижу в твоём доводе противопоставление — среда, где "всё есть" в виде встроенного набора против среды с развитым набором библиотек. ИМХО, второй вариант лучше в контексте топика (и не только), поскольку после изучения библиотек программист сможет написать свои, реализующие его модель абстракций, то есть, ту, которая лучше подходит под его задачи.

Кстати. Здесь я согласился бы с тем, что .Net и библиотеки Java предлагают большой набор готовых решений разных практических проблем, что, по сути и является задачей библиотек.

ГВ>>Для C# и Java эти вопросы решались исходя из целей этих языков. C# — поддержание амбиций Microsoft (т.е., внедрение поддержки модели COM),
AVK>Гы.

Интересный контраргумент ;)

ГВ>>а Java... кстати, в Java event-ов и property на уровне языка нет! Есть библиотеки!
AVK>Я в курсе. Ничего хорошего в этом нет.

AVK>>>Как раз реализация определенных концепций на таких языках оказывается зачастую более понятной, простой и красивой. Сравни к примеру COM и объекты дотнета или джавы.
ГВ>>Ну, во-первых. Сравнивать COM (в сущности — способ структурирования коммуникаций)
AVK>COM это COM, т.е. компонентная модель. И не надо никаких лишних сущностей придумывать. Принцип бритвы Оккама помнишь?

Помню. Только ещё помню довольно редкие случаи корректного его (принципа) применения. Кстати, какую сущность я здесь придумал?

ГВ>> с моделью объектов в языках реализации не совсем корректно.
AVK>Очень даже корректно. Решаемые задачи абсолютно идентичны.

Упс. :) COM (ИМХО, кстати, равно как и CORBA, в противовес которой и развит COM/DCOM) — способ структурировать взаимодействия объектов, адекватный на уровне связи больших элементов программы. Здесь я полагаю, что некорректно само использование COM как концепции архитектуры реализации.

ГВ>>Реализация COM для C++ в Miscrosoft-овском варианте обладает теми же чертами, что и плоский API на C с небольшими вкраплениями объектного подхода. То есть — можно было бы и лучше.
AVK>В рамках С++, при оставлении самого языка неизменным, вряд ли.

Проиллюстрируй. В защиту своего довода приведу: а) код, генерируемый MIDL включает поддержку pure-C и не использует возможностей C++ по реализации абстракций в полном объёме и б) Модель, реализованная в ATL — не единственная возможная. Одно управление BSTR на уровне системы чего стоит.

Кроме того, реализовывать интерфейсы прямым наследованием от самих интерфейсов — тоже не самый лучший вариант. Да, он удобен в ряде случаев, но для большой системы необходимо множество интерфейсов и множество сущностей уровня реализации. Так что, неизбежно придётся вводить промежуточный слой, объединяющий реализацию интерфейсов COM с реализацией самой системы. Структура этого слоя сама по себе может быть сложной, если захочется уменьшить объём механической работы. Здесь бы и пригодились подходы, отличные от наследования.

ГВ>> Потом, не надо забывать о том, что, действительно, по сравнению с C++ (что, впрочем, ИМХО, справедливо для любого языка общего назначения) языки специального назначения обладают преимуществами в специальных областях. Ну, например, VBS или Perl лучше подходят для скриптования идиотской модели объектов ClearQuest, нежели C++, хотя и там время от времени приходится использовать его.

ГВ>>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun, а C# + CLR — как противовес Java в той же области,
AVK>Это твои домыслы. И джава и дотнет созданы как средства разработки приложений.

C++ тоже создан как переносимый язык разработки приложений и в этом смысле эквивалентен C# или Java. Однако, переносимость подавалась как одно из основных преимуществ Java, а C# из дотнета слишком уж похож на Java и в его пользу тоже приводятся аргументы из серии переносимости. Честно говоря, я вижу за всей этой шумихой маркетинговую борьбу и не более того.

Объединяет их по отношению к C++ одно — кастрация его возможностей. Буду повторять в каждом абзаце — возможности C# и Java в части выражения абстракций — Уже, чем у C++. И это, кстати, подавалось в своё время как преимущество Java перед последним.

ГВ>> то, естественно, они в этом смысле обладают преимуществами перед C++. Тогда как C++ создан для упрощения решения проблем программирования. Что называется — почувствуйте разницу ;)
AVK>Программировать на шарпе и джаве на порядок проще чем на плюсах. Так что ты попробуй для начала и почувствуй разницу. А разница действительно существенна.

Вопрос: кому проще и по сравнению с кем и в каком контексте (на каких проектах)?

AVK> В отсутствие рефлекшена и получаются монстры вроде COM с его IUnknown,QueryInterface и IDispatch.

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

ГВ>>И здесь я действительно согласен с тем, что на C# проще реализовать что-то на базе модели COM. Но, ёлки-палки, COM — это не способ построения абстракций уровня реализации, он слишком ограничен для этого!
AVK>Не, ты не понял. В шарпе COM оставлен только для совместимости. У него своя собственная объектная модель.

Хорошо. Снимаю аргумент, как излишне эмоциональный.

ГВ>>Итак, цели: выделение абстракций и их комбинирование.
ГВ>>Чего нет в Java: а) множественное наследование; б) шаблоны; в) инлайнирование (как инструмент совмещения структурированных абстракций и эффективности исполнения).
AVK>Тебе списочек того что нет в плюсах привести? Именно в плане абстрагирования. Тем паче что к собственно абстракциям имеет отношении только первый пункт.

Да, приведи список возможностей, если не затруднит. А мы рассмотрим ((c) Жеглов) ;)

AVK> Остальные это только способ решить проблемы производительности путем усложнения модели. Виртуальные контейнеры понятнее и проще в использовании чем темплейты, единственный их недостаток это производительность. Что же касается инлайнирования, то, если верить VladD2, то VC при включении оптимизации на него просто кладет и сам решает где и что инлайнить.

Значит так. Давай не будем путать калий с кальцием. Во-первых, VC — далёк от стандарта, и использовать его несосотятельность в этом смысле как аргумент против языка, им реализуемого — некорректно. Возьми другой компилятор, если этот тебя не устраивает. Во-вторых, шаблоны мало того, что вводились как инструмент повышения производительности, но не программы, а труда программиста, так на современном этапе развития они нередко позволяют сделать то, чего нельзя добиться с помощью наследования. Очень простой пример — шаблон метода с набором его специализаций в шаблоне класса. Такой метод принципиально может быть инстанцирован для любых типов аргументов, притом для некоторых типов аргументов он будет работать по специфическому алгоритму, отличному от общего. То, что MS VC++ 6.0 безобразно с этим работает — не аргумент против C++ как языка.

ГВ>>Предлагать назвать что-то, имеющееся в Java, что нельзя сделать в C++ — было бы подставой тебя с моей стороны, поскольку ничего такого нет, за исключением возможности переноса байт-кода.
AVK>Рефлекшен я уже приводил. Для дотнета это еще Reflection.Emit, CodeDOM. А самое главное — встроенная в язык компонентная модель. Для того чтобы подгружать на лету объекты не нужно воротить COM.

За рефлекшн ничего сказать не могу и принимаю обвинения в своей некомпетентности относительно этой детали, но тем не менее, хочу услышать почему Reflection.Emit нельзя реализовать на C++? А что до CodeDOM... Ну, никто не мешает вместе со своей программой таскать ещё и вагон компиляторов и генераторов и сделать унифицированный доступ к ним. Строго говоря, ничего нового в таком подходе нет. Только вопрос — зачем? И это — черта не языка, а инфраструктры (я склонен называть это — библиотеками). По второй части: объекты бывают разные. Одни разумно подгружать, используя COM, другие — из файлов, третьи — ещё откуда-то.

ГВ>>Абсолютно не согласен.
AVK>Ну да — при разработке джавы и шарпа во главу угла ставилось прежде всего ускорение разработки и уменьшение количества ошибок. Оказывается и у Sun и у MS нифига не вышло, не удалось переплюнуть даже древний C++.

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

ГВ>>Вопрос в том — что именно называть большой и сложной программой.
AVK>Большую и сложную программу. Например ERP.

Какую именно ERP? Если не затруднит, приведи хоть какие-нибудь метрики системы. И... ты уверен, что ERP действительно проще писать, используя языки с покорёженнной объектной моделью?

ГВ>>Прикол как раз в том, что когда работаешь со скриптовыми языками, часто даже не задаёшь себе тех вопросов, которые не боишься ставить, используя C++. А C# и Java я как раз и считаю разновидностью скриптовых языков, посольку ИМХО они апеллируют к реализации каких-то элементов системы на других языках.
AVK>Глупости это все. Скриптами обычно называют языки в которых невозможно конструировать новые типы(объекты).

Вот только грубить не надо. Тем более — с целью скрыть ответ не по существу. Некорректная аргументация плюс апелляция к авторитету. Я приводил своё мнение. Ты — прячешься за абстрактными "обычно".

ГВ>>К примеру, именно отсутствие в Java (и в C#) шаблонов и приведёт либо к разбуханию большой и сложной программы, либо к снижению эффективности её работы, за счёт необходимости run-time-приведения типов (виртуальные функции). Не считая уже того, что в Java невозможно будет перенести на транслятор такую же часть контроля корректности программирования, как и в C++.
AVK>В джаве в разы больше контроля над рантаймом. И сопровождение джавовских программ в разы проще. В сях даже стек-трейса нет.

Речь шла о переносе контроля на компилятор. Обрати внимание. На run-time всегда можно переложить ту же трассировку стека и пр. Вопрос только — зачем? Как раз-таки грамотное использование шаблонов и позволяет в ряде случаев избежать необходимости run-time-контроля за счёт строгой типизации и гарантирования компилятором того, что элементы программы совмещены корректно.

ГВ>> Т.е., Java-программы будет сложнее сопровождать, если конечно, не требовать от пользователя поставить 4-х процессорный сервер P4-2200 под 10-пользовательскую CRM. ;)
AVK>Через пару лет такой сервер будет считаться минимальной и дешевой конфигурацией :)

Не передёргивай. Я говорил о том, что к платформе будут предъявлены завышенные требования. Напоминаю: когда-то 640К считались пределом, достаточным для любых задач (слова Гейтса, если не ошибаюсь, но это — неважно). Так что, не переживай: через пару лет при таких делах потребуется 16-процессорный сервер. ;) Под словом "дела" я имею ввиду вполне реальное снижение "среднестатистической" квалификации программиста и ориентация разработчиков на попытки решения сложных задач упрощёнными способами.

AVK>>>Чтобы создавать большие проекты на С++ нужно быть совсем не новичком.

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

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

Во!!!!! Наконец-то!!! Ну спасибо, порадовал :) "...особенно, если программеры только учатся.". Иными словами — C++ — это язык, использование которого апеллирует к высокому уровню развития программиста. Тему топика помнишь?

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

[skip]

ГВ>>Сразу вопрос. Что такое нормальные property и event? Какая реализация, например, событий, была бы "логичной"? Каким, например, должен быть механизм передачи событий? Должен ли он предусматривать межпроцессную передачу данных? Должна ли принимающая сторона уметь идентифицировать отправителя события? Должна ли создаваться очередь событий? Варианты ответов на эти вопросы прекрасно можно оформить библиотеками классов на C++! Зачем навязывать самим себе "единственно правильную" модель реализации?

IT>Как раз не на уровне языка сделать это элегантно весьма проблематично. Получится какой-нибудь уродский набор классов или макросов.

Ну уж! Будет он уродским или нет — завистит от разработчика.

IT>Мне, кстати, тоже совершенно непонятно, и даже обидно, почему язык, на котором я программирую более 10 лет, остановился в своём развитии. Кто помнит, когда последний раз произошли существенные изменения в языке? Это были шаблоны и RTTI, но это было тоже около 10 лет назад. С тех пор — ничего. Очень жаль. Если в C++ не произойдёт никаких существенных изменений в ближайшие пару лет, то можно будет уверенно заявлять, что этот язык мёртв и давать сабжевые советы просто глупо и даже в какой то степени преступно.

Не согласен. :) Омертвеют задачи, которые привыкли решать на C++. Не более того. Но, поскольку задачи мертвеют редко ;), то и C++ никуда не денется. Пусть сначала достаточное количесвто стандартных компиляторов появится.

IT>Все основные отличия C++ от других языков на самом деле заключаются лишь в трёх следующих вещах:

IT>1. Шаблоны — которые, будем надеятся, скоро появятся и в C# и в Java.
IT>2. Множественное наследование — которое является синонимом плохого дизайна.

Множественное наследование — ещё не синоним плохого дизайна. Это — очень ограниченная трактовка. Забавно, но факт — реализация COM для C++ от Microsoft (я имею ввиду ATL) как раз и построена множественном наследовании. Это просто наблюдение, не более того.

IT>3. Адресной арифметикой — которая наследована от C.

IT>В основном все пальцы C++ программеров в отношении других языков относятся к третьему пункту. Я так крут что знаю как использовать указатели, и я даже знаю, как работает memcpy :super:

Ну, обобщать, наверное, не стоит...

IT>Это очень круто, только у меня есть вопрос — а зачем? 95% современных задач требуют умения работы с базами данных, а не с указателями.

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

ГВ>>Для C# и Java эти вопросы решались исходя из целей этих языков. C# — поддержание амбиций Microsoft (т.е., внедрение поддержки модели COM)

IT>Совершенно неверное и некомпетентное утверждение. Более того, как правило все инсинуации в отношении MS либо безосновательны, либо не выдерживают элементарной критики, либо основаны на том, что я бы тоже срубил пару лимонов в своей деревне, если бы я был Бил Гатес.

IT>Аргументы, плиз, в студию. Мы их рассмотрим и может быть согласимся, может просто посмеёмся, но скорее всего поспорим.

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

AVK>>>Как раз реализация определенных концепций на таких языках оказывается зачастую более понятной, простой и красивой. Сравни к примеру COM и объекты дотнета или джавы.

ГВ>>Ну, во-первых. Сравнивать COM (в сущности — способ структурирования коммуникаций) с моделью объектов в языках реализации не совсем корректно.

IT>Правильно. Это разные вещи с помощью которых решаются одни и те же задачи. Именно поэтому вполне уместно говорить об их эффективности.

Или о разумности их применения для решения одних и тех же задач...

[skip]

ГВ>>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun,

IT>Проблемы переносимости не существует, всё это всего лишь маркетинг.

Извини, не понял. Что — "всё"? Проблема переносимости или виртуальность её решения с помощью Java?

ГВ>>а C# + CLR — как противовес Java в той же области,

IT>возмножно это можно включить в список причин...

ГВ>>то, естественно, они в этом смысле обладают преимуществами перед C++. Тогда как C++ создан для упрощения решения проблем программирования. Что называется — почувствуйте разницу ;)
IT>Не чувствую ни одой разницы. Что такое в C++ "упрощение решения проблем программирования"?
IT>Я как-то сделал маленький эксперимент. Распечатал все тексты одного COM объекта, включая idl-файлы, h-файлы и всякие разные cpp. Получилось 14 листов печатного текста. Затем я переписал тот же COM объект на C#. Результат — 4 страницы печатного текста. Причем, если убрать бизнес логику, то размер заготовки будет 1 к 7. Где тут нафиг C++ упрощает проблемы? Не смешите мои тапочки (c) Один из посетителей RSDN.

Здесь создаёт проблемы реализация COM для C++ от Microsoft, а не C++ как таковой. Кроме того, я вижу в этом косвенное подтверждение тезиса о том, что C# поддерживает модель реализации, аналогичную COM.

ГВ>>И здесь я действительно согласен с тем, что на C# проще реализовать что-то на базе модели COM. Но, ёлки-палки, COM — это не способ построения абстракций уровня реализации, он слишком ограничен для этого!
ГВ>>:crash:

IT>Он не ограничен, он — мёртв. COM is dead, that thing is really dead! COM больше не нужнен самой MS, для неё это отработанный шлак. В десктоп программах он возможно ещё может найти своё место, но что касается распределённых приложений, то MS на него забила конкретно. И это правильно!

Ну что же, поздравим себя с этим и пойдём дальше. (c) кто-то
Тем не менее — ограниченность COM-овской модели и аналогичных никуда не делась. :crash:

[skip]

ГВ>>Итак, цели: выделение абстракций и их комбинирование.
ГВ>>Чего нет в Java: а) множественное наследование; б) шаблоны; в) инлайнирование (как инструмент совмещения структурированных абстракций и эффективности исполнения).

IT>а) в большиестве случаев решается использованием интерфейсов,

Да, но с потерей простоты реализации.

IT>б) необходимо по жизни в основном для типизированных контейнеров,
Вот! Иллюстрация моего тезиса о том, что ряда вопросов люди себе даже не задают. Кроме контейнеров у шаблонов есть ещё вагон областей применения — поищи в инете по словам "generic programming".
IT> и в том же C# многие вещи запросто решаются при помощи foreach + ждем следующей версии языка.

IT>в) интересный термин — инлайнирование . По сути, перекладывание задач оптимизации на плечи программиста. Временные издержки нашего времени, ничего более.

Мммм... Да нет так тут всё просто... Вызовы виртуальных функций не очень-то оптимизируешь вобщем...

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

IT>Не надо обольщаться и делать поспешные заявления. Хотите пример, получите — приведите код безапасной работы с файлом на Java, например, открытие файла, запись строки данных и закрытие. При этом мы учитывем возможность возникновения исключительных ситуаций. На C++ это делается в 2 строки кода. Хотелось бы увидеть более простой код на Java.

Если я правильно понимаю, то здесь у тебя опечатка — перевёрнуты C++ и Java. Если это правильно, то не вижу проблемы — реализуешь аналогичную библиотеку на C++ и полный вперёд. Хоть в одну строку уложи. Это — сравнение библиотек, а не языков.

Если же опечатки у тебя нет, то что тогда доказывать? ;)

ГВ>>Прикол как раз в том, что когда работаешь со скриптовыми языками, часто даже не задаёшь себе тех вопросов, которые не боишься ставить, используя C++. А C# и Java я как раз и считаю разновидностью скриптовых языков, посольку ИМХО они апеллируют к реализации каких-то элементов системы на других языках.

IT>Кто именно считает? Я слышу такое утверждение первый раз.

Я. Я так считаю. Этого вполне достаточно для приведения довода в качестве аргумента.

ГВ>>К примеру, именно отсутствие в Java (и в C#) шаблонов и приведёт либо к разбуханию большой и сложной программы, либо к снижению эффективности её работы, за счёт необходимости run-time-приведения типов (виртуальные функции).

IT>Да нормально пока... Кроме того ждём следующих версий языков. К тому же C#'у всего лишь полгода, C++ уже 20 лет, но мне пока больше не нравяться недостатки последноего.

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

Стоп! Если подходить таким образом, то никогда не сделаешь корректного вывода. Я сравнивал базовые модели языков. А аргументов против моих доводов на этом уровне практически не услышал. Пока, во всяком случае. Аргументы в пользу библиотек/инфраструктуры... не того класса, которого жду.

IT>Я пишу на C++ более 10 лет, т.е. мне не надо рассказывать о его достоинствах и недостатках. Я знаю и использую COM примерно 5 лет, соответсвенно знаком не только с базовыми концепциями и основами, но и деталями этой технологии. Я не знаю Java совсем, поэтому всё приму на веру.

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

IT>Я больше года работаю с C# и .NET, соответственно могу, как минимум, рассуждать об их достоинствах и недостатках. Давайте разговаривать по существу. Если .NET в вашем понимании полное фуфло, а C++ is cool forever и для новичка это как раз то что надо, то я бы хотел услышать аргументированные доводы почему. В противном случае, мягко говоря, это введение в заблуждение подрастающего поколения. Что может оказаться непростительным ;)

Стоп ещё раз. Я не говорю, что ".NET ... полное фуфло, а C++ is cool forever" и никогда так не скажу. Не надо приписывать мне такого способа обобщения. Снова повторюсь, я говорил о базовых моделях языков и их влиянии на развитие программиста как личности, обладающей абстрактным мышлением. И аргументов в пользу того, что у C# или Java — более совершенная модель, чем у C++ я пока не услышал. Скорее — услышал аргументы "против", а именно — "ждём появления темплейтов" и "ждём следующей версии".

Аргументация довода о преимуществах C++ перед Java сама по себе очень простая — C++ даёт больше возможностей по построению и комбинированию абстракций, нежели Java/C#. Пока что, этого никто не опроверг. Факт наличия библиотек, пусть даже встроенных, на данном уровне абстракции "не канает". Далее, я придерживаюсь мнения о том, что мозги лучше развивать со структурно сложными инструментами (C++), тогда будет легче использовать структурно более простые (C#, Java). Этого, собственно говоря, тоже никто не опроверг. Соответственно, не поровергли и исходной посылки — что наинать лучше с C++.

Спор же о преимуществах той или иной библиотеки в данном контексте считаю просто неуместным.

Здравствуйте Аноним, Вы писали:

А>Проясни, пожалуйста, в чём ты видишь её особенную логичность?
Чего пояснять? Возьми да посмотри.

AVK>>Во, начинается. Во многих современных языках события реализуются на уровне языка, а в С++ можно библиотеками. Можно конечно, но не удобно.
А>Раз. В каких языках? И даже если это так — то это ещё не аргумент. Мало ли где что и как реализуют? Тем-то и хорош C++, что позволяет реализовать много, предлагая набор конструктивов, а не готовых решений.
Ну да — то извращение, посредством которого реализованы события называется набором конструктивов? :)

А>Два. Не согласен. Именно это (наличие возможности) как раз и удобно. ИМХО, всегда удобнее, если тебе не навязывают некое решение как единственно верное.
Знаешь что я тебе скажу? Любой язык навязывает свои решения, даже ассемблер. Полностью избавиться от стандартных решений можно только программируя в машинных кодах. Системы создания приложений в своей эволюции стремяться как можно больше сделать автоматически, без участия программиста. Шарп и джава со своими рантаймами это следущий шаг в этом направлении. Так кто мешал довести С++ до их уровня? Или так и будем еще 30 лет топтаться на месте? Язык это не идол, на который нужно молиться. Он должен развиваться в соответствии с новыми реалиями. Вычислительные мощности и объемы памяти возросли в десятки тысяч раз, появилась уйма новых технологий, некоторые из которых революционны. А язык так и остался почти таким же. Не думаю что это нормально.

А> Напоминаю, что топик начинался с обсуждения развития начинающего программиста и выбираемых для этого средств. Так вот, я полагаю, что C++ косвенно способствует развитию культуры программистского мышления, нежели C# или Java.
Вот как раз именно развитию культуры он и не способствует. Многие паттерны на нем реализуются в разы сложнее. Т.е. вместо ковыряния с концепциями программирования он будет ковыряться с особенностями плюсов. Оно ему надо?
Ты ради интереса зайди на дотнетовский форум и посмотри сколько там вопросов по языку и компонентной модели. И сравни с количеством онных в плюсовом форуме.
Еще меня радует то что начиная писать на плюсах новичок натыкается на одни и те же грабли. До него на эти грабли наткнулись все, однако грабли так в языке и остались. И вместо того чтобы убрать их все начинают орать, мол ламеры, наступили. И забывают при этом что какое то время назад сами на них наступали.
Я вобще не понимаю откуда эта нелюбовь к изменению языка. Вон Борланд паскаль меняет не особо стесняясь и я не думаю что от этого стало хуже.

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

ГВ>>>Для C# и Java эти вопросы решались исходя из целей этих языков. C# — поддержание амбиций Microsoft (т.е., внедрение поддержки модели COM),
AVK>>Гы.
А>Интересный контраргумент ;)
Не хочется такую глупость опровергать.

AVK>>>>Как раз реализация определенных концепций на таких языках оказывается зачастую более понятной, простой и красивой. Сравни к примеру COM и объекты дотнета или джавы.
ГВ>>>Ну, во-первых. Сравнивать COM (в сущности — способ структурирования коммуникаций)
AVK>>COM это COM, т.е. компонентная модель. И не надо никаких лишних сущностей придумывать. Принцип бритвы Оккама помнишь?
А>Помню. Только ещё помню довольно редкие случаи корректного его (принципа) применения. Кстати, какую сущность я здесь придумал?
А ты свои слова перечитай еще раз.

ГВ>>> с моделью объектов в языках реализации не совсем корректно.
AVK>>Очень даже корректно. Решаемые задачи абсолютно идентичны.

А>Упс. :) COM (ИМХО, кстати, равно как и CORBA, в противовес которой и развит COM/DCOM) — способ структурировать взаимодействия объектов, адекватный на уровне связи больших элементов программы.
Во блин нагородил. Вот корба кстати по своему назначению соответствует только DCOM, да и то только его части. А мы о COM говорим, ты не забыл еще?

А>Здесь я полагаю, что некорректно само использование COM как концепции архитектуры реализации.
Концепция архитектуры реализации. Красиво звучит, но абсолютно бессмысленно. Ты анекдот про чукчу и подводную лодку знаешь? Так вот, ты не мудри, ты пальцем покажи какие конкретно задачи решает COM и не решает компонентная модель джавы и дотнета?

ГВ>>>Реализация COM для C++ в Miscrosoft-овском варианте обладает теми же чертами, что и плоский API на C с небольшими вкраплениями объектного подхода. То есть — можно было бы и лучше.
AVK>>В рамках С++, при оставлении самого языка неизменным, вряд ли.

А>Проиллюстрируй. В защиту своего довода приведу: а) код, генерируемый MIDL включает поддержку pure-C и не использует возможностей C++ по реализации абстракций в полном объёме и б) Модель, реализованная в ATL — не единственная возможная. Одно управление BSTR на уровне системы чего стоит.
Э нет, так не пойдет. Это ты утверждал что в MS идиоты и на самом то деле все можно сделать намного лучше. Вот и расскажи как это сделать.

А>Кроме того, реализовывать интерфейсы прямым наследованием от самих интерфейсов — тоже не самый лучший вариант. Да, он удобен в ряде случаев, но для большой системы необходимо множество интерфейсов и множество сущностей уровня реализации. Так что, неизбежно придётся вводить промежуточный слой, объединяющий реализацию интерфейсов COM с реализацией самой системы. Структура этого слоя сама по себе может быть сложной, если захочется уменьшить объём механической работы. Здесь бы и пригодились подходы, отличные от наследования.
А может просто ввести интерфейсы в язык? И все, и никаких сложных слоев.

ГВ>>>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun, а C# + CLR — как противовес Java в той же области,
AVK>>Это твои домыслы. И джава и дотнет созданы как средства разработки приложений.

А>C++ тоже создан как переносимый язык разработки приложений и в этом смысле эквивалентен C# или Java. Однако, переносимость подавалась как одно из основных преимуществ Java, а C# из дотнета слишком уж похож на Java и в его пользу тоже приводятся аргументы из серии переносимости. Честно говоря, я вижу за всей этой шумихой маркетинговую борьбу и не более того.
Ты не путай переносимость на уровне исходников и на уровне бинарников. Это разные вещи.

А>Объединяет их по отношению к C++ одно — кастрация его возможностей. Буду повторять в каждом абзаце — возможности C# и Java в части выражения абстракций — Уже, чем у C++. И это, кстати, подавалось в своё время как преимущество Java перед последним.
Вот такие вот стойкие защитники языка уже сколько раз пытались GC на плюсах реализовать. И чо то у них ничего не вышло пока. Не подскажешь почему?
И, это, ты так интересно забываешь про рефлекшен все время. Реализуй ка мне его на плюсах ввиде либы. А заодно может чего с динамической генерацией классов и CodeDOM придумаешь.

AVK>>Программировать на шарпе и джаве на порядок проще чем на плюсах. Так что ты попробуй для начала и почувствуй разницу. А разница действительно существенна.
А>Вопрос: кому проще и по сравнению с кем и в каком контексте (на каких проектах)?
Всем проще, в 95% проектов. Не проще в драйверах, в программах-числомолотилках с простым алгоритмом. Ну может еще где, всего не упомнишь.

AVK>> В отсутствие рефлекшена и получаются монстры вроде COM с его IUnknown,QueryInterface и IDispatch.
А>Принимаю возможные обвинения в некомпетентности, но не мог бы ты раскрыть причинно-следственную связь? Думаю, это всем будет интересно.
А чего тут раскрывать. Когда у тебя есть полная информация о типе объекта все эти комовские навороты просто не нужны.

AVK>>Тебе списочек того что нет в плюсах привести? Именно в плане абстрагирования. Тем паче что к собственно абстракциям имеет отношении только первый пункт.
А>Да, приведи список возможностей, если не затруднит. А мы рассмотрим ((c) Жеглов) ;)

Наверняка что то забуду, надеюсь меня поправят. Часть уже приводил. Итак
1) Рефлекшен
2) Эмиттинг кода
3) Поддержка ремоутинга на уровне языка (это в дотнете, в джаве все как в плюсах с дкомом, может немножко попроще). Никаких стабов и скелетонов, никаких idl и tlb. Все встроено в рантайм и не требует внимания программиста. Создание удаленного объекта сводится к оператору new.
4) Домены приложений. Т.е. можно создать изолированную от внешнего мира песочницу с ограниченными правами.
5) Поддержка потоков встроенная в язык.
6) Черт возьми, почему в плюсах нету try..finally?
7) Интерфейсы
8) GC
9) GAC (Global Assembly Cache, такая штука которая хранит все версии сборок и отдает нужные конкретному приложению. Т.е. никакого набора кучи mfcxx.dll, которые еще к тому же могут быть разных версий)
10) боксинг и анбоксинг. Т.е. простые типы вроде int и string не ломают объектную парадигму, являясь объектами и при этом не теряя эффективность.
11) Stack trace
12) Встроенная в язык и рантайм сериализация. Всем плюсовым аналогам до ней очень далеко.
13) Атрибуты.


AVK>> Остальные это только способ решить проблемы производительности путем усложнения модели. Виртуальные контейнеры понятнее и проще в использовании чем темплейты, единственный их недостаток это производительность. Что же касается инлайнирования, то, если верить VladD2, то VC при включении оптимизации на него просто кладет и сам решает где и что инлайнить.

А>Значит так. Давай не будем путать калий с кальцием. Во-первых, VC — далёк от стандарта, и использовать его несосотятельность в этом смысле как аргумент против языка, им реализуемого — некорректно.
ПОясняю. При этом VC является одним из самых быстрых компиляторов. Т.е. инлайнирование он делает весьма эффективно. Так зачем его тогда делать вручную, если оно автоматически неплохо получается?


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

А> Во-вторых, шаблоны мало того, что вводились как инструмент повышения производительности, но не программы, а труда программиста, так на современном этапе развития они нередко позволяют сделать то, чего нельзя добиться с помощью наследования. Очень простой пример — шаблон метода с набором его специализаций в шаблоне класса. Такой метод принципиально может быть инстанцирован для любых типов аргументов, притом для некоторых типов аргументов он будет работать по специфическому алгоритму, отличному от общего. То, что MS VC++ 6.0 безобразно с этим работает — не аргумент против C++ как языка.

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

AVK>>Рефлекшен я уже приводил. Для дотнета это еще Reflection.Emit, CodeDOM. А самое главное — встроенная в язык компонентная модель. Для того чтобы подгружать на лету объекты не нужно воротить COM.

А>За рефлекшн ничего сказать не могу и принимаю обвинения в своей некомпетентности относительно этой детали,
Это не деталь, это ключевая особенность. Именно она позволяет не воротить монстроидальных комов.


А> но тем не менее, хочу услышать почему Reflection.Emit нельзя реализовать на C++?
Теоретически можно. Но что то ручная генерация vtbl меня не радует. И про переносимость даже на уровне исходных кодов можно забыть. Все будет работать только с конкретной версией компилера и переписанным рантаймом.

А> А что до CodeDOM... Ну, никто не мешает вместе со своей программой таскать ещё и вагон компиляторов и генераторов и сделать унифицированный доступ к ним. Строго говоря, ничего нового в таком подходе нет. Только вопрос — зачем? И это — черта не языка, а инфраструктры (я склонен называть это — библиотеками).
Рантайм и библиотеки это несколько разные вещи, не находишь?

А> По второй части: объекты бывают разные. Одни разумно подгружать, используя COM, другие — из файлов, третьи — ещё откуда-то.
А еще лучше иметь единую технологию подгрузки которая будет устраивать всегда, а не городить коктейль из технологий. Или у сишников это называется правильным дизайном?

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

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

ГВ>>>Вопрос в том — что именно называть большой и сложной программой.
AVK>>Большую и сложную программу. Например ERP.

А>Какую именно ERP? Если не затруднит, приведи хоть какие-нибудь метрики системы.
А кто такие метрики системы?

А>И... ты уверен, что ERP действительно проще писать, используя языки с покорёженнной объектной моделью?
Уверен, пробовал. И объектная модель у них не покореженная, она по крайней мере не хуже плюсовой.

AVK>>Глупости это все. Скриптами обычно называют языки в которых невозможно конструировать новые типы(объекты).

А>Вот только грубить не надо. Тем более — с целью скрыть ответ не по существу. Некорректная аргументация плюс апелляция к авторитету. Я приводил своё мнение. Ты — прячешься за абстрактными "обычно".
Я не прячусь. Просто нет четкой границы между скриптами и нескриптами. Поэтому и обычно.

AVK>>В джаве в разы больше контроля над рантаймом. И сопровождение джавовских программ в разы проще. В сях даже стек-трейса нет.

ГВ>>> Т.е., Java-программы будет сложнее сопровождать, если конечно, не требовать от пользователя поставить 4-х процессорный сервер P4-2200 под 10-пользовательскую CRM. ;)
AVK>>Через пару лет такой сервер будет считаться минимальной и дешевой конфигурацией :)

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

А> Напоминаю: когда-то 640К считались пределом, достаточным для любых задач (слова Гейтса, если не ошибаюсь, но это — неважно). Так что, не переживай: через пару лет при таких делах потребуется 16-процессорный сервер. ;)
Ну и что в этом плохого, если этот сервер обходится дешевле чем работа программиста в течении месяца?

А> Под словом "дела" я имею ввиду вполне реальное снижение "среднестатистической" квалификации программиста и ориентация разработчиков на попытки решения сложных задач упрощёнными способами.
Не надо только думать что квалификация программиста определяется его умением писать низкоуровневый код. Самое интересное что часто подобное просто не нужно. Я на собеседовании к примеру даже не спрашиваю — умеет ли человек proxy stub для кома написать или похачить чего, не интересно это мне. А вот как раз умение просто решать сложные задачи очень ценно.

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

А>Во!!!!! Наконец-то!!! Ну спасибо, порадовал :) "...особенно, если программеры только учатся.". Иными словами — C++ — это язык, использование которого апеллирует к высокому уровню развития программиста. Тему топика помнишь?
Не надо переворачивать с ног на голову. Нормальное использование плюсов возможно только при высокой квалификации программера, причем большая часть этой квалификации — умение обходить плюсовые грабли.
А поскольку квалифицированных программеров мало, то в результате имеем низкое качество плюсовых проектов в нормальных условиях либо высокую их стоимость.
Тут вот какое дело — самое главное в мире софтостроения это деньги. И если в итоге новая технология позволяет решить задачу дешевле и качественней то это хорошая технология. А 16-типроцессорные сервера, идеологические убеждения программеров, средства разработки и прочая мишура это детали. И если создание систем на дотнете окажется экономически выгоднее нежели на традиционных плюсах, то никакой авторитеть страуструпа не поможет плюсам оставаться главным средствам разработки. Где сейчас идеологически правильная дековская альфа? А идеологически неправильные интел и amd снимают сливки с процессорного рынка и все мы благополучно пишем на x86. Идеологически правильные никсы очень круты, но все мы почему то пишем под Win32. Вот такие вот пирожки с котятами.

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

ГВ>Ну уж! Будет он уродским или нет — завистит от разработчика.
Вот только что то ни у кого пока ничего не вышло.

ГВ>Не согласен. :) Омертвеют задачи, которые привыкли решать на C++. Не более того. Но, поскольку задачи мертвеют редко ;), то и C++ никуда не денется. Пусть сначала достаточное количесвто стандартных компиляторов появится.
Самое обидное что на платформе Win32 этот язык такими темпами в нынешнем виде сильно потеряет в популярности.
Задачи непрерывно растут и он уже с ними не справляется. Оглянись — практически ни одной современной ERP системы в которой бизнес-логика пишется на пюсах. Везде свои языки какие нибудь.

ГВ>Множественное наследование — ещё не синоним плохого дизайна. Это — очень ограниченная трактовка. Забавно, но факт — реализация COM для C++ от Microsoft (я имею ввиду ATL) как раз и построена множественном наследовании. Это просто наблюдение, не более того.
А им деваться некуда, интерфейсов то нет.

ГВ>Здесь создаёт проблемы реализация COM для C++ от Microsoft, а не C++ как таковой.
Ну хорошо, приведи пример компонентной модели для плюсов которая не имела бы таких проблем. Я просто в свое время этим занимался и понимаю что реализовать подобное без изменений языка намного проще вряд ли возможно. Тыт тут корбу упоминал — так вот, ее реализация еще более мостроидальной выходит.

ГВ>Кроме того, я вижу в этом косвенное подтверждение тезиса о том, что C# поддерживает модель реализации, аналогичную COM.
Не аналогичную а выполняющую те же функции.

ГВ>Ну что же, поздравим себя с этим и пойдём дальше. (c) кто-то
ГВ>Тем не менее — ограниченность COM-овской модели и аналогичных никуда не делась. :crash:
Давай конкретно — в чем ограниченность дотнетовской модели?


IT>>а) в большиестве случаев решается использованием интерфейсов,
ГВ>Да, но с потерей простоты реализации.
Но зато с простотой дизайна. В больших проектах это важнее.

IT>>б) необходимо по жизни в основном для типизированных контейнеров,
ГВ>Вот! Иллюстрация моего тезиса о том, что ряда вопросов люди себе даже не задают. Кроме контейнеров у шаблонов есть ещё вагон областей применения — поищи в инете по словам "generic programming".
Ты давай пиши сюда. Знаешь сколько поисковик на этот запрос выдаст? И всерьез думаешь что я или IT будем сидеть и разгребать это? Я думаю что не думаешь. Тогда ты предлагаешь вещи которые заведомо невыполнимы? Интересный метод спора.
И потом, пусть у меня опыт активного общения с плюсами всего года 3, но IT на сях писал поболе и наверное знает о применении шаблона.

IT>>Кто именно считает? Я слышу такое утверждение первый раз.

ГВ>Я. Я так считаю. Этого вполне достаточно для приведения довода в качестве аргумента.

А я считаю что C++ это скриптовый язык. Ну как, аргумент?

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

ГВ>Стоп! Если подходить таким образом, то никогда не сделаешь корректного вывода. Я сравнивал базовые модели языков. А аргументов против моих доводов на этом уровне практически не услышал. Пока, во всяком случае. Аргументы в пользу библиотек/инфраструктуры... не того класса, которого жду.
Вот тебе и говорят что ты не знаешь даже "базовой модели" шарпа и при этом утверждаешь что она плоха. Забавно.

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

ГВ>Стоп ещё раз. Я не говорю, что ".NET ... полное фуфло, а C++ is cool forever" и никогда так не скажу. Не надо приписывать мне такого способа обобщения. Снова повторюсь, я говорил о базовых моделях языков и их влиянии на развитие программиста как личности, обладающей абстрактным мышлением. И аргументов в пользу того, что у C# или Java — более совершенная модель, чем у C++ я пока не услышал. Скорее — услышал аргументы "против", а именно — "ждём появления темплейтов" и "ждём следующей версии".
Тебе их несколько раз называли. Отсутствие компонентной модели, рефлекшена, интерфейсов, свойств, событий. Т.е. C++ обеспечивает намного меньшую абстракцию и вынуждает разбираться в большем количестве деталей реализации. Дело не в том что он позволяет что то делать вручную а в том он заставляет делать вручную.


ГВ>Аргументация довода о преимуществах C++ перед Java сама по себе очень простая — C++ даёт больше возможностей по построению и комбинированию абстракций, нежели Java/C#.
Списочек того что не позволяет С++ я привел. А ущербность такой логики показать легко — ассемблер даёт больше возможностей по построению и комбинированию абстракций, нежели С++. Вывод: ассемблер лучше чем С++.

ГВ> Пока что, этого никто не опроверг. Факт наличия библиотек, пусть даже встроенных, на данном уровне абстракции "не канает". Далее, я придерживаюсь мнения о том, что мозги лучше развивать со структурно сложными инструментами (C++), тогда будет легче использовать структурно более простые (C#, Java). Этого, собственно говоря, тоже никто не опроверг. Соответственно, не поровергли и исходной посылки — что наинать лучше с C++.
Зачем забивать мозги особенностями реализации? Чем меньше этих деталей тем качественней обучение. Опыт изучения С++ тяжело перенести на что то иное, ибо большая его часть специфична.

ГВ>Спор же о преимуществах той или иной библиотеки в данном контексте считаю просто неуместным.

Называть граблями практически неограниченные возможности языка... Элджер неплохо описал границы c++.

Что должен позволять язык программирования?

• Работать с оборудованием
  
• Выражать абстракции высокого уровня

Примерно слова Страуструпа.

Что позоляют Java/C#? В основном 2-ое. Это языки для реализации логики высокого уровня и не более того — вот их границы, они очень четко очерчены.

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

IT>>Как раз не на уровне языка сделать это элегантно весьма проблематично. Получится какой-нибудь уродский набор классов или макросов.

ГВ>Ну уж! Будет он уродским или нет — завистит от разработчика.

Речь шла об ивентах и свойствах, правильно? Если бы хоть одному разработчику удалось сделать это более менее элегантно, то все мы уже давно бы пользовались плодами этих трудов. Но пока что-то не видно нормальных решений. При этом разработчики компиляторов каждый по своему добавляют свойства в язык. Т.е. сделать это совсем не трудно. Не понятно, почему это не добавлено до сих пор в стандарт. В чём проблема?

IT>>...Если в C++ не произойдёт никаких существенных изменений в ближайшие пару лет, то можно будет уверенно заявлять, что этот язык мёртв и давать сабжевые советы просто глупо и даже в какой то степени преступно.

ГВ>Не согласен. :) Омертвеют задачи, которые привыкли решать на C++. Не более того. Но, поскольку задачи мертвеют редко ;), то и C++ никуда не денется. Пусть сначала достаточное количесвто стандартных компиляторов появится.

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

IT>>2. Множественное наследование — которое является синонимом плохого дизайна.

ГВ>Множественное наследование — ещё не синоним плохого дизайна. Это — очень ограниченная трактовка. Забавно, но факт — реализация COM для C++ от Microsoft (я имею ввиду ATL) как раз и построена множественном наследовании. Это просто наблюдение, не более того.

Хорошо. Я должен был более подробно разъяснить то, что я понимаю под этим пунктом. C++ пожалуй лишь один из современных языков, поддерживающих множественное наследование в полном объёме. Интерфейсы — это из этой области, но это как раз та часть, которая реализуется очень легко и присутствует во многих языках. Но это не настоящее :) множественное наследование. Я надеюсь мы оба понимаем о чём речь. При реализации интерфейсов мы не думаем о данных, которые мы наследуем от производного класса. А значит у нас нет проблем с неоднозначностью доступа к ним и с тем как кастить объект к базоваму классу и обратно. Нет проблем с diamond структурами и нет необходимости загромождать язык виртуальным наследованием, чтобы всё это обойти.

Хотя, я знаю один пример, где множественное наследование наряду с шаблонами выгладид очень эффективно — это ATL. Там всё действительно круто. Других примеров я не знаю.

IT>>Это очень круто, только у меня есть вопрос — а зачем? 95% современных задач требуют умения работы с базами данных, а не с указателями.

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

И при чём тут указатели?

IT>>Аргументы, плиз, в студию. Мы их рассмотрим и может быть согласимся, может просто посмеёмся, но скорее всего поспорим.

ГВ>Хорошо. Приведу свои рассуждения по этому поводу позже — придётся систематизировать наблюдения. Пока что прими как факт, что я убеждён в своей правоте.

Ok. Ждём :)

ГВ>>>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun,

IT>>Проблемы переносимости не существует, всё это всего лишь маркетинг.

ГВ>Извини, не понял. Что — "всё"? Проблема переносимости или виртуальность её решения с помощью Java?

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

ГВ>Здесь создаёт проблемы реализация COM для C++ от Microsoft, а не C++ как таковой. Кроме того, я вижу в этом косвенное подтверждение тезиса о том, что C# поддерживает модель реализации, аналогичную COM.

COM был нормально реализован для C++. Не вижу здесь проблем. И вообще COM — это весьма серьёзная технология для своего времени. Просто время это проходит, вот и всё.

Последнее "подтверждение тезиса" меня как раз лишний раз убеждает в том, что речь идёт о предмете о котором нет чёткого понимания. C# и COM совершенно разные и несравнимые вещи. Можно сравнивать COM и CLR, можно C# и C++, но не COM и C#. Но даже если речь идёт о COM и CLR, то могу тебя уверить, что наличие поддержки COM в .NET сделана только из соображений совместимости. Модель в .NET другая, ну то есть абсолютно разная.

ГВ>Тем не менее — ограниченность COM-овской модели и аналогичных никуда не делась. :crash:

В чём именно ограниченность COM-вской модели?

IT>>б) необходимо по жизни в основном для типизированных контейнеров,

ГВ>Вот! Иллюстрация моего тезиса о том, что ряда вопросов люди себе даже не задают. Кроме контейнеров у шаблонов есть ещё вагон областей применения — поищи в инете по словам "generic programming".

Я могу открыть исходники ATL и всё это созерцать там в полный рост. Но только я не собираюсь предлагать новичкам начать изучать программирование с GP. На этом всё их программирование тут же и закончится. К тому же именно из-за своей сложности GP вряд ли получит широкое применение.

IT>>в) интересный термин — инлайнирование . По сути, перекладывание задач оптимизации на плечи программиста. Временные издержки нашего времени, ничего более.

ГВ>Мммм... Да нет так тут всё просто... Вызовы виртуальных функций не очень-то оптимизируешь вобщем...

Тот же ATL великолепно демонстрирует возможность замены виртуальных функций с помощью GP, и это совсем неплохо оптимизируется.

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

IT>>Не надо обольщаться и делать поспешные заявления. Хотите пример, получите — приведите код безапасной работы с файлом на Java, например, открытие файла, запись строки данных и закрытие. При этом мы учитывем возможность возникновения исключительных ситуаций. На C++ это делается в 2 строки кода. Хотелось бы увидеть более простой код на Java.

ГВ>Если я правильно понимаю, то здесь у тебя опечатка — перевёрнуты C++ и Java. Если это правильно, то не вижу проблемы — реализуешь аналогичную библиотеку на C++ и полный вперёд. Хоть в одну строку уложи. Это — сравнение библиотек, а не языков.

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

ГВ>Если же опечатки у тебя нет, то что тогда доказывать? ;)

Правильно, тут доказывать нечего :)

ГВ>>>Прикол как раз в том, что когда работаешь со скриптовыми языками, часто даже не задаёшь себе тех вопросов, которые не боишься ставить, используя C++. А C# и Java я как раз и считаю разновидностью скриптовых языков, посольку ИМХО они апеллируют к реализации каких-то элементов системы на других языках.

IT>>Кто именно считает? Я слышу такое утверждение первый раз.

ГВ>Я. Я так считаю. Этого вполне достаточно для приведения довода в качестве аргумента.

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

ГВ>Стоп! Если подходить таким образом, то никогда не сделаешь корректного вывода. Я сравнивал базовые модели языков. А аргументов против моих доводов на этом уровне практически не услышал. Пока, во всяком случае. Аргументы в пользу библиотек/инфраструктуры... не того класса, которого жду.

Это тоже заблуждение. Язык не может быть отделён от своего окружения. Даже C++. Если ты пишешь на C++ под Windows и не имеешь опыта в Unix, то никто тебя не возьмёт писать систему для последнего. Язык можно и нужно рассматривать в контексте его окружения.

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

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

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

Моя модель такая. Для нормального владения тем же C++ нужно примерно 1-1.5 года интенсивной работы с ним. Если это первый изучаемый язык, то возможно нужно больше времени. После этого уже не придётся оправдываться, что мол типа я давно на нём не писал и уже забыл. Дальше уже без разницы сколько там лет. Но, если человек использует технологию постоянно в течении скажем 3-4 лет, то вопросов у меня вообще к нему никаких нет.

ГВ>Стоп ещё раз. Я не говорю, что ".NET ... полное фуфло, а C++ is cool forever" и никогда так не скажу. Не надо приписывать мне такого способа обобщения. Снова повторюсь, я говорил о базовых моделях языков и их влиянии на развитие программиста как личности, обладающей абстрактным мышлением. И аргументов в пользу того, что у C# или Java — более совершенная модель, чем у C++ я пока не услышал. Скорее — услышал аргументы "против", а именно — "ждём появления темплейтов" и "ждём следующей версии".

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

ГВ>Аргументация довода о преимуществах C++ перед Java сама по себе очень простая — C++ даёт больше возможностей по построению и комбинированию абстракций, нежели Java/C#. Пока что, этого никто не опроверг. Факт наличия библиотек, пусть даже встроенных, на данном уровне абстракции "не канает". Далее, я придерживаюсь мнения о том, что мозги лучше развивать со структурно сложными инструментами (C++), тогда будет легче использовать структурно более простые (C#, Java). Этого, собственно говоря, тоже никто не опроверг. Соответственно, не поровергли и исходной посылки — что наинать лучше с C++.

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

Что касается тезиса о том, что чем сложнее язык, тем лучше будущему программисту, то я уже как-то не уверен в этом. Здесь можно провести аналогию с автоматической и ручной коробкой передач. Ты можешь виртуозно управлять ручной коробкой, но, например, в штатах тебе это скорее всего не понадобится. Да и шансов у ручной коробки мало на длинных дистанциях, устаешь сильно, в пробках особенно. А для сверх длинных у автоматов существует ещё и круиз-контроль. Выставил скорость и сиди кури и наблюдай окрестности, ну там про руль не забывай :)

ГВ>Спор же о преимуществах той или иной библиотеки в данном контексте считаю просто неуместным.

Я так не считаю.

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

ME>Называть граблями практически неограниченные возможности языка...

Кто посмел?

ME>Элджер неплохо описал границы c++.

ME>Что должен позволять язык программирования?

• Работать с оборудованием
  
• Выражать абстракции высокого уровня

ME>Примерно слова Страуструпа.

ME>Что позоляют Java/C#? В основном 2-ое. Это языки для реализации логики высокого уровня и не более того — вот их границы, они очень четко очерчены.

А Элджер там не привёл случайно примера работы с оборудованием на C++? Мне было бы интересно взглянуть. А то я что-то никак не припомню в C++ никаких языковых конструкций, позволяющих это делать. Даже когда ещё под DOS-ом возникала такая необходимоть, то приходилось либо уходит во встроенный ассемблер, либо пользоваться библиотеками.

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

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

IT>Речь шла об ивентах и свойствах, правильно? Если бы хоть одному разработчику удалось сделать это более менее элегантно, то все мы уже давно бы пользовались плодами этих трудов. Но пока что-то не видно нормальных решений. При этом разработчики компиляторов каждый по своему добавляют свойства в язык. Т.е. сделать это совсем не трудно. Не понятно, почему это не добавлено до сих пор в стандарт. В чём проблема?
Как в чем ? Вероятно, всего лишь в реализации

IT>Всегда считалось что на Unix доминируют C и C++, даже сама операционка написана на этих языках. Тем не менее, пришла Java и задвинула C/C++ куда подальше в части разработки прикладных систем. Если бы не MS со своим Windows, то рынок C++ программистов на сегодняшний день составлял бы каких нибудь несколько жалких процентов от общего числа. Я уверен, что это из-за того, что язык никак не развивается. Других причин я не вижу. В принципе, и Java и C# как раз и можно считать развитием C++, а следовательно и начинать лучше прямо с них.
Да нет, задачи-то решаемые на плюсах остались (куда они, родимые, денутся), но чтобы сохранить свое право на существование реализация их (с той поры как плюсы были едва ли не единственным языком и абстракции и реализации) по сложности возросла в разы. Вывод — новичку лучше не влазить в это, поскольку есть множество достойных альтернатив. Черт возьми, наверное, все же приятно работать с С# и деньги получать

IT>>>2. Множественное наследование — которое является синонимом плохого дизайна.

ГВ>>Множественное наследование — ещё не синоним плохого дизайна. Это — очень ограниченная трактовка. Забавно, но факт — реализация COM для C++ от Microsoft (я имею ввиду ATL) как раз и построена множественном наследовании. Это просто наблюдение, не более того.

IT>Хорошо. Я должен был более подробно разъяснить то, что я понимаю под этим пунктом. C++ пожалуй лишь один из современных языков, поддерживающих множественное наследование в полном объёме. Интерфейсы — это из этой области, но это как раз та часть, которая реализуется очень легко и присутствует во многих языках. Но это не настоящее множественное наследование. Я надеюсь мы оба понимаем о чём речь. При реализации интерфейсов мы не думаем о данных, которые мы наследуем от производного класса. А значит у нас нет проблем с неоднозначностью доступа к ним и с тем как кастить объект к базоваму классу и обратно. Нет проблем с diamond структурами и нет необходимости загромождать язык виртуальным наследованием, чтобы всё это обойти.


IT>Тот же ATL великолепно демонстрирует возможность замены виртуальных функций с помощью GP, и это совсем неплохо оптимизируется.
Дык... то, что там применено — известный финт ушами, но в _большом_ проекте при участии людей с разной подготовкой и идеологией это будет для того, кто такое напишет, чревато последствиями. Другого же С++ пока предложить не может. Пока. Но — увы
ЗЫ Ах, да, есть же еще template metaprogramming, это тоже подойдет _новичку_ в полной мере..

Кстати, известно что-либо о том, как будет выражаться поддержка шаблонов в С# ?

AVK>1) Рефлекшен
AVK>2) Эмиттинг кода
AVK>3) Поддержка ремоутинга на уровне языка (это в дотнете, в джаве все как в плюсах с дкомом, может немножко попроще). Никаких стабов и скелетонов, никаких idl и tlb. Все встроено в рантайм и не требует внимания программиста. Создание удаленного объекта сводится к оператору new.
AVK>4) Домены приложений. Т.е. можно создать изолированную от внешнего мира песочницу с ограниченными правами.
AVK>5) Поддержка потоков встроенная в язык.
AVK>6) Черт возьми, почему в плюсах нету try..finally?
AVK>7) Интерфейсы
AVK>8) GC
AVK>9) GAC (Global Assembly Cache, такая штука которая хранит все версии сборок и отдает нужные конкретному приложению. Т.е. никакого набора кучи mfcxx.dll, которые еще к тому же могут быть разных версий)
AVK>10) боксинг и анбоксинг. Т.е. простые типы вроде int и string не ломают объектную парадигму, являясь объектами и при этом не теряя эффективность.
AVK>11) Stack trace
AVK>12) Встроенная в язык и рантайм сериализация. Всем плюсовым аналогам до ней очень далеко.
AVK>13) Атрибуты.

14)Контексты? Или считать их следствием введения reflection. Но с другой стороны, контексты — это отдельная, важная возможность перехватывать вызовы. Так что имхо 14).

IT>А Элджер там не привёл случайно примера работы с оборудованием на C++? Мне было бы интересно взглянуть. А то я что-то никак не припомню в C++ никаких языковых конструкций, позволяющих это делать. Даже когда ещё под DOS-ом возникала такая необходимоть, то приходилось либо уходит во встроенный ассемблер, либо пользоваться библиотеками.

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

Вот в .NET напрямую тоже не поработаешь... Не думаю, что это сильный недостаток.
Я вообще себе это все представляю так:

| Системные | Прикладные         |          
| задачи    | задачи             |

Это было лет 20 назад. И Страуструп хотел охватить языом почти все.

А сегодня:

| Системные     |                                Прикладные                                     |          
| задачи        |                                задачи                                         |

И одним языком все охватывать — это смерть. Для языка.

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

ME>Называть граблями практически неограниченные возможности языка... Элджер неплохо описал границы c++.
Граблями я называю грабли.

ME>Что должен позволять язык программирования?
ME>

ME>
• Работать с оборудованием
  ME>
• Выражать абстракции высокого уровня
  ME>

ME>Примерно слова Страуструпа.

ME>Что позоляют Java/C#? В основном 2-ое. Это языки для реализации логики высокого уровня и не более того — вот их границы, они очень четко очерчены.
А для чего сейчас нужно работать напрямую с оборудованием?

Здравствуйте Андрей Тарасевич, Вы писали:

АТ>С# не позиционируется как замена C++. Какое может быть "поздно"?

Привет монстрам С++!
Я уже где-то тут писал, что
1. Начинающему программисту уже позно изучать С++ поскольку конкуренция слишком сильная.
2. Microsoft переходит на .NET, и даже само не может сказать где там будет место для С++. Если человек пишет не под win, то оно конечно всё по другому. Но таких остаётся всё меньше и меньше.

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

ME>Называть граблями практически неограниченные возможности языка... Элджер неплохо описал границы c++.

ME>Что должен позволять язык программирования?
ME>

ME>
• Работать с оборудованием
  
  Не корректно выразился. Одной из задач при создании С была необходимость достигнуть быстродействия сравнимого с ассемблерным кодом. Это вполне удалось.
  
  И сравнивнивать по критерию быстродействия / системных требований программы на C++/C#/Java, наверное, не совсем корректно, т.к. создавались эти языки для разных целей.
  
  ME>
• Выражать абстракции высокого уровня
  ME>

ME>Примерно слова Страуструпа.

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

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

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

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

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

Почитай "шустриков" на нашем сайте. Там хорошо видно, что по быстродействию C# ничем не уступает C++, местами даже его обгоняет. И зависит всё не столько от самого языка, сколько от оптимизатора конкретного компилятора.

ME>И сравнивнивать по критерию быстродействия / системных требований программы на C++/C#/Java, наверное, не совсем корректно, т.к. создавались эти языки для разных целей.

Может они и создавались для разных, да только вот используются для одних и тех же.

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

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

A>>программа на Java с 3 окнами уже занимает 50M, ты просто не сможешь написать
A>>прогу на Java занимающей 10M в памяти.
AVK>Ну это ты загнул. 50М это уже EJB-серверы. Типичный десктоп 10-20 метров и будет.

Щаз. Я тебе подскажу как это посмотреть. Task manager показывает
не всю память а только реально занятую, т.е. то что выкинуто в swap не
считается, включи колону VM Size и поплюсуй ее с обыкновенной
получится как раз 50 Mb для программы с 3 окнами, смотрел 3 дня назад.

A>>Стабильная утечка памяти 10K в минуту элементарно отлавливается(Bounds checker еще никто не отменял)
AVK>Увы, это не так.

Хм. Видимо зависит от программиста, у нас не так.

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

A>>>Стабильная утечка памяти 10K в минуту элементарно отлавливается(Bounds checker еще никто не отменял)
AVK>>Увы, это не так.

Дикий народ! Сколько говорилось про умные указатели, выделение ресурса — инициализация и проч.!

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

IT>Почитай "шустриков" на нашем сайте. Там хорошо видно, что по быстродействию C# ничем не уступает C++, местами даже его обгоняет. И зависит всё не столько от самого языка, сколько от оптимизатора конкретного компилятора.

Да и Java ничем не отличается по тестам. Но
реальные программы на ней это не спасает.

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

IT>Это тоже заблуждение. Язык не может быть отделён от своего окружения. Даже C++. Если ты пишешь на C++ под Windows и не имеешь опыта в Unix, то никто тебя не возьмёт писать систему для последнего. Язык можно и нужно рассматривать в контексте его окружения.

Не согласен. Мне кажется в этом утверждении ты основываешься только
на опыте работы с msvc. Люди которые никогда не писали в unix достаточно неплохо
пишут кросплатформенные модули, там как раз все просто, не
делай #include <windows.h> и все будет нормально. C++ это как
раз один из немногих языков хорошо отделеный от окружения.
(что msvc плохо от окружения отделен это я согласен)

Чтобы понять это надо просто попрограммировать на разных компиляторах,
хотя бы под одну платформу.(Кстати DJGPP(порт GNU под DOS) гораздо сильнее похож
на gcc под unix чем на msvc, напиши прогу которая будет компилиться и им
и msvc вот у тебя уже и есть фактически кросплатформенная вещь, переделки
скорее всего понадобятся но мелкие)

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

AVK>Здравствуйте Аноним, Вы писали:

А>>Проясни, пожалуйста, в чём ты видишь её особенную логичность?
AVK>Чего пояснять? Возьми да посмотри.

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

AVK>>>Во, начинается. Во многих современных языках события реализуются на уровне языка, а в С++ можно библиотеками. Можно конечно, но не удобно.
А>>Раз. В каких языках? И даже если это так — то это ещё не аргумент. Мало ли где что и как реализуют? Тем-то и хорош C++, что позволяет реализовать много, предлагая набор конструктивов, а не готовых решений.
AVK>Ну да — то извращение, посредством которого реализованы события называется набором конструктивов? :)

Вопрос: Какие события и где реализованиы? Упреждая возможный ответ: события Win32 — далеко не единственный вариант модели событий.
И ещё – под «набором конструктивов» в данном случае я имею ввиду набор средств манипулирования абстракциями. (Забегая вперёд скажу – наследование и шаблоны).

А>>Два. Не согласен. Именно это (наличие возможности) как раз и удобно. ИМХО, всегда удобнее, если тебе не навязывают некое решение как единственно верное.
AVK>Знаешь что я тебе скажу? Любой язык навязывает свои решения, даже ассемблер. Полностью избавиться от стандартных решений можно только программируя в машинных кодах. Системы создания приложений в своей эволюции стремяться как можно больше сделать автоматически, без участия программиста. Шарп и джава со своими рантаймами это следущий шаг в этом направлении. Так кто мешал довести С++ до их уровня? Или так и будем еще 30 лет топтаться на месте? Язык это не идол, на который нужно молиться. Он должен развиваться в соответствии с новыми реалиями. Вычислительные мощности и объемы памяти возросли в десятки тысяч раз, появилась уйма новых технологий, некоторые из которых революционны. А язык так и остался почти таким же. Не думаю что это нормально.

Так… Ну, здесь у тебя по большей части лозунги… Что-то подобное я слышал, когда бушевал RAD-психоз. Тоже казалось – ща возьмём дельфу, и накропаем прогу на такой скорости, да такую крутую! Только выяснилось, что реально она решала ну… процентов 10-15 проблем… И то – за счёт библиотек.
Относительно же языка. Да, я тоже не считаю C++ идолом. Но, увы, лучшей модели пока ещё никто из китов не предложил… Кроме того, если язык будет развиваться в соответствии с "новыми реалиями", которые меняются очень быстро (я полагаю, ты имеешь ввиду именно их), то он превратится в эклектику и действительно-таки рухнет под собственной тяжестью. Языки PL/xxx помнишь?

А>> Напоминаю, что топик начинался с обсуждения развития начинающего программиста и выбираемых для этого средств. Так вот, я полагаю, что C++ косвенно способствует развитию культуры программистского мышления, нежели C# или Java.
AVK>Вот как раз именно развитию культуры он и не способствует. Многие паттерны на нем реализуются в разы сложнее. Т.е. вместо ковыряния с концепциями программирования он будет ковыряться с особенностями плюсов. Оно ему надо?
AVK>Ты ради интереса зайди на дотнетовский форум и посмотри сколько там вопросов по языку и компонентной модели. И сравни с количеством онных в плюсовом форуме.

Это некорректный аргумент — аргумент к коллективу. Please, не думай, что я сделаю те же самые выводы, что и ты на основании схожих с твоими наблюдений.
Тем не менее вопрос: какой ты сделал вывод на основании сравнения количеств сообщений в обоих типах форумов?

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

Правильно (про грабли), натыкается, поскольку сразу пытается доказать, что он "крут как якут". C++ (для сложных вещей, в особенности) требует стройности в оформлении мыслей => определённой подготовки => определённого уровня как профессионала. Кстати, что это я? Это как раз-таки сложные вещи требуют всего этого! Что же плохого в том, что человек этому научится? Как я понимаю, плохо в этом только то, что у него возрастут требования к работодателю. Да, но и работодатель от этого только выиграет.
Ну хорошо, хорошо  Это я съязвил малость ;)

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

Снова аргументируешь, апеллируя к авторитету.
Изменение изменению – рознь. Я не люблю не "изменение", а отупление инструмента вкупе с навязыванием эклектики. А что до Borland — пусть меняет на здоровье. Для меня Borland не авторитет и не аргумент. Мало ли кто и что делает? Да и к нашему спору она не относится.

А>>Кроме того, я вижу в твоём доводе противопоставление — среда, где "всё есть" в виде встроенного набора против среды с развитым набором библиотек. ИМХО, второй вариант лучше в контексте топика (и не только), поскольку после изучения библиотек программист сможет написать свои, реализующие его модель абстракций, то есть, ту, которая лучше подходит под его задачи.
AVK>Вот тут совсем не понял что ты хотел сказать.

ГВ>>>>Для C# и Java эти вопросы решались исходя из целей этих языков. C# — поддержание амбиций Microsoft (т.е., внедрение поддержки модели COM),
AVK>>>Гы.
А>>Интересный контраргумент ;)
AVK>Не хочется такую глупость опровергать.

Моя логика в данном случае простая. Microsoft располагает приличным количеством клиентов-разработчиков из которых большая часть — VB, неплохо знакомых с компонентной моделью + клиентами-разработчиками VC++, ограниченных отклонениями языка от стандарта. Плюс к тому, имеется определённый набор библиотек и концепций — MFC, COM, ATL, plain-Win32. Глядя на развивающуюся Java Microsoft желает зафиксировать аудиторию своих пользователей. (по-моему, вполне логично). Средства: а) показать преимущества своей платформы б) дискредетировать возможную альтернативу.
"Неявное" вытаскивание своей платформы привело к скандалу с Sun (историю с J++ все помнят?) То есть, играть надо на "своём" поле. Вопрос, каким это поле должно быть? Ответ — равноприемлемым для сложившейся аудитории пользователей. Итак — создаётся новая платформа. Такой шаг логичен и с другой стороны — одной компании трудно поддерживать большой набор концептуально разнородных технологий. Вопрос: какие элементы в эту технологию нужно вводить? Здесь следует учесть амбиции MS в части распределённых приложений, то есть таких, которые выполняются на разных станциях (я не имею ввиду распределённые приложения, как набор математических моделей), то есть — состоящих из взаимодействующих компонентов. Здесь я сделаю отступление: абстракция, как инструмент разработки софта обычно служит снижению объёма ручной работы — т.е., — повышению производительности одиночки или очень компактного коллектива. И вот теперь обратим внимание на то, что целью MS не может быть "интеллектуализация" платформы, как инструмента выражения абстракций, поскольку следствия такого подхода — снижение численности аудитории (по крайней мере, на первых порах), что противоречит цели обеспечения финансовой устойчивости компании. Однако, тем не менее, имеется устоявшаяся модель таких понятий, как "событие", "компонент", "интерфейс" и ещё кое-что, что доступно пользователям VC++ (изначально ограниченного в силу несоответствия стандарту). Отсюда, ИМХО, естественно следует внедрение вышеупомянутых идиом на уровне системного базиса новой платформы. Следующий момент — появление горы сразу стандартизуемых конкретных служб и сервисов (изучение последних создаст у массовой аудитории иллюзию повышения своей квалификации — я знаю, что такое "название нужной службы вписать" и это есть в языке "впишите сами"). Часть этих служб будет реализована на уровне runtime, часть — станет элементом стандартного framework и т.п. Чем их больше — тем на самом деле лучше, поскольку подсаженные на подобную иглу пользователи вряд-ли когда с неё слезут.

Я признаю, что MS сделала очень неплохой маркетинговый шаг, вытолкав .NET в жизнь. Осталось только отстоять её.

Итак: для MS убивается куча зайцев: а) довольна наименее квалифицированная часть пользователей, б) создаётся необходимый шум и косвенная дискредитация альтернативы (Java), в) у компании появляется собственная платформа, где никто ей не мешает.

Каковы следствия для пользователей? Следствия естественны – попав в среду с большим количеством ответов на конкретные вопросы пользователи скорее будут вынуждены заняться поиском вопросов, на которые им даны ответы, нежели развитием себя как реализаторов абстракций.

AVK>>>>>Как раз реализация определенных концепций на таких языках оказывается зачастую более понятной, простой и красивой. Сравни к примеру COM и объекты дотнета или джавы.
ГВ>>>>Ну, во-первых. Сравнивать COM (в сущности — способ структурирования коммуникаций)
А>>Помню. Только ещё помню довольно редкие случаи корректного его (принципа) применения. Кстати, какую сущность я здесь придумал?
AVK>А ты свои слова перечитай еще раз.
Я назвал COM способом структурирования коммуникаций. Пусть немного некорректно. Корректно, ИМХО, было бы так: Component Object Model часто используется как базисный набор абстракций для структурирования взаимодействия элементов программного комплекса в среде Windows. По-моему, не противоречит предыдущему высказыванию. А не для этого ли он разработан?

ГВ>>>> с моделью объектов в языках реализации не совсем корректно.
AVK>>>Очень даже корректно. Решаемые задачи абсолютно идентичны.

А>>Упс. :) COM (ИМХО, кстати, равно как и CORBA, в противовес которой и развит COM/DCOM) — способ структурировать взаимодействия объектов, адекватный на уровне связи больших элементов программы.
AVK>Во блин нагородил. Вот корба кстати по своему назначению соответствует только DCOM, да и то только его части. А мы о COM говорим, ты не забыл еще?
С помощью CORBA (ключевое слово — Architecture) в общем можно решить те же проблемы, что и с помощью COM, за исключением среды Windows, где наиболее распространённые приложения поддерживают только COM.
Если говорить о соответствии, то насколько я помню, именно равитие CORBA привело к активности MS в части развития DCOM, так что… это ещё кто чему соответствует ;)

А>>Здесь я полагаю, что некорректно само использование COM как концепции архитектуры реализации.
AVK>Концепция архитектуры реализации. Красиво звучит, но абсолютно бессмысленно. Ты анекдот про чукчу и подводную лодку знаешь? Так вот, ты не мудри, ты пальцем покажи какие конкретно задачи решает COM и не решает компонентная модель джавы и дотнета?
Я не противопоставляю COM никаким компонентным моделям. Просто я считаю, что компонентная модель – не лучший способ реализации абстракций высокого уровня.

ГВ>>>>Реализация COM для C++ в Miscrosoft-овском варианте обладает теми же чертами, что и плоский API на C с небольшими вкраплениями объектного подхода. То есть — можно было бы и лучше.
AVK>>>В рамках С++, при оставлении самого языка неизменным, вряд ли.

А>>Проиллюстрируй. В защиту своего довода приведу: а) код, генерируемый MIDL включает поддержку pure-C и не использует возможностей C++ по реализации абстракций в полном объёме и б) Модель, реализованная в ATL — не единственная возможная. Одно управление BSTR на уровне системы чего стоит.
AVK>Э нет, так не пойдет. Это ты утверждал что в MS идиоты и на самом то деле все можно сделать намного лучше. Вот и расскажи как это сделать.
Я никогда не называю оппонента идиотом. Это не мой метод ведения спора. Однако интересен тот факт, что моё утверждение о «не лучшей из возможных реализаций” привело к тому, что ты приписал мне вульгарную оценку. Однако, это ты сделал такой вывод! Дорогой! Это ты назвал MS идиотами! А из твоих слов я делаю вывод о том, что для тебя болезненно важна уверенность в единственной правильности своего инструмента. Болезненна до такой степени, что ты срываешься на оскорбления (косвенные).

А>>Кроме того, реализовывать интерфейсы прямым наследованием от самих интерфейсов — тоже не самый лучший вариант. Да, он удобен в ряде случаев, но для большой системы необходимо множество интерфейсов и множество сущностей уровня реализации. Так что, неизбежно придётся вводить промежуточный слой, объединяющий реализацию интерфейсов COM с реализацией самой системы. Структура этого слоя сама по себе может быть сложной, если захочется уменьшить объём механической работы. Здесь бы и пригодились подходы, отличные от наследования.
AVK>А может просто ввести интерфейсы в язык? И все, и никаких сложных слоев.
Слои непременно появятся. Это будут слои реализации интерфейсов. В противном случае – будет внутренняя эклектика на уровне реализации приложения. Логичное следствие эклектики для программного продукта – экспоненциальный рост трудоёмкости сопровождения и развития.
ГВ>>>>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun, а C# + CLR — как противовес Java в той же области,
AVK>>>Это твои домыслы. И джава и дотнет созданы как средства разработки приложений.

А>>C++ тоже создан как переносимый язык разработки приложений и в этом смысле эквивалентен C# или Java. Однако, переносимость подавалась как одно из основных преимуществ Java, а C# из дотнета слишком уж похож на Java и в его пользу тоже приводятся аргументы из серии переносимости. Честно говоря, я вижу за всей этой шумихой маркетинговую борьбу и не более того.
AVK>Ты не путай переносимость на уровне исходников и на уровне бинарников. Это разные вещи.
Да, согласен. Это действительно разные вещи. Но есть одна закавыка в переносимости. Для её обеспечения всегда привлекаются дополнительные средства. Или runtime-environment (CLR, JVM,…) или компилятор. В принципе, можно было бы говорить о переносимости Java, если бы в приложения не втягивалась зависимость от JVM… О переносимости CLR фактически говорить ещё рано.

А>>Объединяет их по отношению к C++ одно — кастрация его возможностей. Буду повторять в каждом абзаце — возможности C# и Java в части выражения абстракций — Уже, чем у C++. И это, кстати, подавалось в своё время как преимущество Java перед последним.
AVK>Вот такие вот стойкие защитники языка уже сколько раз пытались GC на плюсах реализовать. И чо то у них ничего не вышло пока. Не подскажешь почему?
Потому что в плюсах он не нужен. Есть идиомы умных указателей и ещё много чего, вполне заменяющего GC.
AVK>И, это, ты так интересно забываешь про рефлекшен все время. Реализуй ка мне его на плюсах ввиде либы. А заодно может чего с динамической генерацией классов и CodeDOM придумаешь.
Динамически генерировать классы на C++ можно. На здоровье: таскаешь компилятор с библиотеками вместе с приложением – и полный вперёд! Аналогично можно генерировать тексты на любом языке програмирования, если у твоей программы хватит интеллекта на постановку задачи для такой генерации.
А что до рефлекшена, так он теоретически может быть реализован front-end компилятором. Вопрос – зачем?
AVK>>>Программировать на шарпе и джаве на порядок проще чем на плюсах. Так что ты попробуй для начала и почувствуй разницу. А разница действительно существенна.
А>>Вопрос: кому проще и по сравнению с кем и в каком контексте (на каких проектах)?
AVK>Всем проще, в 95% проектов. Не проще в драйверах, в программах-числомолотилках с простым алгоритмом. Ну может еще где, всего не упомнишь.

Сударь! Я уличаю Вас в неправомерном обобщении. Что это за 95% проектов?

AVK>>> В отсутствие рефлекшена и получаются монстры вроде COM с его IUnknown,QueryInterface и IDispatch.
А>>Принимаю возможные обвинения в некомпетентности, но не мог бы ты раскрыть причинно-следственную связь? Думаю, это всем будет интересно.
AVK>А чего тут раскрывать. Когда у тебя есть полная информация о типе объекта все эти комовские навороты просто не нужны.

Налицо подмена понятий. Комовские навороты нужны были для обеспечения иерархического упорядочивания коммуникативных свойств (IUnknown + QueryInterface) и работы в условиях, где неизвестен реальный объект, с которым проводится коммуникация (IUnknown + IDispatch). Однако, неужели ты находишь, что подобный подход может серьёзно упростить решение проблемы устойчивости программы? Как раз-таки, устойчивость проще обеспечить в условиях жёсткой фиксации семантики, а не распознавания её «на ходу». COM – это так… частный случай выражения семантики взаимодействий.

AVK>>>Тебе списочек того что нет в плюсах привести? Именно в плане абстрагирования. Тем паче что к собственно абстракциям имеет отношении только первый пункт.
А>>Да, приведи список возможностей, если не затруднит. А мы рассмотрим ((c) Жеглов) ;)

AVK>Наверняка что то забуду, надеюсь меня поправят. Часть уже приводил. Итак
А я оппонирую , предлагая оценку с точки зрения C++-ника. И вот так выделю предполагаемый способ построения аналога на C++, а вот так – оценку указанного средства как средства построения абстракций. Но только… могу где-то оказаться неправым в описании свойств CLR/C#, так что – поправь, pls., если что.
Значит, я предполагал, что средство построения абстракций – суть элемент структуры языка, позволяющий как выделять абстракции (совокупности свойств, обозначаемых одним общим термином), так и комбинировать их свойства. Абстракция более высокого уровня выражает более общие аспекты функционирования (массивы, списки), чем абстракция частная или более низкого уровня (control, файл).
Признаю, также, что несколько неправомерно причислил C++ — inline к средству построения абстракций.
Итак, что же предлагаешь ты?
AVK>1) Рефлекшен
Не является средством построения / комбинирования абстракций. Компонент общей системы контроля и run-time-распознавания типов. Внимание! Ключевое слово – runtime. На C++ можно реализовать сотней разных способов
AVK>2) Эмиттинг кода
Хммм… встроенный ассемблер машины стековых, похоже вычислений. И что здесь такого? Помнится, даже сам писал что-то подобное.  Очень несложно реализуется на C++ с использованием шаблонов и пр., если необходимо. На C++ решается библиотеками. Не является средством построения абстракций. Ну, в крайнем случае, в той же степени, что и транслятор.
AVK>3) Поддержка ремоутинга на уровне языка (это в дотнете, в джаве все как в плюсах с дкомом, может немножко попроще). Никаких стабов и скелетонов, никаких idl и tlb. Все встроено в рантайм и не требует внимания программиста. Создание удаленного объекта сводится к оператору new.
Не является средством построения абстракций Как я понимаю, ремоутинг может полностью поддерживаться только в рамках CLR или же COM для не-CLR-объектов. С точки зрения C++ решение такой задачи — интерфейсы + фабрики классов (необязательно – COM-овских). Деталь окружения, порождённая от COM и отразившаяся на структуре языка. Впрямую не решается на C++ за счёт отсутствия единой runtime-среды для программ на C++ Навязывание единой фабрики классов.
AVK>4) Домены приложений. Т.е. можно создать изолированную от внешнего мира песочницу с ограниченными правами.
Не является средством построения абстракций Модель управления доступом. Это Не свойство языка как такового. Разные среды – разные модели. Библиотеки C++ и идиомы построения приложения
AVK>5) Поддержка потоков встроенная в язык.
Не является средством построения абстракций Я усматриваю в этом прямое отображение модели CLR на концепции C# + реализацию многопоточности. Да, примитив lock встроен в язык как ключевое слово. А в C++ lock – это может быть и объект и аргумент шаблона. C++ не содержит прямого языкового аналога lock, но это может быть сделано библиотеками.
AVK>6) Черт возьми, почему в плюсах нету try..finally?
Как это соотносится с построением абстракций? Зачем? Разрушение локальных ресурсов решается деструкторами. Это есть прямое потакание плохому стилю программирования. C++ прямого аналога не содержит. Аналогичные задачи решаются до их возникновения посредством стиля программирования и деструкторами
AVK>7) Интерфейсы
Является средством построения абстракций. В C++ имеется прямой аналог — абстрактные классы. Имеется прямой аналог в C++
AVK>8) GC
Не средство построения абстракций Сборщик мусора, как известно — палка о двух концах. Рассмотрено выше, но повторюсь: идиомы «умных» указателей для C++ никто не отменял. Реализуется на C++ как и многие другие стратегии управления памятью и ресурсами
AVK>9) GAC (Global Assembly Cache, такая штука которая хранит все версии сборок и отдает нужные конкретному приложению. Т.е. никакого набора кучи mfcxx.dll, которые еще к тому же могут быть разных версий)
Не средство построения абстракций. Это, конечно, экстремизм  с моей стороны, но на C++ такая задача решается библиотеками, выбирающими каталог, откуда извлекаются компоненты. Реализуется библиотеками C++
AVK>10) боксинг и анбоксинг. Т.е. простые типы вроде int и string не ломают объектную парадигму, являясь объектами и при этом не теряя эффективность.
Средство runtime-контроля, не является средством построения абстракций. Привязали, значит, указатель из CLR-хипа к адресу объекта, который естественно стал managed, поскольку на него есть прямой доступ… Берем шаблонные классы с inline-методами C++ и получаем аналог. Шаблоны C++
AVK>11) Stack trace
Вспомогательная подсистема. На C++ может реализовываться с помощью Debug API и exception-ами. Периодически, конечно, необходимая вещь… Ах да! У нас же тут неизвестно какой объект неизвестно где создаётся… Ну, тогда Реализуемо на C++. в зависимости от среды исполнения.
AVK>12) Встроенная в язык и рантайм сериализация. Всем плюсовым аналогам до ней очень далеко.
Это всего лишь готовое решение, а не способ их сиснтеза! Даже если здесь добавляется контроль типов. Итак, снова библиотеки… Реализуется библиотеками на C++
AVK>13) Атрибуты.
Не является способом построения абстракций Атрибуты могут быть привязаны к элементу описания типа (вероятно). Позволяют решать задачи идентификации элемента описания во внешнием контексте. Но это – часть общей стреатегии использования типов и информации о них, ёлки палки! На C++ аналогичная задача решается статическими дескрипторами классов или (по идее  ) front-end компиляторами. Решается библиотеками
Кроме того, ты ещё упоминал события, которые тоже – суть просто возможное решение одной из многочисленных задач программирования.
Теперь попробую подбить итоги: из 14-ти названных особенностей абсолютное большинство (13) – предлагаемые способы Microsoft способы решения вполне конкретных задач. Только одна (!) указанная тобой особенность – суть способ построения абстракций – интерфейсы. Однако, она содержится в C++. Так что, ты всё-таки моего тезиса о том, что C++ предоставляет больше средств построения абстракций не опроверг. И ничего «разэтакого» я пока в C# по сравнению с C++ не увидел. Да, есть здоровенная библиотека под названием CLR со своей идеологией, средой исполнения и прочим, что само по себе уже давным-давно есть под названием «операционная система», «объекты синхронизации» и т.п. Полагаю, что всё это хозяйство может одержать решительную победу на рынке распределённых приложений, если Sun, а также консорциум ORB прогнётся под нажимом Microsoft.
В смысле же способов построения абстракций – ничего превосходящего C++ в данном случае не предложено. Предложен C#, по сути являющийся аппроксимацией модели CLR (как в своё время C аппроксимировал асемблеры) и возможность создавать трансляторы с любых языков для модели виртуального процессора. То есть, всё только начинается?
AVK>>> Остальные это только способ решить проблемы производительности путем усложнения модели. Виртуальные контейнеры понятнее и проще в использовании чем темплейты, единственный их недостаток это производительность. Что же касается инлайнирования, то, если верить VladD2, то VC при включении оптимизации на него просто кладет и сам решает где и что инлайнить.
А>>Значит так. Давай не будем путать калий с кальцием. Во-первых, VC — далёк от стандарта, и использовать его несосотятельность в этом смысле как аргумент против языка, им реализуемого — некорректно.
AVK>ПОясняю. При этом VC является одним из самых быстрых компиляторов. Т.е. инлайнирование он делает весьма эффективно. Так зачем его тогда делать вручную, если оно автоматически неплохо получается?
Мне тоже в этом смысле VC++ нравится, но порой это не перевешивает его отрицательных качеств в смысле работы с шаблонами.
А>> Возьми другой компилятор, если этот тебя не устраивает.
AVK>Так остальные медленнее будут.
Парадокс в том, что на самом деле C++-ники чаще используют производительность как аргумент против архитектуры с интерпретируемым кодом в ядре (Java без HotSpot, CLR без транслятора в Native-код), тогда как реальное преимущество C++ — это именно возможность гибко управлять абстракциями.
А насколько?
А>> Во-вторых, шаблоны мало того, что вводились как инструмент повышения производительности, но не программы, а труда программиста, так на современном этапе развития они нередко позволяют сделать то, чего нельзя добиться с помощью наследования. Очень простой пример — шаблон метода с набором его специализаций в шаблоне класса. Такой метод принципиально может быть инстанцирован для любых типов аргументов, притом для некоторых типов аргументов он будет работать по специфическому алгоритму, отличному от общего. То, что MS VC++ 6.0 безобразно с этим работает — не аргумент против C++ как языка.

AVK>Я вот чего то не въехал — чем это удобнее виртуальных контейнеров? Такие контейнеры могут хранить любые типы, даже те о которых на момент компиляции ничего не известно. И так же можно в зависимоти от типа применять специфический алгоритм, хотя это и плохой дизайн на самом деле.

Ту-ту-ту! Для этого тебе придётся подменять реализацию контейнера, или вводить интерфейс-импортёр алгоритма, а на C++ соответствующую специализацию можно держать вместе с классом-пользователем.

[reflection.emit]
AVK>Это не деталь, это ключевая особенность. Именно она позволяет не воротить монстроидальных комов.

Ага,  при условии гомогенного runtime.

А>> но тем не менее, хочу услышать почему Reflection.Emit нельзя реализовать на C++?
AVK>Теоретически можно. Но что то ручная генерация vtbl меня не радует. И про переносимость даже на уровне исходных кодов можно забыть. Все будет работать только с конкретной версией компилера и переписанным рантаймом.
В данном случае всё будет работать только при условии наличия .NET Не могу сказать, что это – критический недостаток, но и сгенерировать vtbl – не суперсложная задача, если приспичит. Как я понял, на C# предлагается генерировать ассемблер… Опровергни меня, плиз, если я не прав. Только, чур, аргументированно!
А>> А что до CodeDOM... Ну, никто не мешает вместе со своей программой таскать ещё и вагон компиляторов и генераторов и сделать унифицированный доступ к ним. Строго говоря, ничего нового в таком подходе нет. Только вопрос — зачем? И это — черта не языка, а инфраструктры (я склонен называть это — библиотеками).
AVK>Рантайм и библиотеки это несколько разные вещи, не находишь?
Если бы ещё этот runtime не оказывал такого сумасшедшего влияния на язык высокого уровня…
А>> По второй части: объекты бывают разные. Одни разумно подгружать, используя COM, другие — из файлов, третьи — ещё откуда-то.
AVK>А еще лучше иметь единую технологию подгрузки которая будет устраивать всегда, а не городить коктейль из технологий. Или у сишников это называется правильным дизайном?
А вот это уже взывание к «истине единой и неделимой». Почему-то я уверен, что никогда не будет единой модели или же технологии чего-либо. Как компонентных объектов, так и способв их подгрузки и пр. л ты думаешь, что кроме MS желающих не найдётся? Что-то я не очень верю, что Sun, к примеру, согласится на эдакое безобразие. ;)
AVK>>>Ну да — при разработке джавы и шарпа во главу угла ставилось прежде всего ускорение разработки и уменьшение количества ошибок. Оказывается и у Sun и у MS нифига не вышло, не удалось переплюнуть даже древний C++.
А>>Я мог бы отклонить этот аргумент как аргумент к авторитету... и я это делаю. Поскольку я начну махать флагом "А Страуструп, по-твоему, дурак набитый?" и ничего хорошего из этого не выйдет.
AVK>Может и не дурак, но похоже ему уже нифига не нужно.
Не стоит, наверное, повторять вслед за маркетинговыми службами MS и Sun всё, что они говорят. Что именно ставилось во главу угла – никто нам с тобой не скажет, но я склонен считать, что всё-таки – деньги массовой аудитории. Также я думаю, что, по крайней мере MS ставились задачи ускорить процессы разработки в определённых областях – так называемых «типовых». Ну и плюс то, о чём я говорил выше. Кстати, ты косвенно подтвердил, что хорошо подобранный набор готовых реализаций абстракций может сильно повлиять на процесс разработки. А подтвердил тем, что привёл список из 14 пунктов. Есть одна закавыка в этом… Способов построения абстракций-то — мало! А именно их развитие и могло бы привести к ещё более серьёзному ускорению процесса просто за счёт избавления от «типовых задач». Однако, MS и Sun заинтересованы в существовании и ни в коем случае, не в устранении этих самых типовых областей. Реально в этом заинтересованы только те, кому скучно всё время делать одно и то же. Так что – древний C++ ни Sun ни MS пока реально переплюнуть всё равно не смогли…

[skip про ERP]
AVK>А кто такие метрики системы?
Измеримые характеристики системы – число файлов, число экранов, число таблиц БД, число .exe/.dll модулей и т.п. Кроме того – характеристики сложности исходных тестов программ: Холстедовские, объектные метрики, цикломатическая сложность и т.п. Кпримеру – количество классов, свзяей между ними, функций, методов, констант и т.п.

А>>И... ты уверен, что ERP действительно проще писать, используя языки с покорёженнной объектной моделью?
AVK>Уверен, пробовал. И объектная модель у них не покореженная, она по крайней мере не хуже плюсовой.
Хуже. Пока что я в этом уверен.

[skip рассуждения о скриптах и не-скриптах]

AVK>>>В джаве в разы больше контроля над рантаймом. И сопровождение джавовских программ в разы проще. В сях даже стек-трейса нет.

См. мой комментарий к п.11.

ГВ>>>> Т.е., Java-программы будет сложнее сопровождать, если конечно, не требовать от пользователя поставить 4-х процессорный сервер P4-2200 под 10-пользовательскую CRM. ;)
AVK>>>Через пару лет такой сервер будет считаться минимальной и дешевой конфигурацией :)

А>>Не передёргивай. Я говорил о том, что к платформе будут предъявлены завышенные требования.
AVK>Но при этом она делает за программиста больше работы. В итоге в денюжках это оказывается намного выгоднее.
А вот и нет! Она всё время заставляет его играть на грани фола. Если ты ограничен в способах построения абстракций, то всё время балансируешь на грани производительность машины – производительность твоего собственного труда. И чем уже эта грань – тем больше возни программиста потребуется.
А>> Напоминаю: когда-то 640К считались пределом, достаточным для любых задач (слова Гейтса, если не ошибаюсь, но это — неважно). Так что, не переживай: через пару лет при таких делах потребуется 16-процессорный сервер. ;)
AVK>Ну и что в этом плохого, если этот сервер обходится дешевле чем работа программиста в течении месяца?
Ничего плохого. Только программистов таких может уже и не остаться при подобном подходе к программированию. Вот тогда-то и запоём.
А>> Под словом "дела" я имею ввиду вполне реальное снижение "среднестатистической" квалификации программиста и ориентация разработчиков на попытки решения сложных задач упрощёнными способами.
AVK>Не надо только думать что квалификация программиста определяется его умением писать низкоуровневый код. Самое интересное что часто подобное просто не нужно. Я на собеседовании к примеру даже не спрашиваю — умеет ли человек proxy stub для кома написать или похачить чего, не интересно это мне. А вот как раз умение просто решать сложные задачи очень ценно.
«Всякая сложная проблема имеет простое неправильное решение» — один из законов Мерфи.
Я сталкивался с теми, кто пытается просто решать сложные проблемы. ИМХО, людей страшнее и опаснее в программировании нет. Поскольку последствия расхлёбывают их коллеги и пользователи. Впрочем, может быть я неправомерно обобщаю 
AVK>>>Знаешь, мой опыт показывает обратное. При написании программ на плюсах или Дельфи ошибок получается в разы больше чем на джаве или дотнете, особенно если программеры только учаться.
AVK>>>Еще можешь посмотреть средний процент успешных проектов на джаве и плюсах, статистика общедоступна.

Здесь можно поспорить о причинах. Сама по себе статистика ни о чём не говорит, кроме как о том, что C++ — непростой язык.

А>>Во!!!!! Наконец-то!!! Ну спасибо, порадовал :) "...особенно, если программеры только учатся.". Иными словами — C++ — это язык, использование которого апеллирует к высокому уровню развития программиста. Тему топика помнишь?
AVK>Не надо переворачивать с ног на голову. Нормальное использование плюсов возможно только при высокой квалификации программера, причем большая часть этой квалификации — умение обходить плюсовые грабли.
Зато, уж если может нормально использовать!… 
AVK>А поскольку квалифицированных программеров мало, то в результате имеем низкое качество плюсовых проектов в нормальных условиях либо высокую их стоимость.
AVK>Тут вот какое дело — самое главное в мире софтостроения это деньги. И если в итоге новая технология позволяет решить задачу дешевле и качественней то это хорошая технология.
Более качественного решения ты не получишь никогда при таком подходе, поскольку качество, насколько я помню, в своих «высших» проявлениях всё-таки строится на предотвращении проблем, а не на их быстром решении. Кстати, это отражено и в CMM. Возможно, это спорно, но я полагаю, что предотвращение проблемы должно строиться на абстрактной модели, охватывающей множество реальных ситуаций. А здесь мы получим тотальную деквалификацию с очень большой вероятностью, какое уж нафиг предотвращение! Нам будут подкидывать технологию за технологией, для которых всё время не будет хватать спецов!
AVK>А 16-типроцессорные сервера, идеологические убеждения программеров,
Манагёр ты мой драгоценный. Когда же ты перестанешь унижать оппонентов? Кроме того, это твои убеждения смахивают на идеологические.
AVK> средства разработки и прочая мишура это детали. И если создание систем на дотнете окажется экономически выгоднее нежели на традиционных плюсах, то никакой авторитеть страуструпа не поможет плюсам оставаться главным средствам разработки. Где сейчас идеологически правильная дековская альфа? А идеологически неправильные интел и amd снимают сливки с процессорного рынка и все мы благополучно пишем на x86. Идеологически правильные никсы очень круты, но все мы почему то пишем под Win32. Вот такие вот пирожки с котятами.
А зачем в качестве примера приводить историю CPU? С таким же успехом можно привести историю какого-нибудь автомобиля. Это уже опасное передёргивание. CPU – утилитарная вещь, для рыночного успеха которой важно соотношение цена/производительность. Если я не ошибаюсь, то как раз по этому критерию Alpha и проиграла Intel. Только это, чёрт возьми, неряшливая аналогия! Человек – не процессор и может самостоятельно повышать свою производительность на порядки при наличии адекватных инструментов. А инструмент как раз таки и ухудшается! Посмотри, ты не привёл пока ни одного свойства C# как языка, для которого не было бы или невозможно было бы сделать аналог в C++! В данном случае особенности runtime и стандартных встроенных возможностей (по сути – набор реализованных абстракций) не в счёт, поскольку они не решают задач построения абстракций

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

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

ГВ>>Ну уж! Будет он уродским или нет — завистит от разработчика.
AVK>Вот только что то ни у кого пока ничего не вышло.

А ещё зависит от компилятора...

ГВ>>Не согласен. :) Омертвеют задачи, которые привыкли решать на C++. Не более того. Но, поскольку задачи мертвеют редко ;), то и C++ никуда не денется. Пусть сначала достаточное количесвто стандартных компиляторов появится.
AVK>Самое обидное что на платформе Win32 этот язык такими темпами в нынешнем виде сильно потеряет в популярности.
AVK>Задачи непрерывно растут и он уже с ними не справляется. Оглянись — практически ни одной современной ERP системы в которой бизнес-логика пишется на пюсах. Везде свои языки какие нибудь.

И что же в этом плохого? Специализированные языки для специализированных задач. C++ как раз и есть очень хороший инструмент для их реализации.

ГВ>>Множественное наследование — ещё не синоним плохого дизайна. Это — очень ограниченная трактовка. Забавно, но факт — реализация COM для C++ от Microsoft (я имею ввиду ATL) как раз и построена множественном наследовании. Это просто наблюдение, не более того.
AVK>А им деваться некуда, интерфейсов то нет.

Есть. Абстрактные классы.

ГВ>>Здесь создаёт проблемы реализация COM для C++ от Microsoft, а не C++ как таковой.
AVK>Ну хорошо, приведи пример компонентной модели для плюсов которая не имела бы таких проблем. Я просто в свое время этим занимался и понимаю что реализовать подобное без изменений языка намного проще вряд ли возможно. Тыт тут корбу упоминал — так вот, ее реализация еще более мостроидальной выходит.

Далась вам компонентная модель! Ну интерфейсная технология и интерфейсная технология.

ГВ>>Кроме того, я вижу в этом косвенное подтверждение тезиса о том, что C# поддерживает модель реализации, аналогичную COM.
AVK>Не аналогичную а выполняющую те же функции.

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

ГВ>>Ну что же, поздравим себя с этим и пойдём дальше. (c) кто-то
ГВ>>Тем не менее — ограниченность COM-овской модели и аналогичных никуда не делась. :crash:
AVK>Давай конкретно — в чем ограниченность дотнетовской модели?
В ограниченности объектной модели. Шаблонов нет, Множественнного наследования реализаций нет.

IT>>>а) в большиестве случаев решается использованием интерфейсов,
ГВ>>Да, но с потерей простоты реализации.
AVK>Но зато с простотой дизайна. В больших проектах это важнее.

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

IT>>>б) необходимо по жизни в основном для типизированных контейнеров,
ГВ>>Вот! Иллюстрация моего тезиса о том, что ряда вопросов люди себе даже не задают. Кроме контейнеров у шаблонов есть ещё вагон областей применения — поищи в инете по словам "generic programming".
AVK>Ты давай пиши сюда. Знаешь сколько поисковик на этот запрос выдаст? И всерьез думаешь что я или IT будем сидеть и разгребать это? Я думаю что не думаешь. Тогда ты предлагаешь вещи которые заведомо невыполнимы? Интересный метод спора.
AVK>И потом, пусть у меня опыт активного общения с плюсами всего года 3, но IT на сях писал поболе и наверное знает о применении шаблона.



IT>>>Кто именно считает? Я слышу такое утверждение первый раз.

ГВ>>Я. Я так считаю. Этого вполне достаточно для приведения довода в качестве аргумента.

AVK>А я считаю что C++ это скриптовый язык. Ну как, аргумент?

В каком-то смысле – да. Скрипт. Над ассемблером. Но, блин, какой гибкий!

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

ГВ>>Стоп! Если подходить таким образом, то никогда не сделаешь корректного вывода. Я сравнивал базовые модели языков. А аргументов против моих доводов на этом уровне практически не услышал. Пока, во всяком случае. Аргументы в пользу библиотек/инфраструктуры... не того класса, которого жду.
AVK>Вот тебе и говорят что ты не знаешь даже "базовой модели" шарпа и при этом утверждаешь что она плоха. Забавно.

Множественного наследования нет, шаблонов нет. => усложнение реализации систем, выходящих з арамки использования стандартных примитивов C#. Что хорошего?

[skip]
AVK>Знаешь, когда люди, написавшие на плюсах мегабайты кода говорят что язык надо менять я им почему то верю.

Может быть, надо просто компилятор поменять?

ГВ>>Стоп ещё раз. Я не говорю, что ".NET ... полное фуфло, а C++ is cool forever" и никогда так не скажу. Не надо приписывать мне такого способа обобщения. Снова повторюсь, я говорил о базовых моделях языков и их влиянии на развитие программиста как личности, обладающей абстрактным мышлением. И аргументов в пользу того, что у C# или Java — более совершенная модель, чем у C++ я пока не услышал. Скорее — услышал аргументы "против", а именно — "ждём появления темплейтов" и "ждём следующей версии".
AVK>Тебе их несколько раз называли. Отсутствие компонентной модели, рефлекшена, интерфейсов, свойств, событий. Т.е. C++ обеспечивает намного меньшую абстракцию и вынуждает разбираться в большем количестве деталей реализации. Дело не в том что он позволяет что то делать вручную а в том он заставляет делать вручную.

Я рассмотрел это в предыдущем постинге. (http://www.rsdn.ru/forum/message.asp?mid=87539&amp;only

Автор: Геннадий Васильев
Дата: 20.08.02

) Здесь же замечу, что самого правильного набора библиотек не бывает.

ГВ>>Аргументация довода о преимуществах C++ перед Java сама по себе очень простая — C++ даёт больше возможностей по построению и комбинированию абстракций, нежели Java/C#.
AVK>Списочек того что не позволяет С++ я привел. А ущербность такой логики показать легко — ассемблер даёт больше возможностей по построению и комбинированию абстракций, нежели С++. Вывод: ассемблер лучше чем С++.

Никаких абстракций Asm строить не позволяет. Манипулирование кодом макросами намного более опасно и требует большего контроля чем строгая типизация C++.

ГВ>> Пока что, этого никто не опроверг. Факт наличия библиотек, пусть даже встроенных, на данном уровне абстракции "не канает". Далее, я придерживаюсь мнения о том, что мозги лучше развивать со структурно сложными инструментами (C++), тогда будет легче использовать структурно более простые (C#, Java). Этого, собственно говоря, тоже никто не опроверг. Соответственно, не поровергли и исходной посылки — что наинать лучше с C++.
AVK>Зачем забивать мозги особенностями реализации? Чем меньше этих деталей тем качественней обучение. Опыт изучения С++ тяжело перенести на что то иное, ибо большая его часть специфична.

Структурно сложный инструмент – я имею ввиду тот, у которого сложная и стройная структура, а не пачка библиотек, как у Java и C#. Кстати, многие вещи с теми же шаблонами были бы намного проще и отвязанней от деталей реализации, кабы не бесконечные глюки трансляторов. А структурой библиотек уж точно будешь забивать себе мозги.

ГВ>В ограниченности объектной модели. Шаблонов нет

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

А нельзя сделать то же самое с использованием интерфейсов? Как это сделано в Framework?
Что такое шаблон? Это некоторая абстракция с параметрами — типами. При этом типы должны поддерживать определенные операции. Т.е иметь определенный интерфейс.
Между прочим, один из первоначальных вариантов синтаксиса шаблонов в C++ включал явный перечень операций, которые должен поддерживать тип-аргумент, т.е. описание требуемого интерфейса.

Таким образом, в чем еще разница?

1. Шаблон приходится компилировать заново при инстанцировании. Это плохо. Контейнер на основе интерфейсов — не нужно. У шаблонов для каждого типа генерится свой код. Это тоже плоховато.

2. Шаблон может явно оперировать типом-аргументом (это хорошо), например, функция Add может возвращать именно тот тип, которым шаблон инстанцировали, а в .NET приходится приводить тип.

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

Итак, имхо, примерно 1:1, потому что я сомневаюсь в реальности проблемы 3.

Может я забыл что-то очень важное, для чего еще нужны шаблоны?

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

ГВ>Я справшивал твоё мнение. Не передёргивай. На основании чтения я сделаю собственные выводы и не факт, что они совпадут с твоими. Кстати, твоё нежелание оценивать аспекты технологии, которой ты пользуешься, может говорить о том, что ты просто неспособен её оценить. Извини.
Давай все же не будем переходить на личности.
Что же касается моего мнения — я просто подумал что события в дотнете настолько проще в использовании что это в дополнительных комментариях не нуждается. Ты все же погляди, а потом уж будем разговаривать.

AVK>>Ну да — то извращение, посредством которого реализованы события называется набором конструктивов? :)

ГВ>Вопрос: Какие события и где реализованиы? Упреждая возможный ответ: события Win32 — далеко не единственный вариант модели событий.

Все те варианты реализации событий, которые я видел, начиная с Borland C++ 3.1. Где по твоему события реализованы удобнее всего? А Win32 тут не при чем.

AVK>>Знаешь что я тебе скажу? Любой язык навязывает свои решения, даже ассемблер. Полностью избавиться от стандартных решений можно только программируя в машинных кодах. Системы создания приложений в своей эволюции стремяться как можно больше сделать автоматически, без участия программиста. Шарп и джава со своими рантаймами это следущий шаг в этом направлении. Так кто мешал довести С++ до их уровня? Или так и будем еще 30 лет топтаться на месте? Язык это не идол, на который нужно молиться. Он должен развиваться в соответствии с новыми реалиями. Вычислительные мощности и объемы памяти возросли в десятки тысяч раз, появилась уйма новых технологий, некоторые из которых революционны. А язык так и остался почти таким же. Не думаю что это нормально.

ГВ>Так… Ну, здесь у тебя по большей части лозунги… Что-то подобное я слышал, когда бушевал RAD-психоз. Тоже казалось – ща возьмём дельфу, и накропаем прогу на такой скорости, да такую крутую! Только выяснилось, что реально она решала ну… процентов 10-15 проблем… И то – за счёт библиотек.

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

AVK>>Ты ради интереса зайди на дотнетовский форум и посмотри сколько там вопросов по языку и компонентной модели. И сравни с количеством онных в плюсовом форуме.

ГВ>Это некорректный аргумент — аргумент к коллективу. Please, не думай, что я сделаю те же самые выводы, что и ты на основании схожих с твоими наблюдений.
ГВ>Тем не менее вопрос: какой ты сделал вывод на основании сравнения количеств сообщений в обоих типах форумов?

Что языки дотнета проще в освоении и вызывают меньше вопросов.

ГВ>Правильно (про грабли), натыкается, поскольку сразу пытается доказать, что он "крут как якут". C++ (для сложных вещей, в особенности) требует стройности в оформлении мыслей => определённой подготовки => определённого уровня как профессионала. Кстати, что это я? Это как раз-таки сложные вещи требуют всего этого! Что же плохого в том, что человек этому научится? Как я понимаю, плохо в этом только то, что у него возрастут требования к работодателю. Да, но и работодатель от этого только выиграет.

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

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

ГВ>Снова аргументируешь, апеллируя к авторитету.

Какой авторитет? Я тебе факты привожу.

ГВ>Изменение изменению – рознь. Я не люблю не "изменение", а отупление инструмента вкупе с навязыванием эклектики.

Ты много можешь любить и не любить. Но если С++ окажется менее эффективен, мало кому будет интересна любовь или нелюбовь.

AVK>>Не хочется такую глупость опровергать.

ГВ>Моя логика в данном случае простая. Microsoft располагает приличным количеством клиентов-разработчиков из которых большая часть — VB, неплохо знакомых с компонентной моделью + клиентами-разработчиками VC++, ограниченных отклонениями языка от стандарта. Плюс к тому, имеется определённый набор библиотек и концепций — MFC, COM, ATL, plain-Win32. Глядя на развивающуюся Java Microsoft желает зафиксировать аудиторию своих пользователей. (по-моему, вполне логично). Средства: а) показать преимущества своей платформы б) дискредетировать возможную альтернативу.

Ну все правильно ты говоришь. Вот только не надо воспринимать популярность джавы как данность. Джава как технология становится все лучше и лучше и приобретает все больше сторонников. MS, если не хочет остаться не у дел, вынуждена тоже предложить технологии следующего поколения. Если С++ так хорош — почему тогда так популярна Java и VB, Delphi?

ГВ>"Неявное" вытаскивание своей платформы привело к скандалу с Sun (историю с J++ все помнят?) То есть, играть надо на "своём" поле. Вопрос, каким это поле должно быть? Ответ — равноприемлемым для сложившейся аудитории пользователей. Итак — создаётся новая платформа. Такой шаг логичен и с другой стороны — одной компании трудно поддерживать большой набор концептуально разнородных технологий. Вопрос: какие элементы в эту технологию нужно вводить? Здесь следует учесть амбиции MS

Это не амбиции MS, это реальная ситуация на рынке. У Sun с его J2EE тоже такие же амбиции. Как ты думаешь — чего это у них амбиции такие схожие?


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

Во как ты загнул. Ты только забываешь одим маленький момент — конкуренцию. MS пока еще далеко не монополист на рынке средств разработки. Если кто то выпустит средство позволяющее создавать приложения меньшим количеством разработчиков более низкой квалификации, то MS со своими амбициями окажется сам знаешь где (Хотя на самом деле я думаю у MS таких идей нет).


ГВ> Однако, тем не менее, имеется устоявшаяся модель таких понятий, как "событие", "компонент", "интерфейс" и ещё кое-что, что доступно пользователям VC++ (изначально ограниченного в силу несоответствия стандарту). Отсюда, ИМХО, естественно следует внедрение вышеупомянутых идиом на уровне системного базиса новой платформы. Следующий момент — появление горы сразу стандартизуемых конкретных служб и сервисов (изучение последних создаст у массовой аудитории иллюзию повышения своей квалификации — я знаю, что такое "название нужной службы вписать" и это есть в языке "впишите сами"). Часть этих служб будет реализована на уровне runtime, часть — станет элементом стандартного framework и т.п. Чем их больше — тем на самом деле лучше, поскольку подсаженные на подобную иглу пользователи вряд-ли когда с неё слезут.

Вот как раз MS некоторые вещи похоже специально реализовал отвратно чтобы не убивать рынок разработчиков компонентов.

ГВ>Итак: для MS убивается куча зайцев: а) довольна наименее квалифицированная часть пользователей,

Ага, особенно те кому с VB придется переползать на VB.NET, технологию принципиально более сложную.

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

Вобщем все что я тебе могу на это ответить — ты все же поинтересуйся что такое дотнет. О, еще пример в голову пришел — как ты думаешь, на каком языке обычно пишут примеры в книжках про паттерны? Еще сходи на www.microsoft.com/net, там есть раздел Architecture Center


Ты извини, я не могу такие длинные топики поддерживать, поэтому дальше я буду кратенько.

ГВ>>>>>Ну, во-первых. Сравнивать COM (в сущности — способ структурирования коммуникаций)
А>>>Помню. Только ещё помню довольно редкие случаи корректного его (принципа) применения. Кстати, какую сущность я здесь придумал?
AVK>>А ты свои слова перечитай еще раз.
ГВ>Я назвал COM способом структурирования коммуникаций. Пусть немного некорректно. Корректно, ИМХО, было бы так: Component Object Model часто используется как базисный набор абстракций для структурирования взаимодействия элементов программного комплекса в среде Windows. По-моему, не противоречит предыдущему высказыванию. А не для этого ли он разработан?
Нет, это следствие. COM разработан для стандартизации компонентной модели построения систем. А то что его можно использовать для обмена это уже его применение. У кома еще много сфер применения.

ГВ>С помощью CORBA (ключевое слово — Architecture) в общем можно решить те же проблемы, что и с помощью COM, за исключением среды Windows, где наиболее распространённые приложения поддерживают только COM.

Ага, а локальные интерфейсы как же? В корбе их, того, нет. А вот в коме есть. И в ejb 2 есть.

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

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

AVK>>Э нет, так не пойдет. Это ты утверждал что в MS идиоты и на самом то деле все можно сделать намного лучше. Вот и расскажи как это сделать.
ГВ>Я никогда не называю оппонента идиотом.

А как еще назвать того кто сделал очень сложно если можно сделать намного проще? Ты ведь утверждаешь что на С++ можно реализовать более стройную модель чем даже то что есть на дотнете. Сказал А, говори Б. А то получается что мол нагородили в коме бог знает чего все можно сделать намного проще, но на самом деле они молодцы. Что то у тебя не стыкуется.

AVK>>А может просто ввести интерфейсы в язык? И все, и никаких сложных слоев.
ГВ>Слои непременно появятся. Это будут слои реализации интерфейсов. В противном случае – будет внутренняя эклектика на уровне реализации приложения. Логичное следствие эклектики для программного продукта – экспоненциальный рост трудоёмкости сопровождения и развития.
Не, ты чего то недопонимаешь. Либо мы вводим интерфейсы в язык и получаем очень элегантное решение многих задач, либо не вводим и эмулируем тем что есть и получаем что то вроде кома. Если ты видишь третий вариант то давай, рассказывай какой.


AVK>>Вот такие вот стойкие защитники языка уже сколько раз пытались GC на плюсах реализовать. И чо то у них ничего не вышло пока. Не подскажешь почему?
ГВ>Потому что в плюсах он не нужен. Есть идиомы умных указателей и ещё много чего, вполне заменяющего GC.

Опять же не решают смарт поинтеры всех проблем. GC дает замечательную вещь — 100% гарантию освобождения ресурсов памяти. Это позволяет решить многие задачи намного элегантнее. Более того, отсутствие необходимости вобще как то следить за памятью позволяет вводить более высокие и стройные уровни абстракций.


AVK>>И, это, ты так интересно забываешь про рефлекшен все время. Реализуй ка мне его на плюсах ввиде либы. А заодно может чего с динамической генерацией классов и CodeDOM придумаешь.
ГВ>Динамически генерировать классы на C++ можно. На здоровье: таскаешь компилятор с библиотеками вместе с приложением – и полный вперёд!

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

ГВ>А что до рефлекшена, так он теоретически может быть реализован front-end компилятором. Вопрос – зачем?

Во как, рефлекшен уже не нужен. Нет уж, без изменения всего рантайма рефлекшен не реализовать. Для него нужно тащить полную информацию о типах, в типах иметь ссылки на эти метаданные, иметь возможность на лету грузить объекты, иначе действительно рефлекшен не особенно то и нужен. Попытка реализовать рефлекшен существующими средствами приводит .. да, к кому с его QueryInterface, IDispatch и tlb.

ГВ>Налицо подмена понятий. Комовские навороты нужны были для обеспечения иерархического упорядочивания коммуникативных свойств

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


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

Вот как раз это и есть одна из основных задач рефлекшена.

ГВ> Однако, неужели ты находишь, что подобный подход может серьёзно упростить решение проблемы устойчивости программы? Как раз-таки, устойчивость проще обеспечить в условиях жёсткой фиксации семантики, а не распознавания её «на ходу». COM – это так… частный случай выражения семантики взаимодействий.

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

ГВ>Итак, что же предлагаешь ты?
AVK>>1) Рефлекшен
ГВ>Не является средством построения / комбинирования абстракций. Компонент общей системы контроля и run-time-распознавания типов. Внимание! Ключевое слово – runtime.
Вот как раз является. Рефлекшен это как бы следующая абстракция за виртуальностью. Т.е. позволяет осуществить полиморфизм не знаю даже базового типа объекта. Позволяет создавать автоматически описывающие себя объекты и отказаться от регистрации вроде той которая нужна кому. Ну и много чего еще рефлекшен позволяет. Эмиттинг кода или автоматическая генерация стабов без рефлекшена не возможна.

AVK>>2) Эмиттинг кода
ГВ>Хммм… встроенный ассемблер машины стековых, похоже вычислений. И что здесь такого? Помнится, даже сам писал что-то подобное.  Очень несложно реализуется на C++ с использованием шаблонов и пр., если необходимо.
Эмиттинг компонетов заметь, а не просто кода.

ГВ>На C++ решается библиотеками.
Решается. Пример — ком.

ГВ> Не является средством построения абстракций. Ну, в крайнем случае, в той же степени, что и транслятор.
Еще как является. Попробуй прикинуть насколько проще и стройнее будет выглядеть поисковик если будет генериться код для поиска вместо оптимизации и интерпретации.

AVK>>3) Поддержка ремоутинга на уровне языка (это в дотнете, в джаве все как в плюсах с дкомом, может немножко попроще). Никаких стабов и скелетонов, никаких idl и tlb. Все встроено в рантайм и не требует внимания программиста. Создание удаленного объекта сводится к оператору new.
ГВ>Не является средством построения абстракций

Является. Почти полностью стираются границы между удаленными объектами и локальными. Абстракция чистейшей воды.

ГВ> Как я понимаю, ремоутинг может полностью поддерживаться только в рамках CLR

Нет. SOAP как бы стандарт все таки. Да и написать свой форматтер не есть проблема.

ГВ> или же COM для не-CLR-объектов.

У кома свои средства. Тебе уже сказали, ком в дотнете только для совместимости.

ГВ> С точки зрения C++ решение такой задачи — интерфейсы + фабрики классов (необязательно – COM-овских). Деталь окружения, порождённая от COM и отразившаяся на структуре языка. Впрямую не решается на C++ за счёт отсутствия единой runtime-среды для программ на C++ Навязывание единой фабрики классов.

Вот примером решения как раз и является ком. Результат не впечатляет, хотя в общем то работает.

AVK>>4) Домены приложений. Т.е. можно создать изолированную от внешнего мира песочницу с ограниченными правами.
ГВ>Не является средством построения абстракций

Да ну? А что же тогда является? Опять же — чистейшей воды абстракция, виртуальное, так сказать, приложение.

ГВ>Модель управления доступом.

Не только доступом. Опять же что такое модель как не абстракция?

ГВ> Это Не свойство языка как такового. Разные среды – разные модели.

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

AVK>>5) Поддержка потоков встроенная в язык.
ГВ>Не является средством построения абстракций

Ага, конечно. Поток это тоже абстракция. А механизмы языка реализуют некую более абстрактную модель потока ОС.

ГВ> Я усматриваю в этом прямое отображение модели CLR на концепции C# + реализацию многопоточности. Да, примитив lock встроен в язык как ключевое слово. А в C++ lock – это может быть и объект и аргумент шаблона. C++ не содержит прямого языкового аналога lock, но это может быть сделано библиотеками.

Может быть. Но почему то все реализации менее удобны чем то что есть в джаве и дотнете.

AVK>>6) Черт возьми, почему в плюсах нету try..finally?
ГВ>Как это соотносится с построением абстракций? Зачем? Разрушение локальных ресурсов решается деструкторами. Это есть прямое потакание плохому стилю программирования.

Ага, многоэтажные конструкции это конечно лучший стиль чем finally. Тогда надо выкинуть break и continue.

AVK>>7) Интерфейсы
ГВ>Является средством построения абстракций. В C++ имеется прямой аналог — абстрактные классы. Имеется прямой аналог в C++

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

AVK>>8) GC
ГВ>Не средство построения абстракций

Сборщик мусора позволяет не воспринимать больше память как ресурс (С) IT, т.е. в итоге приводит опять к абстракции.

ГВ>Не средство построения абстракций. Это, конечно, экстремизм  с моей стороны, но на C++ такая задача решается библиотеками, выбирающими каталог, откуда извлекаются компоненты. Реализуется библиотеками C++


Не библиотеками а средствами построения компонентной модели.

AVK>>10) боксинг и анбоксинг. Т.е. простые типы вроде int и string не ломают объектную парадигму, являясь объектами и при этом не теряя эффективность.
ГВ>Средство runtime-контроля, не является средством построения абстракций.

Чистейшей воды абстракция. Позволяет работать с простыми типами одновременно как с объектами и как с простыми типами. Если это не средство абстрагирования от конкретики то что же тогда средство?

ГВ> Привязали, значит, указатель из CLR-хипа к адресу объекта, который естественно стал managed, поскольку на него есть прямой доступ… Берем шаблонные классы с inline-методами C++ и получаем аналог. Шаблоны C++

Не, совсем не так. value-типы в хипе не храняться.

AVK>>11) Stack trace
ГВ>Вспомогательная подсистема. На C++ может реализовываться с помощью Debug API и exception-ами. Периодически, конечно, необходимая вещь… Ах да! У нас же тут неизвестно какой объект неизвестно где создаётся… Ну, тогда Реализуемо на C++. в зависимости от среды исполнения.

Тока пока что то никто не реализовал.

AVK>>12) Встроенная в язык и рантайм сериализация. Всем плюсовым аналогам до ней очень далеко.
ГВ>Это всего лишь готовое решение, а не способ их сиснтеза! Даже если здесь добавляется контроль типов. Итак, снова библиотеки… Реализуется библиотеками на C++

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

AVK>>13) Атрибуты.
ГВ>Не является способом построения абстракций

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

ГВ>Атрибуты могут быть привязаны к элементу описания типа (вероятно).

К сборке, к полю, к методу и т.п.

ГВ> Позволяют решать задачи идентификации элемента описания во внешнием контексте.

Позволяет внедрять в код свои собственные метаданные.

ГВ> Но это – часть общей стреатегии использования типов и информации о них, ёлки палки! На C++ аналогичная задача решается статическими дескрипторами классов или (по идее  ) front-end компиляторами. Решается библиотеками

Не решаема на С++ без изменения языка принципиально. Для этого компилятор должен уметь создавать экземпляры классов во время компиляции и сериализовывать их в скомпилированный код.

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

Однако при поддержке со стороны языка решается намного элегантнее.

ГВ>Теперь попробую подбить итоги: из 14-ти названных особенностей абсолютное большинство (13) – предлагаемые способы Microsoft

Далее при неверных предпосылках неверные выводы.

AVK>>Я вот чего то не въехал — чем это удобнее виртуальных контейнеров? Такие контейнеры могут хранить любые типы, даже те о которых на момент компиляции ничего не известно. И так же можно в зависимоти от типа применять специфический алгоритм, хотя это и плохой дизайн на самом деле.

ГВ>Ту-ту-ту! Для этого тебе придётся подменять реализацию контейнера, или вводить интерфейс-импортёр алгоритма,

Зачем? Ты про рефлекшен и боксинг позабыл уже? И про то что везде кроме С++ существует базовый класс для всех классов?

AVK>>Это не деталь, это ключевая особенность. Именно она позволяет не воротить монстроидальных комов.
ГВ>Ага,  при условии гомогенного runtime.

А язык без рантайма это чистейшей воды абстракция.

ГВ>В данном случае всё будет работать только при условии наличия .NET Не могу сказать, что это – критический недостаток, но и сгенерировать vtbl – не суперсложная задача, если приспичит. Как я понял, на C# предлагается генерировать ассемблер… Опровергни меня, плиз, если я не прав. Только, чур, аргументированно!
Можно машинные коды, если скорость критична. А можно исходники на любом дотнетовском языке — все компиляторы умеют в память компилировать.

AVK>>Уверен, пробовал. И объектная модель у них не покореженная, она по крайней мере не хуже плюсовой.
ГВ>Хуже. Пока что я в этом уверен.

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

AVK>>Ну и что в этом плохого, если этот сервер обходится дешевле чем работа программиста в течении месяца?
ГВ>Ничего плохого. Только программистов таких может уже и не остаться при подобном подходе к программированию. Вот тогда-то и запоём.

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

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

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

AVK>>>>Еще можешь посмотреть средний процент успешных проектов на джаве и плюсах, статистика общедоступна.
ГВ>Здесь можно поспорить о причинах. Сама по себе статистика ни о чём не говорит, кроме как о том, что C++ — непростой язык.

А нафига он нужен, такой непростой?

ГВ>Зато, уж если может нормально использовать!… 

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

ГВ>Более качественного решения ты не получишь никогда при таком подходе, поскольку качество, насколько я помню, в своих «высших» проявлениях всё-таки строится на предотвращении проблем, а не на их быстром решении.

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

ГВ>Кстати, это отражено и в CMM. Возможно, это спорно, но я полагаю, что предотвращение проблемы должно строиться на абстрактной модели, охватывающей множество реальных ситуаций. А здесь мы получим тотальную деквалификацию с очень большой вероятностью, какое уж нафиг предотвращение! Нам будут подкидывать технологию за технологией, для которых всё время не будет хватать спецов!

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

AVK>>А 16-типроцессорные сервера, идеологические убеждения программеров,
ГВ>Манагёр ты мой драгоценный. Когда же ты перестанешь унижать оппонентов? Кроме того, это твои убеждения смахивают на идеологические.

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

ГВ>А зачем в качестве примера приводить историю CPU?

Родственная область.

ГВ> С таким же успехом можно привести историю какого-нибудь автомобиля.

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

ГВ>Это уже опасное передёргивание. CPU – утилитарная вещь, для рыночного успеха которой важно соотношение цена/производительность.

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

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

Аналогия была не человек-процессор, а программная система-процессор.

ГВ>А инструмент как раз таки и ухудшается! Посмотри, ты не привёл пока ни одного свойства C# как языка, для которого не было бы или невозможно было бы сделать аналог в C++!

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





В общем резюме — я предполагаю что главная причина неприятия всех новых технологий это нежелание менять устоявшуюся ситуацию. Это вполне понятно, убил человек уйму времени на изучение какой то технологии, а тут ему говорят что надо по новой переучиваться.
Но вернемся к предмету спора — лучше дотнет С++ или хуже это третий вопрос. Главное — MS обязательно сделает дотнет основным средством разработки под Win32. % Win32 ты знаешь. Так зачем новичку С++, если все равно скорее всего ему придется писать на дотнете?

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

[skip]

IT>Речь шла об ивентах и свойствах, правильно? Если бы хоть одному разработчику удалось сделать это более менее элегантно, то все мы уже давно бы пользовались плодами этих трудов. Но пока что-то не видно нормальных решений. При этом разработчики компиляторов каждый по своему добавляют свойства в язык. Т.е. сделать это совсем не трудно. Не понятно, почему это не добавлено до сих пор в стандарт. В чём проблема?

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

[хрясь]

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

Тут не согласен. Более развитая среда программирования – ещё соглашусь, но сами языки… "Увитием" C++ назвать ещё можно, а развитием... Ну, набиты они библиотеками и развитым рантаймом под самое не балуйся. И что с того?

IT>>>2. Множественное наследование — которое является синонимом плохого дизайна.

ГВ>>Множественное наследование — ещё не синоним плохого дизайна. Это — очень ограниченная трактовка. Забавно, но факт — реализация COM для C++ от Microsoft (я имею ввиду ATL) как раз и построена множественном наследовании. Это просто наблюдение, не более того.

IT>Хорошо. Я должен был более подробно разъяснить то, что я понимаю под этим пунктом. C++ пожалуй лишь один из современных языков, поддерживающих множественное наследование в полном объёме. Интерфейсы — это из этой области, но это как раз та часть, которая реализуется очень легко и присутствует во многих языках. Но это не настоящее :) множественное наследование. Я надеюсь мы оба понимаем о чём речь.

Согласен. Я тоже не считаю интерфейсы множественным наследованием.

IT>При реализации интерфейсов мы не думаем о данных, которые мы наследуем от производного класса.
Не производного – базового.
IT>А значит у нас нет проблем с неоднозначностью доступа к ним и с тем как кастить объект к базоваму классу и обратно. Нет проблем с diamond структурами и нет необходимости загромождать язык виртуальным наследованием, чтобы всё это обойти.
Извини, ну ты и смешал всё в кучу. Давай разделять: наследование реализации, наследование интерфейсов и преобразование типов.
Итак, по порядку. Откуда при реализации интерфейса возникает проблема данных базового класса?

Это всё верно, но виртуальное наследование просто гарантирует единственность экземпляра реализации класса-родителя в экземпляре наследника независимо от промежуточного наследования.

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

IT>>>Это очень круто, только у меня есть вопрос — а зачем? 95% современных задач требуют умения работы с базами данных, а не с указателями.

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

IT>И при чём тут указатели?

Мммм… Если ты припомнишь ветку, то я и не говорил об адресной арифметике. По-моему, ты сам (или AndrewVK) сказал, что «большинство пальцев C++-ников» основано на умении работать с указателями. А я попытался не очень удачно вернуть дискуссию в прежнее русло. Так что, вопрос не по адресу и не к месту.

[речь шла о маркетинговых целях C# и Java]
IT>>>Аргументы, плиз, в студию. Мы их рассмотрим и может быть согласимся, может просто посмеёмся, но скорее всего поспорим.

См. постинг к AndrewVK. Может быть, несколько сумбурно.

ГВ>>>>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun,

IT>>>Проблемы переносимости не существует, всё это всего лишь маркетинг.

ГВ>>Извини, не понял. Что — "всё"? Проблема переносимости или виртуальность её решения с помощью Java?

IT>Sun преподносил Java как средство решения проблем переносимости. Но жизнь показывает, что одна и таже Java, но от разных вендоров порой не совместима, а иногда нужно пошаманить, чтобы добится совместимости и между разными версиями от одного производителя. Впрочем, речь у нас сейчас не об этом.

Совершенно согласен. Речь о различии способов реализации абстракций средствами разных языков – C# и C++ и о предпочтительном инструменте для начала развития программиста..

ГВ>>Здесь создаёт проблемы реализация COM для C++ от Microsoft, а не C++ как таковой. Кроме того, я вижу в этом косвенное подтверждение тезиса о том, что C# поддерживает модель реализации, аналогичную COM.

IT>COM был нормально реализован для C++. Не вижу здесь проблем. И вообще COM — это весьма серьёзная технология для своего времени. Просто время это проходит, вот и всё.

Да никуда никакое время не девается ;) Проблемы все те же самые. Впрочем, ладно, это уже не по существу.

IT>Последнее "подтверждение тезиса" меня как раз лишний раз убеждает в том, что речь идёт о предмете о котором нет чёткого понимания. C# и COM совершенно разные и несравнимые вещи. Можно сравнивать COM и CLR, можно C# и C++, но не COM и C#. Но даже если речь идёт о COM и CLR, то могу тебя уверить, что наличие поддержки COM в .NET сделана только из соображений совместимости. Модель в .NET другая, ну то есть абсолютно разная.

Да, согласен, что неправомерно сравнивать COM и CLR, но модель C# как языка очень много унаследовала от компонентной модели COM.

[skip]

IT>В чём именно ограниченность COM-вской модели?
Ограниченность COM-модели состоит в том, что она не позволяет гибко управлять абстракциями – по крайней мере, так же гибко, как и C++. Такая же беда есть и у Java.
IT>>>б) необходимо по жизни в основном для типизированных контейнеров,

ГВ>>Вот! Иллюстрация моего тезиса о том, что ряда вопросов люди себе даже не задают. Кроме контейнеров у шаблонов есть ещё вагон областей применения — поищи в инете по словам "generic programming".

IT>Я могу открыть исходники ATL и всё это созерцать там в полный рост. Но только я не собираюсь предлагать новичкам начать изучать программирование с GP. На этом всё их программирование тут же и закончится. К тому же именно из-за своей сложности GP вряд ли получит широкое применение.

Я, собственно, тоже не предлагаю новичкам начинать с GP. Я предлагаю начинать с C++, как более сложного инструмента, в котором реализованы такие методы управления абстракциями, понимание которых существенно упростит для новичка постижение широкораспространённых инструментов. Ну и… всячески развиваю мысль о том, что на сложных инструментах учиться лучше, чем на простых. Тем более, если базовая подготовка уже есть.

IT>>>в) интересный термин — инлайнирование . По сути, перекладывание задач оптимизации на плечи программиста. Временные издержки нашего времени, ничего более.

ГВ>>Мммм... Да нет так тут всё просто... Вызовы виртуальных функций не очень-то оптимизируешь вобщем...

IT>Тот же ATL великолепно демонстрирует возможность замены виртуальных функций с помощью GP, и это совсем неплохо оптимизируется.

Обрати внимание – что это возможно при наличии GP! А в Java/C#-то GP нет!!! Так что, сие есть пусть косвенное, но подтверждение.

[Java, C++, файлы – хватит о них ;) ]

ГВ>>>>Прикол как раз в том, что когда работаешь со скриптовыми языками, часто даже не задаёшь себе тех вопросов, которые не боишься ставить, используя C++. А C# и Java я как раз и считаю разновидностью скриптовых языков, посольку ИМХО они апеллируют к реализации каких-то элементов системы на других языках.

IT>>>Кто именно считает? Я слышу такое утверждение первый раз.

ГВ>>Я. Я так считаю. Этого вполне достаточно для приведения довода в качестве аргумента.

IT>Ну тогда бы мне очень хотелось услышать этот довод. Правда, очень интересно знать почему C# и Java относятся тобой к скриптовым языкам.


ГВ>>Стоп! Если подходить таким образом, то никогда не сделаешь корректного вывода. Я сравнивал базовые модели языков. А аргументов против моих доводов на этом уровне практически не услышал. Пока, во всяком случае. Аргументы в пользу библиотек/инфраструктуры... не того класса, которого жду.

IT>Это тоже заблуждение. Язык не может быть отделён от своего окружения. Даже C++. Если ты пишешь на C++ под Windows и не имеешь опыта в Unix, то никто тебя не возьмёт писать систему для последнего. Язык можно и нужно рассматривать в контексте его окружения.

Это – вполне конкретные частные глюки тех, кто считает, что программист "под XXX" — это набор знаний конкретного API (и только он). В сущности — базовые абстракции, реализованные в различных ОС — похожи.

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

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

Хорошо. В C#/CLR я новичок, Java знаю чуть лучше. C++ использую уже около восьми лет. Плюс теория, базовое образование и т.п.

IT>Моя модель такая. Для нормального владения тем же C++ нужно примерно 1-1.5 года интенсивной работы с ним. Если это первый изучаемый язык, то возможно нужно больше времени. После этого уже не придётся оправдываться, что мол типа я давно на нём не писал и уже забыл. Дальше уже без разницы сколько там лет. Но, если человек использует технологию постоянно в течении скажем 3-4 лет, то вопросов у меня вообще к нему никаких нет.

Я считаю примерно так же.

ГВ>>Стоп ещё раз. Я не говорю, что ".NET ... полное фуфло, а C++ is cool forever" и никогда так не скажу. Не надо приписывать мне такого способа обобщения. Снова повторюсь, я говорил о базовых моделях языков и их влиянии на развитие программиста как личности, обладающей абстрактным мышлением. И аргументов в пользу того, что у C# или Java — более совершенная модель, чем у C++ я пока не услышал. Скорее — услышал аргументы "против", а именно — "ждём появления темплейтов" и "ждём следующей версии".

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

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

[skip]

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

Нет-нет-нет. Не согласен. На Ассемблере нельзя выразить абстракцию также, как на C++, хотя его знание само по себе – полезно. Кстати, работа с эмиттингом кода, если не ошибаюсь, включает знание виртуального ассемблера CLR – MSIL. Может быть, я ошибаюсь. Поправь, если не так.

IT>Что касается тезиса о том, что чем сложнее язык, тем лучше будущему программисту, то я уже как-то не уверен в этом. Здесь можно провести аналогию с автоматической и ручной коробкой передач. Ты можешь виртуозно управлять ручной коробкой, но, например, в штатах тебе это скорее всего не понадобится. Да и шансов у ручной коробки мало на длинных дистанциях, устаешь сильно, в пробках особенно. А для сверх длинных у автоматов существует ещё и круиз-контроль. Выставил скорость и сиди кури и наблюдай окрестности, ну там про руль не забывай :)

Знаешь, в ответ н эту аналогию: C++ — это полуавтомат, который ты сам можешь довести до необходимого тебе автомата, Java – полуавтомат, который гораждо сложнее развивать.

ГВ>>Спор же о преимуществах той или иной библиотеки в данном контексте считаю просто неуместным.

IT>Я так не считаю.

Библиотека – суть набор конкретных решений, тогда как структура языка – набор методов их реализаций.

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

ГВ>>В ограниченности объектной модели. Шаблонов нет

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

Ну вот, собственно говоря, для этого в основном и нужны. Для обощенного программирования реализаций.

IT>А нельзя сделать то же самое с использованием интерфейсов? Как это сделано в Framework?
IT>Что такое шаблон? Это некоторая абстракция с параметрами — типами. При этом типы должны поддерживать определенные операции. Т.е иметь определенный интерфейс.

Да... Где-то так. Только здесь нужно чётко понимать, что "интерфейс" — это не только набор методов. Фактически, шаблон может специфицировать и наличие определённых полей данных, которые, впрочем, можно подменить перекрывая операторы присовения и т.п.

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

Угу. Кстати, ИМХО, жаль что такой возможности нет. Можно было бы жёще контролировать согласование типов.

IT>Таким образом, в чем еще разница?

IT>1. Шаблон приходится компилировать заново при инстанцировании. Это плохо. Контейнер на основе интерфейсов — не нужно. У шаблонов для каждого типа генерится свой код. Это тоже плоховато.

Эээ! Не так всё просто. Методы шаблона + методы аргументов могут быть вместе инлайнированы. Тогда как при runtime-связывании тебе нужно учитывать наличие, как минимум, двух дополнительных шагов: 1. Получение доступа к интерфейсу контейнера (к примеру, List), 2: Предоставление ему интерфейса элемента (пусть, например — ListItem). Обрати внимание — два дополнительных шага. Если учесть, что поиск нужного интерфейса по идее лучше всего тоже переложить на runtime, то получаем помимо увеличения времени исполнения (да хоть и фиг бы с ним) сразу ещё дополнительное усложнение программирования в том смысле, что контроль хотя бы наличия нужного интерфейса может быть произведён только в процессе работы программы. А значит дополнительное тестирование, дополниетльные сборки/разборки и т.п. Само по себе это всё, даже если и происходит быстро, то напоминает оптимизацию пузырьковой сортировки посредством установки более мощного процессора :)

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

IT>2. Шаблон может явно оперировать типом-аргументом (это хорошо), например, функция Add может возвращать именно тот тип, которым шаблон инстанцировали, а в .NET приходится приводить тип.

Не только в возвращаемых значениях дело. Шаблоны, также, позволяют использовать куски кода (inline-методы) как элементы определения типа. Компонуя такие элементы ты не так сильно проигрываешь в быстродействии, как при runtime-связывании, следовательно — можешь построить более развитую абстракцию (в смысле — глубже структурировать абстракции), работающую гораздо быстрее, чем при реализации runtime-связывания. ИМХО, чем мельче структурированы абстракции уровня реализации, тем больше шансов получить более надёжную программу с меньшим циклом тестирования. Хотя бы просто за счёт того, что повторяющийся код будет вынесен в шаблоны.

IT>3. У шаблону можно попытаться применить тип, созданный задолго до написания шаблона — есть нужные операции — хорошо, нет — не получится. А вот с контейнером или обобщенным алгоритмом на базе интерфейсов это может не пройти, если нужен специфический интерфейс, а предметный тип — старый, да еще и sealed. Но может это и надуманная проблема.

IT>Итак, имхо, примерно 1:1, потому что я сомневаюсь в реальности проблемы 3.

IT>Может я забыл что-то очень важное, для чего еще нужны шаблоны?
IT>

Проблема на самом деле глубже. С уровня высоких руководящих вершин её видно, но она тем не менее есть.

Попытаюсь проиллюстрировать на простом примере.

Допустим, имеется некий метод, исполнение которого включает обращение к 5 инлайнированным шаблонам. Шаблонами реализованы некие алгоритмы, предположим, достаточно быстрые (например, то же самое помещение объекта в список). А при реализации того же самого на базе runtime-связывания тебе придётся или городить высокоуровневую оптимизацию или довольствоваться 5-ю дополнительными вызовами. Время выполнения будет отличаться сильно. Естественное следствие — "утыкание" в пределы приемлемой производительности системы, перешагнув которые придётся менять реализацию, например, для того, чтобы свести 5 вызовов к одному. Чуешь, да? Абстракции, реализуемые программистами часто усложняются и развиваются хотя бы ради того, чтобы избавить их самих от рутинной работы (что бы ни говорили по этому поводу менеджеры :-\\ ) и чтобы в конечном счёте избавиться от части нареканий на качество продукта, меньше морочаться с тестированием и т.п. Но в случае только runtime-связывания, предел допустимого падения производительности системы будет достигнут гораздо быстрее, что неизбежно приведёт к снижению качества программ.

То есть, здесь почти "колдовская" фишка. :no: Отсутствие такой простой возможности, как встваить один кусок кода с определёнными свойствами в другой кусок кода автоматически влечёт кучу побочных проблем. Здесь, кажется, можно даже численно выразить зависимость... Хм... Надо попробовать...

Ну и пара вздохов в заключение ;)

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

А что до криков по поводу того, что скоро P10 будет минимальной конфигурацией, так ерунда это всё. Даже если так и будет. Всегда пользователи будут экономить на покупке и компьютеров и ПО. Всегда будут таким образом предъявлять к компьютерам требования, находящиеся на грани их возможностей.

Ага...Спасибо.

Правда, тут Страуструпа посмотрел — у него есть кратенькое, но доходчивое описание плюсов и минусов контейнеров a la Framework и контейнеров a la STL.

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

Я здесь многое поскипаю, а то топик и правда омонстрел :)

AVK>Что же касается моего мнения — я просто подумал что события в дотнете настолько проще в использовании что это в дополнительных комментариях не нуждается. Ты все же погляди, а потом уж будем разговаривать.

Поглядел. :) Кстати, особо не впечатлился. Стандартное решение и стандартное решение. Приведи примеры реализаций чего-либо с использованием событий.

ГВ>>Вопрос: Какие события и где реализованиы? Упреждая возможный ответ: события Win32 — далеко не единственный вариант модели событий.

AVK>Все те варианты реализации событий, которые я видел, начиная с Borland C++ 3.1. Где по твоему события реализованы удобнее всего? А Win32 тут не при чем.

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

AVK>>>Знаешь что я тебе скажу? Любой язык навязывает свои решения, даже ассемблер. Полностью избавиться от стандартных решений можно только программируя в машинных кодах. Системы создания приложений в своей эволюции стремяться как можно больше сделать автоматически, без участия программиста. Шарп и джава со своими рантаймами это следущий шаг в этом направлении. Так кто мешал довести С++ до их уровня? Или так и будем еще 30 лет топтаться на месте? Язык это не идол, на который нужно молиться. Он должен развиваться в соответствии с новыми реалиями. Вычислительные мощности и объемы памяти возросли в десятки тысяч раз, появилась уйма новых технологий, некоторые из которых революционны. А язык так и остался почти таким же. Не думаю что это нормально.
[…]
AVK>Ты погляди для интереса сколько лет джаве.

C++ тоже эволюционировал, только в области развития средств манипулирования абстракциями (шаблоны добавились), а не по части попыток вобрать в стандартные библиотеки всё и вся. Кстати, ИМХО, действительно жаль, что стандартных общепринятых прикладных библиотек не так много, как хотелось бы.

[…]
ГВ>>Тем не менее вопрос: какой ты сделал вывод на основании сравнения количеств сообщений в обоих типах форумов?

AVK>Что языки дотнета проще в освоении и вызывают меньше вопросов.

Ну и что с того? Да, они в чём-то проще чем C++. И, соответственно, предоставляют меньше возможностей конструировать абстракции без потерь производительности программиста и его продукта.

[…]
AVK>Не, ты специально прикидываешься? То, что многие вещи в языке неочевидны и требуют изменения стиля мышления ты считаешь его достоинством?

Я считаю его достоинством стройность мышления, и логичность концепций, к которым он апеллирует в отдельных своих элементах, отсутствующих в Java/C#. Кроме того, эта самая стройность мышления является очень неплохим основанием для разработки качественных программ.

AVK>А знаешь на чем больше всего пишут?

Да хоть на PL/1. И что? :) Пусть пишут. Вопрос в том – кто. Школьники, вон, на Фокале может ещё где-то пишут. Помимо того, что это — аргумент к авторитету в лице коллектива, это само по себе не умаляет достоинств C++ как языка.

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

Гарантирую: ты всё время будешь решать примерно одни и те же проблемы — согласования семантики компонентов и связанного с этим оверхеда. И уж проблеме точно будешь уделять всё доступное время. Ну ладно – необязательно. ;)

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

Правильно, средство. И я утверждаю, что C++ — исключительно мощное средство, которым, к сожалению, мало кто умеет пользоваться. Но это не аргумент против языка. Это всего лишь констатация недостатка образования или интеллекта. Знаешь, тот факт, что не все умеют кататься на двухколёсном велосипеде ещё не означает, что к нему нужно приделывать колёсики сбоку. ((c) не помню кто – то ли Голуб, то ли Элджер)

AVK>>>Я вобще не понимаю откуда эта нелюбовь к изменению языка. Вон Борланд паскаль меняет не особо стесняясь и я не думаю что от этого стало хуже.
[…]
AVK>Какой авторитет? Я тебе факты привожу.

Извини, я тебя неправильно понял. Просто, зачем нужен такой факт. Да, Borland упорно подтягивает Pascal к C++ (он и изначально, если не ошибаюсь, базировался именно на урезанной модели C++). Но в любом случае, это – личное дело Borland.

ГВ>>Изменение изменению – рознь. Я не люблю не "изменение", а отупление инструмента вкупе с навязыванием эклектики.

AVK>Ты много можешь любить и не любить. Но если С++ окажется менее эффективен, мало кому будет интересна любовь или нелюбовь.

Вопрос не в любви. C++ вполне эффективен при грамотном использовании. И, кстати, ты имеешь ввиду C++ или библиотеки/framework ? Так и библиотеки для C++ сейчас тоже развиваются. Ну, о них я уже говорил…

[skip]
ГВ>>Каковы следствия для пользователей? Следствия естественны – попав в среду с большим количеством ответов на конкретные вопросы пользователи скорее будут вынуждены заняться поиском вопросов, на которые им даны ответы, нежели развитием себя как реализаторов абстракций.

AVK>Вобщем все что я тебе могу на это ответить — ты все же поинтересуйся что такое дотнет.
Уже интересуюсь…
AVK> О, еще пример в голову пришел — как ты думаешь, на каком языке обычно пишут примеры в книжках про паттерны? Еще сходи на www.microsoft.com/net, там есть раздел Architecture Center

В книжках каких издательств? “Обычно”, говоришь, Microsoft, говоришь… Однако, насколько я помню, паттерны в основном пишут на языке квадратиков и стрелочек… или – на английском (реже – на русском  ). В частности, они могут быть сформулированы на каком-либо языке программирования. Architecture Center изобилует выражениями ‘for .NET’, ‘for Exhange’ и т.п. Я понимаю, что здесь сформулированы паттерны, работающие для конкретных продуктов MS, но причём тут «вообще»? А «общефилософские» книги от MS Press я вообще стараюсь стороной обходить или использую только как справочники по конкретным технологическим решениям. Интеллект, ИМХО, целее остаётся.
Кстати, вот тебе для ознакомления: http://hillside.net, http://www.acm.org, http://www.cs.wustl.edu/~schmidt/CACM-editorial.html, http://www.cs.wustl.edu/~schmidt/patterns.html
Посмотри.
Кстати, замечу, что подмена общего частным (в данном случае – общего паттерна частным его случаем) – очень распространённый способ манипуляции людьми. Например, вместо явного уточнения – «для системы такой-то», достаточно опустить уточнение и сформулировать остальное высказывание в терминах той самой системы. Нагло, но в примитивной среде сработает. Обратный случай – сознательное желание изучающими внешних ограничений. Это уж… «Есть люди типа «жив»…» Насколько я вижу, те кто плотно подсели на MS за её пределами видеть ничего не хотят и отстаивают частные решения MS как истину в последней инстанции. Не хочу обобщать, поэтому и говорю, начиная со слов «насколько я вижу». Однако, мне кажется, что это наблюдение можно экстраполировать на большую группу, зная именно об успешном маркетинге MS.

AVK>Ты извини, я не могу такие длинные топики поддерживать, поэтому дальше я буду кратенько.
Угу, согласен. Может, нам пора в «философию программирования» переместиться?
[… бритва Оккама …]
ГВ>>Я назвал COM способом структурирования коммуникаций. Пусть немного некорректно. Корректно, ИМХО, было бы так: Component Object Model часто используется как базисный набор абстракций для структурирования взаимодействия элементов программного комплекса в среде Windows. По-моему, не противоречит предыдущему высказыванию. А не для этого ли он разработан?
AVK>Нет, это следствие. COM разработан для стандартизации компонентной модели построения систем.
Стоп. COM является разработкой MS, единственной и неповторимой. И нужен он прежде всего её самой (был).
«Стандартизация компонетной модели» – это звучит! Ты, конечно, меня извини, но это очень похоже на лозунг MS-овского маркетингового отдела. Какая ещё стандартизация, если на уровне стандарта предписано существование vtbl, который сам по себе – порождение реализации объектной парадигмы?
На всякий случай, пара выдержек из глоссария подсказки MS Platform SDK (выделения жирным шрифтом мои):
Component Object Model (COM)
The OLE object-oriented programming model that defines how objects interact within a single process or between processes. In COM, clients have access to an object through interfaces implemented on the object. See also Interface.
COM object
An object that conforms to the OLE Component Object Model (COM). A COM object is an instance of an object definition, which specifies the object's data (интересно, какие? Property, что-ли?) and one or more implementations of interfaces on the object. Clients interact with a COM object only through its interfaces. See also Component Object Model and Interface.
Interface
A group of semantically related functions that provide access to a COM object. Each OLE interface defines a contract that allows objects to interact according to the Component Object Model (COM). While OLE provides many interface implementations, most interfaces can also be implemented by developers designing OLE applications. See also Component Object Model and COM object.
В этом смысле мне позиция OMG представляется более честной. Они назвали архитектуру архитектурой, а брокер – брокером и не выпендривались, подменяя понятия с маркетинговыми целями. Кстати, название механизма, из которого развился COM тоже было, ИМХО, честнее – OLE (Object Linking & Embedding – Связывание и загрузка объектов).

AVK> А то что его можно использовать для обмена это уже его применение.
AVK> У кома еще много сфер применения.

См. выше.

ГВ>>С помощью CORBA (ключевое слово — Architecture) в общем можно решить те же проблемы, что и с помощью COM, за исключением среды Windows, где наиболее распространённые приложения поддерживают только COM.

AVK>Ага, а локальные интерфейсы как же? В корбе их, того, нет. А вот в коме есть. И в ejb 2 есть.

ИМХО, это можно назвать определённым недостатком корбы, хотя и не думаю, что очень большим, поскольку для локальных инстанцирований разумно использовать возможности, им предоставляемые. В частности – зависимую от языка передачу данных.

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

AVK>О как. Т.е. компоненты суть вещь не очень то нужная? Есть что то более правильное? Извини, но я пока ничего лучше компонентной модели для решения ее спектра задач пока не вижу.
Да. Компоненты – суть вещь не очень-то нужная, когда речь идёт о реализации внутренних структур приложения. (А абстракциями высокого уровня я называю типы данных высокой общности применения, т.е., тех, что используются для внутренней организации приложения.) Помимо того, что они корёжат приложение примитивной моделью передачи данных, так ещё и придётся внутренние элементы приложения реализовывать с учётом модели жизненного цикла объектов COM. Нет, конечно, можно чесать левое ухо правой ногой через затылок, но зачем?

AVK>>>Э нет, так не пойдет. Это ты утверждал что в MS идиоты и на самом то деле все можно сделать намного лучше. Вот и расскажи как это сделать.
ГВ>>Я никогда не называю оппонента идиотом.

AVK>А как еще назвать того кто сделал очень сложно если можно сделать намного проще?
Ну, например, засунул COM в самую «нутерь» приложения. ;)
Есть много других определений. Надо понять – почему он так сделал. И я, кроме того, не имел ввиду «проще», а говорил о «лучше», что для меня синоним определений «надёжно», «стабильно», «ясно» и т.п.. ИМХО, упорядочение совокупности функций (интерфейс с COM-овским vtbl), для которой есть спецификация – может быть реализована на C++ не только наследованием, что может и гибкости добавить. Вполне можно было, например, вместо прямого отображения интерфейса на конструкции C++ (class) отображать его в виде класса метаданных, которыми пользоваться для построения интерфейса на базе template. Кстати, тот факт, что MIDL генерирует только C/C++-отображение – тоже не “супер”.
AVK> Ты ведь утверждаешь что на С++ можно реализовать более стройную модель чем даже то что есть на дотнете. Сказал А, говори Б. А то получается что мол нагородили в коме бог знает чего все можно сделать намного проще, но на самом деле они молодцы. Что то у тебя не стыкуется.
Так, ещё раз. Не приписывай мне того, чего я не говорил. На C++ принципиально можно реализовать всё, что есть в дотнете (если нужно), хотя это и сложно. Оценка модели как «стройная» определяется конкретными условиями её применения, а вот фиксация модели одной на все случаи жизни, ИМХО, — дополнительное ограничение.

[…]
AVK>Не, ты чего то недопонимаешь. Либо мы вводим интерфейсы в язык и получаем очень элегантное решение многих задач,
Например? Давай, ты приведёшь пару решений, где интерфейсы «очень элегантны». А мы рассмотрим ((c) Г. Жеглов) Помоги мне, непутёвому, постичь истину. Я всё время объясняю свои взгляды, не апеллируя к твоему, якобы «недопониманию».
AVK> либо не вводим и эмулируем тем что есть и получаем что то вроде кома. Если ты видишь третий вариант то давай, рассказывай какой.
ИМХО, ты путаешь интерфейсы и RTTI (фактически, одно из применений COM-овского QueryInterface и метаданных COM или .NET)
Относительно интерфейсов и их противопоставления множественному наследованию реализаций я полагаю вот что:
Например, при множественном наследовании реализаций: если у меня есть часто (более одного раза с непрогнозируемым ростом числа использований) употребляемый интерфейс X (в том смысле, что он реализован более чем в одном классе), для которого можно вывести общие методы реализации, то их разумно положить в один класс, который станет одним из базовых для всех классов, реализующих этот интерфейс. При этом у меня не будет необходимости реализовывать интерфейс полностью каждый раз заново. Такой приём называется подмешиванием.
Кстати, при наличии шаблонов я могу наложить дополнительный контроль на использование интерфейса за счёт согласования определённых аргументов шаблонов на «сервере» и «клиенте».
С другой стороны, если множественного наследования реализаций нет, то я вынужден либо уносить реализации всех возможных интерфейсов в базовый класс, автоматически перегружая его функциональностью, либо – реализовывать интерфейс в каждом классе, его реализующем.
Легко убедиться, что в случае с отсутствием множественного наследования либо усложняются абстракции верхнего уровня дерева наследования, либо разбухает реализация нижних уровней. А куда деваться? Вариантов дополнительного структурирования абстракций-то нет! Кстати, мы тут где-то поминали Borland с её паскалем, так вот мне, например, невозможность множественного наследования d Pascal от Borland доставляла бездну неудобств еще со времён Turbo Pascal 5.5 (да, я сам – «паскалист» от программистского рождения ;) ).
QueryInterface из COM — суть частный случай RTTI (- вот тебе объект, — а что это такое?). ИМХО, по-любому, далеко не лучший метод проектирования, поскольку не гарантирует стабильности работы приложения.
[...]
AVK>Опять же не решают смарт поинтеры всех проблем. GC дает замечательную вещь — 100% гарантию освобождения ресурсов памяти. Это позволяет решить многие задачи намного элегантнее. Более того, отсутствие необходимости вобще как то следить за памятью позволяет вводить более высокие и стройные уровни абстракций.

В данном случае, извини, конечно, но я склонен относить это к неумению выделять и определять идиомы управления памятью и контроля ресурсов – т.е., структурировать абстракции. Тем более не пойму, каким образом необходимость управления памятью влияет на стройность абстракций?

AVK>>>И, это, ты так интересно забываешь про рефлекшен все время. Реализуй ка мне его на плюсах ввиде либы. А заодно может чего с динамической генерацией классов и CodeDOM придумаешь.
ГВ>>Динамически генерировать классы на C++ можно. На здоровье: таскаешь компилятор с библиотеками вместе с приложением – и полный вперёд!

AVK>Назад. Как ты собираешся класс подгрузить на лету? Представь что базовый тип уже загружен в основном приложении, а в длл его потомок. Нужно чтобы в vtbl была ссылка именно на уже существующий базовый класс. Если просто грузануть откомпилированную либу ты получишь два экземпляра одних и тех же базовых классов. Проблему конечно можно решить, но решение как раз и приводит к кому.
Да, механизм придётся проработать  , но если уж возникла такая необходимость, то на C++ его реализовать можно. Но, по идее, C++ — язык со статическими типами, так что, такой проблемы просто не должно возникнуть. Это не мешает коммуникации реализовать в терминах COM, CORBA и ещё черт-те чего.

ГВ>>А что до рефлекшена, так он теоретически может быть реализован front-end компилятором. Вопрос – зачем?

AVK>Во как, рефлекшен уже не нужен.
Да нет… Вроде как «пока» не нужен.
AVK> Нет уж, без изменения всего рантайма рефлекшен не реализовать. Для него нужно тащить полную информацию о типах, в типах иметь ссылки на эти метаданные, иметь возможность на лету грузить объекты, иначе действительно рефлекшен не особенно то и нужен. Попытка реализовать рефлекшен существующими средствами приводит .. да, к кому с его QueryInterface, IDispatch и tlb.

Или к брокеру объектных запросов. ;)

ГВ>>Налицо подмена понятий. Комовские навороты нужны были для обеспечения иерархического упорядочивания коммуникативных свойств

AVK>Слушай, что за манера бросаться заумными фразами? Давай говори русским языком. Что такое "иерархическое упорядочивание коммуникативных свойств"? Ты в жизни с людьми так же разговариваешь?
См. выдержки из MS Platform SDK help выше. Объекты – совокупности групп функций (интерфейсов), в общем определяется взаимодействие. Иерархия – суть упорядочивание (функции – в интерфейсах, интерфейсы – в объектах). Где противоречие? (Хотя сама фраза действительно – масло масляное, лучше было бы сказать: «иерархия коммуникативных свойств»)

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

AVK>Вот как раз это и есть одна из основных задач рефлекшена.

Ну, я кажется уже понял, что одна из задач рефлекшена – гипертрофированный RTTI для обеспечение наследования реализаций. Кстати, знаешь, почему я, например, RTTI недолюбливаю в любом виде? А потому, что упование на RTTI вместо статического контроля ведёт к разбуханию программы. Вместо уверенности в типе полученного объекта мне приходится вводить анализ + вариабельность потока управления в зависимости от результата анализа.
Ну, конечно, истина, ИМХО, на самом деле – посередине. Где-то и RTTI нужен.

ГВ>> Однако, неужели ты находишь, что подобный подход может серьёзно упростить решение проблемы устойчивости программы? Как раз-таки, устойчивость проще обеспечить в условиях жёсткой фиксации семантики, а не распознавания её «на ходу». COM – это так… частный случай выражения семантики взаимодействий.

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

Компилятор. Всегда. Знает. С чем. Работает. Иначе его просто невозможно было бы написать. В данном случае он работает с конструкциями, описывающими порождение метаданных и с самими метаданными при недоступности исходного кода. То же самое, что и описание виртуальных функций. Ничего нового. Это конкретные части потока исполнения могут строиться без опоры на реализацию взаимодействующих с ними сегментов, что есть реализация декомпозиции. В данном случае мы обсуждаем варианты объектной декомпозиции.

ГВ>>Итак, что же предлагаешь ты?
[1. Рефлекшен]
[…]
AVK> Т.е. позволяет осуществить полиморфизм не знаю даже базового типа объекта.
Угу. А метаданные это что?
Клиент-то полиморфного объекта имеет вполне чёткие предположения о его функциональности. Или ты вправду думаешь, что из неизвестно чего может появиться то, что нужно?
Звучит как покушение на фундаментальные принципы  Только вот их разрушить невозможно…
AVK> Позволяет создавать автоматически описывающие себя объекты и отказаться от регистрации вроде той которая нужна кому. Ну и много чего еще рефлекшен позволяет. Эмиттинг кода или автоматическая генерация стабов без рефлекшена не возможна.

С комовской регистрацией всё логично – COM-овские подсистемы в общем отделены от runtime, в которых исполняются программы. Единственная связь – механизмы .EXE и .DLL. Отсюда и необходимость регистрации. В случае CLR от него ничего не отделено, если это managed и точно также отрезано, если unmanaged. Соответственно, должна быть и регистрация для unmanaged-кода.
Кстати, никогда проблем с регистрацией объектов не испытывал. Очень просто сделать одну библиотеку с IDL-описанием и использовать её для связи с Native-C++ приложением.

[2. Эмиттинг кода]
ГВ>>Хммм… встроенный ассемблер машины стековых, похоже вычислений. И что здесь такого? Помнится, даже сам писал что-то подобное.  Очень несложно реализуется на C++ с использованием шаблонов и пр., если необходимо.
AVK>Эмиттинг компонетов заметь, а не просто кода.

Так. Компонент эмиттируется вместе с метаданными и объектным кодом. O’K. Значит, по идее, он может перемещаться между станциями сети… на которых установлен .NET… Но это же частное решение задачи перемещения исполняемого кода поближе к обрабатывающему его процессору. Это отнюдь не средство конструирования абстракций.
ГВ>>На C++ решается библиотеками.
AVK>Решается. Пример — ком.

Неверный пример. COM занимается маршаллингом параметров и интерфейсов, а не реализаций.

ГВ>> Не является средством построения абстракций. Ну, в крайнем случае, в той же степени, что и транслятор.
AVK>Еще как является. Попробуй прикинуть насколько проще и стройнее будет выглядеть поисковик если будет генериться код для поиска вместо оптимизации и интерпретации.
Ага. А данные для себя любимого он будет гонять по сетке на клиентскую машину? Ну ладно, так, конечно, можно сделать за счёт эмиттинга, только не забудь, что для того, чтобы такой поисковик корректно сделать нужно провести очень нехилую работу – практически – компилятор написать. А иначе ты получишь тот же простой поисковик но на базе махины по имени .NET.

AVK>>>3) Поддержка ремоутинга на уровне языка (это в дотнете, в джаве все как в плюсах с дкомом, может немножко попроще). Никаких стабов и скелетонов, никаких idl и tlb. Все встроено в рантайм и не требует внимания программиста. Создание удаленного объекта сводится к оператору new.
ГВ>>Не является средством построения абстракций

AVK>Является. Почти полностью стираются границы между удаленными объектами и локальными. Абстракция чистейшей воды.

Нет же  Это – готовая реализация механизма, обеспечивающего вызов удалённых функций. Частные случаи: RPC, COM, LPC (для межпроцессного общения), NDR и т.п.

ГВ>> Как я понимаю, ремоутинг может полностью поддерживаться только в рамках CLR
AVK>Нет. SOAP как бы стандарт все таки. Да и написать свой форматтер не есть проблема.
ГВ>> или же COM для не-CLR-объектов.
AVK>У кома свои средства. Тебе уже сказали, ком в дотнете только для совместимости.
Я имел ввиду вот что. Допустим, какое-то приложение написано под тот же Linux. Что нужно добавить к этому приложению, чтобы к нему можно было обращаться из CLR-приложения, используя ремоутинг? Я предполагаю, что некоторую интерфейсную, сиречь «ответную» часть. Эта ответная часть должна работать либо по протоколу SOAP, либо – COM. Я прав? Только давай, варианты с промежуточным гейтованием вызовов через HTTP не рассматривать.

ГВ>> С точки зрения C++ решение такой задачи — интерфейсы + фабрики классов (необязательно – COM-овских). Деталь окружения, порождённая от COM и отразившаяся на структуре языка. Впрямую не решается на C++ за счёт отсутствия единой runtime-среды для программ на C++ Навязывание единой фабрики классов.
AVK>Вот примером решения как раз и является ком. Результат не впечатляет, хотя в общем то работает.

Согласен, но это никак не противоречит моему доводу. Это даёт возможность без особых усилий абстрагироваться от отдельных аспектов среды исполнения (та машина, эта… какая разница!) и коммуникаций, но не является само по себе новым способом построения абстракций.

AVK>>>4) Домены приложений. Т.е. можно создать изолированную от внешнего мира песочницу с ограниченными правами.
ГВ>>Не является средством построения абстракций

AVK>Да ну? А что же тогда является? Опять же — чистейшей воды абстракция, виртуальное, так сказать, приложение.

Я же говорил, что считаю средствами построения абстракций. Иллюстрирую. Например, возможность сделать следующее: создать сложный тип данных (структура), добавить к нему действия (методы класса), совместить типы (наследование), частично совместить типы (наследование с перекрытием членов или методов). А например, описание типа, создаваемое прозрачно для программиста – это особенность среды исполнения и трансляции, поток – это готовая реализация абстракции потока. И как любая реализованная абстракция – со своими плюсами и минусами.

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

Если бы они могли менять базис языка – то жизнь была бы прекрасна и удивительна. Представляешь – библиотека, предоставляющая новую схему трансляции, и при этом — не противоречащую старой. Супер! :up: Только вот, это даже теоретически очень сложно… Только какие-то очень частные случаи.

ГВ>>Модель управления доступом.

AVK>Не только доступом. Опять же что такое модель как не абстракция?

Хммм… По отношению к приложению – частный случай реализации абстрактного управления доступом. Сам я ещё не разобрался в доткомовской, но вроде – неплохая. И всё равно, что с того? Это же всё равно не средство построения абстракций.

ГВ>> Это Не свойство языка как такового. Разные среды – разные модели.

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

Имеем переплетение – язык-среда программирования. Мда… Ну что-ж…

AVK>>>5) Поддержка потоков встроенная в язык.
ГВ>>Не является средством построения абстракций

AVK>Ага, конечно. Поток это тоже абстракция. А механизмы языка реализуют некую более абстрактную модель потока ОС.

Поток как просто «поток управления» — абстракция. Поток, как конкретный символ Thread или конкретные примитивы блокировки – это уже реализация.

ГВ>> Я усматриваю в этом прямое отображение модели CLR на концепции C# + реализацию многопоточности. Да, примитив lock встроен в язык как ключевое слово. А в C++ lock – это может быть и объект и аргумент шаблона. C++ не содержит прямого языкового аналога lock, но это может быть сделано библиотеками.

AVK>Может быть. Но почему то все реализации менее удобны чем то что есть в джаве и дотнете.

Ну, строго говоря, универсально-удобных вещей не бывает.

AVK>>>6) Черт возьми, почему в плюсах нету try..finally?
ГВ>>Как это соотносится с построением абстракций? Зачем? Разрушение локальных ресурсов решается деструкторами. Это есть прямое потакание плохому стилю программирования.

AVK>Ага, многоэтажные конструкции это конечно лучший стиль чем finally. Тогда надо выкинуть break и continue.
Почти да, поскольку они (многоэтажные конструкции) универсальнее. А в случае try…finally нужно обязательно отслеживать и зеркально отображать исходное распределение ресурсов.

AVK>>>7) Интерфейсы
ГВ>>Является средством построения абстракций. В C++ имеется прямой аналог — абстрактные классы. Имеется прямой аналог в C++

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

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

AVK>>>8) GC
ГВ>>Не средство построения абстракций

AVK>Сборщик мусора позволяет не воспринимать больше память как ресурс (С) IT, т.е. в итоге приводит опять к абстракции.

С точки зрения контроля за симметричностью операций создания/удаления – да, согласен, но с точки зрения занятого объема – нет. Кстати, мне интересно, нужно ли в C# отслеживать и контролировать действия GC? Просто интересно мнение тех, кто уже поработал с C#.
Тем не менее, наличие/отсутствие GC практически никак не влияет на возможности программиста по комбинированию реализаций.

ГВ>>Не средство построения абстракций. Это, конечно, экстремизм  с моей стороны, но на C++ такая задача решается библиотеками, выбирающими каталог, откуда извлекаются компоненты. Реализуется библиотеками C++
AVK>

AVK>Не библиотеками а средствами построения компонентной модели.

Ладно, как частный случай библиотек ;)

AVK>>>10) боксинг и анбоксинг. Т.е. простые типы вроде int и string не ломают объектную парадигму, являясь объектами и при этом не теряя эффективность.
ГВ>>Средство runtime-контроля, не является средством построения абстракций.

AVK>Чистейшей воды абстракция. Позволяет работать с простыми типами одновременно как с объектами и как с простыми типами. Если это не средство абстрагирования от конкретики то что же тогда средство?

ГВ>> Привязали, значит, указатель из CLR-хипа к адресу объекта, который естественно стал managed, поскольку на него есть прямой доступ… Берем шаблонные классы с inline-методами C++ и получаем аналог. Шаблоны C++

AVK>Не, совсем не так. value-типы в хипе не храняться.

В какой части? Managed или unmanaged?

[Stack trace]
ГВ>>Вспомогательная подсистема. На C++ может реализовываться с помощью Debug API и exception-ами. Периодически, конечно, необходимая вещь… Ах да! У нас же тут неизвестно какой объект неизвестно где создаётся… Ну, тогда Реализуемо на C++. в зависимости от среды исполнения.

AVK>Тока пока что то никто не реализовал.

Как так? А dbghelp.dll?

AVK>>>12) Встроенная в язык и рантайм сериализация. Всем плюсовым аналогам до ней очень далеко.
ГВ>>Это всего лишь готовое решение, а не способ их сиснтеза! Даже если здесь добавляется контроль типов. Итак, снова библиотеки… Реализуется библиотеками на C++

AVK>Увы, намного хуже. В нете сериализуется все и вся куда угодно и как угодно без поддержки со стороны объектов. Опять же следствие наличия рефлекшена.

Ну да, следствие наличия единого runtime-окружения, держащего информацию о типах. Но всё равно – это не доп. средство построения абстракций.

AVK>>>13) Атрибуты.
ГВ>>Не является способом построения абстракций

AVK>Ага, внедрение пользовательских метаданных в код это конечно не средство построения абстракций. Какая ж это абстракция метаданные?

Никакая. Это реализация пусть единого для .NET, но тем не менее, частного случая реализации такого подхода.

ГВ>>Атрибуты могут быть привязаны к элементу описания типа (вероятно).

AVK>К сборке, к полю, к методу и т.п.
Угу. Так есть, если рассматривать описание типа в полном контексте – от namespace до конкретного члена конкретного класса.

ГВ>> Позволяют решать задачи идентификации элемента описания во внешнием контексте.

AVK>Позволяет внедрять в код свои собственные метаданные.

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

[…]
ГВ>> Но это – часть общей стреатегии использования типов и информации о них, ёлки палки! На C++ аналогичная задача решается статическими дескрипторами классов или (по идее  ) front-end компиляторами. Решается библиотеками

AVK>Не решаема на С++ без изменения языка принципиально. Для этого компилятор должен уметь создавать экземпляры классов во время компиляции и сериализовывать их в скомпилированный код.
Хммм… Допускаю, что я чего-то не понял. При чём тут генерация классов? Ты имеешь ввиду экземпляры описаний классов? Ну да, правильно… C++ — язык со статической моделью типов, поэтому (возвращаясь к теме топика) и требует организации ладно, не мышления… проектирования. Но runtime-генерация чего угодно (хоть типов, хоть кодов) – это довольно опасная в неопытных руках штука.

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

AVK>Однако при поддержке со стороны языка решается намного элегантнее.

Да, но перенос частных решений на уровень языка как раз и есть, ИМХО, один из признаков конгломеративных (эклектичных) языков. ;) Что-то не то здесь со стройностью.

ГВ>>Теперь попробую подбить итоги: из 14-ти названных особенностей абсолютное большинство (13) – предлагаемые способы Microsoft

AVK>Далее при неверных предпосылках неверные выводы.
Мы с тобой, похоже, на разных языках говорим…

AVK>>>Я вот чего то не въехал — чем это удобнее виртуальных контейнеров? Такие контейнеры могут хранить любые типы, даже те о которых на момент компиляции ничего не известно. И так же можно в зависимости от типа применять специфический алгоритм, хотя это и плохой дизайн на самом деле.

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

ГВ>>Ту-ту-ту! Для этого тебе придётся подменять реализацию контейнера, или вводить интерфейс-импортёр алгоритма,

AVK>Зачем? Ты про рефлекшен и боксинг позабыл уже? И про то что везде кроме С++ существует базовый класс для всех классов?

Именно это и отличает принципиально C++ от «остальных» (как я понимаю, ты имеешь ввиду в первую очередь Java, C#, Smalltalk. Снова обобщаешь…). Именно сильная типизация и решает целую кучу проблем совмещения в системе с развитыми внутренними структурами данных.

AVK>>>Это не деталь, это ключевая особенность. Именно она позволяет не воротить монстроидальных комов.
ГВ>>Ага,  при условии гомогенного runtime.

AVK>А язык без рантайма это чистейшей воды абстракция.

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

ГВ>>В данном случае всё будет работать только при условии наличия .NET Не могу сказать, что это – критический недостаток, но и сгенерировать vtbl – не суперсложная задача, если приспичит. Как я понял, на C# предлагается генерировать ассемблер… Опровергни меня, плиз, если я не прав. Только, чур, аргументированно!
AVK>Можно машинные коды, если скорость критична. А можно исходники на любом дотнетовском языке — все компиляторы умеют в память компилировать.

То есть, как я понимаю, компилятор можно отыскать как компонент где-то в пространстве .NET? То есть, по сути, на любой машине? Поправь, pls., если не так. Если так, то это и на самом деле неплохо само по себе.

AVK>>>Уверен, пробовал. И объектная модель у них не покореженная, она по крайней мере не хуже плюсовой.
ГВ>>Хуже. Пока что я в этом уверен.
AVK>Ну если ты можешь быть уверенным в том что не знаешь то дальше наверное спорить бессмысленно.

Ты пока не доказал, что объектная модель лучше, то есть гибче, чем та, которая предоставляется C++. Пока что, ты перечислял только сервисы, в большинстве случаев использования которых требуется дополнительная ручная работа, тогда как C++ позволяет избавляться от ручной работы и не его вина в том, что это мало кто делает, предпочитая механическую деятельность. Хотя модель со статическими типами тоже не идеал в каких-то смыслах, но, ИМХО, та модель, что предлагается языками типа Java и C# имеет больше ограничений.

AVK>>>Ну и что в этом плохого, если этот сервер обходится дешевле чем работа программиста в течении месяца?
ГВ>>Ничего плохого. Только программистов таких может уже и не остаться при подобном подходе к программированию. Вот тогда-то и запоём.

AVK>Программисты остануться, не переживай, сложность систем тоже растет не менее быстро чем быстродействие железок и эффективность средств разработки.
Сложность сложности – рознь… Кстати, ты так и не привёл ни одной метрики ERP-системы, о которых я просил тебя в одном из предыдущих постингов. Нет, ну если коммерческая тайна, то… А если нет, то хоть экраны и таблицы – оценочное кличество в штуках и ещё хорошо бы знать – сколько делали. Но… сам смотри.

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

Здесь надо смотреть конкретные ситуации, а то мы лозунгами до посинения бросаться можем ;)

ГВ>>…, что C++ — непростой язык.
AVK>А нафига он нужен, такой непростой?

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

ГВ>>Зато, уж если может нормально использовать!… 

AVK>То наконец начинаешь решать задачи, которые человек решал на джаве год назад, причем решает их медленнее и с большим количеством багов. Сомнительное преимущество.

ИМХО, всё связано с малоизвестностью библиотек для C++, аналоги которых вставлены в стандартное окружение Java.

ГВ>>Более качественного решения ты не получишь никогда при таком подходе, поскольку качество, насколько я помню, в своих «высших» проявлениях всё-таки строится на предотвращении проблем, а не на их быстром решении.

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

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

ГВ>>Кстати, это отражено и в CMM. Возможно, это спорно, но я полагаю, что предотвращение проблемы должно строиться на абстрактной модели, охватывающей множество реальных ситуаций. А здесь мы получим тотальную деквалификацию с очень большой вероятностью, какое уж нафиг предотвращение! Нам будут подкидывать технологию за технологией, для которых всё время не будет хватать спецов!
AVK>Я тебе еще раз повторю — ты зря считаешь что квалификация это виртуозное знание языка и его потрохов, ОС и т.п. Знаешь почему хорошие программеры по прошествию определенного времени становяться архитекторами? И вот на этой стадии очень важное значение приобретает легкость реализации тех абстракций, которые рисуются при построении системы. Надо работать не снизу вверх, от возможностей языка к архитектуре системы, а наоборот, оти архитектуры к возможностям языка. Только так действительно сложные системы можно сделать управляемыми и эволюционирующими.

Здесь ни с чем поспорить не могу. Но и архитекторам тоже C++ даёт больше свободы в реализации абстракций, чем Java/C#. Generic-типы есть в UML, но их нет в Java. То, что ими не пользуются говорит, ИМХО, только об относительно слабом развитии архитекторов (как раз – о деквалификации). Никого конкретно обидеть не хочу.

AVK>>>А 16-типроцессорные сервера, идеологические убеждения программеров,
ГВ>>Манагёр ты мой драгоценный. Когда же ты перестанешь унижать оппонентов? Кроме того, это твои убеждения смахивают на идеологические.
AVK>Я пока что никого не унижал. Если ты воспринял на свой счет, извини, я тебя не имел ввиду.
O’K, проехали ;) Ты меня тоже за уменьшительно-ласкательое обращение извини.

ГВ>>А зачем в качестве примера приводить историю CPU?

AVK>Родственная область.

ГВ>> С таким же успехом можно привести историю какого-нибудь автомобиля.

AVK>Ты даже не представляешь сколько общего между разработкой софта и сложных цифровых железок.

Представляю, отчего же нет?

ГВ>>Это уже опасное передёргивание. CPU – утилитарная вещь, для рыночного успеха которой важно соотношение цена/производительность.
AVK>Так ведь и для софта самая важная характеристика это самое отношение. Тока к цене прибавляется еще и время, а под производительностью понимается объем решаемых в реальном мире задач.

ГВ>>Человек – не процессор и может самостоятельно повышать свою производительность на порядки при наличии адекватных инструментов.
AVK>Аналогия была не человек-процессор, а программная система-процессор.

Согласен, но мы ведь говорим о человеке и его развитии… Просто зацепились на разных оценках явлений.

ГВ>>А инструмент как раз таки и ухудшается! Посмотри, ты не привёл пока ни одного свойства C# как языка, для которого не было бы или невозможно было бы сделать аналог в C++!
AVK>Ты как здорово опустиk. Приведи мне что можно сделать на С++ чего нельзя сделать на ассемблере.
Не путай. Ассемблер предоставляет совсем другие способы конструирования абстракций. Потому C++ с его сильной типизацией и распространился. C#/Java – это совершенно другая модель.

AVK>В общем резюме — я предполагаю что главная причина неприятия всех новых технологий это нежелание менять устоявшуюся ситуацию. Это вполне понятно, убил человек уйму времени на изучение какой то технологии, а тут ему говорят что надо по новой переучиваться.
Да нет, времени не жалко. Просто, кабы предлагали что-то такое, что было бы выше уровнем. Знаешь, у меня немного знакомых хороших программистов С++, которые радуются от перехода на VB или на SQL.
AVK>Но вернемся к предмету спора — лучше дотнет С++ или хуже это третий вопрос. Главное — MS обязательно сделает дотнет основным средством разработки под Win32. % Win32 ты знаешь. Так зачем новичку С++, если все равно скорее всего ему придется писать на дотнете?
Кроме Win32 ещё платформы найдутся. А нужен C++ затем, чтобы он знал, что ещё можно делать и быстрее понимал якобы трудные концепции. Короче — чтобы программировать умел! Чтобы, короче, был программистом типа "жив" :super:, а не типа "жду рецепта". :???:

Вот так-то ;)

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

A>>>программа на Java с 3 окнами уже занимает 50M, ты просто не сможешь написать прогу на Java занимающей 10M в памяти.
AVK>>Ну это ты загнул. 50М это уже EJB-серверы. Типичный десктоп 10-20 метров и будет.

A>Щаз. Я тебе подскажу как это посмотреть. Task manager показывает не всю память а только реально занятую, т.е. то что выкинуто в swap не считается, включи колону VM Size и поплюсуй ее с обыкновенной получится как раз 50 Mb для программы с 3 окнами, смотрел 3 дня назад.

VM Size показывает распределённую приложению память, включая своп и мап-файлы. Откуда следует, что 50 мег может легко набежать не за счёт свопа, а за счёт того, что Windows мапит файлы, которые могут понадибиться для работы сборок. Что такое маппинг и как он использует память я, недеюсь, тебе объяснять не надо.

A>>>Стабильная утечка памяти 10K в минуту элементарно отлавливается(Bounds checker еще никто не отменял)
AVK>>Увы, это не так.

A>Хм. Видимо зависит от программиста, у нас не так.

<moderator>
Вот как-то мне не понравился тон этого сообщения... как-то сквозь него пальцы проглядывают...
</moderator>

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

IT>>Почитай "шустриков" на нашем сайте. Там хорошо видно, что по быстродействию C# ничем не уступает C++, местами даже его обгоняет. И зависит всё не столько от самого языка, сколько от оптимизатора конкретного компилятора.

A>Да и Java ничем не отличается по тестам. Но реальные программы на ней это не спасает.

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

Я проделал не мало тестов, чтобы поверить в быстродействие CLR, т.к. для меня это было одним из основных критериев перехода на .NET. Могу тебя уверить, всё там нормально, изучение asm-кода в отладчике это подтверждает. Тормоза могут быть при загрузке программы из-за первоночальной JIT-компиляции (с этим тоже можно легко бороться компиляцией при установке программы), потом всё пучёчком. Разница в генерируемом коде между C# и C++ может быть только из-за работы оптимизаторов.

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

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

ГВ>Тут не согласен. Более развитая среда программирования – ещё соглашусь, но сами языки… "Увитием" C++ назвать ещё можно, а развитием... Ну, набиты они библиотеками и развитым рантаймом под самое не балуйся. И что с того?

С того то, что окружение обогащает язык. Вспомним Delphi, вспомним Clarion, да тот же Clipper. Чем обоснована популярность этих не сред, а языков? Да ничем, только средой и обоснована. Насчёт Дельфи я конечно грубо нарываюсь на неприятности, но, по правде сказать, есть у меня такое подозрение, что начиная ещё с 5-й версии Torbo Pascal развитие самого языка тупо следовало прихотям среды и моды. В отношении Clarion и Clipper я вообще молчу. Тем не менее, на этих языках программировали десятки тысяч, сотни, а может быть и миллионы программистов. Точнее, они программировали не на языках, а на средах. :)

IT>>При реализации интерфейсов мы не думаем о данных, которые мы наследуем от производного класса.

ГВ>Не производного – базового.

Глючу, но ты на чеку :))

IT>>А значит у нас нет проблем с неоднозначностью доступа к ним и с тем как кастить объект к базоваму классу и обратно. Нет проблем с diamond структурами и нет необходимости загромождать язык виртуальным наследованием, чтобы всё это обойти.

ГВ>Извини, ну ты и смешал всё в кучу. Давай разделять: наследование реализации, наследование интерфейсов и преобразование типов.
ГВ>Итак, по порядку. Откуда при реализации интерфейса возникает проблема данных базового класса?

Да с интерфейсами, как мы уже разобрались, всё в порядке. Проблема с данными, только с ними. Виртуальное наследование без данных это уже практически интерфейсы. Присутствует только реализация. Но кому она нужна без данных ;)

ГВ>Это всё верно, но виртуальное наследование просто гарантирует единственность экземпляра реализации класса-родителя в экземпляре наследника независимо от промежуточного наследования.

Точно.

IT>>И при чём тут указатели?

ГВ>Мммм… Если ты припомнишь ветку, то я и не говорил об адресной арифметике. По-моему, ты сам (или AndrewVK) сказал, что «большинство пальцев C++-ников» основано на умении работать с указателями. А я попытался не очень удачно вернуть дискуссию в прежнее русло. Так что, вопрос не по адресу и не к месту.

Да уж :) Это был я.

ГВ>>>>>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun,

ГВ>Да, согласен, что неправомерно сравнивать COM и CLR, но модель C# как языка очень много унаследовала от компонентной модели COM.

C# как язык очень много унаследовал от C++, в том числе, как это ни странно, и работу с указателями (в отличии от Java). Никаких сравнений C# и COM мне что-то не приходит в голову.

IT>>В чём именно ограниченность COM-вской модели?

ГВ>Ограниченность COM-модели состоит в том, что она не позволяет гибко управлять абстракциями – по крайней мере, так же гибко, как и C++. Такая же беда есть и у Java.

Что такое в данном контексте "гибко управлять абстракциями"?

ГВ>Я, собственно, тоже не предлагаю новичкам начинать с GP. Я предлагаю начинать с C++, как более сложного инструмента, в котором реализованы такие методы управления абстракциями, понимание которых существенно упростит для новичка постижение широкораспространённых инструментов. Ну и… всячески развиваю мысль о том, что на сложных инструментах учиться лучше, чем на простых. Тем более, если базовая подготовка уже есть.

Мой путь был такой:

— Фортран (диплом в институте), основы программирования вообще,
— Паскаль (первые шаги в НИИ), процедурное программирование,
— PDP-ASM (вторые шаги в НИИ), низкоуровневое программирование,
— C (первые реальные проекты), всё предыдущее вместе.

Последний язык стал моим основным рабочим до знакомства с C++. Если бы я начал сразу с C, то не думаю, что мне бы это сильно помогло. Я как раз считаю, что мне сильно повезло именно с данной последовательностью. После Паскаля (который, кстати, умел только генерировать код на asm'е, а потом вызывал сам asm) и изучения ассемблера, C мне показался именно тем, что мне как раз и было нужно.

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

IT>>Это тоже заблуждение. Язык не может быть отделён от своего окружения. Даже C++. Если ты пишешь на C++ под Windows и не имеешь опыта в Unix, то никто тебя не возьмёт писать систему для последнего. Язык можно и нужно рассматривать в контексте его окружения.

ГВ>Это – вполне конкретные частные глюки тех, кто считает, что программист "под XXX" — это набор знаний конкретного API (и только он). В сущности — базовые абстракции, реализованные в различных ОС — похожи.

Я как-то делал проект, где одна и таже программа должна была работать под Win32, DOS и Novell Netware. Простая функция определения свободного места на диске потребовала реализации трёх различных функций под три ОС и разборки с тремя API.

За различия между Win32 и DOS я вообще молчу. Разный размер интов, разная длина указателей... слава Богу всё это в прошлом... но ведь скоро грядёт 64-х разрядный инт... Посмотрим, что будет с твоими абстракциями.

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

ГВ>Хорошо. В C#/CLR я новичок, Java знаю чуть лучше. C++ использую уже около восьми лет. Плюс теория, базовое образование и т.п.

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

ГВ>Кстати, работа с эмиттингом кода, если не ошибаюсь, включает знание виртуального ассемблера CLR – MSIL. Может быть, я ошибаюсь. Поправь, если не так.

Что такое эмиттинг кода?

IT>>Что касается тезиса о том, что чем сложнее язык, тем лучше будущему программисту, то я уже как-то не уверен в этом. Здесь можно провести аналогию с автоматической и ручной коробкой передач. Ты можешь виртуозно управлять ручной коробкой, но, например, в штатах тебе это скорее всего не понадобится. Да и шансов у ручной коробки мало на длинных дистанциях, устаешь сильно, в пробках особенно. А для сверх длинных у автоматов существует ещё и круиз-контроль. Выставил скорость и сиди кури и наблюдай окрестности, ну там про руль не забывай :)

ГВ>Знаешь, в ответ н эту аналогию: C++ — это полуавтомат, который ты сам можешь довести до необходимого тебе автомата, Java – полуавтомат, который гораждо сложнее развивать.

[skip]

ГВ>Библиотека – суть набор конкретных решений, тогда как структура языка – набор методов их реализаций.

C++ — в чистом виде ручная коробка, автомат — это VB :) C# тоже без всяких полу больше автомат. Но таковым его делает в том числе и его окружение. Что есть в C++? Устаревшая необъектная RTL от C да STL, о котором до сих пор нет однозначного мнения что это такое — добро или зло.

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

IT>>Это тоже заблуждение. Язык не может быть отделён от своего окружения. Даже C++. Если ты пишешь на C++ под Windows и не имеешь опыта в Unix, то никто тебя не возьмёт писать систему для последнего. Язык можно и нужно рассматривать в контексте его окружения.

A>Не согласен. Мне кажется в этом утверждении ты основываешься только на опыте работы с msvc. Люди которые никогда не писали в unix достаточно неплохо пишут кросплатформенные модули, там как раз все просто, не делай #include <windows.h> и все будет нормально. C++ это как раз один из немногих языков хорошо отделеный от окружения. (что msvc плохо от окружения отделен это я согласен)

Это смотря что ты пишешь. У меня был знакомый, который страшно материл Windows за наличие GUI, он всю жизнь писал программы, которые принимали на вход данные, колбасили их и выдавали на выход. Этакий

int i;
cin >> i;
i *= 2;
out << i;

В этом случае действительно возможностей C++ более чем достаточно. Но если мы уходим в GUI, то без ОС здесь никак. Возможно существуют хорошие кросплатформенные библиотеки, но я очень сильно сомневаюсь, что на них можно написать что серьёзное.

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

Был такой Watcom C++. Классный компайлер был, ничего не могу сказать. На шаблонах правда страшно тормозил. Но и на нём приходилось дефайны ставить чтобы использовать одни и теже функции из разных ОС.

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

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

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

ГВ>>Тут не согласен. Более развитая среда программирования – ещё соглашусь, но сами языки… "Увитием" C++ назвать ещё можно, а развитием... Ну, набиты они библиотеками и развитым рантаймом под самое не балуйся. И что с того?

IT>С того то, что окружение обогащает язык.

Неверно. Окружение предоставляет комплект стандартных реализаций определённых возможностей. Ну-ка, обогати мне C++ новым способом наследования за счёт окружения! :)

IT> Вспомним Delphi, вспомним Clarion, да тот же Clipper. Чем обоснована популярность этих не сред, а языков?

Delphi — порождение RAD-психоза + славный наследник интегрированной среды Turbo/Borland Pascal, позволявшая до поры до времени абстрагироваться от особенностей Windows. Clarion — точно не знаю. Clipper — одно из немногоих средств создания программ, работающих с базами данных (были ещё и dBase I — IV, была ещё и FoxPro).

IT> Да ничем, только средой и обоснована. Насчёт Дельфи я конечно грубо нарываюсь на неприятности, но, по правде сказать, есть у меня такое подозрение, что начиная ещё с 5-й версии Torbo Pascal развитие самого языка тупо следовало прихотям среды и моды.

С последним согласен. Кстати, мода удивительным образом заставляет подтягивать Pascal к C++. А комплект того, что есть в C# на уровне языка — не то же самое порождение моды? В том-то и проблема, что не все приложения похожи на то, чего требует мода. И не везде уместны модные реализации.

IT> В отношении Clarion и Clipper я вообще молчу. Тем не менее, на этих языках программировали десятки тысяч, сотни, а может быть и миллионы программистов. Точнее, они программировали не на языках, а на средах. :)

Понимаешь ли... вот бы ещё квалификацию сравнить. Тех, кого были "миллионы" с теми, кто забросил Delphi, Clipper и проч. при первой же возможности. Кроме того, не забывай, что, по крайней мере Clipper и Clarion предтавляли качественно иные возможности работы с БД по сравнению с другими средствами.

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

C++ по идее обогащается библиотеками, сам язык — очень богат. С другой стороны, фирмы типа MS не озаботились развитием средств программирования под C++. Оно и понятно, рынок бы сузился (возможно). Не видно и других средств, решающих рутинные однообразные вещи. Зато полным ходом развиваются средства, апеллирующие к слабому абстрактному мышлению и предоставляющие "рецепты от <фирму вписать>". Понятно, что у миллионов оно слабее, чем у некоторых, составляющих, к примеру, десятки тысяч из них. И что? Эти десятки тысяч стоит причесать "под миллионы"? А может, лучше миллионы подтянуть? Впрочем, это уже философия, хотя и близкая к теме топика.

IT>>>А значит у нас нет проблем с неоднозначностью доступа к ним и с тем как кастить объект к базоваму классу и обратно. Нет проблем с diamond структурами и нет необходимости загромождать язык виртуальным наследованием, чтобы всё это обойти.

ГВ>>Извини, ну ты и смешал всё в кучу. Давай разделять: наследование реализации, наследование интерфейсов и преобразование типов.
ГВ>>Итак, по порядку. Откуда при реализации интерфейса возникает проблема данных базового класса?

IT>Да с интерфейсами, как мы уже разобрались, всё в порядке. Проблема с данными, только с ними. Виртуальное наследование без данных это уже практически интерфейсы. Присутствует только реализация. Но кому она нужна без данных ;)

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

Понимаешь, проблемы, связанные с дублированием реализаций и необходимостью ручного контроля никуда не делись, оттого, что для C#/Java кастрировали модель C++. Если бы это всё было так просто. Иллюзия! И, ИМХО, опасная.

Ещё про кастинг во все стороны. В иерархической системе с сильной статической типизацией возникновение задачи "обратного" кастинга (от базового класса к производному), о существовании которой неизвестно на момент проектирования базового класса — суть ошибка проектирования. Но это не главный аргумент. Главное то, на чём основано сие логическое построение. А соновано оно на том, что клиентов (N) класса всегда N > 1 (иначе этот класс попросту не нужен). => необходимо во всех N вместо гарантии работоспособности того или иного преобразования ввести runtime-контроль. Во всех точках использования такого кастинга :crash: . Что автоматически тянет за собой усложнение сопровождения. Это же классика! Diamond-структуры, реализованные на C++ — тоже палка о тех же концах.

[skip]

ГВ>>>>>>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun,

ГВ>>Да, согласен, что неправомерно сравнивать COM и CLR, но модель C# как языка очень много унаследовала от компонентной модели COM.

IT>C# как язык очень много унаследовал от C++, в том числе, как это ни странно, и работу с указателями (в отличии от Java). Никаких сравнений C# и COM мне что-то не приходит в голову.

Интерфейсы, компоненты, remoting, events, описания типов... Но, может быть, я не прав...

IT>>>В чём именно ограниченность COM-вской модели?

ГВ>>Ограниченность COM-модели состоит в том, что она не позволяет гибко управлять абстракциями – по крайней мере, так же гибко, как и C++. Такая же беда есть и у Java.

IT>Что такое в данном контексте "гибко управлять абстракциями"?

Комбинировать абстракции в compile-time. Как раз то, что позволяют шаблоны и множественное наследование. В случае COM всегда приходится уповать на runtime. В случае компонентной архитектуры — аналогично.

[skip о путях]

IT>Но я не буду рекомендовать эту последовательность молодым, просто потому, что она сильно устарела. Но, считаю, что лучше начать с языка попроще. Самым лучшим и к тому же самым практичным кандидатом на сегодняшний день (естественно, это моё ИМХО), является шарп.

Ну, я тоже начинал (к сожалению, ИМХО) не с C++ и с Turbo Pascal начинать не посоветую.
А про C#... ИМХО, начать им (да и другим подобным языком!) пользоваться проще, после изучения C++. А вот с обратной дорогой...

IT>>>Это тоже заблуждение. Язык не может быть отделён от своего окружения. Даже C++. Если ты пишешь на C++ под Windows и не имеешь опыта в Unix, то никто тебя не возьмёт писать систему для последнего. Язык можно и нужно рассматривать в контексте его окружения.

ГВ>>Это – вполне конкретные частные глюки тех, кто считает, что программист "под XXX" — это набор знаний конкретного API (и только он). В сущности — базовые абстракции, реализованные в различных ОС — похожи.

IT>Я как-то делал проект, где одна и таже программа должна была работать под Win32, DOS и Novell Netware. Простая функция определения свободного места на диске потребовала реализации трёх различных функций под три ОС и разборки с тремя API.

И это пока никак не опровергает сказанного мной. :super: Ты разобрался с API, но программу-то, надеюсь не менял полностью ради этого?

IT>За различия между Win32 и DOS я вообще молчу. Разный размер интов, разная длина указателей... слава Богу всё это в прошлом...

Да к тому же и шаблоны компилятором толком ещё не поддерживаются...

IT> но ведь скоро грядёт 64-х разрядный инт... Посмотрим, что будет с твоими абстракциями.

Да ничего... Они защищены от особенностей реализации элементарных типов (int, в частности). Кстати, __int64 уже сейчас поддерживают. Элементарный тип как тип...

[...]

IT>Вот. Советую как можно ближе познакомится с .NET. Думаю, эта платформа — наше будущее. С одной стороны — против лома (тут я однозначно намекаю на MS) нет приёма, с другой — эта платформа являет собой воплощение лучших идей, придуманных в нашей отрасли на сегодняшний день. А как известно "заимствовать" идеи MS тоже умеет.

В том, что эта платформа — будущее MS, я не сомневаюсь. В том что наше в целом — пока сомневаюсь. ИМХО, противостояние "Unix/Win32/ещё много чего" так и продолжится. Прежде всего взовьются те, кто сейчас делает Unix/Windows переносимый софт, например, на той же Java. Кстати, здесь мне нравится, что MS оставила C++ для своей платформы — пусть не полностью managed (оно и понятно, ИМХО модель C++ противоречит модели объектов CLR... Собственно, как статическая типизация противоречит runtime-типизации). Осталось только дотянуть его до стандарта.

ИМХО, будет такое же противостояние, как сейчас оно существует между MSSQL/DB2/Oracle. Только в качестве противостоящих будут CLR/JVM/?/?, поскольку свято место пусто... Об этом сейчас не хочется думать, когда, кажется, что все проблемы вот-вот решатся, но, полагаю, что именно так и будет.

ГВ>>Кстати, работа с эмиттингом кода, если не ошибаюсь, включает знание виртуального ассемблера CLR – MSIL. Может быть, я ошибаюсь. Поправь, если не так.

IT>Что такое эмиттинг кода?

Если я не ошибаюсь :shuffle: — посмотри namespace Reflection.Emit.

IT>>>Что касается тезиса о том, что чем сложнее язык, тем лучше будущему программисту, то я уже как-то не уверен в этом. Здесь можно провести аналогию с автоматической и ручной коробкой передач. Ты можешь виртуозно управлять ручной коробкой, но, например, в штатах тебе это скорее всего не понадобится. Да и шансов у ручной коробки мало на длинных дистанциях, устаешь сильно, в пробках особенно. А для сверх длинных у автоматов существует ещё и круиз-контроль. Выставил скорость и сиди кури и наблюдай окрестности, ну там про руль не забывай :)

IT>[skip]

ГВ>>Библиотека – суть набор конкретных решений, тогда как структура языка – набор методов их реализаций.

IT>C++ — в чистом виде ручная коробка, автомат — это VB :) C# тоже без всяких полу больше автомат. Но таковым его делает в том числе и его окружение. Что есть в C++? Устаревшая необъектная RTL от C да STL, о котором до сих пор нет однозначного мнения что это такое — добро или зло.

:no: Извини, но это совсем неправомерное обобщение да ещё и переворачивание с ног на голову. C++ — это C++, а библиотеки — это библиотеки и, ИМХО, программисты обязаны выделять и разделять эти понятия.

На C++ ещё есть ACE+TAO, boost и т.п. Кстати, ACE поддерживает кучу Unix-ов и компиляторов, помимо Windows+MSVC.

А в оценках добро/зло вообще ни у кого нет однозначного :maniac: мнения. Сущность у них такая :super: И, ИМХО, упование на неё — большая ошибка любого специалиста.

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

Цитировать не буду. И так слишком длинно.

Итак, с чем я согласен. Ну, почти со всем. Вот только COM пока не мертв. В новй Windows.Net так и не появилось серьезного сервера приложений для .NET, а вот как раз COM+ улучшился. Похоже у MS просто не хватает сил и мужества сделать все так как гворил Бокс. Бокс романтик, а продукт-менеджеры в MS реалисты. Правда сервером может выступать и IIS, но это позволяет решать только проблпмы автоматизации web-а. Это конечно не плохо, но для полной победы явно мало.

Я бы на сегодня сказал так. COM и С++ остаются, но потихоничку переходят в разряд низкоуровневых средств.

.NET можно смело считать новой версией COM-а. (У меня есть фактическое этому подтверждение) По крайней мере он развивает все то хорошее что было в COM-е:
Динамическую загрузку и исполнение кода.
Описание типов (теперь она стало полным).
Абстрагирование интерфейса от реализации.
Динамическое приведение типов.


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

Согласен, что на практике можно вообще обходится без указателей, но черт возьми! Прогарммист не их понимающий и не умеющий с ними работь — это даже не ламер. Это просто маральный урод. Уж извените за грубось. Это как тест на выживание. Освоил указатели — программист. Нет — лучше заняться маркетингом и менеджментом.

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

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

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

ГВ>>Также не согласен с доводом, что C++ — это язык для низкоуровневых систем. C++ — язык для сложных и больших программ, а не только низкоровневых.
AVK>Вот как раз для сложных и болшьших программ С++ подходит хуже нежели шарп и джава.

Ну, это ты зря! На С++ любая программа становится большой и сложной.

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

ГВ>Сразу вопрос. Что такое нормальные property и event?

Ой дайте я.

property:

MyObj.SomeProp = 12345;

Вот такой. Если у кого есть ольтернатива, то выкладывайте ее. Возникает вопрос, а зачем они нужны? Дык есть таки программки называются визульными дизайнерами. Там на базе концепции свойств задают начальное состояние компонента. Зачем нжны комоненты поянять нужно?

ГВ> Какая реализация, например, событий, была бы "логичной"?

Любая которая дала бы возможность быстро и удобно организовывать колбэк-вызовы. Помнишь в С была такая простая и эффективная идеея — указатели на фуниции? Вглядело это так:

MyFunc1(int iArg){...}
MyFunc2(int iArg){...}
MyFunc3(int iArg){...}
...
(pFunc*)(int iArg);
pFunc = MyFunc1;
pFunc(1);
pFunc = MyFunc2;
pFunc(2);
pFunc = MyFunc3;
pFunc(3);

С синтаксисом без компилятора могу наврать, но общая идея такая. И что зделали с этой идеей в С++? Её убили на корню. Зделали указатели на фуниции-члены классов. Кому они нужны? Ведь вызвть фуницию с совподающим описанием неудастся.

Проблема решается двумя способами введением в язык указателя на метод экземпляра и интерфейсами. Первая идея реализована в Дельфи и билдере. Идея проста и элегантна — указатель не зависит от конкретного класса и содержит указатель на экземпляр. По сути хранятся два указателя. Первый указвает на объект. Второй на функию.

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

Интересно, что в тихую замял вопрос про рефлекшен. Возможно просто незнаешь термина. В COM это назывлось TypeInfo. Так вот, С++ напрочь лишен подобного михонизма. И чтобы создать теже события для компонентов реализованных на С++ к программе нужно прилепить еще гору года в виде разных tlb. Так рождается COM. А потом рождаются разные ATL и #import, единственная цель которых скрыть все сложности реализации компонентов и упростить работу. В итоге мы порождаем проблему и ее же решаем.

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

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

ГВ> Каким, например, должен быть механизм передачи событий? Должен ли он предусматривать межпроцессную передачу данных? Должна ли принимающая сторона уметь идентифицировать отправителя события? Должна ли создаваться очередь событий? Варианты ответов на эти вопросы прекрасно можно оформить библиотеками классов на C++! Зачем навязывать самим себе "единственно правильную" модель реализации?

Вот сразу видно, что сам ты подсудимого не знал и книг его не читал. Знаешь что такое делигат? В .NET он как раз решает все те вопросы о котоых ты говоришь так иронично. Причем решает локонично, красиво и универсально. Пишиш так:

public delegate void FileCallback(string sFileName);
...
internal void IterateNode(FileCallback Callback, string sPath)
{
    ...
    foreach(string File in m_Files) // перебираем их..
        Callback(sPath + File); // и вызываем для каждого callback-метод.
}

... // в другом классе, а то и вообще в другом модуле (а то и в проекте)

m_SearchEngine.IterateNodes(new FileCallback(ProcessFile));

public void ProcessFile(string sFileName){...}

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

ГВ>Для C# и Java эти вопросы решались исходя из целей этих языков. C# — поддержание амбиций Microsoft (т.е., внедрение поддержки модели COM), а Java... кстати, в Java event-ов и property на уровне языка нет! Есть библиотеки!

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

COM стэкуется с .NET через довольно сложную систему именуемую Interop. Собственно через нее нэт стыкуется и с обычным Win32. Причем базовая часть нэта, так называемая CLI (в народе Ротор) порирована под Фришку. Так что амбиции то амбициями, а факты фактоми.

ГВ>Ну, во-первых. Сравнивать COM (в сущности — способ структурирования коммуникаций) с моделью объектов в языках реализации не совсем корректно.

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

ГВ>Реализация COM для C++ в Miscrosoft-овском варианте

А что были другие?

ГВ> обладает теми же чертами, что и плоский API на C с небольшими вкраплениями объектного подхода. То есть — можно было бы и лучше.

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

ГВ> Потом, не надо забывать о том, что, действительно, по сравнению с C++ (что, впрочем, ИМХО, справедливо для любого языка общего назначения) языки специального назначения обладают преимуществами в специальных областях. Ну, например, VBS или Perl лучше подходят для скриптования идиотской модели объектов ClearQuest, нежели C++, хотя и там время от времени приходится использовать его.

Скриптования это круто. Я вот только не пойму, C# тоже специализированный язык для этого самого скриптования или ты о чет-то другом?

ГВ>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun, а C# + CLR — как противовес Java в той же области, то, естественно, они в этом смысле обладают преимуществами перед C++. Тогда как C++ создан для упрощения решения проблем программирования. Что называется — почувствуйте разницу

Ты сам то понял что сказал? Язык "создан для упрощения решения проблем программирования". Может он того... для самого этого программирования и создан? И какая разница тогда между Явой и С++?

ГВ>И здесь я действительно согласен с тем, что на C# проще реализовать что-то на базе модели COM. Но, ёлки-палки, COM — это не способ построения абстракций уровня реализации, он слишком ограничен для этого!
ГВ>

Надо мужикам расказать, а то они и незнали. (с)

1. C# не прднозначен для создания COM-объектов хотя на нем их действительно делать не сложно.
2. COM единственная доведенная до серийного исползования бинарная компонентная модель.
3. COM замечательно подходит для "построения абстракций уровня реализации".

ГВ>Итак, цели: выделение абстракций и их комбинирование.
ГВ>Чего нет в Java: а) множественное наследование;

Это действительно прискорбно.

ГВ> б) шаблоны;

Это тоже. Но в следующей версии Явы они уже будут.

ГВ> в) инлайнирование (как инструмент совмещения структурированных абстракций и эффективности исполнения).

Да словечко еще то. Так вот лучшие на сегодня компиляторы от MS и Intel уже сегдня плюют на эти директивы. Более того они умеют делать автоподстановку, причем значительно эффективнее чем прогаммист. Это и не мудренно, так как только комилятор может понять эффективна она или нет. В Яве и .Net это метод тоже используется.

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

А ты не стесняйся. Вот попробуй на С++ сделать указатель на член экземпляра объекта. Ну или реализуй алгоритм сборки мусора, да так чтобы тебя не полсли куда подальще когда увидят насколько это сложна и неээфективно. Покажи еще как на С++ динамически загрузить объект и вызват его методы. Причем на КОМ не фига пинять. Там от С++ ничерта не остаются. Ты попробцй срдствами языка. Попробуй вызвать виртуальный метод из коструктора или деструктора. Попробуй найти кострукцию finally.

ГВ>Абсолютно не согласен. Вопрос в том — что именно называть большой и сложной программой.

Да любой проект можно сделать большим сложным и глючным.

ГВ>...SQL+VB, где основная сложность — поддержание адекватности структуры отчётов структуре БД, что суть прямое нарушение принципа абстракции пользовательского интерфейса (отчётов) от деталей реализации (структуры БД). Так основное время команды уходило на вот это самое бестолкове сопровождение.

А ты случаем не видел аналога на C++ + SQL? О... забавное зрелище. Тут есть люди которые с такими системами борются. Я согласен, что большие и сложные вещи можно писать на чем угодно, но С++ больше подходит для низкоуровневых разработок, чем для RAD-разработки. Именно поэтому CGI так быстро уступили разным ASP, PHP и JSP.

ГВ>Прикол как раз в том, что когда работаешь со скриптовыми языками, часто даже не задаёшь себе тех вопросов, которые не боишься ставить, используя C++. А C# и Java я как раз и считаю разновидностью скриптовых языков, посольку ИМХО они апеллируют к реализации каких-то элементов системы на других языках.

Ну, ты ради хохмы открой хоть один из них. Может и вопросы придут. Явно же видно что ты их максимум посмотрел и отбросил. Иначе бы не стал их со скриптами сравнивать.

ГВ>К примеру, именно отсутствие в Java (и в C#) шаблонов и приведёт либо к разбуханию большой и сложной программы, либо к снижению эффективности её работы, за счёт необходимости run-time-приведения типов (виртуальные функции). Не считая уже того, что в Java невозможно будет перенести на транслятор такую же часть контроля корректности программирования, как и в C++.

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

ГВ> Т.е., Java-программы будет сложнее сопровождать, если конечно, не требовать от пользователя поставить 4-х процессорный сервер P4-2200 под 10-пользовательскую CRM.

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

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

VD>Ой дайте я.

Так-так... \

VD>property:

VD>MyObj.SomeProp = 12345;

VD>Вот такой. Если у кого есть ольтернатива, то выкладывайте ее. Возникает вопрос, а зачем они нужны? Дык есть таки программки называются визульными дизайнерами. Там на базе концепции свойств задают начальное состояние компонента. Зачем нжны комоненты поянять нужно?

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

ГВ>> Какая реализация, например, событий, была бы "логичной"?

VD>Любая которая дала бы возможность быстро и удобно организовывать колбэк-вызовы. Помнишь в С была такая простая и эффективная идеея — указатели на фуниции? Вглядело это так:
VD>

VD>MyFunc1(int iArg){...}
VD>MyFunc2(int iArg){...}
VD>MyFunc3(int iArg){...}
VD>...
VD>(pFunc*)(int iArg);
VD>pFunc = MyFunc1;
VD>pFunc(1);
VD>pFunc = MyFunc2;
VD>pFunc(2);
VD>pFunc = MyFunc3;
VD>pFunc(3);
VD>

VD>С синтаксисом без компилятора могу наврать, но общая идея такая. И что зделали с этой идеей в С++? Её убили на корню.

Да, дружище. Забыл ты C++. Указатели на функции и на статические члены типов там живут и благоденствуют.

VC>Зделали указатели на фуниции-члены классов. Кому они нужны? Ведь вызвть фуницию с совподающим описанием неудастся.

Это ещё что за новости? Да, вызвать функцию, совпадающую по формальным параметрам, но не являющуюся членом класса по указателю на функцию-член действительно нельзя, поскольку нужен ещё и экземпляр класса. А статическую функцию-член — очень даже можно. Впрочем, об этом — ниже.

VD>Проблема решается двумя способами введением в язык указателя на метод экземпляра и интерфейсами.

Ещё она решается шаблонами, но об этом — попозже.

VD>Первая идея реализована в Дельфи и билдере. Идея проста и элегантна — указатель не зависит от конкретного класса и содержит указатель на экземпляр. По сути хранятся два указателя. Первый указвает на объект. Второй на функию.

Ну да, так примерно и есть.

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

Это что-то новое. Указатель на функцию можно хранить в inline-static или в специализации этого метода. А зачем реализовывать ещё и все методы интерфейса? И ещё — что означает твоё выражение "реализовать только один метод интерфейса"? Реализовать где? По идее — если методы могут реализовываться абсолютно независимо, то это уже — отдельные классы.

Стоп, кажется, понял. Ты имеешь ввиду — реализовать отдельный метод класса, оставив часть их абстрактными, т.е., нереализованными?

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

VD>Интересно, что в тихую замял вопрос про рефлекшен.

Замнёшь его, как же В другой ветке где-то, а сейчас — ещё и в "Философии программирования" на эту тему есть рассуждения AndrewVK, IT и мои.

VD>Возможно просто незнаешь термина.

Не знал.

VD> В COM это назывлось TypeInfo. Так вот, С++ напрочь лишен подобного михонизма. И чтобы создать теже события для компонентов реализованных на С++ к программе нужно прилепить еще гору года в виде разных tlb. Так рождается COM. А потом рождаются разные ATL и #import, единственная цель которых скрыть все сложности реализации компонентов и упростить работу. В итоге мы порождаем проблему и ее же решаем.

Что верно — то верно.

VD>Так вот в .NET и Яве компонентный подход был интегрирован в рантайм-подсистему. Теперь вместо QueryInterface можно просто привести тип и рантайм все поймет и сделает как ужно,

Ну, если на то пошло, то если тип COM-интерфейса вообще не был известен на этапе трансляции COM-клиента (ни по IID ни по-иначе), то вызов методов можно было и через IDispatch оформить с соответствующим заворачиванием в шаблоны/функторы, а имя типа объекта — из окошка ввести. Вариант не лучший, бесспорно, с любой стороны, поскольку нет никакой гарантии, что подвернувшийся объект будет адекватно на эти вызовы реагировать.

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

ИМХО, элемент залога устойчивости системы.

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

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

ГВ>> Каким, например, должен быть механизм передачи событий? Должен ли он предусматривать межпроцессную передачу данных? Должна ли принимающая сторона уметь идентифицировать отправителя события? Должна ли создаваться очередь событий? Варианты ответов на эти вопросы прекрасно можно оформить библиотеками классов на C++! Зачем навязывать самим себе "единственно правильную" модель реализации?

VD>Вот сразу видно, что сам ты подсудимого не знал и книг его не читал. Знаешь что такое делигат? В .NET он как раз решает все те вопросы о котоых ты говоришь так иронично. Причем решает локонично, красиво и универсально. Пишиш так:

VD>

VD>public delegate void FileCallback(string sFileName);
VD>...
VD>internal void IterateNode(FileCallback Callback, string sPath)
VD>{
VD>    ...
VD>    foreach(string File in m_Files) // перебираем их..
VD>        Callback(sPath + File); // и вызываем для каждого callback-метод.
VD>}

VD>... // в другом классе, а то и вообще в другом модуле (а то и в проекте)

VD>m_SearchEngine.IterateNodes(new FileCallback(ProcessFile));

VD>public void ProcessFile(string sFileName){...}
VD>

VD>Все это работат очень похоже на указатели на фуниции в С.

Согласен, здесь даже укрыты различия между "обычными" функциями и методами. На C++ решается не так лаконично, но делегат...

VD>Но делегат это тип (почти класс).

...sealed, т.е., наследовать от него нельзя.

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

Ну, это уж кому как.

ГВ>>Для C# и Java эти вопросы решались исходя из целей этих языков. C# — поддержание амбиций Microsoft (т.е., внедрение поддержки модели COM), а Java... кстати, в Java event-ов и property на уровне языка нет! Есть библиотеки!

VD>Нда, про COM ты похже знаешь совсем мало, а про .NET вообще ничего не знаешь, но выводы делешь. "Сам я подсудимого не занаю и произведений его не читал, но как и весь совесткий народ..." (с).

VD>COM стэкуется с .NET через довольно сложную систему именуемую Interop. Собственно через нее нэт стыкуется и с обычным Win32. Причем базовая часть нэта, так называемая CLI (в народе Ротор) порирована под Фришку. Так что амбиции то амбициями, а факты фактоми.

Хорошо. Признаю, что здесь с определениме целей я ошибся.

ГВ>>Ну, во-первых. Сравнивать COM (в сущности — способ структурирования коммуникаций) с моделью объектов в языках реализации не совсем корректно.

VD>Это где же ты такое определение COM-а нашел? Вообще-то COM — это бинарная компонентная модель позволяющая создавать модули совместимые между разными языками. То о чем ты подумал называется ORPC. Или в простонародье DCOM-ом.

Основу для такого вывода я нашёл в глоссарии к MS SDK help.

ГВ>>Реализация COM для C++ в Miscrosoft-овском варианте

VD>А что были другие?

Ну, скажем так, могли бы быть.

ГВ>> обладает теми же чертами, что и плоский API на C с небольшими вкраплениями объектного подхода. То есть — можно было бы и лучше.

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

ГВ>> Потом, не надо забывать о том, что, действительно, по сравнению с C++ (что, впрочем, ИМХО, справедливо для любого языка общего назначения) языки специального назначения обладают преимуществами в специальных областях. Ну, например, VBS или Perl лучше подходят для скриптования идиотской модели объектов ClearQuest, нежели C++, хотя и там время от времени приходится использовать его.

VD>Скриптования это круто. Я вот только не пойму, C# тоже специализированный язык для этого самого скриптования или ты о чет-то другом?

C# специален для CLR. В отсутствие CLR с его специфическими особенностями, C# попросту нет.

ГВ>>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun, а C# + CLR — как противовес Java в той же области, то, естественно, они в этом смысле обладают преимуществами перед C++. Тогда как C++ создан для упрощения решения проблем программирования. Что называется — почувствуйте разницу

VD>Ты сам то понял что сказал? Язык "создан для упрощения решения проблем программирования". Может он того... для самого этого программирования и создан? И какая разница тогда между Явой и С++?

В самом "верхнем" смысле — никакой, кроме той, что C++ гибче.

ГВ>>И здесь я действительно согласен с тем, что на C# проще реализовать что-то на базе модели COM. Но, ёлки-палки, COM — это не способ построения абстракций уровня реализации, он слишком ограничен для этого!
ГВ>>

VD>Надо мужикам расказать, а то они и незнали. (с)

Странные у тебя мужики А что, отсутствие множественного наследования и шаблонов (надеюсь, временное) увеличивает гибкость? Относительно того, что C# непосредственно унаследован от COM — признаю свою ошибку, хотя, всё равно, ИМХО, CLR много у него взял. Ну что ж, это вполне логично и оправданно.

VD>1. C# не прднозначен для создания COM-объектов хотя на нем их действительно делать не сложно.

Признаю.

VD>2. COM единственная доведенная до серийного исползования бинарная компонентная модель.

Это не говорит о нём ни "за" ни "против".

VD>3. COM замечательно подходит для "построения абстракций уровня реализации".

Нет. Поскольку за COM-интерфейсами есть ещё много чего.

ГВ>>Итак, цели: выделение абстракций и их комбинирование.
ГВ>>Чего нет в Java: а) множественное наследование;

VD>Это действительно прискорбно.

ГВ>> б) шаблоны;

VD>Это тоже. Но в следующей версии Явы они уже будут.

ГВ>> в) инлайнирование (как инструмент совмещения структурированных абстракций и эффективности исполнения).

VD>Да словечко еще то. Так вот лучшие на сегодня компиляторы от MS и Intel уже сегдня плюют на эти директивы. Более того они умеют делать автоподстановку, причем значительно эффективнее чем прогаммист. Это и не мудренно, так как только комилятор может понять эффективна она или нет. В Яве и .Net это метод тоже используется.

O'K, согласен.

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

VD>А ты не стесняйся. Вот попробуй на С++ сделать указатель на член экземпляра объекта.

Запросто. Я же говорю, что ты подзабыл C++. Кстати, укзатель на член экземпляра — это указатель на тип этого самого члена.

class A { public: int _a; }

typedef int A::*a_member;

...

A my_a, my_b;

a_member ap = &A::a;

cout << my_a.*ap << endl;
cout << my_b.*ap << endl;

Впрочем, я понимаю, что ты имеешь ввиду — реализовать ту же модель, что реализована делегатами. В принципе, я уже придумал реализацию, запощу чуть позже. Сюда или в "C++". Хотя, повторюсь, что на C++ реализация не столь лаконична, как в C#.

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

Ну, не так уж он и нужен.

VD> Покажи еще как на С++ динамически загрузить объект и вызват его методы. Причем на КОМ не фига пинять.

Есть такой паттерн, называется прокси, если не ошибаюсь... или lazy-object.

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

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

VD> Попробуй найти кострукцию finally.

Можно и без неё обойтись.

ГВ>>Абсолютно не согласен. Вопрос в том — что именно называть большой и сложной программой.

VD>Да любой проект можно сделать большим сложным и глючным.

Особенно, если компонентизировать его без меры.

ГВ>>...SQL+VB, где основная сложность — поддержание адекватности структуры отчётов структуре БД, что суть прямое нарушение принципа абстракции пользовательского интерфейса (отчётов) от деталей реализации (структуры БД). Так основное время команды уходило на вот это самое бестолкове сопровождение.

VD>А ты случаем не видел аналога на C++ + SQL? О... забавное зрелище.

Видел. То, как их реализуют мне тоже не понравилось.

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

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

VD> Именно поэтому CGI так быстро уступили разным ASP, PHP и JSP.

ГВ>>Прикол как раз в том, что когда работаешь со скриптовыми языками, часто даже не задаёшь себе тех вопросов, которые не боишься ставить, используя C++. А C# и Java я как раз и считаю разновидностью скриптовых языков, посольку ИМХО они апеллируют к реализации каких-то элементов системы на других языках.

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

Да, это я сгоряча, в общем-то.

ГВ>>К примеру, именно отсутствие в Java (и в C#) шаблонов и приведёт либо к разбуханию большой и сложной программы, либо к снижению эффективности её работы, за счёт необходимости run-time-приведения типов (виртуальные функции). Не считая уже того, что в Java невозможно будет перенести на транслятор такую же часть контроля корректности программирования, как и в C++.

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

Шаблоны добавляют производительности не столько готовой программе, сколько процессу её разработки.

ГВ>> Т.е., Java-программы будет сложнее сопровождать, если конечно, не требовать от пользователя поставить 4-х процессорный сервер P4-2200 под 10-пользовательскую CRM.

VD>Практика показывает, что сопровождать как раз проще Яву и Шарп. Дело в том, что у этих языков выше уровень абстракции, ниже склонность толкать программиста на совершение ошибок. Это позволяет делать программы быстрее, с меньшим количеством ошибок и более формлизованных. К тому же это компонентные языки. Разбиение программы на компонены позволяет создавать ее как бы из кирпичиков. При этом каждый кирпичик можно оттестировать и документировать. Понятно, что это можно делать и на ассемблере, но Ява и Шарп подталкивают к этому и предоставлют мощьную поддержку.

Да, конечно. Ява и Шарп в каких-то случаях лаконичнее, но в каких-то — принципиально не смогут обеспечить той же лаконичности, что и C++. Хотя бы за счёт отсутствия множественного наследования и (всё ещё) — шаблонов.

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

VD>Итак, с чем я согласен. Ну, почти со всем. Вот только COM пока не мертв. В новй Windows.Net так и не появилось серьезного сервера приложений для .NET, а вот как раз COM+ улучшился.
Похоже у них просто сил не хватает, или не хочется вкладывать в это деньги пока дотнет не завоевал определенного сегмента рынка. Пока что только SQL-сервер мигрирует в сторону .Net.
А вобще хотя бы IIS можно было бы под дотнет переписать, не такой уж IIS большой проект.

VD>Правда сервером может выступать и IIS, но это позволяет решать только проблпмы автоматизации web-а.
Не, ну какой из IIS апп сервер? Если без всяких MSMQ еще можно прожить, то без транзакций и кеша/пула объектов уже сложно.

VD> Это конечно не плохо, но для полной победы явно мало.
Мало

VD>Я бы на сегодня сказал так. COM и С++ остаются, но потихоничку переходят в разряд низкоуровневых средств.
С++ и COM останется до тех пор пока большая часть NT не будет переписана под .NET, а это если и будет то очень нескоро.

VD>.NET можно смело считать новой версией COM-а. (У меня есть фактическое этому подтверждение) По крайней мере он развивает все то хорошее что было в COM-е:
VD>Динамическую загрузку и исполнение кода.
VD>Описание типов (теперь она стало полным).
VD>Абстрагирование интерфейса от реализации.
VD>Динамическое приведение типов.
Ну это характеристики не СОМ а компонентной модели вобще.

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

VD>Ой дайте я. :)

VD>property:

VD>MyObj.SomeProp = 12345;

VD>Вот такой. ;) Если у кого есть ольтернатива, то выкладывайте ее. Возникает вопрос, а зачем они нужны? Дык есть таки программки называются визульными дизайнерами. Там на базе концепции свойств задают начальное состояние компонента. Зачем нжны комоненты поянять нужно?

Так вот товарищ как раз утверждает что компоненты на самом деле не очень то и нужны.

VD>Проблема решается двумя способами введением в язык указателя на метод экземпляра и интерфейсами. Первая идея реализована в Дельфи и билдере. Идея проста и элегантна — указатель не зависит от конкретного класса и содержит указатель на экземпляр. По сути хранятся два указателя. Первый указвает на объект. Второй на функию.
Ну делегаты по сути дела тоже самое только понавороченнее — это не указатель а коллекция указателей.

VD>Интересно, что в тихую замял вопрос про рефлекшен. Возможно просто незнаешь термина. В COM это назывлось TypeInfo.

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

VD>Так вот в .NET и Яве компонентный подход был интегрирован в рантайм-подсистему. Теперь вместо QueryInterface можно просто привести тип и рантайм все поймет и сделает как ужно, а не будет недоуменно смотреть и говорить что он знает только типы доступные во время компиляции.
Самое интересное что и компилятор при компиляции тоже пользуется рефлекшеном и компонентной моделью.

VD>Все это работат очень похоже на указатели на фуниции в С. Но делегат это тип (почти класс).
Почему почти? Класс и есть.

VD>COM стэкуется с .NET через довольно сложную систему именуемую Interop. Собственно через нее нэт стыкуется и с обычным Win32. Причем базовая часть нэта,
Стандартизованная в ECMA
VD> так называемая CLI (в народе Ротор)
CLI это common language implementation, название стандарта. Ротор — название конкретной реализации.

VD> порирована под Фришку.
Причем при активном участии MS, т.е. в отличие от Mono это не самодеятельность.

ГВ>> б) шаблоны;

VD>Это тоже. Но в следующей версии Явы они уже будут.

Prototype for JSR014: Adding Generics to the JavaTM Programming Language v. 1.2
Доступно для скачивания. Так что почти что уже есть.

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

VD>>Вот такой. Если у кого есть ольтернатива, то выкладывайте ее. Возникает вопрос, а зачем они нужны? Дык есть таки программки называются визульными дизайнерами. Там на базе концепции свойств задают начальное состояние компонента. Зачем нжны комоненты поянять нужно?

ГВ>То есть, проблема пропертей инспирирована единственно дизайнерами окошек... Так тогда она и яйца выеденного не стоит.
Инспирирована компонентной архитектурой.

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

Тем не менее даже монстры вроде WebLogic написанные на джаве вполне устойчивы.

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

ГВ>Слушай, давай определись — какой аспект рантайма ты имеешь ввиду.

Динамическую загрузку классов.

VD>>Но делегат это тип (почти класс).

ГВ>...sealed, т.е., наследовать от него нельзя.

А зачем?

VD>> О нем можно узнать информацию черз рефлекшон (динамически). Колбэки можно осуществлять сквозь границы процессов и машин. Можно подключать сразу нескльно обработчиков к одному делегату. В общем современный вариант решения проблемы, а не перекладывание ее на плечи программиста.
ГВ>Ну, это уж кому как.
Ну если ты мазохист и любишь изобретать велосипеды в каждом проекте то конечно.

VD>>Это где же ты такое определение COM-а нашел? Вообще-то COM — это бинарная компонентная модель позволяющая создавать модули совместимые между разными языками. То о чем ты подумал называется ORPC. Или в простонародье DCOM-ом.

ГВ>Основу для такого вывода я нашёл в глоссарии к MS SDK help.

Он настолько монстроидален что при желании там можно найти что угодно
Вон в дотнетовском форуме человек где то вычитал что можно Remoting сервер использовать COM-клиентами. Хотя далее становится понятно что имелось ввиду просто возможность использования одних и тех же объектов для ремоутинга и COM+.

VD>>А что были другие?
ГВ>Ну, скажем так, могли бы быть.
А почему не были?

VD>>Ты сам то понял что сказал? Язык "создан для упрощения решения проблем программирования". Может он того... для самого этого программирования и создан? И какая разница тогда между Явой и С++?

ГВ>В самом "верхнем" смысле — никакой, кроме той, что C++ гибче.
А ассемблер еще гибче.

VD>>Надо мужикам расказать, а то они и незнали. (с)

ГВ>Странные у тебя мужики А что, отсутствие множественного наследования и шаблонов (надеюсь, временное) увеличивает гибкость?
Гибкость это не единственная характеристика языка. Строгая типизация снижает гибкость. Выкидываем?

ГВ> Относительно того, что C# непосредственно унаследован от COM — признаю свою ошибку, хотя, всё равно, ИМХО, CLR много у него взял. Ну что ж, это вполне логично и оправданно.
CLR у C++? Что именно?

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

ГВ>Есть такой паттерн, называется прокси, если не ошибаюсь... или lazy-object.
При чем здесь паттерн? Ты расскажи — как конкретно на лету загрузить класс.

VD>> Попробуй найти кострукцию finally.
ГВ>Можно и без неё обойтись.
Во опять. Нет, значит можно обойтись. Вон в дотнете нет множественного наследования и шаблонов, ну так без них вполне можно обойтись. Тем более что множественное наследование интерфейсов есть, а подключение реализаций можно реализовать.

VD>>Да любой проект можно сделать большим сложным и глючным.
ГВ>Особенно, если компонентизировать его без меры.
Вот как раз наоборот.

ГВ>Да, конечно. Ява и Шарп в каких-то случаях лаконичнее,
Они в большинстве случаев лаконичнее.

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

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

ГВ>То есть, проблема пропертей инспирирована единственно дизайнерами окошек...

Ну, еще дизайнерами миделвэа-приложений и другими дизайнерами.

ГВ>Так тогда она и яйца выеденного не стоит.

Стоит, не стоит. Это удобно и нет ни одного противопоказания. Но в стандрат не вводят. Мелочь конечно, но пративно.

ГВ>Да, дружище. Забыл ты C++. Указатели на функции и на статические члены типов там живут и благоденствуют.

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

Делегаты и клосюры это нечто большее. Вот это в отличии от свойств уже сильно облегчает жизнь. Но не для С++-ников. :(

VC>>Зделали указатели на фуниции-члены классов. Кому они нужны? Ведь вызвть фуницию с совподающим описанием неудастся.

ГВ>Это ещё что за новости? Да, вызвать функцию, совпадающую по формальным параметрам, но не являющуюся членом класса по указателю на функцию-член действительно нельзя, поскольку нужен ещё и экземпляр класса. А статическую функцию-член — очень даже можно. Впрочем, об этом — ниже.


А нафига мне статическая? Этак я и на С-ях писать могу. Мне нужно событийно ориентированное программирование на базе ОО. На С я это и 10 лет назад делал.

VD>>Проблема решается двумя способами введением в язык указателя на метод экземпляра и интерфейсами.

ГВ>Ещё она решается шаблонами, но об этом — попозже.

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

VD>>Первая идея реализована в Дельфи и билдере. Идея проста и элегантна — указатель не зависит от конкретного класса и содержит указатель на экземпляр. По сути хранятся два указателя. Первый указвает на объект. Второй на функию.

ГВ>Ну да, так примерно и есть.

Где? В Билдере — да. В стандарте — нет.

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

ГВ> :???: Это что-то новое.

Что новое? Интерфейсы? Да им сто лет.

ГВ> Указатель на функцию можно хранить в inline-static или в специализации этого метода.

Чё-чё. Ты не мудри, ты пальцем покажи. :)

ГВ> А зачем реализовывать ещё и все методы интерфейса?

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

Помойму ты не понимаешь что я имею ввиду под словом интерфейс. COM знаешь? А CORBA-у? Это от туда термин.

ГВ> И ещё — что означает твоё выражение "реализовать только один метод интерфейса"? Реализовать где?

В классе который должен обратбатывать события.

ГВ> По идее — если методы могут реализовываться абсолютно независимо, то это уже — отдельные классы.

Вот здесь бы и подошли абстракции типа клосюра (у Борлонда) или делегатов у MS. Без них событийное программирование — мрак.

ГВ>Стоп, кажется, понял. Ты имеешь ввиду — реализовать отдельный метод класса, оставив часть их абстрактными, т.е., нереализованными?

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

VD>>Интересно, что в тихую замял вопрос про рефлекшен.

ГВ>Замнёшь его, как же :) В другой ветке где-то, а сейчас — ещё и в "Философии программирования" на эту тему есть рассуждения AndrewVK, IT и мои.

Ну, ды ссылку давай. :)

И все же отсуствие полноценной информации о типах во время выполнения программы резко уменьшает возможности автомтизации в программах. Ну, и делают невозможным разработку компонетов на таких языках. MS работая над комом был вынужден добавить tlb и MIDL, т.е. расширил не только язык но и средства разработки. В .NET и Яве рефлекшен снимает все эти проблемы.

ГВ>Ну, если на то пошло, то если тип COM-интерфейса вообще не был известен на этапе трансляции COM-клиента (ни по IID ни по-иначе), то вызов методов можно было и через IDispatch оформить с соответствующим заворачиванием в шаблоны/функторы, а имя типа объекта — из окошка ввести. Вариант не лучший, бесспорно, с любой стороны, поскольку нет никакой гарантии, что подвернувшийся объект будет адекватно на эти вызовы реагировать.

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

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

ГВ>ИМХО, элемент залога устойчивости системы.

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

Например, в С++ безпроблем можно привести указатель на один объект к указатлю на другой. Все грохнет в рантайме. И грохнет серьезно (обычно AV). В .NET же в рантайме делаются проверки и неправильное приведение вызовет исключение. Но исключение неправильного приведения типов. Такое исключение легко обработать.

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

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

ГВ>Слушай, давай определись — какой аспект рантайма ты имеешь ввиду.

В смысле? Я имею в виду, то что С++ идеологически настроен на генерацию кода. И рантай его подсистема заканчивается на CRT.

Чтобы понять о чем я говорю, представь сколько кода нужно для вызова метода информация о котором не была доступна во время компиляции? Т.е. на входе есть имя модуля (длл-ки) и нужно дать мозможность вызвать один из методов класса который находится в этом модуле. На C# это пишится за пол часа. На С++ эта задача в общем не решаема. Решить ее можно применяя разные расширения типа COM.

ГВ>Согласен, здесь даже укрыты различия между "обычными" функциями и методами. На C++ решается не так лаконично, но делегат...

Я в свое время пытался сделать удобоваримый вариант. В конце концов все закончилось тем, что пришлось заложиться на реализацию внутренних структур классов конкретным компилятором (VC6) и снова отказаться от контроля типов во время компиляции. Т.е. в принципе проблема решается, но криво. С поддержкой компилятора можно было бы сделать намного проще и лучше. Причем я даже согласился бы на минимальные изменения. Достаточно было бы дать возможность вызывать по указателю методы (у экземпляра) с одинаковым описанием. Остальное решаемо. Но Страуструп опять уперся рогом. :(

VD>>Но делегат это тип (почти класс).

ГВ>...sealed, т.е., наследовать от него нельзя.

К сожалению. Но на практике и этого хватает. А "почти класс" это я ктому, что о нем можно получить информацию в том же рантайме.

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

ГВ>Ну, это уж кому как.

Согласись, что С++ стал бы только лучше если бы в него добавили бы эти самые делегаты и рефлекшон? Кому от этог хуже.

ГВ>Основу для такого вывода я нашёл в глоссарии к MS SDK help.

Да. С глосариями у MS всегда были проблемы. Они больше запутывают.

ГВ>>>Реализация COM для C++ в Miscrosoft-овском варианте
VD>>А что были другие? :)))
ГВ>Ну, скажем так, могли бы быть.
:)

VD>>Скриптования это круто. Я вот только не пойму, C# тоже специализированный язык для этого самого скриптования или ты о чет-то другом?

ГВ>C# специален для CLR. В отсутствие CLR с его специфическими особенностями, C# попросту нет.

Ну, а скрипты то тут причем? Скрипт от не скрипта отличает наличие процесса компиляции. Тот же VB3 был интерпретатором, но не скриптом. А уж CLR 100%-но компилирует весь код перед исполнением.

VD>>Ты сам то понял что сказал? Язык "создан для упрощения решения проблем программирования". Может он того... для самого этого программирования и создан? И какая разница тогда между Явой и С++?

ГВ>В самом "верхнем" смысле — никакой, кроме той, что C++ гибче.

Ну, что есть того не отнять. Но обратная сторона этой гибкости — неимоверная сложность программирования на нем. На С++ недельный поиск ошибки — это нормально. Для Явы два часа уже аврал. .NET же вообще дает тебе все варианты. Нужна низкоуровневая оптимизация... берем MC++ (который, кстати не урезан, а даже расширен, и поддерживает все возможности С++ известнве MS :) ). А то и вообще на мсиле в рантайме... Нужна безопастность и скорость разработки... берем C# или VB.NET. Нужны экзотические приколы... берем Перл, Эфил и т.п. Т.е. противопоставление есть только в одну сторону. Ну, а гибкость?... Дык она в основном нужна там где проблема не решается штатными методами. Например, на Шарпе можно создать здоровенное приложение ни разу не обратившись к указатлям. Но как только нужно взаимодействовать с теми же контролами виндовс, как без них не обойтись. Да и вообще становится удобнее писать на С++.

VD>>Надо мужикам расказать, а то они и незнали. (с)

ГВ>Странные у тебя мужики ;)

Ты что рекламу не смотришь? :)

ГВ> А что, отсутствие множественного наследования и шаблонов (надеюсь, временное) увеличивает гибкость?

Нет. Это явные недостатки. Причем явно слизанные с Явы и Дельфи. Мы это уже обсуждали. Вопрос в том, что приемуществ явно больше. Да и скорее всего недостатки эти скоро устранят. Уж если Ява дожила до шаблонов... :)

ГВ> Относительно того, что C# непосредственно унаследован от COM — признаю свою ошибку, хотя, всё равно, ИМХО, CLR много у него взял. Ну что ж, это вполне логично и оправданно.

Кто бы спорил. Забавно, что зародился CLR именно как проект COM-2. Но MS был бы не MS елси бы у него все выходило так как задумано. :)

VD>>2. COM единственная доведенная до серийного исползования бинарная компонентная модель.

ГВ>Это не говорит о нём ни "за" ни "против".

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

VD>>3. COM замечательно подходит для "построения абстракций уровня реализации".

ГВ>Нет. Поскольку за COM-интерфейсами есть ещё много чего.

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

VD>>А ты не стесняйся. Вот попробуй на С++ сделать указатель на член экземпляра объекта.

ГВ>Запросто. Я же говорю, что ты подзабыл C++. Кстати, укзатель на член экземпляра — это указатель на тип этого самого члена.

Извени. И имел в виду указатль на функцию челен. Причем я не даром сказал указатель на член экземпляра объекта. Т.е. попробуй сделать указатель на фукцию так чтобы в него можно было поместить адрес на фуниции разных классов (но с одинаковым описанием). Псевдокод:

struct A { void MyFanc1(); };
struct B { void MyFanc2(); };

НекийУсловныйУказательНаМетод pMethod = bCondition ? MyFanc1 : MyFanc2;

...

pMethod();

Делегаты с таким справляются на ура.

ГВ> ;) Впрочем, я понимаю, что ты имеешь ввиду — реализовать ту же модель, что реализована делегатами. В принципе, я уже придумал реализацию, запощу чуть позже. Сюда или в "C++". Хотя, повторюсь, что на C++ реализация не столь лаконична, как в C#.

Я уже этим занимался. Как уже говорил получилось не красиво.

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

ГВ>Ну, не так уж он и нужен.

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

VD>> Покажи еще как на С++ динамически загрузить объект и вызват его методы. Причем на КОМ не фига пинять.

ГВ>Есть такой паттерн, называется прокси, если не ошибаюсь... или lazy-object.

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

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

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

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

VD>> Попробуй найти кострукцию finally.

ГВ>Можно и без неё обойтись.

Вот только нужно ли? Мы вот вообще ATL-объекты без исключений пишим. Но радости от этого никакой. :(

VD>>Да любой проект можно сделать большим сложным и глючным. :)

ГВ>Особенно, если компонентизировать его без меры. ;)

Это без разницы. Были бы "талантливые" руки. Компонентный же подход как раз и становится выходом когда размеры проета становятся невыносимыми.

VD>>А ты случаем не видел аналога на C++ + SQL? О... забавное зрелище.

ГВ>Видел. То, как их реализуют мне тоже не понравилось.

Так может дело в людях?

ГВ>>>Прикол как раз в том, что когда работаешь со скриптовыми языками, часто даже не задаёшь себе тех вопросов, которые не боишься ставить, используя C++. А C# и Java я как раз и считаю разновидностью скриптовых языков, посольку ИМХО они апеллируют к реализации каких-то элементов системы на других языках.

Ну, ошибаешьс ты. Что же тут поделаешь. 99% (см. Анакрино и Ротор) библиотек для C# написанно на нем самом. Вот рантайм-подсистема, та да на 70% плюсовый код.

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

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

ГВ>Да, это я сгоряча, в общем-то.

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

ГВ>Шаблоны добавляют производительности не столько готовой программе, сколько процессу её разработки.

Не скажи. Методы применяемые в Яве и .NET-е такие же производительные, даже по шустрее в общем итоге. Но с шаблонами там было бы все намного лучше. Одна беда там нужны уже не шаблоны, а "общие типы". Дело в том, что они должны жить в рантайме. В том же MC++ шаблоны есть и на них можно без проблем писать .NET приложения. Все это скомпилируется в мсил и (если ты не зацепил специфичных для платформы вещей) запустится на другой платформе. Но вот унаследовать CLR-класс от такого класса не удасться. :(

ГВ>Да, конечно. Ява и Шарп в каких-то случаях лаконичнее, но в каких-то — принципиально не смогут обеспечить той же лаконичности, что и C++. Хотя бы за счёт отсутствия множественного наследования и (всё ещё) — шаблонов.

Так никто и не спорит. Просто в прикладных задачай Шарпы и Явы подходят как нельзя лучше. А в системных... Вот потому мы выбераем не Яву, а .NET. Там же есть то самый С++. Если что создаем обертку на нем и используем ее из Шарпа. Мы и раньше так делали. VC + VB. На последнем клепаем интерфейсы, на первом логику и низкоуровневый код. Интеграция берез COM. Теперь просто все становится еще проще. Между прочим С++-ные модули прекрасно отлаживаются будучи встроеными в C#-проект. В COM-е нужно было изгаляться по черному, а тут... просто лафа.