VladD2,

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

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

> ПК> А, в фоновом режиме, таки да, начались кой-какие подвижки в сторону соответствия стандарту.

> И вот тут возникает вопрос. Почему такие бабки кладутся на разрботку нового языка — сишарпа, и упровляемой среды упровления?

Маркетинг. Завоевание рынка Java и т.п. Денег хотят, короче.

> И почему МС решились положить толстый ... на весь С++ и сейчас переориентируют кучу кода под тот же C#?

MS вкладывается в C++ по полной программе, и твои заявления сильно расходятся с тем, что говорят официальные лица компании, которым я в этом вопросе, снова-таки доверяю значительно больше

Например:

> C# must be quite capable if MS is writing all internal code with it now. Wow. I thought the day would never come that C++ would take a back seat.

That's really news to me.

I wouldn't stretch this too far. Yes, C# is a great language but the use of C++ is still alive and thriving. Since I interned in Microsoft Outlook, I usually go over there to hang out and see what's going on. C# is used in areas where the .NET platform is designed to stand out -- namely Web Services and ASP.NET. C++ is definitely the mainstream language for writing the applications.

Добавка от менеджера, для большей ясности:

To re-iterate what Brandon already said, the statement that Microsoft is using C# for all internal development is completely bogus.

И далее оттуда-же:

Yes, managed code is the direction we are going in moving forward for all the places where it makes sense. However extrapolating that to mean C# is simply not true. We are spending a lot of resources to make sure C++ is a primary development language on the .Net platform and are seeing a lot of internal adoption of C++ to write managed code inside of Microsoft. In the RTM version the primary focus of MC++ is to enable you take integrate easily with existing code, but in future releases you will see us focusing much more on making C++ take up the traditional role it serves role as the high end language for system level programming and for expert level programming on the .Net platform.

А шумиха вокруг C# вполне объяснима: надо же MS свое детище двигать, Джаву теснить...

> Не уж то одной из причин небыло как раз отсуствия у С++ и его стандарта некоторых качеств?

Да, конечно, есть и эта причина. Но только на основании наличия разницы языков говорить о безусловном преимуществе какого-то из них некорректно.

> А вот ты сам сказал, что реализовывать, то даже меньше чем в случае шарпа

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

> Большинство программистов использующих С++ в своей работе бревна в нем не замечают, при этом постоянно понимая вопрос о том зачем нужед дотнет и т.п.

Большинство программистов, использующих C++ в своей работе, с которыми я общаюсь, никаких вопросов о назначении .Net не задают. Он им глубоко фиолетов, пока не приходится с ним иметь дело.

> Да что там. Страуструп несет такое, что смешно становится.

Например?

> ПК> Ты уверен, что достаточно глубоко ознакомился с предметом? VC++ 7.0 и 7.1 в плане соответствия стандарту — небо и земля.

> Я уверен, что идет очередная попытка уйти всторону. Да и снова преувеличения. Никакой там земли и неба нет. Список изменений умешатся в одном абзаце.

Этот список изменений, умещающихся в одном абзаце — большая часть изменений в языке от ARM и ранних черновиков стандарта (VC++6.0) до современного состояния языка. Это намного больше, чем осталось доделать для почти полного соответствия стандарту ("почти" означает без экспорта шаблонов). Фактически VC++7.1 осталось: двухфазный поиск имен, исправление ошибок, и еще одна фича сомнительной нужности — спецификация исключений; пожалуй, все...

У GCC близкая ситуация. Так что странно говорить о слабой поддержке стандарта современными компиляторами...

> ПК>Модули вещь хорошая.

> Ну, так может признать то, что отсуствие их в С++ и уход спецификации С++ от их описания — это болшая брешь в них?

Причем здесь брешь? С точки зрения C++ от добавления модулей ничего принципиально не изменится:
1) улучшится скорость компиляции;
2) упростится диагностика ODR;
3) может, еще какие мелочи.
Или ты еще что-то подразумеваешь?

> Так что признаем недостатком стандарта С++ отсуствие разделов говорящих о модулях и принципах компиляции с их использованием? А так же признаем недостатком то, что в языке нет конструкций отличных от #include позволющих импортировать типы из вне?

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

> ПК> Тезис о лучшей кроссплатформенности (переносимости) Java и .Net подтверждать данными каких-нибудь объективных исследований будешь, <...> или это твое личное мнение, в обоснованиях не нуждающееся?

> Это мое лично мнение сформированное на большом количестве фактов.

Ок, приводи факты, их количество, сравнение количества для C++, С# и Java и т.п. Или посылаем мнение в лес как необоснованное.

> Так если без обобщений. Есть проблемы у С++ и его стандарта?

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

> Много ли их?

Не знаю. Зависит от критериев много/мало.

> Влияют ли они на качество С++ и/или стандарта?

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

> ПК> Проектирование традиционно, все-таки, предшествует выпуску продукта, соответственно, проектирование языка должно было произойти до реализации компиляторов, каковая, как нам известно, предшествовала составлению стандартов.

> Нет. Уж стандарт — это всего лишь акт принятия спецификации. А вот специяикация является непосредственным процессом проектирования языка.

