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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[skip]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[skip]

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

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

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

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

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

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

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

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

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

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

[skip]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ok. Ждём :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кто посмел?

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

А сегодня:

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

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

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

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

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

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

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

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

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

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

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