Re[27]: Компиляторы и стандарты
От: Павел Кузнецов  
Дата: 20.11.04 10:37
Оценка: 187 (20)
VladD2,

я тебя убедительно прошу читать сообщения целиком, до того, как ты начинаешь отвечать. Иначе вести беседу с тобой чрезвычайно затруднительно, т.к. по ходу составления ответного сообщения ты задаешь множество вопросов, ответы на которые ты мог бы получить, прочитав один-два следующих абзаца.

Кроме того, так как сообщения разрослись до сложнопотребляемых размеров, в этом я касаюсь только вопросов соответствия компиляторов стандарту. Ответы на сравнения с другими языками пойдут в другое сообщение, которое я напишу позже. Сюда вопросы сравнения языков, пожалуйста не примешивай — а то совсем каша, а не обсуждение получается.

> ПК> С 1998.


> Не, с 89-го. 98 — это дата выхда последнег стандарта.


Первого. Вторая версия того же стандарта, она же пока последняя, вышла в 2003 году.

> А 89-ых — это год когда появились шаблоны и вообще язык можно было назвать состоявшимся.


Назвать язык C++ образца 89-го года состоявшимся (если понимать под этим совпадение с современным C++) — по меньшей мере, сильное преувеличение:
Подобная эволюция и является причиной многих трудностей разработчиков по приведению своих компиляторов в соответствие со стандартом, т.к. многие архитектурные решения те, кто взялись за реализацию компиляторов C++ еще в те времена, принимали на основании дизайна языка, очень сильно упрощенного по сравнению с современным. А некоторые, как Майкрософт, унаследовали общую архитектуру своих компиляторов еще от компиляторов C, имевших к тому моменту свою историю.

А если посмотреть на функциональность, добавлявшуюся к языку после начала процесса стандартизации, то можно увидеть, что именно интеграция этих новых возможностей (пространства имен, ADL, перегрузка, частичная специализация и перегрузка шаблонов и т.п.), привела к значительному усложнению языка, делая его тем монстриком, которым он является сегодня. Причем поэтапное добавление этих моментов далеко не всегда во всех деталях можно было гладко вписать в архитектуру существовавших компиляторов, что приводило ко все новому и новому усложнению их реализации и внесения последующих изменений...

>>> ПК> В Microsoft до недавнего времени на стандарт плевали с высокой колокольни, и занялись поддержкой оного, когда увидели, что это становится, действительно, важным для их пользователей.


>>> Да то, что это важно для пользователей они поняли еще гду в 90-ом.


> ПК> Откуда дровишки?


> Да из появления VC. А вот откуда твои дровишки? Кто тебе сказал, что они не хотели совместимости? Может они просто не в сила были ее обеспечить...


Ну это зависит от того, кто "они", и что понимать под "не в силах были ее обеспечить". Итак по пунктам:
  1. "Они"...

    Если под "они" понимать Майкрософт в целом, то для компании Майкрософт совместимость со стандартом где-то до релиза 7.0 была на одном из последних мест в списке приоритетов, т.к. у компании было несколько очень крупных клиентов, для которых обратная совместимость была намного важнее.

    Если же под "они" подразумевать, скажем, команду разработчиков компилятора, то тут, вообще, можно целую книгу написать о любви и ненависти разработчиков Майкрософт к стандарту. Книга строилась бы по принципу ромашки: "Любит — не любит, любит — не любит, любит..."

    Вкратце: изначально разработчики Майкрософт бросились к стандарту в объятья. Тут можно упомянуть и то, что вторая встреча комитета стандартизации проводилась в помещении Microsoft в июле 1990, и то, что они оперативно отслеживали изменения в стандарте, и с энтузиазмом реализовывали самые новые "фичи"...

    Однако это обернулось для них боком, когда несколько раз случилось так, что комитет отменял или изменял только что реализованные разработчиками Майкрософт аспекты языка. Доходило даже до того, что изменения происходили после релиза Майкрософтом очередной версии (так, например, случилось с изменениями в поиске имен вскоре после выхода версии VC++ 5.0).

    В итоге примерно ко времени разработки версии 6.0 энтузиазм разработчиков по поводу быстрого отслеживания развития стандарта серьезно поутих. К тому же, как уже раньше писалось, у ребят и без того была масса работы по развитию компилятора и среды. Дошло даже до того, что, как тоже упоминалось выше, Майкрософт была лишена права голоса в комитете из-за пропуска нескольких заседаний комитета (а это немало, учитывая, что встречи проводятся всего два раза в год).

  2. "не в силах были ее обеспечить"...

    Эта фраза вполне подходит к ситуации, в которой оказалась Майкрософт, когда дело дошло до выпуска 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++.

> ПК> В качестве посылки ты используешь недоказанное утверждение. А именно: "язык особой сложности не представляет".


> Назови мне хотя бы один технический критерий по которому он сложнее всех остальных если отбросить запутанность и неопределенность.


Пожалуйста, целый букет, в котором многие пункты служат множителями друг к другу в плане сложности реализации:
И т.д., и т.п. — картинку можно усложнять далее по вкусу.

В общем, многие "фичи" по отдельности сами по себе не очень сложны, но вот их взаимодействие, действительно очень сильно усложняет общую картину...

>>> Буст, Локи используют побочные эффекты этой спецификации которые она даже не декларировала.


> ПК>А именно? Конкретные примеры, пожалуйста. А то, что-то с телепатией у меня уже совсем плохо...


> Да все ты прекрасно понимашь. Эмуляция функцинальных вычислений на базе эффекта рекурсивного определения шаблона со

специализацией вместо граничного условия — это как? Задумывалось ли стандартом такое поведение? Где в С++ вообще хоть слово о возможости вычислений в компайл-тайме (кроме как инициализации константными выражениями)?

А зачем для этого какие-то дополнительные слова? Достаточно спецификации, которая это все сознательно позволяет, а каждое использование не опишешь, да и не надо это. Во время написания стандарта многие вещи с шаблонами уже были известны. Часть открыли после, но это, имхо, только логично, что пользователи языка разрабатывают новые техники его использования.

>>> 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
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.