Не процессом, а результатом. Процесс по определению предшествует результату.

> ПК>Я избегаю сравнений в терминах "криво" и т.п.

> А в каких не избегашь? Можно примерчик?

Легко. Например:

C# поддерживает компонентно-ориентиорванное программирование, C++ — нет.
C++ поддерживает процедурное программирование, C# — нет.

И т.п.

> ПК> С первым можно и не трудиться сравнивать: в реальных программах на C# первой версии, как и в Java, столько неизбежных приведений типов,

> О... тут хочется сделать аж несклько возражений :

> 1. Сколько, Паша? Сколько? Не уж то ты сожешь аргументировано доказать, что их так уж много.

Я лучше задачу простую для иллюстрации приведу. Как отсортировать символы в строке на C#?

> 2. Почему первых версий?

Потому что это то, с чем приходится иметь дело ребятам на работе.

> 3. Данное высказывание является грубешой подменой понятий. Приведение типов в рантайме еще не делает язык типобезопасным. Есть такое понятие как автоматическая проверка типов в рантайме. А то понятие которым ты пыташся подменить типобезомаснсть назвается статической типобезопасностью. Какова же цеть подмены понятий. Мне кажется в очередной раз увести обсуждение в сторону.

Где ты увидел здесь что-то кроме упоминания статической проверки типов?

> ПК>С первым можно и не трудиться сравнивать: в реальных программах на C# первой версии, как и в Java, столько неизбежных приведений типов, обусловленных отсутствием параметризации, что статическая проверка отдыхает по полной программе.

> ПК>2) Это семечки по сравнению с невозможностью в C# (в том числе и, насколько я понимаю, второй версии) обеспечить тот уровень статических проверок, который легко достигается в C++. <...> Пример тебе уже приводили: проверка размерностей в физических выражениях во время компиляции.

> Извини суть того примера я так и не уловил. Более того он мне показался бредовым.

Еще раз в доступном виде.

1. Представь, что есть команда программистов, занимающаяся реализацией задач, связанных с большим количеством вычислений физических величин. Например, движок симуляции механики для игр.
   
2. Они сталкиваются с тем, что периодически делают ошибки в набираемых формулах.
   
3. Огромное количество ошибок, которые они делают, может быть отловлено путем контроля размерности, традиционного для физических вычислений. Например:
   

   Length l = length();
   Time   t = time();
   
   Velocity v = l * t; // ошибка: размерностью выражения справа является м*с, слева — м/с
   Velocity v = l / t; // ОК

   
   Естественно, выражения не ограничиваются такими простыми вещами. Есть целая система традиционных единиц. В частности:
   

   Mass     m = mass();
   Velocity v = velocity();
   
   Energy   e = m * v / 2;     // ошибка: размерности не совпадают
   Energy   e = m * v * v / 2; // OK
   
   Impulse  p = m * v * v;     // ошибка: размерности не совпадают
   Impulse  p = m * v;         // OK

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

   Velocity     v1 = velocity(1);
   Velocity     v2 = velocity(2);
   Velocity     v3 = velocity(3);
   Time         t  = time();
   
   Acceleration a  = v1 / t;                                  // OK
   Acceleration a  = v1 * v2 / t;                             // ошибка
   Acceleration a  = v1 * v2 / v3 / t;                        // OK
   Acceleration a  = ( v1 * v2 + v1 * v3 ) / ( v1 + v2 ) / t; // OK

   
   и т.п.
   
4. На C++ это делается относительно элементарно.
   
5. Как получить это на C#?
   
6. Предвосхищая вопросы, да, это реально используется, вот ссылки:
   http://wwwasd.web.cern.ch/wwwasd/lhc++/workshops/lhc++_mar99/24mar99/SIUNITS.PPT
   http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html
   и т.п.

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

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

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

> Из этих слов я делаю вывод, что ты исходиш из предположений:
> 1. Сто C# не имеет возможности наиболее эффективных приложений, а С++ имеет.

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

> 2. Что у C# как языка (а не конкретной реализации на CLI/дотнете и т.а.) есть какие-то особенности не позволяющие ему непосредственно общаться с аппаратной платформой.

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

> 3. Что С++ является системым языком, а не универсальным.

C++ поддерживает более одного стиля и парадигмы. В том числе правила проектирования данного языка содержат ряд положений, направленных на поддержку низкоуровневого программирования, среди которых есть и "Не оставлять места для языка более низкого уровня, чем C++, исключая ассемблер", и "Правило нулевых издержек: чем не пользуетесь, за то не платите", и "Если есть сомнения, предоставлять средства для ручного контроля".

Снова две разных вселенных...

> 4. Что типобезопасность противоричит эффективности и/или системности.

Типобезопасность не требует модели C#. C++ вполне безопасный в плане статического контроля типизации язык. Как показывают примеры выше, более безопасный, чем C#. В динамике встроенный контроль типов очень ограничен. Но это не означает, что кто-нибудь запрещает при необходимости построить свою надстройку, контролирующую все, что угодно.

>>> Да и о какой совместимости речь? С99 напрочь не совместим с С++. Значит совместимость не так и важна?

