Темная сторона КСА УВД Галактика

Встречаются два программиста — один пишет на Си, другой на Ада. Си-программист говорит: — Я буду бифштекс с луком

Анекдот понятный только для тех программистов, кто в теме )

КСА УВД Галактика, ADA, Си, C++

Отображение воздушной обстановки на экране диспетчера. Какое программное обеспечение скрыто за монитором?

Разработка программного обеспечения для промышленных систем становится более профессиональной. На рынке становится все меньше поделок под MS Windows, широко используются клиент — серверные решения. Unix — подобные операционные системы, такие как Linux, уже ни у кого не вызывают снисходительной усмешки. Военные заказчики также смирились с тем, что никаких бюджетов (в первую очередь американских) не хватит для собственной разработки базовых программных технологий, и скрепя сердце согласились с тем, что их придется брать с открытого коммерческого рынка — все то, что обозначается краткой абревиатурой COTS.

Модель разработки Open Source доказала свою жизнеспособность, и корпоративные программисты сейчас ломают головы, как использовать лакомые куски уже наработанного открытого кода и не нарушить условия лицензии GPL в своих разработках. Появился выбор инструментов и сред разработки, также появилось большое количество новых языков программирования. До этого в отечественной истории, в частности в разработке средств управления воздушным движением, принимали любые разработки — и на этом спасибо.

Новые времена — от победы любой ценой к надежности

Сейчас другие времена: рынок начинает насыщаться, и заказчики и программисты начинают задумываться о надежности и отказоустойчивости. Теперь нам интересно знать, что у нас с надежностью программного обеспечения в области автоматизированных систем управления воздушным движением? Думается, не нужно объяснять, как это важно для тех, кто находится на борту самолета, который сопровождает диспетчер. А сопровождение возможно лишь постольку, поскольку диспетчер видит всю воздушную обстановку, которую ему предоставляет софт КСА УВД.

Если мы хотим понять, насколько надежным является программное обеспечение КСА, возьмем для примера самую современную отечественную систему — КСА УВД Галактика. На сайте поставщика есть очень хорошие и важные разделы про подтвержденный уровень качества и безопасности, а также про надежность. Но там не хватает одной принципиальной строчки, которая есть у всех зарубежных разработчиков систем Air Traffic Control (ATC). И эта строчка даже не вишенка на торте, которая венчает серьезную и отказоустойчивую систему. Скорее всего, это весь торт и есть.

Но прежде чем мы возьмем лопаточку и начнем препарировать этот тортик, вернемся на много лет назад и попытаемся вспомнить, что мы знаем про язык программирования Ада.

ADA Language: восстание зомби

Вот и я вспоминаю, какие ассоциации вызвало у меня прочитанное про язык Ада. Вначале американскими военными (Departament of Defense — DOD) был разработан стандарт языка. Затем, уже на основе стандарта начали создаваться компиляторы и другие инструментальные средства. Для такого подхода есть даже специальный термин — опережающая стандартизация. И все это где-то затерялось в засекреченных недрах американских военных разработок. Вот такие первые ощущения; а первые — они самые сильные.

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

Ну хорошо. Мало ли какие прекрасные вещи можно заложить в стандарт, который останется пылиться на полке? Я помню модель протоколов и стандартов OSI, по которым планировалось строить сети во всем мире. Кто сейчас знает про стандарты ISO 8473 CLNP, ISO 9542 ES-IS, ISO 10589 IS-IS и ISO 10747 IDRP, которым предсказывали успешное будущее? Все они отправились в небытие когда появился TCP/IP, и этому протоколу никакие стандарты не предшествовали. Или может вы пользуетесь электронной почтой в соответствии со стандартом X.400, который был специально разработан для нее? Нет, повсеместно работает протокол SMTP, а про X.400 уже никто не вспоминает.

Мировое комьюнити программистов настороженно относится к руководящим документам, которые разрабатывают кабинетные академики, и на тот момент у меня сложилось впечатление, что язык Ада окончательно похоронили вместе с его стандартом. Чтобы в этом удостовериться, надо было копнуть еще немножечко и попробовать отыскать этот язык в виртуальных музеях безуспешных начинаний. Но, на мое удивление, в музее Ады не оказалось.

