Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> Так что ПК практически доказал, что спецификация Шарпа сложнее чем С++-ная.
ПК>Нет.
Нет?
А это можно считать утверждением? Или — это просто так... частное мнение? Ну, то которое ничем не подтверждено и значимость которого стремится к нулю...
Утверждение? Ну, тогда докажи его!
ПК> Только то, что объем спецификации языка C# не меньше, чем объем спецификации языка C++.
А каковы твои критерии сложности языка?
ПК>О сложности я ничего не говорил.
Ну, то есть про сложность ты вообще ничего сказать не можешь, а возражаешь против чужого мнения, просто ради борьбы за справедливость и торжество сферокоников?
Или давай уж определимся с критериями и выясним этот вопрос уровне цифр (типа объективно). Или ты признаешь, что в данном вопросе может существовать только субъективное мнение, и то, что мое субъективное мнение никак не может быть ущербным. А так же признаешь, что все твои возражения и попытки нивелировать мое мнение всего лишь некорректные приемы дискуссии, основанные на том, что мое частное мнение не совпадает с твоим точно таким же частным.
Мое мнение очень просто. C++ более сложный язык с точки зрения изучен, и использования. Но боле просто с технической токи зрения. В общем, практически парадокс если не считать, что сложным в изучении и использовании его делает непродуманность — усеянность граблями (во многом порожденная желанием сохранить совместимость с С), нестыковки в спецификации (то самое неопределенное поведение) и отчасти нежелание принимать авторами языка прогрессивных веяний времени.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>Да, стандарт C++ нельзя рассматривать в отрыве от части стандарта C. На соответствующие пункты стандарта C в теле стандарта C++ есть прямые ссылки. Если интересно, можешь посчитать, сколько в результате получится страниц. Правда, в основном большая часть будет относиться к библиотеке.
> Дык как же тогда ты умудряешся сравнивать стандарт С++ без С и стандарт Шарпа но с BCL?
Уфф... Там, где я сравнивал стандарты C++ и C#, я это делал без библиотек. Соответственно, без ссылок на стандарт C и стандарт CLI.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК> Только то, что объем спецификации языка C# не меньше, чем объем спецификации языка C++.
> А каковы твои критерии сложности языка?
На точно такой же вопрос я тебе уже отвечал.
> ПК>О сложности я ничего не говорил.
> Ну, то есть про сложность ты вообще ничего сказать не можешь, а возражаешь против чужого мнения, просто ради борьбы за справедливость и торжество сферокоников?
Нет, просто если я не располагаю точной информацией, то и заявлений по этому поводу, соответственно, не делаю. Еще раз: увидев твое утверждение о большей проработанности стандарта C#, я подумал, что ты не просто так это говоришь, а обладаешь какой-то более-менее точной информацией. Нет — ну и ладно. Неинформированные мнения мне мало интересны.
> Или давай уж определимся с критериями и выясним этот вопрос уровне цифр (типа объективно). Или ты признаешь, что в данном вопросе может существовать только субъективное мнение, и то, что мое субъективное мнение никак не может быть ущербным. А так же признаешь, что все твои возражения и попытки нивелировать мое мнение всего лишь некорректные приемы дискуссии, основанные на том, что мое частное мнение не совпадает с твоим точно таким же частным.
У меня нет по этому поводу мнения, т.к. недостаточно информации для его составления. О чем я сразу, собственно, и сказал
Имхо, главным критерием качества проработки собственно стандарта является количество его разночтений разными разработчиками: чем этих разночтений меньше, тем стандарт проработаннее. Скажем, для того же C# мне пока сложно об этом судить, т.к. еще не видно сколько-нибудь значительного количества проектов, использующих разные его реализации.
Поэтому странно говорить о несовпадении твоего мнения с моим (отсутствующим). Еще интереснее твои обвинения меня в некорректности ведения дискуссии. Для утверждения о последнем нужно, по крайней мере, привести ссылки на конкретные сообщения с указанием конкретных приемов. Впрочем, можешь не трудиться, мне это уже мало интересно.
Разве что какие-то сколько-нибудь объективные данные о количестве и характере дефектов в стандарте C# найдешь... Вот это было бы намного интереснее.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> Ну, те кто не видел "описания" STL мож даже подумать, что между "Перечислением" библиотек Шарпа и "описанием" STL есть огромная разница.
Конечно, есть. Для STL есть полное описание семантики всех функций. Плюс, там, где нужно, указание временной сложности алгоритмов. Из перечисления функций об этом можно только догадываться, что на спецификацию никак не тянет.
> Плюс что-то я не помню в плюсовом стандарте описания CRT. Оно тоже видимо вынесено в отдельный документ (спецификацию С).
Да, конечно. Извини, но странно, что, ты берешься сравнивать стандарты, этого не зная.
> Дык описание STL не долеко от него ушло. Учитывая полному имен, коментарии и общую логичность библиотек для использования этого достаточно.
Ты что, серьезно? Никакие имена и "общая логичность" библиотек не заменят полноценную спецификацию. О комментариях я бы в данном случае вообще не упоминал бы, т.к. в них только namespace. В общем, проще ограничиться примером:
// Namespace: System.Threading, Library: BCLpublic sealed class Monitor
{
public static void Enter(object obj);
public static void Exit(object obj);
public static void Pulse(object obj);
public static void PulseAll(object obj);
public static bool TryEnter(object obj);
public static bool TryEnter(object obj, int millisecondsTimeout);
public static bool TryEnter(object obj, TimeSpan timeout);
public static bool Wait(object obj, int millisecondsTimeout);
public static bool Wait(object obj, TimeSpan timeout);
public static bool Wait(object obj);
}
Ты утверждаешь, что семантика данного класса достаточна для реализации независимыми разработчиками без дополнительной спецификации?
> А сравнивать качество описания библиотек в "дополнительном стандарте" и то, что входит в стандарт плюсов просто нельзя. Это все равно что книга против ее реферата.
Мне война мнений и упражнения в риторике не интересны, так что развивать эту тему я не буду. Разве что ты захочешь свое это мнение аргументировать, используя общепринятые правила логики... Но почему-то после предыдущей дискуссии я в этом сомневаюсь.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
>>> Какова цель спецификации языка?
> ПК>Как и у любой спецификации: точно (насколько возможно полно и непротиворечиво) описать предмет спецификации, т.е. язык.
> Можно назвать успешным описание С++ если МС, Борланд и пр. не могут реализовать этот стандарт?
Могут. Но пока не реализовали. И вовсе не из-за того, что язык плохо специфицирован, а из-за маркетинговых соображений: были заняты другим.
Borland, насколько мне известно, купил front end у EDG. Это означает, что Borland в следующем релизе, если у них там спецы в состоянии справиться с тем, что сделал один Грег Камю, будет поддерживать стандарт полностью, включая export (*) (насколько вообще возможно полное соответствие какому-либо стандарту).
В Microsoft до недавнего времени на стандарт плевали с высокой колокольни, и занялись поддержкой оного, когда увидели, что это становится, действительно, важным для их пользователей. Разница между VC++6.0/VC++7.0 и VC++7.1 в отношении поддержки стандарта радикальная. Когда у меня была возможность пообщаться с командой VC++ в апреле, они сказали, что в VC++8.0 особых продвижек в отношении степени поддержки стандарта не будет, т.к. все их силы направлены на C++/CLI. Поднимать соответствие стандарту планируется в следующем после Whidbey релизе.
Другой большой игрок на этом поле, GCC, уже соответствует стандарту в очень большой степени, пожалуй, за исключением некоторых тонкостей, не имеющих серьезного значения для практической работы.
В общем, если уж EDG, где работает всего несколько человек, были в состоянии сделать компилятор, полностью поддерживающий стандарт, то и другим компаниям это под силу. Вопрос только в том, насколько это компаниям было нужно.
Сегодня стало нужно.
>>> Т.е. несовместимость между Борлад С++ и VC++ — это проблемы языка, а не его стандарта?
> ПК>Если речь идет о разной трактовке некоторых языковых конструкций, то в подавляющем большинстве случаев это проблемы реализаций, нарушающих стандарт.
> Так почему же реализации Явы и Шарпа трактуют конструкции одинаково, а С++-а по разному. Может быть все же в этом виновата именно спецификация?
Относительно реализаций Шарпа у меня достаточной информации нет. То, что мне удалось найти, говорило о том, что не так уж и одинаково. Но, похоже, точно еще ничего не известно, т.к. нет достаточного использования одними и теми же проектами разных реализаций. Поживем — увидим.
Относительно же Java, боюсь тебя разочаровать, но спецификация там далеко не везде точная, и разница между реализациями есть, причем в фундаментальных и простых моментах, таких как контроль доступа к членам классов и т.п. Например, вот одна из соответствующих работ: http://www.cis.nctu.edu.tw/~wuuyang/papers/CTHPC2002ambiguities.pdf
> Может быть она излишне запутана, противоричива или еще что-то?
В C++ дело не в качестве спецификации, а в том, что, как уже говорилось, на момент выхода стандарта уже было значительное количество кода, написанное под реализации, созданные еще до выхода стандарта, плюс сами реализации.
Проще говоря, стандарт немного запоздал. И, соответственно, компании-разработчики не торопились дорабатывать свои компиляторы ввиду обратной совместимости, и отсутствия достаточных стимулов для этой доработки.
Теперь ситуация значительно изменилась, соответствие стандарту стало важным, и разработчики компиляторов и стандартных библиотек стремительно дорабатывают свои продукты. Динамику этого можно видеть, например, в работе: http://www.cs.clemson.edu/~malloy/projects/ddj/paper.pdf С тех пор, имхо, ситуация еще значительно улучшилась, но я некоторое время за соответствующими исследованиями не следил.
> Понятно, что она может быть написана без ошибок, и в ней может быть учтено все что только можно. Только при этом она будет противоричива, запутана или приводить к диким временным затратам на семантический анализ. Все это брак.
Пожалуй, единственная, действительно, сложно поддающаяйся проверке вещь, это ODR (One Definition Rule). Но это никак не связано с качеством спецификации. Это следствие одного из требований к языку, совместимости с C на уровне модели трансляции и компоновщика.
> ПК> Если речь идет о бинарной совместимости порождаемых объектных файлов, то это не является проблемой ни языка, ни стандарта — это вещи, которые отданы на откуп реализациям, точно так же, как, скажем, способ, каким пользователь указывает компилятору каталоги для поиска заголовочных файлов и т.п.
> Самому то не смешно? В спецификации не оговорены важнейшие аспекты построения компиляторов и рантайм-систем.
Нет, не смешно. Эти моменты опускают почти (?) все известные мне стандарты языков, работающих непосредственно с аппаратной платформой. Может, тебе известен хотя бы один стандарт кросс-платформенного языка (работающего непосредственно с платформой, без прокладки типа JVM или .Net), который специфицирует эти подробности?
> Это приводит к физической несовместимости компиляторов. Это не доработки. Это уже дырища.
Это следствие кроссплатформенности. С этим сложно (невозможно?) что-то сделать. Как ты себе представляешь бинарную совместимость между объектными файлами для x86 и, скажем, Macintosh?
>>> Ну, и еще один вопрос. Судя по твоим переключением стрелок на язык ты считашь, что С++ плохо спроектированный язык с хорошей спецификацией. Так?
> ПК> Не так.
> Как же не так? Тут у тебя явные не соотвестия. По твоим словам, у стандарта проблем нет.
Этого я не говорил.
> У языка теже.
И этого тоже.
Я только сказал, что названные тобой "проблемы" ни к проблемам стандарта, ни к проблемам языка не относятся.
> А результат мягко говоря кривоватый.
Мягко говоря, спорный момент.
> Когда мы говорили о проблемах спецификации ты кивл на язык и говоришь, что мол проблемы его.
Этого я тоже не говорил. Ты, вероятно, спутал моменты, когда я утверждал что некоторые из твоих реплик не относятся к обсуждению качества стандарта, а относятся к обсуждению языка. Утверждений о наличии или отсутствии проблем, насколько я помню, я не делал.
> ПК> Под качеством проектирования языка я подразумеваю соответствие результата сформулированным требованиям к языку
> То есть качество получившегося языка тут как бы и не причем?
Ты вырезал фразу из контекста.
> ПК> плюс, в рамках этих требований — соблюдение "общих" принципов проектирования языка.
> То есть все что угодно, но не качество результата?
Это и есть "качество результата". Я ж, вроде, даже ссылки на книги дал, чтобы можно было подробнее посмотреть.
>>> И очень интересно каковы твои критерии определения сложности языка?
> ПК> Количество разных понятий, которыми язык оперирует.
> Ну, по количеству понятий Шарп даже первой версии значительно превосходит плюсы. Причем даже версии 1.0. А уж 2.0...
Это снова личное мнение, или же тебе известны какие-нибудь серьезные данные по этому поводу? Заметь, я не утверждаю ни что C# проще, чем C++, ни что он сложнее. Только отмечаю, что я не видел подобных данных.
> Хотя конечно установление зависимости между сложностью языка и возможностью сравнения спецификаций, мяго говоря, необоснованно.
Размеров спецификаций.
>>> Если на базе этого описания у десятка серьезных и очень богатых контор не удается создать компиляторы которые одинаково интерпреритруют исходный код, то я назывю такой стандарт не качественным. > > ПК>Это уже намного ближе. > > К чему? Что у спецификации есть какие-то иные цели кроме описания языка?
Вот и мне удивительно, с чем же ты тогда споришь, если согласен, что единственной задачей спецификации является точное описание языка...
> ПК> Теперь осталось поправить "не удается" на "до сих пор не сделали"
> Это дно и тоже. На сегодня нет. Значит не удается.
Не значит. Тут очевидная логическая брешь. Из отсутствия чего-либо невозможность этого не следует. Более того, разработчикам из EDG, компании значительно меньшего размера, чем Borland или, тем более, Microsoft, это удалось за вполне приемлемое время. Свои соображения относительно того, почему компиляторы Borland и Microsoft не соответствуют стандарту, я уже изложил.
> ПК> и проанализировать, почему это так: из-за качества стандарта, либо же из-за других причин. К последним в данном случае можно отнести существование множества реализаций еще до создания стандарта,
> Да? Во оно как? Попробуй обосновать это утверждение.
Компании-разработчики компиляторов делают компилятор совместимым со стандартом не просто так, а потому что это нужно их пользователям. Некоторое время назад, для пользователей более важной была совместимость со своим старым кодом, чем со стандартом. По мере развития библиотек, использующих все большее количество возможностей, описанных в стандарте (boost, Loki, Blitz, Pooma, STLport и т.п.), у пользователей появились потребности в большем соответствии компиляторов стандарту. Соответственно, чаша весов "соответствие старому коду" — "соответствие стандарту" начала перевешиваться в сторону последнего.
Очень многие моменты, в которых компиляторы не соответствовали стандарту, вызваны именно историческими причинами, тем, что эти возможности уже были реализованы в компиляторах, и менять их без достаточных оснований разработчики не хотели (см. также свежий пример ниже).
> ПК> плюс множество проблем, связанных с обратной совместимостью с кодом, написанным под реализации, не соответствующие стандарту.
> И это тоже.
> Я лично не вижу никакой зависимости между совместимостью и соотвествием стандартов. Тот же МС ввел пару тройку ключей компилятора и проблемы совместимости решились. Но VC как не был совместим со стандартом, так и не совместим.
VC++ значительно продвинулся в этом отношении. Но ты серьезно недооцениваешь влияние обратной совместимости. Скажем, даже вполне очевидные и легкие в исправлении несоответствия стандарту, разработчики VC++ подчас отказываются исправлять именно из-за нарушения обратной совместимости с существующим кодом. Простой пример.
В режиме межфайловой оптимизации VC++ может объединять специализации шаблонов, что в результате приводит к тому, что адреса разных специализаций шаблонов оказываются одинаковыми — стандарт явным образом это запрещает. Простым вариантом, позволяющим сохранить данную оптимизацию, плюс сделать компилятор более соответствующим стандарту, было бы в случае взятия адреса подобной специализации выдавать адрес специальной функции, состоящей из одного jmp на соптимизированную специализацию. Так бы и овцы были бы целы (требование стандарта было бы соблюдено), и волки были бы сыты (оптимизация бы работала, как задумано).
Однако разработчики VC++ отказались от такого варианта именно на основании того, что может существовать код, который предполагает, что по адресу функции находится непосредственно ее реализация.
> Возьмем например экспорт шаблонов. Чистейшей воды профанация, так как как их не экспортируй, а проблемы шаблонов и препроцесор не позволяют создать приемлемой промежцточной формы для подобного экспорта.
Позволяют. Хотя я вполне разделяю скептическое отношение к экспорту шаблонов.
> Теперь сравни это решение с теми же дженириками в дотнете и попробуй после этого утвержадать, что решения выбранные в С++ были глубоко продуманными,
Все известные мне решения были вполне глубоко продуманными. В том смысле, что никакие из них не принимались без обсуждения и взвешивания альтернатив. В некоторых решениях были допущены ошибки. Но это справедливо и для любого другого языка, тем более, имеющего столь продолжительную историю развития.
> а спецификация непротиворичивой.
> Ясно как божий день, что сложность реализации на практике проистикает из-за проблем спецификации. Просто проблемы бывают разного рода. Ты почему-то недоговоренности в виде неопределенного поведения
Еще раз: неопределенное поведение это не недоговоренности. Все случаи явно продекларированного неопределенного поведения, которые я анализировал, были приняты вполне сознательно. Это не "недоговоренности", это проектные решения, проистекающие из свойств языка и его истории.
Яркий пример, скажем, та же проверка выхода за границы массивов. Потребовать этой проверки стандарты C и C++ физически не могли из-за наличия большого количества реализаций, которые этого не делали, и которые просто проигнорировали бы подобное требование стандарта, а вместе с ним и весь стандарт. Кроме исторических причин есть и другие: не всегда накладные расходы проверок выхода за пределы массивов допустимы по тем или иным причинам.
Соответственно, оба стандарта были специально написаны так, чтобы ее допускать, но не требовать.
И реализации C или C++, проверяющие выход за границы массивов вполне возможны (и существуют). Как это делать, и почему этого не делают популярные реализации, уже в этом форуме описывалось.
Если бы, например, те же указатели в нынешнем виде были из C или C++ удалены, это было бы спецификацией совсем других языков. Качество (точность) же самих спецификаций при этом не обязательно бы изменилось.
(*) "Фича", конечно, сомнительной нужности и очень большой сложности в реализации, и я не обижусь, если те же Microsoft ее реализовывать не будут. Но реализовать можно. Было бы желание.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
P.S.
>> ПК> Если речь идет о бинарной совместимости порождаемых объектных файлов, то это не является проблемой ни языка, ни стандарта — это вещи, которые отданы на откуп реализациям, точно так же, как, скажем, способ, каким пользователь указывает компилятору каталоги для поиска заголовочных файлов и т.п.
>> Самому то не смешно? В спецификации не оговорены важнейшие аспекты построения компиляторов и рантайм-систем.
> Нет, не смешно. Эти моменты опускают почти (?) все известные мне стандарты языков, работающих непосредственно с аппаратной платформой. Может, тебе известен хотя бы один стандарт кросс-платформенного языка (работающего непосредственно с платформой, без прокладки типа JVM или .Net), который специфицирует эти подробности?
Посмотрел в стандарт C# по этому поводу. Насколько я понял, он формат сборки тоже оставляет за кадром. Так что в этом отношении и в спецификации этого языка "не оговорен важнейший аспект построения компиляторов и рантайм-систем"
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
V>>Что значит "лучше"?
VD>
ЛУЧШЕ. 1. см. хороший. 2. в знач. сказ., кому. Об улучшении состояния больного. Ребенку сегодня л. 3. вводн.сл. и частица. Предпочтительнее, вернее. Говори или, л., я? Л. не рисковать. Л. и не спорь. * А лучше сказать, в знач. союза — вводит уточнение, а вернее сказать. Он умен, а лучше сказать осмотрителен. Лучше всего, вводи, ел. — то же, что лучше (в 3 знач.). Давай поговорим или, лучше всего, помолчим. Как нельзя лучше — очень хорошо, отлично. Дела идут как нельзя лучше. И того лучше (ещё того лучше) (обычно ирон.) — совсем хорошо.
и? какую из форм и применимых оборотов ты имел ввиду? пока не одна не подходит для рассматриваемого вопроса и тем более под твои утверждения...
V>> Как можно сравнивать спецификации космического корабля и одноместного самолета?
VD>Некорректная аналогия. Тут сравниваются спецификации импиративных языков объектно ориентированного программирования общего назначения. Они более чем сравнимы.
Во-первых — разного назначения. (!!! хотя и используют похожие подходы)
Ввиду того, сравнимы только в области пересечения, которая невелика.
V>> Количество потенциальных неувязок в первом случае гораздо больше. VD>Демагогия на базе некорректной аналогии.
уже пояснил свою аналогию, где говорилось о различном назначении, но похожем подходе для достижения целей. Первый случай потенциально опасней, сложней и т.д.
V>>Спецификация C# действительна очень проста,
VD>Для тех кто ее не читал. Рельно она понятна и не противоричива, но не проста. Это довольно объемный и не простой документ. Проста она только в сравнении с запутанной и противоричивой.
Читал внимательно и неоднократно. Она проста не только (не столько) в сравнении со сложной, сколько из-за синтаксиса самого языка и предполагаемой техники компиляции/сборки (!!!). Компилятор C# изначально многопроходный, в идеале — сколь угодно проходный. Компилятор С++ изначально расчитан на ограниченное число проходов (язык организован так, что вполне позволяет обойтись одним — по историческим причинам, ты помнишь мощность своего десктопа в 1990-м? а объем его оперативки? он бы просто не смог скомпилировать более-менее сложную программу на C#)
Если ты в курсе проблем С++, то многие потенциальные неоднозначности как раз связаны с одинаковым синтаксисом объявления и определения. Первой конструкции в C# нет из-за упомянутой техники компиляции.
Далее, C# разработан из предположения, что никак не зависит от архитектуры платформы, на которой исполняется. C# использует общую систему типов, которая не зависит от разрядности применяемой платформы. Многие UB в С++ (ты упоминал их наличие) именно отражают тот факт, что язык С++ предназначен в качестве "родного" для целевой платформы, т.е. должен оперировать родными типами целевой платформы. Явно упомянутые UB отражают те моменты, которые могут быть не переносимы м/у платформами (в виду характера этих платформ).
Хотя, никто не запрещает проводить произвольную реинтерпретацию участков памяти, даже в случае потенциального UB. ПОЧТИ все системные программы очень низкого уровня (дрова и пр.) используют моменты, которые могут быть расцененены как UB в общем случае, но весьма подходят для частной платформы. Тут мы видим наследие языка С, который суть одно сплошное UB , однако в С++ оставлены те же возможности и механизмы их реализаций, что и в С, что позволяет использовать С++ в тех областях, где раньше был применим С (а до него ASM).
В C# возможна реинтерпретация памяти только в p-Invoke, где тоже элементарно получить UB в случае ошибки описания предполагаемой бинарной структуры ожидаемого типа. В самом же C# реинтерпретации памяти нет, в подобных случая применяет конструирование нового объекта требуемого типа — суть копирование памяти. В случае написания системного ПО — шаг весьма сомнительной необходимости.
V>> сам язык гораздо проще. VD>Тоже, скажем, так сомнительное утверждение. Со многих точек зрения C# сложнее С++.
Тоже, скажем, так сомнительное утверждение. Ты неоднократно говорил о том, что C# сложнее С++. Я хочу узнать, наконец, в чем именно? (условия конкурса — речь не о .Net, а именно о C#, предлагаю обсудить возможности тех же дженериков и шаблонов, и посмотреть количество приемов разработки, которые позволяют эти варианты, причем на С++ будут рассматриваться только варианты без UB )
VD>При том. Качественнее. На меньшем количестве страниц дано более сбалансированное и логичное описание. Нет такого количества пробелем и т.п.
Тааак, вот это мы приплыли. Качество ПО — это степень соответствия его требованиям.
Качество ПО (Вендров, Липаев)
совокупность свойств ПО, к-рые характеризуют способность ПО
удовлетворять заданным требованиям.
или еще более общее определение:
Качество (Розова, "Упрвление качеством")
совокупность характеристик объекта, относящихся к его способности
удовлетворять обусловленные или предполагаемые потребности.
...Каждая потребность выражается рядом требований, которые
участвуют в формировании отношений пригодности объекта
для целей потребителя, служат для оценки соответствия
объекта его назначению...
Требования к качеству (Розова, "Управление качеством")
* можно определить как выражение определенных потребностей или
их перевод в набор количественно или качественно установленных
требований к характеристикам объекта с целью их воплощения в
объекте
V>>Спецификация VB.Net еще проще... VD>Опять неправда. Спецификация VB.Net приблизительно равна по объему и сложности Шарповой.
Она чуть-меньше, но сути это не меняет. Речь о том, что существуют языки с еще меньшей спецификацией, но это не говорит о том, что они "лучше" или "хуже". (уверен, что спецификация языка LOGO меньше. Спецификация того Basic, что был на ZX-Spectrum еще меньше и т.д. Сказать, что эти языки некачественные — некорректно. Они отлично отлично соответствовали своим требованиям и являлись лучшим из вариантов в своей области применения)
VD>Вот тут Re[16]: Качество стандар
ты выступал за обоснование любых утверждений. В данном сообщении ты наделал кучу ничем не подтвержденных (а реально ошибочных) утверждений. Поробуй их обосновать. Ну, ради хохмы.
Тебе бы все хохмить. Чтобы утверждать ошибочность утверждений, надо их хотя бы пытаться опровергать.А если же просто не согласен, можно ограничиться постом "не согласен". Или минусы ставить.
Здравствуйте, VladD2, Вы писали:
VD>Сравнил количество страниц занимаемых граматиками языков. VD>
VD>C++ 685-667 = 18
VD>C# 461-433 = 28
VD>
VD>Так что на языке сухих цифр C# на 30% сложнее C++. VD>А народ с дури думает, что Шарп учить проще.
Влад, ты же разбираешься в этом вопросе, а жонглируешь...
Ты забыл оценить мощность порождаемого грамматикой множества выражений.
Все зависит от грамматики (от характера правил). Чем больше в ней ограничений (и больше ее размер), тем меньше может быть мощность допустимых выражений (и тем проще учить язык).
-------
Изучить язык — это не столько выучить грамматику, сколько научиться "разбирать" или "порождать" выражения языка.
-------
Потрачу на досуге время, посмотрю как именно описаны грамматики. (может, в случае С++ была возможно ввести больше промежуточных обощающих символов, и потому удалось компактней ее записать, а в C# есть доп. ограничивающие ключевые слова, делающие это невозможным)
Здравствуйте, vdimas, Вы писали:
V>Влад, ты же разбираешься в этом вопросе, а жонглируешь... V>Ты забыл оценить мощность порождаемого грамматикой множества выражений.
Здравствуйте, vdimas, Вы писали: V>Влад, ты же разбираешься в этом вопросе, а жонглируешь... V>Ты забыл оценить мощность порождаемого грамматикой множества выражений.
Здравствуйте, vdimas, Вы писали:
V>Компилятор C# изначально многопроходный, в идеале — сколь угодно проходный. Компилятор С++ изначально расчитан на ограниченное число проходов (язык организован так, что вполне позволяет обойтись одним — по историческим причинам, ты помнишь мощность своего десктопа в 1990-м? а объем его оперативки? он бы просто не смог скомпилировать более-менее сложную программу на C#)
Какой из этого следует вывод?
V>Тут мы видим наследие языка С, который суть одно сплошное UB , однако в С++ оставлены те же возможности и механизмы их реализаций, что и в С, что позволяет использовать С++ в тех областях, где раньше был применим С (а до него ASM).
Какой из этого следует вывод?
V>В C# возможна реинтерпретация памяти только в p-Invoke,
И в unsafe mode.
V> где тоже элементарно получить UB в случае ошибки описания предполагаемой бинарной структуры ожидаемого типа.
Например? Особенно интересны элементарные случаи. На всякий случай — P/Invoke это safe механизм.
VD>>Тоже, скажем, так сомнительное утверждение. Со многих точек зрения C# сложнее С++. V>Тоже, скажем, так сомнительное утверждение. Ты неоднократно говорил о том, что C# сложнее С++. Я хочу узнать, наконец, в чем именно?
Например в количестве стандартных синтаксических конструкций. А ты думал что С++ во всем сложнее щарпа? На всякий случай — я не утверждаю что один язык безоговорочно сложнее другого, это утверждение неверно в оба конца.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, vdimas, Вы писали:
V>>Влад, ты же разбираешься в этом вопросе, а жонглируешь... V>>Ты забыл оценить мощность порождаемого грамматикой множества выражений.
AVK>Что такое мощность?
совокупность всех допустимых цепочек, порождаемых правилом/системой правил.
---------
в С++, например, невозможно определить семантику такого выражения:
xxx yyy(zzz);
т.е. в зависимости от контекста, это может быть или объявление сигнатуры ф-ии либо инициализация переменной yyy значением переменной zzz.
тут как-то на rsdn было обсуждение насчет класса грамматики — контекстно свободная или контекстно-зависимая. Пришли к тому, что КЗ.
КЗ стоят на вершине иерархии Холмского:
регулярные -> КС -> КЗ.
однако, КЗ грамматики обычно очень компактны в записи, именно из-за того, что одно и то же выражение может трактоваться по разному, в зависимости от контекста, т.е. можно ввести доп. промежуточные символы для краткости записи.
------
1. Все продукции грамматики типа 1, или грамматики контекстно-зависимой, контекстной, имеют вид [...]
2. Грамматика типа 2, или контекстно-свободная грамматика, — это грамматика [...]
3. Все продукции грамматики типа 3, регулярной грамматики [...]
С ростом номера уменьшается общность грамматики. Это значит, что при всех i (i=0,1,2) имеются языки, описываемые грамматикой типа i, но не типа i+1. Язык принадлежит типу самой простой из описывающих его грамматик.
Контекстно-зависимые грамматики и грамматики с фразовой структурой в иерархии Хомского [...]. Хотя языки, определяемые грамматиками этих типов, являются более мощными, в то же время они сложнее для понимания, анализа и практического использования.
Языки программирования: разработка и реализация. Т. Пратт, М. Зелковиц
В моделирование синтаксиса естественных языков для задач автоматического синтаксического анализа наиболее распространёнными являются формальные системы, относящиеся к одному из следующих классов:
· Регулярные грамматики – используются только для упрощенного анализа (shallow parsing), в общем случае не могут быть задействованы в качестве базового формализма системы полноценного синтаксического парсинга.
· Контекстно-свободные грамматики – используются достаточно широко, однако в чистом виде также непригодны для полноценного анализа, так как их мощности недостаточно для работы с синтаксическими явлениями, характеризующимися наличием нелокальных связей [...]
· Мягко контекстно-зависимые грамматики – будучи несколько более мощными, чем КС-грамматики, грамматики данного класса позволяют анализировать большинство типов синтаксически релевантных нелокальных связей.
здесь
Разработка системы автоматического синтаксического анализа на основе мягко контекстно-зависимой унификационной грамматики
Александр Перекрестенко
Институт проблем информатики РАН
Здравствуйте, AndrewVK, Вы писали:
V>>Компилятор C# изначально многопроходный, в идеале — сколь угодно проходный. Компилятор С++ изначально расчитан на ограниченное число проходов (язык организован так, что вполне позволяет обойтись одним — по историческим причинам, ты помнишь мощность своего десктопа в 1990-м? а объем его оперативки? он бы просто не смог скомпилировать более-менее сложную программу на C#)
AVK>Какой из этого следует вывод?
Ты хоть намекни, какой следует вывод у тебя.
V>>Тут мы видим наследие языка С, который суть одно сплошное UB , однако в С++ оставлены те же возможности и механизмы их реализаций, что и в С, что позволяет использовать С++ в тех областях, где раньше был применим С (а до него ASM).
AVK>Какой из этого следует вывод?
Что применим до сих пор, и будет еще долго применим, для реализации того же дотнет на различных платформах
V>> где тоже элементарно получить UB в случае ошибки описания предполагаемой бинарной структуры ожидаемого типа.
AVK>Например? Особенно интересны элементарные случаи. На всякий случай — P/Invoke это safe механизм.
C# не гарантирует расположение полей в run-time.
для "надежности" расположение можно описать аттрибутами, но эта аттрибутика не описываема в грамматике языка.
я тоже в С++ пользуюсь #pragma pack(xxx) и избегаю последствий UB точно таким же приемом. Просто, в случае С++ никто не стесняется говорить о возможном UB.
struct A { int i; }
struct B { int i; }
A* a = new A;
B* b = (B*)a;
будет работать? — будет.
однако UB в общем случае.
VD>>>Тоже, скажем, так сомнительное утверждение. Со многих точек зрения C# сложнее С++. V>>Тоже, скажем, так сомнительное утверждение. Ты неоднократно говорил о том, что C# сложнее С++. Я хочу узнать, наконец, в чем именно?
AVK>Например в количестве стандартных синтаксических конструкций. А ты думал что С++ во всем сложнее щарпа?
А почему бы не подсчитать семантические?
добрая чать этих "стандартных синтаксических конструкций" относится к особенностям единой системы типов.Net и аттрибутики.
В MC++ этих дополнительных нетовских конструкций как минимум не меньше, и плюс весь остальной язык.
(тут вообще прикол получается. грамматика C# завязана на конкретные типы из .Net, аттрибуты управляют программой. допустимые и применимые аттрибуты в граматике не опишешь, налицо некий разрыв и опора просто на спецификации и идентификаторы "специальных" типов/аттрибутов)
AVK>На всякий случай — я не утверждаю что один язык безоговорочно сложнее другого, это утверждение неверно в оба конца.
Ну хорошо, а субъективно как?
Я на С++ хрен его знает сколько, и порой открываю интересные трюки (читай — нахожу доп. выразительные ср-ва языка, способные сэкономить трудоемкость).
В C# въехал сразу, но выразительности не хватает. (хотя она окупается гигантскими всеобъемлющими библиотеками поддержки)
Собственно, я рассматриваю C# как удобный интрфейс к этим библиотекам.
Плюсовики признают, "нам бы такие всеобъемлющие библиотеки", базара не было бы ни о чем
Да, ас C# — это тонкий знаток дотнета, ас С++ — тонкий знаток языка.
Здравствуйте, VladD2, Вы писали:
VD>К сожелению, общая грамотность людей на форумах не очень высока. И подобные приемы частенько проходят, причем проходят на ура. Вот почитай на досуге http://blacklight.h1.ru/oppo09.htm там многие из этих примемов описаны.
Вряд ли ты полностью избежишь этих приемов. Если это кому-то удасться — никто не будет читать rsdn.ru форумы.
Как я могу отказать себе в таком начале предложения: "очевидно, ...".
Или как ты можешь отказаться от возможности додумать за оппонента и доказывать его неправоту. (ссылки не приведу, ворошить старое — грех, да и скучное это занятие)
Если от всего этого отказаться, то форум превратиться в голый обмен только лишь "подтвержденными" фактами. Тогда даже ссылок мало будет, ибо ссылка не обязательно является достоверным фактом, желательно будет несколько ссылок и т.д. и т.п.
Разумеется, подобный маразматический сценарий никто не рассматривает. Тут вопрос гораздо более приземленного житейского плана. Ты говоришь о грамотности, я бы лучше заговорил о культуре. В споре необходимо поддерживать паритет с собеседником, например, если ты просишь обосновать мнение оппонента, и он это делает, будет вполне "политкорректно" поступать аналогично. Простое признание — "нет аргументов", куда как культурнее, чем "они тут и нахрен не сдались (аргументы)".
Здравствуйте, Павел Кузнецов, Вы писали:
>> Можно назвать успешным описание С++ если МС, Борланд и пр. не могут реализовать этот стандарт?
ПК>Могут. Но пока не реализовали. И вовсе не из-за того, что язык плохо специфицирован, а из-за маркетинговых соображений: были заняты другим.
А, ну, да. С 1989-го года времени не хватает.
ПК>Borland, насколько мне известно, купил front end у EDG.
То есть сдался. Давай называть вещи своими именами. А что касается EDG — то вроде как он довольно медленнен и еще бабка на двое сказала, чем все это кончится.
Хотя весело буедет если все купят одну реализацию. Тогда твои слова о возможности множества реализаций будут очень кстати.
ПК> Это означает, что Borland в следующем релизе, если у них там спецы в состоянии справиться с тем, что сделал один Грег Камю, будет поддерживать стандарт полностью, включая export (*) (насколько вообще возможно полное соответствие какому-либо стандарту).
Какому либо может и можно. А вот этому очень сомнительно.
ПК>В Microsoft до недавнего времени на стандарт плевали с высокой колокольни, и занялись поддержкой оного, когда увидели, что это становится, действительно, важным для их пользователей.
Да то, что это важно для пользователей они поняли еще гду в 90-ом. Вот только сложно это неимоверно. Уж больно много проблем.
ПК> Разница между VC++6.0/VC++7.0 и VC++7.1 в отношении поддержки стандарта радикальная.
Ага. Только для этого им пришлось купить отдельного специалиста, так как свои что-то не очень справлялись. Видимо тупые. Стандарт прочесть не могут.
ПК> Когда у меня была возможность пообщаться с командой VC++ в апреле, они сказали, что в VC++8.0 особых продвижек в отношении степени поддержки стандарта не будет, т.к. все их силы направлены на C++/CLI.
Ну, и как, по-твоему, можно назвать хорошим стандарт на реализацию которого у багатейшей конторы в мире не хватает сил вот уже 16 лет?
ПК> Поднимать соответствие стандарту планируется в следующем после Whidbey релизе.
Ага. Им как раз тогда больше заняться нечем будет. У них как раз Лонгхор с Оркасом в 2006-ом. И есть планы переписывать ту же студию в менеджед-код.
ПК>Другой большой игрок на этом поле, GCC, уже соответствует стандарту в очень большой степени, пожалуй, за исключением некоторых тонкостей, не имеющих серьезного значения для практической работы.
Да для практики не имеют значения и все что не реализовано в VC 7.1. Один фиг все ведущие библиотеки под него и GCC затачиваются. Вот только у тех кто делает стандарт так и не возникло мысли привести его к этой самой практике. А то и еще больше упростить, чтобы на его реализацию не требовалось 16 лет и покупки супер-спецов.
ПК>В общем, если уж EDG, где работает всего несколько человек, были в состоянии сделать компилятор, полностью поддерживающий стандарт, то и другим компаниям это под силу. Вопрос только в том, насколько это компаниям было нужно.
Вопрос скорее в квалификации и упертости спецов. Ну, и вопрос в том, что это за спецификация такая которую не очень то охотно поддерживают.
ПК>Сегодня стало нужно.
Так почему же 16 лет было не нужно?
>> Так почему же реализации Явы и Шарпа трактуют конструкции одинаково, а С++-а по разному. Может быть все же в этом виновата именно спецификация?
ПК>Относительно реализаций Шарпа у меня достаточной информации нет.
Ну, скачай Моно погляди. У них с cs.exe совместимость даже бинарная. Ошибки правда есть у обоих компиляторов. Но одинаковый код они воспринимают одинаково.
ПК> То, что мне удалось найти, говорило о том, что не так уж и одинаково.
Не правду говоришь. То что ты смог найти — это описание трудностей связанных с бинарной реализацией. Оной в С++ вообще не существует. Так что и сравнивать нечего. А вот со спецификацией языка проблем ты так и не нашел. Я правда знаю по одной у каждого из компиляторов. Можно слишком вольно трактует глобальные атрибуты (может найти их черти где) — это проблема Yacc-а используемого ими. А у МС есть забавнейшая проблема с интерпретацией констант при некотором стечении обстоятельств. Но это все. Причем это именно ошибки в софте, а не проблемы стандарта. Ту же Моновскую багу я лично обошел. Может быть есть еще что-то неоткрытое, но с проблемами компиляторов С++ это ни в какое сравнение не идет. Оными забиты все форумы.
ПК> Но, похоже, точно еще ничего не известно, т.к. нет достаточного использования одними и теми же проектами разных реализаций. Поживем — увидим.
Да есть. Почти все проекты создаваемые для Моно проверяются на дотнете. Да и сам Моно прекрасно компилируется на дотнете — это просто огромный проект.
ПК>Относительно же Java, боюсь тебя разочаровать, но спецификация там далеко не везде точная, и разница между реализациями есть, причем в фундаментальных и простых моментах, таких как контроль доступа к членам классов и т.п. Например, вот одна из соответствующих работ: http://www.cis.nctu.edu.tw/~wuuyang/papers/CTHPC2002ambiguities.pdf
Да, такие бы проблемы плюсам и глядишь Явы бы и на свет не появилось бы.
>> Может быть она излишне запутана, противоречива или еще что-то?
ПК>В C++ дело не в качестве спецификации, а в том, что, как уже говорилось, на момент выхода стандарта уже было значительное количество кода, написанное под реализации, созданные еще до выхода стандарта, плюс сами реализации.
А. Ну, да. Именно это и помешало МС за 16 лет реализовать стандарт. Гы-гы.
Продумывание грамотной интеграции конечно в задачи тех, кто придумывал язык и писал его спецификацию не входило. Логично.
ПК>Проще говоря, стандарт немного запоздал. И, соответственно, компании-разработчики не торопились дорабатывать свои компиляторы ввиду обратной совместимости, и отсутствия достаточных стимулов для этой доработки.
Сильно же они не торопились. Стандарт в сегодняшнем виде существует с 1998-го.
ПК>Теперь ситуация значительно изменилась,
Оно и понятно. На С++ пишется все ольше и больше кода. Конкуренты вымирают пачками...
ПК> соответствие стандарту стало важным, и разработчики компиляторов и стандартных библиотек стремительно дорабатывают свои продукты. Динамику этого можно видеть, например, в работе: http://www.cs.clemson.edu/~malloy/projects/ddj/paper.pdf С тех пор, имхо, ситуация еще значительно улучшилась, но я некоторое время за соответствующими исследованиями не следил.
Да, да. Ценная ссылка. Какой рывок совместимости!
Проудкт год выпуска процент успешных тестов
VisualC++ 6.0 1998 73.6
VisualStudio 7.0 2000 77.1
и того у МС просто грандиозный рывок! За 2 года аж 3.5%! Если так дело пойдет и дальше то, им осталось 6.5 лет до полного соответствия. Хотя 7.1 отличий от 7.0 практически не имеет, да и по твоим словам 8.0 тоже иметь особо не будет.
>> Понятно, что она может быть написана без ошибок, и в ней может быть учтено все что только можно. Только при этом она будет противоречива, запутана или приводить к диким временным затратам на семантический анализ. Все это брак.
ПК>Пожалуй, единственная, действительно, сложно поддающаяйся проверке вещь, это ODR (One Definition Rule). Но это никак не связано с качеством спецификации. Это следствие одного из требований к языку, совместимости с C на уровне модели трансляции и компоновщика.
Ага. Во всем виноват С. Причем виноват на столько, что из одного из самых простых языков (это я о С) С++ превратился в один из самых сложных. Вот парадокс? И самое парадоксальное, что из-за отсутствия совместимости и сложности реализации переносимые системы так и пишут на С. Просто таки не С, а какой-то демон.
>> Самому то не смешно? В спецификации не оговорены важнейшие аспекты построения компиляторов и рантайм-систем.
ПК>Нет, не смешно. Эти моменты опускают почти (?) все известные мне стандарты языков, работающих непосредственно с аппаратной платформой. Может, тебе известен хотя бы один стандарт кросс-платформенного языка (работающего непосредственно с платформой, без прокладки типа JVM или .Net), который специфицирует эти подробности?
Гы. Оберон. Хотя вроде D, Модула, Дельфи и его куча разных языков. Не обязательно же описывать все? Но вопрос модулей, их загрузки и т.п. охватывают многие более современные языки. Да что там далеко ходить? Я тут видел соответствующий запрос в стандарт С++.
>> Это приводит к физической несовместимости компиляторов. Это не доработки. Это уже дырища.
ПК>Это следствие кроссплатформенности.
От (!) опять парадокс. У Явы и дотнета с ней родимой куда лучше, а модули описаны. Даже Delphi перетащили под Линукс, а ведь и в ней модули описаны.
ПК> С этим сложно (невозможно?) что-то сделать. Как ты себе представляешь бинарную совместимость между объектными файлами для x86 и, скажем, Macintosh?
А не нужна бинарная совместимость для разных платформ. Нужно ввести в стандарт понятие модуля, метаданных и других вещей. Тогда подобных проблем или вообще не будет, или не будет хотя бы на одной платформе.
>> Как же не так? Тут у тебя явные не соотвестия. По твоим словам, у стандарта проблем нет.
ПК>Этого я не говорил.
От тебе раз. А о чем ты говорил? Столько всего сказал, а ничего не говорил.
>> У языка теже.
ПК>И этого тоже.
Значит таки есть? Причем и у языка, и у стандарта? Или этого ты тоже не говорил?
ПК>Я только сказал, что названные тобой "проблемы" ни к проблемам стандарта, ни к проблемам языка не относятся.
Да конечно. А к чему же они тогда относятся. Или это как в том анекдоте. Ж..а есть, а слова нет?
>> А результат мягко говоря кривоватый.
ПК>Мягко говоря, спорный момент.
Давно ясно, что язык напичкан граблями и проблемами. Но всегда найдутся люди, которым приятнее закрыть глаза.
>> Когда мы говорили о проблемах спецификации ты кивл на язык и говоришь, что, мол, проблемы его.
ПК>Этого я тоже не говорил.
Ну, т.е. ты говорил только, что ничего не знаешь? Типа проблемы есть, но они точно не спецификации, и точно не языка. Изумительно!
ПК> Ты, вероятно, спутал моменты, когда я утверждал что некоторые из твоих реплик не относятся к обсуждению качества стандарта, а относятся к обсуждению языка. Утверждений о наличии или отсутствии проблем, насколько я помню, я не делал.
Пашь, так сделай заявление! Одно из двух. Или проблемы есть. Или их нет. Не может же быть в данном вопросе промежуточного состояния. Сфероконики в природе не водятся.
>> ПК> Под качеством проектирования языка я подразумеваю соответствие результата сформулированным требованиям к языку
>> То есть качество получившегося языка тут как бы и не причем?
ПК>Ты вырезал фразу из контекста.
Да? Я вот мне кажется, что ты уклонился от прямого вопроса. Так все же является ли качество языка следствием качества проектирования или качества языка никак не связано с качеством проектирования?
>> ПК> плюс, в рамках этих требований — соблюдение "общих" принципов проектирования языка.
>> То есть все что угодно, но не качество результата?
ПК>Это и есть "качество результата". Я ж, вроде, даже ссылки на книги дал, чтобы можно было подробнее посмотреть.
А какое отношение качество результата имеет к библиографическим книгам?
Из твоих слов можно сделать вывод, что С++ вообще нельзя сравнивать с другими языками, так как он делался для удовлетворения желаний Страуструпа.
Между тем и С++, и любой другой универсальный ИЯ создавались только лишь для одного — для того чтобы писать на нем программы. И качество языка можно без каких бы то ни было ссылок сравнивать с другим качеством другого.
В общем, не нужно юлить. Скажи честно, что ты понимаешь, что сравнение качества С++ более современными языками будет явно не в его пользу. И именно по этому вся чески избегаешь этих сравнений.
А ведь все так просто. Берем типобезопасность. Струструп утверждал, что одна из целей преследовавшийся при создания С++ была создать язык более типобезопасный нежели С. Давай сравним его успехи в этой области и успехи того же Шарпа. Пишем:
int i = 2;
if (i == true)
...
получаем сообщение об ошибке в Шарпе и более чем странное поведение в С++. И это есть типобезопасность?
Идем дальше:
double d = 123;
int * p = (int*)&d;
printf("%d", i);
ах неопределенное поведение? А почему в Шарпе сообщение об ошибке компилятора или рантайма? Что мешало сделать так же? А что мешает сделать сейчас?
Ах совместимость с С... Понятно. И ведь даже в голову не приходит, что код С и С++ может компилироваться по разным правилам. И что совместимость от этого не пострадает.
Да и о какой совместимости речь? С99 напрочь не совместим с С++. Значит совместимость не так и важна?
>>>> И очень интересно каковы твои критерии определения сложности языка?
>> ПК> Количество разных понятий, которыми язык оперирует.
>> Ну, по количеству понятий Шарп даже первой версии значительно превосходит плюсы. Причем даже версии 1.0. А уж 2.0...
ПК>Это снова личное мнение,
Ага. Мнение. Это только у тебя его не бывает.
ПК> или же тебе известны какие-нибудь серьезные данные по этому поводу?
Гы. А ты не заметил, что в Шарпе на треть больше конструкций и сложнее синтаксис?
ПК> Заметь, я не утверждаю ни что C# проще, чем C++, ни что он сложнее. Только отмечаю, что я не видел подобных данных.
Так все же утверждал? Ну, так может, ответишь на искусно обойденный вопрос о критериях сложности? Вопрос то ключевой! Критерии то бываю разные. Бывают синтаксические. Тут Шарп значительно сложнее С++ и спорить бесполезно. Достаточно подсчитать количество конструкций. Бываю, субъективные. Их, правда, ты всячески пытаешься низвести до ничтожества, но тем не менее простота изучения именно субъективный критерий. Причем очень важный критерий. Тут Шарп несомненно проще. Доказательством тому является то почему народ переходит с С++ на Шарп и с какой легкостью это происходит (а языки, то сильно разные).
Ну, что у нас там осталось? Семантика? Да тут Шарп тоже сложнее. Потому и описательная часть стандарта больше.
Что же остается? А остается как раз качество языка/стандарта (называй, как хочешь). Те самые фишки вроде неопределенного поведения, неописанных в стандарте или описанных поверхностно двусмысленностей. Неразумных предпочтений. Запутанности синтаксиса. И все это как раз и есть результат непродуманности языка/спецификации. С 85-го года на это времени не хватило.
>> Хотя конечно установление зависимости между сложностью языка и возможностью сравнения спецификаций, мягко говоря, необоснованно.
ПК>Размеров спецификаций.
Хотя ты всячески клонишь к тому, что и спецификации сравнивать нельзя. Ну, да фиг с ним. Ответь хотя бы на вопрос почему нельзя сравнивать размеры и сложность языков?
Почему ты всячески избегаешь любых сравнений (особенно если они явно не в пользу С++)?
>>>> Если на базе этого описания у десятка серьезных и очень богатых контор не удается создать компиляторы которые одинаково интерпретируют исходный код, то я называю такой стандарт не качественным. >> >> ПК>Это уже намного ближе. >> >> К чему? Что у спецификации есть какие-то иные цели кроме описания языка?
ПК>Вот и мне удивительно, с чем же ты тогда споришь, если согласен, что единственной задачей спецификации является точное описание языка...
С тем, что спецификация С++ удачная. И с тем, что С++ удачный язык не требующий изменений. Ну, и с тем "единственной задачей спецификации является точное описание языка". Спецификации порождает язык. И основная (заметь, не единственная) задача спецификации породить качественный язык с минимумом неопределенностей и проблем.
>> ПК> Теперь осталось поправить "не удается" на "до сих пор не сделали"
>> Это дно и тоже. На сегодня нет. Значит не удается.
ПК>Не значит.
Значит. Как бы тебе не хотелось чтобы было по другому.
ПК> Тут очевидная логическая брешь.
Тут с логикой все ОК. Высказывание делается на сегодняшний день. Так что они полностью эквивалентны.
ПК> Из отсутствия чего-либо невозможность этого не следует.
А вот тут действительно очевидная логическая ошибка. Высказывание "На сегодня нет" не эквивалентно "невозможно в принципе".
ПК> Более того, разработчикам из EDG, компании значительно меньшего размера, чем Borland или, тем более, Microsoft, это удалось за вполне приемлемое время. Свои соображения относительно того, почему компиляторы Borland и Microsoft не соответствуют стандарту, я уже изложил.
Это все пустые слова. Двух компиляторов одинаково интерпретирующих исходный код нет. И скорее всего появятся таковые только когда какой-нибудь EDG начнет ОЕМить свой фронтенд.
Стало быть задачу создания качественного компилятора решить очень не просто. А так как сам язык особой сложности не представляет, то можно сделать однозначное заключение, что проблемы именно в стандарте.
>> Да? Во оно как? Попробуй обосновать это утверждение.
ПК>Компании-разработчики компиляторов делают компилятор совместимым со стандартом не просто так, а потому что это нужно их пользователям. Некоторое время назад, для пользователей более важной была совместимость со своим старым кодом, чем со стандартом. По мере развития библиотек, использующих все большее количество возможностей, описанных в стандарте (boost, Loki, Blitz, Pooma, STLport и т.п.), у пользователей появились потребности в большем соответствии компиляторов стандарту.
Забавно. Буст, Локи используют побочные эффекты этой спецификации которые она даже не декларировала. STLport всего лишь реализация спецификации появившейся где-то в 1992. Стандарт тоже появился очень давно. Самый последний только в 98-ом (я не ошибаюсь?). Прошло 16 лет с тех пор как появился С++, и только сегодня пользователи вдруг внезапно ощутили потребность в его стандарте. А ради чего? STLport отлично работает на VC6 и GCC 2.x. Вместо boost и Loki лучше было ввести необходимые средства в язык. Про Blitz и Pooma и сегодня мало кто слышал и они мало кому нужны.
ПК> Соответственно, чаша весов "соответствие старому коду" — "соответствие стандарту" начала перевешиваться в сторону последнего.
Да в сторону Шарпа с Явой она уже давно перевешивает. И чем дальше, тем больше.
ПК>VC++ значительно продвинулся в этом отношении. Но ты серьезно недооцениваешь влияние обратной совместимости. Скажем, даже вполне очевидные и легкие в исправлении несоответствия стандарту, разработчики VC++ подчас отказываются исправлять именно из-за нарушения обратной совместимости с существующим кодом. Простой пример.
ПК>Однако разработчики VC++ отказались от такого варианта именно на основании того, что может существовать код, который предполагает, что по адресу функции находится непосредственно ее реализация.
Пример никуда не годный, так как банальное выключение оптимизации должно привести к соответствию стандарту. В VC хватает куда более явных несоответствий.
ПК>Позволяют. Хотя я вполне разделяю скептическое отношение к экспорту шаблонов.
Чтобы они действительно позволяли, нужно серьезно ограничить шаблоны. А то и отказаться от идеи разрешения двусмысленностей на базе анализа типов (как в Шарпе). А тогда придется думать о серьезной доработки языка (если не охота остаться без поклонников).
Учитывая же что без изменения языка от экспорта шаблонов реальных преимуществ будет получить трудно. И учитывая те сложности которые возникают при реализации этого дела, реализовать эту фичу можно только из принципа. А подобное требование стандарта кроме как дополнительной трудностью назвать нельзя.
ПК>Все известные мне решения были вполне глубоко продуманными. В том смысле, что никакие из них не принимались без обсуждения и взвешивания альтернатив.
А если все же смотреть не на процесс, а на результат?
ПК> В некоторых решениях были допущены ошибки.
Я бы сказал, что "во многих".
ПК> Но это справедливо и для любого другого языка, тем более, имеющего столь продолжительную историю развития.
В таких объемах не для многих. Пожалуй что С++ тут один из лидеров. Хотя С конечно фаворит.
ПК>Еще раз: неопределенное поведение это не недоговоренности. Все случаи явно продекларированного неопределенного поведения, которые я анализировал, были приняты вполне сознательно.
Ага. Классика:
int x = i++ + ++i;
ну, куда уж было довести стандарт, чтобы в этом случае все было четко определено. Или это баги компиляторов?
ПК> Это не "недоговоренности", это проектные решения, проистекающие из свойств языка и его истории.
И то, что от подобных "проектных решений" избавляются как от вшей все мало-мальски грамотные авторы языков — это случайность? Это не проектные решения. Это именно непродуманность. Всегда проще объявить проблему не решаемой и посоветовать не наступать на грабли.
Например, возьмем автоматическое приведение инта к булеву типу и обратно. Булев тип был введен далеко не для совместимости с С. И код использующий его явно рассчитан на его поведение. Но почему же тогда было не описать какие-нибудь опции совместимости (те же прагмы) которые вводят строгую типизацию с возможностью выключать ее для унаследованного кода?
ПК>Яркий пример, скажем, та же проверка выхода за границы массивов. Потребовать этой проверки стандарты C и C++ физически не могли
Очень даже могли. Более чем могли. На сегодня даже кое-что реализовано вопреки стандарту.
ПК> из-за наличия большого количества реализаций, которые этого не делали, и которые просто проигнорировали бы подобное требование стандарта, а вместе с ним и весь стандарт.
Еще раз. Цена вопроса — введение уровня совместимости с унаследованным кодом. А то и просто объявление наплевать и растереть. Со временем бы все подтянулись. Подтянулись же до более сложных вещей. Я, например, провел два дня переписывая код проектов чтобы перейти с VC6 на VC7. А потом еще день чтобы перейти с 7.0 на 7.1. И ничего. МС даже не задумался о том, что у меня будут проблемы. А ведь могли бы хоть диагностику по приличнее сделать. А то ведь я пол дня въезжал в то, что компилятору нужно подставить typenae кое-где.
ПК> Кроме исторических причин есть и другие: не всегда накладные расходы проверок выхода за пределы массивов допустимы по тем или иным причинам.
Это чушь, а не причины. 1. Кому нужно сделали бы фичу опциональной. 2. Все современные компиляторы с успехом выносят инварианты из циклов и т.п. так что через год проблемы вообще не было бы. В том же дотнете влияния этих проверок не чувствуется.
ПК>Соответственно, оба стандарта были специально написаны так, чтобы ее допускать, но не требовать.
Да, уж. Без фактического наличия в языке массивов допускать подобное можно только для классов-оберток.
ПК>И реализации C или C++, проверяющие выход за границы массивов вполне возможны (и существуют). Как это делать, и почему этого не делают популярные реализации, уже в этом форуме описывалось.
Этот вопрос просто не был продуман. Если бы об этом задумались (кстати, похоже, в С99 таки задумались), то ввели бы четкое понятие массива, чтобы было где этот контроль осуществлять. А так, по жизни все работают с указателями, которые контролировать крайне сложно. Остается только вектор и т.п. Но к языку это уже имеет отношение отдаленное. Главное, что страдает надежность.
ПК>Если бы, например, те же указатели в нынешнем виде были из C или C++ удалены, это было бы спецификацией совсем других языков.
Гы. Вот это уже ближе к реалиям. Опять глядим на Шарп. Указатели есть, но они четко удалены в небезопасный контекст, где допустимо неопределенное поведение. И есть полноценные заменители указателей вроде массивов и ссылочных типов. Поступи похожим образом создатели С++... глядишь у Оберонщиков пропала бы столь любимая тема для обсасывания. Заметь, чуть что они сразу начинают доказывать преимущество Оберона на базе недостатков С++. Просто-таки экспонат в кунсткамере.
ПК> Качество (точность) же самих спецификаций при этом не обязательно бы изменилось.
"Точность" не единственная характеристика качества. Это ты пытаешься сделать эти понятие тождественными.
Сложность реализации, количество неопределенностей, ясность изложения наконец, все это тоже критерии измерения качества.
ПК>
ПК>(*) "Фича", конечно, сомнительной нужности и очень большой сложности в реализации, и я не обижусь, если те же Microsoft ее реализовывать не будут. Но реализовать можно. Было бы желание.
Реализовать можно все. Вот только зачем? И какой ценой?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
