Здравствуйте, Павел Кузнецов, Вы писали:

ПК>С 1998.

Не, с 89-го. 98 — это дата выхда последнег стандарта. А 89-ых — это год когда появились шаблоны и вообще язык можно было назвать состоявшимся.

>> ПК> В Microsoft до недавнего времени на стандарт плевали с высокой колокольни, и занялись поддержкой оного, когда увидели, что это становится, действительно, важным для их пользователей.

>> Да то, что это важно для пользователей они поняли еще гду в 90-ом.

ПК>Откуда дровишки?

Да из появления VC. А вот откуда твои дровишки? Кто тебе сказал, что они не хотели совместимости? Может они просто не в сила были ее обеспечить...

ПК> В 1990 еще стандарта и в помине не было.

С++ был. СТЛ был. Так что уже можно было начинать дружить со Страуструпом.

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

Цитаты, плиз. А то я тоже много чего слышал.

ПК> А именно, что соответствие стандарту стало приоритетным только для предпоследнего (7.0) и последнего релиза (7.1). А отношение к стандарту до этого можно легко уяснить по простому факту, что Майкрософт во времена разработки стандарта даже была исключена из списка голосующих членов комитета за пропуск нескольких заседаний.

Ну, т.е. Борлад можно считать паенькой и значит, то что они тоже не смогли создать совместимую со стандартом версию все же говорит о его сложности запутанности?

ПК>Вот беда-то какая, с цифрами снова совсем неладно. 2004 — 16 = 1988.

Сейчас почти 2005-ый. Плюсы оформились в 98 так что все ОК. Если бы МС только подправляли свой компилятор для учета текущего стандарта, то мы умели бы полноценный компилятор уже в лице VC 1.0/1.5. А VC6 вообще был бы полностью совместим со стандартом, так как вышел в том же году.

ПК>В том славном году еще даже C не был стандартизован, не то что C++.

С++ тогда появился и оформился. А С уже лет 10 как имел стандарт дефакто — K&R.

ПК> А Microsoft выпустили свою шестую версию Visual Studio в 1998 году, и в то время на стандарт, вышедший в том же году, им еще было чихать совершенно.

Им как видишь и сейчас в общем-то чихать. Они свои создают.

ПК>Следующий релиз, Visual Studio .Net 2002, был посвящен презентации .Net (не забываем и Managed extensions for C++ — это, естественно, тоже делали разработчики из команды VC++),

Да, да... согласен. Уболтал, речистый. МС контора бедная. Ей просто ресурсов не хватило сделать компилятор соотвествующий стандарту. Ну, а Борлад, Сайбес (он же PowerSoft, он же Ватком), а GCC, а все остальные? Почему появился только какой-то там незивестный на три буквый которым никто реально не пользуется?

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

И вот тут возникает вопрос. Почему такие бабки кладутся на разрботку нового языка — сишарпа, и упровляемой среды упровления? Ведь С++ так крут, что казалось бы в него то и нужно бабки вбухивать. А они так тебе. Вкладывают в "почти скриптовый" язык. Тут были товарищи сравнивающие этот язык с Питоном и метившие ему место в качестве средств написания юнит-тестов. Почему же такая странная оценка МС? Зачем они с Саном переругались только ради права улучшения ява-машины и языка Ява? К чему такие затраты?

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

ПК>Надо понимать, что история компилятора С/С++ от Microsoft насчитывает уже около 20 лет.

С больше. С++ меньше и существенно. Первый С++-компилятор МС, если мне не изменяет память, — это VC 1.0, появившийся где-то в 93-ем. Который тоже от С++ отличался очень значительно.

ПК>А остановиться, и переписать компилятор с нуля не может позволить себе даже Microsoft.

Да, ну? Боюсь, что МС под силу даже купить Страуструпа и весь С++-комитет.

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

Заметь, когда МС захотели они взяли и создали то же Шарп. Да и тот же Гейтс — это не заурядный компиляторщик.

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

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

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

Во-во. Судя по тому как спускается на тормозах C++/CLI (до сих пор приличной бэты нет). Для них и C++/CLI баловство.

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

А какие встречал? Из твоих слов можно подумать, что есть какие-то проблемы. Только я вот их почему-то не встречал. С чего бы это?

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

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