Зато я нашел этот язык там где уж точно не ожидал его обнаружить: в таких компаниях как Airbas, Boeing, Lockheed — Martin, Thales, Indra (вот эта последняя парочка работающая в ATC особенно интересна), а также в разнообразных критичных системах — начиная от парижских поездов метро, которые едут без машиниста, истребителях и заканчивая станциями, летящими к Марсу, а также ракетами Ariane, Atlas и Delta.

И вот тут стало по настоящему интересно. Где-то в самой что ни на есть профессиональной области элитного уровня существует затерянный мир языка Ада, о котором основная масса программистов, штурмующих PHP и Java в хорошо оплачиваемых web проектах ничего и не подозревает. Каким образом Ада ухитрилась вернуться из забвения и незаметно обосноваться в современности?

Задержка в развитии

Американские военные, породившие язык, все сделали как положено по уставу, то есть стандарту. Но на большее их не хватило: дальше пошли сплошные косяки. Во первых, они решили что весь софт для военных приложений будет крутиться на Аде, что оказалось совсем не так, но дело было сделано: от военных проектов было отброшено большое количество профессионалов, которые нашли себя в области свободных разработок, не завязанных на DOD.

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

Эта бесхитростная логика потерпела сокрушительное поражение, когда выяснилось, что со временем круг людей которые разбираются в Ада исчезающе мал, зато те программисты которые получали возможность бесплатного профессионального роста на языке Си в области GNU/Linux, выросли и стали подавляющим большинством. Отсутствие людских ресурсов в Ада программировании привело к тому, что разработчики ПО для нового истребителя F-35 решили отказаться от Ада (на котором разрабатывался софт для F-22 и других самолетов) и начали разрабатывать его на языках C/C++. В результате проект начинает показывать все признаки провального — сложный комплекс ПО никак не удается отладить и запустить в полном объеме.

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

По опубликованным данным, в настоящий момент написано около 50 млн. строк исходного кода на Ада для систем вооружений, и большой объем ПО находится в текущей разработке. В 1996 году в США был произведен анализ рынка ресурсов разработчиков для Ада и Си. Всего было определено 1млн. 920 тысяч программистов, из которых 90.000, или менее 5%, писали на Аде.

ADA vs C

Теперь когда мы закончили с историей, перейдем к сравнительным цифрам, сопоставляя возможности Ада и наиболее популярного языка Си. Это сопоставление ни в коем случае не говорит о том, какой язык хороший или плохой. Они просто предназначены совершенно для разных применений.

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

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

Кстати насчет шлема: среди менеджеров бытует мнение (к которому программисты, которые «в теме», относятся с большим скепсисом), что путем повышения «дисциплины программирования» и «качественного тестирования» можно убрать все ошибки из кода Си. Это жалкая попытка надеть шлем и при этом говорить, что мотоцикл теперь стал совершенно безопасным. Одной из отличительных особенностей Ады как раз является то, что это язык со строгой типизацией данных, что делает невозможными кучу ошибок, которые легко сделать на Си. И пусть вас не вводит в заблуждение, что программный комплекс работает целый год без сбоев: достаточно редкого сочетания данных и внешних условий, чтобы попасть на нетестированную ветку алгоритма (а все ветви протестировать невозможно), и вот тут дремлющая ошибка может сработать.

Но мы отвлеклись: возвращаемся к цифрам.

Вначале дадим информацию из Вики: по сравнению с Си программами, программы написанные на Ада содержат на 70% меньше исправлений и на 90% меньше багов. Большие преимущества Ада начинают проявляться при сопровождении сложных программных комплексов (а вы думали что самое главное это разработать софт? а вот и нет), где сопровождение «часто составляет около 80% от общей стоимости разработки».

Положим, Википедия не очень сильный авторитет. Обратимся к более весомым исследованиям, и поскольку мы плавно подбираемся к КСА УВД, таким авторитетом для нас будет FAA — Federal Aviation Administration, то есть американский аналог Росавиации, и известная компания IBM. В этой таблице приведены параметры надежного и безопасного программирования по данным FAA и IBM:

Наименование
параметра
Ada 83 C
Availabilityм/ Reliability

Доступность / Надежность

21.5 11.6
Maintainability / Extensibility

