Здравствуйте, VladD2, Вы писали:
VD>Итак. Я утверждаю, что требуют доказательства только не очевидные заявления сделанные в ходе логического вывода или доказательства. Все же остальные случаи являются выражением личного мения и подтверждения не требуют. В противном случае ты ставишь собеседника в очень неудобное положение. В народе это называется заставлять доказывать, что ты не верблюд.
бурные аплодисменты.
в статике это выглядит приемлимо, однако, наблюдая за динамикой дисскуссии — не очень.
бывают споры "за жисть", а бывают аргументированные обмены мнениями, если ввязался в последнее — изволь соответствовать... или не ввязываться.
VladD2,
> ПК> Количество упоминаний неопределенного поведения никак не связано с качеством проработки стандарта.
> Какова цель спецификации языка?
Как и у любой спецификации: точно (насколько возможно полно и непротиворечиво) описать предмет спецификации, т.е. язык. Применительно к стандартам языков это обычно (в зависимости от подхода, выбранного составителями спецификации) означает наличие множества требований к программе, и описание того, что последует в случае, когда программа этим требованиям соответствует.
Далее, важно проводить разделение между теми моментами, которые упущены при составлении спецификации, т.е. ситуации, для которых упущены требования (дефекты последней), и моментами, сознательно спецификацией не регулируемые, т.е. ситуации, для которых требования есть, но отсутствует описание, что последует в случае нарушения данных требований. Последние в стандартах обычно называют ведущими к неопределенному поведению.
Подчеркиваю, что неопределенное поведение не обязательно должно быть явно указано: нарушение любых требований, указанных в спецификации, если не оговорено обратное, приводит к неопределенному поведению. Вот, например, цитата из стандарта C#:
If any requirement of this International Standard is violated, the behavior is undefined.
> И может ли быть у "плохого" языка хорошая спецификация?
Конечно. Для любого языка существует гамма точности возможных его описаний. По-моему, обоснование данного момента достаточно очевидно: в любую спецификацию достаточно легко внести неточность, и наоборот, при обнаружении неточности ее можно устранить теми или иными усилиями. Впрочем, все это верно для любой спецификации, не только спецификации языка.
>>> или смотришь что в спецификации есть по работе с модулями и все становится понятно.
> ПК>То же самое. Это вопросы специфицируемого языка, а не качества проработки стандарта.
> Т.е. несовместимость между Борлад С++ и VC++ — это проблемы языка, а не его стандарта?
Если речь идет о разной трактовке некоторых языковых конструкций, то в подавляющем большинстве случаев это проблемы реализаций, нарушающих стандарт. Если речь идет о бинарной совместимости порождаемых объектных файлов, то это не является проблемой ни языка, ни стандарта — это вещи, которые отданы на откуп реализациям, точно так же, как, скажем, способ, каким пользователь указывает компилятору каталоги для поиска заголовочных файлов и т.п.
> Ну, и еще один вопрос. Судя по твоим переключением стрелок на язык ты считашь, что С++ плохо спроектированный язык с хорошей спецификацией. Так?
Не так. Под качеством проектирования языка я подразумеваю соответствие результата сформулированным требованиям к языку (анализ этих моментов для C++ можно найти в книге "Дизайн и эволюция C++"), плюс, в рамках этих требований — соблюдение "общих" принципов проектирования языка (см., например, Пратт, Зелковиц. "Языки программирования, разработка и реализация", или, на худой конец, Себеста. "Основные концепции языков программирования").
> И очень интересно каковы твои критерии определения сложности языка?
Количество разных понятий, которыми язык оперирует.
> Если на базе этого описания у десятка серьезных и очень богатых контор не удается создать компиляторы которые одинаково интерпреритруют исходный код, то я назывю такой стандарт не качественным.
Это уже намного ближе. Теперь осталось поправить "не удается" на "до сих пор не сделали" и проанализировать, почему это так: из-за качества стандарта, либо же из-за других причин. К последним в данном случае можно отнести существование множества реализаций еще до создания стандарта, плюс множество проблем, связанных с обратной совместимостью с кодом, написанным под реализации, не соответствующие стандарту.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК> Проведи небольшой поиск по словам "shifting the burden of proof", и найдешь сколько угодно подтверждений данным моим словам.
> Забавная привычка приводить ссылки на языке на котором не думаешь.
Ошибка #043 тип Shifting the burden of proof.
Допущение истинности утвеpждения, пока не доказано обpатное. Пpимеp: "Бывают зеленые сантаклаусы, синие единоpоги, зелененькие человечки в таpелочках и пауки шиpиной в земной шаp. Докажите обpатное".
> Вот тебе ссылочка на статью 49 Конституции РФ в которой как раз говорится о недопустимости переложения бремяни доказывания на обвиняемого. Как раз о той самой презумпции невиновности.
Презумпция невиновности сюда вообще никаким боком. Мы говорим об установлении истинности тех или иных утверждений, а не о чьей-то вине.
> Итак. Я утверждаю, что требуют доказательства только не очевидные заявления сделанные в ходе логического вывода или доказательства. Все же остальные случаи являются выражением личного мения и подтверждения не требуют.
Да, естественно. Я и не требую от тебя доказательств. Просто говорю о том, что неаргументированное мнение для читателя имеет пользу, стремящуюся к нулю. Впредь буду заранее уточнять, собираешься ли ты аргументировать то или иное свое спорное утверждение, или это очередное ИМХО. Или, если тебе это больше нравится, могу все твои утверждения по умолчанию считать исключительно твоим ИМХО, которое ты аргументировать не собираешься — как тебе угодно.
> В противном случае ты ставишь собеседника в очень неудобное положение.
Собеседник, делающий утверждения, которые внятно аргументировать отказывается, ставит в неудобное положение себя сам.
> В народе это называется заставлять доказывать, что ты не верблюд.
"Доказывать, что ты не верблюд" — это как раз о противоположном. Это когда кто-то делает по меньшей мере спорное утверждение, и предлагает оппонентам доказать его ложность, вместо того, чтобы самому доказывать, что оно верно.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> Какова цель спецификации языка?
ПК>Как и у любой спецификации: точно (насколько возможно полно и непротиворечиво) описать предмет спецификации, т.е. язык.
Можно назвать успешным описание С++ если МС, Борланд и пр. не могут реализовать этот стандарт?
ПК>Подчеркиваю, что неопределенное поведение не обязательно должно быть явно указано: нарушение любых требований, указанных в спецификации, если не оговорено обратное, приводит к неопределенному поведению.
Это пожалуй единственное разумное оправдание появлению неопределенного проведения. Во всех остальных местах оно является недостатком спецификации (или языка если тебе так больше нравится). Понятно, что в реальной жизни невозможно обойтись без проблем, но все же их должно быть минимум.
>> И может ли быть у "плохого" языка хорошая спецификация?
ПК>Конечно.
Тогда дальше разговаривать не о чем.
ПК> Для любого языка существует гамма точности возможных его описаний. По-моему, обоснование данного момента достаточно очевидно: в любую спецификацию достаточно легко внести неточность, и наоборот, при обнаружении неточности ее можно устранить теми или иными усилиями. ПК> Впрочем, все это верно для любой спецификации, не только спецификации языка.
Нет уж. Если спецификация порождает некачественный продукт, то это убогость этой специяикации.
В общем, как всегда ты подходишь к делу насктлько формально насколко это возможно, а именно до потери смысла обсуждаемого вопроса.
>> Т.е. несовместимость между Борлад С++ и VC++ — это проблемы языка, а не его стандарта?
ПК>Если речь идет о разной трактовке некоторых языковых конструкций, то в подавляющем большинстве случаев это проблемы реализаций, нарушающих стандарт.
Так почему же реализации Явы и Шарпа трактуют конструкции одинаково, а С++-а по разному. Может быть все же в этом виновата именно спецификация? Может быть она излишне запутана, противоричива или еще что-то? А раз так, то что же это как не убогость спецификации? Понятно, что она может быть написана без ошибок, и в ней может быть учтено все что только можно. Только при этом она будет противоричива, запутана или приводить к диким временным затратам на семантический анализ. Все это брак.
ПК> Если речь идет о бинарной совместимости порождаемых объектных файлов, то это не является проблемой ни языка, ни стандарта — это вещи, которые отданы на откуп реализациям, точно так же, как, скажем, способ, каким пользователь указывает компилятору каталоги для поиска заголовочных файлов и т.п.
Самому то не смешно? В спецификации не оговорены важнейшие аспекты построения компиляторов и рантайм-систем. Это приводит к физической несовместимости компиляторов. Это не доработки. Это уже дырища.
>> Ну, и еще один вопрос. Судя по твоим переключением стрелок на язык ты считашь, что С++ плохо спроектированный язык с хорошей спецификацией. Так?
ПК>Не так.
Как же не так? Тут у тебя явные не соотвестия. По твоим словам, у стандарта проблем нет. У языка теже. А результат мягко говоря кривоватый. Когда мы говорили о проблемах спецификации ты кивл на язык и говоришь, что мол проблемы его. А теперь и от этого отказываешся.
ПК> Под качеством проектирования языка я подразумеваю соответствие результата сформулированным требованиям к языку
То есть качество получившегося языка тут как бы и не причем?
Другими словами язык качественный если его автор (пусть даже 20 лет назад) ставил перед собой половинчатые цели. Так?
Цели создания С++ ставились 20 лет назад. На сегодня у пользователей (программистов) требуования уже сильно отличаются. Как-то странно сравнивать языки не на прямую, а по принципу соотвествия их догмам их создателей.
ПК> плюс, в рамках этих требований — соблюдение "общих" принципов проектирования языка.
То есть все что угодно, но не качество результата?
>> И очень интересно каковы твои критерии определения сложности языка?
ПК>Количество разных понятий, которыми язык оперирует.
Ну, по количеству понятий Шарп даже первой версии значительно превосходит плюсы. Причем даже версии 1.0. А уж 2.0...
Стало быть по твоим же словам сравнивать размеры спецификаций блее чем можно.
Хотя конечно установление зависимости между сложностью языка и возможностью сравнения спецификаций, мяго говоря, необоснованно.
>> Если на базе этого описания у десятка серьезных и очень богатых контор не удается создать компиляторы которые одинаково интерпреритруют исходный код, то я назывю такой стандарт не качественным.
ПК>Это уже намного ближе.
К чему? Что у спецификации есть какие-то иные цели кроме описания языка?
ПК> Теперь осталось поправить "не удается" на "до сих пор не сделали"
Это дно и тоже. На сегодня нет. Значит не удается. Не нужно пытаться жанглировать терминологией.
ПК> и проанализировать, почему это так: из-за качества стандарта, либо же из-за других причин. К последним в данном случае можно отнести существование множества реализаций еще до создания стандарта,
Да? Во оно как? Попробуй обосновать это утверждение.
ПК> плюс множество проблем, связанных с обратной совместимостью с кодом, написанным под реализации, не соответствующие стандарту.
И это тоже.
Я лично не вижу никакой зависимости между совместимостью и соотвествием стандартов. Тот же МС ввел пару тройку ключей компилятора и проблемы совместимости решились. Но VC как не был совместим со стандартом, так и не совместим.
Возьмем например экспорт шаблонов. Чистейшей воды профанация, так как как их не экспортируй, а проблемы шаблонов и препроцесор не позволяют создать приемлемой промежцточной формы для подобного экспорта. А учитывая, что большинство контор пошло по пути создания прекомпилируемых заголовочных файлов, то и смысла в этих фичах не видно.
Теперь сравни это решение с теми же дженириками в дотнете и попробуй после этого утвержадать, что решения выбранные в С++ были глубоко продуманными, а спецификация непротиворичивой.
Ясно как божий день, что сложность реализации на практике проистикает из-за проблем спецификации. Просто проблемы бывают разного рода. Ты почему-то недоговоренности в виде неопределенного поведения или черезмерную сложность за таковые считать не хочешь. А это проблемы. И очнь серьезные.
Лично я не могу отделить качество языка от качества его спецификации. Качественная спецификация порождает качественный продукт. Видимо в понимании зависимостей мы и не сходимся. Ну, да это не единственное место геде мы по разному смотрим на жизнь.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Тут можно воспользоваться твоим приечиками и спросить, а что ты понимаешь под конструктивом...
ПК>Под конструктивом в данном случае я понимаю совместные действия оппонентов, направленные на выяснение правильности той или иной точки зрения путем верификации логической цепочки, приводящей к заявленному выводу.
Ужас какой. Я то думал, что конструктив — это всего лишь плодотворный, т.е. наличие осязаемого результата.
Ну, раз это не так, то продолжим детерминировать понятия. Итак, что ты понимашь под "совместные действия оппонентов", как действия могут быть направлены на выяснения точки зрения (бить что-ли кого-то будем?), как ты себе видишь верификацию данного тобой выше определения, и почему оно не соотвествет общепринятым определениям?
>> далее довести до состояния сфероконика и обвинить тебя в чем попало.
ПК>Это еще зачем?
Хороший вопрос. Переадресую его тебе.
ПК> Это не ведет к установлению правильности или неправильности заявленной позиции, так что к "моим приемчикам" это не относится.
Именно что относится. Ты, порою, очень умело превращаешь обсуждение совершенно конкретных проблем или вещей в крайне оторванные от жизни общефилосовкие рассуждения уходящие долеко от первоначальной темы. Вот мне и интересно... зачем?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Итак. Я утверждаю, что требуют доказательства только не очевидные заявления сделанные в ходе логического вывода или доказательства. Все же остальные случаи являются выражением личного мения и подтверждения не требуют. В противном случае ты ставишь собеседника в очень неудобное положение. В народе это называется заставлять доказывать, что ты не верблюд.
V>бурные аплодисменты. V>в статике это выглядит приемлимо, однако, наблюдая за динамикой дисскуссии — не очень.
Вот и задумайся, не является ли это только ощущениями.
V>бывают споры "за жисть", а бывают аргументированные обмены мнениями, если ввязался в последнее — изволь соответствовать... или не ввязываться.
Примеры где я привел каие-то факты в качестве доказательства и отказался их объяснять? Я не хочу быть в положении оправдывающегося. Вот и все. А некоторые очень любят незаметно применить тот или иной демагогический примчик с целью поставить человека (который зачастую и собеседником то не является) в неудобное положение.
К сожелению, общая грамотность людей на форумах не очень высока. И подобные приемы частенько проходят, причем проходят на ура. Вот почитай на досуге http://blacklight.h1.ru/oppo09.htm там многие из этих примемов описаны.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Я даю ссылки на языке, на котором проще по этим ссылкам найти информацию.
Гы. Ну, так учитывай, что читающие могут быть не сильны в этом языке и в предь старайся давать информацию на языке оппонента.
ПК> Можно и по-русски: ПК>http://warrax.croco.net/46_47/errors.html ПК>
Ошибка #043 тип Shifting the burden of proof.
ПК>Допущение истинности утвеpждения, пока не доказано обpатное. Пpимеp: "Бывают зеленые сантаклаусы, синие единоpоги, зелененькие человечки в таpелочках и пауки шиpиной в земной шаp. Докажите обpатное".
Прекрасно.
1. Где ты в моих словах усмотрел "Допущение истинности утверждения"? Я выразил свое мнение. Я не утверждаю, что не ошибаюсь. Ты просто потребовал его обоснования, а я сказал, что не хочу этого делать. Далее ты добавил, что оно безапелляционное. На что я ответил, что если тебе нужно, то ты можешь опровергать его сколько влезет (т.е. апеллировать).
2. Считаешь ли ты допустимым объявлять мнение неверным, только на основании того, что человек высказавший его не хочет (или даже не может) дать полного его обоснования?
ПК>Презумпция невиновности сюда вообще никаким боком. Мы говорим об установлении истинности тех или иных утверждений, а не о чьей-то вине.
Гы. Перекладывание бремени поиска доказательств на обвиняемого (или другими словами, принуждение к оправданию) как раз и является нарушением презумпции невиновности. Ты открой ссылочку то... и поищи слова "бремя отвественности".
Ставя под сомнение чужое мнение ты обвиняешь другого человека в том, что он говорит не правду и принуждаешь его оправдываться на ровном месте. Заставляя его оправдываться ты как раз нарушаешь этот принцип.
>> Итак. Я утверждаю, что требуют доказательства только не очевидные заявления сделанные в ходе логического вывода или доказательства. Все же остальные случаи являются выражением личного мения и подтверждения не требуют.
ПК>Да, естественно. Я и не требую от тебя доказательств.
Это откровенная неправда. Ты именно вынуждаешь оправдываться. Брошенная в след фраза "а ну-ка обоснуй это мнение" ни чем иным назвать нельзя.
ПК>Просто говорю о том, что неаргументированное мнение для читателя имеет пользу, стремящуюся к нулю.
Очередная ошибка. Мнение есть мнение. Оно не обязано иметь пользу. Оно даже может быть ошибочным. Так что тут даже такие рассуждения не применимы. Да и ценность мнения отнюдь не сводится к нулю тем, что за ним не следует огромного формального доказательства его истинности. Если мнение высказывается авторитетным в некотором вопросе человеком, то оно уже будет иметь для меня ценность. Например, твое мнение о соответствии той или иной конструкции стандарту C++ для меня несомненно имеет значение. В прочем, я всегда буду допускать, что ты можешь банально ошибиться и не буду возводить твое мнение в разряд 100%-но истинных утверждений на базе которых можно построить однозначно верный логический вывод.
Так вот ты очень часто докапывашся до общих мнений. Причем зачастую вопросы по которым эти мнения высказываются просто физически сложно доказать или дать полное их обоснование. И при этом ты именно что требуешь обоснованиий, так как не получив оных ты начинаешь утверждать, что ценность такое мнение иметь не можешь (чем в общем-то оскорбляешь носителя этого мнения).
ПК>Впредь буду заранее уточнять, собираешься ли ты аргументировать то или иное свое спорное утверждение, или это очередное ИМХО.
Паша. Я уже понял, что иностранные термины для тебя намного доходчивее, нежели обычные русские слова. Запомни на будущее, что русское слово "по-моему" == дебильному транслитерированному ИМХО.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>И тем не менее это не отнимает у меня права высказывать свое мнение по этому поводу. Я не мало потрахался с обими языками и могу сказать, что качество проработки у Шапровской спецификации гораздо выше. Думаю, что в основном это именно из-за того, что сам язык лучше спроектирован. Чем меньше нестыковок, тем проще писать сеецификацию.
V>Что значит "лучше"?
ЛУЧШЕ. 1. см. хороший. 2. в знач. сказ., кому. Об улучшении состояния больного. Ребенку сегодня л. 3. вводн.сл. и частица. Предпочтительнее, вернее. Говори или, л., я? Л. не рисковать. Л. и не спорь. * А лучше сказать, в знач. союза — вводит уточнение, а вернее сказать. Он умен, а лучше сказать осмотрителен. Лучше всего, вводи, ел. — то же, что лучше (в 3 знач.). Давай поговорим или, лучше всего, помолчим. Как нельзя лучше — очень хорошо, отлично. Дела идут как нельзя лучше. И того лучше (ещё того лучше) (обычно ирон.) — совсем хорошо.
V> Как можно сравнивать спецификации космического корабля и одноместного самолета?
Некорректная аналогия. Тут сравниваются спецификации импиративных языков объектно ориентированного программирования общего назначения. Они более чем сравнимы.
V> Количество потенциальных неувязок в первом случае гораздо больше.
Демагогия на базе некорректной аналогии.
V>Спецификация C# действительна очень проста,
Для тех кто ее не читал. Рельно она понятна и не противоричива, но не проста. Это довольно объемный и не простой документ. Проста она только в сравнении с запутанной и противоричивой.
V> сам язык гораздо проще.
Тоже, скажем, так сомнительное утверждение. Со многих точек зрения C# сложнее С++.
V> При чем тут "лучше"?
При том. Качественнее. На меньшем количестве страниц дано более сбалансированное и логичное описание. Нет такого количества пробелем и т.п.
V>Спецификация VB.Net еще проще...
Опять неправда. Спецификация VB.Net приблизительно равна по объему и сложности Шарповой.
ты выступал за обоснование любых утверждений. В данном сообщении ты наделал кучу ничем не подтвержденных (а реально ошибочных) утверждений. Поробуй их обосновать. Ну, ради хохмы.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> V> При чем тут "лучше"?
> При том. Качественнее. На меньшем количестве страниц дано более сбалансированное и логичное описание. Нет такого количества пробелем и т.п.
Из твоих предыдущих объяснений я уже понял, что части "качественнее", "количество проблем", "более сбалансированное и логичное описание" — исключительно твое личное мнение, которое выражается в неформальных категориях и, соответственно, измерению не поддается. Ну что ж, так тому и быть.
Но вот часть о "меньшем количестве страниц" просто не соответствует действительности самым простым образом.
"Языковая" часть C# описывается в приведенном тобой документе (учитывая только нормативные части) начиная со страницы 1 по страницу 11 и со страницы 63 по страницу 433, что составляет 370 страниц.
"Языковая" часть C++ описывается в соответствущем стандарте начиная со страницы 1 и заканчивая страницей 317, что составляет 316 страниц. Остаток стандарта C++ — описание стандартной библиотеки, которая из стандарта C# вынесена в отдельный документ.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Из твоих предыдущих объяснений я уже понял, что части "качественнее", "количество проблем", "более сбалансированное и логичное описание" — исключительно твое личное мнение, которое выражается в неформальных категориях и, соответственно, измерению не поддается. Ну что ж, так тому и быть.
Ну, почему же? Количество проблем легко измеряется обычным подсчетом. Это ты хочешь представить так, будто их нет или невозможожно посчитать/сравнить. Заходишь на форум по соответствующему языку и начинишь считать грабли, на которые наступили люди. Статистики я не вел, но уверен, что разрыв между С++ и Шаром будет очень не маленький. И, я просто уверен, что ты и сам это знаешь очень не плохо. Грабли C++ в купе с морем неопределенностей и дали стимул для создания Явы и C#-а.
Логичность описания заключается в редком упоминании неопределенного поведения (почти полном отсутствии) и в легкости восприятия. Последнее конечно субъективная характеристика, но сути дела это не меняет.
Что же касается точных измерений, так в жизни очень малая доля явлений может быть легко переведена в язык цифр (а уж так чтобы их можно было без натяжки сравнить...). Причем обычно для таких сравнений нужно провести нехилые научные исследования. Так что для сферокоников есть хорошая почва почти везде.
ПК>Но вот часть о "меньшем количестве страниц" просто не соответствует действительности самым простым образом.
ПК>"Языковая" часть C# описывается в приведенном тобой документе (учитывая только нормативные части) начиная со страницы 1 по страницу 11 и со страницы 63 по страницу 433, что составляет 370 страниц.
ПК>"Языковая" часть C++ описывается в соответствущем стандарте начиная со страницы 1 и заканчивая страницей 317, что составляет 316 страниц. Остаток стандарта C++ — описание стандартной библиотеки, которая из стандарта C# вынесена в отдельный документ.
А что, по-твоему, находится на страницах 469-527? Где же тот непреклонный борец за формализацию все и вся? По факту в стандарте С++ более 700 страниц, в Шарповском ~530. И описание библиотек в них есть. Ну, а если подходить неформально, то неплохо бы заметить, что в стандарте C#-а описание сдублировано. Сначала идет краткое обзорное описание, а потом тоже самое раскрывается более тщательно.
Хотя конечно сравнивать "чистое описание языка" тоже разумно.
Ну, да ладно. В общем-то твое "описательное" сравнение мне даже на руку. ОК. Будь, по-твоему. Ты ведь любишь цифры? Так, давай посчитаем...
Итак, делаем поиск словосочетаний "undefined behavior" и "behavior is undefined"... и получаем:
В стандарте С++:
При этом "undefined behavior" встречается:
1 раз в оглавлении
2 раза в упоминании "Undefined behavior is indicated in this International Standard only by the words ''undefined behavior.''" (кстати, само по себе упоминание многого стоит!).
...
короче по делу реже, чем в описательном плане.
Реально все неопределенное поведение собрано в одном разделе. Вот его текст:
B.1 Undefined behavior A program that does not contain any occurrences of the unsafe modifier cannot exhibit any undefined behavior.
The behavior is undefined in the following circumstances:
1. When dereferencing the result of converting one pointer type to another and the resulting pointer is not correctly aligned for the pointed-to type. (§25.4)
2. When the unary * operator is applied to a pointer containing an invalid value (§25.5.1).
3. When a pointer is subscripted to access an out-of-bounds element (§25.5.3).
4. Modifying objects of managed type through fixed pointers (§25.6)
5. The initial content of memory allocated by stackalloc (§25.7).
6. Attempting to allocate a negative number of items using stackalloc (§25.7).
Заметь, неопределенное поведение может быть только в ансэйф-контексте!
Итого, в сухом остатке имеем около 100 против нуля (если не включать опцию поддержки unsafe-кода) или 6 (если включать)!
Вот это я называю качеством стандарта, продуманностью, логичностью и т.п. Можно ли называть все эти цифрами объективной оценкой? Конечно, нет, ведь нет проблем свести все к сфероконикам или сказать, что-то еще. Например, приплести "малое количество реальных реализаций компиляторов" и т.п. Начинай...
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Кстати, о размерах и корректности приплетения других стандатов включенный в список нормативны ссылок...
Таким образом исходя из твоей логики стандарт С++ (Гы-Гы) нельзя рассматривать в отрыве от стандарта С. Склько в нем страниц?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>"Языковая" часть C# описывается в приведенном тобой документе (учитывая только нормативные части) начиная со страницы 1 по страницу 11 и со страницы 63 по страницу 433, что составляет 370 страниц.
> ПК>"Языковая" часть C++ описывается в соответствущем стандарте начиная со страницы 1 и заканчивая страницей 317, что составляет 316 страниц. Остаток стандарта C++ — описание стандартной библиотеки, которая из стандарта C# вынесена в отдельный документ.
> А что, по-твоему, находится на страницах 469-527?
В черновике следующей версии стандарта C#? Перечисление классов (и их содержимого) стандартной библиотеки + описание Documentation comments. В "релизной" предыдущей версии стандарта обе части помечены как информативные, в черновике только вторая. Соответствующая описанию стандартной библиотеки C++ нормативная часть с определением семантики стандартной библиотеки из стандарта C# вынесена в отдельный документ:
These types and their members are listed here, in alphabetical order. For a formal definition of these types and their members, refer to ISO/IEC 23271:2002 Common Language Infrastructure (CLI), Partition IV; Base Class Library (BCL), Extended Numerics Library, and Extended Array Library, which are included by reference in this International Standard.
> Где же тот непреклонный борец за формализацию все и вся?
Не знаю. Если кому-то охота заняться развешиванием ярлыков — это не ко мне.
> По факту в стандарте С++ более 700 страниц, в Шарповском ~530. И описание библиотек в них есть.
Нет в стандарте C# спецификации библиотек. Только перечисление классов и их членов.
> Ну, а если подходить неформально, то неплохо бы заметить, что в стандарте C#-а описание сдублировано. Сначала идет краткое обзорное описание, а потом тоже самое раскрывается более тщательно.
Краткое обзорное описание является информативной частью и без потери для полноты спецификации языка может быть из стандарта выброшено, т.к. требования могут содержаться только в нормативных частях. Соответственно, информативные части я в подсчете количества страниц спецификации не учитывал.
> Итак, делаем поиск словосочетаний "undefined behavior" и "behavior is undefined"... и получаем: <> Вот это я называю качеством стандарта, продуманностью, логичностью и т.п.
Что ты называешь качеством стандарта, я уже давно понял, и давно ответил, что мне совершенно все равно, сколько упоминаний неопределенного поведения ты найдешь в стандартах, т.к. к качеству стандарта (в смысле соответствия его своей цели) это не относится. Изменив неопределенное поведение на что-то другое ты получишь просто другой язык. Полнота и точность спецификации от этого не изменятся.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, vdimas, Вы писали:
V>Спецификация C# действительна очень проста, сам язык гораздо проще. При чем тут "лучше"? V>Спецификация VB.Net еще проще...
Гы. Плюс сверху видишь? Так это ПК так свое несогласие выражает. Вот аргументация его мнения: Re[10]: Качество стандарт
Так что ПК практически доказал, что спецификация Шарпа сложнее чем С++-ная. Ну, а то что C# сложнее чем C++ легко понять просто посчитав количество конструкций языка.
ЗЫ
Если серьезно, то хорошее доказательсво тезиса о том, что простота языка заключается в простоте его восприятия, а не как не в количественных показателях. Единственный серьезный количественный показатель пожалуй — это количество граблей.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> Таким образом исходя из твоей логики стандарт С++ (Гы-Гы) нельзя рассматривать в отрыве от стандарта С. Склько в нем страниц?
Да, стандарт C++ нельзя рассматривать в отрыве от части стандарта C. На соответствующие пункты стандарта C в теле стандарта C++ есть прямые ссылки. Если интересно, можешь посчитать, сколько в результате получится страниц. Правда, в основном большая часть будет относиться к библиотеке.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В черновике следующей версии стандарта C#? Перечисление классов (и их содержимого) стандартной библиотеки + описание Documentation comments. В "релизной" предыдущей версии стандарта обе части помечены как информативные, в черновике только вторая. Соответствующая описанию стандартной библиотеки C++ нормативная часть с определением семантики стандартной библиотеки из стандарта C# вынесена в отдельный документ: ПК>
ПК>These types and their members are listed here, in alphabetical order. For a formal definition of these types and their members, refer to ISO/IEC 23271:2002 Common Language Infrastructure (CLI), Partition IV; Base Class Library (BCL), Extended Numerics Library, and Extended Array Library, which are included by reference in this International Standard.
Ну, те кто не видел "описания" STL мож даже подумать, что между "Перечислением" библиотек Шарпа и "описанием" STL есть огромная разница. Плюс что-то я не помню в плюсовом стандарте описания CRT. Оно тоже видимо вынесено в отдельный документ (спецификацию С).
>> Где же тот непреклонный борец за формализацию все и вся?
ПК>Не знаю. Если кому-то охота заняться развешиванием ярлыков — это не ко мне.
Как не к тебе? Ты с таким удовольствием этим занимашся.
>> По факту в стандарте С++ более 700 страниц, в Шарповском ~530. И описание библиотек в них есть.
ПК>Нет в стандарте C# спецификации библиотек. Только перечисление классов и их членов.
Дык описание STL не долеко от него ушло. Учитывая полному имен, коментарии и общую логичность библиотек для использования этого достаточно.
А сравнивать качество описания библиотек в "дополнительном стандарте" и то, что входит в стандарт плюсов просто нельзя. Это все равно что книга против ее реферата.
ПК>Краткое обзорное описание является информативной частью и без потери для полноты спецификации языка может быть из стандарта выброшено, т.к. требования могут содержаться только в нормативных частях. Соответственно, информативные части я в подсчете количества страниц спецификации не учитывал.
ОК. Я на это не обратил внимания.
>> Итак, делаем поиск словосочетаний "undefined behavior" и "behavior is undefined"... и получаем: <> Вот это я называю качеством стандарта, продуманностью, логичностью и т.п.
Эко ты покацал. Явно тебе не понравилось "количественное сравнение".
ПК>Что ты называешь качеством стандарта, я уже давно понял, и давно ответил, что мне совершенно все равно, сколько упоминаний неопределенного поведения ты найдешь в стандартах, т.к. к качеству стандарта (в смысле соответствия его своей цели)
Созданию дырявого языка?
ПК> это не относится.
Значит относится к качеству языка? И просто по случайности получилось, что при такой замечательной спецификации получился столь дырявый язык?
ПК> Изменив неопределенное поведение на что-то другое ты получишь просто другой язык. Полнота и точность спецификации от этого не изменятся.
Да, да. Дави на формализм. Ведь формально С++ ни счем сравнивать нельзя. У него другие цели (ну, не код же на нем писать, в самом деле?). Он особенный. Он ведь священная корова. Вот только почему? Аж, да, ведь он так тебе нравится.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Да, стандарт C++ нельзя рассматривать в отрыве от части стандарта C. На соответствующие пункты стандарта C в теле стандарта C++ есть прямые ссылки. Если интересно, можешь посчитать, сколько в результате получится страниц. Правда, в основном большая часть будет относиться к библиотеке.
Дык как же тогда ты умудряешся сравнивать стандарт С++ без С и стандарт Шарпа но с BCL? Да и в Шарповском стандарте тоже только ссылки на БЦЛ.
В общем, опять неувязочка.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Переадресую его тебе.
Да и в Шарповском стандарте тоже только ссылки на БЦЛ. 