я тебя убедительно прошу читать сообщения целиком, до того, как ты начинаешь отвечать. Иначе вести беседу с тобой чрезвычайно затруднительно, т.к. по ходу составления ответного сообщения ты задаешь множество вопросов, ответы на которые ты мог бы получить, прочитав один-два следующих абзаца.
Кроме того, так как сообщения разрослись до сложнопотребляемых размеров, в этом я касаюсь только вопросов соответствия компиляторов стандарту. Ответы на сравнения с другими языками пойдут в другое сообщение, которое я напишу позже. Сюда вопросы сравнения языков, пожалуйста не примешивай — а то совсем каша, а не обсуждение получается.
> ПК> С 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
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
>>> Какова цель спецификации языка?
> ПК>Как и у любой спецификации: точно (насколько возможно полно и непротиворечиво) описать предмет спецификации, т.е. язык.
> Можно назвать успешным описание С++ если МС, Борланд и пр. не могут реализовать этот стандарт?
Могут. Но пока не реализовали. И вовсе не из-за того, что язык плохо специфицирован, а из-за маркетинговых соображений: были заняты другим.
Borland, насколько мне известно, купил front end у EDG. Это означает, что Borland в следующем релизе, если у них там спецы в состоянии справиться с тем, что сделал один Грег Камю, будет поддерживать стандарт полностью, включая export (*) (насколько вообще возможно полное соответствие какому-либо стандарту).
В Microsoft до недавнего времени на стандарт плевали с высокой колокольни, и занялись поддержкой оного, когда увидели, что это становится, действительно, важным для их пользователей. Разница между VC++6.0/VC++7.0 и VC++7.1 в отношении поддержки стандарта радикальная. Когда у меня была возможность пообщаться с командой VC++ в апреле, они сказали, что в VC++8.0 особых продвижек в отношении степени поддержки стандарта не будет, т.к. все их силы направлены на C++/CLI. Поднимать соответствие стандарту планируется в следующем после Whidbey релизе.
Другой большой игрок на этом поле, GCC, уже соответствует стандарту в очень большой степени, пожалуй, за исключением некоторых тонкостей, не имеющих серьезного значения для практической работы.
В общем, если уж EDG, где работает всего несколько человек, были в состоянии сделать компилятор, полностью поддерживающий стандарт, то и другим компаниям это под силу. Вопрос только в том, насколько это компаниям было нужно.
Сегодня стало нужно.
>>> Т.е. несовместимость между Борлад С++ и VC++ — это проблемы языка, а не его стандарта?
> ПК>Если речь идет о разной трактовке некоторых языковых конструкций, то в подавляющем большинстве случаев это проблемы реализаций, нарушающих стандарт.
> Так почему же реализации Явы и Шарпа трактуют конструкции одинаково, а С++-а по разному. Может быть все же в этом виновата именно спецификация?
Относительно реализаций Шарпа у меня достаточной информации нет. То, что мне удалось найти, говорило о том, что не так уж и одинаково. Но, похоже, точно еще ничего не известно, т.к. нет достаточного использования одними и теми же проектами разных реализаций. Поживем — увидим.
Относительно же Java, боюсь тебя разочаровать, но спецификация там далеко не везде точная, и разница между реализациями есть, причем в фундаментальных и простых моментах, таких как контроль доступа к членам классов и т.п. Например, вот одна из соответствующих работ: http://www.cis.nctu.edu.tw/~wuuyang/papers/CTHPC2002ambiguities.pdf
> Может быть она излишне запутана, противоричива или еще что-то?
В C++ дело не в качестве спецификации, а в том, что, как уже говорилось, на момент выхода стандарта уже было значительное количество кода, написанное под реализации, созданные еще до выхода стандарта, плюс сами реализации.
Проще говоря, стандарт немного запоздал. И, соответственно, компании-разработчики не торопились дорабатывать свои компиляторы ввиду обратной совместимости, и отсутствия достаточных стимулов для этой доработки.
Теперь ситуация значительно изменилась, соответствие стандарту стало важным, и разработчики компиляторов и стандартных библиотек стремительно дорабатывают свои продукты. Динамику этого можно видеть, например, в работе: http://www.cs.clemson.edu/~malloy/projects/ddj/paper.pdf С тех пор, имхо, ситуация еще значительно улучшилась, но я некоторое время за соответствующими исследованиями не следил.
> Понятно, что она может быть написана без ошибок, и в ней может быть учтено все что только можно. Только при этом она будет противоричива, запутана или приводить к диким временным затратам на семантический анализ. Все это брак.
Пожалуй, единственная, действительно, сложно поддающаяйся проверке вещь, это ODR (One Definition Rule). Но это никак не связано с качеством спецификации. Это следствие одного из требований к языку, совместимости с C на уровне модели трансляции и компоновщика.
> ПК> Если речь идет о бинарной совместимости порождаемых объектных файлов, то это не является проблемой ни языка, ни стандарта — это вещи, которые отданы на откуп реализациям, точно так же, как, скажем, способ, каким пользователь указывает компилятору каталоги для поиска заголовочных файлов и т.п.
> Самому то не смешно? В спецификации не оговорены важнейшие аспекты построения компиляторов и рантайм-систем.
Нет, не смешно. Эти моменты опускают почти (?) все известные мне стандарты языков, работающих непосредственно с аппаратной платформой. Может, тебе известен хотя бы один стандарт кросс-платформенного языка (работающего непосредственно с платформой, без прокладки типа JVM или .Net), который специфицирует эти подробности?
> Это приводит к физической несовместимости компиляторов. Это не доработки. Это уже дырища.
Это следствие кроссплатформенности. С этим сложно (невозможно?) что-то сделать. Как ты себе представляешь бинарную совместимость между объектными файлами для x86 и, скажем, Macintosh?
>>> Ну, и еще один вопрос. Судя по твоим переключением стрелок на язык ты считашь, что С++ плохо спроектированный язык с хорошей спецификацией. Так?
> ПК> Не так.
> Как же не так? Тут у тебя явные не соотвестия. По твоим словам, у стандарта проблем нет.
Этого я не говорил.
> У языка теже.
И этого тоже.
Я только сказал, что названные тобой "проблемы" ни к проблемам стандарта, ни к проблемам языка не относятся.
> А результат мягко говоря кривоватый.
Мягко говоря, спорный момент.
> Когда мы говорили о проблемах спецификации ты кивл на язык и говоришь, что мол проблемы его.
Этого я тоже не говорил. Ты, вероятно, спутал моменты, когда я утверждал что некоторые из твоих реплик не относятся к обсуждению качества стандарта, а относятся к обсуждению языка. Утверждений о наличии или отсутствии проблем, насколько я помню, я не делал.
> ПК> Под качеством проектирования языка я подразумеваю соответствие результата сформулированным требованиям к языку
> То есть качество получившегося языка тут как бы и не причем?
Ты вырезал фразу из контекста.
> ПК> плюс, в рамках этих требований — соблюдение "общих" принципов проектирования языка.
> То есть все что угодно, но не качество результата?
Это и есть "качество результата". Я ж, вроде, даже ссылки на книги дал, чтобы можно было подробнее посмотреть.
>>> И очень интересно каковы твои критерии определения сложности языка?
> ПК> Количество разных понятий, которыми язык оперирует.
> Ну, по количеству понятий Шарп даже первой версии значительно превосходит плюсы. Причем даже версии 1.0. А уж 2.0...
Это снова личное мнение, или же тебе известны какие-нибудь серьезные данные по этому поводу? Заметь, я не утверждаю ни что C# проще, чем C++, ни что он сложнее. Только отмечаю, что я не видел подобных данных.
> Хотя конечно установление зависимости между сложностью языка и возможностью сравнения спецификаций, мяго говоря, необоснованно.
Размеров спецификаций.
>>> Если на базе этого описания у десятка серьезных и очень богатых контор не удается создать компиляторы которые одинаково интерпреритруют исходный код, то я назывю такой стандарт не качественным. > > ПК>Это уже намного ближе. > > К чему? Что у спецификации есть какие-то иные цели кроме описания языка?
Вот и мне удивительно, с чем же ты тогда споришь, если согласен, что единственной задачей спецификации является точное описание языка...
> ПК> Теперь осталось поправить "не удается" на "до сих пор не сделали"
> Это дно и тоже. На сегодня нет. Значит не удается.
Не значит. Тут очевидная логическая брешь. Из отсутствия чего-либо невозможность этого не следует. Более того, разработчикам из EDG, компании значительно меньшего размера, чем Borland или, тем более, Microsoft, это удалось за вполне приемлемое время. Свои соображения относительно того, почему компиляторы Borland и Microsoft не соответствуют стандарту, я уже изложил.
> ПК> и проанализировать, почему это так: из-за качества стандарта, либо же из-за других причин. К последним в данном случае можно отнести существование множества реализаций еще до создания стандарта,
> Да? Во оно как? Попробуй обосновать это утверждение.
Компании-разработчики компиляторов делают компилятор совместимым со стандартом не просто так, а потому что это нужно их пользователям. Некоторое время назад, для пользователей более важной была совместимость со своим старым кодом, чем со стандартом. По мере развития библиотек, использующих все большее количество возможностей, описанных в стандарте (boost, Loki, Blitz, Pooma, STLport и т.п.), у пользователей появились потребности в большем соответствии компиляторов стандарту. Соответственно, чаша весов "соответствие старому коду" — "соответствие стандарту" начала перевешиваться в сторону последнего.
Очень многие моменты, в которых компиляторы не соответствовали стандарту, вызваны именно историческими причинами, тем, что эти возможности уже были реализованы в компиляторах, и менять их без достаточных оснований разработчики не хотели (см. также свежий пример ниже).
> ПК> плюс множество проблем, связанных с обратной совместимостью с кодом, написанным под реализации, не соответствующие стандарту.
> И это тоже.
> Я лично не вижу никакой зависимости между совместимостью и соотвествием стандартов. Тот же МС ввел пару тройку ключей компилятора и проблемы совместимости решились. Но VC как не был совместим со стандартом, так и не совместим.
VC++ значительно продвинулся в этом отношении. Но ты серьезно недооцениваешь влияние обратной совместимости. Скажем, даже вполне очевидные и легкие в исправлении несоответствия стандарту, разработчики VC++ подчас отказываются исправлять именно из-за нарушения обратной совместимости с существующим кодом. Простой пример.
В режиме межфайловой оптимизации VC++ может объединять специализации шаблонов, что в результате приводит к тому, что адреса разных специализаций шаблонов оказываются одинаковыми — стандарт явным образом это запрещает. Простым вариантом, позволяющим сохранить данную оптимизацию, плюс сделать компилятор более соответствующим стандарту, было бы в случае взятия адреса подобной специализации выдавать адрес специальной функции, состоящей из одного jmp на соптимизированную специализацию. Так бы и овцы были бы целы (требование стандарта было бы соблюдено), и волки были бы сыты (оптимизация бы работала, как задумано).
Однако разработчики VC++ отказались от такого варианта именно на основании того, что может существовать код, который предполагает, что по адресу функции находится непосредственно ее реализация.
> Возьмем например экспорт шаблонов. Чистейшей воды профанация, так как как их не экспортируй, а проблемы шаблонов и препроцесор не позволяют создать приемлемой промежцточной формы для подобного экспорта.
Позволяют. Хотя я вполне разделяю скептическое отношение к экспорту шаблонов.
> Теперь сравни это решение с теми же дженириками в дотнете и попробуй после этого утвержадать, что решения выбранные в С++ были глубоко продуманными,
Все известные мне решения были вполне глубоко продуманными. В том смысле, что никакие из них не принимались без обсуждения и взвешивания альтернатив. В некоторых решениях были допущены ошибки. Но это справедливо и для любого другого языка, тем более, имеющего столь продолжительную историю развития.
> а спецификация непротиворичивой.
> Ясно как божий день, что сложность реализации на практике проистикает из-за проблем спецификации. Просто проблемы бывают разного рода. Ты почему-то недоговоренности в виде неопределенного поведения
Еще раз: неопределенное поведение это не недоговоренности. Все случаи явно продекларированного неопределенного поведения, которые я анализировал, были приняты вполне сознательно. Это не "недоговоренности", это проектные решения, проистекающие из свойств языка и его истории.
Яркий пример, скажем, та же проверка выхода за границы массивов. Потребовать этой проверки стандарты C и C++ физически не могли из-за наличия большого количества реализаций, которые этого не делали, и которые просто проигнорировали бы подобное требование стандарта, а вместе с ним и весь стандарт. Кроме исторических причин есть и другие: не всегда накладные расходы проверок выхода за пределы массивов допустимы по тем или иным причинам.
Соответственно, оба стандарта были специально написаны так, чтобы ее допускать, но не требовать.
И реализации C или C++, проверяющие выход за границы массивов вполне возможны (и существуют). Как это делать, и почему этого не делают популярные реализации, уже в этом форуме описывалось.
Если бы, например, те же указатели в нынешнем виде были из C или C++ удалены, это было бы спецификацией совсем других языков. Качество (точность) же самих спецификаций при этом не обязательно бы изменилось.
(*) "Фича", конечно, сомнительной нужности и очень большой сложности в реализации, и я не обижусь, если те же Microsoft ее реализовывать не будут. Но реализовать можно. Было бы желание.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2, >> Стандат Шарпа проработан куда лучше, но размер он имеет даже меньший. ПК>А каков твой критерий качества проработки стандарта?
Очевидно — это причастность стандарта к языку, на котором сам программируешь
Здравствуйте, 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.: Винодельческие провинции — это есть рулез!
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,
> Чтобы сравнивать стандарты нет никакой нужны сравнивать в них буквы и искать недочеты. Достаточно прочесть и составить собственное мнение. Причем порой даже все читать не нужно. Делаешь просто поиск по словосочетанию "неопределенное поведение" <...>
Количество упоминаний неопределенного поведения никак не связано с качеством проработки стандарта.
> или смотришь что в спецификации есть по работе с модулями и все становится понятно.
То же самое. Это вопросы специфицируемого языка, а не качества проработки стандарта.
> Потом сравнивашь объемы спецификаций...
Без сравнения сложности языков это не имеет значения.
P.S. В общем, похоже, мы с тобой подходим к данному вопросу совсем с разных сторон: ты со стороны личных предпочтений и собственных мнений, а я со стороны возможности количественного/точного сравнения. Дальше, наверное, можно не продолжать, так как эти дорожки вряд ли встретятся.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> Апеллируй скоько тебе влезет, если хочется. Для меня сказанное мной очевидно. Но заниматься глупыми доказательствами просто не считаю нужным. Жизнь и так все расставляет на свои места.
Именно об этом я и говорил: безаргументированное ИМХО ("имею мнение, хрен оспоришь"). Как было верно замечено ранее, "цена — копейка в базарный день". Т.е. для читателя, желающего узнать (*) что-то новое, никакой ценности подобные сообщения не несут.
(*) Узнать, а не поверить. Т.е. иметь возможность убедиться в правильности рассуждений автора, обоснованности его предпосылок и т.п., а не уверовать в то, что автор (для которого все сказанное им "очевидно"), знает, что и куда расставит жизнь.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК> А каков твой критерий качества проработки стандарта?
> 1. Минимальное количество определенностей. > 2. Максимальная логичность языка. > 3. Синимизация граблей. > Ну, а в итоге понятность, простота, надежность.
Интересно... По мне, это больше похоже на критерии качества языка, а не его стандарта.
Имхо, главным критерием качества проработки собственно стандарта является количество его разночтений разными разработчиками: чем этих разночтений меньше, тем стандарт проработаннее. Скажем, для того же C# мне пока сложно об этом судить, т.к. еще не видно сколько-нибудь значительного количества проектов, использующих разные его реализации.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Итак. Я утверждаю, что требуют доказательства только не очевидные заявления сделанные в ходе логического вывода или доказательства. Все же остальные случаи являются выражением личного мения и подтверждения не требуют. В противном случае ты ставишь собеседника в очень неудобное положение. В народе это называется заставлять доказывать, что ты не верблюд.
бурные аплодисменты.
в статике это выглядит приемлимо, однако, наблюдая за динамикой дисскуссии — не очень.
бывают споры "за жисть", а бывают аргументированные обмены мнениями, если ввязался в последнее — изволь соответствовать... или не ввязываться.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Можно назвать успешным описание С++ если МС, Борланд и пр. не могут реализовать этот стандарт?
ПК>Могут. Но пока не реализовали. И вовсе не из-за того, что язык плохо специфицирован, а из-за маркетинговых соображений: были заняты другим.
А, ну, да. С 1989-го года времени не хватает.
ПК>Borland, насколько мне известно, купил front end у EDG.
То есть сдался. Давай называть вещи своими именами. А что касается EDG — то вроде как он довольно медленнен и еще бабка на двое сказала, чем все это кончится.
Хотя весело буедет если все купят одну реализацию. Тогда твои слова о возможности множества реализаций будут очень кстати.
ПК> Это означает, что Borland в следующем релизе, если у них там спецы в состоянии справиться с тем, что сделал один Грег Камю, будет поддерживать стандарт полностью, включая export (*) (насколько вообще возможно полное соответствие какому-либо стандарту).
Какому либо может и можно. А вот этому очень сомнительно.
ПК>В Microsoft до недавнего времени на стандарт плевали с высокой колокольни, и занялись поддержкой оного, когда увидели, что это становится, действительно, важным для их пользователей.
Да то, что это важно для пользователей они поняли еще гду в 90-ом. Вот только сложно это неимоверно. Уж больно много проблем.
ПК> Разница между VC++6.0/VC++7.0 и VC++7.1 в отношении поддержки стандарта радикальная.
Ага. Только для этого им пришлось купить отдельного специалиста, так как свои что-то не очень справлялись. Видимо тупые. Стандарт прочесть не могут.
ПК> Когда у меня была возможность пообщаться с командой VC++ в апреле, они сказали, что в VC++8.0 особых продвижек в отношении степени поддержки стандарта не будет, т.к. все их силы направлены на C++/CLI.
Ну, и как, по-твоему, можно назвать хорошим стандарт на реализацию которого у багатейшей конторы в мире не хватает сил вот уже 16 лет?
ПК> Поднимать соответствие стандарту планируется в следующем после Whidbey релизе.
Ага. Им как раз тогда больше заняться нечем будет. У них как раз Лонгхор с Оркасом в 2006-ом. И есть планы переписывать ту же студию в менеджед-код.
ПК>Другой большой игрок на этом поле, GCC, уже соответствует стандарту в очень большой степени, пожалуй, за исключением некоторых тонкостей, не имеющих серьезного значения для практической работы.
Да для практики не имеют значения и все что не реализовано в VC 7.1. Один фиг все ведущие библиотеки под него и GCC затачиваются. Вот только у тех кто делает стандарт так и не возникло мысли привести его к этой самой практике. А то и еще больше упростить, чтобы на его реализацию не требовалось 16 лет и покупки супер-спецов.
ПК>В общем, если уж EDG, где работает всего несколько человек, были в состоянии сделать компилятор, полностью поддерживающий стандарт, то и другим компаниям это под силу. Вопрос только в том, насколько это компаниям было нужно.
Вопрос скорее в квалификации и упертости спецов. Ну, и вопрос в том, что это за спецификация такая которую не очень то охотно поддерживают.
ПК>Сегодня стало нужно.
Так почему же 16 лет было не нужно?
>> Так почему же реализации Явы и Шарпа трактуют конструкции одинаково, а С++-а по разному. Может быть все же в этом виновата именно спецификация?
ПК>Относительно реализаций Шарпа у меня достаточной информации нет.
Ну, скачай Моно погляди. У них с cs.exe совместимость даже бинарная. Ошибки правда есть у обоих компиляторов. Но одинаковый код они воспринимают одинаково.
ПК> То, что мне удалось найти, говорило о том, что не так уж и одинаково.
Не правду говоришь. То что ты смог найти — это описание трудностей связанных с бинарной реализацией. Оной в С++ вообще не существует. Так что и сравнивать нечего. А вот со спецификацией языка проблем ты так и не нашел. Я правда знаю по одной у каждого из компиляторов. Можно слишком вольно трактует глобальные атрибуты (может найти их черти где) — это проблема Yacc-а используемого ими. А у МС есть забавнейшая проблема с интерпретацией констант при некотором стечении обстоятельств. Но это все. Причем это именно ошибки в софте, а не проблемы стандарта. Ту же Моновскую багу я лично обошел. Может быть есть еще что-то неоткрытое, но с проблемами компиляторов С++ это ни в какое сравнение не идет. Оными забиты все форумы.
ПК> Но, похоже, точно еще ничего не известно, т.к. нет достаточного использования одними и теми же проектами разных реализаций. Поживем — увидим.
Да есть. Почти все проекты создаваемые для Моно проверяются на дотнете. Да и сам Моно прекрасно компилируется на дотнете — это просто огромный проект.
ПК>Относительно же Java, боюсь тебя разочаровать, но спецификация там далеко не везде точная, и разница между реализациями есть, причем в фундаментальных и простых моментах, таких как контроль доступа к членам классов и т.п. Например, вот одна из соответствующих работ: http://www.cis.nctu.edu.tw/~wuuyang/papers/CTHPC2002ambiguities.pdf
Да, такие бы проблемы плюсам и глядишь Явы бы и на свет не появилось бы.
>> Может быть она излишне запутана, противоречива или еще что-то?
ПК>В C++ дело не в качестве спецификации, а в том, что, как уже говорилось, на момент выхода стандарта уже было значительное количество кода, написанное под реализации, созданные еще до выхода стандарта, плюс сами реализации.
А. Ну, да. Именно это и помешало МС за 16 лет реализовать стандарт. Гы-гы.
Продумывание грамотной интеграции конечно в задачи тех, кто придумывал язык и писал его спецификацию не входило. Логично.
ПК>Проще говоря, стандарт немного запоздал. И, соответственно, компании-разработчики не торопились дорабатывать свои компиляторы ввиду обратной совместимости, и отсутствия достаточных стимулов для этой доработки.
Сильно же они не торопились. Стандарт в сегодняшнем виде существует с 1998-го.
ПК>Теперь ситуация значительно изменилась,
Оно и понятно. На С++ пишется все ольше и больше кода. Конкуренты вымирают пачками...
ПК> соответствие стандарту стало важным, и разработчики компиляторов и стандартных библиотек стремительно дорабатывают свои продукты. Динамику этого можно видеть, например, в работе: http://www.cs.clemson.edu/~malloy/projects/ddj/paper.pdf С тех пор, имхо, ситуация еще значительно улучшилась, но я некоторое время за соответствующими исследованиями не следил.
Да, да. Ценная ссылка. Какой рывок совместимости!
Проудкт год выпуска процент успешных тестов
VisualC++ 6.0 1998 73.6
VisualStudio 7.0 2000 77.1
и того у МС просто грандиозный рывок! За 2 года аж 3.5%! Если так дело пойдет и дальше то, им осталось 6.5 лет до полного соответствия. Хотя 7.1 отличий от 7.0 практически не имеет, да и по твоим словам 8.0 тоже иметь особо не будет.
>> Понятно, что она может быть написана без ошибок, и в ней может быть учтено все что только можно. Только при этом она будет противоречива, запутана или приводить к диким временным затратам на семантический анализ. Все это брак.
ПК>Пожалуй, единственная, действительно, сложно поддающаяйся проверке вещь, это ODR (One Definition Rule). Но это никак не связано с качеством спецификации. Это следствие одного из требований к языку, совместимости с C на уровне модели трансляции и компоновщика.
Ага. Во всем виноват С. Причем виноват на столько, что из одного из самых простых языков (это я о С) С++ превратился в один из самых сложных. Вот парадокс? И самое парадоксальное, что из-за отсутствия совместимости и сложности реализации переносимые системы так и пишут на С. Просто таки не С, а какой-то демон.
>> Самому то не смешно? В спецификации не оговорены важнейшие аспекты построения компиляторов и рантайм-систем.
ПК>Нет, не смешно. Эти моменты опускают почти (?) все известные мне стандарты языков, работающих непосредственно с аппаратной платформой. Может, тебе известен хотя бы один стандарт кросс-платформенного языка (работающего непосредственно с платформой, без прокладки типа JVM или .Net), который специфицирует эти подробности?
Гы. Оберон. Хотя вроде D, Модула, Дельфи и его куча разных языков. Не обязательно же описывать все? Но вопрос модулей, их загрузки и т.п. охватывают многие более современные языки. Да что там далеко ходить? Я тут видел соответствующий запрос в стандарт С++.
>> Это приводит к физической несовместимости компиляторов. Это не доработки. Это уже дырища.
ПК>Это следствие кроссплатформенности.
От (!) опять парадокс. У Явы и дотнета с ней родимой куда лучше, а модули описаны. Даже Delphi перетащили под Линукс, а ведь и в ней модули описаны.
ПК> С этим сложно (невозможно?) что-то сделать. Как ты себе представляешь бинарную совместимость между объектными файлами для x86 и, скажем, Macintosh?
А не нужна бинарная совместимость для разных платформ. Нужно ввести в стандарт понятие модуля, метаданных и других вещей. Тогда подобных проблем или вообще не будет, или не будет хотя бы на одной платформе.
>> Как же не так? Тут у тебя явные не соотвестия. По твоим словам, у стандарта проблем нет.
ПК>Этого я не говорил.
От тебе раз. А о чем ты говорил? Столько всего сказал, а ничего не говорил.
>> У языка теже.
ПК>И этого тоже.
Значит таки есть? Причем и у языка, и у стандарта? Или этого ты тоже не говорил?
ПК>Я только сказал, что названные тобой "проблемы" ни к проблемам стандарта, ни к проблемам языка не относятся.
Да конечно. А к чему же они тогда относятся. Или это как в том анекдоте. Ж..а есть, а слова нет?
>> А результат мягко говоря кривоватый.
ПК>Мягко говоря, спорный момент.
Давно ясно, что язык напичкан граблями и проблемами. Но всегда найдутся люди, которым приятнее закрыть глаза.
>> Когда мы говорили о проблемах спецификации ты кивл на язык и говоришь, что, мол, проблемы его.
ПК>Этого я тоже не говорил.
Ну, т.е. ты говорил только, что ничего не знаешь? Типа проблемы есть, но они точно не спецификации, и точно не языка. Изумительно!
ПК> Ты, вероятно, спутал моменты, когда я утверждал что некоторые из твоих реплик не относятся к обсуждению качества стандарта, а относятся к обсуждению языка. Утверждений о наличии или отсутствии проблем, насколько я помню, я не делал.
Пашь, так сделай заявление! Одно из двух. Или проблемы есть. Или их нет. Не может же быть в данном вопросе промежуточного состояния. Сфероконики в природе не водятся.
>> ПК> Под качеством проектирования языка я подразумеваю соответствие результата сформулированным требованиям к языку
>> То есть качество получившегося языка тут как бы и не причем?
ПК>Ты вырезал фразу из контекста.
Да? Я вот мне кажется, что ты уклонился от прямого вопроса. Так все же является ли качество языка следствием качества проектирования или качества языка никак не связано с качеством проектирования?
>> ПК> плюс, в рамках этих требований — соблюдение "общих" принципов проектирования языка.
>> То есть все что угодно, но не качество результата?
ПК>Это и есть "качество результата". Я ж, вроде, даже ссылки на книги дал, чтобы можно было подробнее посмотреть.
А какое отношение качество результата имеет к библиографическим книгам?
Из твоих слов можно сделать вывод, что С++ вообще нельзя сравнивать с другими языками, так как он делался для удовлетворения желаний Страуструпа.
Между тем и С++, и любой другой универсальный ИЯ создавались только лишь для одного — для того чтобы писать на нем программы. И качество языка можно без каких бы то ни было ссылок сравнивать с другим качеством другого.
В общем, не нужно юлить. Скажи честно, что ты понимаешь, что сравнение качества С++ более современными языками будет явно не в его пользу. И именно по этому вся чески избегаешь этих сравнений.
А ведь все так просто. Берем типобезопасность. Струструп утверждал, что одна из целей преследовавшийся при создания С++ была создать язык более типобезопасный нежели С. Давай сравним его успехи в этой области и успехи того же Шарпа. Пишем:
int i = 2;
if (i == true)
...
получаем сообщение об ошибке в Шарпе и более чем странное поведение в С++. И это есть типобезопасность?
Идем дальше:
double d = 123;
int * p = (int*)&d;
printf("%d", i);
ах неопределенное поведение? А почему в Шарпе сообщение об ошибке компилятора или рантайма? Что мешало сделать так же? А что мешает сделать сейчас?
Ах совместимость с С... Понятно. И ведь даже в голову не приходит, что код С и С++ может компилироваться по разным правилам. И что совместимость от этого не пострадает.
Да и о какой совместимости речь? С99 напрочь не совместим с С++. Значит совместимость не так и важна?
>>>> И очень интересно каковы твои критерии определения сложности языка?
>> ПК> Количество разных понятий, которыми язык оперирует.
>> Ну, по количеству понятий Шарп даже первой версии значительно превосходит плюсы. Причем даже версии 1.0. А уж 2.0...
ПК>Это снова личное мнение,
Ага. Мнение. Это только у тебя его не бывает.
ПК> или же тебе известны какие-нибудь серьезные данные по этому поводу?
Гы. А ты не заметил, что в Шарпе на треть больше конструкций и сложнее синтаксис?
ПК> Заметь, я не утверждаю ни что C# проще, чем C++, ни что он сложнее. Только отмечаю, что я не видел подобных данных.
Так все же утверждал? Ну, так может, ответишь на искусно обойденный вопрос о критериях сложности? Вопрос то ключевой! Критерии то бываю разные. Бывают синтаксические. Тут Шарп значительно сложнее С++ и спорить бесполезно. Достаточно подсчитать количество конструкций. Бываю, субъективные. Их, правда, ты всячески пытаешься низвести до ничтожества, но тем не менее простота изучения именно субъективный критерий. Причем очень важный критерий. Тут Шарп несомненно проще. Доказательством тому является то почему народ переходит с С++ на Шарп и с какой легкостью это происходит (а языки, то сильно разные).
Ну, что у нас там осталось? Семантика? Да тут Шарп тоже сложнее. Потому и описательная часть стандарта больше.
Что же остается? А остается как раз качество языка/стандарта (называй, как хочешь). Те самые фишки вроде неопределенного поведения, неописанных в стандарте или описанных поверхностно двусмысленностей. Неразумных предпочтений. Запутанности синтаксиса. И все это как раз и есть результат непродуманности языка/спецификации. С 85-го года на это времени не хватило.
>> Хотя конечно установление зависимости между сложностью языка и возможностью сравнения спецификаций, мягко говоря, необоснованно.
ПК>Размеров спецификаций.
Хотя ты всячески клонишь к тому, что и спецификации сравнивать нельзя. Ну, да фиг с ним. Ответь хотя бы на вопрос почему нельзя сравнивать размеры и сложность языков?
Почему ты всячески избегаешь любых сравнений (особенно если они явно не в пользу С++)?
>>>> Если на базе этого описания у десятка серьезных и очень богатых контор не удается создать компиляторы которые одинаково интерпретируют исходный код, то я называю такой стандарт не качественным. >> >> ПК>Это уже намного ближе. >> >> К чему? Что у спецификации есть какие-то иные цели кроме описания языка?
ПК>Вот и мне удивительно, с чем же ты тогда споришь, если согласен, что единственной задачей спецификации является точное описание языка...
С тем, что спецификация С++ удачная. И с тем, что С++ удачный язык не требующий изменений. Ну, и с тем "единственной задачей спецификации является точное описание языка". Спецификации порождает язык. И основная (заметь, не единственная) задача спецификации породить качественный язык с минимумом неопределенностей и проблем.
>> ПК> Теперь осталось поправить "не удается" на "до сих пор не сделали"
>> Это дно и тоже. На сегодня нет. Значит не удается.
ПК>Не значит.
Значит. Как бы тебе не хотелось чтобы было по другому.
ПК> Тут очевидная логическая брешь.
Тут с логикой все ОК. Высказывание делается на сегодняшний день. Так что они полностью эквивалентны.
ПК> Из отсутствия чего-либо невозможность этого не следует.
А вот тут действительно очевидная логическая ошибка. Высказывание "На сегодня нет" не эквивалентно "невозможно в принципе".
ПК> Более того, разработчикам из EDG, компании значительно меньшего размера, чем Borland или, тем более, Microsoft, это удалось за вполне приемлемое время. Свои соображения относительно того, почему компиляторы Borland и Microsoft не соответствуют стандарту, я уже изложил.
Это все пустые слова. Двух компиляторов одинаково интерпретирующих исходный код нет. И скорее всего появятся таковые только когда какой-нибудь EDG начнет ОЕМить свой фронтенд.
Стало быть задачу создания качественного компилятора решить очень не просто. А так как сам язык особой сложности не представляет, то можно сделать однозначное заключение, что проблемы именно в стандарте.
>> Да? Во оно как? Попробуй обосновать это утверждение.
ПК>Компании-разработчики компиляторов делают компилятор совместимым со стандартом не просто так, а потому что это нужно их пользователям. Некоторое время назад, для пользователей более важной была совместимость со своим старым кодом, чем со стандартом. По мере развития библиотек, использующих все большее количество возможностей, описанных в стандарте (boost, Loki, Blitz, Pooma, STLport и т.п.), у пользователей появились потребности в большем соответствии компиляторов стандарту.
Забавно. Буст, Локи используют побочные эффекты этой спецификации которые она даже не декларировала. STLport всего лишь реализация спецификации появившейся где-то в 1992. Стандарт тоже появился очень давно. Самый последний только в 98-ом (я не ошибаюсь?). Прошло 16 лет с тех пор как появился С++, и только сегодня пользователи вдруг внезапно ощутили потребность в его стандарте. А ради чего? STLport отлично работает на VC6 и GCC 2.x. Вместо boost и Loki лучше было ввести необходимые средства в язык. Про Blitz и Pooma и сегодня мало кто слышал и они мало кому нужны.
ПК> Соответственно, чаша весов "соответствие старому коду" — "соответствие стандарту" начала перевешиваться в сторону последнего.
Да в сторону Шарпа с Явой она уже давно перевешивает. И чем дальше, тем больше.
ПК>VC++ значительно продвинулся в этом отношении. Но ты серьезно недооцениваешь влияние обратной совместимости. Скажем, даже вполне очевидные и легкие в исправлении несоответствия стандарту, разработчики VC++ подчас отказываются исправлять именно из-за нарушения обратной совместимости с существующим кодом. Простой пример.
ПК>Однако разработчики VC++ отказались от такого варианта именно на основании того, что может существовать код, который предполагает, что по адресу функции находится непосредственно ее реализация.
Пример никуда не годный, так как банальное выключение оптимизации должно привести к соответствию стандарту. В VC хватает куда более явных несоответствий.
ПК>Позволяют. Хотя я вполне разделяю скептическое отношение к экспорту шаблонов.
Чтобы они действительно позволяли, нужно серьезно ограничить шаблоны. А то и отказаться от идеи разрешения двусмысленностей на базе анализа типов (как в Шарпе). А тогда придется думать о серьезной доработки языка (если не охота остаться без поклонников).
Учитывая же что без изменения языка от экспорта шаблонов реальных преимуществ будет получить трудно. И учитывая те сложности которые возникают при реализации этого дела, реализовать эту фичу можно только из принципа. А подобное требование стандарта кроме как дополнительной трудностью назвать нельзя.
ПК>Все известные мне решения были вполне глубоко продуманными. В том смысле, что никакие из них не принимались без обсуждения и взвешивания альтернатив.
А если все же смотреть не на процесс, а на результат?
ПК> В некоторых решениях были допущены ошибки.
Я бы сказал, что "во многих".
ПК> Но это справедливо и для любого другого языка, тем более, имеющего столь продолжительную историю развития.
В таких объемах не для многих. Пожалуй что С++ тут один из лидеров. Хотя С конечно фаворит.
ПК>Еще раз: неопределенное поведение это не недоговоренности. Все случаи явно продекларированного неопределенного поведения, которые я анализировал, были приняты вполне сознательно.
Ага. Классика:
int x = i++ + ++i;
ну, куда уж было довести стандарт, чтобы в этом случае все было четко определено. Или это баги компиляторов?
ПК> Это не "недоговоренности", это проектные решения, проистекающие из свойств языка и его истории.
И то, что от подобных "проектных решений" избавляются как от вшей все мало-мальски грамотные авторы языков — это случайность? Это не проектные решения. Это именно непродуманность. Всегда проще объявить проблему не решаемой и посоветовать не наступать на грабли.
Например, возьмем автоматическое приведение инта к булеву типу и обратно. Булев тип был введен далеко не для совместимости с С. И код использующий его явно рассчитан на его поведение. Но почему же тогда было не описать какие-нибудь опции совместимости (те же прагмы) которые вводят строгую типизацию с возможностью выключать ее для унаследованного кода?
ПК>Яркий пример, скажем, та же проверка выхода за границы массивов. Потребовать этой проверки стандарты C и C++ физически не могли
Очень даже могли. Более чем могли. На сегодня даже кое-что реализовано вопреки стандарту.
ПК> из-за наличия большого количества реализаций, которые этого не делали, и которые просто проигнорировали бы подобное требование стандарта, а вместе с ним и весь стандарт.
Еще раз. Цена вопроса — введение уровня совместимости с унаследованным кодом. А то и просто объявление наплевать и растереть. Со временем бы все подтянулись. Подтянулись же до более сложных вещей. Я, например, провел два дня переписывая код проектов чтобы перейти с VC6 на VC7. А потом еще день чтобы перейти с 7.0 на 7.1. И ничего. МС даже не задумался о том, что у меня будут проблемы. А ведь могли бы хоть диагностику по приличнее сделать. А то ведь я пол дня въезжал в то, что компилятору нужно подставить typenae кое-где.
ПК> Кроме исторических причин есть и другие: не всегда накладные расходы проверок выхода за пределы массивов допустимы по тем или иным причинам.
Это чушь, а не причины. 1. Кому нужно сделали бы фичу опциональной. 2. Все современные компиляторы с успехом выносят инварианты из циклов и т.п. так что через год проблемы вообще не было бы. В том же дотнете влияния этих проверок не чувствуется.
ПК>Соответственно, оба стандарта были специально написаны так, чтобы ее допускать, но не требовать.
Да, уж. Без фактического наличия в языке массивов допускать подобное можно только для классов-оберток.
ПК>И реализации C или C++, проверяющие выход за границы массивов вполне возможны (и существуют). Как это делать, и почему этого не делают популярные реализации, уже в этом форуме описывалось.
Этот вопрос просто не был продуман. Если бы об этом задумались (кстати, похоже, в С99 таки задумались), то ввели бы четкое понятие массива, чтобы было где этот контроль осуществлять. А так, по жизни все работают с указателями, которые контролировать крайне сложно. Остается только вектор и т.п. Но к языку это уже имеет отношение отдаленное. Главное, что страдает надежность.
ПК>Если бы, например, те же указатели в нынешнем виде были из C или C++ удалены, это было бы спецификацией совсем других языков.
Гы. Вот это уже ближе к реалиям. Опять глядим на Шарп. Указатели есть, но они четко удалены в небезопасный контекст, где допустимо неопределенное поведение. И есть полноценные заменители указателей вроде массивов и ссылочных типов. Поступи похожим образом создатели С++... глядишь у Оберонщиков пропала бы столь любимая тема для обсасывания. Заметь, чуть что они сразу начинают доказывать преимущество Оберона на базе недостатков С++. Просто-таки экспонат в кунсткамере.
ПК> Качество (точность) же самих спецификаций при этом не обязательно бы изменилось.
"Точность" не единственная характеристика качества. Это ты пытаешься сделать эти понятие тождественными.
Сложность реализации, количество неопределенностей, ясность изложения наконец, все это тоже критерии измерения качества.
ПК>
ПК>(*) "Фича", конечно, сомнительной нужности и очень большой сложности в реализации, и я не обижусь, если те же Microsoft ее реализовывать не будут. Но реализовать можно. Было бы желание.
Реализовать можно все. Вот только зачем? И какой ценой?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AVK>...
AVK>Материал из Википедии — свободной энциклопедии
AVK>...
Эпиграф:
Не читайте советских газет. (с) Булгаков.
И русскую Википедию. (с) Зверёк
The word "byte" has several meanings, all closely related:
1. A contiguous sequence of a fixed number of bits. On modern computers, an eight-bit byte or octet is by far the most common. This was not always the case. Certain older models have used six-, seven-, or nine-bit bytes — for instance on the 36-bit architecture of the PDP-10. Another example of a non eight-bit sequence is the 12-bit slab of the NCR-315. A byte is always atomic on the system, meaning that it is the smallest addressable unit. An eight-bit byte can hold 256 possible values (28 = 256) -- enough to store an unsigned integer ranging from 0 to 255, a signed integer from -128 to 127, or a character of a seven-bit (such as ASCII) or eight-bit character encoding.
2. A contiguous sequence of bits that comprises a sub-field of a longer sequence known as a word. On some computers it is possible to address bytes of arbitrary length. This usage is reflected, for example, in LDB and DPB assembly instructions for field extraction on a PDP-10, which survive as bytewise operations in Common Lisp; and in the six-bit bytes of the IBM 1401.
3. A datatype or synonym for a datatype in certain programming languages. C, for example, defines byte as a storage unit capable of at least being large enough to hold any character of the execution environment (clause 3.5 of the C standard). Since the C char integral data type can hold at least 8 bits (clause 5.2.4.2.1), a byte in C is at least capable of holding 256 different values (signed or unsigned char doesn't matter). Java plays it simpler. Java's integral byte data type is always defined as consisting of 8 bits and being a signed data type, holding values from -128 to 127.
VladD2,
> ПК> Количество упоминаний неопределенного поведения никак не связано с качеством проработки стандарта.
> Какова цель спецификации языка?
Как и у любой спецификации: точно (насколько возможно полно и непротиворечиво) описать предмет спецификации, т.е. язык. Применительно к стандартам языков это обычно (в зависимости от подхода, выбранного составителями спецификации) означает наличие множества требований к программе, и описание того, что последует в случае, когда программа этим требованиям соответствует.
Далее, важно проводить разделение между теми моментами, которые упущены при составлении спецификации, т.е. ситуации, для которых упущены требования (дефекты последней), и моментами, сознательно спецификацией не регулируемые, т.е. ситуации, для которых требования есть, но отсутствует описание, что последует в случае нарушения данных требований. Последние в стандартах обычно называют ведущими к неопределенному поведению.
Подчеркиваю, что неопределенное поведение не обязательно должно быть явно указано: нарушение любых требований, указанных в спецификации, если не оговорено обратное, приводит к неопределенному поведению. Вот, например, цитата из стандарта C#:
If any requirement of this International Standard is violated, the behavior is undefined.
> И может ли быть у "плохого" языка хорошая спецификация?
Конечно. Для любого языка существует гамма точности возможных его описаний. По-моему, обоснование данного момента достаточно очевидно: в любую спецификацию достаточно легко внести неточность, и наоборот, при обнаружении неточности ее можно устранить теми или иными усилиями. Впрочем, все это верно для любой спецификации, не только спецификации языка.
>>> или смотришь что в спецификации есть по работе с модулями и все становится понятно.
> ПК>То же самое. Это вопросы специфицируемого языка, а не качества проработки стандарта.
> Т.е. несовместимость между Борлад С++ и VC++ — это проблемы языка, а не его стандарта?
Если речь идет о разной трактовке некоторых языковых конструкций, то в подавляющем большинстве случаев это проблемы реализаций, нарушающих стандарт. Если речь идет о бинарной совместимости порождаемых объектных файлов, то это не является проблемой ни языка, ни стандарта — это вещи, которые отданы на откуп реализациям, точно так же, как, скажем, способ, каким пользователь указывает компилятору каталоги для поиска заголовочных файлов и т.п.
> Ну, и еще один вопрос. Судя по твоим переключением стрелок на язык ты считашь, что С++ плохо спроектированный язык с хорошей спецификацией. Так?
Не так. Под качеством проектирования языка я подразумеваю соответствие результата сформулированным требованиям к языку (анализ этих моментов для C++ можно найти в книге "Дизайн и эволюция C++"), плюс, в рамках этих требований — соблюдение "общих" принципов проектирования языка (см., например, Пратт, Зелковиц. "Языки программирования, разработка и реализация", или, на худой конец, Себеста. "Основные концепции языков программирования").
> И очень интересно каковы твои критерии определения сложности языка?
Количество разных понятий, которыми язык оперирует.
> Если на базе этого описания у десятка серьезных и очень богатых контор не удается создать компиляторы которые одинаково интерпреритруют исходный код, то я назывю такой стандарт не качественным.
Это уже намного ближе. Теперь осталось поправить "не удается" на "до сих пор не сделали" и проанализировать, почему это так: из-за качества стандарта, либо же из-за других причин. К последним в данном случае можно отнести существование множества реализаций еще до создания стандарта, плюс множество проблем, связанных с обратной совместимостью с кодом, написанным под реализации, не соответствующие стандарту.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>И вот тут возникает вопрос. Почему такие бабки кладутся на разрботку нового языка — сишарпа, и упровляемой среды упровления? Ведь С++ так крут, что казалось бы в него то и нужно бабки вбухивать. А они так тебе. Вкладывают в "почти скриптовый" язык. Тут были товарищи сравнивающие этот язык с Питоном и метившие ему место в качестве средств написания юнит-тестов. Почему же такая странная оценка МС? Зачем они с Саном переругались только ради права улучшения ява-машины и языка Ява? К чему такие затраты?
Дык, тебе уже вроде ответили, а ты опять спрашиваешь:
Весь C++ изначально предназначен именно для того, для чего в C# создан unsafe. Весь. И отлично с этим справляется. Его использование для более прикладных задач требует большей квалификации, чем использование C#.
Сейчас надо писать не много программ, а очень много. Держать дорогих программистов — накладно. На фирмах сидят под сотню прогеров, им надо кнопки нафиг на формы бросать, перехватывать Click-и, читать записи из базы данных, находить среднее арифметическое, применяя правила округления, рисовать отчеты и разукрашивать каждую нечетную строку в них, выделяя жирным итог.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Я не требую от тебя формального доказательства. Только прошу логичной аргументации чем-нибудь кроме твоих впечатлений.
Для тебя логичной аргументацией является аргументация восхволяющая С++. А остальную ты всеми силами пыташся невилировать.
Даже очевидные недостактки С++ и его спецификации ты или не видишь, или оправдываешь, или пытаешся осмеять/невилировать (в том числе и поптыками опустить мнение оппонента).
В такой ситуации любые мои слова для тебя не будут являться аргументами.
Мне вот непонятно другое. Когда оберонщики используют С++ в качестве некого эталона багоглючности ты полчишь себе в тряпочку, когда я краем задеваю С++, ты докапывашся до первого попвшегося слова (мало относящегося к делу) и развивашь эту тему во вселенский флэйм. Что является причиной этому?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
VD>>>Реально фиксация типов данных была сделана исходя из разных соображений. Одно из них было — упрощение восприятия программ людьми.
V>>еще пара таких высказываний и я буду собирать подписи за открытие храма Билла-Безвоздмездного в Севастополе
VD>Начинай. Типы зафиксировали еще в Яве. Не думаю, что он приложел к этому руку.
Не думаю, что причина та, которую ты озвучил.
VD>Это всего лишь демагогия.
Во-первых, порезал аргументы. Во-вторых — некрасиво аргументы игнориировать.
V>>Во-первых, моно чуствует себя немного хуже даже на Win32 платформе. Во вторых, я некорректно выразился. Я имел ввиду Intel32.
VD>Гы. Как раз Вынь32 был еще хот чем-то. А Intel32 совсем мимо кассы. Есть куча КПК на которых крутится дотнет. Ява вообще 70% мобильников захватила. Там Интелом и не пахнет. Ну, а 32... что-же похоже это самое разумное количество бит для процессора предназначенного в частное пользование.
V>>Где там ориентация на 64 бита?
VD>Ну, хотя бы она в том, что реально в бехопасном режиме без указания расположения полей ни кто не мешает разработчикам фрэймворка плевать на указанные велечины и делать int 64-битным.
ну и? какой вывод? что даже в unsafe-режиме есть возможность написать непереносимую программу.
VD>Кстати, в Вынь64 int вроде как остается 32-битным, так что с указателями прийдется повозиться. Весь Вынь-ориентированный С++-ный код прийдется серьезно проверить, так как проблем в нем может оказаться не мало.
там, где используется API так, как описано в h-заголовках — никаких проблем. В VC++ 7.x есть опция — выдавать варниги несовместимости для 64-битных платформ. Так все уже давно компилят свои программы с этой опцией и проблем пока нет. (Проблемы могут быть там, где есть явные преобразования типов в духе С (SomeType*)&someVar. Но тут компилятор просто умывает руки, мол, пишешь в духе С — значит и задача твоя соответствующая).
VD>А вот код на Шарпе гарантированно будет работать. И при наличии хорошо оптимизированной VM будет работать очень шустро.
Мне с последним утверждением спорить?
V>> все коллекции имеют индекс типа int. Да и вообще, int — наиболее употребимый тип (он же System.Int32).
VD>Ни одна коллекция не сможет вместить в себя и 2 миллиарда объектов, так как их алгоритмы просто на это не рассчитаны. Массивы же имеют 64-битную индексацию (погляди класс Array там есть как 32-х, так и 64-битные методы). Можеш даже провести эксперемент. Создай вот такой код:
Какая разница, во что он компилит, если внешний интерфейс на Int32?
Если я захочу разреженный массив сделать с 64-битным индексом (раз платформа позволяет, а у меня сложное математическое моделирование на мэйн-фрейме), то не смогу воспользоваться стандартными интерфейсами: ICollection, IList.
VD>В общем, дотнет построен по принципу ты пишешь программу, а она работает на любой платформе.
Мне и с этим спорить?
Яву именно для этого двигали, т.е. для экстенсивного расширения сфер влияния фирм-инициаторов.
VD>Ты как бы пишешь нужную тебе программу, а CLR обеспечивает оптимальное исполнение на заданной платформе. Программа не становится другой на 64-битной платформе. Она просто получает возможность создать больше объектов (если больше памяти есть) и более эффективно работать с 64-битными числами. В общем, подход заточеный на максимальную переносимость того что есть, а не на масимальную но гипотетическую возможность оптимизации. Всю оптимизацию берет на себя фрэймворк.
Ты — идеальный потребитель с т.з. финансовой позиции Microsoft. Успехов!
AndrewVK,
> ПК>Весь — нет. Но часть, влияющую на семантику языковых конструкций — нужно.
> Упомянутые P/Invoke и формат сборки к ним не относятся.
Гут. Это был просто пример. Данных о количестве неоднозначностей и недосказанностей в стандартах C# и CLI, как уже говорилось, у меня нет. Если эта информация у кого-нибудь есть, мне бы она была интересной.
>>> и можно смело будет рассматривать стандарт плюсов как часть описания дотнета.
> ПК> Можно. Но это не будет соответствовать действительности: C++/CLI основывается на спецификации CLI, так же, как и C#. И точно так же, как стандарт C#, частью стандарта CLI не является.
> Компилятор С++ может порождать код для нетовского рантайма. Именно С++, а не С++/CLI или С++ with Managed Extensions.
А еще для X86, Solaris, Macintosh и прочих платформ, на базе которых можно построить абстрактную машину, описанную в стандарте C++. Иными словами стандарт C++, в отличие от стандарта C#, от .Net/CLI не зависит. И наоборот, стандарт CLI от стандарта C++ тоже не зависит.
Стандарт же C# ссылается на стандарт CLI в нормативной части:
The following normative documents contain provisions, which, through reference in this text, constitute
provisions of this International Standard. <...>
ECMA-335, 2nd Edition, December 2002, Common Language Infrastructure (CLI), Partition IV: Base
Class Library (BCL), Extended Numerics Library, and Extended Array Library (also published as ISO/IEC
23271:2002).
Соответственно, без стандарта CLI, нормативная часть стандарта C# будет неполной.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, vdimas, Вы писали:
V>Я бы ввел обязательную спецификацию исключений.
Вот в джаве такое сделали. В результате большинство современных фреймворков используют исключения, отнаследованные от RuntimeException, которые специфицировать не надо.
ПК>Большинство программистов, использующих C++ в своей работе, с которыми я общаюсь, никаких вопросов о назначении .Net не задают. Он им глубоко фиолетов, пока не приходится с ним иметь дело.
Скажу больше, С++ программисты обычно с любопытством относятся к этой платформе, пока не посидят конкретно. Не скажу про 2.0 (релиз еще не вышел), но недостаточность выразительных ср-в C# порой вызывает просто физические ломки (точно такие, как были при работе на VB). Одно радовало — хорошо хоть придумали делегаты и систему событий на их основе, ибо если бы сделали как в Java, то это было бы "последней каплей" на чаше весов в пользу отказа от языка (да именно, даже несмотря на мощнейшую платформу)
ПК>Этот список изменений, умещающихся в одном абзаце — большая часть изменений в языке от ARM и ранних черновиков стандарта (VC++6.0) до современного состояния языка. Это намного больше, чем осталось доделать для почти полного соответствия стандарту ("почти" означает без экспорта шаблонов). Фактически VC++7.1 осталось: двухфазный поиск имен, исправление ошибок, и еще одна фича сомнительной нужности — спецификация исключений; пожалуй, все...
Я бы ввел обязательную спецификацию исключений. Во-первых, это бы немного упростила реализацию механизма исключений компиляторами. Во-вторых, подняло бы надежность программ. (правда, за счет некоторого неудобства)
VladD2,
> ПК> Имхо, главным критерием качества проработки собственно стандарта является количество его разночтений разными разработчиками: чем этих разночтений меньше, тем стандарт проработаннее. Скажем, для того же C# мне пока сложно об этом судить, т.к. еще не видно сколько-нибудь значительного количества проектов, использующих разные его реализации.
> Не думаю, что нужна туча реализаций компилятора, чтобы можно было рассуждать о качестве проработки стандарта.
Не туча реализаций компилятора, а хотя бы две-три реализации и сколько-нибудь значительное количество проектов, которые могут работать то на одной, то на другой реализации.
> Достаточно внимательно его прочесть.
Если речь о самой возможности рассуждений, то для этого можно и не читать: рассуждать можно и о чем угодно. Если достаточно общего впечатления — да, достаточно просто внимательно прочесть. Другой вопрос, насколько верным будет это впечатление.
Если же речь о сколько-нибудь объективном сравнении нескольких разных стандартов, то для этого нужно составить более-менее соответствующее действительности представление о количестве разночтений и недосказанностей в этих стандартах.
Как показывает практика, внимательно прочесть стандарт для этого не достаточно. Недостаточно даже несколько раз внимательно прочесть. Даже очень внимательное прочтение очень многими людьми по нескольку раз не является достаточным. Даже в случае, когда эти люди являются экспертами языка и/или разработчиками соответствующих компиляторов. Пока дело не доходит до реализации и практического использования, многие недосказанности и противоречия просто не видны.
Я бы с удовольствием прочитал любое обоснованное сравнение степени проработки стандартов разных языков, но, имхо, подобная работа, результаты которой будут хоть сколько-нибудь точны, легко потянет на диссертацию, и вряд ли кому-нибудь настолько интересно этим заниматься.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>К сожелению, общая грамотность людей на форумах не очень высока. И подобные приемы частенько проходят, причем проходят на ура. Вот почитай на досуге http://blacklight.h1.ru/oppo09.htm там многие из этих примемов описаны.
Вряд ли ты полностью избежишь этих приемов. Если это кому-то удасться — никто не будет читать rsdn.ru форумы.
Как я могу отказать себе в таком начале предложения: "очевидно, ...".
Или как ты можешь отказаться от возможности додумать за оппонента и доказывать его неправоту. (ссылки не приведу, ворошить старое — грех, да и скучное это занятие)
Если от всего этого отказаться, то форум превратиться в голый обмен только лишь "подтвержденными" фактами. Тогда даже ссылок мало будет, ибо ссылка не обязательно является достоверным фактом, желательно будет несколько ссылок и т.д. и т.п.
Разумеется, подобный маразматический сценарий никто не рассматривает. Тут вопрос гораздо более приземленного житейского плана. Ты говоришь о грамотности, я бы лучше заговорил о культуре. В споре необходимо поддерживать паритет с собеседником, например, если ты просишь обосновать мнение оппонента, и он это делает, будет вполне "политкорректно" поступать аналогично. Простое признание — "нет аргументов", куда как культурнее, чем "они тут и нахрен не сдались (аргументы)".
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Я даю ссылки на языке, на котором проще по этим ссылкам найти информацию.
Гы. Ну, так учитывай, что читающие могут быть не сильны в этом языке и в предь старайся давать информацию на языке оппонента.
ПК> Можно и по-русски: ПК>http://warrax.croco.net/46_47/errors.html ПК>
Ошибка #043 тип Shifting the burden of proof.
ПК>Допущение истинности утвеpждения, пока не доказано обpатное. Пpимеp: "Бывают зеленые сантаклаусы, синие единоpоги, зелененькие человечки в таpелочках и пауки шиpиной в земной шаp. Докажите обpатное".
Прекрасно.
1. Где ты в моих словах усмотрел "Допущение истинности утверждения"? Я выразил свое мнение. Я не утверждаю, что не ошибаюсь. Ты просто потребовал его обоснования, а я сказал, что не хочу этого делать. Далее ты добавил, что оно безапелляционное. На что я ответил, что если тебе нужно, то ты можешь опровергать его сколько влезет (т.е. апеллировать).
2. Считаешь ли ты допустимым объявлять мнение неверным, только на основании того, что человек высказавший его не хочет (или даже не может) дать полного его обоснования?
ПК>Презумпция невиновности сюда вообще никаким боком. Мы говорим об установлении истинности тех или иных утверждений, а не о чьей-то вине.
Гы. Перекладывание бремени поиска доказательств на обвиняемого (или другими словами, принуждение к оправданию) как раз и является нарушением презумпции невиновности. Ты открой ссылочку то... и поищи слова "бремя отвественности".
Ставя под сомнение чужое мнение ты обвиняешь другого человека в том, что он говорит не правду и принуждаешь его оправдываться на ровном месте. Заставляя его оправдываться ты как раз нарушаешь этот принцип.
>> Итак. Я утверждаю, что требуют доказательства только не очевидные заявления сделанные в ходе логического вывода или доказательства. Все же остальные случаи являются выражением личного мения и подтверждения не требуют.
ПК>Да, естественно. Я и не требую от тебя доказательств.
Это откровенная неправда. Ты именно вынуждаешь оправдываться. Брошенная в след фраза "а ну-ка обоснуй это мнение" ни чем иным назвать нельзя.
ПК>Просто говорю о том, что неаргументированное мнение для читателя имеет пользу, стремящуюся к нулю.
Очередная ошибка. Мнение есть мнение. Оно не обязано иметь пользу. Оно даже может быть ошибочным. Так что тут даже такие рассуждения не применимы. Да и ценность мнения отнюдь не сводится к нулю тем, что за ним не следует огромного формального доказательства его истинности. Если мнение высказывается авторитетным в некотором вопросе человеком, то оно уже будет иметь для меня ценность. Например, твое мнение о соответствии той или иной конструкции стандарту C++ для меня несомненно имеет значение. В прочем, я всегда буду допускать, что ты можешь банально ошибиться и не буду возводить твое мнение в разряд 100%-но истинных утверждений на базе которых можно построить однозначно верный логический вывод.
Так вот ты очень часто докапывашся до общих мнений. Причем зачастую вопросы по которым эти мнения высказываются просто физически сложно доказать или дать полное их обоснование. И при этом ты именно что требуешь обоснованиий, так как не получив оных ты начинаешь утверждать, что ценность такое мнение иметь не можешь (чем в общем-то оскорбляешь носителя этого мнения).
ПК>Впредь буду заранее уточнять, собираешься ли ты аргументировать то или иное свое спорное утверждение, или это очередное ИМХО.
Паша. Я уже понял, что иностранные термины для тебя намного доходчивее, нежели обычные русские слова. Запомни на будущее, что русское слово "по-моему" == дебильному транслитерированному ИМХО.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>Можно узнать про эти платформы и эти типы? VD>Напомню, в Шарпе есть: byte (1 байта), short (2), int (4), long (8). Можно узнать о типах C/C++ которые не покрываются этими виличинами.
PDP-10: 36-битное слово и 72-битное двойное слово.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Шахтер, Вы писали:
Ш>>Тебе был приведен совершенно конкретный пример проца с 24 битовым байтом.
AVK>С 24-хбитовым словом, а не байтом.
С байтом. Если тебе так трудно это понять -- это твои личные проблемы.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, vdimas, Вы писали:
V>>Влад, ты же разбираешься в этом вопросе, а жонглируешь... V>>Ты забыл оценить мощность порождаемого грамматикой множества выражений.
AVK>Что такое мощность?
совокупность всех допустимых цепочек, порождаемых правилом/системой правил.
---------
в С++, например, невозможно определить семантику такого выражения:
xxx yyy(zzz);
т.е. в зависимости от контекста, это может быть или объявление сигнатуры ф-ии либо инициализация переменной yyy значением переменной zzz.
тут как-то на rsdn было обсуждение насчет класса грамматики — контекстно свободная или контекстно-зависимая. Пришли к тому, что КЗ.
КЗ стоят на вершине иерархии Холмского:
регулярные -> КС -> КЗ.
однако, КЗ грамматики обычно очень компактны в записи, именно из-за того, что одно и то же выражение может трактоваться по разному, в зависимости от контекста, т.е. можно ввести доп. промежуточные символы для краткости записи.
------
1. Все продукции грамматики типа 1, или грамматики контекстно-зависимой, контекстной, имеют вид [...]
2. Грамматика типа 2, или контекстно-свободная грамматика, — это грамматика [...]
3. Все продукции грамматики типа 3, регулярной грамматики [...]
С ростом номера уменьшается общность грамматики. Это значит, что при всех i (i=0,1,2) имеются языки, описываемые грамматикой типа i, но не типа i+1. Язык принадлежит типу самой простой из описывающих его грамматик.
Контекстно-зависимые грамматики и грамматики с фразовой структурой в иерархии Хомского [...]. Хотя языки, определяемые грамматиками этих типов, являются более мощными, в то же время они сложнее для понимания, анализа и практического использования.
Языки программирования: разработка и реализация. Т. Пратт, М. Зелковиц
В моделирование синтаксиса естественных языков для задач автоматического синтаксического анализа наиболее распространёнными являются формальные системы, относящиеся к одному из следующих классов:
· Регулярные грамматики – используются только для упрощенного анализа (shallow parsing), в общем случае не могут быть задействованы в качестве базового формализма системы полноценного синтаксического парсинга.
· Контекстно-свободные грамматики – используются достаточно широко, однако в чистом виде также непригодны для полноценного анализа, так как их мощности недостаточно для работы с синтаксическими явлениями, характеризующимися наличием нелокальных связей [...]
· Мягко контекстно-зависимые грамматики – будучи несколько более мощными, чем КС-грамматики, грамматики данного класса позволяют анализировать большинство типов синтаксически релевантных нелокальных связей.
здесь
Разработка системы автоматического синтаксического анализа на основе мягко контекстно-зависимой унификационной грамматики
Александр Перекрестенко
Институт проблем информатики РАН
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> Стандат Шарпа проработан куда лучше, но размер он имеет даже меньший.
ПК>А каков твой критерий качества проработки стандарта?
Ходил сейчас на сайт ANSI, прикупить новую версию стандарта. Так вот, С++ стандарт -- в числе бестселлеров.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Какова цель спецификации языка?
ПК>Как и у любой спецификации: точно (насколько возможно полно и непротиворечиво) описать предмет спецификации, т.е. язык.
Можно назвать успешным описание С++ если МС, Борланд и пр. не могут реализовать этот стандарт?
ПК>Подчеркиваю, что неопределенное поведение не обязательно должно быть явно указано: нарушение любых требований, указанных в спецификации, если не оговорено обратное, приводит к неопределенному поведению.
Это пожалуй единственное разумное оправдание появлению неопределенного проведения. Во всех остальных местах оно является недостатком спецификации (или языка если тебе так больше нравится). Понятно, что в реальной жизни невозможно обойтись без проблем, но все же их должно быть минимум.
>> И может ли быть у "плохого" языка хорошая спецификация?
ПК>Конечно.
Тогда дальше разговаривать не о чем.
ПК> Для любого языка существует гамма точности возможных его описаний. По-моему, обоснование данного момента достаточно очевидно: в любую спецификацию достаточно легко внести неточность, и наоборот, при обнаружении неточности ее можно устранить теми или иными усилиями. ПК> Впрочем, все это верно для любой спецификации, не только спецификации языка.
Нет уж. Если спецификация порождает некачественный продукт, то это убогость этой специяикации.
В общем, как всегда ты подходишь к делу насктлько формально насколко это возможно, а именно до потери смысла обсуждаемого вопроса.
>> Т.е. несовместимость между Борлад С++ и VC++ — это проблемы языка, а не его стандарта?
ПК>Если речь идет о разной трактовке некоторых языковых конструкций, то в подавляющем большинстве случаев это проблемы реализаций, нарушающих стандарт.
Так почему же реализации Явы и Шарпа трактуют конструкции одинаково, а С++-а по разному. Может быть все же в этом виновата именно спецификация? Может быть она излишне запутана, противоричива или еще что-то? А раз так, то что же это как не убогость спецификации? Понятно, что она может быть написана без ошибок, и в ней может быть учтено все что только можно. Только при этом она будет противоричива, запутана или приводить к диким временным затратам на семантический анализ. Все это брак.
ПК> Если речь идет о бинарной совместимости порождаемых объектных файлов, то это не является проблемой ни языка, ни стандарта — это вещи, которые отданы на откуп реализациям, точно так же, как, скажем, способ, каким пользователь указывает компилятору каталоги для поиска заголовочных файлов и т.п.
Самому то не смешно? В спецификации не оговорены важнейшие аспекты построения компиляторов и рантайм-систем. Это приводит к физической несовместимости компиляторов. Это не доработки. Это уже дырища.
>> Ну, и еще один вопрос. Судя по твоим переключением стрелок на язык ты считашь, что С++ плохо спроектированный язык с хорошей спецификацией. Так?
ПК>Не так.
Как же не так? Тут у тебя явные не соотвестия. По твоим словам, у стандарта проблем нет. У языка теже. А результат мягко говоря кривоватый. Когда мы говорили о проблемах спецификации ты кивл на язык и говоришь, что мол проблемы его. А теперь и от этого отказываешся.
ПК> Под качеством проектирования языка я подразумеваю соответствие результата сформулированным требованиям к языку
То есть качество получившегося языка тут как бы и не причем?
Другими словами язык качественный если его автор (пусть даже 20 лет назад) ставил перед собой половинчатые цели. Так?
Цели создания С++ ставились 20 лет назад. На сегодня у пользователей (программистов) требуования уже сильно отличаются. Как-то странно сравнивать языки не на прямую, а по принципу соотвествия их догмам их создателей.
ПК> плюс, в рамках этих требований — соблюдение "общих" принципов проектирования языка.
То есть все что угодно, но не качество результата?
>> И очень интересно каковы твои критерии определения сложности языка?
ПК>Количество разных понятий, которыми язык оперирует.
Ну, по количеству понятий Шарп даже первой версии значительно превосходит плюсы. Причем даже версии 1.0. А уж 2.0...
Стало быть по твоим же словам сравнивать размеры спецификаций блее чем можно.
Хотя конечно установление зависимости между сложностью языка и возможностью сравнения спецификаций, мяго говоря, необоснованно.
>> Если на базе этого описания у десятка серьезных и очень богатых контор не удается создать компиляторы которые одинаково интерпреритруют исходный код, то я назывю такой стандарт не качественным.
ПК>Это уже намного ближе.
К чему? Что у спецификации есть какие-то иные цели кроме описания языка?
ПК> Теперь осталось поправить "не удается" на "до сих пор не сделали"
Это дно и тоже. На сегодня нет. Значит не удается. Не нужно пытаться жанглировать терминологией.
ПК> и проанализировать, почему это так: из-за качества стандарта, либо же из-за других причин. К последним в данном случае можно отнести существование множества реализаций еще до создания стандарта,
Да? Во оно как? Попробуй обосновать это утверждение.
ПК> плюс множество проблем, связанных с обратной совместимостью с кодом, написанным под реализации, не соответствующие стандарту.
И это тоже.
Я лично не вижу никакой зависимости между совместимостью и соотвествием стандартов. Тот же МС ввел пару тройку ключей компилятора и проблемы совместимости решились. Но VC как не был совместим со стандартом, так и не совместим.
Возьмем например экспорт шаблонов. Чистейшей воды профанация, так как как их не экспортируй, а проблемы шаблонов и препроцесор не позволяют создать приемлемой промежцточной формы для подобного экспорта. А учитывая, что большинство контор пошло по пути создания прекомпилируемых заголовочных файлов, то и смысла в этих фичах не видно.
Теперь сравни это решение с теми же дженириками в дотнете и попробуй после этого утвержадать, что решения выбранные в С++ были глубоко продуманными, а спецификация непротиворичивой.
Ясно как божий день, что сложность реализации на практике проистикает из-за проблем спецификации. Просто проблемы бывают разного рода. Ты почему-то недоговоренности в виде неопределенного поведения или черезмерную сложность за таковые считать не хочешь. А это проблемы. И очнь серьезные.
Лично я не могу отделить качество языка от качества его спецификации. Качественная спецификация порождает качественный продукт. Видимо в понимании зависимостей мы и не сходимся. Ну, да это не единственное место геде мы по разному смотрим на жизнь.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>В самом деле, если размер машинного слова не ложится на размеры целых типов CLI, то очевидно, что работа с целыми в C# не будет прямой работой с платформой.
> Можно узнать про эти платформы и эти типы? > Напомню, в Шарпе есть: byte (1 байта), short (2), int (4), long (8).
Важно уточнить, что при этом размер байта в C# фиксирован, и равен 8 битам. В C/C++ такого ограничения нет.
> Можно узнать о типах C/C++ которые не покрываются этими виличинами.
Сюда не впишутся платформы, имеющие машинное слово, не являющееся степенью двойки, например 36 или 30 бит. Где-то до конца восьмидесятых подобные компьютеры еще были в производстве. А использование на них C актуально и до сих пор.
> ПК> Я не утверждаю, что это плохо. Просто это демонстрирует разницу в целях, которые ставили перед собой разработчики C# и C++.
> А я утверждаю, что введение зависимости между машинным словом и размером int-а была сделана в целях оптимизации, что никак не относится к переносимости
Фактически, С "родился" среди компьютеров с разным размером машинного слова и разным размером байта; поэтому не удивительно, что в книгах "отцов-основателей" вполне можно встретить упоминание этих моментов:
C has four fundamental types of variables:
int integer (PDP-11: 16 bits; H6070: 36 bits; IBM360: 32 bits)
char one byte character (PDP-11, IBM360: 8 bits; H6070: 9 bits)
float single-precision floating point
double double-precision floating point
Для ревизии C эти моменты были актуальны и в 1999:
Other architectures have different word sizes, such as 36 and 60 bit; for these implementations, types using multiples of word sizes, such as 72-bit and 60-bit integers, are appropriate.
Также это видно и по дизайну "фиксированных целых" — новый стандарт C99 не требует от платформы их наличия.
И дело тут вовсе не в оптимизации, а в самом предназначении языка для системного программирования, каковое вряд ли можно представить без наличия типа, непосредственно соответствущего машинному слову, равно как и типа, представляющего минимально адресуемую единицу памяти.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не, дело не в этом. Дело в том, что публично высказанное ошибочное мнение, оставленное без соответствующих contra может принести кому-то вполне реальный вред. Мне например. И кстати, это одна из причин, по которой я, например, тусуюсь на этом форуме.
Да, да!!! Я тоже здесь тусуюсь в ожидании получения вполне реального вреда!
Пока получается с точностью до наоборот... не везет, короче...
AndrewVK,
> ПК> Напомню, что, как верно заметил Шахтер в другом сообщении, это стандарту не соответствует. В соответствующем стандарту компиляторе был бы как раз 24/16-битовый char, т.е. соответствующий платформенному байту.
> Паша, ты правда не понимаешь отличия между байтом и словом?
Я-то вполне понимаю. Но подозреваю, что у нас с тобой терминология немного отличается. Я приведу определение "моего" байта, а ты, если хочешь, можешь привести определение "твоего".
Байт (в терминах стандартов C и C++) — минимально адресуемая единица памяти. Кроме того, у байта (в терминах стандартов C и C++) все биты значащие. Байт (в терминах стандартов C и C++) может быть любого размера, не только 8 бит.
Чтобы не путать понятие восьмибитного типа данных с байтом, 8 бит иногда называют октетом.
Т.к. данный процессор не позволяет непосредственно адресовать октет, то байт (в терминах стандартов C и C++) на этой архитектуре октетом быть не может.
И т.к. данный процессор позволяет адресовать объекты, начиная с машинных слов, плюс, минимальный тип со всеми значащими битами — то же машинное слово, то в данной архитектуре байт (в терминах стандартов C и C++) совпадает с машинным словом.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК> Проведи небольшой поиск по словам "shifting the burden of proof", и найдешь сколько угодно подтверждений данным моим словам.
> Забавная привычка приводить ссылки на языке на котором не думаешь.
Ошибка #043 тип Shifting the burden of proof.
Допущение истинности утвеpждения, пока не доказано обpатное. Пpимеp: "Бывают зеленые сантаклаусы, синие единоpоги, зелененькие человечки в таpелочках и пауки шиpиной в земной шаp. Докажите обpатное".
> Вот тебе ссылочка на статью 49 Конституции РФ в которой как раз говорится о недопустимости переложения бремяни доказывания на обвиняемого. Как раз о той самой презумпции невиновности.
Презумпция невиновности сюда вообще никаким боком. Мы говорим об установлении истинности тех или иных утверждений, а не о чьей-то вине.
> Итак. Я утверждаю, что требуют доказательства только не очевидные заявления сделанные в ходе логического вывода или доказательства. Все же остальные случаи являются выражением личного мения и подтверждения не требуют.
Да, естественно. Я и не требую от тебя доказательств. Просто говорю о том, что неаргументированное мнение для читателя имеет пользу, стремящуюся к нулю. Впредь буду заранее уточнять, собираешься ли ты аргументировать то или иное свое спорное утверждение, или это очередное ИМХО. Или, если тебе это больше нравится, могу все твои утверждения по умолчанию считать исключительно твоим ИМХО, которое ты аргументировать не собираешься — как тебе угодно.
> В противном случае ты ставишь собеседника в очень неудобное положение.
Собеседник, делающий утверждения, которые внятно аргументировать отказывается, ставит в неудобное положение себя сам.
> В народе это называется заставлять доказывать, что ты не верблюд.
"Доказывать, что ты не верблюд" — это как раз о противоположном. Это когда кто-то делает по меньшей мере спорное утверждение, и предлагает оппонентам доказать его ложность, вместо того, чтобы самому доказывать, что оно верно.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК>Не туча реализаций компилятора, а хотя бы две-три реализации и сколько-нибудь значительное количество проектов, которые могут работать то на одной, то на другой реализации.
> Этого тоже не нужно. Это банальная отмазка. К тому же две реализации есть и проекты работающие на них тоже есть.
Вот и нужно собрать данные о проблемах переносимости реальных проектов между этими двумя реализациями для возможности каких-то суждений. Я таких данных не видел. Может, приведешь ссылку?
> Спецификация языка нужна не только для переноса компиляторов на другие платформы (для дотнета это вообще не актуально) или создания конкурирующий компиляторов, в первую очередь она нужна для того чтобы разбираться в языке.
Стандарт — закон. Для закона прежде всего важна точность, а не легкость понимания. Так что с этим положением я не согласен.
> ПК> Если достаточно общего впечатления — да, достаточно просто внимательно прочесть. Другой вопрос, насколько верным будет это впечатление.
> Паш. Глупо пытаться поставить под сомнение очевидные вещи. Ты бы лучше открыл да почитал.
Открывал и читал. Даже внимательно. Даже не один раз. И что? Очевидной степень проработки данного стандарта от прочтения для меня не стала.
> ПК> Если же речь о сколько-нибудь объективном сравнении нескольких разных стандартов, то для этого нужно составить более-менее соответствующее действительности представление о количестве разночтений и недосказанностей в этих стандартах.
> Ну, сколько оных в С++ ты вкурсе. А вот в Шарповом я подобных вещей встречал очень мало.
Да, именно об этом я и говорю: по C++ данные есть, а по C# я таковых не видел. Соответственно, без этих данных о качестве проработки стандарта C# судить сложно; если вообще можно. Отсутствие данных по дефектам стандарта не означает отсутствие дефектов. Большинство программистов с дефектами стандарта C++ тоже не сталкиваются, так что это не аргумент их отсутствия. Где можно посмотреть список дефектов стандартов C# и CLI (*), чтобы можно было судить об их количестве и затрагиваемых аспектах?
> ПК> Пока дело не доходит до реализации и практического использования, многие недосказанности и противоречия просто не видны.
> Пашь, поверь я как раз занимаюсь "реализацией и практическим использованием". Причем очень плотно.
Компилятора C#, позволяющего порождать исполняемые программы? Синтаксические преобразования не в счет, т.к. подавляющее большинство дефектов стандартов сказываются на неоднозначности трактовки семантики программы, а не трактовки синтаксиса.
> ПК> но, имхо, подобная работа, результаты которой будут хоть сколько-нибудь точны, легко потянет на диссертацию, и вряд ли кому-нибудь настолько интересно этим заниматься.
> И тем не менее это не отнимает у меня права высказывать свое мнение по этому поводу.
Естественно, но отсутствие аргументации или, хотя бы, объяснений, что именно ты имеешь в виду, сильно снижает ценность твоих подобных высказываний для читателей.
(*) Т.к. в стандарт C++ входит и описание абстрактной машины, каковая для C# представлена CLI.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК> Естественно, но отсутствие аргументации или, хотя бы, объяснений, что именно ты имеешь в виду, сильно снижает ценность твоих подобных высказываний для читателей.
> Я и не брался за составление серьезного и аргументированного сравнения. Темблее что для меня сравнение стандартов в отрыве от языков совершенно бесмысленно. Ты кажется сам оценил эту работу как дисертацию. Надеюсь, в этот раз ты не потребуешь написать дисиртацию, чтобы подтвердить мое права на наличие собственного мнения.
Дык, я полагал, что ты обладаешь сколько-нибудь достоверной информацией, делая такие безаппеляционные заявления
VladD2,
> ПК> Т.к. стандарт C# в качестве понятия, эквивалентного абстрактной машине, описанной в стандарте C++, использует CLI, то для сравнении стандарта C++ и C# к последнему следует добавлять стандарт CLI. Иначе будет производиться сравнение части с целым, что, очевидно, некорректно.
> Не нужно притягивать за уши, что попало. Есть спецификация C# и есть куча спецификаций под общим названием стандарт дотнета. Для сравнения языков совершенно не нужно притягивать весь дотнет.
Весь — нет. Но часть, влияющую на семантику языковых конструкций — нужно. Можно и наоборот сделать: исключить из рассмотрения части стандарта C++, выходящие за рамки стандарта C#...
> Тот же С++ реализуется для дотнета,
Не тот же, а другой.
> и можно смело будет рассматривать стандарт плюсов как часть описания дотнета.
Можно. Но это не будет соответствовать действительности: C++/CLI основывается на спецификации CLI, так же, как и C#. И точно так же, как стандарт C#, частью стандарта CLI не является.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов и VladD2!
>> Апеллируй скоько тебе влезет, если хочется. Для меня сказанное мной очевидно. Но заниматься глупыми доказательствами просто не считаю нужным. Жизнь и так все расставляет на свои места.
ПК>Именно об этом я и говорил: безаргументированное ИМХО ("имею мнение, хрен оспоришь"). Как было верно замечено ранее, "цена — копейка в базарный день". Т.е. для читателя, желающего узнать (*) что-то новое, никакой ценности подобные сообщения не несут.
Дискуссия начинает съезжать в сторону базара.
У меня 2 предложения:
1) отказаться от неконструктивных выпадов в пользу диалога (помните Сократовское "в споре рождается истина"?)
2) отделить ветку, примерно вот с этого места: http://www.rsdn.ru/Forum/?mid=897371
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Именно об этом я и говорил: безаргументированное ИМХО ("имею мнение, хрен оспоришь"). Как было верно замечено ранее, "цена — копейка в базарный день". Т.е. для читателя, желающего узнать (*) что-то новое, никакой ценности подобные сообщения не несут.
На счет ценности, тут ты не прав. Цена моего мнения — мой опыт. Субъективное мнение, под час, тоже достойное основание. Особенно когда вопрос сложно доказать или подтвердить на практике.
Что касается "узнать", то я и не претендую на научные труды. Вернее может и притендую, но не во всех жизненных областях.
Надо тебе доказать правильность или ошибочность моих суждений, можешь это делать. Вот только не нужно рассуждать об безапелляционности и т.п. До тех пор пока ты не доказал обратного твои возражения такое же мнение ни чем не лучшее других. А так как области в которых ты требуешь доказательств вообще являются скорее философскми, то говорить можно с большой вероятностью предугадать чем кончится такое доказательство. Оно кончится флэймом или рабитым лбом.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Кодт, Вы писали:
К>Дискуссия начинает съезжать в сторону базара. К>У меня 2 предложения: К>1) отказаться от неконструктивных выпадов в пользу диалога (помните Сократовское "в споре рождается истина"?)
— озаглавив её, скажем, "Критерии качества стандарта языка" К>Я бомбу повесил, дело за вами.
Когда Паша начинает с вопросов — это верный признак того, что предпологается пообвинять оппонента и затяеять обще филосовскую дискуссию, так что если не считать их полезными (ну, хотя бы побочными эффектами), то их можно смело сразу сносить в помойку.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Кодт,
>> 1) отказаться от неконструктивных выпадов в пользу диалога (помните Сократовское "в споре рождается истина"?)
ПК>Дык, к сожалению, от конструктива Влад уже отказался, сказав, что аргументировать свое сообщение он не станет. Буду только рад, если от простого высказывания мнений он вернется к их обоснованию.
Тут можно воспользоваться твоим приечиками и спросить, а что ты понимаешь под конструктивом... далее довести до состояния сфероконика и обвинить тебя в чем попало. Но что-то мне это не нравится.
Я еще раз повторюсь, что не стоит пытаться выставить мнение других людей как некчемное или незаслуживающее внимания. Если ты хочешь что-то доказать или опровергнуть, то делай это, а не разводи демагогию. Большинство из выскзываний на форуме ничего не стоят с точки зрения сферического коня в вакуме, но они ценны тем что высказываются на базе жизненного опыта высказывающего их субъекта. Они могут быть верным или не верными. Их может быть легко или трудно доказать. Но главное, что от того, что кто-то не хочет доказывать очевидные или очень сложные веши они не становятся неверными. Они так и остаются суждениями.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Дык, к сожалению, от конструктива Влад уже отказался, сказав, что аргументировать свое сообщение он не станет. Буду только рад, если от простого высказывания мнений он вернется к их обоснованию.
> Тут можно воспользоваться твоим приечиками и спросить, а что ты понимаешь под конструктивом...
Под конструктивом в данном случае я понимаю совместные действия оппонентов, направленные на выяснение правильности той или иной точки зрения путем верификации логической цепочки, приводящей к заявленному выводу.
> далее довести до состояния сфероконика и обвинить тебя в чем попало.
Это еще зачем? Это не ведет к установлению правильности или неправильности заявленной позиции, так что к "моим приемчикам" это не относится.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>Снова shifting the burden of proof. Для того, чтобы в дискуссии не учитывались некоторые суждения, доказывать их ошибочность не нужно. Достаточно просто отсутствие доказательства их верности.
VD>Ну, вот так как вот эти твои слова, да и 99% все остальных сказанных на этом форуме не имеют подтверждений, то на основании твоих же слов признаем их голословными, огульными и не будем учитывать их в дискуссиях. ОК?
примерно так,
в общем случае rsdn-дискуссии дают информацию о том, че на свете бывает и чем люди заняты.
если что-то заинтересует на более предметном уровне, то наличие подтверждений высказываний может сильно сэкономить время читателя.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Тут можно воспользоваться твоим приечиками и спросить, а что ты понимаешь под конструктивом...
ПК>Под конструктивом в данном случае я понимаю совместные действия оппонентов, направленные на выяснение правильности той или иной точки зрения путем верификации логической цепочки, приводящей к заявленному выводу.
Ужас какой. Я то думал, что конструктив — это всего лишь плодотворный, т.е. наличие осязаемого результата.
Ну, раз это не так, то продолжим детерминировать понятия. Итак, что ты понимашь под "совместные действия оппонентов", как действия могут быть направлены на выяснения точки зрения (бить что-ли кого-то будем?), как ты себе видишь верификацию данного тобой выше определения, и почему оно не соотвествет общепринятым определениям?
>> далее довести до состояния сфероконика и обвинить тебя в чем попало.
ПК>Это еще зачем?
Хороший вопрос. Переадресую его тебе.
ПК> Это не ведет к установлению правильности или неправильности заявленной позиции, так что к "моим приемчикам" это не относится.
Именно что относится. Ты, порою, очень умело превращаешь обсуждение совершенно конкретных проблем или вещей в крайне оторванные от жизни общефилосовкие рассуждения уходящие долеко от первоначальной темы. Вот мне и интересно... зачем?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>"Языковая" часть C# описывается в приведенном тобой документе (учитывая только нормативные части) начиная со страницы 1 по страницу 11 и со страницы 63 по страницу 433, что составляет 370 страниц.
> ПК>"Языковая" часть C++ описывается в соответствущем стандарте начиная со страницы 1 и заканчивая страницей 317, что составляет 316 страниц. Остаток стандарта C++ — описание стандартной библиотеки, которая из стандарта C# вынесена в отдельный документ.
> А что, по-твоему, находится на страницах 469-527?
В черновике следующей версии стандарта C#? Перечисление классов (и их содержимого) стандартной библиотеки + описание Documentation comments. В "релизной" предыдущей версии стандарта обе части помечены как информативные, в черновике только вторая. Соответствующая описанию стандартной библиотеки C++ нормативная часть с определением семантики стандартной библиотеки из стандарта C# вынесена в отдельный документ:
These types and their members are listed here, in alphabetical order. For a formal definition of these types and their members, refer to ISO/IEC 23271:2002 Common Language Infrastructure (CLI), Partition IV; Base Class Library (BCL), Extended Numerics Library, and Extended Array Library, which are included by reference in this International Standard.
> Где же тот непреклонный борец за формализацию все и вся?
Не знаю. Если кому-то охота заняться развешиванием ярлыков — это не ко мне.
> По факту в стандарте С++ более 700 страниц, в Шарповском ~530. И описание библиотек в них есть.
Нет в стандарте C# спецификации библиотек. Только перечисление классов и их членов.
> Ну, а если подходить неформально, то неплохо бы заметить, что в стандарте C#-а описание сдублировано. Сначала идет краткое обзорное описание, а потом тоже самое раскрывается более тщательно.
Краткое обзорное описание является информативной частью и без потери для полноты спецификации языка может быть из стандарта выброшено, т.к. требования могут содержаться только в нормативных частях. Соответственно, информативные части я в подсчете количества страниц спецификации не учитывал.
> Итак, делаем поиск словосочетаний "undefined behavior" и "behavior is undefined"... и получаем: <> Вот это я называю качеством стандарта, продуманностью, логичностью и т.п.
Что ты называешь качеством стандарта, я уже давно понял, и давно ответил, что мне совершенно все равно, сколько упоминаний неопределенного поведения ты найдешь в стандартах, т.к. к качеству стандарта (в смысле соответствия его своей цели) это не относится. Изменив неопределенное поведение на что-то другое ты получишь просто другой язык. Полнота и точность спецификации от этого не изменятся.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК> Только то, что объем спецификации языка C# не меньше, чем объем спецификации языка C++.
> А каковы твои критерии сложности языка?
На точно такой же вопрос я тебе уже отвечал.
> ПК>О сложности я ничего не говорил.
> Ну, то есть про сложность ты вообще ничего сказать не можешь, а возражаешь против чужого мнения, просто ради борьбы за справедливость и торжество сферокоников?
Нет, просто если я не располагаю точной информацией, то и заявлений по этому поводу, соответственно, не делаю. Еще раз: увидев твое утверждение о большей проработанности стандарта C#, я подумал, что ты не просто так это говоришь, а обладаешь какой-то более-менее точной информацией. Нет — ну и ладно. Неинформированные мнения мне мало интересны.
> Или давай уж определимся с критериями и выясним этот вопрос уровне цифр (типа объективно). Или ты признаешь, что в данном вопросе может существовать только субъективное мнение, и то, что мое субъективное мнение никак не может быть ущербным. А так же признаешь, что все твои возражения и попытки нивелировать мое мнение всего лишь некорректные приемы дискуссии, основанные на том, что мое частное мнение не совпадает с твоим точно таким же частным.
У меня нет по этому поводу мнения, т.к. недостаточно информации для его составления. О чем я сразу, собственно, и сказал
Имхо, главным критерием качества проработки собственно стандарта является количество его разночтений разными разработчиками: чем этих разночтений меньше, тем стандарт проработаннее. Скажем, для того же C# мне пока сложно об этом судить, т.к. еще не видно сколько-нибудь значительного количества проектов, использующих разные его реализации.
Поэтому странно говорить о несовпадении твоего мнения с моим (отсутствующим). Еще интереснее твои обвинения меня в некорректности ведения дискуссии. Для утверждения о последнем нужно, по крайней мере, привести ссылки на конкретные сообщения с указанием конкретных приемов. Впрочем, можешь не трудиться, мне это уже мало интересно.
Разве что какие-то сколько-нибудь объективные данные о количестве и характере дефектов в стандарте C# найдешь... Вот это было бы намного интереснее.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> Ну, те кто не видел "описания" STL мож даже подумать, что между "Перечислением" библиотек Шарпа и "описанием" STL есть огромная разница.
Конечно, есть. Для STL есть полное описание семантики всех функций. Плюс, там, где нужно, указание временной сложности алгоритмов. Из перечисления функций об этом можно только догадываться, что на спецификацию никак не тянет.
> Плюс что-то я не помню в плюсовом стандарте описания CRT. Оно тоже видимо вынесено в отдельный документ (спецификацию С).
Да, конечно. Извини, но странно, что, ты берешься сравнивать стандарты, этого не зная.
> Дык описание STL не долеко от него ушло. Учитывая полному имен, коментарии и общую логичность библиотек для использования этого достаточно.
Ты что, серьезно? Никакие имена и "общая логичность" библиотек не заменят полноценную спецификацию. О комментариях я бы в данном случае вообще не упоминал бы, т.к. в них только namespace. В общем, проще ограничиться примером:
// Namespace: System.Threading, Library: BCLpublic sealed class Monitor
{
public static void Enter(object obj);
public static void Exit(object obj);
public static void Pulse(object obj);
public static void PulseAll(object obj);
public static bool TryEnter(object obj);
public static bool TryEnter(object obj, int millisecondsTimeout);
public static bool TryEnter(object obj, TimeSpan timeout);
public static bool Wait(object obj, int millisecondsTimeout);
public static bool Wait(object obj, TimeSpan timeout);
public static bool Wait(object obj);
}
Ты утверждаешь, что семантика данного класса достаточна для реализации независимыми разработчиками без дополнительной спецификации?
> А сравнивать качество описания библиотек в "дополнительном стандарте" и то, что входит в стандарт плюсов просто нельзя. Это все равно что книга против ее реферата.
Мне война мнений и упражнения в риторике не интересны, так что развивать эту тему я не буду. Разве что ты захочешь свое это мнение аргументировать, используя общепринятые правила логики... Но почему-то после предыдущей дискуссии я в этом сомневаюсь.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
P.S.
>> ПК> Если речь идет о бинарной совместимости порождаемых объектных файлов, то это не является проблемой ни языка, ни стандарта — это вещи, которые отданы на откуп реализациям, точно так же, как, скажем, способ, каким пользователь указывает компилятору каталоги для поиска заголовочных файлов и т.п.
>> Самому то не смешно? В спецификации не оговорены важнейшие аспекты построения компиляторов и рантайм-систем.
> Нет, не смешно. Эти моменты опускают почти (?) все известные мне стандарты языков, работающих непосредственно с аппаратной платформой. Может, тебе известен хотя бы один стандарт кросс-платформенного языка (работающего непосредственно с платформой, без прокладки типа JVM или .Net), который специфицирует эти подробности?
Посмотрел в стандарт C# по этому поводу. Насколько я понял, он формат сборки тоже оставляет за кадром. Так что в этом отношении и в спецификации этого языка "не оговорен важнейший аспект построения компиляторов и рантайм-систем"
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК>Конечно, есть. Для STL есть полное описание семантики всех функций. Плюс, там, где нужно, указание временной сложности алгоритмов. Из перечисления функций об этом можно только догадываться, что на спецификацию никак не тянет.
> Да нет там почти описания.
"Не нашел" еще не значит "нет" Все классы, типы и функции STL имеют описание.
> Жаль копировать от туда не удается. А то я бы тебе привел бы простыню дклараций без единого коментария.
Смотри на следующие или предыдущие страницы. Если назовешь номер главы и/или укажешь, простыню объявлений чего ты увидел, я скажу, где искать к этому спецификацию.
>>> Плюс что-то я не помню в плюсовом стандарте описания CRT. Оно тоже видимо вынесено в отдельный документ (спецификацию С).
> ПК> Да, конечно. Извини, но странно, что, ты берешься сравнивать стандарты, этого не зная.
> Ты стрелки то не переводи. Я к тому, что с тем же успехом можно притянуть сюда объем спецификации С.
Можно. Если ты захочешь сравнить размер спецификаций полностью, включая описание библиотек — естественно.
> ПК> Ты что, серьезно? Никакие имена и "общая логичность" библиотек не заменят полноценную спецификацию.
> То полноценную. А в плюсовом стандарте описание крайне скудное.
Достаточное для точной реализации. В противном случае приводи конкретные примеры недостаточно точных описаний.
> ПК> О комментариях я бы в данном случае вообще не упоминал бы, т.к. в них только namespace. В общем, проще ограничиться примером: > ПК>
> ПК>Ты утверждаешь, что семантика данного класса достаточна для реализации независимыми разработчиками без дополнительной спецификации?
> А ты утверждаешь, что не понимашь что делают методы?
Я утверждаю, что здесь не указано множество необходимых для реализации моментов: что в точности делают эти функции, бросают ли они исключения, если да, то какие и при каких условиях, каковы их пред- и постусловия.
> Или утверждаешь, что из описания СТЛ можно все достконально понять?
По меньшей мере перечисленные выше моменты — да.
>>> А сравнивать качество описания библиотек в "дополнительном стандарте" и то, что входит в стандарт плюсов просто нельзя. Это все равно что книга против ее реферата.
> ПК> Мне война мнений и упражнения в риторике не интересны,
> Какие мнения? Описание СТЛ-я — это страницы голых листингов изредка разбавленные объяснениями.
Все необходимые для реализации объяснения для каждого класса, типа и функции, представлены. Объем для спецификации достоинством не является. Главное — однозначность и непротиворечивость трактовок.
> Вот и сравни это с описанием BCL.
Пока что я не убежден в безусловных преимуществах последней. Скажем, модель тех же контейнеров у меня, мягко говоря, восторга не вызвала. Я не собираюсь критиковать BCL, просто отмечаю, что мое сравнение, сделанное по твоему предложению, твоих выводов не подтвердило.
> ПК> Разве что ты захочешь свое это мнение аргументировать, <...> используя общепринятые правила логики... Но почему-то после предыдущей дискуссии я в этом сомневаюсь.
> Изумительно! И это говорит человек трубовавший обоснования безобидным высказываниям. Изумительно! А теперь потрудись доказать, все свои обвинения. Или взять свои слова обратно.
Я не требую от тебя формального доказательства. Только прошу логичной аргументации чем-нибудь кроме твоих впечатлений.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, 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 и полюбоваться на то как народу приходится извращаться. Да еще одна песня шарповской грамматики — глобальные атрибуты. Долго расписывать, но это тоже не контекстно-свободная грамматика.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>С 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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Реально фиксация типов данных была сделана исходя из разных соображений. Одно из них было — упрощение восприятия программ людьми.
еще пара таких высказываний и я буду собирать подписи за открытие храма Билла-Безвоздмездного в Севастополе
V>>Продолжая в твоем же духе — производители компьютеров гонят по-черному, выпуская аппаратуру с разной разрядностью, и, какая нелепость, с разной системой команд. Этот досадный факт делает применение С++ на этих платформах необоснованным решением. Ты уж тогда оставь С++ в покое, собери производителей железок и заставь их делать все по одной некой образцовой архитектуре. Правда, (ой блин) надобность в дотнете сама собой отпадет.
VD>Это демагогия. И не надо говорить, что она аналогична моим словам.
Это прямое следсвие твоих рассуждений. С++ ориентирован на непосредственную поддержку произвольных архитектур в системе их "родных" типов, и ты умудряешься называть это недостатком. В свете твоих рассуждений я вижу только один путь избавить его от этого досадного недостатка, уже озвучил какой. (так что, нет демагогии)
V>>типы CLI зафиксированы так, чтобы дать наибольший выигрыш на Win32 платформе.
VD>Ничем не обоснованное утверждение. Более того дотнет проектировался с прицелом как на 64-разнядные системы, так и на другие платформы. На том же Линуксе Моно себя чувствует ни чем не хуже.
Во-первых, моно чуствует себя немного хуже даже на Win32 платформе. Во вторых, я некорректно выразился. Я имел ввиду Intel32.
Где там ориентация на 64 бита? все коллекции имеют индекс типа int. Да и вообще, int — наиболее употребимый тип (он же System.Int32)
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Шахтер, Вы писали:
AVK>>>Да ты не стесняйся, приводи конкретные примеры современных микроконтроллеров, у которых байт не равен 8 битам.
Ш>>Вы хочете байтов? Их есть у меня. ;)
AVK>Внимательно изучил. Где там написано что байт не равен 8 битам?
Процессоры семейства Motorola 563xx оперируют с 24 битовыми (или 16 битовыми в 16 битовом режиме) словами. 8 битовые данные они ни адресовать, ни обрабатывать непосредственно не могут.
Я надеюсь, ты по-английски читать умеешь.
— although the char type is 8 bit, each char occupies one memory word, because the DSP56xxx has no instructions to access one byte efficiently.
Здравствуйте, AndrewVK, Вы писали:
AVK>Умею. А ты по русски? Я тебе вроде бы конкретный вопрос задал — какие современные процессоры имеют байт не равный 8 битам.
Тебе был приведен совершенно конкретный пример проца с 24 битовым байтом.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndrewVK, Вы писали:
AVK>>А тебе чего надо? Если нужна реализация, то для этого есть абстрактные классы, ибо нефиг заниматься копипейстом.
VD>Известно чего. Множественного наследования или микс-инов.
Множественное наследование интерфейсов (без чего немыслимо программирование на C#) — это частный вид множественного наследования в ООП. Не, вернее так: интерфейс — это частный вид класса.
В .Net множественное наследование классов отсутствует не по идеологическим соображениям, а из-за особенностей работы сборщика мусора. (имеются ввиду используемые на данный момент алгоритмы определения периметра)
Когда-то этот вопрос был четко прояснен для Джавы, нет смысла мусолить опять.
Здравствуйте, AndrewVK, Вы писали:
V>>Компилятор C# изначально многопроходный, в идеале — сколь угодно проходный. Компилятор С++ изначально расчитан на ограниченное число проходов (язык организован так, что вполне позволяет обойтись одним — по историческим причинам, ты помнишь мощность своего десктопа в 1990-м? а объем его оперативки? он бы просто не смог скомпилировать более-менее сложную программу на C#)
AVK>Какой из этого следует вывод?
Ты хоть намекни, какой следует вывод у тебя.
V>>Тут мы видим наследие языка С, который суть одно сплошное UB , однако в С++ оставлены те же возможности и механизмы их реализаций, что и в С, что позволяет использовать С++ в тех областях, где раньше был применим С (а до него ASM).
AVK>Какой из этого следует вывод?
Что применим до сих пор, и будет еще долго применим, для реализации того же дотнет на различных платформах
V>> где тоже элементарно получить UB в случае ошибки описания предполагаемой бинарной структуры ожидаемого типа.
AVK>Например? Особенно интересны элементарные случаи. На всякий случай — P/Invoke это safe механизм.
C# не гарантирует расположение полей в run-time.
для "надежности" расположение можно описать аттрибутами, но эта аттрибутика не описываема в грамматике языка.
я тоже в С++ пользуюсь #pragma pack(xxx) и избегаю последствий UB точно таким же приемом. Просто, в случае С++ никто не стесняется говорить о возможном UB.
struct A { int i; }
struct B { int i; }
A* a = new A;
B* b = (B*)a;
будет работать? — будет.
однако UB в общем случае.
VD>>>Тоже, скажем, так сомнительное утверждение. Со многих точек зрения C# сложнее С++. V>>Тоже, скажем, так сомнительное утверждение. Ты неоднократно говорил о том, что C# сложнее С++. Я хочу узнать, наконец, в чем именно?
AVK>Например в количестве стандартных синтаксических конструкций. А ты думал что С++ во всем сложнее щарпа?
А почему бы не подсчитать семантические?
добрая чать этих "стандартных синтаксических конструкций" относится к особенностям единой системы типов.Net и аттрибутики.
В MC++ этих дополнительных нетовских конструкций как минимум не меньше, и плюс весь остальной язык.
(тут вообще прикол получается. грамматика C# завязана на конкретные типы из .Net, аттрибуты управляют программой. допустимые и применимые аттрибуты в граматике не опишешь, налицо некий разрыв и опора просто на спецификации и идентификаторы "специальных" типов/аттрибутов)
AVK>На всякий случай — я не утверждаю что один язык безоговорочно сложнее другого, это утверждение неверно в оба конца.
Ну хорошо, а субъективно как?
Я на С++ хрен его знает сколько, и порой открываю интересные трюки (читай — нахожу доп. выразительные ср-ва языка, способные сэкономить трудоемкость).
В C# въехал сразу, но выразительности не хватает. (хотя она окупается гигантскими всеобъемлющими библиотеками поддержки)
Собственно, я рассматриваю C# как удобный интрфейс к этим библиотекам.
Плюсовики признают, "нам бы такие всеобъемлющие библиотеки", базара не было бы ни о чем
Да, ас C# — это тонкий знаток дотнета, ас С++ — тонкий знаток языка.
Здравствуйте, VladD2, Вы писали:
V>>Ты — идеальный потребитель с т.з. финансовой позиции Microsoft. Успехов!
просто был очарован твоим слогом.
жаль, что он:
— не доказывал ни одной из поднятых тобой тем в предыдущих топах
— не опровергал мои аргументы
— был построен не то как рекламный слоган, не то как признание в любви. По крайней мере в самом материале не утверждалось ничего такого, что требовало бы или не требовало бы аргументов собеседника.
в свете этого: VD>Ну, что же. Будем считать, что этим ты прсписался в отсуствии достойной аргументации. Поговорим лет через 10.
немного мимо...
ну и легкое чуство юмора тоже должно присутствовать.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Интересно... По мне, это больше похоже на критерии качества языка, а не его стандарта.
Это связанные вещи. Не может быть качественного языка без качественного стандарта.
ПК>Имхо, главным критерием качества проработки собственно стандарта является количество его разночтений разными разработчиками: чем этих разночтений меньше, тем стандарт проработаннее. Скажем, для того же C# мне пока сложно об этом судить, т.к. еще не видно сколько-нибудь значительного количества проектов, использующих разные его реализации.
Не думаю, что нужна туча реализаций компилятора, чтобы можно было рассуждать о качестве проработки стандарта. Достаточно внимательно его прочесть.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, prVovik, Вы писали:
V>>Очевидно — это причастность стандарта к языку, на котором сам программируешь
VD>Как ты думашь, что может сподвигнуть к отказу от языка на котором до этого программировал около 10 лет?
Неужели тебя сподвиг УРОВЕНЬ СТАНДАРТИЗОВАННОСТИ языка?
VD>И какой язык считать более близким если на одном программировал 10 лет, а на другом 2 года?
Ну, эмигранты тоже всегда рассказывают ужасы, о своей прежней жизни на родине. Это, кстати, почти научный факт
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Не туча реализаций компилятора, а хотя бы две-три реализации и сколько-нибудь значительное количество проектов, которые могут работать то на одной, то на другой реализации.
Этого тоже не нужно. Это банальная отмазка. К тому же две реализации есть и проекты работающие на них тоже есть.
Спецификация языка нужна не только для переноса компиляторов на другие платформы (для дотнета это вообще не актуально) или создания конкурирующий компиляторов, в первую очередь она нужна для того чтобы разбираться в языке.
То что по спецификации Шарпа можно спокойно изучать язык — это факт доказанный на практике. Как и то, что в стандарте плюсов черт может голову сломать.
>> Достаточно внимательно его прочесть.
ПК>Если речь о самой возможности рассуждений, то для этого можно и не читать: рассуждать можно и о чем угодно.
Из серии сам я автора не читал... ?
ПК> Если достаточно общего впечатления — да, достаточно просто внимательно прочесть. Другой вопрос, насколько верным будет это впечатление.
Паш. Глупо пытаться поставить под сомнение очевидные вещи. Ты бы лучше открыл да почитал.
ПК>Если же речь о сколько-нибудь объективном сравнении нескольких разных стандартов, то для этого нужно составить более-менее соответствующее действительности представление о количестве разночтений и недосказанностей в этих стандартах.
Ну, сколько оных в С++ ты вкурсе. А вот в Шарповом я подобных вещей встречал очень мало.
ПК>Как показывает практика, внимательно прочесть стандарт для этого не достаточно. Недостаточно даже несколько раз внимательно прочесть. Даже очень внимательное прочтение очень многими людьми по нескольку раз не является достаточным. Даже в случае, когда эти люди являются экспертами языка и/или разработчиками соответствующих компиляторов. Пока дело не доходит до реализации и практического использования, многие недосказанности и противоречия просто не видны.
Пашь, поверь я как раз занимаюсь "реализацией и практическим использованием". Причем очень плотно.
ПК>Я бы с удовольствием прочитал любое обоснованное сравнение степени проработки стандартов разных языков,
Я бы тоже.
ПК>но, имхо, подобная работа, результаты которой будут хоть сколько-нибудь точны, легко потянет на диссертацию, и вряд ли кому-нибудь настолько интересно этим заниматься.
И тем не менее это не отнимает у меня права высказывать свое мнение по этому поводу. Я не мало потрахался с обими языками и могу сказать, что качество проработки у Шапровской спецификации гораздо выше. Думаю, что в основном это именно из-за того, что сам язык лучше спроектирован. Чем меньше нестыковок, тем проще писать сеецификацию.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Т.к. стандарт C# в качестве понятия, эквивалентного абстрактной машине, описанной в стандарте C++, использует CLI, то для сравнении стандарта C++ и C# к последнему следует добавлять стандарт CLI. Иначе будет производиться сравнение части с целым, что, очевидно, некорректно.
Не нужно притягивать за уши, что попало. Есть спецификация C# и есть куча спецификаций под общим названием стандарт дотнета. Для сравнения языков совершенно не нужно притягивать весь дотнет. В конце концов иначе получается обсурд. Тот же С++ реализуется для дотнета, и можно смело будет рассматривать стандарт плюсов как часть описания дотнета.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Весь — нет. Но часть, влияющую на семантику языковых конструкций — нужно.
Упомянутые P/Invoke и формат сборки к ним не относятся.
>> и можно смело будет рассматривать стандарт плюсов как часть описания дотнета.
ПК>Можно. Но это не будет соответствовать действительности: C++/CLI основывается на спецификации CLI, так же, как и C#. И точно так же, как стандарт C#, частью стандарта CLI не является.
Компилятор С++ может порождать код для нетовского рантайма. Именно С++, а не С++/CLI или С++ with Managed Extensions.
VladD2,
> Надо тебе доказать правильность или ошибочность моих суждений, можешь это делать.
Снова shifting the burden of proof. Для того, чтобы в дискуссии не учитывались некоторые суждения, доказывать их ошибочность не нужно. Достаточно просто отсутствие доказательства их верности.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> Попробуй найти там ссылки с зависимостями.
ПК>Пожалуйста, на том же месте: ПК>
3. Normative references
ПК>The following normative documents contain provisions, which, through reference in this text, constitute provisions of this International Standard. <...>
ПК>ISO/IEC 23271:2002, Common Language Infrastructure (CLI), Partition IV: Base Class Library (BCL), Extended Numerics Library, and Extended Array Library.
Ну, и посмотри на что тут ссылка. И какая. Ссылка на описание библиотек. Их интерфейс полностью приведен в спецификации.
А если посмотреть на что идут ссылки дальше:
ISO 31.11:1992, Quantities and units — Part 11: Mathematical signs and symbols for use in the physical sciences and technology.
ISO/IEC 2382.1:1993, Information technology — Vocabulary — Part 1: Fundamental terms.
ISO/IEC 10646 (all parts), Information technology — Universal Multiple-Octet Coded Character Set (UCS).
IEC 60559:1989, Binary floating-point arithmetic for microprocessor systems (previously designated IEC 559:1989). (This standard is widely known by its U.S. national designation, ANSI/IEEE Standard 754-1985, IEEE Standard for Binary Floating-Point Arithmetic.)
The Unicode Consortium. The Unicode Standard, Version 3.0, defined by: The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), Unicode Annex UAX #15: Unicode Normalization Forms, and Unicode Annex UAX #19: UTF-32.
И слпдовать твоей логике, то вообще смешно становится, так как не дай бог в спецификации мат.символы будут по разному описаны. Ведь стандарты вообще сравнить будет нельзя.
В общем, как всегда при попытки притянуть за уши не относящиеся к делу вещи ты скатился к формализму.
Чтобы сравнивать стандарты нет никакой нужны сравнивать в них буквы и искать недочеты. Достаточно прочесть и составить собственное мнение. Причем порой даже все читать не нужно. Делаешь просто поиск по словосочетанию "неопределенное поведение" или смотришь что в спецификации есть по работе с модулями и все становится понятно. Потом сравнивашь объемы спецификаций...
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>Снова shifting the burden of proof. Для того, чтобы в дискуссии не учитывались некоторые суждения, доказывать их ошибочность не нужно. Достаточно просто отсутствие доказательства их верности.
> Ну, вот так как вот эти твои слова, да и 99% все остальных сказанных на этом форуме не имеют подтверждений
Отчего же? Проведи небольшой поиск по словам "shifting the burden of proof", и найдешь сколько угодно подтверждений данным моим словам.
> то на основании твоих же слов признаем их голословными, огульными и не будем учитывать их в дискуссиях. ОК?
Те, которые я откажусь аргументировать, ограничиваясь ссылками на личный опыт и прочие не верифицируемые источники — естественно.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Количество упоминаний неопределенного поведения никак не связано с качеством проработки стандарта.
Какова цель спецификации языка?
И может ли быть у "плохого" языка хорошая спецификация?
>> или смотришь что в спецификации есть по работе с модулями и все становится понятно.
ПК>То же самое. Это вопросы специфицируемого языка, а не качества проработки стандарта.
Т.е. несовместимость между Борлад С++ и VC++ — это проблемы языка, а не его стандарта?
Ну, и еще один вопрос. Судя по твоим переключением стрелок на язык ты считашь, что С++ плохо спроектированный язык с хорошей спецификацией. Так?
>> Потом сравнивашь объемы спецификаций...
ПК>Без сравнения сложности языков это не имеет значения.
В исходной теме говорилось именно о сложности спецификации. Так что в контексте данного обсуждения очень даже имет значение.
И очень интересно каковы твои критерии определения сложности языка?
ПК>P.S. В общем, похоже, мы с тобой подходим к данному вопросу совсем с разных сторон: ты со стороны личных предпочтений и собственных мнений, а я со стороны возможности количественного/точного сравнения. Дальше, наверное, можно не продолжать, так как эти дорожки вряд ли встретятся.
Как всегда.
Для тебя стандарт это такой сферический конь в вакуме качество которого никак не зависит от порождаемого им продукта. А для меня основным критерием качества стандатта является качество порождаемого им продукта. Если на базе этого описания у десятка серьезных и очень богатых контор не удается создать компиляторы которые одинаково интерпреритруют исходный код, то я назывю такой стандарт не качественным. А с тем что пролемы этого стандарта ростут из качества проектирования языка дык тут я полностью согласен.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> ПК>Снова shifting the burden of proof. Для того, чтобы в дискуссии не учитывались некоторые суждения, доказывать их ошибочность не нужно. Достаточно просто отсутствие доказательства их верности.
>> Ну, вот так как вот эти твои слова, да и 99% все остальных сказанных на этом форуме не имеют подтверждений
ПК>Отчего же?
Не от чего же. А с чего же. С твоих слов.
ПК> Проведи небольшой поиск по словам "shifting the burden of proof", и найдешь сколько угодно подтверждений данным моим словам.
Забавная привычка приводить ссылки на языке на котором не думаешь. Что в русском нет этих терминов? Вот тебе ссылочка на статью 49 Конституции РФ в которой как раз говорится о недопустимости переложения бремяни доказывания на обвиняемого. Как раз о той самой презумпции невиновности.
В данном случае ты ставишь меня в положение обвиняемого и пыташся заставить меня же оправдываться.
>> то на основании твоих же слов признаем их голословными, огульными и не будем учитывать их в дискуссиях. ОК?
ПК>Те, которые я откажусь аргументировать, ограничиваясь ссылками на личный опыт и прочие не верифицируемые источники — естественно.
Пашь, ты хочешь чтобы я заставил тебя отказываться от аргументации? Это очень несложно сделать. Достаточно просто заставить тебя аргументировать все без исключения твои высказывания. Рано или поздно ты откажешся аргументировать все подряд или вместо аргументации начнешь перекладывать бремя доказательства на другого.
Ты применяешь очень некрасивые приемы в дискусси. Ты пыташся заствить оправдываться оппонента. К сожалению многие не понимаю всю демагогичность данного приема.
Итак. Я утверждаю, что требуют доказательства только не очевидные заявления сделанные в ходе логического вывода или доказательства. Все же остальные случаи являются выражением личного мения и подтверждения не требуют. В противном случае ты ставишь собеседника в очень неудобное положение. В народе это называется заставлять доказывать, что ты не верблюд.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>И тем не менее это не отнимает у меня права высказывать свое мнение по этому поводу. Я не мало потрахался с обими языками и могу сказать, что качество проработки у Шапровской спецификации гораздо выше. Думаю, что в основном это именно из-за того, что сам язык лучше спроектирован. Чем меньше нестыковок, тем проще писать сеецификацию.
Что значит "лучше"? Как можно сравнивать спецификации космического корабля и одноместного самолета? Количество потенциальных неувязок в первом случае гораздо больше.
Спецификация C# действительна очень проста, сам язык гораздо проще. При чем тут "лучше"?
Спецификация VB.Net еще проще...
Здравствуйте, vdimas, Вы писали:
V>Спецификация C# действительна очень проста, сам язык гораздо проще. При чем тут "лучше"? V>Спецификация VB.Net еще проще...
Гы. Плюс сверху видишь? Так это ПК так свое несогласие выражает. Вот аргументация его мнения: Re[10]: Качество стандарт
Так что ПК практически доказал, что спецификация Шарпа сложнее чем С++-ная. Ну, а то что C# сложнее чем C++ легко понять просто посчитав количество конструкций языка.
ЗЫ
Если серьезно, то хорошее доказательсво тезиса о том, что простота языка заключается в простоте его восприятия, а не как не в количественных показателях. Единственный серьезный количественный показатель пожалуй — это количество граблей.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>Да, стандарт C++ нельзя рассматривать в отрыве от части стандарта C. На соответствующие пункты стандарта C в теле стандарта C++ есть прямые ссылки. Если интересно, можешь посчитать, сколько в результате получится страниц. Правда, в основном большая часть будет относиться к библиотеке.
> Дык как же тогда ты умудряешся сравнивать стандарт С++ без С и стандарт Шарпа но с BCL?
Уфф... Там, где я сравнивал стандарты C++ и C#, я это делал без библиотек. Соответственно, без ссылок на стандарт C и стандарт CLI.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, 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>Ну хорошо, а субъективно как?
Синтаксис шарпа сложнее, возможностей с легкостью делать то что изначально не предполагалось больше у С++.
Здравствуйте, 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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Пожалуйста, перечисли, что именно не позволяет в шаблонах создать приемлемую промежуточную форму, и что является приемлемой промежуточной формой?
Не совсем в шаблонах. Тут накладывается несколько факторов.
Сумма невозможности детерминирования некоторых синтаксических конструкций без информации о типах, отсуствие ограничений (а стало быть невозможность передать информацию о итпах в шаблон во время его парсинга), допустимость неверного синтаксиса до конкретного применения в купе приводят к тому, что промежуточная форма обызана быть слишком абстрактной и по ней невзможно осуществить качественной семантический контроль. В итоге получается, что создать то его можно. Но овчинка не стоит выделки.
В итоге, многие компиляторы вообще плют на парсинг шаблонов до их воплощения.
... << 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,
> С++ ставит размер типов в зависимость от реализации, а C#, как и система типов CLI четко определяет их в стандрарте.
> <...>
> V> однако в С++ оставлены те же возможности и механизмы их реализаций, что и в С, что позволяет использовать С++ в тех областях, где раньше был применим С (а до него ASM).
> Все необходимые для этого возможности есть и в C#. <...>
Не совсем. В частности, чуть выше процитирована одна из причин, не позволяющих в некоторых случаях использовать C# без дополнительной прослойки. В самом деле, если размер машинного слова не ложится на размеры целых типов CLI, то очевидно, что работа с целыми в C# не будет прямой работой с платформой. И подобный выбор очень хорошо иллюстрирует то, что C#, в отличие от C++, и близко не предназначен для замены использования C или, тем более, ассемблера.
Я не утверждаю, что это плохо. Просто это демонстрирует разницу в целях, которые ставили перед собой разработчики C# и C++.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, vdimas, Вы писали:
ГВ>>Не, дело не в этом. Дело в том, что публично высказанное ошибочное мнение, оставленное без соответствующих contra может принести кому-то вполне реальный вред. Мне например. И кстати, это одна из причин, по которой я, например, тусуюсь на этом форуме. V>Да, да!!! Я тоже здесь тусуюсь в ожидании получения вполне реального вреда! V>Пока получается с точностью до наоборот... не везет, короче...
Дима, спасибо за поправку. Естественно, я тусуюсь тут того, чтобы не допустить такого вреда.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, vdimas, Вы писали:
ГВ>>>Не, дело не в этом. Дело в том, что публично высказанное ошибочное мнение, оставленное без соответствующих contra может принести кому-то вполне реальный вред. Мне например. И кстати, это одна из причин, по которой я, например, тусуюсь на этом форуме. V>>Да, да!!! Я тоже здесь тусуюсь в ожидании получения вполне реального вреда! V>>Пока получается с точностью до наоборот... не везет, короче...
ГВ>Дима, спасибо за поправку. Естественно, я тусуюсь тут того, чтобы не допустить такого вреда.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Важно уточнить, что при этом размер байта в C# фиксирован, и равен 8 битам. В C/C++ такого ограничения нет.
C/C вообще нет типа byte. Ну, да не в том дело.
ПК>И дело тут вовсе не в оптимизации, а в самом предназначении языка для системного программирования, каковое вряд ли можно представить без наличия типа, непосредственно соответствущего машинному слову, равно как и типа, представляющего минимально адресуемую единицу памяти.
Да, можно представить. Особенно на сегодня. Для языка уже не так вазно машинное слово. Операции с адресацией все больше и больше уводятся из самого языка ("за кулисы"), а те редкие случае которые действительно нужны можно оформить в виде платформно-зависимых библиотек.
Да и само системное программирование — это отдельный и довольно узких участок деятельности. С++ же обычно применяется для совсем не системных областей. И в этих областях его небезопасность базовых концепций служит весма плохую службу.
Ну, а там где от С есть толк этот езяк еще долго будет использоваться. Возможно даже совместно с новыми более надежными и простыми в испльзовании средствами.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ну стандарт C# от стандарта CLI зависит совершенно явным образом, поэтому тут отказываться не от чего.
Только лишь тем, что описание базовых бублиотек чтобы не дублировать вынесли в отдельную спецификацию. Они ксатит, тоже на Шарпе описаны.
>> и соглсен, что и C#, и C++ могут быть реализованы отдельно без привязыки к разным там реализациям CLI?
ПК>А вот здесь еще не знаю.
Ну, так ты решил свои затруднения?
ПК> Сначала был в этом уверен, теперь — нет.
Уже приятно.
ПК> Разбираюсь.
Ну, и как?
ПК> По крайней мере, часть библиотек, описанных в стандарте CLI, C#, в отличие от C++, требует.
И? Это непреодалимая проблема?
ПК> Это факт.
О... Таких фактов можно надыбать много. Например, C# создал МС. Тоже фак. Какя связь? А какая там связь?
ПК> Осталось разобраться, требуется ли этой части библиотек что-то собственно от платформы, или же это только спецификация относительно небольшого набора интерфейсов.
Разберись. А до тех пор не нужно делать предположений и высказывать мнений. Ты же веть так этого не любишь.
ПК>Сегодня обходит, завтра, может, не будет обходить. Поживем — увидим. Если модули появятся — просто супер, но и без них вполне жить можно.
А можно жить и без С++. По крайней мере во многих областях. И если они и дальше "будут обходить", то объходить начут С++. В прочем уже начинают обходить.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
AVK>>Да ты не стесняйся, приводи конкретные примеры современных микроконтроллеров, у которых байт не равен 8 битам.
Ш>Вы хочете байтов? Их есть у меня. ;)
VladD2,
> V> Причина в том, что эти системы начинались разрабатываться тогда, когда еще не было стандартов С++ и даже этого компилятора на многих аппаратных платформах.
> А это нет. Темболее что NT и Линукс разрабатывались в начале 90-ых. С++ тогда уже был.
Но стандарта не было.
> V> Windows уже давно пишут на С++.
> Никгда системные части Виндов не писались на С++. Погляди примеры к DDK и т.е.
Часть из них "внутри", под сишными интерфейсами, написана именно на C++. Хотя, конечно, зависит от того, что ты называешь "системными" частями. Тем не менее, части собственно Windows, как верно заметил vdimas, пишут на C++.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Шахтер, Вы писали:
Ш>Процессоры семейства Motorola 563xx оперируют с 24 битовыми (или 16 битовыми в 16 битовом режиме) словами.
А Pentium 32битными в 32-хбитном режиме.
Ш> 8 битовые данные они ни адресовать, ни обрабатывать непосредственно не могут.
Видимо для DSP это не нужно.
Ш>Я надеюсь, ты по-английски читать умеешь.
Ш>- although the char type is 8 bit, each char occupies one memory word, because the DSP56xxx has no instructions to access one byte efficiently.
Умею. А ты по русски? Я тебе вроде бы конкретный вопрос задал — какие современные процессоры имеют байт не равный 8 битам.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Я-то вполне понимаю. Но подозреваю, что у нас с тобой терминология немного отличается. Я приведу определение "моего" байта, а ты, если хочешь, можешь привести определение "твоего".
ПК>Байт (в терминах стандартов C и C++) — минимально адресуемая единица памяти. Кроме того, у байта (в терминах стандартов C и C++) все биты значащие. Байт (в терминах стандартов C и C++) может быть любого размера, не только 8 бит.
Байт Материал из Википедии — свободной энциклопедии
Байт м. скл. — единица измерения информации, равная восьми (первоначально шести) битам, может принимать 28 различных значений. Название было впервые использовано в 1956 году В.Бухгольцем при проекторовании первого суперкомпьютера IBM 7030 для пучка одновременно передаваемых в устройствах ввода-вывода битов (шести штук), позже в рамках того же проекта расширили байт до восьми (23) бит.
Машинное слово Материал из Википедии — свободной энциклопедии
Машинное слово — машиннозависимая и платформозависимая величина, измеряемая в битах или байтах, равная разрядности регистров процессора (обычно некоторая степень двойки). Машинное слово определяет следующие характеристики машины:
разрядность данных, наиболее оптимально обрабатываемых процессором;
максимальное значение беззнакового целого типа, напрямую поддерживаемого процессором: если результат арифметической операции превосходит это значение, то происходит переполнение;
максимальный объём оперативной памяти, напрямую адресуемой процессором.
[править]
Размер машинного слова на различных платформах
i8086, i8088, i80286 — 16 бит = 2 байта, максимальное значение 216-1=65535
i80386, i80486, Intel Pentium — 32 бита = 4 байта, максимальное значение 232-1=4294967295.
Intel Itanium, AMD Opteron, AMD Athlon 64, DEC Alpha, Sun SparcStation — 64 бита = 8 байтов, максимальное значение 264-1=18446744073709551615.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Но стандарта не было.
Юникс тоже без стандарта писался, но это не помешало стать ему и С стандартами дефакто.
>> V> Windows уже давно пишут на С++.
>> Никгда системные части Виндов не писались на С++. Погляди примеры к DDK и т.е.
ПК>Часть из них "внутри", под сишными интерфейсами, написана именно на C++.
Если только очень маленькая. К 2006-му году объем С++-кода в Виндовс, скорее всего, будет меньше чем Шарповского, так как объемы WinFX API будут рости как снеждые комы. Так что...
ПК> Хотя, конечно, зависит от того, что ты называешь "системными" частями. Тем не менее, части собственно Windows, как верно заметил vdimas, пишут на C++.
Ядро пишут именно на С. И никаких предпосылок для использования С++ в подовляющем большинстве не будет. С++ будет занимать низкоуровневую нишу гед он всегда будет конкурировать с С. А высокоуровневая уже прочно занята тем же Шарпом. И это правильно.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
>>> V> Windows уже давно пишут на С++.
>>> Никгда системные части Виндов не писались на С++. Погляди примеры к DDK и т.е.
ПК>>Часть из них "внутри", под сишными интерфейсами, написана именно на C++.
VD>Если только очень маленькая.
Я тут прошелся по одному знаменитому архивчику. Там набралось 2255 *.cpp файлов общей длинной 1763618 строк кода. Так что твоё утверждение об очень маленькой части не соответствует действительности.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
Ш>>Я тут прошелся по одному знаменитому архивчику. Там набралось 2255 *.cpp файлов общей длинной 1763618 строк кода. Так что твоё утверждение об очень маленькой части не соответствует действительности.
VD>Речь шла о дравах или ядре. Пошарься еще рез.
Цитата ПК.
Часть из них "внутри", под сишными интерфейсами, написана именно на C++. Хотя, конечно, зависит от того, что ты называешь "системными" частями. Тем не менее, части собственно Windows, как верно заметил vdimas, пишут на C++.
Здравствуйте, vdimas, Вы писали:
V>в свете этого: VD>>Ну, что же. Будем считать, что этим ты прсписался в отсуствии достойной аргументации. Поговорим лет через 10. V>немного мимо...
Похоже как раз в самую точку.
V>ну и легкое чуство юмора тоже должно присутствовать.
Меньше нужно смотреть назные Аншлаги, тогда и юмор будет по приличнее.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, vdimas, Вы писали:
V>>ибо если к уже имеющемуся классу захочу подмешать интерфейс — обломаюсь.
AVK>здесь
не выход для полномасштабного применения, в проекировании на это никто и никогда забиваться не будет, хотя вполне реально использовать в немногочисленным местах где "сильна нада".
Здравствуйте, Шахтер, Вы писали:
Ш>Я надеюсь, ты по-английски читать умеешь. Ш>- although the char type is 8 bit, each char occupies one memory word, because the DSP56xxx has no instructions to access one byte efficiently.
Пример некорректный. Этот перевод говорит только лишь о том, что такие процессоры могут работать лишь с данными, выравненными по границе слова.
Здравствуйте, prVovik, Вы писали:
VD>>Как ты думашь, что может сподвигнуть к отказу от языка на котором до этого программировал около 10 лет? V>Неужели тебя сподвиг УРОВЕНЬ СТАНДАРТИЗОВАННОСТИ языка?
Уровень качества. В том числе и уровень качества стандарта. Мог бы догодаться.
VD>>И какой язык считать более близким если на одном программировал 10 лет, а на другом 2 года? V>Ну, эмигранты тоже всегда рассказывают ужасы, о своей прежней жизни на родине. Это, кстати, почти научный факт
Это к ПК. А аналогии идут лесом. Или можно долго подбирать аналогии вроде смены Запорожца на Кодилак.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Павел Кузнецов,
> Вот и нужно собрать данные о проблемах переносимости реальных проектов между этими двумя реализациями для возможности каких-то суждений. Я таких данных не видел. Может, приведешь ссылку?
P.S. Беглый поиск показал, что в ходе кроссплатформенной разработки дефекты выявляются:
In general I have observed the following problems:
1. Mono implementation violates ECMA or any other standard
2. .NET implementatioan violates ECMA or any other standard
3. Both violate standards (surprisingly but it is or was true for PECOFF file format ECMA extended standard — it was violated by both Mono and .NET — Mono is fixed now)
4. Both conform to standard but every implementation is behaving differently due to standard ambiguity (P/Invoke is best example)
<...>
I have observed this problem with all my projects written for .NET which looking into feature sets only should work on Mono but they are crashing gracefully with plenty of exceptions. By delving into detailed analysis I discovered and reported several Mono bugs, but in parallel I discovered multiple incosistencies with standard conformance by Mono and .NET — not blaming anyone. The result is that portability is a major issue for any .NET/Mono developer looking for portability of any project.
Вопрос только в их количестве...
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Естественно, но отсутствие аргументации или, хотя бы, объяснений, что именно ты имеешь в виду, сильно снижает ценность твоих подобных высказываний для читателей.
Я и не брался за составление серьезного и аргументированного сравнения. Темблее что для меня сравнение стандартов в отрыве от языков совершенно бесмысленно. Ты кажется сам оценил эту работу как дисертацию. Надеюсь, в этот раз ты не потребуешь написать дисиртацию, чтобы подтвердить мое права на наличие собственного мнения.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>Вопрос только в их количестве...
> Ты не перепутал язык C# и платформу .NET?
Т.к. стандарт C# в качестве понятия, эквивалентного абстрактной машине, описанной в стандарте C++, использует CLI, то для сравнении стандарта C++ и C# к последнему следует добавлять стандарт CLI. Иначе будет производиться сравнение части с целым, что, очевидно, некорректно.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Дык, я полагал, что ты обладаешь сколько-нибудь достоверной информацией, делая такие безаппеляционные заявления
О! Снова ярлыки. Снова желание взять на понт... Апеллируй скоько тебе влезет, если хочется. Для меня сказанное мной очевидно. Но заниматься глупыми доказательствами просто не считаю нужным. Жизнь и так все расставляет на свои места.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Стандарт же C# ссылается на стандарт CLI в нормативной части: ПК>
The following normative documents contain provisions, which, through reference in this text, constitute
ПК>provisions of this International Standard. <...>
ПК>ECMA-335, 2nd Edition, December 2002, Common Language Infrastructure (CLI), Partition IV: Base
ПК>Class Library (BCL), Extended Numerics Library, and Extended Array Library (also published as ISO/IEC
ПК>23271:2002).
ПК>Соответственно, без стандарта CLI, нормативная часть стандарта C# будет неполной.
Annex F. Bibliography 1
This annex is informative. 2
3
ANSI X3.274-1996, Programming Language REXX. (This document is useful in understanding floating- 4
point decimal arithmetic rules.) 5
ISO 31-0:1992, Annex B (informative), Guide to the rounding of numbers (This document defines “banker’s 6
rounding.”) 7
ISO/IEC 9899:1999, Programming languages — C. 8
ISO/IEC 14882:1998, Programming languages — C++.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
На всякий случай: это черновик, соответственно, стандартом он пока не является.
> Попробуй найти там ссылки с зависимостями.
Пожалуйста, на том же месте:
3. Normative references
The following normative documents contain provisions, which, through reference in this text, constitute provisions of this International Standard. <...>
ISO/IEC 23271:2002, Common Language Infrastructure (CLI), Partition IV: Base Class Library (BCL), Extended Numerics Library, and Extended Array Library.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Кодт,
> 1) отказаться от неконструктивных выпадов в пользу диалога (помните Сократовское "в споре рождается истина"?)
Дык, к сожалению, от конструктива Влад уже отказался, сказав, что аргументировать свое сообщение он не станет. Буду только рад, если от простого высказывания мнений он вернется к их обоснованию.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Снова shifting the burden of proof. Для того, чтобы в дискуссии не учитывались некоторые суждения, доказывать их ошибочность не нужно. Достаточно просто отсутствие доказательства их верности.
Ну, вот так как вот эти твои слова, да и 99% все остальных сказанных на этом форуме не имеют подтверждений, то на основании твоих же слов признаем их голословными, огульными и не будем учитывать их в дискуссиях. ОК?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Компилятор С++ может порождать код для нетовского рантайма. Именно С++, а не С++/CLI или С++ with Managed Extensions.
ПК>А еще для X86, Solaris, Macintosh и прочих платформ, на базе которых можно построить абстрактную машину, описанную в стандарте C++. Иными словами стандарт C++, в отличие от стандарта C#, от .Net/CLI не зависит. И наоборот, стандарт CLI от стандарта C++ тоже не зависит.
Т.е. ты утверждаешь, что кроме как на .Net реализовать абстрактную машину C# нельзя?
ПК>Стандарт же C# ссылается на стандарт CLI в нормативной части: ПК>
The following normative documents contain provisions, which, through reference in this text, constitute provisions of this International Standard. <...>
ПК>ECMA-335, 2nd Edition, December 2002, Common Language Infrastructure (CLI), Partition IV: Base Class Library (BCL), Extended Numerics Library, and Extended Array Library (also published as ISO/IEC 23271:2002).
ПК>Соответственно, без стандарта CLI, нормативная часть стандарта C# будет неполной.
Там описаны библиотеки. На их описание и ссылки. Причем все эти библиотеки включены в спецификацию. Какие еще зависимости тебя беспокоят?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Итак. Я утверждаю, что требуют доказательства только не очевидные заявления сделанные в ходе логического вывода или доказательства. Все же остальные случаи являются выражением личного мения и подтверждения не требуют. В противном случае ты ставишь собеседника в очень неудобное положение. В народе это называется заставлять доказывать, что ты не верблюд.
V>бурные аплодисменты. V>в статике это выглядит приемлимо, однако, наблюдая за динамикой дисскуссии — не очень.
Вот и задумайся, не является ли это только ощущениями.
V>бывают споры "за жисть", а бывают аргументированные обмены мнениями, если ввязался в последнее — изволь соответствовать... или не ввязываться.
Примеры где я привел каие-то факты в качестве доказательства и отказался их объяснять? Я не хочу быть в положении оправдывающегося. Вот и все. А некоторые очень любят незаметно применить тот или иной демагогический примчик с целью поставить человека (который зачастую и собеседником то не является) в неудобное положение.
К сожелению, общая грамотность людей на форумах не очень высока. И подобные приемы частенько проходят, причем проходят на ура. Вот почитай на досуге http://blacklight.h1.ru/oppo09.htm там многие из этих примемов описаны.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>И тем не менее это не отнимает у меня права высказывать свое мнение по этому поводу. Я не мало потрахался с обими языками и могу сказать, что качество проработки у Шапровской спецификации гораздо выше. Думаю, что в основном это именно из-за того, что сам язык лучше спроектирован. Чем меньше нестыковок, тем проще писать сеецификацию.
V>Что значит "лучше"?
ЛУЧШЕ. 1. см. хороший. 2. в знач. сказ., кому. Об улучшении состояния больного. Ребенку сегодня л. 3. вводн.сл. и частица. Предпочтительнее, вернее. Говори или, л., я? Л. не рисковать. Л. и не спорь. * А лучше сказать, в знач. союза — вводит уточнение, а вернее сказать. Он умен, а лучше сказать осмотрителен. Лучше всего, вводи, ел. — то же, что лучше (в 3 знач.). Давай поговорим или, лучше всего, помолчим. Как нельзя лучше — очень хорошо, отлично. Дела идут как нельзя лучше. И того лучше (ещё того лучше) (обычно ирон.) — совсем хорошо.
V> Как можно сравнивать спецификации космического корабля и одноместного самолета?
Некорректная аналогия. Тут сравниваются спецификации импиративных языков объектно ориентированного программирования общего назначения. Они более чем сравнимы.
V> Количество потенциальных неувязок в первом случае гораздо больше.
Демагогия на базе некорректной аналогии.
V>Спецификация C# действительна очень проста,
Для тех кто ее не читал. Рельно она понятна и не противоричива, но не проста. Это довольно объемный и не простой документ. Проста она только в сравнении с запутанной и противоричивой.
V> сам язык гораздо проще.
Тоже, скажем, так сомнительное утверждение. Со многих точек зрения C# сложнее С++.
V> При чем тут "лучше"?
При том. Качественнее. На меньшем количестве страниц дано более сбалансированное и логичное описание. Нет такого количества пробелем и т.п.
V>Спецификация VB.Net еще проще...
Опять неправда. Спецификация VB.Net приблизительно равна по объему и сложности Шарповой.
ты выступал за обоснование любых утверждений. В данном сообщении ты наделал кучу ничем не подтвержденных (а реально ошибочных) утверждений. Поробуй их обосновать. Ну, ради хохмы.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> V> При чем тут "лучше"?
> При том. Качественнее. На меньшем количестве страниц дано более сбалансированное и логичное описание. Нет такого количества пробелем и т.п.
Из твоих предыдущих объяснений я уже понял, что части "качественнее", "количество проблем", "более сбалансированное и логичное описание" — исключительно твое личное мнение, которое выражается в неформальных категориях и, соответственно, измерению не поддается. Ну что ж, так тому и быть.
Но вот часть о "меньшем количестве страниц" просто не соответствует действительности самым простым образом.
"Языковая" часть C# описывается в приведенном тобой документе (учитывая только нормативные части) начиная со страницы 1 по страницу 11 и со страницы 63 по страницу 433, что составляет 370 страниц.
"Языковая" часть C++ описывается в соответствущем стандарте начиная со страницы 1 и заканчивая страницей 317, что составляет 316 страниц. Остаток стандарта C++ — описание стандартной библиотеки, которая из стандарта C# вынесена в отдельный документ.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Из твоих предыдущих объяснений я уже понял, что части "качественнее", "количество проблем", "более сбалансированное и логичное описание" — исключительно твое личное мнение, которое выражается в неформальных категориях и, соответственно, измерению не поддается. Ну что ж, так тому и быть.
Ну, почему же? Количество проблем легко измеряется обычным подсчетом. Это ты хочешь представить так, будто их нет или невозможожно посчитать/сравнить. Заходишь на форум по соответствующему языку и начинишь считать грабли, на которые наступили люди. Статистики я не вел, но уверен, что разрыв между С++ и Шаром будет очень не маленький. И, я просто уверен, что ты и сам это знаешь очень не плохо. Грабли C++ в купе с морем неопределенностей и дали стимул для создания Явы и C#-а.
Логичность описания заключается в редком упоминании неопределенного поведения (почти полном отсутствии) и в легкости восприятия. Последнее конечно субъективная характеристика, но сути дела это не меняет.
Что же касается точных измерений, так в жизни очень малая доля явлений может быть легко переведена в язык цифр (а уж так чтобы их можно было без натяжки сравнить...). Причем обычно для таких сравнений нужно провести нехилые научные исследования. Так что для сферокоников есть хорошая почва почти везде.
ПК>Но вот часть о "меньшем количестве страниц" просто не соответствует действительности самым простым образом.
ПК>"Языковая" часть C# описывается в приведенном тобой документе (учитывая только нормативные части) начиная со страницы 1 по страницу 11 и со страницы 63 по страницу 433, что составляет 370 страниц.
ПК>"Языковая" часть C++ описывается в соответствущем стандарте начиная со страницы 1 и заканчивая страницей 317, что составляет 316 страниц. Остаток стандарта C++ — описание стандартной библиотеки, которая из стандарта C# вынесена в отдельный документ.
А что, по-твоему, находится на страницах 469-527? Где же тот непреклонный борец за формализацию все и вся? По факту в стандарте С++ более 700 страниц, в Шарповском ~530. И описание библиотек в них есть. Ну, а если подходить неформально, то неплохо бы заметить, что в стандарте C#-а описание сдублировано. Сначала идет краткое обзорное описание, а потом тоже самое раскрывается более тщательно.
Хотя конечно сравнивать "чистое описание языка" тоже разумно.
Ну, да ладно. В общем-то твое "описательное" сравнение мне даже на руку. ОК. Будь, по-твоему. Ты ведь любишь цифры? Так, давай посчитаем...
Итак, делаем поиск словосочетаний "undefined behavior" и "behavior is undefined"... и получаем:
В стандарте С++:
При этом "undefined behavior" встречается:
1 раз в оглавлении
2 раза в упоминании "Undefined behavior is indicated in this International Standard only by the words ''undefined behavior.''" (кстати, само по себе упоминание многого стоит!).
...
короче по делу реже, чем в описательном плане.
Реально все неопределенное поведение собрано в одном разделе. Вот его текст:
B.1 Undefined behavior A program that does not contain any occurrences of the unsafe modifier cannot exhibit any undefined behavior.
The behavior is undefined in the following circumstances:
1. When dereferencing the result of converting one pointer type to another and the resulting pointer is not correctly aligned for the pointed-to type. (§25.4)
2. When the unary * operator is applied to a pointer containing an invalid value (§25.5.1).
3. When a pointer is subscripted to access an out-of-bounds element (§25.5.3).
4. Modifying objects of managed type through fixed pointers (§25.6)
5. The initial content of memory allocated by stackalloc (§25.7).
6. Attempting to allocate a negative number of items using stackalloc (§25.7).
Заметь, неопределенное поведение может быть только в ансэйф-контексте!
Итого, в сухом остатке имеем около 100 против нуля (если не включать опцию поддержки unsafe-кода) или 6 (если включать)!
Вот это я называю качеством стандарта, продуманностью, логичностью и т.п. Можно ли называть все эти цифрами объективной оценкой? Конечно, нет, ведь нет проблем свести все к сфероконикам или сказать, что-то еще. Например, приплести "малое количество реальных реализаций компиляторов" и т.п. Начинай...
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Кстати, о размерах и корректности приплетения других стандатов включенный в список нормативны ссылок...
Таким образом исходя из твоей логики стандарт С++ (Гы-Гы) нельзя рассматривать в отрыве от стандарта С. Склько в нем страниц?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> Таким образом исходя из твоей логики стандарт С++ (Гы-Гы) нельзя рассматривать в отрыве от стандарта С. Склько в нем страниц?
Да, стандарт C++ нельзя рассматривать в отрыве от части стандарта C. На соответствующие пункты стандарта C в теле стандарта C++ есть прямые ссылки. Если интересно, можешь посчитать, сколько в результате получится страниц. Правда, в основном большая часть будет относиться к библиотеке.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В черновике следующей версии стандарта C#? Перечисление классов (и их содержимого) стандартной библиотеки + описание Documentation comments. В "релизной" предыдущей версии стандарта обе части помечены как информативные, в черновике только вторая. Соответствующая описанию стандартной библиотеки C++ нормативная часть с определением семантики стандартной библиотеки из стандарта C# вынесена в отдельный документ: ПК>
ПК>These types and their members are listed here, in alphabetical order. For a formal definition of these types and their members, refer to ISO/IEC 23271:2002 Common Language Infrastructure (CLI), Partition IV; Base Class Library (BCL), Extended Numerics Library, and Extended Array Library, which are included by reference in this International Standard.
Ну, те кто не видел "описания" STL мож даже подумать, что между "Перечислением" библиотек Шарпа и "описанием" STL есть огромная разница. Плюс что-то я не помню в плюсовом стандарте описания CRT. Оно тоже видимо вынесено в отдельный документ (спецификацию С).
>> Где же тот непреклонный борец за формализацию все и вся?
ПК>Не знаю. Если кому-то охота заняться развешиванием ярлыков — это не ко мне.
Как не к тебе? Ты с таким удовольствием этим занимашся.
>> По факту в стандарте С++ более 700 страниц, в Шарповском ~530. И описание библиотек в них есть.
ПК>Нет в стандарте C# спецификации библиотек. Только перечисление классов и их членов.
Дык описание STL не долеко от него ушло. Учитывая полному имен, коментарии и общую логичность библиотек для использования этого достаточно.
А сравнивать качество описания библиотек в "дополнительном стандарте" и то, что входит в стандарт плюсов просто нельзя. Это все равно что книга против ее реферата.
ПК>Краткое обзорное описание является информативной частью и без потери для полноты спецификации языка может быть из стандарта выброшено, т.к. требования могут содержаться только в нормативных частях. Соответственно, информативные части я в подсчете количества страниц спецификации не учитывал.
ОК. Я на это не обратил внимания.
>> Итак, делаем поиск словосочетаний "undefined behavior" и "behavior is undefined"... и получаем: <> Вот это я называю качеством стандарта, продуманностью, логичностью и т.п.
Эко ты покацал. Явно тебе не понравилось "количественное сравнение".
ПК>Что ты называешь качеством стандарта, я уже давно понял, и давно ответил, что мне совершенно все равно, сколько упоминаний неопределенного поведения ты найдешь в стандартах, т.к. к качеству стандарта (в смысле соответствия его своей цели)
Созданию дырявого языка?
ПК> это не относится.
Значит относится к качеству языка? И просто по случайности получилось, что при такой замечательной спецификации получился столь дырявый язык?
ПК> Изменив неопределенное поведение на что-то другое ты получишь просто другой язык. Полнота и точность спецификации от этого не изменятся.
Да, да. Дави на формализм. Ведь формально С++ ни счем сравнивать нельзя. У него другие цели (ну, не код же на нем писать, в самом деле?). Он особенный. Он ведь священная корова. Вот только почему? Аж, да, ведь он так тебе нравится.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Да, стандарт C++ нельзя рассматривать в отрыве от части стандарта C. На соответствующие пункты стандарта C в теле стандарта C++ есть прямые ссылки. Если интересно, можешь посчитать, сколько в результате получится страниц. Правда, в основном большая часть будет относиться к библиотеке.
Дык как же тогда ты умудряешся сравнивать стандарт С++ без С и стандарт Шарпа но с BCL? Да и в Шарповском стандарте тоже только ссылки на БЦЛ.
В общем, опять неувязочка.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> Так что ПК практически доказал, что спецификация Шарпа сложнее чем С++-ная.
ПК>Нет.
Нет?
А это можно считать утверждением? Или — это просто так... частное мнение? Ну, то которое ничем не подтверждено и значимость которого стремится к нулю...
Утверждение? Ну, тогда докажи его!
ПК> Только то, что объем спецификации языка C# не меньше, чем объем спецификации языка C++.
А каковы твои критерии сложности языка?
ПК>О сложности я ничего не говорил.
Ну, то есть про сложность ты вообще ничего сказать не можешь, а возражаешь против чужого мнения, просто ради борьбы за справедливость и торжество сферокоников?
Или давай уж определимся с критериями и выясним этот вопрос уровне цифр (типа объективно). Или ты признаешь, что в данном вопросе может существовать только субъективное мнение, и то, что мое субъективное мнение никак не может быть ущербным. А так же признаешь, что все твои возражения и попытки нивелировать мое мнение всего лишь некорректные приемы дискуссии, основанные на том, что мое частное мнение не совпадает с твоим точно таким же частным.
Мое мнение очень просто. C++ более сложный язык с точки зрения изучен, и использования. Но боле просто с технической токи зрения. В общем, практически парадокс если не считать, что сложным в изучении и использовании его делает непродуманность — усеянность граблями (во многом порожденная желанием сохранить совместимость с С), нестыковки в спецификации (то самое неопределенное поведение) и отчасти нежелание принимать авторами языка прогрессивных веяний времени.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
V>>Что значит "лучше"?
VD>
ЛУЧШЕ. 1. см. хороший. 2. в знач. сказ., кому. Об улучшении состояния больного. Ребенку сегодня л. 3. вводн.сл. и частица. Предпочтительнее, вернее. Говори или, л., я? Л. не рисковать. Л. и не спорь. * А лучше сказать, в знач. союза — вводит уточнение, а вернее сказать. Он умен, а лучше сказать осмотрителен. Лучше всего, вводи, ел. — то же, что лучше (в 3 знач.). Давай поговорим или, лучше всего, помолчим. Как нельзя лучше — очень хорошо, отлично. Дела идут как нельзя лучше. И того лучше (ещё того лучше) (обычно ирон.) — совсем хорошо.
и? какую из форм и применимых оборотов ты имел ввиду? пока не одна не подходит для рассматриваемого вопроса и тем более под твои утверждения...
V>> Как можно сравнивать спецификации космического корабля и одноместного самолета?
VD>Некорректная аналогия. Тут сравниваются спецификации импиративных языков объектно ориентированного программирования общего назначения. Они более чем сравнимы.
Во-первых — разного назначения. (!!! хотя и используют похожие подходы)
Ввиду того, сравнимы только в области пересечения, которая невелика.
V>> Количество потенциальных неувязок в первом случае гораздо больше. VD>Демагогия на базе некорректной аналогии.
уже пояснил свою аналогию, где говорилось о различном назначении, но похожем подходе для достижения целей. Первый случай потенциально опасней, сложней и т.д.
V>>Спецификация C# действительна очень проста,
VD>Для тех кто ее не читал. Рельно она понятна и не противоричива, но не проста. Это довольно объемный и не простой документ. Проста она только в сравнении с запутанной и противоричивой.
Читал внимательно и неоднократно. Она проста не только (не столько) в сравнении со сложной, сколько из-за синтаксиса самого языка и предполагаемой техники компиляции/сборки (!!!). Компилятор C# изначально многопроходный, в идеале — сколь угодно проходный. Компилятор С++ изначально расчитан на ограниченное число проходов (язык организован так, что вполне позволяет обойтись одним — по историческим причинам, ты помнишь мощность своего десктопа в 1990-м? а объем его оперативки? он бы просто не смог скомпилировать более-менее сложную программу на C#)
Если ты в курсе проблем С++, то многие потенциальные неоднозначности как раз связаны с одинаковым синтаксисом объявления и определения. Первой конструкции в C# нет из-за упомянутой техники компиляции.
Далее, C# разработан из предположения, что никак не зависит от архитектуры платформы, на которой исполняется. C# использует общую систему типов, которая не зависит от разрядности применяемой платформы. Многие UB в С++ (ты упоминал их наличие) именно отражают тот факт, что язык С++ предназначен в качестве "родного" для целевой платформы, т.е. должен оперировать родными типами целевой платформы. Явно упомянутые UB отражают те моменты, которые могут быть не переносимы м/у платформами (в виду характера этих платформ).
Хотя, никто не запрещает проводить произвольную реинтерпретацию участков памяти, даже в случае потенциального UB. ПОЧТИ все системные программы очень низкого уровня (дрова и пр.) используют моменты, которые могут быть расцененены как UB в общем случае, но весьма подходят для частной платформы. Тут мы видим наследие языка С, который суть одно сплошное UB , однако в С++ оставлены те же возможности и механизмы их реализаций, что и в С, что позволяет использовать С++ в тех областях, где раньше был применим С (а до него ASM).
В C# возможна реинтерпретация памяти только в p-Invoke, где тоже элементарно получить UB в случае ошибки описания предполагаемой бинарной структуры ожидаемого типа. В самом же C# реинтерпретации памяти нет, в подобных случая применяет конструирование нового объекта требуемого типа — суть копирование памяти. В случае написания системного ПО — шаг весьма сомнительной необходимости.
V>> сам язык гораздо проще. VD>Тоже, скажем, так сомнительное утверждение. Со многих точек зрения C# сложнее С++.
Тоже, скажем, так сомнительное утверждение. Ты неоднократно говорил о том, что C# сложнее С++. Я хочу узнать, наконец, в чем именно? (условия конкурса — речь не о .Net, а именно о C#, предлагаю обсудить возможности тех же дженериков и шаблонов, и посмотреть количество приемов разработки, которые позволяют эти варианты, причем на С++ будут рассматриваться только варианты без UB )
VD>При том. Качественнее. На меньшем количестве страниц дано более сбалансированное и логичное описание. Нет такого количества пробелем и т.п.
Тааак, вот это мы приплыли. Качество ПО — это степень соответствия его требованиям.
Качество ПО (Вендров, Липаев)
совокупность свойств ПО, к-рые характеризуют способность ПО
удовлетворять заданным требованиям.
или еще более общее определение:
Качество (Розова, "Упрвление качеством")
совокупность характеристик объекта, относящихся к его способности
удовлетворять обусловленные или предполагаемые потребности.
...Каждая потребность выражается рядом требований, которые
участвуют в формировании отношений пригодности объекта
для целей потребителя, служат для оценки соответствия
объекта его назначению...
Требования к качеству (Розова, "Управление качеством")
* можно определить как выражение определенных потребностей или
их перевод в набор количественно или качественно установленных
требований к характеристикам объекта с целью их воплощения в
объекте
V>>Спецификация VB.Net еще проще... VD>Опять неправда. Спецификация VB.Net приблизительно равна по объему и сложности Шарповой.
Она чуть-меньше, но сути это не меняет. Речь о том, что существуют языки с еще меньшей спецификацией, но это не говорит о том, что они "лучше" или "хуже". (уверен, что спецификация языка LOGO меньше. Спецификация того Basic, что был на ZX-Spectrum еще меньше и т.д. Сказать, что эти языки некачественные — некорректно. Они отлично отлично соответствовали своим требованиям и являлись лучшим из вариантов в своей области применения)
VD>Вот тут Re[16]: Качество стандар
ты выступал за обоснование любых утверждений. В данном сообщении ты наделал кучу ничем не подтвержденных (а реально ошибочных) утверждений. Поробуй их обосновать. Ну, ради хохмы.
Тебе бы все хохмить. Чтобы утверждать ошибочность утверждений, надо их хотя бы пытаться опровергать.А если же просто не согласен, можно ограничиться постом "не согласен". Или минусы ставить.
Здравствуйте, VladD2, Вы писали:
VD>Сравнил количество страниц занимаемых граматиками языков. VD>
VD>C++ 685-667 = 18
VD>C# 461-433 = 28
VD>
VD>Так что на языке сухих цифр C# на 30% сложнее C++. VD>А народ с дури думает, что Шарп учить проще.
Влад, ты же разбираешься в этом вопросе, а жонглируешь...
Ты забыл оценить мощность порождаемого грамматикой множества выражений.
Все зависит от грамматики (от характера правил). Чем больше в ней ограничений (и больше ее размер), тем меньше может быть мощность допустимых выражений (и тем проще учить язык).
-------
Изучить язык — это не столько выучить грамматику, сколько научиться "разбирать" или "порождать" выражения языка.
-------
Потрачу на досуге время, посмотрю как именно описаны грамматики. (может, в случае С++ была возможно ввести больше промежуточных обощающих символов, и потому удалось компактней ее записать, а в C# есть доп. ограничивающие ключевые слова, делающие это невозможным)
Здравствуйте, vdimas, Вы писали:
V>Влад, ты же разбираешься в этом вопросе, а жонглируешь... V>Ты забыл оценить мощность порождаемого грамматикой множества выражений.
Здравствуйте, vdimas, Вы писали: V>Влад, ты же разбираешься в этом вопросе, а жонглируешь... V>Ты забыл оценить мощность порождаемого грамматикой множества выражений.
Здравствуйте, vdimas, Вы писали:
V>Компилятор C# изначально многопроходный, в идеале — сколь угодно проходный. Компилятор С++ изначально расчитан на ограниченное число проходов (язык организован так, что вполне позволяет обойтись одним — по историческим причинам, ты помнишь мощность своего десктопа в 1990-м? а объем его оперативки? он бы просто не смог скомпилировать более-менее сложную программу на C#)
Какой из этого следует вывод?
V>Тут мы видим наследие языка С, который суть одно сплошное UB , однако в С++ оставлены те же возможности и механизмы их реализаций, что и в С, что позволяет использовать С++ в тех областях, где раньше был применим С (а до него ASM).
Какой из этого следует вывод?
V>В C# возможна реинтерпретация памяти только в p-Invoke,
И в unsafe mode.
V> где тоже элементарно получить UB в случае ошибки описания предполагаемой бинарной структуры ожидаемого типа.
Например? Особенно интересны элементарные случаи. На всякий случай — P/Invoke это safe механизм.
VD>>Тоже, скажем, так сомнительное утверждение. Со многих точек зрения C# сложнее С++. V>Тоже, скажем, так сомнительное утверждение. Ты неоднократно говорил о том, что C# сложнее С++. Я хочу узнать, наконец, в чем именно?
Например в количестве стандартных синтаксических конструкций. А ты думал что С++ во всем сложнее щарпа? На всякий случай — я не утверждаю что один язык безоговорочно сложнее другого, это утверждение неверно в оба конца.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Посмотрел в стандарт 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
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
заметил, что один интересный пункт пропустил.
> Возьмем например экспорт шаблонов. Чистейшей воды профанация, так как как их не экспортируй, а проблемы шаблонов и препроцесор не позволяют создать приемлемой промежцточной формы для подобного экспорта.
> ПК> Позволяют. Хотя я вполне разделяю скептическое отношение к экспорту шаблонов.
> Чтобы они действительно позволяли, нужно серьезно ограничить шаблоны.
Пожалуйста, перечисли, что именно не позволяет в шаблонах создать приемлемую промежуточную форму, и что является приемлемой промежуточной формой?
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, 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
Здравствуйте, 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#. Там они просто вмешиваются в работу компилятора и "вручную" обрабатывают некоторые из указанных конструкций, изымая их из входной последовательности разборщика. сам же разборщик более похож на реализацию КС грамматики.
Это как раз то, что в твоем определении называлось "Мягко контекстно-зависимые грамматики".
Спасибо
> Павел, всегда хотел спросить, были ли тобой ранее прочитаны все источники из которых ты приводишь цитаты или ты их изыскиваешь перед написанием поста?
По-разному. В данном случае заранее мне были хорошо известны все "источники", кроме конкретных сообщений разработчиков VC++ в группах новостей и записей интервью. Но так как все то же самое я читал ранее в пересказах третьих лиц, плюс пол-года назад услышал это же от некоторых из них лично, то оставалось только найти какую-нибудь открытую информацию, которая не могла не найтись
> И еще очень интересно сколько суммарно было затрачено времени на составление ответа?
Больше, чем мне того хотелось так как в таких дискуссиях обычно все остаются при своих. Думаю, часа два писал...
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, vdimas, Вы писали:
V>>Я бы ввел обязательную спецификацию исключений.
AVK>Вот в джаве такое сделали. В результате большинство современных фреймворков используют исключения, отнаследованные от RuntimeException, которые специфицировать не надо.
да, тут даже не столько в спецификации исключений дело, сколько в единой объектной иерархии этих исключений.
В С++ с этим бардак, надо признать. Каждый С++ фреймворк начинается с того, что народ описывает свою собственную иерархию ексепшенов. Совместное использование этих фреймворков — это нечто
(все это решаемо, разумеется, но за отдельную плату)
но это практически единственное, что мне не хватает в С++. Все остальное либо есть, либо достижимо, причем с небывалой степенью гибкости.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В самом деле, если размер машинного слова не ложится на размеры целых типов CLI, то очевидно, что работа с целыми в C# не будет прямой работой с платформой.
Можно узнать про эти платформы и эти типы?
Напомню, в Шарпе есть: byte (1 байта), short (2), int (4), long (8). Можно узнать о типах C/C++ которые не покрываются этими виличинами.
ПК> И подобный выбор очень хорошо иллюстрирует то, что C#, в отличие от C++, и близко не предназначен для замены использования C или, тем более, ассемблера.
Без обоснования первого утверждения, для меня все эти слова выглядят, как попытка притянуть "аргументы" за уши.
ПК>Я не утверждаю, что это плохо. Просто это демонстрирует разницу в целях, которые ставили перед собой разработчики C# и C++.
А я утверждаю, что введение зависимости между машинным словом и размером int-а была сделана в целях оптимизации, что никак не относится к переносимости, и на сегодня (учитывая интеллект компиляторов) не актуально.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>То что Ява и дотнет имеют лучшую переносимость нежели С++, и то что обе этих платформы признали зависимость размеров типов от платформы является отличным косвенным подтверждением ошибочности этого утверждения.
что-то ты все ставишь с ног на голову, меняешь причину и следсвие.
для обеспечения переносимости м/у платформами пришлось зафиксировать представление базовых типов.
Продолжая в твоем же духе — производители компьютеров гонят по-черному, выпуская аппаратуру с разной разрядностью, и, какая нелепость, с разной системой команд. Этот досадный факт делает применение С++ на этих платформах необоснованным решением. Ты уж тогда оставь С++ в покое, собери производителей железок и заставь их делать все по одной некой образцовой архитектуре. Правда, (ой блин) надобность в дотнете сама собой отпадет.
----
чуство нелепости этого спора не покидает, скорее обостряется
----
типы CLI зафиксированы так, чтобы дать наибольший выигрыш на Win32 платформе. Посмотрим сравнение быстродействия С++ и дотнета на остальных платформах. Дотнет же ради переносимости разработан, вполне корректно будет сравнивать результаты именно на разных платформах.
Здравствуйте, vdimas, Вы писали:
ГВ>>Дима, спасибо за поправку. Естественно, я тусуюсь тут того, чтобы не допустить такого вреда. V>Спасиб за компанию!
Хм. Кстати, хорошая мысль. Как насчёт субботы?
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Дима, спасибо за поправку. Естественно, я тусуюсь тут того, чтобы не допустить такого вреда. V>>Спасиб за компанию! ГВ>Хм. Кстати, хорошая мысль. Как насчёт субботы?
Господа, личные вопросы стоит обсуждать по e-mail.
Здравствуйте, vdimas, Вы писали:
VD>>То что Ява и дотнет имеют лучшую переносимость нежели С++, и то что обе этих платформы признали зависимость размеров типов от платформы является отличным косвенным подтверждением ошибочности этого утверждения.
V>что-то ты все ставишь с ног на голову, меняешь причину и следсвие.
V>для обеспечения переносимости м/у платформами пришлось зафиксировать представление базовых типов.
Я ничего никуда не ставлю. Можно сказать и так. Но это только одна из предпосылок к подобному решению. Реально фиксация типов данных была сделана исходя из разных соображений. Одно из них было — упрощение восприятия программ людьми.
V>Продолжая в твоем же духе — производители компьютеров гонят по-черному, выпуская аппаратуру с разной разрядностью, и, какая нелепость, с разной системой команд. Этот досадный факт делает применение С++ на этих платформах необоснованным решением. Ты уж тогда оставь С++ в покое, собери производителей железок и заставь их делать все по одной некой образцовой архитектуре. Правда, (ой блин) надобность в дотнете сама собой отпадет.
Это демагогия. И не надо говорить, что она аналогична моим словам.
V>типы CLI зафиксированы так, чтобы дать наибольший выигрыш на Win32 платформе.
Ничем не обоснованное утверждение. Более того дотнет проектировался с прицелом как на 64-разнядные системы, так и на другие платформы. На том же Линуксе Моно себя чувствует ни чем не хуже.
V> Посмотрим сравнение быстродействия С++ и дотнета на остальных платформах. Дотнет же ради переносимости разработан, вполне корректно будет сравнивать результаты именно на разных платформах.
Вот когда выйдут нормальные вируальные машины на 64-битные платформы тогда и глянем. А на линуксе у Моно такой же код. Так что и производительность отличатся не должна.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Важно уточнить, что при этом размер байта в C# фиксирован, и равен 8 битам. В C/C++ такого ограничения нет.
> C/C вообще нет типа byte. Ну, да не в том дело.
Как в стандарте C, так и в стандарте C++ есть понятие байта. В соответствии со стандартами C и C++ байту соответствуют типы char, signed char, и unsigned char.
> ПК> И дело тут вовсе не в оптимизации, а в самом предназначении языка для системного программирования, каковое вряд ли можно представить без наличия типа, непосредственно соответствущего машинному слову, равно как и типа, представляющего минимально адресуемую единицу памяти.
> Да, можно представить. Особенно на сегодня. Для языка уже не так вазно машинное слово.
Для системного — все так же. Именно о слабой пригодности C# для этих целей и шла речь. Например, вряд ли получится использовать даже unsafe режим C# для реализации даже тех же целочисленных типов самого C# (Int32 и т.п.) на платформе, где машинное слово не является степенью двойки, а байт не равен 8.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, vdimas, Вы писали:
V>видел и .Net 2.0, однако отсутствие конструкции типа typedef делает невозможным примерно 70% шаблонного программирования (не могу в классе указать зависимый тип, т.е. все traits и стратегии — лесом). Отсутствие возможности отнаследоваться от параметра шаблона отнимает еще примерно 20% (имеплементация аспектов интерфейсов).
Просто писать нужно по другому. Взмен того от чего отказались в Шаблонах даны не менее интересные фишки вроде параметризованных делегатов, интерфейсов и абстрактных классов.
Как я понимаю, дженерики намеренно уводят от макросоподобия навязывая ОО-стиль и компонентый подход. Те же стратегии отлично реализуются дженерик-делегатами или дженерик-интерфейсами. Получается несколько подругому, но это не значит что хуже.
Вот чего точно нет в C# 2.0, так это основанного на шаблонах метапрограммирования. Но эту проблему как раз решит R# и другие средства АОП и метапрограммирования. Я уже сейчас делаю на R# вещи недоступные или крайне сложно реализуемые на С++. Например, вот пилотный вариант реализации паттерна Visitor на R#-е
.
V>В 1.0 и 1.1 имплементация интерфейсов — вообще полные мраки... туши свет, кидай гранату.
(в плане мозолей на пальцах)
Вообще-то в VS2003 — это можно сделать автоматически. А в VS2005 вообще смарт-тэг на имени интерфейса вылезает и можно сделать как явную, так и не явную реализацию.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, а там где от С есть толк этот езяк еще долго будет использоваться. Возможно даже совместно с новыми более надежными и простыми в испльзовании средствами.
Я не вижу ни одной причины использовать С на данный момент. Крупные системы на С — это те, которые относительно давно ведут свой отчет.
Для маленьких встраиваемых систем сейчас сущестует EC++, где убрали множественное наследование, динамик каст и т.д.
Здравствуйте, vdimas, Вы писали:
V>Насчет синтаксиса C# 2.0 вынужден согласиться, там наворочено много чего, возможно нужна КЗ-грамматика, я имел ввиду 1.0 — 1.1
Ну, слава богу, хоть так. Хотя бы частичное признание очевидных вещей отдельными личностями...
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Я смотрел в роторе компилятор C#. Там они просто вмешиваются в работу компилятора и "вручную" обрабатывают некоторые из указанных конструкций, изымая их из входной последовательности разборщика. сам же разборщик более похож на реализацию КС грамматики.
О! Вот теперь я слышу разумные слова. Так оно и есть. Граматика Шарпа — это КСГ, но с набором исключений. Все эти исключения описаны в стандарте и предложены пути разрешения.
Точно так же приходится разрешать их и в парсере R#-а. Собственно я их и приводил.
ЗЫ
Кстати, не в курсе нет ли еще Ротора 2.0? Ну, на базе второго фрэймворка?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Как в стандарте C, так и в стандарте C++ есть понятие байта. В соответствии со стандартами C и C++ байту соответствуют типы char, signed char, и unsigned char.
Понятие не есть тип. Кстати, поискал по стандарту, но так и не нашел где определялся бы размер char/unsigned char. Что весма забавно.
ПК>Для системного — все так же.
Да не так же. И процессоры стали более стандартными. И понятие системности размылось. И акценты важности сместились. На сегодня зачастую бывает важнее факторы надежности и переносимости. А размеры типов они все же относятся именно к опримизации.
ПК> Именно о слабой пригодности C# для этих целей и шла речь. Например, вряд ли получится использовать даже unsafe режим C# для реализации даже тех же целочисленных типов самого C# (Int32 и т.п.) на платформе, где машинное слово не является степенью двойки, а байт не равен 8.
Во-первых, на сегодны такие платформы еще поискать нужно. А экзотика смело поживет на С.
Во-вторых, опять же не трудно реализовать все что нужно внутри виртуальной машины, которая может быть хоть на ассемблере быть написана.
В общем, если речь идет о возможности написания ОС на управляемых средах, то это более чем возможно. Более того Ява-ОС уже была создана. И на Обероне (который в данном случае близок к Яве и дотнету) тоже ОС имеется.
Я себе такое вижу следующим образом. На С или ассемблере пишется микроядро в которо на которое ложатся задачи начальной загрзки, джит-компиляции, управление памятью и оптимизации получаемого машинного кода под конкретную платформу. Остальное пишется на управляемом языке. За счет отсутствия указателей проблем с их размерами не будет. А конкретные программы оперируют привычными ими типами. Для общения с железом пишется прослойка которая может обращаться к ядру в тонких случаях.
ЗЫ
В общем, технически тут особых проблем не будет. Тут скорее вопрос целесобразности и вопрос традиций/имеющегося кода. Думаю, пройдет лет 10 и ОС состоящие на 90-99% из менеджед-кода станут повседневной реальностью.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
VD>>Реально фиксация типов данных была сделана исходя из разных соображений. Одно из них было — упрощение восприятия программ людьми.
V>еще пара таких высказываний и я буду собирать подписи за открытие храма Билла-Безвоздмездного в Севастополе
Начинай. Типы зафиксировали еще в Яве. Не думаю, что он приложел к этому руку.
V>>>Продолжая в твоем же духе — производители компьютеров гонят по-черному, выпуская аппаратуру с разной разрядностью, и, какая нелепость, с разной системой команд. Этот досадный факт делает применение С++ на этих платформах необоснованным решением. Ты уж тогда оставь С++ в покое, собери производителей железок и заставь их делать все по одной некой образцовой архитектуре. Правда, (ой блин) надобность в дотнете сама собой отпадет.
VD>>Это демагогия. И не надо говорить, что она аналогична моим словам.
V>Это прямое следсвие твоих рассуждений.
Это всего лишь демагогия.
V>Во-первых, моно чуствует себя немного хуже даже на Win32 платформе. Во вторых, я некорректно выразился. Я имел ввиду Intel32.
Гы. Как раз Вынь32 был еще хот чем-то. А Intel32 совсем мимо кассы. Есть куча КПК на которых крутится дотнет. Ява вообще 70% мобильников захватила. Там Интелом и не пахнет. Ну, а 32... что-же похоже это самое разумное количество бит для процессора предназначенного в частное пользование.
V>Где там ориентация на 64 бита?
Ну, хотя бы она в том, что реально в бехопасном режиме без указания расположения полей ни кто не мешает разработчикам фрэймворка плевать на указанные велечины и делать int 64-битным. Проверели, что код не работает на уровне битов и наплевали... Указатели уже автоматичски становятся 64-битными. Так что проблем просто-таки никаких.
Кстати, в Вынь64 int вроде как остается 32-битным, так что с указателями прийдется повозиться. Весь Вынь-ориентированный С++-ный код прийдется серьезно проверить, так как проблем в нем может оказаться не мало. А вот код на Шарпе гарантированно будет работать. И при наличии хорошо оптимизированной VM будет работать очень шустро.
V> все коллекции имеют индекс типа int. Да и вообще, int — наиболее употребимый тип (он же System.Int32).
Ни одна коллекция не сможет вместить в себя и 2 миллиарда объектов, так как их алгоритмы просто на это не рассчитаны. Массивы же имеют 64-битную индексацию (погляди класс Array там есть как 32-х, так и 64-битные методы). Можеш даже провести эксперемент. Создай вот такой код:
class Program
{
static void Main(string[] args)
{
long i = 123;
byte[] a = new byte[i];
}
}
Скомпилируй его. И дезасемблируй. Получишь нечто вроде:
Главная инструкция здесь выделена жирным. Она конвертирует лезащее на вершине стека числов в так называемый "natural int". Это нечто аралогичное int в С. Таким образом если мы будет работать на 64-битной платформе, то будет роизведена попытка конвертации к int64, а на 32-битной соотвественно в int32.
В общем, дотнет построен по принципу ты пишешь программу, а она работает на любой платформе. Ты как бы пишешь нужную тебе программу, а CLR обеспечивает оптимальное исполнение на заданной платформе. Программа не становится другой на 64-битной платформе. Она просто получает возможность создать больше объектов (если больше памяти есть) и более эффективно работать с 64-битными числами. В общем, подход заточеный на максимальную переносимость того что есть, а не на масимальную но гипотетическую возможность оптимизации. Всю оптимизацию берет на себя фрэймворк.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Я не вижу ни одной причины использовать С на данный момент. Крупные системы на С — это те, которые относительно давно ведут свой отчет.
Гы. Вот там и используется. А причины банальны. С — это элементарнийший язык. Транслятор для него можно написать на ассемблере за довольно короткий строк (темболее, что для этого достаточно заменить бэкэнд). И этого языка достаточно для системной части.
V>Для маленьких встраиваемых систем сейчас сущестует EC++, где убрали множественное наследование, динамик каст и т.д.
Ну, посчитай сколько ОС и драйверов написано на нем, а сколько на С.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Как в стандарте C, так и в стандарте C++ есть понятие байта. В соответствии со стандартами C и C++ байту соответствуют типы char, signed char, и unsigned char.
> Понятие не есть тип.
В C/C++ char — это и есть тип, обозначающий байт. Просто назван по-другому.
> Кстати, поискал по стандарту, но так и не нашел где определялся бы размер char/unsigned char. Что весма забавно.
5.3.3 Sizeof
The sizeof operator yields the number of bytes in the object representation of its operand. <...> sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1 <...>
> На С или ассемблере пишется микроядро <...>
Вот это и есть пример той задачи, для которой C#, в отличие от C или C++ не подходит, и о которых шла речь.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Шахтер, Вы писали:
VD>>Да не так же. И процессоры стали более стандартными.
Ш>В порядке самообразования. Зайди на сайты Texas Instruments и Motorola и скачай доки по их процам разных семейств. И почитай на досуге.
Да ты не стесняйся, приводи конкретные примеры современных микроконтроллеров, у которых байт не равен 8 битам.
Здравствуйте, VladD2, Вы писали:
V>>Я не вижу ни одной причины использовать С на данный момент. Крупные системы на С — это те, которые относительно давно ведут свой отчет.
VD>Гы. Вот там и используется. А причины банальны. С — это элементарнийший язык. Транслятор для него можно написать на ассемблере за довольно короткий строк (темболее, что для этого достаточно заменить бэкэнд). И этого языка достаточно для системной части.
Разве это причина? Причина в том, что эти системы начинались разрабатываться тогда, когда еще не было стандартов С++ и даже этого компилятора на многих аппаратных платформах.
V>>Для маленьких встраиваемых систем сейчас сущестует EC++, где убрали множественное наследование, динамик каст и т.д.
VD>Ну, посчитай сколько ОС и драйверов написано на нем, а сколько на С.
Windows уже давно пишут на С++. WinXP многие свои новые API вообще выдает как COM-объекты.
Дрова для видюх под винды, поддерживающие DirectX, тоже нереально писать без C++ (можно, но затрахаешься).
Здравствуйте, VladD2, Вы писали:
V>>В 1.0 и 1.1 имплементация интерфейсов — вообще полные мраки... туши свет, кидай гранату. VD>(в плане мозолей на пальцах)
VD>Вообще-то в VS2003 — это можно сделать автоматически.
автоматически он создаст заголовки этих ф-ий, от этого не легче.
Здравствуйте, vdimas, Вы писали:
VD>>Вообще-то в VS2003 — это можно сделать автоматически. V>автоматически он создаст заголовки этих ф-ий, от этого не легче.
А тебе чего надо? Если нужна реализация, то для этого есть абстрактные классы, ибо нефиг заниматься копипейстом.
Здравствуйте, Шахтер, Вы писали:
Ш>В порядке самообразования. Зайди на сайты Texas Instruments и Motorola и скачай доки по их процам разных семейств. И почитай на досуге.
Это не те ли где сейчас Ява крутится?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, vdimas, Вы писали:
VD>>>Вообще-то в VS2003 — это можно сделать автоматически. V>>автоматически он создаст заголовки этих ф-ий, от этого не легче.
AVK>А тебе чего надо? Если нужна реализация, то для этого есть абстрактные классы, ибо нефиг заниматься копипейстом.
ибо если к уже имеющемуся классу захочу подмешать интерфейс — обломаюсь.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Шахтер, Вы писали:
VD>>>Да не так же. И процессоры стали более стандартными.
Ш>>В порядке самообразования. Зайди на сайты Texas Instruments и Motorola и скачай доки по их процам разных семейств. И почитай на досуге.
AVK>Да ты не стесняйся, приводи конкретные примеры современных микроконтроллеров, у которых байт не равен 8 битам.
Здравствуйте, vdimas, Вы писали:
V>Разве это причина?
Ага.
V> Причина в том, что эти системы начинались разрабатываться тогда, когда еще не было стандартов С++ и даже этого компилятора на многих аппаратных платформах.
А это нет. Темболее что NT и Линукс разрабатывались в начале 90-ых. С++ тогда уже был.
V>Windows уже давно пишут на С++.
Никгда системные части Виндов не писались на С++. Погляди примеры к DDK и т.е.
V>WinXP многие свои новые API вообще выдает как COM-объекты.
Одно другому не мешает.
V>Дрова для видюх под винды, поддерживающие DirectX, тоже нереально писать без C++ (можно, но затрахаешься).
Не вижу связи. DirectX работает поверх дров с С-ишным АПИ.
В общем, погляди тут рядом есть рассуждения как раз тех кто проффесионально пишет дрова. У них вообще вопрос "зачем нужен С++?" встает.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
VD>>Вообще-то в VS2003 — это можно сделать автоматически. V>автоматически он создаст заголовки этих ф-ий, от этого не легче.
Вообще-то от этого значительно легче (с точки зрения мазолей).
Ну, а радикальное уменьшение мазолей можно найти здесь
Здравствуйте, AndrewVK, Вы писали:
AVK>А тебе чего надо? Если нужна реализация, то для этого есть абстрактные классы, ибо нефиг заниматься копипейстом.
Известно чего. Множественного наследования или микс-инов.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Шахтер,
> AVK> Внимательно изучил. Где там написано что байт не равен 8 битам?
> Процессоры семейства Motorola 563xx оперируют с 24 битовыми (или 16 битовыми в 16 битовом режиме) словами. 8 битовые данные они ни адресовать, ни обрабатывать непосредственно не могут.
> Я надеюсь, ты по-английски читать умеешь.
> — although the char type is 8 bit, each char occupies one memory word, because the DSP56xxx has no instructions to access one byte efficiently.
Напомню, что, как верно заметил Шахтер в другом сообщении, это стандарту не соответствует. В соответствующем стандарту компиляторе был бы как раз 24/16-битовый char, т.е. соответствующий платформенному байту.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Напомню, что, как верно заметил Шахтер в другом сообщении, это стандарту не соответствует. В соответствующем стандарту компиляторе был бы как раз 24/16-битовый char, т.е. соответствующий платформенному байту.
Паша, ты правда не понимаешь отличия между байтом и словом?
Здравствуйте, AndrewVK, Вы писали:
ПК>>Я-то вполне понимаю. Но подозреваю, что у нас с тобой терминология немного отличается. Я приведу определение "моего" байта, а ты, если хочешь, можешь привести определение "твоего". ПК>>Байт (в терминах стандартов C и C++) — минимально адресуемая единица памяти. Кроме того, у байта (в терминах стандартов C и C++) все биты значащие. Байт (в терминах стандартов C и C++) может быть любого размера, не только 8 бит. AVK>
AVK>Байт
AVK>Материал из Википедии — свободной энциклопедии
AVK>Байт м. скл. — единица измерения информации, равная восьми (первоначально шести) битам, может принимать 28 различных значений. Название было впервые использовано в 1956 году В.Бухгольцем при проекторовании первого суперкомпьютера IBM 7030 для пучка одновременно передаваемых в устройствах ввода-вывода битов (шести штук), позже в рамках того же проекта расширили байт до восьми (23) бит.
Всё-таки, байт — это 6 или 8 бит?
AVK>
AVK>Машинное слово
AVK>Материал из Википедии — свободной энциклопедии
[skip]
Никто не будет спорить с наличием широкораспространённой трактовки "байт = 8 бит". И только. Стандарт C++ чётко определяет это понятие в терминах, которые могут быть адекватно трактованы на любой платформе — и с 4-х битовым байтом, и с 9-битовым.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Шахтер, Вы писали:
Ш>Я тут прошелся по одному знаменитому архивчику. Там набралось 2255 *.cpp файлов общей длинной 1763618 строк кода. Так что твоё утверждение об очень маленькой части не соответствует действительности.
Речь шла о дравах или ядре. Пошарься еще рез.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Никгда системные части Виндов не писались на С++. Погляди примеры к DDK и т.е.
не путай интерфейс с реализацией.
Windows предоставляет функциональный API, понятный остальным языкам.
V>>WinXP многие свои новые API вообще выдает как COM-объекты. VD>Одно другому не мешает.
видать, ты не писал COM объекты на С. На это не пойдет ни один руководитель ни одного отдела, и в MS тоже.
V>>Дрова для видюх под винды, поддерживающие DirectX, тоже нереально писать без C++ (можно, но затрахаешься).
VD>Не вижу связи. DirectX работает поверх дров с С-ишным АПИ.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Шахтер, Вы писали:
Ш>>Windows состоит не только из ядра и драйверов.
V>а оконная система и реестр там на чем?
Не знаю. В этом архиве только 1/5 кода и искать что к чему относится в этом массиве -- мягко говоря неблагодарное занятие. Я смотрел бегло только WinSock, там значительная часть на C++.
Здравствуйте, vdimas, Вы писали:
AVK>>здесь
V>не выход для полномасштабного применения, в проекировании на это никто и никогда забиваться не будет, хотя вполне реально использовать в немногочисленным местах где "сильна нада".
Ага. Вот такие, ничем не подкрепленные, отмазки всегда применяются чтобы выдать желаемое за действительное.
Почитай статьи по Яве, там подобные технологии используются уже очень широко. В качестве ключевых слов: AOP, Spring.
Заметь, что применяются все это в огромных коропоративных проектах.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ArtDenis, Вы писали:
AD>Здравствуйте, Шахтер, Вы писали:
Ш>>Я надеюсь, ты по-английски читать умеешь. Ш>>- although the char type is 8 bit, each char occupies one memory word, because the DSP56xxx has no instructions to access one byte efficiently.
AD>Пример некорректный. Этот перевод говорит только лишь о том, что такие процессоры могут работать лишь с данными, выравненными по границе слова.
Ещё один обскурант нарисовался. Прежде чем выступать, познакомься с предметом. И заодно подучи английский.
было:
Ш>Процессоры семейства Motorola 563xx оперируют с 24 битовыми (или 16 битовыми в 16 битовом режиме) словами. 8 битовые данные они ни адресовать, ни обрабатывать непосредственно не могут.
Ш>- although the char type is 8 bit, each char occupies one memory word, because the DSP56xxx has no instructions to access one byte efficiently.
У меня замечание не по существу, а из вредности.
Если всему написанному верить, имеем "24-битовый байт", "24-битовое слово" и тем не менее "no instructions to access one byte efficiently".
А ведь если как следует разобраться в вещах, добавленных в стандарт на завершающих сроках составления спецификации, и представить себе стоимость их реализации при учете древней архитектуры компилятора, да еще осложненной множеством заплаток в результате периодических адаптаций к черновикам стандарта, все будет выглядеть далеко не так радужно... И если взглянуть на моменты, в которых VC++ расходится со стандартом, то можно обнаружить, что это как раз те самые вещи, которые хуже всего вписываются в архитектуру, разрабатывавшуюся без их учета.
Перекуём баги на фичи!