Проблемы совместимости между Моно и Дотнетом лежать совсем в других плоскостях. Они в количестве и соотвествии библиотек. Так до сих пор нет аналога ВыньФормс. А вот веб-проекты переносятся без особых проблем. Причем конкретно с языком я вообще проблем не встречал.

Так что если, они есть то милости просим дать ссылки. А иначе не стоит на них упавать.

ПК>Проблемы компиляторов C++ точно такие же проблемы "в софте".

Да? И отсуствие фич, это всего лишь ба? И то что верный код компилируется по разному? Подобных проблем я что-то в Моно и Шаре не замечал. Не верный иногда обрабатывается по разному, а вот верный вроде как без проблем.

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

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

ПК> Ключевое отличие компиляторов C++ от компиляторов C# — разница в возрасте, значение которой ты упорно не хочешь признавать или понимать.

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

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

ПК>Снова о том, "как корабли бороздят просторы космоса"?

Нет, снова о качестве языка и спецификации.

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

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

ПК>Не совсем туда смотришь. Та работа в основном была посвящена GCC, VC++ приводился в качестве сравнения.

И тем не менее ссылка классная!

>>

>> Проудкт           год выпуска   процент успешных тестов
>> VisualC++ 6.0         1998              73.6
>> VisualStudio 7.0      2000              77.1
>>

>> и того у МС просто грандиозный рывок! За 2 года аж 3.5%! Если так дело пойдет и дальше то, им осталось 6.5 лет до полного соответствия. Хотя 7.1 отличий от 7.0 практически не имеет

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

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

ПК> Два ключевых понятия, дающих представления о характере различий: частичная специализация шаблонов классов (partial specialization),
ПК>аргументно-зависимый поиск имен (ADL). По результатам тестов измерения соответствия стандарту, насколько я помню, VC++ 7.1 показывает цифры около 98%.

98% МС заявлял еще в 7.0. Теперь это уже должно быть 103%.

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

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

ПК> Но к бинарной совместимости не относящася.

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

ПК> О бинарной совместимости мы уже закончили? Примеров языков, специфицирующих эти "важнейшие аспекты построения компиляторов и рантайм-систем", приводить не будешь?

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

Так что признаем недостатком стандарта С++ отсуствие разделов говорящих о модулях и принципах компиляции с их использованием?

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

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

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

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

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

ПК> или это твое личное мнение, в обоснованиях не нуждающееся?

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

А ты берешся утверждать обратное? Или просто таким образом решил невелировать мое мнение?

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

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

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

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

ПК>Ага, уже лучше.

Ну, слава богу. Жаль, что эти слова у тебя выступают только как присказка. Хоть бы разок услышать как ты изменишь мнение.

ПК> Но и этого не достаточно: и на одной платформе проблемы точно так же могут быть.

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


>> Пашь, так сделай заявление! Одно из двух. Или проблемы есть. Или их нет. Не может же быть в данном вопросе промежуточного состояния. Сфероконики в природе не водятся.

ПК>Проблемы есть

Неможет быть? Я в это не верю..

ПК> у всех языков

фух. А я то грешным делом подумал, что ты признал очевидное. Ну, да ладно.

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

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

Так если без обобщений. Есть проблемы у С++ и его стандарта? Много ли их? Влияют ли они на качество С++ и/или стандарта?

>> Да? Я вот мне кажется, что ты уклонился от прямого вопроса. Так все же является ли качество языка следствием качества проектирования или качества языка никак не связано с качеством проектирования?

ПК>Проектирования? Конечно. Но мы говорили о стандарте.

А он не есть спецификацией рожденной в процессе проектирования?

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

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

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

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

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

ПК>Это неверный вывод.

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

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

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

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

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

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

2. Почему первых версий? На дворе Ява 1.5 (заметь, релиз!). И второй фрэймворк. Я так с бОльшим удовольствием буду сравнивать именно с последникм. И, думаю, ты догадывашся почему.

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

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

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

ПК>1) От реального компилятора C++ ты получишь предупреждение,

Не от реальных, а от некоторых, и на некотором уровен варнингов.

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

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

ПК> Это был сознательный выбор при проектировании языка.

Да? Ой как хочется услышать обоснование этой "сознательности".

ПК> Причины такого поведения можешь найти в "Дизайне и эволюции языка C++".

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

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

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