Удобство сопровождения / Расширяемость

14.0 10.2

 

 

Приведем результаты еще одного любопытного исследования, в котором анализировались параметры проекта, в котором разработка начиналась на Си, затем также начал использоваться язык Ада, который на момент анализа составлял примерно половину проекта:

 

Наименование
параметра
Ada 83 C
Количество строк исходного кода SLOC 1272771 1508695
Новые функции 23031 26483
Правки кода 5841 13890
Правки / новые функции 0.25 0.52
Правки / KSLOC 4.59 9.21
Стоимость разработки $8.446.812 $15.873.508
Стоимость разработки / SLOC $6.62 $10.52
Количество ошибок 122 1020
Количество ошибок / KSLOC 0.096  0.676

 

В таблице пересчитаны также относительные значения, приведенные к количеству строк исходного кода SCLOC. Мне представляется, что цифры говорят сами за себя: в проектах написанных на Ада меньше ошибок и они имеют более низкую стоимость разработки. Теперь, когда мы оценили потенциал этого языка, а также обнаружили, что он жив и очень хорошо используется в критичных системах, возникает вопрос: а что с этим в отечественной практике? Из чего состоит КСА УВД Галактика, которую мы выбрали в качестве примера?

КСА УВД Галактика:  скучно и предсказуемо C++

Как я упомянул выше, признанные мэтры в области разработки средств управления воздушным движением — УВД (Air Traffic Control — ATC) Thales и Indra используют язык Ада. Теперь это уже далеко не секрет. Также не секрет и то, что все программное обеспечение КСА УВД Галактика написано на С++. Это обстоятельство нигде не афишируется, хотя зарубежные поставщики ATC свободно указывают тип используемого языка в своих материалах.

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

Перейдем к конкретным примерам.

На примере ниже в результате механической ошибки программа Си будет работать совсем по другому алгоритму — не так как вы ожидали. Здесь показан участок кода, который обрабатывает и затем отображает трек воздушного судна и будет выполняться или нет в зависимости от переменной clear:

В последнем случае компилятор Ада еще и ткнет вас носом, что вы именно перепутали:

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

Я сам попадал на этот вариант, в результате тратил огромное количество времени, чтобы найти, в чем проблема. Но у меня были небольшие приложения и мне повезло что ошибка проявляла себя. Если же это большой проект КСА УВД и ошибка проявится только при определенных условиях? Например, если начнет работать алгоритм опасного сближения воздушных судов?

Другой пример. В Си точка с запятой — это пустой оператор, который просто не будет выполняться. Поэтому если вы влепите две точки запятой подряд (почистите клавиатуру от крошек!), ничего не будет. Но только не в том случае, когда этот пустой оператор окажется после if:

Для такой ошибки в Си программе КСА УВД диспетчер увидит кучу треков, в том числе ложных, которые на экране появляться не должны.

И в этом случае, компилятор Ада не только укажет на синтаксическую ошибку, но и покажет что точка с запятой избыточна и не на своем месте:

Вы знаете, пока я тестировал эти примеры на своем компе, мне начал нравиться этот язык. Больше всего мне понравилось то, что он имеет встроенные средства многозадачности, чего нет даже в Си. Про многозадачность я напишу в следующий раз, а здесь приведу еще один пример, каких типовых ошибок программирования удается избежать за счет строгой типизации языка Ада. Это очень, очень опасная и распространенная ошибка, которую Си никак не контролирует — выход за границы массива. Если вы просчитались с оценкой размера массива, или совершили ошибку  в вычислении индекса, или неправильно организовали цикл… причин может быть множество; в результате вы забираетесь в области памяти, которые принадлежат другим переменным, и эффект опять таки будет непредсказуем.

И полбеды, что это будет именно «эффект», то есть вы будете его наблюдать. Наблюдаете — значит знаете об ошибке. Гораздо хуже, если эффекта не будет, и он проявит себя когда КСА УВД уже в эксплуатации, наступает сочетание нетестируемых факторов…

Ниже программа на Си, которую я также протестировал на своем компе. Она корректна с синтаксической точки зрения, компилятор обрабатывает ее молча, но в ней есть существенный изъян: из-за логической ошибки во втором цикле мы вышли за пределы объявленного массива b и записываем в память уже не значения b, а непонятно что. Никто не схватит нас за руку и не предупредит об этом!

