Вопрос начинающего программиста на С++ - О работе

Здравствуйте 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&only) Здесь же замечу, что самого правильного набора библиотек не бывает.

ГВ>>Аргументация довода о преимуществах 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: И, ИМХО, упование на неё — большая ошибка любого специалиста.

	От:	MaximE
	Дата:	19.08.02 09:27
	Оценка:

	От:	Igor Trofimov
	Дата:	19.08.02 10:03
	Оценка:

От:	IT	linq2db.com
Дата:	19.08.02 12:57
Оценка:

От:	Anatolix	https://www.linkedin.com/in/anatolix/
Дата:	19.08.02 15:19
Оценка:

	От:	Anton V. Kolotaev
	Дата:	19.08.02 15:23
	Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	20.08.02 14:01
Оценка:	55 (6)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	20.08.02 17:48
Оценка: