Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Посмотрел в стандарт C# по этому поводу. Насколько я понял, он формат сборки тоже оставляет за кадром. Так что в этом отношении и в спецификации этого языка "не оговорен важнейший аспект построения компиляторов и рантайм-систем"
Оговорено понятие модульности. Импорта типов, экспотра типов. Ну, и как ты говоришь он ссылается на стандатры в которых все описано досканально.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Конечно, есть. Для STL есть полное описание семантики всех функций. Плюс, там, где нужно, указание временной сложности алгоритмов. Из перечисления функций об этом можно только догадываться, что на спецификацию никак не тянет.
Да нет там почти описания. Жаль копировать от туда не удается. А то я бы тебе привел бы простыню дклараций без единого коментария.
>> Плюс что-то я не помню в плюсовом стандарте описания CRT. Оно тоже видимо вынесено в отдельный документ (спецификацию С).
ПК>Да, конечно. Извини, но странно, что, ты берешься сравнивать стандарты, этого не зная.
Ты стрелки то не переводи. Я к тому, что с тем же успехом можно притянуть сюда объем спецификации С.
ПК>Ты что, серьезно? Никакие имена и "общая логичность" библиотек не заменят полноценную спецификацию.
То полноценную. А в плюсовом стандарте описание крайне скудное.
ПК> О комментариях я бы в данном случае вообще не упоминал бы, т.к. в них только namespace. В общем, проще ограничиться примером: ПК>
ПК>Ты утверждаешь, что семантика данного класса достаточна для реализации независимыми разработчиками без дополнительной спецификации?
А ты утверждаешь, что не понимашь что делают методы? Или утверждаешь, что из описания СТЛ можно все достконально понять?
>> А сравнивать качество описания библиотек в "дополнительном стандарте" и то, что входит в стандарт плюсов просто нельзя. Это все равно что книга против ее реферата.
ПК>Мне война мнений и упражнения в риторике не интересны,
Какие мнения? Описание СТЛ-я — это страницы голых листингов изредка разбавленные объяснениями. Вот и сравни это с описанием BCL.
ПК> так что развивать эту тему я не буду.
Правильно. И мнение не выражай. Так спокойнее.
ПК> Разве что ты захочешь свое это мнение аргументировать,
Я то агрументировал. Только кто-то упорно делает вид, что ничего не видит.
ПК> используя общепринятые правила логики... Но почему-то после предыдущей дискуссии я в этом сомневаюсь.
Изумительно! И это говорит человек трубовавший обоснования безобидным высказываниям. Изумительно! А теперь потрудись доказать, все свои обвинения. Или взять свои слова обратно.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Посмотрел в стандарт C# по этому поводу. Насколько я понял, он формат сборки тоже оставляет за кадром. Так что в этом отношении и в спецификации этого языка "не оговорен важнейший аспект построения компиляторов и рантайм-систем"
> Оговорено понятие модульности. Импорта типов, экспотра типов.
Все в пределах одной реализации. Требований к разным реализациям хранить эти данные в одном формате я не нашел.
> Ну, и как ты говоришь он ссылается на стандатры в которых все описано досканально.
Прямо он ссылается на "библиотечную" часть. Я искал в стандарте C# требования к формату сборки или что-нибудь в таком роде, пытаясь определиться со своим ответом на твой вопрос
Пока что склонен считать, что стандарт C# не требует от разных реализаций бинарной совместимости. Естественно, это будет требоваться, если они, как и майкрософтовский вариант, будут построены поверх CLI в качестве среды исполнения. Но такого требования, похоже нет.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
>>> Можно назвать успешным описание С++ если МС, Борланд и пр. не могут реализовать этот стандарт?
> ПК> Могут. Но пока не реализовали. И вовсе не из-за того, что язык плохо специфицирован, а из-за маркетинговых соображений: были заняты другим.
> А, ну, да. С 1989-го года времени не хватает.
С 1998.
> ПК> В Microsoft до недавнего времени на стандарт плевали с высокой колокольни, и занялись поддержкой оного, когда увидели, что это становится, действительно, важным для их пользователей.
> Да то, что это важно для пользователей они поняли еще гду в 90-ом.
Откуда дровишки? В 1990 еще стандарта и в помине не было. Да и прямые высказывания разработчиков и менеджеров, которым я в этом отношении склонен верить гораздо больше, говорят немного о другом. А именно, что соответствие стандарту стало приоритетным только для предпоследнего (7.0) и последнего релиза (7.1). А отношение к стандарту до этого можно легко уяснить по простому факту, что Майкрософт во времена разработки стандарта даже была исключена из списка голосующих членов комитета за пропуск нескольких заседаний.
> ПК> Когда у меня была возможность пообщаться с командой VC++ в апреле, они сказали, что в VC++8.0 особых продвижек в отношении степени поддержки стандарта не будет, т.к. все их силы направлены на C++/CLI.
> Ну, и как, по-твоему, можно назвать хорошим стандарт на реализацию которого у багатейшей конторы в мире не хватает сил вот уже 16 лет?
Вот беда-то какая, с цифрами снова совсем неладно. 2004 — 16 = 1988.
В том славном году еще даже C не был стандартизован, не то что C++. А Microsoft выпустили свою шестую версию Visual Studio в 1998 году, и в то время на стандарт, вышедший в том же году, им еще было чихать совершенно. Главными заботами были улучшение среды (маркетинг Intellisence), отладчика (Edit and continue), интеграция средств быстрой разработки интерфейсов (Wizards etc.) и т.п.
Следующий релиз, Visual Studio .Net 2002, был посвящен презентации .Net (не забываем и Managed extensions for C++ — это, естественно, тоже делали разработчики из команды VC++), и снова усилия по улучшению отладчика и значительные вложения в оптимизатор, т.к. Intel буквально наступал на пятки. Вообще, усилия разработчиков компилятора C++ с тех пор в огромной степени сосредоточены на оконечной части компилятора, т.к. это дает отдачу сразу всем компиляторным отделам Microsoft. В частности, был инициирован и активно развивается и по сейчас проект Phoenix. Плюс одной из больших задач являлось объединение прежде разобщенных сред разработки (Visual C++, Visual Basic, Interdev). А, в фоновом режиме, таки да, начались кой-какие подвижки в сторону соответствия стандарту.
Для релиза 7.1 команда VC++ сделала много чудес в плане обеспечения лучшей совместимости со стандартом, хотя и там у них было очень много других задач. Это и окончание продвижек в оптимизаторе, начатых еще во время разработки .Net 2002 (Whole program optimizations), и добавление в код некоторых проверок для контроля порчи стека и т.п. во время исполнения. И продолжение работы над объединенной средой, что потребовало очень много усилий (часть функциональности, которая была доступна разработчикам на C++ еще в VS 98 не возвращена и до сих пор).
Надо понимать, что история компилятора С/С++ от Microsoft насчитывает уже около 20 лет. Т.е., по словам разработчиков, в некоторых частях компилятора "работает" код, буквально написанный еще в те времена. Исправление некоторых даже тривиальных вещей из-за устаревшей архитектуры сильно затруднено. В частности, такой небольшой пример для некоторого понимания, насколько глубоко сидят эти проблемы:
short s = 0, s1 = 1, s2 = 2;
s += s1; // 1
s2 = s + s1; // 2
В точке (1) при некотором наборе опций компилятор выдаст предупреждение, что, мол, переменной типа short происходит присваивание значения типа int. При этом в точке (2) при тех же настройках будет тишина. (или наоборот, точно уже не помню, но это для нас сейчас совершенно не имеет значения) Отключение предупреждения во втором случае было совершенно сознательным шагом, но вот в точке (1) это оказалось сделать очень тяжело. Именно из-за того, что компилятор в этом случае идет по дорожке, проложенной еще лет 20 назад.
А остановиться, и переписать компилятор с нуля не может позволить себе даже Microsoft. Да, ребята молодцы, и делают огромную работу, и я очень ценю то, что они сделали для релиза 7.1, но еще раз хочу подчеркнуть, что информация, так сказать, из самых первых рук совершенно противоречит твоим заявлениям о незначительности обратной совместимости и давности реализаций многих аспектов компилятора.
И, как я уже говорил, для релиза 8.0 особо заметных улучшений в плане соответствия стандарту не планируется. Не потому что это сделать нельзя, а потому что есть еще много других задач, решение которых сейчас с точки зрения Майкрософт даст большую отдачу, чем "дотачивание" фронт энда. В частности, это и C++/CLI, и добавление очередных проверок времени исполнения, и улучшение отладчика, и развитие среды и т.д., и т.п.
> ПК> Поднимать соответствие стандарту планируется в следующем после Whidbey релизе.
> Ага. Им как раз тогда больше заняться нечем будет. У них как раз Лонгхор с Оркасом в 2006-ом. И есть планы переписывать ту же студию в менеджед-код.
Ну, мне гадать ни к чему. Я только передаю то, что слышал от команды VC++. Впрочем, их голоса по этому поводу тоже звучали не очень уверенно, так что, как я понимаю, с планами окончательной определенности там еще тоже нет.
> ПК> Относительно реализаций Шарпа у меня достаточной информации нет.
> Ну, скачай Моно погляди. У них с cs.exe совместимость даже бинарная. Ошибки правда есть у обоих компиляторов. Но одинаковый код они воспринимают одинаково.
Пока что, от тех, кто переносил реальные проекты, я встречал не столь оптимистичные суждения.
> Причем это именно ошибки в софте, а не проблемы стандарта. <...> Может быть есть еще что-то неоткрытое, но с проблемами компиляторов С++ это ни в какое сравнение не идет. Оными забиты все форумы.
Проблемы компиляторов C++ точно такие же проблемы "в софте". Там, где есть разное поведение, есть и указания, что должно быть по стандарту. Ключевое отличие компиляторов C++ от компиляторов C# — разница в возрасте, значение которой ты упорно не хочешь признавать или понимать.
> Продумывание грамотной интеграции конечно в задачи тех, кто придумывал язык и писал его спецификацию не входило. Логично.
Снова о том, "как корабли бороздят просторы космоса"? Может, ты все-таки перейдешь от риторики к конкретике? К примерам, приведению каких-нибудь сколько-нибудь точных результатов и т.п.?
> ПК> http://www.cs.clemson.edu/~malloy/projects/ddj/paper.pdf С тех пор, имхо, ситуация еще значительно улучшилась, но я некоторое время за соответствующими исследованиями не следил.
> Да, да. Ценная ссылка. Какой рывок совместимости!
Не совсем туда смотришь. Та работа в основном была посвящена GCC, VC++ приводился в качестве сравнения.
>
> Проудкт год выпуска процент успешных тестов
> VisualC++ 6.0 1998 73.6
> VisualStudio 7.0 2000 77.1
>
> и того у МС просто грандиозный рывок! За 2 года аж 3.5%! Если так дело пойдет и дальше то, им осталось 6.5 лет до полного соответствия. Хотя 7.1 отличий от 7.0 практически не имеет
Ты уверен, что достаточно глубоко ознакомился с предметом? VC++ 7.0 и 7.1 в плане соответствия стандарту — небо и земля. Два ключевых понятия, дающих представления о характере различий: частичная специализация шаблонов классов (partial specialization), аргументно-зависимый поиск имен (ADL). По результатам тестов измерения соответствия стандарту, насколько я помню, VC++ 7.1 показывает цифры около 98%.
> ПК> Может, тебе известен хотя бы один стандарт кросс-платформенного языка (работающего непосредственно с платформой, без прокладки типа JVM или .Net), который специфицирует эти подробности?
> Гы. Оберон. Хотя вроде D, Модула, Дельфи и его куча разных языков. Не обязательно же описывать все? Но вопрос модулей, их загрузки и т.п. охватывают многие более современные языки. Да что там далеко ходить? Я тут видел соответствующий запрос в стандарт С++.
Модули вещь хорошая. Но к бинарной совместимости не относящася. О бинарной совместимости мы уже закончили? Примеров языков, специфицирующих эти "важнейшие аспекты построения компиляторов и рантайм-систем", приводить не будешь?
>>> Это приводит к физической несовместимости компиляторов. Это не доработки. Это уже дырища.
> ПК> Это следствие кроссплатформенности.
> От (!) опять парадокс. У Явы и дотнета с ней родимой куда лучше, а модули описаны.
Тезис о лучшей кроссплатформенности (переносимости) Java и .Net подтверждать данными каких-нибудь объективных исследований будешь, или это твое личное мнение, в обоснованиях не нуждающееся? Cсылки на реальные проблемы с переносом программ на Java и .Net я приводил, так что утверждать об их отсутствии по меньшей мере некорректно.
> ПК> С этим сложно (невозможно?) что-то сделать. Как ты себе представляешь бинарную совместимость между объектными файлами для x86 и, скажем, Macintosh?
> А не нужна бинарная совместимость для разных платформ. Нужно ввести в стандарт понятие модуля, метаданных и других вещей. Тогда подобных проблем или вообще не будет, или не будет хотя бы на одной платформе.
Ага, уже лучше. Но и этого не достаточно: и на одной платформе проблемы точно так же могут быть. Вот если стандарт платформы будет регулировать ABI, то да, на этой платформе проблем не будет. Свежие примеры: .Net, IA-64.
> ПК> Ты, вероятно, спутал моменты, когда я утверждал что некоторые из твоих реплик не относятся к обсуждению качества стандарта, а относятся к обсуждению языка. Утверждений о наличии или отсутствии проблем, насколько я помню, я не делал.
> Пашь, так сделай заявление! Одно из двух. Или проблемы есть. Или их нет. Не может же быть в данном вопросе промежуточного состояния. Сфероконики в природе не водятся.
Проблемы есть у всех языков и у всех соответствующих спецификаций. И C++, и C#, и Java в этом отношении исключениями не являются. Вот только без объективных данных делать заявления о количестве искомых проблем, имхо, некорректно.
> Да? Я вот мне кажется, что ты уклонился от прямого вопроса. Так все же является ли качество языка следствием качества проектирования или качества языка никак не связано с качеством проектирования?
Проектирования? Конечно. Но мы говорили о стандарте. Напоминаю, что языки C и C++ появились и реально использовались до того, как были составлены соответствующие стандарты. Проектирование традиционно, все-таки, предшествует выпуску продукта, соответственно, проектирование языка должно было произойти до реализации компиляторов, каковая, как нам известно, предшествовала составлению стандартов.
> Из твоих слов можно сделать вывод, что С++ вообще нельзя сравнивать с другими языками, так как он делался для удовлетворения желаний Страуструпа.
Это неверный вывод.
> В общем, не нужно юлить. Скажи честно, что ты понимаешь, что сравнение качества С++ более современными языками будет явно не в его пользу. И именно по этому вся чески избегаешь этих сравнений.
Я избегаю сравнений в терминах "криво" и т.п.
> А ведь все так просто. Берем типобезопасность. Струструп утверждал, что одна из целей преследовавшийся при создания С++ была создать язык более типобезопасный нежели С. Давай сравним его успехи в этой области и успехи того же Шарпа.
С первым можно и не трудиться сравнивать: в реальных программах на C# первой версии, как и в Java, столько неизбежных приведений типов, обусловленных отсутствием параметризации, что статическая проверка отдыхает по полной программе.
> Пишем: >
> int i = 2;
> if (i == true)
> ...
>
> получаем сообщение об ошибке в Шарпе и более чем странное поведение в С++. И это есть типобезопасность?
1) От реального компилятора C++ ты получишь предупреждение, каковое, если тебе хочется, ты можешь превратить в сообщение об ошибке. Это был сознательный выбор при проектировании языка. Причины такого поведения можешь найти в "Дизайне и эволюции языка C++".
2) Это семечки по сравнению с невозможностью в C# (в том числе и, насколько я понимаю, второй версии) обеспечить тот уровень статических проверок, который легко достигается в C++. Пример тебе уже приводили: проверка размерностей в физических выражениях во время компиляции.
> Идем дальше: >
> double d = 123;
> int * p = (int*)&d;
> printf("%d", i);
>
> ах неопределенное поведение? А почему в Шарпе сообщение об ошибке компилятора или рантайма? Что мешало сделать так же? А что мешает сделать сейчас?
Ничего не мешает. Стандарт явным образом разрешает такой вариант развития событий как сообщение об ошибке во время компиляции или во время исполнения. Неопределенное поведение на конкретной платформе вполне может проявляться так, как посчитают нужным разработчики компилятора. Прецеденты подобных проверок вполне имеются.
> Ах совместимость с С... Понятно. И ведь даже в голову не приходит, что код С и С++ может компилироваться по разным правилам. И что совместимость от этого не пострадает.
Нет, в данном случае вовсе не совместимость с C, а возможность реализации наиболее эффективных приложений, непосредственно работающих с аппаратной платформой. Ты совершенно упускаешь из виду, что C++, в отличие от C#, по своему назначению является языком системного программирования.
> Да и о какой совместимости речь? С99 напрочь не совместим с С++. Значит совместимость не так и важна?
Совместимость важна. С99 не так уж и не совместим c С++, а после выхода следующей версии C++, эта разница станет еще меньше.
> ПК> или же тебе известны какие-нибудь серьезные данные по этому поводу?
> Гы. А ты не заметил, что в Шарпе на треть больше конструкций и сложнее синтаксис?
Большее количество ключевых слов или конструкций не означает большую сложность языка. Мнения мне не интересны. Если у тебя есть ссылки на работы по этому поводу — милости прошу.
> ПК> Заметь, я не утверждаю ни что C# проще, чем C++, ни что он сложнее. Только отмечаю, что я не видел подобных данных.
> Так все же утверждал?
Нет.
> Ну, так может, ответишь на искусно обойденный вопрос о критериях сложности? Вопрос то ключевой! Критерии то бываю разные.
Да, критерии бывают очень разные. Тут мы с тобой, как мы уже выяснили, расходимся. Тебе достаточно изложенных тобой положений и субъективной их оценки для подобных сравнений, мне — нет.
> Ответь хотя бы на вопрос почему нельзя сравнивать размеры и сложность языков?
Можно. Но не уровне субъективных критериев, без привлечения эмоций ("низводить до ничтожества"), и использования в качестве аргументов того, что требуется доказать ("несомненно проще").
> Почему ты всячески избегаешь любых сравнений (особенно если они явно не в пользу С++)?
Я не вижу, чтобы здесь были серьезные аргументы "явно не в пользу C++". Я вижу твои об этом заявления.
> ПК>Вот и мне удивительно, с чем же ты тогда споришь, если согласен, что единственной задачей спецификации является точное описание языка...
> С тем, что спецификация С++ удачная.
Ну, как мы выяснили, для тебя это одно и то же, что утверждение об удачности самого языка, поэтому, имхо, можно и не выделять спецификацию в отдельный пункт...
> И с тем, что С++ удачный язык не требующий изменений.
Тут сразу два пункта. 1) Считать ли C++ удачным языком — зависит от того, что вкладываешь в слово "удачный". В соответствии с моими критериями, C++ — вполне удачный язык. 2) Изменений C++ требует. Против этого, по-моему, никто и не возражает...
> Ну, и с тем "единственной задачей спецификации является точное описание языка". Спецификации порождает язык. И основная (заметь, не единственная) задача спецификации породить качественный язык с минимумом неопределенностей и проблем.
Ну, с моей точки зрения, это расходится с действительностью, т.к. те же C и C++ родились еще до соответствующих стандартов. Соответственно, стандарт может уточнять язык, но создание языка ему предшествует.
> Стало быть задачу создания качественного компилятора решить очень не просто.
Да это так. Никто и не утверждал, что это тривиальная задача.
> А так как сам язык особой сложности не представляет, то можно сделать однозначное заключение, что проблемы именно в стандарте.
В качестве посылки ты используешь недоказанное утверждение. А именно: "язык особой сложности не представляет".
> Буст, Локи используют побочные эффекты этой спецификации которые она даже не декларировала.
А именно? Конкретные примеры, пожалуйста. А то, что-то с телепатией у меня уже совсем плохо...
> STLport всего лишь реализация спецификации появившейся где-то в 1992.
1998.
> Стандарт тоже появился очень давно. Самый последний только в 98-ом (я не ошибаюсь?).
Это первый. Вторая его редакция (только исправления дефектов, без изменения семантики) — 2003.
> Прошло 16 лет с тех пор как появился С++, и только сегодня пользователи вдруг внезапно ощутили потребность в его стандарте. А ради чего? STLport отлично работает на VC6 и GCC 2.x.
Не вполне. Хотя есть некоторые техники, позволяющие реализовать значительную часть оптимизаций STLport и на VC++6, часть вещей остается недоступной, пока компилятор не поддерживает стандарт. Это и полноценная частичная специализация, и ADL, необходимый для предоставления своих функций вида swap, и многие другие "мелочи", сильно отравляющие жизнь как разработчикам библиотеки, так и ее пользователям.
> Вместо boost и Loki лучше было ввести необходимые средства в язык.
Это еще один очень спорный тезис.
> Про Blitz и Pooma и сегодня мало кто слышал и они мало кому нужны.
Да уж конечно. Если ты не слышал, не значит, что никто не слышал. Это именно те библиотеки, которые "порвали" Фортран в матричных вычислениях благодаря использованию template expressions.
> ПК>Однако разработчики VC++ отказались от такого варианта именно на основании того, что может существовать код, который предполагает, что по адресу функции находится непосредственно ее реализация.
> Пример никуда не годный, так как банальное выключение оптимизации должно привести к соответствию стандарту. В VC хватает куда более явных несоответствий.
Это пример, иллюстрирующий тем, кому это интересно, реальные причины, почему те или иные несоответствия стандарту не исправляются. Соответствие стандарту в каком-то воображаемом режиме, не используемом в реальной жизни, пользователям мало интересно.
> ПК>Все известные мне решения были вполне глубоко продуманными. В том смысле, что никакие из них не принимались без обсуждения и взвешивания альтернатив.
> А если все же смотреть не на процесс, а на результат?
Включая и результат. Для меня мерилом результата является соответствие языка тем задачам, для которых он создан. А то, нравится ли он всем на планете Земля или нет, мне совершенно не интересно.
> ПК> Еще раз: неопределенное поведение это не недоговоренности. Все случаи явно продекларированного неопределенного поведения, которые я анализировал, были приняты вполне сознательно.
> Ага. Классика: >
> int x = i++ + ++i;
>
> ну, куда уж было довести стандарт, чтобы в этом случае все было четко определено. Или это баги компиляторов?
Это совершенно сознательное решение, являющееся следствием того, как работали/работают конкретные аппаратные платформы, с которыми языки C и C++ призваны непосредственно взаимодействовать. Возможно, вследствие почти полного исчезновения таких экзотических платформ, это правило будет изменено в следующей версии стандарта.
> ПК> Это не "недоговоренности", это проектные решения, проистекающие из свойств языка и его истории.
> И то, что от подобных "проектных решений" избавляются как от вшей все мало-мальски грамотные авторы языков — это случайность?
Нет, это следствие того, что те, кого ты называешь "мало-мальски грамотными авторами языков", проектируют языки для несколько других задач.
> Например, возьмем автоматическое приведение инта к булеву типу и обратно. Булев тип был введен далеко не для совместимости с С. И код использующий его явно рассчитан на его поведение. Но почему же тогда было не описать какие-нибудь опции совместимости (те же прагмы) которые вводят строгую типизацию с возможностью выключать ее для унаследованного кода?
Для этого есть опции компилятора, которые ты вполне можешь использовать и сегодня. А создание прагм для переключения семантики языка — дело гиблое, ибо приводит к созданию диалектов, и реальным проблемам при переносе фрагментов кода из одного участка, контролируемого одними прагмами, в другой.
> ПК>Яркий пример, скажем, та же проверка выхода за границы массивов. Потребовать этой проверки стандарты C и C++ физически не могли
> Очень даже могли. Более чем могли. На сегодня даже кое-что реализовано вопреки стандарту.
Не вопреки, а благодаря. Еще раз: стандарт специально составлен так, чтобы у разработчиков компилятора была возможность реализации подобных проверок без нарушения стандарта.
> ПК> из-за наличия большого количества реализаций, которые этого не делали, и которые просто проигнорировали бы подобное требование стандарта, а вместе с ним и весь стандарт.
> Еще раз. Цена вопроса — введение уровня совместимости с унаследованным кодом. А то и просто объявление наплевать и растереть. Со временем бы все подтянулись.
Спорный вопрос. В этом пункте мнения разработчиков языка, да и мое тоже, с твоим разошлись.
> Подтянулись же до более сложных вещей. Я, например, провел два дня переписывая код проектов чтобы перейти с VC6 на VC7. А потом еще день чтобы перейти с 7.0 на 7.1. И ничего. МС даже не задумался о том, что у меня будут проблемы.
Задумался. Поэтому и тянули с введением этих несовместимостей.
> ПК> Кроме исторических причин есть и другие: не всегда накладные расходы проверок выхода за пределы массивов допустимы по тем или иным причинам.
> Это чушь, а не причины. 1. Кому нужно сделали бы фичу опциональной.
Это другой подход. Разработчики стандарта предпочитают, чтобы проверки были опциональными. Если разработчики компиляторов поголовно будут их реализовывать по запросам пользователей, тогда проверки станут обязательными в стандарте.
> 2. Все современные компиляторы с успехом выносят инварианты из циклов и т.п. так что через год проблемы вообще не было бы. В том же дотнете влияния этих проверок не чувствуется.
В .Net по спецификации нет проверок при выходе за границы массивов в результате адресной арифметики.
> А так, по жизни все работают с указателями, которые контролировать крайне сложно. Остается только вектор и т.п. Но к языку это уже имеет отношение отдаленное. Главное, что страдает надежность.
Это проблемы тех, кто работает с указателями. Никто их к этому не принуждает. Вот такая, быть может, не нравящаяся тебе философия языка.
> ПК> Если бы, например, те же указатели в нынешнем виде были из C или C++ удалены, это было бы спецификацией совсем других языков.
> Гы. Вот это уже ближе к реалиям. Опять глядим на Шарп. Указатели есть, но они четко удалены в небезопасный контекст, где допустимо неопределенное поведение. <...>
У C# совсем другая объектная модель, чем у C++. Это совсем другой язык, похожий на C++ только синтаксисом. У C++ другая, хотя частично и пересекающаяся с C#, область применения.
> И есть полноценные заменители указателей вроде массивов и ссылочных типов.
Это не замена. Это для других вещей. Весь C++ изначально предназначен именно для того, для чего в C# создан unsafe. Весь. И отлично с этим справляется. Его использование для более прикладных задач требует большей квалификации, чем использование C#. Но некоторые вполне согласны заплатить эту цену за большие выразительные возможности языка, и находят его использование для прикладных задач вполне удобным.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК>Конечно, есть. Для STL есть полное описание семантики всех функций. Плюс, там, где нужно, указание временной сложности алгоритмов. Из перечисления функций об этом можно только догадываться, что на спецификацию никак не тянет.
> Да нет там почти описания.
"Не нашел" еще не значит "нет" Все классы, типы и функции STL имеют описание.
> Жаль копировать от туда не удается. А то я бы тебе привел бы простыню дклараций без единого коментария.
Смотри на следующие или предыдущие страницы. Если назовешь номер главы и/или укажешь, простыню объявлений чего ты увидел, я скажу, где искать к этому спецификацию.
>>> Плюс что-то я не помню в плюсовом стандарте описания CRT. Оно тоже видимо вынесено в отдельный документ (спецификацию С).
> ПК> Да, конечно. Извини, но странно, что, ты берешься сравнивать стандарты, этого не зная.
> Ты стрелки то не переводи. Я к тому, что с тем же успехом можно притянуть сюда объем спецификации С.
Можно. Если ты захочешь сравнить размер спецификаций полностью, включая описание библиотек — естественно.
> ПК> Ты что, серьезно? Никакие имена и "общая логичность" библиотек не заменят полноценную спецификацию.
> То полноценную. А в плюсовом стандарте описание крайне скудное.
Достаточное для точной реализации. В противном случае приводи конкретные примеры недостаточно точных описаний.
> ПК> О комментариях я бы в данном случае вообще не упоминал бы, т.к. в них только namespace. В общем, проще ограничиться примером: > ПК>
> ПК>Ты утверждаешь, что семантика данного класса достаточна для реализации независимыми разработчиками без дополнительной спецификации?
> А ты утверждаешь, что не понимашь что делают методы?
Я утверждаю, что здесь не указано множество необходимых для реализации моментов: что в точности делают эти функции, бросают ли они исключения, если да, то какие и при каких условиях, каковы их пред- и постусловия.
> Или утверждаешь, что из описания СТЛ можно все достконально понять?
По меньшей мере перечисленные выше моменты — да.
>>> А сравнивать качество описания библиотек в "дополнительном стандарте" и то, что входит в стандарт плюсов просто нельзя. Это все равно что книга против ее реферата.
> ПК> Мне война мнений и упражнения в риторике не интересны,
> Какие мнения? Описание СТЛ-я — это страницы голых листингов изредка разбавленные объяснениями.
Все необходимые для реализации объяснения для каждого класса, типа и функции, представлены. Объем для спецификации достоинством не является. Главное — однозначность и непротиворечивость трактовок.
> Вот и сравни это с описанием BCL.
Пока что я не убежден в безусловных преимуществах последней. Скажем, модель тех же контейнеров у меня, мягко говоря, восторга не вызвала. Я не собираюсь критиковать BCL, просто отмечаю, что мое сравнение, сделанное по твоему предложению, твоих выводов не подтвердило.
> ПК> Разве что ты захочешь свое это мнение аргументировать, <...> используя общепринятые правила логики... Но почему-то после предыдущей дискуссии я в этом сомневаюсь.
> Изумительно! И это говорит человек трубовавший обоснования безобидным высказываниям. Изумительно! А теперь потрудись доказать, все свои обвинения. Или взять свои слова обратно.
Я не требую от тебя формального доказательства. Только прошу логичной аргументации чем-нибудь кроме твоих впечатлений.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
заметил, что один интересный пункт пропустил.
> Возьмем например экспорт шаблонов. Чистейшей воды профанация, так как как их не экспортируй, а проблемы шаблонов и препроцесор не позволяют создать приемлемой промежцточной формы для подобного экспорта.
> ПК> Позволяют. Хотя я вполне разделяю скептическое отношение к экспорту шаблонов.
> Чтобы они действительно позволяли, нужно серьезно ограничить шаблоны.
Пожалуйста, перечисли, что именно не позволяет в шаблонах создать приемлемую промежуточную форму, и что является приемлемой промежуточной формой?
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, vdimas, Вы писали:
V>>>Компилятор C# изначально многопроходный, в идеале — сколь угодно проходный. Компилятор С++ изначально расчитан на ограниченное число проходов (язык организован так, что вполне позволяет обойтись одним — по историческим причинам, ты помнишь мощность своего десктопа в 1990-м? а объем его оперативки? он бы просто не смог скомпилировать более-менее сложную программу на C#)
AVK>>Какой из этого следует вывод?
V>Ты хоть намекни, какой следует вывод у тебя.
Ну, на поверхности — С++ нуждается в глубоком рефакторинге.
V>>>Тут мы видим наследие языка С, который суть одно сплошное UB , однако в С++ оставлены те же возможности и механизмы их реализаций, что и в С, что позволяет использовать С++ в тех областях, где раньше был применим С (а до него ASM).
AVK>>Какой из этого следует вывод?
V>Что применим до сих пор, и будет еще долго применим, для реализации того же дотнет на различных платформах
А что, против этого кто то спорил?
V>>> где тоже элементарно получить UB в случае ошибки описания предполагаемой бинарной структуры ожидаемого типа.
AVK>>Например? Особенно интересны элементарные случаи. На всякий случай — P/Invoke это safe механизм.
V>C# не гарантирует расположение полей в run-time.
Что такое "расположение полей" и при чем тут P/Invoke?
V>для "надежности" расположение можно описать аттрибутами, но эта аттрибутика не описываема в грамматике языка. V>я тоже в С++ пользуюсь #pragma pack(xxx) и избегаю последствий UB точно таким же приемом. Просто, в случае С++ никто не стесняется говорить о возможном UB.
V>
V>struct A { int i; }
V>struct B { int i; }
V>A* a = new A;
V>B* b = (B*)a;
V>
V>будет работать? — будет. V>однако UB в общем случае.
Не, ты приведи пример safe-кода на шарпе с UB.
AVK>>Например в количестве стандартных синтаксических конструкций. А ты думал что С++ во всем сложнее щарпа?
V>А почему бы не подсчитать семантические?
ИМХО это невозможно. Есть конструкции С++, не имеющие аналогов в С#, есть конструкции С#, не имеющие аналогов в С++.
V>В MC++ этих дополнительных нетовских конструкций как минимум не меньше, и плюс весь остальной язык.
Меньше. Например свойств в грамматике МС++ нет, они эмулируются. То же самое можно сказать про события, using и т.п.
V>(тут вообще прикол получается. грамматика C# завязана на конкретные типы из .Net,
Например? Навскидку вспоминается только FlagsAttribute.
V> аттрибуты управляют программой. допустимые и применимые аттрибуты в граматике не опишешь, налицо некий разрыв и опора просто на спецификации и идентификаторы "специальных" типов/аттрибутов)
Какие "специальные" атрибуты влияют именно на парсер, а не на семантический анализатор?
AVK>>На всякий случай — я не утверждаю что один язык безоговорочно сложнее другого, это утверждение неверно в оба конца.
V>Ну хорошо, а субъективно как?
Синтаксис шарпа сложнее, возможностей с легкостью делать то что изначально не предполагалось больше у С++.
Здравствуйте, AndrewVK, Вы писали:
V>>Ты хоть намекни, какой следует вывод у тебя.
AVK>Ну, на поверхности — С++ нуждается в глубоком рефакторинге.
Это будет уже другая история. Если выкинуть/изменить неоднозначные конструкции в С++, придется отказаться от всех многолетних (действительно многолетних) наработок. Очередное начало "с чистого листа" отрасль не потянет (по крайней мере в ближайшем будущем).
V>>Что применим до сих пор, и будет еще долго применим, для реализации того же дотнет на различных платформах
AVK>А что, против этого кто то спорил?
ты нет, дык и я вроде не с тобой спорил.
AVK>Не, ты приведи пример safe-кода на шарпе с UB.
public class A1 { int i; fload j; double k; }
[DllImport("SomeApi.dll")]
static private int GetSomeThing(A1 a);
Если не зафиксировать явно положение полей — UB.
AVK>>>Например в количестве стандартных синтаксических конструкций. А ты думал что С++ во всем сложнее щарпа?
V>>А почему бы не подсчитать семантические?
AVK>ИМХО это невозможно. Есть конструкции С++, не имеющие аналогов в С#, есть конструкции С#, не имеющие аналогов в С++.
Имхо,
A.B.C.D.E(F, G, H); — не сложно.
аттрибуты и все остальное еще проще.
сложно вот:
A* ((B(&C)[D])*)(*E)(F(*)(G), H*&);
V>>В MC++ этих дополнительных нетовских конструкций как минимум не меньше, и плюс весь остальной язык.
AVK>Меньше. Например свойств в грамматике МС++ нет, они эмулируются. То же самое можно сказать про события, using и т.п.
using namespace A = B::C::D;
using namespace E::F;
__gc class MyClass
{
public:
MyClass() : m_size(0) {}
// compiler generates a pseudo data member called Size__property int get_Size() { return m_size; }
__property void set_Size(int value) { m_size = value; }
// Examples of managed events:__event ClickEventHandler* Click1; // data member as event__event void Click(String* s); // method as eventvoid OnClick(String* s) { Click(s); }
protected:
int m_size;
};
__gc class MyReceiver {
public:
void MyHandler1(String* s) {
Console::Write("MyHandler1 was called with value ");
Console::WriteLine(s);
}
};
int main()
{
MyClass* class1 = new MyClass;
Console::WriteLine(class1->Size);
MyReceiver* receiver = new MyReceiver;
__hook(&MyClass::Click, class1, &CReceiver::MyHandler1, receiver);
class->OnClick("Click event test \n");
__unhook(&MyClass::Click, class1, &CReceiver::MyHandler1, receiver);
}
V>>(тут вообще прикол получается. грамматика C# завязана на конкретные типы из .Net,
AVK>Например? Навскидку вспоминается только FlagsAttribute.
[DllImport("SomeApi.dll")]
static private int GetSomeThing(A1 a);
Нельзя только объявлять ф-ии, надо определять их тела. Корректность приведеного случая как раз зависит от наличия вполне конкретного аттрибута. Как это увязать с грамматикой?
(в 2.0 с частичными классами они пошли еще дальше)
AVK>Какие "специальные" атрибуты влияют именно на парсер, а не на семантический анализатор?
на парсер? на него никак, он бъет на лексемы.
AVK> Синтаксис шарпа сложнее, возможностей с легкостью делать то что изначально не предполагалось больше у С++.
на уровне прикладного использования да. Только шарп тут не при чем, тут библиотеки дотнета тебе в помощь. Когда же ты что-то разрабатываешь (практически с 0-ля, бывает и такое), у меня на C# пальчики начинают болеть, и Ctrl+Insert на клаве уже затерся, из-за типизированных коллекций например.
видел и .Net 2.0, однако отсутствие конструкции типа typedef делает невозможным примерно 70% шаблонного программирования (не могу в классе указать зависимый тип, т.е. все traits и стратегии — лесом). Отсутствие возможности отнаследоваться от параметра шаблона отнимает еще примерно 20% (имеплементация аспектов интерфейсов).
В 1.0 и 1.1 имплементация интерфейсов — вообще полные мраки... туши свет, кидай гранату.
(в плане мозолей на пальцах)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
V>>Влад, ты же разбираешься в этом вопросе, а жонглируешь...
VD>Чем? Чистое сравнение количества конструкций языка. Без каких личбо выводов.
V>>Ты забыл оценить мощность порождаемого грамматикой множества выражений.
VD>Осталось определить смысл вкладываемый в это понятие и как перевести "это" в количественную составляющую...
смысл такой — количество допустимых выражений на единицу языка.
учитывая наличие правил с рекурсивностью определений в том и другом случае, можно исключить рекурсивные ветки (или дать им максимум 1-но вложение) для детерминированности.
есть подход от обратного.
берем допустимые цепочки и смотрим, скольким нетерминалам (конечным или промежуточным) удовлетворяет эта цепочка. Чем большим (чем больше неоднозначность), тем мощнее грамматика.
Рассматривать C# в отрыве от платформы — бесполезное занятие.
C# представляет из себя язык-интерфейс к платформе. Правда, зело удивляет тот факт, что на C# невозможно задействовать ВСЕ возможности этой платформы. А используя студию — и того меньше.
Вроде, С++/CLR задумывался как более полное решение...
Отношение к нему двойственное, разумеется. Местами он хорош, намного лучше промежуточного MC++.
С другой стороны, это опять же, С++ плюс интерфейс к дотнету.
Мы пришли к ситуации, когда "грамматическая чистота" языков перестала иметь значение. Язык служит для использования в рамках вполне конкретной прикладной технологии. Если просто признать это, т.е. взглянуть на современное положение вещей с другой т.з., то весь предыдущий спор теряет смысл, причем со стороны обоих противоположных мнений.
Здравствуйте, vdimas, Вы писали:
AVK>>Не, ты приведи пример safe-кода на шарпе с UB.
V>public class A1 { int i; fload j; double k; }
V>
V>[DllImport("SomeApi.dll")]
V>static private int GetSomeThing(A1 a);
V>
V>Если не зафиксировать явно положение полей — UB.
Почему это undefined? Что здесь неопределенно? Алгоритмы маршаллера известны, никаких неопределенностей он не допускает. Да и в любом случае — не язык это. Компилятор в ответ на такое должен сгенерировать строго определенный набор метаданных и IL кода.
AVK>>ИМХО это невозможно. Есть конструкции С++, не имеющие аналогов в С#, есть конструкции С#, не имеющие аналогов в С++.
V>Имхо, V>A.B.C.D.E(F, G, H); — не сложно.
V>аттрибуты и все остальное еще проще.
V>сложно вот: V>A* ((B(&C)[D])*)(*E)(F(*)(G), H*&);
V>
Не сложно, а запутанно. Это не совсем одно и то же. На шарпе я тоже могу каракатиц напридумать, вон Влад пример приводил. Да и в usafe-mode такое и на шарпе возможно.
AVK>>Например? Навскидку вспоминается только FlagsAttribute.
V>
V>[DllImport("SomeApi.dll")]
V>static private int GetSomeThing(A1 a);
V>
V>Нельзя только объявлять ф-ии, надо определять их тела. Корректность приведеного случая как раз зависит от наличия вполне конкретного аттрибута.
Не зависит. Это вобще некорректный код. Корректный такой:
[DllImport("SomeApi.dll")]
staticexternprivate int GetSomeThing(A1 a);
Такой тоже корректный:
staticexternprivate int GetSomeThing(A1 a);
V> Как это увязать с грамматикой?
Никак. Это не грамматика.
V>(в 2.0 с частичными классами они пошли еще дальше)
А именно?
AVK>>Какие "специальные" атрибуты влияют именно на парсер, а не на семантический анализатор?
V>на парсер? на него никак, он бъет на лексемы.
Парсером обычно называют синтаксический анализатор. А лексический сокращенно называют лексер. Вопрос остается.
AVK>> Синтаксис шарпа сложнее, возможностей с легкостью делать то что изначально не предполагалось больше у С++.
V>на уровне прикладного использования да. Только шарп тут не при чем, тут библиотеки дотнета тебе в помощь.
Отнюдь. К примеру using, foreach, частичные классы, итераторы, анонимные методы это чисто языковые конструкции.
V> Когда же ты что-то разрабатываешь (практически с 0-ля, бывает и такое), у меня на C# пальчики начинают болеть, и Ctrl+Insert на клаве уже затерся, из-за типизированных коллекций например.
А у меня нет. Хотя уже десяток мег кода точно написал.
V>видел и .Net 2.0, однако отсутствие конструкции типа typedef делает невозможным примерно 70% шаблонного программирования (не могу в классе указать зависимый тип, т.е. все traits и стратегии — лесом). Отсутствие возможности отнаследоваться от параметра шаблона отнимает еще примерно 20% (имеплементация аспектов интерфейсов).
И слава богу.
V>В 1.0 и 1.1 имплементация интерфейсов — вообще полные мраки... туши свет, кидай гранату. V>(в плане мозолей на пальцах)
AVK>staticexternprivate int GetSomeThing(A1 a);
AVK>
кстати, дейсвительно!!! компилятор такой код компилирует, но выполнить не может.
AVK>>>Какие "специальные" атрибуты влияют именно на парсер, а не на семантический анализатор?
V>>на парсер? на него никак, он бъет на лексемы.
AVK>Парсером обычно называют синтаксический анализатор. А лексический сокращенно называют лексер. Вопрос остается.
Да, я был не прав, думая что компилятор не пропустит указанную конструкцию без аттрибута, ибо эта конструкция лишена смысла...
Ситуация стала еще более прикольной
Выдал TypeLoaderException в run-time, но не указал, из-за чего именно.
Представим класс, который инкапсулирует WinAPI, например...
AVK>А у меня нет. Хотя уже десяток мег кода точно написал.
Лучше бы ты их на С++ написал. Десяток мег на С++ — это черта уже свернуть можно было.
V>>видел и .Net 2.0, однако отсутствие конструкции типа typedef делает невозможным примерно 70% шаблонного программирования (не могу в классе указать зависимый тип, т.е. все traits и стратегии — лесом). Отсутствие возможности отнаследоваться от параметра шаблона отнимает еще примерно 20% (имеплементация аспектов интерфейсов).
AVK>И слава богу.
почему?
----
Насчет синтаксиса C# 2.0 вынужден согласиться, там наворочено много чего, возможно нужна КЗ-грамматика, я имел ввиду 1.0 — 1.1
Здравствуйте, vdimas, Вы писали:
AVK>>Такой тоже корректный: AVK>>
AVK>>staticexternprivate int GetSomeThing(A1 a);
AVK>>
V>кстати, дейсвительно!!! компилятор такой код компилирует, но выполнить не может.
А ты думал я тебя обманываю?
AVK>>Парсером обычно называют синтаксический анализатор. А лексический сокращенно называют лексер. Вопрос остается.
V>Да, я был не прав, думая что компилятор не пропустит указанную конструкцию без аттрибута, ибо эта конструкция лишена смысла...
С чего ты взял что она лишена смысла? dll отнюдь не единственный источник внешних функций. Это может быть, к примеру, прилинкованная статически unmanaged-функция.
V>Ситуация стала еще более прикольной V>Выдал TypeLoaderException в run-time, но не указал, из-за чего именно.
Inner exception смотрел?
V>Представим класс, который инкапсулирует WinAPI, например...
Хочешь поговорить на эту тему?
AVK>>А у меня нет. Хотя уже десяток мег кода точно написал.
V>Лучше бы ты их на С++ написал. Десяток мег на С++ — это черта уже свернуть можно было.
А на C# думаешь нельзя? Да и на С++, может конечно не десяток мег, но тоже предостаточно написал. Правда С++ был Borland C++ 3.1.
V>>>видел и .Net 2.0, однако отсутствие конструкции типа typedef делает невозможным примерно 70% шаблонного программирования (не могу в классе указать зависимый тип, т.е. все traits и стратегии — лесом). Отсутствие возможности отнаследоваться от параметра шаблона отнимает еще примерно 20% (имеплементация аспектов интерфейсов).
AVK>>И слава богу.
V>почему?
Потому что код, основанный на том что ты сейчас описал похож на тихий ужас. Ну и в качестве дополнительного кайфа наличие возможности наследоваться от параметра шаблона приводит к тому что шаблон невозможно заранее скомпилировать.
V>Насчет синтаксиса C# 2.0 вынужден согласиться, там наворочено много чего, возможно нужна КЗ-грамматика, V> я имел ввиду 1.0 — 1.1
Тем не менее наличие контекстно зависимых ключевых слов get, set, value, add, remove не позволяет обойтись даже LR грамматикой без ручной дописки парсящего кода. Jay-грамматику для шарпа можешь взять в mono и полюбоваться на то как народу приходится извращаться. Да еще одна песня шарповской грамматики — глобальные атрибуты. Долго расписывать, но это тоже не контекстно-свободная грамматика.
Здравствуйте, AndrewVK, Вы писали:
AVK>Тем не менее наличие контекстно зависимых ключевых слов get, set, value, add, remove не позволяет обойтись даже LR грамматикой без ручной дописки парсящего кода. Jay-грамматику для шарпа можешь взять в mono и полюбоваться на то как народу приходится извращаться. Да еще одна песня шарповской грамматики — глобальные атрибуты. Долго расписывать, но это тоже не контекстно-свободная грамматика.
Я смотрел в роторе компилятор C#. Там они просто вмешиваются в работу компилятора и "вручную" обрабатывают некоторые из указанных конструкций, изымая их из входной последовательности разборщика. сам же разборщик более похож на реализацию КС грамматики.
Здравствуйте, vdimas, Вы писали:
V>и? какую из форм и применимых оборотов ты имел ввиду? пока не одна не подходит для рассматриваемого вопроса и тем более под твои утверждения...
Ненадо прикидываться... В первом.
VD>>Некорректная аналогия. Тут сравниваются спецификации импиративных языков объектно ориентированного программирования общего назначения. Они более чем сравнимы.
V>Во-первых — разного назначения. (!!! хотя и используют похожие подходы)
Одинакогово, одинакового. Они позволяют решать одинаковые задачи и являются
универсальными.
V>Ввиду того, сравнимы только в области пересечения, которая невелика.
Я так понимаю, тебе даставляет удовольствие кидаться многосмысленными терминами врод "области пересечения". Вот только остальные гадать не обязаны. Так что расталковывай свою терминологию сам и сразу.
V>>> Количество потенциальных неувязок в первом случае гораздо больше. VD>>Демагогия на базе некорректной аналогии. V>уже пояснил свою аналогию, где говорилось о различном назначении, но похожем подходе для достижения целей. Первый случай потенциально опасней, сложней и т.д.
Выводы на базе аналогии — это форменная демагоги. Да и пояснением "это" назвать нельзя.
V>>>Спецификация C# действительна очень проста,
VD>>Для тех кто ее не читал. Рельно она понятна и не противоричива, но не проста. Это довольно объемный и не простой документ. Проста она только в сравнении с запутанной и противоричивой.
V>Читал внимательно и неоднократно.
Значит говоришь неправду намеренно?
V> Она проста не только (не столько) в сравнении со сложной, сколько из-за синтаксиса самого языка и предполагаемой техники компиляции/сборки (!!!).
Это называется логична и не протвиоричива. Назвать же простым документ в 400 страниц можно только если есть огромное желение извратить факты.
V> Компилятор C# изначально многопроходный,
Он приципиально однопроходный. И мнофазовый. Но это детали реализации и не очень корректное использование терминалогии. В спецификации самого языка нет даже намека на способы реализации.
V> в идеале — сколь угодно проходный. Компилятор С++ изначально расчитан на ограниченное число проходов
То есть не один?
V> (язык организован так, что вполне позволяет обойтись одним
Какое отношение имеет возможность и реализация. Укажи мне места в спецификации С++ где об этом говорится. Там вообще слова "compiler" встречается случайно... праз 5.
V>- по историческим причинам, ты помнишь мощность своего десктопа в 1990-м? а объем его оперативки? он бы просто не смог скомпилировать более-менее сложную программу на C#)
И к чему все это? Единственное что моно утвержадать — это то что С++ требует предекларации методов и проповедут пследовательную видимость в то время как C# не требует предеклараций и пропагандирует структурированные области видимости.
Многопроходность компилятора — это термин из тех далеких лет когда компилятор не мог взять в память представление программы целиком. Эти времена ушли уже в 94-ом. (я лично в конце 94-го имел П90 с 16 метрами памяти). И к 98-у (когда появился современный стандарт С++) практически все компиляторы С++ строили AST. Более того во всех книгах посвященных теории компиляторов слова об AST обычно начинаются упоминанием того, что для реализации С++ AST является практически необходимой вещью.
С++ и C# сложне языки и логично, что для отработки всех их семантических правил AST просто необходимо. Так что говорить о проходах просто некорректно. Практически все компиляторы С++ и C# которые я видел на сегодня — это однопроходные, многофазные компиляторы! Так что закончим это "серьезное" обсуждение.
V>Если ты в курсе проблем С++, то многие потенциальные неоднозначности как раз связаны с одинаковым синтаксисом объявления и определения.
Синтаксические неоднозначности С++, о которых ты ведешь речь, не стоиют выеденного яйца. Проблемы С++ отнюдь, не в синтаксических неоднозначностях. Они в немодульности, несогласованности и изуверском текстуальном препроцессоре. Именно решение этих проблем позволило компиляторам Явы и C# обеспечить стольк высокую скорость компиляции.
Открой этот "просто" станарт C# и ты обнаружишь там (прямо в определении) такое понятие как сборка:
Assembly — refers to one or more files that are output by the compiler as a result of program compilation.
An assembly is a configured set of loadable code modules and other resources that together implement a unit of functionality. An assembly can contain types, the executable code used to implement these types, and references to other assemblies. The physical representation of an assembly is not defined by this specification. Essentially, an assembly is the output of the compiler.
Определяюще то что в классике компиляторо-строения называется модулем.
V> Первой конструкции в C# нет из-за упомянутой техники компиляции.
Как я уже говорил. Нет в C# упоминаний о техниках компиляции. И для компиляции как С++, так и C# применяются одинаковые техники и технологии компиляции. Так что хватить петь эту песню.
V>Далее, C# разработан из предположения, что никак не зависит от архитектуры платформы, на которой исполняется.
Гы. А С++ значит был ореентирован на конкретную платформу?
V> C# использует общую систему типов, которая не зависит от разрядности применяемой платформы.
Не использует "общую". А проецируется на систему типов CLI. Тем неменее стандарт C# включает полное описание всех встроенных типов и способов построения пользовательских типов. В точности как и С++.
Разница только в том, что С++ ставит размер типов в зависимость от реализации, а C#, как и система типов CLI четко определяет их в стандрарте.
Причем — это было продуманным, взвешенным решением. И не млую роль в принятии этого решения сыграл анализ проблем С/С++. Учитывая эти проблемы, а так же то, что современное развитие оптимизации в компиляторах позволяет и без ручной оптимизации получить нужную производительность, было принято решение четко определить размеры встроенных типов.
V> Многие UB в С++ (ты упоминал их наличие) именно отражают тот факт, что язык С++ предназначен в качестве "родного" для целевой платформы, т.е.
С++ не стал родным ни для одной виденной мною ОС. По крайней мере более родным, чем другие языки. Да и к делу это не относится. Так что этот аргумент можно смело опустить.
То что часть UB связано с размерами — это верно. Но это только одна из причит приводящая к UB (кстаит, унаследованная у С). Таких причин в стандарте море.
Утверждать, что привязка к размерам типов действительно что-то то дает на сегодня уже мало кто берется. От того все больше и больше разработчиков новых систем считают выбор С/С++ ошибкой и отказываются от него.
V> должен оперировать родными типами целевой платформы.
Кому должен? Можешь доказать это утверждение?
V> Явно упомянутые UB отражают те моменты, которые могут быть не переносимы м/у платформами (в виду характера этих платформ).
То что Ява и дотнет имеют лучшую переносимость нежели С++, и то что обе этих платформы признали зависимость размеров типов от платформы является отличным косвенным подтверждением ошибочности этого утверждения.
Реально идея сделать некоторые типы зависимыми от реализации (платформы, а точнее машины) была введена в С. И основывалась она не на идее переносимости, а на идее оптимизации. Считалось, что зависимые от платформы типы данных позволят создавать более эффектиные приложения. В те времена были машины которые более эффктивно манипулировали двухбайтовыми целыми, а были которые более эффективно манипулировали четырехбайтовыми целыми.
Как раз же с точки зрения переносимости такая зависимость крайне опасна. Реальзые программы пишутся на реальном железе и всегда есть опасность, что программист просто не учтет особенностей другого жлеза. Например, он писал код на VAX-ах (очень реальный сценарий для С) где int был 32-битным, а потом программу пршлось перенести на PC-юху. При компиляции проблем может не возникнуть, а вот при выполнении на писюке прокграма грохнится так как int переполнится.
Таким образом, программируя на С приходится уделять проблемам переносимости куда большее внимание. Именно по этому даже после того как системный софт стали писать на С, все равно мнение о том, что системный софт менее переносим чем прикладной не исчезло.
V>Хотя, никто не запрещает проводить произвольную реинтерпретацию участков памяти, даже в случае потенциального UB.
Не "даже", "Для". Произвольная реинтерпретацию участков памяти — это 100%-ый путь к НП (UB).
V> ПОЧТИ все системные программы очень низкого уровня (дрова и пр.) используют моменты, которые могут быть расцененены как UB в общем случае, но весьма подходят для частной платформы.
Явно необоснованное предположение.
V> Тут мы видим наследие языка С, который суть одно сплошное UB ,
С никогда не был эталоном качества разрботки языка. Однако он был эволюцией языка BCPL который как раз действительно мог бы претендовать на звание полного НП. И эволюция заключалась в ведении типов, которые повышали определенность в программах. Так что как это не парадоксально, можно сказать, что С был большим эвалюционным шагом в стороу устранения неопределенного поведения неже ли С++.
V> однако в С++ оставлены те же возможности и механизмы их реализаций, что и в С, что позволяет использовать С++ в тех областях, где раньше был применим С (а до него ASM).
Все необходимые для этого возможности есть и в C#. Так что потенциально и его можно использовать для создания драйверо и другого системного кода. Вот толко эта нишка как была занята С с момента его появлени, так и остается по сей день. И это легко объяснимо. Кроме применимости есть еще куча других факторов. В том числе и необъодимость. Задачи драйвера манипуляции с портами, битами и другими низкоуровневыми понятиями. Тут возможностей С в общем-то более чем достаточно. Учитывая простоту языка и его распространенность и небольшие объемы задач совершено понятно почему на нем до сих пор пишут системный софт.
V>В C# возможна реинтерпретация памяти только в p-Invoke, где тоже элементарно получить UB в случае ошибки описания предполагаемой бинарной структуры ожидаемого типа. В самом же C# реинтерпретации памяти нет,
Это мягко гворя заблуждение. 1. Атрибут DllImport и модификатор extern (то что ты называешь p-Invoke-ом) не является средствами реинтерпретации памяти и вообще не является средством приводящим к НП. Они предназначены для импорта внешних методов. Все! Точка! Неопределенность поведения могут быть вызвано только неверным описанием внешнего метода или неопределенностью поведения импортируемого метода. Обе этих вещи к языку отношения не имеют. Эдак и Process.Start() можно записать в неопределенное поведение. К тому, же дотнет обеспечивает довольно хорошую защиту от проблем во внешних методах. Так что на практике к порче данных и т.п. они привести могут с трудом.
2. В C# есть и штатные средства реинтерпретации памяти — это unsafe-код. При этом в он помечаетя специльным образом и все случаи НП четко специфицированны (их ровно 7).
V> в подобных случая применяет конструирование нового объекта требуемого типа — суть копирование памяти. В случае написания системного ПО — шаг весьма сомнительной необходимости.
Тоже мягко говоря заблуждение. Например:
int i = int.MaxValue;
byte bt = (byte)i;
byte[] bytes = new byte[]{ 12, 34, 56 };
i = bytes[0] | bytes[1] << 8 | bytes[2] << 16;
V>>> сам язык гораздо проще. VD>>Тоже, скажем, так сомнительное утверждение. Со многих точек зрения C# сложнее С++. V>Тоже, скажем, так сомнительное утверждение.
Да нет. Как раз легко доказываемое на практике.
V> Ты неоднократно говорил о том, что C# сложнее С++. Я хочу узнать, наконец, в чем именно?
Шарп больше какминимум с точек зрения:
1. Размера граматики. см. здесь.
2. Количества конструкций языка. Например, в С++ отсуствуют: свойства, делегаты, события, итераторы, анонимные методы. Плюсь отсуствуют множество мелочевки вроде модификаторов параметров.
3. Количества и сложности встроенных типов. Например, массвы, строки и делегаты как объекты высшего порядка.
4. Большего объема семантических описаний (вызваных обходом неопределенностей).
5. Наличия средств расширения метаописания (атрибутов).
V> (условия конкурса — речь не о .Net, а именно о C#,
Дотнет во многом рассматривается как рантайм Шарпа. Но можно конечно и изолированно. Список выше (долекий от полноты) никак не относится к дотнету. Это все конструкции языка.
V>предлагаю обсудить возможности тех же дженериков и шаблонов, и посмотреть количество приемов разработки, которые позволяют эти варианты,
Можно обсудить и это. Хотя к сложности языка это будет относиться только с точки зрения простоты использования. Да и разница там не стольк велика чтобы сравнить ее с описанными выше фичами.
Кстати, забавно, что если рассматривать шаблоны и дженерики с точки зрения исключительно обобщенного программирования и концепций ООП, то шаблоны окажутся в сильном проигрыше. Но это уже отдельная тема.
V>причем на С++ будут рассматриваться только варианты без UB )
А в нем, это просто не удастся. В описании шаблонов НП вроде как присуствует.
Единственное преемущество реальное шаблонов С++ заключается в том, что использование некоторых побочных эффектов последней спецификации позволяет их использовать для мета-программирования. Но тут можно противопоставить некоторые другие методы.
VD>>При том. Качественнее. На меньшем количестве страниц дано более сбалансированное и логичное описание. Нет такого количества пробелем и т.п.
V>Тааак, вот это мы приплыли. V>Качество ПО — это степень соответствия его требованиям.
Гы. Где ты увидил ПО? И что такое "его требовния"?
Речь идет о качестве языка и о качестве его спецификации.
Если говорить о стандарте, то тут по-моему все очевидно. Задачи стандарта — описание языка программирования и содействие реализациие его компиляторов/интерпретаторов. При этом в критерии оценки его качества я вношу:
1. Простоту описания. Доходчивость описания.
2. Непротиворичивость описания.
3. Отсуствие (минимизация) неоговоренных мест.
4. Простоту реализации стандарта на практике.
V>Качество ПО (Вендров, Липаев) V>совокупность свойств ПО, к-рые характеризуют способность ПО V>удовлетворять заданным требованиям.
Чтобы сравнивать языки нужно исходить из того, что все требования к ним исходят от конечных пользователей. Надеюсь, мы сравниваем С++ и Шарп как императивные ООЯ общего назначения. Согласен с такой формулировкой требований?
Тогда мне кажутся уместными критерии:
1. Возможность реализации на языке программ общего назначения. Непривязанность к одной конкретной нише разработки ПО.
2. Выразительность. Возможность решать задачу максимально просто, коротко и ясно.
3. Качество контроля. Безопастность программирования: статический/динмический контрольк типов, минимизация граблей (случайного порождения некорректного кода), контроль выхода за пределы массивов, качество инкапсуляции и т.п.
4. Поддержка целевой парадигмы (ООП, ФЯ, АОП). В даном случае поддержка ООП и структурного программирования (СП).
5. Возможность создания эффективного компилятора и рантайма. Другими потенциальная словами возможность создания средствами языка эффективных приложений достаточных для удовлетворений потребностей пользователей.
6. Возможность осуществлять интеграцию с низкоуровневым и системным кодов. Возможно так же причислить сюда возможность создания системного кода. Хотя для многих этот критерий окажется не обязательным.
Возможно можно добавить критериев, но по-моему — это как раз наиболее востребованный набор критериев на сегодня.
V>или еще более общее определение:
V>Качество (Розова, "Упрвление качеством") V>совокупность характеристик объекта, относящихся к его способности V>удовлетворять обусловленные или предполагаемые потребности.
Я предпочитаю не общее определение:
КАЧЕСТВО, -а, ср. 1. Совокупность существенных признаков, свойств, особенностей, отличающих предмет или явление от других и придающих ему определённость (спец.). Категории качества и количества. Переход в новое к. 2. То или иное свойство, признак, определяющий достоинство чего-н. К. работы. К. изделий. Высокие душевные качества. * В качестве кого-чего, предлог с род. п. — как кто-что-н., в виде чего-н., в роли кого-чего-н. Явился в качестве посредника. II прил. качественный, -ая, -ое (к 1 знач.). Качественные различия. Качественные изменения. * Качественные прилагательные — в грамматике: прилагательные, обозначающие качество, свойство и образующие краткие формы и степени сравнения.
V>...Каждая потребность выражается рядом требований, которые V>участвуют в формировании отношений пригодности объекта V>для целей потребителя, служат для оценки соответствия V>объекта его назначению...
Пригодность еще не есть показатель качественности. Например, Жигуленок пригоден для есзды но назвать его качественным продуктом у меня язык не поворачивается.
V>>>Спецификация VB.Net еще проще... VD>>Опять неправда. Спецификация VB.Net приблизительно равна по объему и сложности Шарповой. V>Она чуть-меньше, но сути это не меняет.
Она не меньше. Это целый рад документов очень большого размера.
V> Речь о том, что существуют языки с еще меньшей спецификацией, но это не говорит о том, что они "лучше" или "хуже".
А никто не говорил размер спецификации это достоинство или недостаток. Я утвреждал, что при более высоком качестве языка/спецификации ее объем как минимум соизмерим.
ты выступал за обоснование любых утверждений. В данном сообщении ты наделал кучу ничем не подтвержденных (а реально ошибочных) утверждений. Поробуй их обосновать. Ну, ради хохмы.
V>Тебе бы все хохмить. Чтобы утверждать ошибочность утверждений, надо их хотя бы пытаться опровергать.
Здравствуйте, vdimas, Вы писали:
V>Я смотрел в роторе компилятор C#. Там они просто вмешиваются в работу компилятора и "вручную" обрабатывают некоторые из указанных конструкций, изымая их из входной последовательности разборщика. сам же разборщик более похож на реализацию КС грамматики.
Это как раз то, что в твоем определении называлось "Мягко контекстно-зависимые грамматики".