Молчание компилятора и результат работы программы:

Тадам! Что случилось с нашим массивом a? Точнее, с его первыми двумя элементами? Они затерты вторым циклом. Такой цикл мог располагаться вообще не в нашей программе, или в другом файле, или быть написан позже другим программистом. Сколько дремлющих ошибок в Си коде ждут своего часа, чтобы выйти наружу?

Мотоциклу все равно — если решили сделать крутой разворот и выпали из седла — ваши проблемы. Только посадите ли вы своих детей в такой мотоцикл? И как быть с пассажирами на воздушном судне?

На Аде такой номер не пройдет:

Корректный код: компилируем, запускаем, получаем предсказуемый результат:

Теперь попробуем выйти за границы массива и попортить что-нибудь в другой области памяти:

Компилируем, запускаем и…

Ошибочка вышла! Ада обнаружила что индекс в цикле вышел за границы диапазона. Вот она, прелесть строгой типизации.

Повторюсь, что Си — это прекрасный язык. Но по изложенным причинам совершенно не подходит для критичных приложений, какими являются средства управления воздушным движением (позже я коснусь расширения C++ — все изложенное справедливо и для него, и есть еще дополнительные проблемы). Широко известен набор оправданий, когда выбор несоответствующего инструмента пытаются подменить тем, что «мы будем работать с этим безопасно». Например, оденем шлем на мотоцикле. Или будем забивать гвозди вместо молотка топором, а в инструкции напишем что забивать нужно тыльной частью, а не острым концом, и обяжем всех внимательно следить чтобы острием не заехать себе в глаз.

Когда больше нечего сказать: пришло время оправданий

Итак, послушаем менеджеров, пиарщиков и всех тех, кто продвигает продукты на рынок АС УВД. Вам показалось, что мы забыли программистов? Совсем нет. Это только в менеджерской среде бытуют иллюзии, что качество кода можно поправить инструкциями, внедрением чего-либо типа ISO 9000 или SAP. Поговорите с программистами в курилке: вы обнаружите, что они испытывают такую веселую уверенность в том, что в написанном ими коде наверняка приличное количество ошибок, которые еще ждут своего тестировщика. И это будет наше первое оправдание —

Оправдание №1. Программисты не должны ошибаться

Люди всегда ошибаются. Можно только минимизировать степень этих ошибок. Помните предыдущие таблицы? Это сухая, безразличная статистика. Язык Си развязывает руки и многие вещи считает не «багами», а вашими «фичами». Язык Ада требует от вас ясно выразить то, что вы хотите.

Еще раз: сухая статистика о количестве обнаруженных ошибок на каждую тысячу строк кода:

Количество ошибок / KSLOC Ада: 0.096 Си: 0.676

Будьте уверены в том, что в такой же примерно пропорции в вашем проекте есть необнаруженные ошибки. Со статистикой бесполезно спорить, ее можно только учитывать.

Оправдание №2. Все ошибки можно обнаружить тщательным тестированием

Дружный хохот программистов в курилке. Для начала, простой вопрос: есть ли в штате разработчиков КСА УВД «Галактика» отделенные от программистов тестеры, какая статистика в багзилле (а есть ли она вообще, система учета tickets?), сколько в премии теряют кодеры на каждую обнаруженную тестером ошибку, сколько в премии теряют тестеры на каждую ошибку, обнаруженную саппортом (а есть ли она в компании вообще, служба поддержки?) После этого можно поговорить про «тщательное тестирование». Кстати, что про это говорит ISO 9000?

Оправдание №3. От выбора языка ничего не зависит. Все решает комплекс мер и правильная архитектура

Это оправдание уже более компетентных людей. Теперь встречный вопрос: как вы собираетесь выстраивать правильную архитектуру на основе Си кода с сотнями заголовочных header файлов? Или может лучше строить архитектуру на языке Ада, который как раз предназначен для больших проектов с миллионами (!) строк кода?

Повторно обращаем внимание на изложенные выше примеры: у вас правильная архитектура основанная на Си коде, а ошибка в одном модуле убивает переменные в другом, хе-хе. На этом вся архитектура заканчивается.