Это мнение? Или будешь подтверждать.

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

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

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

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

Здорово. Нечего сказать. А зачем тогда было курочить систему приведения типов С? В нем это можно было делать еще лучше.

Так что получается, что попытались сделать типобезопасность, но не получилось. А теперь прячемся за стандартом.

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

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

Из этих слов я делаю вывод, что ты исходиш из предположений:
1. Сто C# не имеет возможности наиболее эффективных приложений, а С++ имеет.
2. Что у C# как языка (а не конкретной реализации на CLI/дотнете и т.а.) есть какие-то особенности не позволяющие ему непосредственно общаться с аппаратной платформой.
3. Что С++ является системым языком, а не универсальным.
4. Что типобезопасность противоричит эффективности и/или системности.

Так?

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

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

Очень, очень. Там появились массив как объекты высшего порядки и т.п. Скомпилировать программу написанную с испоьзованием фич С99 нельзя ни на одном компиляторе С++.

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

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

ПК> Мнения мне не интересны.

Так не выражай их. А то никаких вот заявление выше на обоснованное утверждение не тянет.

ПК> Если у тебя есть ссылки на работы по этому поводу — милости прошу.

А иначе что? Мне вполне достаточно просто сравнить языки.

Попробуй перечислить понятие С++ отсуствующее в Шарпе. На на оборот можно делать довольно долго:

1. Свойства.
2. Итераторы.
3. События.
4. Делегаты.
5. Атрибуты.
6. Аномнимные методы.
7. forech
8. finally
9. Ссылочный тип данных.
10. Вылью-тип.
11. Базовый тип перечисления.
12. Ансэйф
13. Сборки (модули).
14. Импорт внешних функций.
15. Констрэйны.
16. Встроенные сложные объекты (массивы/строки).
17. Автоматическое управление папятью.
18. Унификация типов.
19. Индексеры.
10. Конструкторы типа.
11. Инетерфейс.
12. Наследование интерфейса.
13. Partial-типы.
14. Версионность.
15. Алисаы пространств имен.
16. Обобщенные интерфейсы и абстрактные классы.
17. Рефлекшон.
18. Enumerator.
19. Автодокументирование в коментариях.

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

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

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

ПК>Нет.

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

>> Ну, так может, ответишь на искусно обойденный вопрос о критериях сложности? Вопрос то ключевой! Критерии то бываю разные.

ПК>Да, критерии бывают очень разные. Тут мы с тобой, как мы уже выяснили, расходимся. Тебе достаточно изложенных тобой положений и субъективной их оценки для подобных сравнений, мне — нет.

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

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

>> Ответь хотя бы на вопрос почему нельзя сравнивать размеры и сложность языков?

ПК>Можно. Но не уровне субъективных критериев, без привлечения эмоций ("низводить до ничтожества"), и использования в качестве аргументов того, что требуется доказать ("несомненно проще").

А доказывать, утвердения о субективности критериев нужно? Или они и без этого весомы и верны?

ПК>Я не вижу, чтобы здесь были серьезные аргументы "явно не в пользу C++". Я вижу твои об этом заявления.

А я вижу заявления, что у меня только заявления. Что дальше?

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

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

Не одно и то же, а зависимые вещи. Неудачность языка следствие неудачности спецификации.

>> И с тем, что С++ удачный язык не требующий изменений.

ПК>Тут сразу два пункта. 1) Считать ли C++ удачным языком — зависит от того, что вкладываешь в слово "удачный".

По-моему, я уже не раз это описал.

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

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

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

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

1. Взражают.
2. Опять же каких.

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

>> Ну, и с тем "единственной задачей спецификации является точное описание языка". Спецификации порождает язык. И основная (заметь, не единственная) задача спецификации породить качественный язык с минимумом неопределенностей и проблем.

ПК>Ну, с моей точки зрения, это расходится с действительностью, т.к. те же C и C++ родились еще до соответствующих стандартов.

А с моей, снва идет подмена понятий. Спецификация была до стандарта. Так понятнее?

ПК> Соответственно, стандарт может уточнять язык, но создание языка ему предшествует.

Старая песня. Отвечать не буду.

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

ПК>Да это так. Никто и не утверждал, что это тривиальная задача.