> ПК> Совместимость важна. С99 не так уж и не совместим c С++, а после выхода следующей версии C++, эта разница станет еще меньше.

> Очень, очень. Там появились массив как объекты высшего порядки и т.п.

Я вполне осведомлен об изменениях в C99.

> Скомпилировать программу написанную с испоьзованием фич С99 нельзя ни на одном компиляторе С++.

1) Можно в виде расширения.
2) Есть намерение, чтобы после ревизии стандарта это было требованием стандарта.

> ПК> Большее количество ключевых слов или конструкций не означает большую сложность языка.

> Зависит от критериев. С точки зрения синтаксиса неоспоримо сожнее.

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

В частности, где-то в последней трети сообщения http://rsdn.ru/forum/?mid=908196

Автор: Павел Кузнецов
Дата: 20.11.04

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

> Попробуй перечислить понятие С++ отсуствующее в Шарпе. <...>

Зачем?

>>> ПК> Заметь, я не утверждаю ни что C# проще, чем C++, ни что он сложнее. Только отмечаю, что я не видел подобных данных.

>>> Так все же утверждал?

> ПК> Нет.

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

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

> А то ситуация какая-то странная. У самого нет даже намека на критерии. Но чужие пыташся выставить неверными. Причем так... в заявительном порядке. Мол у мнея мнение, что твои критерии и аргументы субъективные.

Дык, ты ж объективных данных не приводишь

> ПК> В соответствии с моими критериями, C++ — вполне удачный язык.

> Это ничем не обоснованное мнение. Ценность которого стримится к нулю (с)

> Если серьезно, ты даже своих критериев не выскзал. Все пытаешся обосновать необоснованность моей позиции.

Просто пытаюсь сказать тебе, что никакие подобные критерии не могут подходить всем, как ты это часто преподносишь.

[b]Для меня[b/] главное:

• Не должно быть неявных нарушений статической типизации, или чтобы их количество было сведено к минимуму.
  
• Должен предоставлять разработчику максимум средств для определения поведения "своих" типов. В частности позволять создавать "свои" типы, максимально близко ведущие себя к встроенным. И для "своих" типов задавать максимум ограничений, контролируемых статически.
  
• Должен позволять максимально использовать код повторно.
  
• Должен поддерживать ООП, когда это нужно, но чтобы не болтался под руками со своими ограничениями, когда это не нужно.
  
• То же самое в отношении обобщенного программирования.

И требование, которое к дизайну языка не относится, но являтся, пожалуй, самым важным: вокруг языка должно существовать грамотное сообщество (community), помогающее решать проблемы, возникающие в ходе работы.

По всем перечисленным пунктам C++ я считаю языком удачным.

> ПК> 2) Изменений C++ требует. Против этого, по-моему, никто и не возражает...

> 1. Взражают.

Ну, с ними об этом и спорь

> 2. Опять же каких.

• Лямбда-функции — то, что доктор прописал.
  
• И прочие средства повышения локальности и изоляции кода и данных.
  
• Улучшение средств метапрограммирования пришлось бы очень кстати.
  
• Модули, пожалуй, тоже были бы приятным дополнением.
  
• Ну, остальное, скорее, мелочи, но жизнь тоже облегчат.

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

1) Я согласен с наличием проблем, но не согласен с твоим их перечнем
2) Разговор по поводу проблем C++ затеял ты

> Я всего лишь указал, что Оберощики используют проблемы С++ в целях превознесения их убогого языка.

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

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

У тех языков — свои проблемы.

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

> И что же такого дает данная неопределенность?

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

> ПК> Нет, это следствие того, что те, кого ты называешь "мало-мальски грамотными авторами языков", проектируют языки для несколько других задач.

> Ну, поделись для каких же? Чем они другие?

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

Скажем, для того же C# в спецификации явно оговорено, что он является объектно-ориентированным языком (т.е. навязывает определенную парадигму), и с C он по производительности соревноваться не предназначен. Хотя, согласен, во многих случаях показывает очень неплохие результаты.

> ПК> Еще раз: стандарт специально составлен так, чтобы у разработчиков компилятора была возможность реализации подобных проверок без нарушения стандарта.

> Это скорее случайнось. с теми же указателями вывернуться не удается.

Что значит вывернуться? Все соответствующие места в стандартах C и C++ прописаны так, чтобы были возможны проверки неправильной арифметики указателей во время исполнения. Этому посвящалось время на заседаниях. Как при таких условиях это может быть случайностью?

> ПК> Его использование для более прикладных задач требует большей квалификации, чем использование C#.

> Траха, траха больше требует.

Ну, вопрос открытый. У нас получается ситуация обратная: с использованием C# практических проблем значительно больше. Может, это мы с ним что-то не так делаем, но пока работать заметно менее удобно, чем с плюсами...

> А квалификацию можно потратить на более эффективное или быстрое решение задачи.

Дык, на плюсах так и получается...

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

> О! Еще одно необоснованное утверждение.

В смысле? Я, например, согласен платить эту цену. И те, с кем я работаю, согласны. Чего ж тут обосновывать?