Оправдание №4. Проблемы надежности ПО решаются аппаратным резервированием

То, что аппаратное резервирование серверов решает проблему надежности ПО — иллюзия специалистов которые никогда не писали программ. Если программный сбой возник в основном комплекте сервера, с высокой вероятностью он повторится и в комплекте, который находится в горячем резерве.

Эта особенность была хорошо известна разработчикам VCS Shmid Telecom, которые посвятили этой проблеме значительное время во время общения с нами в офисе компании в Цюрихе. Были разработаны специальные меры для того, чтобы потенциальная программная ошибка не была воспроизведена и при резервировании. С КСА УВД все еще сложнее: нужно сохранить предысторию состояния системы, т.е. все треки и местоположения воздушных судов, которые имели место быть до сбоя.

Оправдание №5. Мы начинали проект уже давно на Си и у нас нет возможности переходить на Ада сейчас

Честный ответ. На языке бизнеса это означает: мы вложили свои деньги в дело и заработаем на своих инвестициях; и неважно, надежный этот код или нет. Желающие могут ознакомиться с нашими сертификатами и актами, которые подписал заказчик. Поскольку это оправдание административного уровня, тут и возразить нечего.

Немного про C++

КСА УВД Галактика написана на C++, поэтому уделим этому расширению языка Си немного внимания. C++ это язык который реализует концепцию объектно — ориентированного программирования. В нем исползуется изоляция реализации методов класса, позволяя сохранить стабильные интерфейсы. Однако защищенность приватных членов класса от изменения снаружи работает только на логическом уровне. На физическом уровне объекты класса точно также располагаются в памяти, как и массивы в примерах которые я привел выше, и они точно также могут подвергнуться изменению.