Ну, так чем тебя тогда не устраивает мое мнение о том, что это недостаток этой спецификации?

ПК>В качестве посылки ты используешь недоказанное утверждение. А именно: "язык особой сложности не представляет".

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

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

>> Буст, Локи используют побочные эффекты этой спецификации которые она даже не декларировала.

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

Да все ты прекрасно понимашь. Эмуляция функцинальных вычислений на базе эффекта рекурсивного определения шаблона со специализацией вместо граничного условия — это как? Задумывалось ли стандартом такое поведение? Где в С++ вообще хоть слово о возможости вычислений в компайл-тайме (кроме как инициализации константными выражениями)?

>> STLport всего лишь реализация спецификации появившейся где-то в 1992.

ПК>1998.

Открываем исходник STL в VC и читаем коментарий:

/*
 * Copyright (c) 1992-2002 by P.J. Plauger.  ALL RIGHTS RESERVED.
 * Consult your license regarding permissions and restrictions.
 V3.13:0009 */

ПК>Не вполне. Хотя есть некоторые техники, позволяющие реализовать значительную часть оптимизаций STLport и на VC++6,

Оптимизации — это уже дело десятое. К нашему вопросу не относящееся.

>> Вместо boost и Loki лучше было ввести необходимые средства в язык.

ПК>Это еще один очень спорный тезис.

Ну, ты же спорить не будешь? Ведь у тебя как вседа недостаточно довыдов.

>> Про Blitz и Pooma и сегодня мало кто слышал и они мало кому нужны.

ПК>Да уж конечно. Если ты не слышал, не значит, что никто не слышал.

Можно устроить голосование и зунать какое количество слышало, какое использовало, а какое реально использует. Проводим? Или на слово поверишь?

ПК> Это именно те библиотеки, которые "порвали" Фортран в матричных вычислениях благодаря использованию template expressions.

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

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

Это не правда. Еще в МС С 4-5 были ошции совместимости стандарту. И это прекрасно работало. Я учился писать на K&R и по началу долго не мок привыкнуть к ограничениями, но тем не менее спокойно компилировал код не соотвествующий стандарту.

ПК>Включая и результат. Для меня мерилом результата является соответствие языка тем задачам, для которых он создан.

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

ПК> А то, нравится ли он всем на планете Земля или нет, мне совершенно не интересно.

Что тогда споришь?

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

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

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

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

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

Ну, поделись для каких же? Чем они другие? Пока что это чисто голословное утверждение.

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

Это не важно. По факту есть грабли обосновываемые сложностью включения опции в компилятор.

ПК>Не вопреки, а благодаря.

Может и не вопреки, но точно не благодоря. Просто стандарт тут идет по боку.

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

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

>> Еще раз. Цена вопроса — введение уровня совместимости с унаследованным кодом. А то и просто объявление наплевать и растереть. Со временем бы все подтянулись.

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

Ну, так укажи в чем и обоснуй. А то от таких слов читателю...

ПК>Задумался. Поэтому и тянули с введением этих несовместимостей.

Ну, ввели же? Так в чем проблема?

ПК>В .Net по спецификации нет проверок при выходе за границы массивов в результате адресной арифметики.

Ты прекрасно знаешь, что сама адресная арифметика существует в специально ограниченом ансэйф-контексте. И что она вообще не нужна на практике. Разве что драйверы или ОС писать. А в С++ это при работе со штатным массивом.

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

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

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

Другой. Но указатели от этого нужнее не становятся.

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

Да нифига она не другая. Это догма которую ты себе втемяшил в голову. Я тебе уже кажется предлагал ее доказать.

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

ПК>Это не замена.

Это именно замена. Об этом говорили авторы языков в которых эта замена появилась. Так что не надо.

ПК> Это для других вещей.

Это каких же?

ПК> Весь C++ изначально предназначен именно для того, для чего в C# создан unsafe.

Во оно как? Можно поинтересоваться что-то такого шешь сейчас или писла ранее, для чего тебе так дико были необходимы грабли?

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

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

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

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

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

Ага. Я даже знаю как их зовут... Мазохисты.

ЗЫ

После появления человеческих средств мета-программировни, АОП и улучшения качества оптимизации кода, я вообе не дам за С++ и ломоного гроша в прикладной области. Ну, а для жизни на грани системной он еще долго протянет.