Здравствуйте, VladD2, Вы писали:
AVK>>Каким образом, простите, доск?
VD>По пунктам. Все метаданные, формат файла и т.п. VD>Все декомпиляторы пользуются этой спецификацией.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Все в пределах одной реализации. Требований к разным реализациям хранить эти данные в одном формате я не нашел.
Дык хотя бы это. Даже этого достаточно чтобы ускорить компиляцию, датеть возможность создавать совместимые продукты и решить море других проблем.
Ну, а бинарный стандарт тоже есть. Просто он вынесен в отдельный стандарт.
>> Ну, и как ты говоришь он ссылается на стандатры в которых все описано досканально.
ПК>Прямо он ссылается на "библиотечную" часть. Я искал в стандарте C# требования к формату сборки или что-нибудь в таком роде, пытаясь определиться со своим ответом на твой вопрос
Дык оставляют возможность реализации языка не на базе дотнета.
Кстати, я правильно понимаю, что данные твои слова можно интерпретировать как отказ от:
ПК>А еще для X86, Solaris, Macintosh и прочих платформ, на базе которых можно построить абстрактную машину, описанную в стандарте C++. Иными словами стандарт C++, в отличие от стандарта C#, от .Net/CLI не зависит. И наоборот, стандарт CLI от стандарта C++ тоже не зависит.
?
Ну, что ты береш свои слова обратно и соглсен, что и C#, и C++ могут быть реализованы отдельно без привязыки к разным там реализациям CLI?
ПК>Пока что склонен считать, что стандарт C# не требует от разных реализаций бинарной совместимости. Естественно, это будет требоваться, если они, как и майкрософтовский вариант, будут построены поверх CLI в качестве среды исполнения. Но такого требования, похоже нет.
Что же до бинарности, то ее и не требуется... на уровне языка. Но модульность, на сегодня ой как востребована. И то, что стандарт плюсов обходит этот момент, а по факту многими своими моментами (такими как #include-ы в препроцессоре) сильно ей препятсвуе, является отрицательным фатором и понижает качество стандарта и соотвественно языка.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>С 1998.
Не, с 89-го. 98 — это дата выхда последнег стандарта. А 89-ых — это год когда появились шаблоны и вообще язык можно было назвать состоявшимся.
>> ПК> В Microsoft до недавнего времени на стандарт плевали с высокой колокольни, и занялись поддержкой оного, когда увидели, что это становится, действительно, важным для их пользователей.
>> Да то, что это важно для пользователей они поняли еще гду в 90-ом.
ПК>Откуда дровишки?
Да из появления VC. А вот откуда твои дровишки? Кто тебе сказал, что они не хотели совместимости? Может они просто не в сила были ее обеспечить...
ПК> В 1990 еще стандарта и в помине не было.
С++ был. СТЛ был. Так что уже можно было начинать дружить со Страуструпом.
ПК> Да и прямые высказывания разработчиков и менеджеров, которым я в этом отношении склонен верить гораздо больше, говорят немного о другом.
Цитаты, плиз. А то я тоже много чего слышал.
ПК> А именно, что соответствие стандарту стало приоритетным только для предпоследнего (7.0) и последнего релиза (7.1). А отношение к стандарту до этого можно легко уяснить по простому факту, что Майкрософт во времена разработки стандарта даже была исключена из списка голосующих членов комитета за пропуск нескольких заседаний.
Ну, т.е. Борлад можно считать паенькой и значит, то что они тоже не смогли создать совместимую со стандартом версию все же говорит о его сложности запутанности?
ПК>Вот беда-то какая, с цифрами снова совсем неладно. 2004 — 16 = 1988.
Сейчас почти 2005-ый. Плюсы оформились в 98 так что все ОК. Если бы МС только подправляли свой компилятор для учета текущего стандарта, то мы умели бы полноценный компилятор уже в лице VC 1.0/1.5. А VC6 вообще был бы полностью совместим со стандартом, так как вышел в том же году.
ПК>В том славном году еще даже C не был стандартизован, не то что C++.
С++ тогда появился и оформился. А С уже лет 10 как имел стандарт дефакто — K&R.
ПК> А Microsoft выпустили свою шестую версию Visual Studio в 1998 году, и в то время на стандарт, вышедший в том же году, им еще было чихать совершенно.
Им как видишь и сейчас в общем-то чихать. Они свои создают.
ПК>Следующий релиз, Visual Studio .Net 2002, был посвящен презентации .Net (не забываем и Managed extensions for C++ — это, естественно, тоже делали разработчики из команды VC++),
Да, да... согласен. Уболтал, речистый. МС контора бедная. Ей просто ресурсов не хватило сделать компилятор соотвествующий стандарту. Ну, а Борлад, Сайбес (он же PowerSoft, он же Ватком), а GCC, а все остальные? Почему появился только какой-то там незивестный на три буквый которым никто реально не пользуется?
ПК>А, в фоновом режиме, таки да, начались кой-какие подвижки в сторону соответствия стандарту.
И вот тут возникает вопрос. Почему такие бабки кладутся на разрботку нового языка — сишарпа, и упровляемой среды упровления? Ведь С++ так крут, что казалось бы в него то и нужно бабки вбухивать. А они так тебе. Вкладывают в "почти скриптовый" язык. Тут были товарищи сравнивающие этот язык с Питоном и метившие ему место в качестве средств написания юнит-тестов. Почему же такая странная оценка МС? Зачем они с Саном переругались только ради права улучшения ява-машины и языка Ява? К чему такие затраты?
Не уж то одной из причин небыло как раз отсуствия у С++ и его стандарта некоторых качеств?
ПК>Надо понимать, что история компилятора С/С++ от Microsoft насчитывает уже около 20 лет.
С больше. С++ меньше и существенно. Первый С++-компилятор МС, если мне не изменяет память, — это VC 1.0, появившийся где-то в 93-ем. Который тоже от С++ отличался очень значительно.
ПК>А остановиться, и переписать компилятор с нуля не может позволить себе даже Microsoft.
Да, ну? Боюсь, что МС под силу даже купить Страуструпа и весь С++-комитет.
А то, что С++-компиляторы умудлрились сделать даже опенсорс-фофаны точно говорит, что проблема не в том, что долго с нуля, а в том, что на то есть причины внутри С++.
Заметь, когда МС захотели они взяли и создали то же Шарп. Да и тот же Гейтс — это не заурядный компиляторщик.
ПК> Да, ребята молодцы, и делают огромную работу, и я очень ценю то, что они сделали для релиза 7.1, но еще раз хочу подчеркнуть, что информация, так сказать, из самых первых рук совершенно противоречит твоим заявлениям о незначительности обратной совместимости и давности реализаций многих аспектов компилятора.
Где эта информация? И почему МС решились положить толстый ... на весь С++ и сейчас переориентируют кучу кода под тот же C#? Не уж то это дешевле нежели написать компилятор снуля?
ПК>Ну, мне гадать ни к чему. Я только передаю то, что слышал от команды VC++. Впрочем, их голоса по этому поводу тоже звучали не очень уверенно, так что, как я понимаю, с планами окончательной определенности там еще тоже нет.
Во-во. Судя по тому как спускается на тормозах C++/CLI (до сих пор приличной бэты нет). Для них и C++/CLI баловство.
ПК>Пока что, от тех, кто переносил реальные проекты, я встречал не столь оптимистичные суждения.
А какие встречал? Из твоих слов можно подумать, что есть какие-то проблемы. Только я вот их почему-то не встречал. С чего бы это?
Уж или потрудись обосновать наличие серьезного количества проблем, или не нужно пытаться приводить их отсуствие за "малое количество информации".
Я тебе уже сказал, скачай Моно и скомпилируй его с помощью VS и компилятора C# от МС. Тма проект просто огромный. Если проблемы есть, ты их увидишь. Я это делал и проблем не обнаружил.
Проблемы совместимости между Моно и Дотнетом лежать совсем в других плоскостях. Они в количестве и соотвествии библиотек. Так до сих пор нет аналога ВыньФормс. А вот веб-проекты переносятся без особых проблем. Причем конкретно с языком я вообще проблем не встречал.
Так что если, они есть то милости просим дать ссылки. А иначе не стоит на них упавать.
ПК>Проблемы компиляторов C++ точно такие же проблемы "в софте".
Да? И отсуствие фич, это всего лишь ба? И то что верный код компилируется по разному? Подобных проблем я что-то в Моно и Шаре не замечал. Не верный иногда обрабатывается по разному, а вот верный вроде как без проблем.
ПК> Там, где есть разное поведение, есть и указания, что должно быть по стандарту.
Дык проблем, в том, что оно разное не смотря на стандарт. Ну, не могут спецы из багатейших контор просто выполнить спецификацию. И это факт. А вот ты сам сказал, что реализовывать, то даже меньше чем в случае шарпа (а уж если если сравнивать весь дотнет...).
ПК> Ключевое отличие компиляторов C++ от компиляторов C# — разница в возрасте, значение которой ты упорно не хочешь признавать или понимать.
Да, упорно не хочу. Я считаю, что разница в возрасте и совместимость тут не причем. Всему виной упорное цепляние за отжившие догмы и нежелание что-либо менять. Большинство программистов использующих С++ в своей работе бревна в нем не замечают, при этом постоянно понимая вопрос о том зачем нужед дотнет и т.п. Да что там. Страуструп несет такое, что смешно становится.
>> Продумывание грамотной интеграции конечно в задачи тех, кто придумывал язык и писал его спецификацию не входило. Логично.
ПК>Снова о том, "как корабли бороздят просторы космоса"?
Нет, снова о качестве языка и спецификации.
ПК> Может, ты все-таки перейдешь от риторики к конкретике? К примерам, приведению каких-нибудь сколько-нибудь точных результатов и т.п.?
Про точные результаты я уже задобался говорит. Если я тебе еще раз указу, на грабли, неопределенности, отсуствие важных аспектов в описании, и т.п. ты же снова потреуешь чего-нибудь трудно реализуемого (типо цифр по количеству граблей) или начнешь говорить, уходить от темы сваливаясь на частности. Все проблемы ты сам прекрасно знаеш. Не знает о ни только ленивый.
ПК>Не совсем туда смотришь. Та работа в основном была посвящена GCC, VC++ приводился в качестве сравнения.
И тем не менее ссылка классная!
>>
>> Проудкт год выпуска процент успешных тестов
>> VisualC++ 6.0 1998 73.6
>> VisualStudio 7.0 2000 77.1
>>
>> и того у МС просто грандиозный рывок! За 2 года аж 3.5%! Если так дело пойдет и дальше то, им осталось 6.5 лет до полного соответствия. Хотя 7.1 отличий от 7.0 практически не имеет
ПК>Ты уверен, что достаточно глубоко ознакомился с предметом? VC++ 7.0 и 7.1 в плане соответствия стандарту — небо и земля.
Я уверен, что идет очередная попытка уйти всторону. Да и снова преувеличения. Никакой там земли и неба нет. Список изменений умешатся в одном абзаце.
ПК> Два ключевых понятия, дающих представления о характере различий: частичная специализация шаблонов классов (partial specialization), ПК>аргументно-зависимый поиск имен (ADL). По результатам тестов измерения соответствия стандарту, насколько я помню, VC++ 7.1 показывает цифры около 98%.
98% МС заявлял еще в 7.0. Теперь это уже должно быть 103%.
ПК>Модули вещь хорошая.
Ну, так может признать то, что отсуствие их в С++ и уход спецификации С++ от их описания — это болшая брешь в них?
ПК> Но к бинарной совместимости не относящася.
Гы. Бинарной совместиости нет даже в Шарпе. Но вот, наличие модулей позволило бы сделать и это. А когда нет вообще никакой отправной точки для совместимости, то и появляются кучи уродов.
ПК> О бинарной совместимости мы уже закончили? Примеров языков, специфицирующих эти "важнейшие аспекты построения компиляторов и рантайм-систем", приводить не будешь?
Это тебе очень хотелось поговорить о бинарной совместимости. Я же говорил о моудулях и отсуствия их описания в С++. Просто как всегда тебе оказалось приятнее обсудить несколько другую проблему придравшись к неосторожно сказанному слову. Ну, что же я к этому уже привык.
Так что признаем недостатком стандарта С++ отсуствие разделов говорящих о модулях и принципах компиляции с их использованием?
А так же признаем недостатком то, что в языке нет конструкций отличных от #include позволющих импортировать типы из вне?
Ведь все это к бинарным стандартам не относится. Так что не включать их в спецификацию можно только если данные аспекты неважны.
ПК>Тезис о лучшей кроссплатформенности (переносимости) Java и .Net подтверждать данными каких-нибудь объективных исследований будешь,
О требуется? И так извесно, что Ява на сегодня есть везде где для нее находятся ресурсы. А плюсы как-то так и не получили признания в качестве эталона переносимости. С в этой области по прежнему впереди.
Ну, и такие выводы можно легко сделать ознакомившись с целями разработки этих систем.
ПК> или это твое личное мнение, в обоснованиях не нуждающееся?
Это мое лично мнение сформированное на большом количестве фактов.
А ты берешся утверждать обратное? Или просто таким образом решил невелировать мое мнение?
ПК> Cсылки на реальные проблемы с переносом программ на Java и .Net я приводил, так что утверждать об их отсутствии по меньшей мере некорректно.
Ссылки на проблемы ровном счетом ничего не говорят. Проблемы есть всегда. Важено только решаются ли они, насколко их много и насколько они существенны. Я могу привести тоже не мало ссылко на проблемы переноса С++-программ на другие платформы.
Так что не надо в очередной разок пытаться заставлять других оправдываться на ровном месте.
>> А не нужна бинарная совместимость для разных платформ. Нужно ввести в стандарт понятие модуля, метаданных и других вещей. Тогда подобных проблем или вообще не будет, или не будет хотя бы на одной платформе.
ПК>Ага, уже лучше.
Ну, слава богу. Жаль, что эти слова у тебя выступают только как присказка. Хоть бы разок услышать как ты изменишь мнение.
ПК> Но и этого не достаточно: и на одной платформе проблемы точно так же могут быть.
Могут быть. И точно будут вещи разные. Понятно, что всех проблем это не решат, но тем не менее это хорошая предпосылка для их решения. А умалчивание почти гарантия, что проблемы появятся.
>> Пашь, так сделай заявление! Одно из двух. Или проблемы есть. Или их нет. Не может же быть в данном вопросе промежуточного состояния. Сфероконики в природе не водятся.
ПК>Проблемы есть
Неможет быть? Я в это не верю..
ПК> у всех языков
фух. А я то грешным делом подумал, что ты признал очевидное. Ну, да ладно.
ПК> и у всех соответствующих спецификаций. И C++, и C#, и Java в этом отношении исключениями не являются. Вот только без объективных данных делать заявления о количестве искомых проблем, имхо, некорректно.
Дада. Прием извесный. Обощаем все до предела и на уровне сфероконика можно согласиться с чем угодно. Все равно смысла
то уже не имеет.
Так если без обобщений. Есть проблемы у С++ и его стандарта? Много ли их? Влияют ли они на качество С++ и/или стандарта?
>> Да? Я вот мне кажется, что ты уклонился от прямого вопроса. Так все же является ли качество языка следствием качества проектирования или качества языка никак не связано с качеством проектирования?
ПК>Проектирования? Конечно. Но мы говорили о стандарте.
А он не есть спецификацией рожденной в процессе проектирования?
ПК> Напоминаю, что языки C и C++ появились и реально использовались до того, как были составлены соответствующие стандарты.
Напомню, что это авторские языки. У них никогда неблыо параллельных вариантов. И их авторы были вольны делать языки такими какими хотили. Так что никто не мешал проектироваь их грамотно. И ут тем более никто не мешал не принимать в качестве стандарта все ошибки.
ПК> Проектирование традиционно, все-таки, предшествует выпуску продукта, соответственно, проектирование языка должно было произойти до реализации компиляторов, каковая, как нам известно, предшествовала составлению стандартов.
Нет. Уж стандарт — это всего лишь акт принятия спецификации. А вот специяикация является непосредственным процессом проектирования языка.
>> Из твоих слов можно сделать вывод, что С++ вообще нельзя сравнивать с другими языками, так как он делался для удовлетворения желаний Страуструпа.
ПК>Это неверный вывод.
Как? Ты же именно по этому упорно уходишь от всяческих сравнений и оценок. Или есть еще какая-то причина? Не уж, то ты за столько лект программирования на этом языке не получил о нем представления достаточного для сравнения его с дуним?
ПК>Я избегаю сравнений в терминах "криво" и т.п.
А в каких не избегашь? Можно примерчик? А то ты постоянно проворцирушь других на высказывания, а сам постоянро от них уходишь. Одни намеки.
ПК>С первым можно и не трудиться сравнивать: в реальных программах на C# первой версии, как и в Java, столько неизбежных приведений типов,
О... тут хочется сделать аж несклько возражений :
1. Сколько, Паша? Сколько? Не уж то ты сожешь аргументировано доказать, что их так уж много.
2. Почему первых версий? На дворе Ява 1.5 (заметь, релиз!). И второй фрэймворк. Я так с бОльшим удовольствием буду сравнивать именно с последникм. И, думаю, ты догадывашся почему.
3. Данное высказывание является грубешой подменой понятий. Приведение типов в рантайме еще не делает язык типобезопасным. Есть такое понятие как автоматическая проверка типов в рантайме. А то понятие которым ты пыташся подменить типобезомаснсть назвается статической типобезопасностью. Какова же цеть подмены понятий. Мне кажется в очередной раз увести обсуждение в сторону.
ПК> обусловленных отсутствием параметризации, что статическая проверка отдыхает по полной программе.
Ага. Вот только остается понять. Ты непрвду говоришь намерено, или просто заблуждаешся.
ПК>1) От реального компилятора C++ ты получишь предупреждение,
Не от реальных, а от некоторых, и на некотором уровен варнингов.
ПК> каковое, если тебе хочется, ты можешь превратить в сообщение об ошибке.
А могу я это превратить в строчку в стандарте, чтобы вообще проблем небыло? А вынести адресную арифметику в какой-нибудь ансэйф-режим?...
ПК> Это был сознательный выбор при проектировании языка.
Да? Ой как хочется услышать обоснование этой "сознательности".
ПК> Причины такого поведения можешь найти в "Дизайне и эволюции языка C++".
Не, не. Посылать не нужно. Ты уж давай или цитату. Или своими словами. Ну, и коментарий личный было бы интересно услышать. Ну, в разрезе современного положения дел и современных требований к надежности и безопасности.
А то ведь от таких посыланий ценность подобных высказываний для народа читающего нашу переписку стремится к нулю. (с)
ПК>2) Это семечки по сравнению с невозможностью в C# (в том числе и, насколько я понимаю, второй версии) обеспечить тот уровень статических проверок, который легко достигается в C++.
Это мнение? Или будешь подтверждать.
ПК>Пример тебе уже приводили: проверка размерностей в физических выражениях во время компиляции.
Извини суть того примера я так и не уловил. Более того он мне показался бредовым.
ПК>Ничего не мешает. Стандарт явным образом разрешает такой вариант развития событий как сообщение об ошибке во время компиляции или во время исполнения. Неопределенное поведение на конкретной платформе вполне может проявляться так, как посчитают нужным разработчики компилятора. Прецеденты подобных проверок вполне имеются.
Ну, т.е. все ОК? И то что это баг для любого разумного программиста — это к дело отношения не имеет. Качество языка от этого не страдает. "Гробь приложение как хочешь — мы тебе поддержим."
Здорово. Нечего сказать. А зачем тогда было курочить систему приведения типов С? В нем это можно было делать еще лучше.
Так что получается, что попытались сделать типобезопасность, но не получилось. А теперь прячемся за стандартом.
>> Ах совместимость с С... Понятно. И ведь даже в голову не приходит, что код С и С++ может компилироваться по разным правилам. И что совместимость от этого не пострадает.
ПК>Нет, в данном случае вовсе не совместимость с C, а возможность реализации наиболее эффективных приложений, непосредственно работающих с аппаратной платформой. Ты совершенно упускаешь из виду, что C++, в отличие от C#, по своему назначению является языком системного программирования.
Из этих слов я делаю вывод, что ты исходиш из предположений:
1. Сто C# не имеет возможности наиболее эффективных приложений, а С++ имеет.
2. Что у C# как языка (а не конкретной реализации на CLI/дотнете и т.а.) есть какие-то особенности не позволяющие ему непосредственно общаться с аппаратной платформой.
3. Что С++ является системым языком, а не универсальным.
4. Что типобезопасность противоричит эффективности и/или системности.
Так?
>> Да и о какой совместимости речь? С99 напрочь не совместим с С++. Значит совместимость не так и важна?
ПК>Совместимость важна. С99 не так уж и не совместим c С++, а после выхода следующей версии C++, эта разница станет еще меньше.
Очень, очень. Там появились массив как объекты высшего порядки и т.п. Скомпилировать программу написанную с испоьзованием фич С99 нельзя ни на одном компиляторе С++.
ПК>Большее количество ключевых слов или конструкций не означает большую сложность языка.
Зависит от критериев. С точки зрения синтаксиса неоспоримо сожнее.
ПК> Мнения мне не интересны.
Так не выражай их. А то никаких вот заявление выше на обоснованное утверждение не тянет.
ПК> Если у тебя есть ссылки на работы по этому поводу — милости прошу.
А иначе что? Мне вполне достаточно просто сравнить языки.
Попробуй перечислить понятие С++ отсуствующее в Шарпе. На на оборот можно делать довольно долго:
1. Свойства.
2. Итераторы.
3. События.
4. Делегаты.
5. Атрибуты.
6. Аномнимные методы.
7. forech
8. finally
9. Ссылочный тип данных.
10. Вылью-тип.
11. Базовый тип перечисления.
12. Ансэйф
13. Сборки (модули).
14. Импорт внешних функций.
15. Констрэйны.
16. Встроенные сложные объекты (массивы/строки).
17. Автоматическое управление папятью.
18. Унификация типов.
19. Индексеры.
10. Конструкторы типа.
11. Инетерфейс.
12. Наследование интерфейса.
13. Partial-типы.
14. Версионность.
15. Алисаы пространств имен.
16. Обобщенные интерфейсы и абстрактные классы.
17. Рефлекшон.
18. Enumerator.
19. Автодокументирование в коментариях.
Это только отсуствующие и не имеющие аналогов понятия. Причем многие из них сами по себе являются комплексными и содержат в себе кучу подпонятий.
>> ПК> Заметь, я не утверждаю ни что C# проще, чем C++, ни что он сложнее. Только отмечаю, что я не видел подобных данных.
>> Так все же утверждал?
ПК>Нет.
Я я тут рядом где-то читал, что все же проще. Вроде твоей рукой было написано. Ну, раз ты отказываешся от этих слов...
>> Ну, так может, ответишь на искусно обойденный вопрос о критериях сложности? Вопрос то ключевой! Критерии то бываю разные.
ПК>Да, критерии бывают очень разные. Тут мы с тобой, как мы уже выяснили, расходимся. Тебе достаточно изложенных тобой положений и субъективной их оценки для подобных сравнений, мне — нет.
Ну, если отбросить ярлыки, то не такие уж и субхективные мои критерии. А так как им ровным счетом ничего не потивопоставлено, то вообще не ясно о чем разговор.
А то ситуация какая-то странная. У самого нет даже намека на критерии. Но чужие пыташся выставить неверными. Причем так... в заявительном порядке. Мол у мнея мнение, что твои критерии и аргументы субъективные.
>> Ответь хотя бы на вопрос почему нельзя сравнивать размеры и сложность языков?
ПК>Можно. Но не уровне субъективных критериев, без привлечения эмоций ("низводить до ничтожества"), и использования в качестве аргументов того, что требуется доказать ("несомненно проще").
А доказывать, утвердения о субективности критериев нужно? Или они и без этого весомы и верны?
ПК>Я не вижу, чтобы здесь были серьезные аргументы "явно не в пользу C++". Я вижу твои об этом заявления.
А я вижу заявления, что у меня только заявления. Что дальше?
Сравнивать ты бошися. Требущь ссылок на какие-то мифические труды. У меня их нет. Но тем не менее аргументов достаточно. С другой стороны для того, чтобы удостовриться в моей правате достаточно просто самому беспрестрасно проанализировать те же стандарты. Но этого ты делать не хочешь. И всечески делашь вид, что этого недостаточно.
ПК>Ну, как мы выяснили, для тебя это одно и то же, что утверждение об удачности самого языка, поэтому, имхо, можно и не выделять спецификацию в отдельный пункт...
Не одно и то же, а зависимые вещи. Неудачность языка следствие неудачности спецификации.
>> И с тем, что С++ удачный язык не требующий изменений.
ПК>Тут сразу два пункта. 1) Считать ли C++ удачным языком — зависит от того, что вкладываешь в слово "удачный".
По-моему, я уже не раз это описал.
ПК> В соответствии с моими критериями, C++ — вполне удачный язык.
Это ничем не обоснованное мнение. Ценность которого стримится к нулю (с)
Если серьезно, ты даже своих критериев не выскзал. Все пытаешся обосновать необоснованность моей позиции.
ПК> 2) Изменений C++ требует. Против этого, по-моему, никто и не возражает...
1. Взражают.
2. Опять же каких.
Ну, и возвращаясь к исходному сообщению, тогда не ясно зачем было вообще поднимать весь разговор если ты согласен с проблемами. Я всего лишь указал, что Оберощики используют проблемы С++ в целях превознесения их убогого языка. А на самом деле есть языки не имеющие этих проблем, и в то же время не стольк убогие как Оберон. Так с чем ты был не соглсен? Или просто до слов было охота докапаться?
>> Ну, и с тем "единственной задачей спецификации является точное описание языка". Спецификации порождает язык. И основная (заметь, не единственная) задача спецификации породить качественный язык с минимумом неопределенностей и проблем.
ПК>Ну, с моей точки зрения, это расходится с действительностью, т.к. те же C и C++ родились еще до соответствующих стандартов.
А с моей, снва идет подмена понятий. Спецификация была до стандарта. Так понятнее?
ПК> Соответственно, стандарт может уточнять язык, но создание языка ему предшествует.
Старая песня. Отвечать не буду.
>> Стало быть задачу создания качественного компилятора решить очень не просто.
ПК>Да это так. Никто и не утверждал, что это тривиальная задача.
Ну, так чем тебя тогда не устраивает мое мнение о том, что это недостаток этой спецификации?
ПК>В качестве посылки ты используешь недоказанное утверждение. А именно: "язык особой сложности не представляет".
Назови мне хотя бы один технический критерий по которому он сложнее всех остальных если отбросить запутанность и неопределенность.
Я лично не вижу особых сложностей. А вот неопределенности вижу. И вижу, что именно они создают трудности при реализации компиляторов. Ну, в чем был бы проблема добавить такую фичу как экспорт шаблонов если бы это не приводило к внутренним проблемам реализации? Фича то простая как три копейки. Вот только нестыкуется она, с тем, что шаблоны не могут быть превращены в полностью детерминированную промежуточную форму. Вот и получается, что что-то экспортировать можно. Но траха от этого можно, а толку чуть, так как экспотрируется рактически скан лексического анализатора.
>> Буст, Локи используют побочные эффекты этой спецификации которые она даже не декларировала.
ПК>А именно? Конкретные примеры, пожалуйста. А то, что-то с телепатией у меня уже совсем плохо...
Да все ты прекрасно понимашь. Эмуляция функцинальных вычислений на базе эффекта рекурсивного определения шаблона со специализацией вместо граничного условия — это как? Задумывалось ли стандартом такое поведение? Где в С++ вообще хоть слово о возможости вычислений в компайл-тайме (кроме как инициализации константными выражениями)?
>> STLport всего лишь реализация спецификации появившейся где-то в 1992.
ПК>1998.
Открываем исходник STL в VC и читаем коментарий:
/*
* Copyright (c) 1992-2002 by P.J. Plauger. ALL RIGHTS RESERVED.
* Consult your license regarding permissions and restrictions.
V3.13:0009 */
ПК>Не вполне. Хотя есть некоторые техники, позволяющие реализовать значительную часть оптимизаций STLport и на VC++6,
Оптимизации — это уже дело десятое. К нашему вопросу не относящееся.
>> Вместо boost и Loki лучше было ввести необходимые средства в язык.
ПК>Это еще один очень спорный тезис.
Ну, ты же спорить не будешь? Ведь у тебя как вседа недостаточно довыдов.
>> Про Blitz и Pooma и сегодня мало кто слышал и они мало кому нужны.
ПК>Да уж конечно. Если ты не слышал, не значит, что никто не слышал.
Можно устроить голосование и зунать какое количество слышало, какое использовало, а какое реально использует. Проводим? Или на слово поверишь?
ПК> Это именно те библиотеки, которые "порвали" Фортран в матричных вычислениях благодаря использованию template expressions.
Да я как бы в крусе. Вот только они нужны в основном узкому кругу лиц, и чтобы доказать, что можна парвать фартран....
ПК>Это пример, иллюстрирующий тем, кому это интересно, реальные причины, почему те или иные несоответствия стандарту не исправляются. Соответствие стандарту в каком-то воображаемом режиме, не используемом в реальной жизни, пользователям мало интересно.
Это не правда. Еще в МС С 4-5 были ошции совместимости стандарту. И это прекрасно работало. Я учился писать на K&R и по началу долго не мок привыкнуть к ограничениями, но тем не менее спокойно компилировал код не соотвествующий стандарту.
ПК>Включая и результат. Для меня мерилом результата является соответствие языка тем задачам, для которых он создан.
Веское обоснование. Правда если его экстраполировать, то это как раз то почему он погибнет. Ведь многое из того за что держится этот язык становится все менее и менее актуальным. Совместимость с С. Уже мало важна. Ее достаточно на уровне импорта С-шных функций. Легкость в переходе на небезопасное программирование вообще начало считаться не благом, а злом. В общем, при таком расскладе языку одна дорога в низкоуровневое программировние. А от туда еще С никак не удается выбить.
ПК> А то, нравится ли он всем на планете Земля или нет, мне совершенно не интересно.
Что тогда споришь?
ПК>Это совершенно сознательное решение, являющееся следствием того, как работали/работают конкретные аппаратные платформы, с которыми языки C и C++ призваны непосредственно взаимодействовать. Возможно, вследствие почти полного исчезновения таких экзотических платформ, это правило будет изменено в следующей версии стандарта.
И что же такого дает данная неопределенность?
А вот то что возможно изменнение только подверждает, что это чистой воды недоработка.
Один фиг человека написавшего подобное можно смело увольнять за экстремистскиие выходки.
ПК>Нет, это следствие того, что те, кого ты называешь "мало-мальски грамотными авторами языков", проектируют языки для несколько других задач.
Ну, поделись для каких же? Чем они другие? Пока что это чисто голословное утверждение.
ПК>Для этого есть опции компилятора, которые ты вполне можешь использовать и сегодня. А создание прагм для переключения семантики языка — дело гиблое, ибо приводит к созданию диалектов, и реальным проблемам при переносе фрагментов кода из одного участка, контролируемого одними прагмами, в другой.
Это не важно. По факту есть грабли обосновываемые сложностью включения опции в компилятор.
ПК>Не вопреки, а благодаря.
Может и не вопреки, но точно не благодоря. Просто стандарт тут идет по боку.
ПК> Еще раз: стандарт специально составлен так, чтобы у разработчиков компилятора была возможность реализации подобных проверок без нарушения стандарта.
Это скорее случайнось. с теми же указателями вывернуться не удается.
>> Еще раз. Цена вопроса — введение уровня совместимости с унаследованным кодом. А то и просто объявление наплевать и растереть. Со временем бы все подтянулись.
ПК>Спорный вопрос. В этом пункте мнения разработчиков языка, да и мое тоже, с твоим разошлись.
Ну, так укажи в чем и обоснуй. А то от таких слов читателю...
ПК>Задумался. Поэтому и тянули с введением этих несовместимостей.
Ну, ввели же? Так в чем проблема?
ПК>В .Net по спецификации нет проверок при выходе за границы массивов в результате адресной арифметики.
Ты прекрасно знаешь, что сама адресная арифметика существует в специально ограниченом ансэйф-контексте. И что она вообще не нужна на практике. Разве что драйверы или ОС писать. А в С++ это при работе со штатным массивом.
ПК>Это проблемы тех, кто работает с указателями. Никто их к этому не принуждает. Вот такая, быть может, не нравящаяся тебе философия языка.
Никудышная это философия. Когда я начинал программировать, я мне она очень нравилась. Я это тогда называл "гибкостью". А потом, когда пришлось поглядеть на последствия этой гибкости... причем зачастую сделанными не собой... и когда увидел, что можно жить по другому без особых последствий, то понял, что был не прав.
ПК>У C# совсем другая объектная модель, чем у C++. Это совсем другой язык, похожий на C++ только синтаксисом.
Другой. Но указатели от этого нужнее не становятся.
ПК> У C++ другая, хотя частично и пересекающаяся с C#, область применения.
Да нифига она не другая. Это догма которую ты себе втемяшил в голову. Я тебе уже кажется предлагал ее доказать.
>> И есть полноценные заменители указателей вроде массивов и ссылочных типов.
ПК>Это не замена.
Это именно замена. Об этом говорили авторы языков в которых эта замена появилась. Так что не надо.
ПК> Это для других вещей.
Это каких же?
ПК> Весь C++ изначально предназначен именно для того, для чего в C# создан unsafe.
Во оно как? Можно поинтересоваться что-то такого шешь сейчас или писла ранее, для чего тебе так дико были необходимы грабли?
ПК> Весь. И отлично с этим справляется. Его использование для более прикладных задач требует большей квалификации, чем использование C#.
Траха, траха больше требует. А квалификацию можно потратить на более эффективное или быстрое решение задачи.
ПК> Но некоторые вполне согласны заплатить эту цену за большие выразительные возможности языка,
О! Еще одно необоснованное утверждение.
ПК> и находят его использование для прикладных задач вполне удобным.
Ага. Я даже знаю как их зовут... Мазохисты.
ЗЫ
После появления человеческих средств мета-программировни, АОП и улучшения качества оптимизации кода, я вообе не дам за С++ и ломоного гроша в прикладной области. Ну, а для жизни на грани системной он еще долго протянет.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Пожалуйста, перечисли, что именно не позволяет в шаблонах создать приемлемую промежуточную форму, и что является приемлемой промежуточной формой?
Не совсем в шаблонах. Тут накладывается несколько факторов.
Сумма невозможности детерминирования некоторых синтаксических конструкций без информации о типах, отсуствие ограничений (а стало быть невозможность передать информацию о итпах в шаблон во время его парсинга), допустимость неверного синтаксиса до конкретного применения в купе приводят к тому, что промежуточная форма обызана быть слишком абстрактной и по ней невзможно осуществить качественной семантический контроль. В итоге получается, что создать то его можно. Но овчинка не стоит выделки.
В итоге, многие компиляторы вообще плют на парсинг шаблонов до их воплощения.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Прямо он ссылается на "библиотечную" часть. Я искал в стандарте C# требования к формату сборки или что-нибудь в таком роде, пытаясь определиться со своим ответом на твой вопрос
. К своему удивлению не нашел.
> <...> я правильно понимаю, что данные твои слова можно интерпретировать как отказ от: >
ПК>А еще для X86, Solaris, Macintosh и прочих платформ, на базе которых можно построить абстрактную машину, описанную в стандарте C++. Иными словами стандарт C++, в отличие от стандарта C#, от .Net/CLI не зависит. И наоборот, стандарт CLI от стандарта C++ тоже не зависит.
> ?
> Ну, что ты береш свои слова обратно
Ну стандарт C# от стандарта CLI зависит совершенно явным образом, поэтому тут отказываться не от чего.
> и соглсен, что и C#, и C++ могут быть реализованы отдельно без привязыки к разным там реализациям CLI?
А вот здесь еще не знаю. Сначала был в этом уверен, теперь — нет. Разбираюсь. По крайней мере, часть библиотек, описанных в стандарте CLI, C#, в отличие от C++, требует. Это факт. Осталось разобраться, требуется ли этой части библиотек что-то собственно от платформы, или же это только спецификация относительно небольшого набора интерфейсов.
> модульность, на сегодня ой как востребована. И то, что стандарт плюсов обходит этот момент <...>
Сегодня обходит, завтра, может, не будет обходить. Поживем — увидим. Если модули появятся — просто супер, но и без них вполне жить можно.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>И вот тут возникает вопрос. Почему такие бабки кладутся на разрботку нового языка — сишарпа, и упровляемой среды упровления? Ведь С++ так крут, что казалось бы в него то и нужно бабки вбухивать. А они так тебе. Вкладывают в "почти скриптовый" язык. Тут были товарищи сравнивающие этот язык с Питоном и метившие ему место в качестве средств написания юнит-тестов. Почему же такая странная оценка МС? Зачем они с Саном переругались только ради права улучшения ява-машины и языка Ява? К чему такие затраты?
Дык, тебе уже вроде ответили, а ты опять спрашиваешь:
Весь C++ изначально предназначен именно для того, для чего в C# создан unsafe. Весь. И отлично с этим справляется. Его использование для более прикладных задач требует большей квалификации, чем использование C#.
Сейчас надо писать не много программ, а очень много. Держать дорогих программистов — накладно. На фирмах сидят под сотню прогеров, им надо кнопки нафиг на формы бросать, перехватывать Click-и, читать записи из базы данных, находить среднее арифметическое, применяя правила округления, рисовать отчеты и разукрашивать каждую нечетную строку в них, выделяя жирным итог.
я тебя убедительно прошу читать сообщения целиком, до того, как ты начинаешь отвечать. Иначе вести беседу с тобой чрезвычайно затруднительно, т.к. по ходу составления ответного сообщения ты задаешь множество вопросов, ответы на которые ты мог бы получить, прочитав один-два следующих абзаца.
Кроме того, так как сообщения разрослись до сложнопотребляемых размеров, в этом я касаюсь только вопросов соответствия компиляторов стандарту. Ответы на сравнения с другими языками пойдут в другое сообщение, которое я напишу позже. Сюда вопросы сравнения языков, пожалуйста не примешивай — а то совсем каша, а не обсуждение получается.
> ПК> С 1998.
> Не, с 89-го. 98 — это дата выхда последнег стандарта.
Первого. Вторая версия того же стандарта, она же пока последняя, вышла в 2003 году.
> А 89-ых — это год когда появились шаблоны и вообще язык можно было назвать состоявшимся.
Назвать язык C++ образца 89-го года состоявшимся (если понимать под этим совпадение с современным C++) — по меньшей мере, сильное преувеличение:
В июне 1989 года вышла версия 2.0 компилятора Cfront, в которой, в дополнение к возможностям, введенным в версии 1, были добавлены: множественное наследование, декорирование имен, изменения правил поиска имен перегруженных функций, абстрактные классы, статические и константные функции-члены и т.п.
Назвать то, что было в версии 2.0 современным C++ нельзя и близко: еще не было ни шаблонов, ни вложенных классов, ни исключений, ни многих других атрибутов современного C++. Да и многие из тех вещей, что пересекались с современным C++, там были определены совсем по-другому.
И хотя шаблоны в виде проекта существовали еще с 1986, их первые реализации в версиях Cfront 1989-1990, последовавших после 2.0, были очень и очень далеки от того, что мы имеем сейчас.
Поближе к современному языку было то, что содержалось в "Annotated Reference Manual", вышедшем в мае 1990. Там были добавлены: шаблоны, исключения, вложенные классы и некоторые другие возможности. Но по-прежнему не было ни пространств имен, ни RTTI, ни новых приведений типов, ни явного инстанцирования шаблонов, ни возможности указания аргументов шаблонов при вызове шаблонов функций, ни многих других менее значительных деталей современного C++. И, снова-таки, семантика значительного количества конструкций языка в разной степени отличалась от современной.
Подобная эволюция и является причиной многих трудностей разработчиков по приведению своих компиляторов в соответствие со стандартом, т.к. многие архитектурные решения те, кто взялись за реализацию компиляторов C++ еще в те времена, принимали на основании дизайна языка, очень сильно упрощенного по сравнению с современным. А некоторые, как Майкрософт, унаследовали общую архитектуру своих компиляторов еще от компиляторов C, имевших к тому моменту свою историю.
А если посмотреть на функциональность, добавлявшуюся к языку после начала процесса стандартизации, то можно увидеть, что именно интеграция этих новых возможностей (пространства имен, ADL, перегрузка, частичная специализация и перегрузка шаблонов и т.п.), привела к значительному усложнению языка, делая его тем монстриком, которым он является сегодня. Причем поэтапное добавление этих моментов далеко не всегда во всех деталях можно было гладко вписать в архитектуру существовавших компиляторов, что приводило ко все новому и новому усложнению их реализации и внесения последующих изменений...
>>> ПК> В Microsoft до недавнего времени на стандарт плевали с высокой колокольни, и занялись поддержкой оного, когда увидели, что это становится, действительно, важным для их пользователей.
>>> Да то, что это важно для пользователей они поняли еще гду в 90-ом.
> ПК> Откуда дровишки?
> Да из появления VC. А вот откуда твои дровишки? Кто тебе сказал, что они не хотели совместимости? Может они просто не в сила были ее обеспечить...
Ну это зависит от того, кто "они", и что понимать под "не в силах были ее обеспечить". Итак по пунктам: "Они"...
Если под "они" понимать Майкрософт в целом, то для компании Майкрософт совместимость со стандартом где-то до релиза 7.0 была на одном из последних мест в списке приоритетов, т.к. у компании было несколько очень крупных клиентов, для которых обратная совместимость была намного важнее.
Если же под "они" подразумевать, скажем, команду разработчиков компилятора, то тут, вообще, можно целую книгу написать о любви и ненависти разработчиков Майкрософт к стандарту. Книга строилась бы по принципу ромашки: "Любит — не любит, любит — не любит, любит..."
Вкратце: изначально разработчики Майкрософт бросились к стандарту в объятья. Тут можно упомянуть и то, что вторая встреча комитета стандартизации проводилась в помещении Microsoft в июле 1990, и то, что они оперативно отслеживали изменения в стандарте, и с энтузиазмом реализовывали самые новые "фичи"...
Однако это обернулось для них боком, когда несколько раз случилось так, что комитет отменял или изменял только что реализованные разработчиками Майкрософт аспекты языка. Доходило даже до того, что изменения происходили после релиза Майкрософтом очередной версии (так, например, случилось с изменениями в поиске имен вскоре после выхода версии VC++ 5.0).
В итоге примерно ко времени разработки версии 6.0 энтузиазм разработчиков по поводу быстрого отслеживания развития стандарта серьезно поутих. К тому же, как уже раньше писалось, у ребят и без того была масса работы по развитию компилятора и среды. Дошло даже до того, что, как тоже упоминалось выше, Майкрософт была лишена права голоса в комитете из-за пропуска нескольких заседаний комитета (а это немало, учитывая, что встречи проводятся всего два раза в год).
"не в силах были ее обеспечить"...
Эта фраза вполне подходит к ситуации, в которой оказалась Майкрософт, когда дело дошло до выпуска VC++ 6.0.
Во-первых, на момент заморозки изменений в шестой версии, стандарт еще не был выпущен.
Во-вторых, учитывая уже не такое оперативное отслеживание разработчиками эволюции черновика стандарта, компилятор от него несколько подотстал. Фактически можно сказать, что VC++6.0 очень неплохо соответствовал черновику стандарта, но на время, несколько предшествующее его выпуску.
В-третьих, и это было самым существенным препятствием, у компании Майкрософт было несколько очень крупных клиентов, которым они продавали очень значительную часть своих продуктов разработки приложений. Как показал опрос, проведенный Майкрософт, этим крупным клиентам вовсе не нужно было соответствие стандарту. Им нужно было улучшение средств разработки без нарушения обратной совместимости.
В общем, как это ни называй, но в 1998 году у Майкрософт не было цели обеспечивать полную совместимость со стандартом, а только лишь в степени, нужной клиентам, главные из которых в этом отношении были весьма нетребовательны:
> Even better would be a commitment by Microsoft to comply and a timeline for that compliance. Is someone aware of such commitment?
There is no such commitment. <...> we have to decide, based on numerous factors, what work will get us farthest towards our goal.
Что в итоге и привело к тому, что VC++ 6.0 в плане поддержки стандарта от 5.0 отличался незначительно. Это вполне устраивало большие компании, но, естественно, привело к недовольству множества "маленьких" пользователей:
> So, not putting any improvements in VC6 *has* demonstrably lost you at least one customer. I'm probably not the only one in a similar position.
If your only concern is C++ conformance, then I agree with your estimation. But there *are* significant improvements in programmer productivity available in VC6.
И эта ситуация продолжалась до следующего релиза, 7.0 (.Net 2002), в котором потихоньку, преодолевая инерцию "больших" клиентов и под давлением множества "маленьких", началось движение в сторону совместимости со стандартом:
MS get's feedback from their enterprise customers. Those customers that they sell the largest number of copies to. Unfortunately (and i've discussed this with VC development members), there isn't a reliable way to get feedback to MS about the next version of VC from the little guy. Hopefully that will change.
Поворот Microsoft в сторону улучшения соответствия компилятора C++ стандарту ознаменовался и приходом в Microsoft таких известных людей, как Стэнли Липман и Герб Саттер, который прямым текстом начал говорить об этих изменениях в политике компании:
According to Sutter, to whom SD Times spoke in mid-March, before he officially started work at Microsoft, Visual C++ 6.0 was not particularly compliant with the C++ specs; Visual C++ 7, which shipped in February 2002 as part of the Visual Studio .NET suite, was better but still had room for improvement. The company is completing the next version of Visual C++, which he estimated will be about 95 percent compliant with the specs. “Microsoft is doing some catch-up right now,” he said, “because the emphasis on conformance is fairly recent. But it’s real.”
> ПК> В 1990 еще стандарта и в помине не было.
> С++ был. СТЛ был.
С состоянием языка на 1989-1990 год мы разобрались чуть выше. Относительно же STL можно заметить, что ее наличие не означало ее известность. Скажем, комитет одобрил ее только в 1993 или 1994 году, когда, собственно, и появилась возможность с ней ознакомиться по работе: Alexander Stepanov, Meng Lee. "The Standard Template Library". И, снова-таки, в процессе стандартизации STL, как и остальные части стандартной библиотеки, претерпела множество изменений с теми же последствиями, что и развитие языка.
> ПК> Да и прямые высказывания разработчиков и менеджеров, которым я в этом отношении склонен верить гораздо больше, говорят немного о другом.
> Цитаты, плиз. А то я тоже много чего слышал.
Далеко не все доступно в открытых источниках, но и того что есть, полагаю, вполне достаточно.
Интервью с Джоном Кейвсом, разработчиком VC++, и представителем Microsoft в комитете стандартизации:
MS: Why isn't it 100% compliant? What are the issues?
JC: There are several reasons why we are not 100% conformant. One reason is that the Standard was finished relatively recently and at times during the development of the Standard the committee did change its mind and removed features that they had previously added. Another reason is time, there is just a limited amount of things we can to for each release and so there are some small, subtle areas of the C++ Standard we have not been able to address yet. Also the fact that we got bitten more than once by tracking the proposed Standard too closely made us wary of implementing a feature as soon as it is added to the language. These areas mostly deal with smaller features and/or minor changes, and as such we hope to add support for them in a future release. The biggest contributing factor to our current level of conformance is the need to maintain backwards compatibility with existing code, as more important than comformance to the standard. The majority of our users rank backward
compatibility with existing code higher than conformance to the standard. That said, we will continue to implement features that bring us as close as possible to the standard, without negatively impacting our developers.
Есть и еще одно интервью с ним же, где тоже можно легко увидеть периодически всплывающую тему обратной совместимости.
Даже при обсуждении VC++ 7.1 (.Net 2003), неизбежно ломающей часть старого кода, тема обратной совместимости является одним из центральных моментов.
И что характерно, для того же C#, имеющего по сравнению с C++ очень короткую историю, при обсуждении внесении изменений, необходимых для совместимости со стандартом, речь идет именно об обратной совместимости:
I got an email from a customer today, in which he noted that the C# compiler allows you to write: <...> despite the fact that the spec does not list bool as one of the types that you can switch on.
Unfortunately, we've shipped the current behavior, and one of our high-order goals is not to break existing code by changing the compiler.
In this case, however, I think we may be going to far in not fixing a bug because there's a chance somebody might have written code that used it.
Хотя в данном случае аудитория настроена вполне решительно, по мере того, как релизы, содержащие возможности, затрагиваемые изменениями будут отстоять все дальше и дальше во времени, эти изменения будут приниматься все менее и менее охотно...
> Борлад можно считать паенькой и значит, то что они тоже не смогли создать совместимую со стандартом версию все же говорит о его сложности запутанности?
Про Борланд мне известно значительно меньше, чем Майкрософт, но из той информации, которая у меня есть, я склонен уточнить твое высказывание до "тоже не стали создавать полностью совместимую со стандартом версию". Как можно было видеть на примере Майкрософт, GCC и EDG, отсутствие совместимости не означает невозможности ее обеспечить из-за проблем со спецификацией, а скорее говорит о других приоритетах и причинах в тех случаях, когда это не делается.
> ПК> Вот беда-то какая, с цифрами снова совсем неладно. 2004 — 16 = 1988.
> Сейчас почти 2005-ый. Плюсы оформились в 98 так что все ОК.
Да где ж ОК, когда по сравнению с заявленными 16 годами расхождение на 10 лет?! А учитывая то, когда Microsoft решила заняться вопросами совместимости, время получается еще раза в три меньше.
> Если бы МС только подправляли свой компилятор для учета текущего стандарта, то мы умели бы полноценный компилятор уже в лице VC 1.0/1.5. А VC6 вообще был бы полностью совместим со стандартом, так как вышел в том же году.
Как легко рассуждать со стороны, а? А ведь если как следует разобраться в вещах, добавленных в стандарт на завершающих сроках составления спецификации, и представить себе стоимость их реализации при учете древней архитектуры компилятора, да еще осложненной множеством заплаток в результате периодических адаптаций к черновикам стандарта, все будет выглядеть далеко не так радужно... И если взглянуть на моменты, в которых VC++ расходится со стандартом, то можно обнаружить, что это как раз те самые вещи, которые хуже всего вписываются в архитектуру, разрабатывавшуюся без их учета.
> ПК> В том славном году еще даже C не был стандартизован, не то что C++.
> С++ тогда появился и оформился. А С уже лет 10 как имел стандарт дефакто — K&R.
Который от ANSI C тоже вполне ощутимо отличался.
> МС контора бедная. Ей просто ресурсов не хватило сделать компилятор соотвествующий стандарту.
Да причем здесь богаство конторы? Во-первых, разработчиков компиляторов необходимого уровня не так уж и много — Microsoft ведет постоянный конкурс в команду VC++. И, во-вторых, сколько их не найди, "девять женщин не родят ребенка за один месяц".
> Ну, а Борлад, Сайбес (он же PowerSoft, он же Ватком)
Watcom давным-давно почил в бозе, и вернулся к жизни совсем недавно, на общественных началах.
> а GCC
GCC соответствует стандарту в достаточно высокой степени.
> Почему появился только какой-то там незивестный на три буквый которым никто реально не пользуется?
Это утверждение просто-таки неверно. EDG используется очень многими производителями компиляторов. В том числе и Intel, который специально сделан менее соответствующим стандарту в угоду совместимости с VC++.
> ПК> В качестве посылки ты используешь недоказанное утверждение. А именно: "язык особой сложности не представляет".
> Назови мне хотя бы один технический критерий по которому он сложнее всех остальных если отбросить запутанность и неопределенность.
Пожалуйста, целый букет, в котором многие пункты служат множителями друг к другу в плане сложности реализации:
большое количество синтаксических неоднозначностей, требующих бесконечного просмотра вперед
включая конструкции, которые означают разные вещи, в зависимости от того, является ли идентификатор шаблоном, типом, или чем-то еще
взаимодействие этого со сложным поиском имен
включая пространства имен, связанные с аргументами
который еще усложняется в шаблонах в виду наличия зависимых имен
все это еще усложняется в виду сложных правил перегрузки функций
и перегрузки шаблонов функций, включая частичное упорядочивание
сюда же идет сложная система преобразований типов
и преобразования, определенные пользователем, участвующие в перегрузке
сюда же идут правила, касающиеся не участия в перегрузке шаблонов функций, объявления которых не могут быть инстанцированы (SFINAE)
сами шаблоны тоже далеко не просты
особенно с возможностью полной и частичной специализации
и множеством правил для явного и неявного инстанцирования
и взаимодействием с возможностью объявлений неименованных сложных типов по месту использования (все еще помним о неоднозначностях конструкций?)
далее вспоминаем, что часть аспектов перегрузки связана с множественным наследованием
которое подводит нас к достаточно развитой объектной модели C++
включая виртуальное наследование
включая вызов виртуальных функций в присутсвии этих нюансов
включая взаимодействие их с конструкторами и деструкторами
что подводит нас к взаимодействию всего этого добра с исключениями
и идентификацией типов во время исполнения, включая поиск подобъектов в иерархии, осложненной множественным и виртуальным наследованием
еще не стоит забывать, что в перегрузке в разных ипостасях присутствуют cv-квалификаторы
что снова возвращает нас к преобразованиям типов, включающим продвижение cv-квалификаторов
и распад некоторых сложных типов до указателя
и снова вспоминаем, что и это тоже взаимодействует с перегрузкой, шаблонами и преобразованиями, определенными пользователем
и шаблонами функций преобразований, определенных пользователем
и я промолчу, какие полезут нюансы, если разработчик решит реализовывать экспорт шаблонов...
впрочем, один упомяну: требуется поиск имен не только в единице трансляции, которая сейчас компилируется, но и в других
в том числе из областей видимости, недоступных в других случаях
И т.д., и т.п. — картинку можно усложнять далее по вкусу.
В общем, многие "фичи" по отдельности сами по себе не очень сложны, но вот их взаимодействие, действительно очень сильно усложняет общую картину...
>>> Буст, Локи используют побочные эффекты этой спецификации которые она даже не декларировала.
> ПК>А именно? Конкретные примеры, пожалуйста. А то, что-то с телепатией у меня уже совсем плохо...
> Да все ты прекрасно понимашь. Эмуляция функцинальных вычислений на базе эффекта рекурсивного определения шаблона со
специализацией вместо граничного условия — это как? Задумывалось ли стандартом такое поведение? Где в С++ вообще хоть слово о возможости вычислений в компайл-тайме (кроме как инициализации константными выражениями)?
А зачем для этого какие-то дополнительные слова? Достаточно спецификации, которая это все сознательно позволяет, а каждое использование не опишешь, да и не надо это. Во время написания стандарта многие вещи с шаблонами уже были известны. Часть открыли после, но это, имхо, только логично, что пользователи языка разрабатывают новые техники его использования.
>>> STLport всего лишь реализация спецификации появившейся где-то в 1992.
> ПК> 1998.
> Открываем исходник STL в VC и читаем коментарий: >
> * Copyright (c) 1992-2002 by P.J. Plauger. ALL RIGHTS RESERVED.
> * Consult your license regarding permissions and restrictions.
>
Ага, а чуть ниже:
* Copyright (c) 1994
* Hewlett-Packard Company
которая являлась самой первой реализацией STL от Степанова, и на базе которой Плоджер делал свой вариант уж никак не раньше 1994 Просто найденный тобой копирайт не означает, что именно данный исходник ведет свое начало с 1992 года, это речь о всей библиотеке, еще с тех времен, когда на STL там намеков не было. В любом случае, спецификация появилась именно в 1998 году. До этого были только черновики. Опять-таки, в STLport ценна именно реализация, а не спецификация.
> ПК> Не вполне. Хотя есть некоторые техники, позволяющие реализовать значительную часть оптимизаций STLport и на VC++6,
> Оптимизации — это уже дело десятое. К нашему вопросу не относящееся.
Еще как относящиеся, т.к. они и являются одним из мотивов исопльзовать STLport, Blitz или Pooma.
>>> Вместо boost и Loki лучше было ввести необходимые средства в язык.
> ПК> Это еще один очень спорный тезис.
> Ну, ты же спорить не будешь? Ведь у тебя как вседа недостаточно довыдов.
Дык, в качестве аргумента его использовал ты. Не обосновано — тезис не принимается.
>>> Про Blitz и Pooma и сегодня мало кто слышал и они мало кому нужны.
> ПК> Да уж конечно. Если ты не слышал, не значит, что никто не слышал.
> Можно устроить голосование и зунать какое количество слышало, какое использовало, а какое реально использует. Проводим? Или на слово поверишь?
РСДН в этом отношении нерепрезентативная выборка. Опрос нужно проводить среди тех, кто пишет приложения с матричной алгеброй. А то можно и по опросам среди программистов баз данных о популярности 3D движков узнавать. И наоборот. В любом случае, эти библиотеки находятся в списке тех, которые разработчики VC++ поставили в качестве критерия достаточного соответствия 7.1 стандарту именно в результате запросов пользователей. Так что мотивирующим фактором, как можешь видеть, они вполне являлись, хоть некоторым могут и не быть известны.
> ПК> Это пример, иллюстрирующий тем, кому это интересно, реальные причины, почему те или иные несоответствия стандарту не исправляются. Соответствие стандарту в каком-то воображаемом режиме, не используемом в реальной жизни, пользователям мало интересно.
> Это не правда. Еще в МС С 4-5 были ошции совместимости стандарту. И это прекрасно работало.
Агащазблин, MFC с такими опциями тоже прекрасно не работало...
> Совместимость с С. Уже мало важна. Ее достаточно на уровне импорта С-шных функций.
Недостаточно. Напротив, одной из главных задач следующего стандарта является улучшение совместимости с C, в т.ч. C99.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
я тебя убедительно прошу читать сообщения целиком, до того, как ты начинаешь отвечать. Иначе вести беседу с тобой чрезвычайно затруднительно, т.к. по ходу составления ответного сообщения ты задаешь множество вопросов, ответы на которые ты мог бы получить, прочитав один-два следующих абзаца.
Кроме того, так как сообщения разрослись до сложнопотребляемых размеров, в этом я касаюсь только ответов на вопросы о сравнении C++ и C#. Сюда вопросы соответствия компиляторов стандарту, пожалуйста не примешивай.
> ПК> А, в фоновом режиме, таки да, начались кой-какие подвижки в сторону соответствия стандарту.
> И вот тут возникает вопрос. Почему такие бабки кладутся на разрботку нового языка — сишарпа, и упровляемой среды упровления?
Маркетинг. Завоевание рынка Java и т.п. Денег хотят, короче.
> И почему МС решились положить толстый ... на весь С++ и сейчас переориентируют кучу кода под тот же C#?
MS вкладывается в C++ по полной программе, и твои заявления сильно расходятся с тем, что говорят официальные лица компании, которым я в этом вопросе, снова-таки доверяю значительно больше
> C# must be quite capable if MS is writing all internal code with it now. Wow. I thought the day would never come that C++ would take a back seat.
That's really news to me.
I wouldn't stretch this too far. Yes, C# is a great language but the use of C++ is still alive and thriving. Since I interned in Microsoft Outlook, I usually go over there to hang out and see what's going on. C# is used in areas where the .NET platform is designed to stand out -- namely Web Services and ASP.NET. C++ is definitely the mainstream language for writing the applications.
Добавка от менеджера, для большей ясности:
To re-iterate what Brandon already said, the statement that Microsoft is using C# for all internal development is completely bogus.
Yes, managed code is the direction we are going in moving forward for all the places where it makes sense. However extrapolating that to mean C# is simply not true. We are spending a lot of resources to make sure C++ is a primary development language on the .Net platform and are seeing a lot of internal adoption of C++ to write managed code inside of Microsoft. In the RTM version the primary focus of MC++ is to enable you take integrate easily with existing code, but in future releases you will see us focusing much more on making C++ take up the traditional role it serves role as the high end language for system level programming and for expert level programming on the .Net platform.
А шумиха вокруг C# вполне объяснима: надо же MS свое детище двигать, Джаву теснить...
> Не уж то одной из причин небыло как раз отсуствия у С++ и его стандарта некоторых качеств?
Да, конечно, есть и эта причина. Но только на основании наличия разницы языков говорить о безусловном преимуществе какого-то из них некорректно.
> А вот ты сам сказал, что реализовывать, то даже меньше чем в случае шарпа
Этого я не говорил. В противном случае приводи ссылки.
> Большинство программистов использующих С++ в своей работе бревна в нем не замечают, при этом постоянно понимая вопрос о том зачем нужед дотнет и т.п.
Большинство программистов, использующих C++ в своей работе, с которыми я общаюсь, никаких вопросов о назначении .Net не задают. Он им глубоко фиолетов, пока не приходится с ним иметь дело.
> Да что там. Страуструп несет такое, что смешно становится.
Например?
> ПК> Ты уверен, что достаточно глубоко ознакомился с предметом? VC++ 7.0 и 7.1 в плане соответствия стандарту — небо и земля.
> Я уверен, что идет очередная попытка уйти всторону. Да и снова преувеличения. Никакой там земли и неба нет. Список изменений умешатся в одном абзаце.
Этот список изменений, умещающихся в одном абзаце — большая часть изменений в языке от ARM и ранних черновиков стандарта (VC++6.0) до современного состояния языка. Это намного больше, чем осталось доделать для почти полного соответствия стандарту ("почти" означает без экспорта шаблонов). Фактически VC++7.1 осталось: двухфазный поиск имен, исправление ошибок, и еще одна фича сомнительной нужности — спецификация исключений; пожалуй, все...
У GCC близкая ситуация. Так что странно говорить о слабой поддержке стандарта современными компиляторами...
> ПК>Модули вещь хорошая.
> Ну, так может признать то, что отсуствие их в С++ и уход спецификации С++ от их описания — это болшая брешь в них?
Причем здесь брешь? С точки зрения C++ от добавления модулей ничего принципиально не изменится:
1) улучшится скорость компиляции;
2) упростится диагностика ODR;
3) может, еще какие мелочи.
Или ты еще что-то подразумеваешь?
> Так что признаем недостатком стандарта С++ отсуствие разделов говорящих о модулях и принципах компиляции с их использованием? А так же признаем недостатком то, что в языке нет конструкций отличных от #include позволющих импортировать типы из вне?
Ну, признаем, и что? А если не признаем, то что изменится? Хоть с модулями, хоть без модулей, для части людей, предпочитающих сочетание парадигм программирования, плюс большие выразительные возможности языка реальных альтернатив все равно пока нет.
> ПК> Тезис о лучшей кроссплатформенности (переносимости) Java и .Net подтверждать данными каких-нибудь объективных исследований будешь, <...> или это твое личное мнение, в обоснованиях не нуждающееся?
> Это мое лично мнение сформированное на большом количестве фактов.
Ок, приводи факты, их количество, сравнение количества для C++, С# и Java и т.п. Или посылаем мнение в лес как необоснованное.
> Так если без обобщений. Есть проблемы у С++ и его стандарта?
Проблемы, как я уже говорил есть. Странно, что приходится повторять дважды.
> Много ли их?
Не знаю. Зависит от критериев много/мало.
> Влияют ли они на качество С++ и/или стандарта?
Тоже не знаю. Если переформулировать вопрос в смысле, станет ли легче работать, если проблемы решить — да, станет. Если вопрос в смысле, тяжелее ли сейчас работать, чем на других языках — нет, не тяжелее. Скажем, с тем же C# сейчас ребята мучаются значительно больше.
> ПК> Проектирование традиционно, все-таки, предшествует выпуску продукта, соответственно, проектирование языка должно было произойти до реализации компиляторов, каковая, как нам известно, предшествовала составлению стандартов.
> Нет. Уж стандарт — это всего лишь акт принятия спецификации. А вот специяикация является непосредственным процессом проектирования языка.
Не процессом, а результатом. Процесс по определению предшествует результату.
> ПК>Я избегаю сравнений в терминах "криво" и т.п.
> А в каких не избегашь? Можно примерчик?
Легко. Например:
C# поддерживает компонентно-ориентиорванное программирование, C++ — нет.
C++ поддерживает процедурное программирование, C# — нет.
И т.п.
> ПК> С первым можно и не трудиться сравнивать: в реальных программах на C# первой версии, как и в Java, столько неизбежных приведений типов,
> О... тут хочется сделать аж несклько возражений :
> 1. Сколько, Паша? Сколько? Не уж то ты сожешь аргументировано доказать, что их так уж много.
Я лучше задачу простую для иллюстрации приведу. Как отсортировать символы в строке на C#?
> 2. Почему первых версий?
Потому что это то, с чем приходится иметь дело ребятам на работе.
> 3. Данное высказывание является грубешой подменой понятий. Приведение типов в рантайме еще не делает язык типобезопасным. Есть такое понятие как автоматическая проверка типов в рантайме. А то понятие которым ты пыташся подменить типобезомаснсть назвается статической типобезопасностью. Какова же цеть подмены понятий. Мне кажется в очередной раз увести обсуждение в сторону.
Где ты увидел здесь что-то кроме упоминания статической проверки типов?
> ПК>С первым можно и не трудиться сравнивать: в реальных программах на C# первой версии, как и в Java, столько неизбежных приведений типов, обусловленных отсутствием параметризации, что статическая проверка отдыхает по полной программе.
> ПК>2) Это семечки по сравнению с невозможностью в C# (в том числе и, насколько я понимаю, второй версии) обеспечить тот уровень статических проверок, который легко достигается в C++. <...> Пример тебе уже приводили: проверка размерностей в физических выражениях во время компиляции.
> Извини суть того примера я так и не уловил. Более того он мне показался бредовым.
Еще раз в доступном виде. Представь, что есть команда программистов, занимающаяся реализацией задач, связанных с большим количеством вычислений физических величин. Например, движок симуляции механики для игр.
Они сталкиваются с тем, что периодически делают ошибки в набираемых формулах.
Огромное количество ошибок, которые они делают, может быть отловлено путем контроля размерности, традиционного для физических вычислений. Например:
Length l = length();
Time t = time();
Velocity v = l * t; // ошибка: размерностью выражения справа является м*с, слева — м/с
Velocity v = l / t; // ОК
Естественно, выражения не ограничиваются такими простыми вещами. Есть целая система традиционных единиц. В частности:
Mass m = mass();
Velocity v = velocity();
Energy e = m * v / 2; // ошибка: размерности не совпадают
Energy e = m * v * v / 2; // OK
Impulse p = m * v * v; // ошибка: размерности не совпадают
Impulse p = m * v; // OK
Нужно поддерживать фактически произвольные степени разных величин, равно как и произвольный набор операций с ними, т.к. они очень легко возникают в процессе промежуточных вычислений.
Velocity v1 = velocity(1);
Velocity v2 = velocity(2);
Velocity v3 = velocity(3);
Time t = time();
Acceleration a = v1 / t; // OK
Acceleration a = v1 * v2 / t; // ошибка
Acceleration a = v1 * v2 / v3 / t; // OK
Acceleration a = ( v1 * v2 + v1 * v3 ) / ( v1 + v2 ) / t; // OK
В предоставлении подобных средств вся философия C++. Сравнивать с этим C#, который дает больше встроенных возможностей, но не предоставляет для разработки подобных средств для типов, определенных пользователем, имхо, не вполне имеет смысл — это две разные вселенные.
> ПК>Нет, в данном случае вовсе не совместимость с C, а возможность реализации наиболее эффективных приложений, непосредственно работающих с аппаратной платформой. Ты совершенно упускаешь из виду, что C++, в отличие от C#, по своему назначению является языком системного программирования.
> Из этих слов я делаю вывод, что ты исходиш из предположений: > 1. Сто C# не имеет возможности наиболее эффективных приложений, а С++ имеет.
C# в некоторых случаях идет на компромиссы в пользу защиты программиста от ошибок. C++ выбирает другую дорогу: дать программисту средства защищать себя самому, но не мешать ему делать то, что ему вздумается.
> 2. Что у C# как языка (а не конкретной реализации на CLI/дотнете и т.а.) есть какие-то особенности не позволяющие ему непосредственно общаться с аппаратной платформой.
Не так свободно, как C++. Например, выделение/освобождение памяти программистом не контролируется. Или организуй-ка на C# компактный контейнер, который хранит все свои данные на стеке, и чтобы работа с ним могла выполняться с теми же удобствами, что с остальными классами...
> 3. Что С++ является системым языком, а не универсальным.
C++ поддерживает более одного стиля и парадигмы. В том числе правила проектирования данного языка содержат ряд положений, направленных на поддержку низкоуровневого программирования, среди которых есть и "Не оставлять места для языка более низкого уровня, чем C++, исключая ассемблер", и "Правило нулевых издержек: чем не пользуетесь, за то не платите", и "Если есть сомнения, предоставлять средства для ручного контроля".
Снова две разных вселенных...
> 4. Что типобезопасность противоричит эффективности и/или системности.
Типобезопасность не требует модели C#. C++ вполне безопасный в плане статического контроля типизации язык. Как показывают примеры выше, более безопасный, чем C#. В динамике встроенный контроль типов очень ограничен. Но это не означает, что кто-нибудь запрещает при необходимости построить свою надстройку, контролирующую все, что угодно.
>>> Да и о какой совместимости речь? С99 напрочь не совместим с С++. Значит совместимость не так и важна?
> ПК> Совместимость важна. С99 не так уж и не совместим c С++, а после выхода следующей версии C++, эта разница станет еще меньше.
> Очень, очень. Там появились массив как объекты высшего порядки и т.п.
Я вполне осведомлен об изменениях в C99.
> Скомпилировать программу написанную с испоьзованием фич С99 нельзя ни на одном компиляторе С++.
1) Можно в виде расширения.
2) Есть намерение, чтобы после ревизии стандарта это было требованием стандарта.
> ПК> Большее количество ключевых слов или конструкций не означает большую сложность языка.
> Зависит от критериев. С точки зрения синтаксиса неоспоримо сожнее.
Да ну? Обычно, наоборот, уменьшение количества разных конструкций, приводящее к перегрузке одних и тех же множеством значений делает анализ синтаксиса сложнее. Например, замена квадратных скобок [] на круглые () для индексации массивов, если последние так же используются для вызова функций, синтаксический анализ значительно усложняют.
я привел беглое описание сложностей анализа C++, по сравнению с которыми "контекстно-зависимые" ключевые слова — цветочки. Полагаю, любому, кто писал синтаксический анализатор для чего угодно, должно быть понятно, что для C++ это сделать намного сложнее, чем для C#.
> Попробуй перечислить понятие С++ отсуствующее в Шарпе. <...>
Зачем?
>>> ПК> Заметь, я не утверждаю ни что C# проще, чем C++, ни что он сложнее. Только отмечаю, что я не видел подобных данных.
>>> Так все же утверждал?
> ПК> Нет.
> Я я тут рядом где-то читал, что все же проще. Вроде твоей рукой было написано. Ну, раз ты отказываешся от этих слов...
Нет, раньше я по этому поводу ничего не говорил. Ты перепутал. В этом сообщении — первое подобное сравнительное утверждение относительно сложности синтаксического анализа. Но, имхо, это и так должно быть ясно. Или нет?
> А то ситуация какая-то странная. У самого нет даже намека на критерии. Но чужие пыташся выставить неверными. Причем так... в заявительном порядке. Мол у мнея мнение, что твои критерии и аргументы субъективные.
Дык, ты ж объективных данных не приводишь
> ПК> В соответствии с моими критериями, C++ — вполне удачный язык.
> Это ничем не обоснованное мнение. Ценность которого стримится к нулю (с)
> Если серьезно, ты даже своих критериев не выскзал. Все пытаешся обосновать необоснованность моей позиции.
Просто пытаюсь сказать тебе, что никакие подобные критерии не могут подходить всем, как ты это часто преподносишь.
[b]Для меня[b/] главное:
Не должно быть неявных нарушений статической типизации, или чтобы их количество было сведено к минимуму.
Должен предоставлять разработчику максимум средств для определения поведения "своих" типов. В частности позволять создавать "свои" типы, максимально близко ведущие себя к встроенным. И для "своих" типов задавать максимум ограничений, контролируемых статически.
Должен позволять максимально использовать код повторно.
Должен поддерживать ООП, когда это нужно, но чтобы не болтался под руками со своими ограничениями, когда это не нужно.
То же самое в отношении обобщенного программирования.
И требование, которое к дизайну языка не относится, но являтся, пожалуй, самым важным: вокруг языка должно существовать грамотное сообщество (community), помогающее решать проблемы, возникающие в ходе работы.
По всем перечисленным пунктам C++ я считаю языком удачным.
> ПК> 2) Изменений C++ требует. Против этого, по-моему, никто и не возражает...
> 1. Взражают.
Ну, с ними об этом и спорь
> 2. Опять же каких.
Лямбда-функции — то, что доктор прописал.
И прочие средства повышения локальности и изоляции кода и данных.
Улучшение средств метапрограммирования пришлось бы очень кстати.
Модули, пожалуй, тоже были бы приятным дополнением.
Ну, остальное, скорее, мелочи, но жизнь тоже облегчат.
> Ну, и возвращаясь к исходному сообщению, тогда не ясно зачем было вообще поднимать весь разговор если ты согласен с проблемами.
1) Я согласен с наличием проблем, но не согласен с твоим их перечнем
2) Разговор по поводу проблем C++ затеял ты
> Я всего лишь указал, что Оберощики используют проблемы С++ в целях превознесения их убогого языка.
Оберон вполне элегантный язык. Убогим я бы его не назвал. Он не обладает выразительной мощью C++ или даже C#, но для его задач это не обязательно нужно.
> А на самом деле есть языки не имеющие этих проблем, и в то же время не стольк убогие как Оберон.
У тех языков — свои проблемы.
> ПК> Это совершенно сознательное решение, являющееся следствием того, как работали/работают конкретные аппаратные платформы, с которыми языки C и C++ призваны непосредственно взаимодействовать. Возможно, вследствие почти полного исчезновения таких экзотических платформ, это правило будет изменено в следующей версии стандарта.
> И что же такого дает данная неопределенность?
Возможность работы на платформах, где невозможна одновременная модификация содержимого ячейки памяти без задержки, при этом без лишней потери производительности в остальных случаях.
> ПК> Нет, это следствие того, что те, кого ты называешь "мало-мальски грамотными авторами языков", проектируют языки для несколько других задач.
> Ну, поделись для каких же? Чем они другие?
Для удобства работы программистов, нуждающихся в максимуме выразительных средств и максимуме статических проверок, в т.ч. применимых к типам, определяемым пользователям, при построении больших систем, без компромиссов в отношении производительности, без навязывания определенной парадигмы.
Скажем, для того же C# в спецификации явно оговорено, что он является объектно-ориентированным языком (т.е. навязывает определенную парадигму), и с C он по производительности соревноваться не предназначен. Хотя, согласен, во многих случаях показывает очень неплохие результаты.
> ПК> Еще раз: стандарт специально составлен так, чтобы у разработчиков компилятора была возможность реализации подобных проверок без нарушения стандарта.
> Это скорее случайнось. с теми же указателями вывернуться не удается.
Что значит вывернуться? Все соответствующие места в стандартах C и C++ прописаны так, чтобы были возможны проверки неправильной арифметики указателей во время исполнения. Этому посвящалось время на заседаниях. Как при таких условиях это может быть случайностью?
> ПК> Его использование для более прикладных задач требует большей квалификации, чем использование C#.
> Траха, траха больше требует.
Ну, вопрос открытый. У нас получается ситуация обратная: с использованием C# практических проблем значительно больше. Может, это мы с ним что-то не так делаем, но пока работать заметно менее удобно, чем с плюсами...
> А квалификацию можно потратить на более эффективное или быстрое решение задачи.
Дык, на плюсах так и получается...
> ПК> Но некоторые вполне согласны заплатить эту цену за большие выразительные возможности языка,
> О! Еще одно необоснованное утверждение.
В смысле? Я, например, согласен платить эту цену. И те, с кем я работаю, согласны. Чего ж тут обосновывать?
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Спасибо
> Павел, всегда хотел спросить, были ли тобой ранее прочитаны все источники из которых ты приводишь цитаты или ты их изыскиваешь перед написанием поста?
По-разному. В данном случае заранее мне были хорошо известны все "источники", кроме конкретных сообщений разработчиков VC++ в группах новостей и записей интервью. Но так как все то же самое я читал ранее в пересказах третьих лиц, плюс пол-года назад услышал это же от некоторых из них лично, то оставалось только найти какую-нибудь открытую информацию, которая не могла не найтись
> И еще очень интересно сколько суммарно было затрачено времени на составление ответа?
Больше, чем мне того хотелось так как в таких дискуссиях обычно все остаются при своих. Думаю, часа два писал...
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
ПК>Большинство программистов, использующих C++ в своей работе, с которыми я общаюсь, никаких вопросов о назначении .Net не задают. Он им глубоко фиолетов, пока не приходится с ним иметь дело.
Скажу больше, С++ программисты обычно с любопытством относятся к этой платформе, пока не посидят конкретно. Не скажу про 2.0 (релиз еще не вышел), но недостаточность выразительных ср-в C# порой вызывает просто физические ломки (точно такие, как были при работе на VB). Одно радовало — хорошо хоть придумали делегаты и систему событий на их основе, ибо если бы сделали как в Java, то это было бы "последней каплей" на чаше весов в пользу отказа от языка (да именно, даже несмотря на мощнейшую платформу)
ПК>Этот список изменений, умещающихся в одном абзаце — большая часть изменений в языке от ARM и ранних черновиков стандарта (VC++6.0) до современного состояния языка. Это намного больше, чем осталось доделать для почти полного соответствия стандарту ("почти" означает без экспорта шаблонов). Фактически VC++7.1 осталось: двухфазный поиск имен, исправление ошибок, и еще одна фича сомнительной нужности — спецификация исключений; пожалуй, все...
Я бы ввел обязательную спецификацию исключений. Во-первых, это бы немного упростила реализацию механизма исключений компиляторами. Во-вторых, подняло бы надежность программ. (правда, за счет некоторого неудобства)
Здравствуйте, vdimas, Вы писали:
V>Я бы ввел обязательную спецификацию исключений.
Вот в джаве такое сделали. В результате большинство современных фреймворков используют исключения, отнаследованные от RuntimeException, которые специфицировать не надо.
VladD2,
> С++ ставит размер типов в зависимость от реализации, а C#, как и система типов CLI четко определяет их в стандрарте.
> <...>
> V> однако в С++ оставлены те же возможности и механизмы их реализаций, что и в С, что позволяет использовать С++ в тех областях, где раньше был применим С (а до него ASM).
> Все необходимые для этого возможности есть и в C#. <...>
Не совсем. В частности, чуть выше процитирована одна из причин, не позволяющих в некоторых случаях использовать C# без дополнительной прослойки. В самом деле, если размер машинного слова не ложится на размеры целых типов CLI, то очевидно, что работа с целыми в C# не будет прямой работой с платформой. И подобный выбор очень хорошо иллюстрирует то, что C#, в отличие от C++, и близко не предназначен для замены использования C или, тем более, ассемблера.
Я не утверждаю, что это плохо. Просто это демонстрирует разницу в целях, которые ставили перед собой разработчики C# и C++.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>1. Где ты в моих словах усмотрел "Допущение истинности утверждения"? Я выразил свое мнение. Я не утверждаю, что не ошибаюсь. Ты просто потребовал его обоснования, а я сказал, что не хочу этого делать. Далее ты добавил, что оно безапелляционное. На что я ответил, что если тебе нужно, то ты можешь опровергать его сколько влезет (т.е. апеллировать).
Вообще-то, дискуссия, направленная на поиск некоей истины как-то не подразумевает участия в ней необоснованных мнений. Ввязавшись в дискуссию, человек автоматически становится оппонентом или пропонентом той или иной обсуждаемой точки зрения.
VD>2. Считаешь ли ты допустимым объявлять мнение неверным, только на основании того, что человек высказавший его не хочет (или даже не может) дать полного его обоснования?
Как правило, Павел (и не только) приводят тебе вполне увесистые контраргументы (рейтинги сообщений дают богатую почву для размышлений!), доказывающие ошибочность твоего мнения. Однако, если суждение сформулировано в очень общих терминах, то его можно или попросту отклонить, сославшись на неправомерность обобщений (ты этим часто грешишь. Я, справедливости ради — тоже), или — потребовать доказательств. Оба эти способа логически эквивалентны, но второй короче. Никакой нелогичности здесь нет. Если ты пришёл к неким выводам, а твой оппонент с ними не согласен, то будь добр озвучить логическую цепочку. Не хочешь? Да не вопрос! Но тогда за твоими оппонентами остаётся полное право просто хмыкнуть и пройти мимо или опубликовать контраргументы. Уж не обижайся.
Тем паче, что ты нередко воюешь с абстрактными "догмами" и "старыми подходами", подразумевая, например, любителей C++.
ПК>>Презумпция невиновности сюда вообще никаким боком. Мы говорим об установлении истинности тех или иных утверждений, а не о чьей-то вине. VD>Гы. Перекладывание бремени поиска доказательств на обвиняемого (или другими словами, принуждение к оправданию) как раз и является нарушением презумпции невиновности. Ты открой ссылочку то... и поищи слова "бремя отвественности". Юридическое обвинение — это некий процесс, сводящийся к доказательству утверждения, что некто ("обвиняемый") совершил некое противоправное деяние. Нюансы могут меняться, но это сейчас не важно. То есть, имеем такие артефакты:
Спорное утверждение (или — обвинение), излагаемое в качестве обвинения. Утверждение такое высказывается истцом или обвинителем. При этом, как правило, стороны придерживаются противоположных точек зрения относительно истинности этого утверждения. Доказательства истиности обвинения, которые предъявляет истец или обвинитель. Сии вещицы должны подтвердить истинность спорного утверждения. Доказательства ложности обвинения, которые может предъявить обвиняемый в защиту тезиса о ложности обвинения. Обвиняемый, который в соответствии с принципом презумпции невиновности может вообще молчать или всяко оправдываться. Суд, который взвешивает аргументы сторон спора и делает окончательный вывод относительно спорного утверждения (плюс кое-какие нюансы).
В случае часто вспыхивающих споров на RSDN, в которых ты оперируешь свои мнением, ты нередко пытаешься таким образом опровергнуть позицию твоего оппонента. В данном случае, с позиций той же самой презумпции невиновности, вполне логично потребовать от тебя доказательств истинности твоего суждения. Ведь ты же сам, фактически, начинаешь обвинять других в ошибках! В свою очередь, когда от тебя требуют доказательств правомерности таких "обвинений" ты начинаешь ссылаться на презумпцию невиновности.
VD>Ставя под сомнение чужое мнение ты обвиняешь другого человека в том, что он говорит не правду и принуждаешь его оправдываться на ровном месте. Заставляя его оправдываться ты как раз нарушаешь этот принцип.
Далеко не всегда. Например, утверждение, что "Стандат Шарпа проработан куда лучше, но размер он имеет даже меньший" есть некое весьма спорное утверждение, подразумевающее некачественную проработку стандарта C++. Вполне логично потребовать от тебя доказательств и обоснований подобного утверждения. Почему нет? Но почему ты становишься при этом в позу несправедливо обвиняемого мне, лично, непонятно.
>>> Итак. Я утверждаю, что требуют доказательства только не очевидные заявления сделанные в ходе логического вывода или доказательства. Все же остальные случаи являются выражением личного мения и подтверждения не требуют. ПК>>Да, естественно. Я и не требую от тебя доказательств. VD>Это откровенная неправда. Ты именно вынуждаешь оправдываться. Брошенная в след фраза "а ну-ка обоснуй это мнение" ни чем иным назвать нельзя.
Напоминаю цитату:
ПК>>Да, естественно. Я и не требую от тебя доказательств. Просто говорю о том, что неаргументированное мнение для читателя имеет пользу, стремящуюся к нулю.
Разумеется, ты свободен от необходимости доказывать свои утверждения. Это твоя личная позиция по отношению к дискуссии и участникам. Но не обижайся, если их начнут называть "безаргументными ИМХО", "не учитываемыми в дискуссии". Или ещё как покрепче. Договорились?
ПК>>Просто говорю о том, что неаргументированное мнение для читателя имеет пользу, стремящуюся к нулю. VD>Очередная ошибка. Мнение есть мнение. Оно не обязано иметь пользу. Оно даже может быть ошибочным. Так что тут даже такие рассуждения не применимы. Да и ценность мнения отнюдь не сводится к нулю тем, что за ним не следует огромного формального доказательства его истинности.
Не, дело не в этом. Дело в том, что публично высказанное ошибочное мнение, оставленное без соответствующих contra может принести кому-то вполне реальный вред. Мне например. И кстати, это одна из причин, по которой я, например, тусуюсь на этом форуме.
VD>Если мнение высказывается авторитетным в некотором вопросе человеком, то оно уже будет иметь для меня ценность. Например, твое мнение о соответствии той или иной конструкции стандарту C++ для меня несомненно имеет значение. В прочем, я всегда буду допускать, что ты можешь банально ошибиться и не буду возводить твое мнение в разряд 100%-но истинных утверждений на базе которых можно построить однозначно верный логический вывод.
Сейчас ты передёргиваешь. Мнения общепризнанных авторитетов — это одно. Ты находишь себя общепризнанным авторитетом в вопросах, по которым вступаешь в полемику? Я вот тебя таковым не нахожу (не сочти за наезд, но по крайней мере для меня ты авторитетом в вопросах, свзяанных с C++ авторитетом не являешься). С другой стороны — мнения авторитетов, это тоже неправомерный аргумент.
VD>Так вот ты очень часто докапывашся до общих мнений. Причем зачастую вопросы по которым эти мнения высказываются просто физически сложно доказать или дать полное их обоснование.
А ты не находишь, что составленное таким образом мнение может быть заблуждением? Что-то из серии решения глобальных политических вопросов на отдльно взятой кухне. А указать коллеге на ошибку в рассуждениях, разве это плохо? В конце концов, интуиция — не всегда надёжный помощник. В идеале интуитивные догадки (а равно и мнения) сначала верифицируются, а потом уже возводятся в ранг аргументирующих утверждений.
VD>И при этом ты именно что требуешь обоснованиий, так как не получив оных ты начинаешь утверждать, что ценность такое мнение иметь не можешь (чем в общем-то оскорбляешь носителя этого мнения).
Ничего оскорбительного в таком утверждении нет. Либо ты как-то слишком уж чувствительно относишься к указаниям на ошибки в своих рассуждениях. Да и не с кинжалом же от тебя доказательств требуют. Даже забанить не угрожают.
ПК>>Впредь буду заранее уточнять, собираешься ли ты аргументировать то или иное свое спорное утверждение, или это очередное ИМХО. VD>Паша. Я уже понял, что иностранные термины для тебя намного доходчивее, нежели обычные русские слова. Запомни на будущее, что русское слово "по-моему" == дебильному транслитерированному ИМХО.
А вот это уже действительно смахивает на оскорбление.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, vdimas, Вы писали:
V>>Я бы ввел обязательную спецификацию исключений.
AVK>Вот в джаве такое сделали. В результате большинство современных фреймворков используют исключения, отнаследованные от RuntimeException, которые специфицировать не надо.
да, тут даже не столько в спецификации исключений дело, сколько в единой объектной иерархии этих исключений.
В С++ с этим бардак, надо признать. Каждый С++ фреймворк начинается с того, что народ описывает свою собственную иерархию ексепшенов. Совместное использование этих фреймворков — это нечто
(все это решаемо, разумеется, но за отдельную плату)
но это практически единственное, что мне не хватает в С++. Все остальное либо есть, либо достижимо, причем с небывалой степенью гибкости.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не, дело не в этом. Дело в том, что публично высказанное ошибочное мнение, оставленное без соответствующих contra может принести кому-то вполне реальный вред. Мне например. И кстати, это одна из причин, по которой я, например, тусуюсь на этом форуме.
Да, да!!! Я тоже здесь тусуюсь в ожидании получения вполне реального вреда!
Пока получается с точностью до наоборот... не везет, короче...
Здравствуйте, vdimas, Вы писали:
ГВ>>Не, дело не в этом. Дело в том, что публично высказанное ошибочное мнение, оставленное без соответствующих contra может принести кому-то вполне реальный вред. Мне например. И кстати, это одна из причин, по которой я, например, тусуюсь на этом форуме. V>Да, да!!! Я тоже здесь тусуюсь в ожидании получения вполне реального вреда! V>Пока получается с точностью до наоборот... не везет, короче...
Дима, спасибо за поправку. Естественно, я тусуюсь тут того, чтобы не допустить такого вреда.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Паша со мной в чем-то согласился. Это надо отпразновать. 