Кроме этого, у C++ есть серьезные критики. Очень трудно обойти мнение Линуса Торвальдса, автора операционной системы Linux (которая вся написана на чистом Си, без использования С++: интересно почему?), который так высказался об этом языке (выражения похожие на ненормативную лексику смягчены :mrgreen:

Жестко сказано. Что именно не нравится Линусу? Он упоминает

Это на самом деле так, поскольку все классы в C++ наследуются от самого высокого уровня абстрактных классов, и выбор структуры этих классов очень важен, поскольку под ними со временем возникает целая иерархия и изменить что-либо на верхнем уровне уже невозможно. Как правило, представления о структуре данных и методов в начале проекта и то, к чему мы приходим в конце проекта, существенно разнятся. На это нам и указывает Линус, и к его мнению стоит прислушаться: как никак, ядро Линукс это огромный проект, и кому как не ему знать, как строится архитектура таких проектов.

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

Тоже очень интересная мысль. Значит, начиная в C++ мы постепенно выбрасываем из него вещи, которые мешают быть нашему проекту быть переносимым и эффективным, и в результате приходим к тому, что используем функционал языка Си. И больше никаких классов.

Кстати, замечание: модель объектно — ориентированного программирования не тождественна классам. Ее можно реализовать и на Си.

В этих словах Линуса можно предсказать судьбу C++ проекта КСА УВД Галактика: со временем рамки абстрактных классов верхнего уровня станут тесными, и софт ждет переработка на уровень вниз — до языка Си. Если к этому времени он не будет портирован на Ада.

Послесловие

Вот и подошло к концу наше небольшое исследование. Почему мы обратили внимание именно на КСА УВД Галактика? Причина в том, что другие поставщики систем УВД не позиционировали свои продукты как современные, передовые и соответствующими правилам Евроконтроля. А поскольку для Галактики написано что она современная, нам захотелось больше узнать про лучшие отечественные примеры.

Вернемся еще раз к тому, что написано на сайте поставщика Галактики про качество и безопасность. Там есть «вишенки» про «соответствие международным стандартам ED 153, DO278/ED 109 (SWAL 3 and 4)», но нет «тортика»: «ПО разработано на языке Ада». Поэтому вишенка как-бы повисает в воздухе: как можно обеспечить соответствие указанным стандартнам безопасности разрабатывая программы на Си?

Известные компании Thales и Indra указывают, что разработка средств УВД ведется на языке Ада. Это точно торт который нужен; к нему не стыдно присовокупить вишенку про то, что надежность ПО в соответствии с требованиями DO278/ED 109 обеспечена.

Безопасных вам полетов!

11 комментариев Темная сторона КСА УВД Галактика

  • Евгений

    Вот не стал бы сравнивать КСА (особенно в ВВП) с чем-либо встраиваемым в самолет-поезд. Слишком уж разные вещи. КСА УВД по регламенту локаторов может несколько часов простаивать. Мне диспетчера сами говорят «Мне нужна радиостанция(аварийная) и простой телефон для выхода на сеть ТфОП — то что какие-то «сервера» чего-то не работают — ну и бес ними, но замечание я вам завтра напишу :-Р.». Сугубо уж философский вопрос. Тут и к заказчику можно претензии высказать — кто и как составлял ТЗ, как тестировали, как принимали, какие условия поддержки.

  • Евгений

    Про резервирование согласен — вроде эта задача со 100% гарантией не решаема(проблема «двух армии вроде» или как-то так), проще иногда иметь 2 сервера работающих параллельно, чем отслеживать, кто «главный», а «нет».

  • Lao

    Конечно, КСА может постоять, если интенсивность полета низкая. В крупных центрах без нее уже никак. И тут дело даже не в том, что КСА УВД может «отключиться» из-за программного сбоя. Хуже ситуация когда она вроде бы работает, но деверять ее данным нельзя.

    В КСА УВД «Галактика» резервирование сделано именно так: работает основной сервер, второй — в горячем резерве, работает параллельно. Третий сервер — в холодном резерве. При отказе основного сервера второй подхватывает текущую картинку, поскольку у него есть предыстория. Если накроется второй, тут уже надо включать третий, и всю картинку отрисовывать с нуля.

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

  • Евгений

    Крупные центры, скорее всего, должны биться на сектора, которые сильно независимы друг от друга — хотя я не силен в резервировании. Мне так еще не нравиться закрытость интерфейсов-протоколов КСА, крайне скудные логи и т.д. (я не про «Галактику»).

    Все равно, мне кажется, язык все-таки инструмент — мастер главное(и заказчик, который четко знает, что ему нужно), тут спор что лучше, дремель или стамеска. Было бы в ТЗ условие на полный рестарт сервера менее чем за минуту — возможно С++ не выбрали. Если бы разработчик не работал строго с VS (так как потрачены многие килобаксы за проф. лицензию), то может сторонние компиляторы выявили большее кол-во узких мест. Ошибки про двойное «==» можно проверять хоть тупо «grep»-ом исходного кода. Как проводилось тестирование опять таки(я так слышал, как разработчики терминала речевой связи оправдывались, что для поиска ошибок им нужно с десяток девушек операторов, которые будут постоянно звонить друг-другу по громкой связи, т.е. даже речи об программном эмуляторе не было).

  • Lao

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

  • Петр

    Проверил ошибку = и == в двух компиляторах. Один выдал ошибку второй предупреждение.
    Ошибка if(); действительно существует, хотя элементарно может быть исправлена выдачей предупреждения ( мне даже кажется, что это я где то видел)

    • Lao

      Это только одна из потенциально возможных ошибок навскидку. Подобного рода рискованных мест может быть много.

      Когда собирается большой проект и к тому же в нем есть модули третьих сторон, весь терминал в предупреждениях компилятора. За ними не уследить

  • Петр

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

    Ну и в си этой ошибки избежать элементарно — достааточно всегда проверять индекс массива.

    • Lao

      В Ада когда мы задаем тип переменной, этим самым мы вводим ряд ограничений на ее значения. И проверка соответствия производится каждый раз, когда мы работаем с этой переменной, без нашего участия.

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

  • Петр

    >>Больше всего мне понравилось то, что он имеет встроенные средства многозадачности, чего нет даже в Си.

    Несколько строчек на асм — и в си вы получаете любую форму многозадачности.

    • Lao

      Можно использовать ассемблерные модули. Тут сразу налетаем на машинно — зависимый код (проблемы при портировании на разные платформы). На ассемблере возможность сделать ошибку гораздо выше, чем в Си.

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

Ответить

Вы можете использовать эти HTML теги

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">