Хочу C++ без C++

Так-то там несколько раз успели прос@#$ь дэдлайны по софту, конца и края этому процессу не видно.

Так-то там несколько раз успели прос@#$ь дэдлайны по софту

Во-первых, дэдлайны по софту про*тся везде, это не повод говорить о «больших проблемах». Во-вторых, ссылки давай, а то я не припомню серьезно сорванных дэдлайнов по проекту.

Вот, например: http://spectrum.ieee.org/riskfactor/aerospace/aviation/software-testing-probl...

Вот, свежачок: http://breakingdefense.com/2016/01/operational-testers-flag-f-35-software-iss...

Принесена в жертву политической корректности.

Очень жаль.

в которых размер бинарника хелловорда около мегабайта отметаем так же

Лол, как будто на C++ размер HelloWorld менее 1МБ.

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

Developmental testing of Block 2B software is behind schedule and will likely delay the delivery of expected warfighting capabilities,” required by the Marines for their variant of the F-35 (the F-35B) that is scheduled for delivery by July 2015.

Однако IOC первой эскадрильи морской пехоты была достигнута в июле, так что...

Лол, как будто на C++ размер HelloWorld менее 1МБ.

6К динамически слинкованный.

Ну, например, потому что там много кода использует исключения.

При чем тут mono или go?

Я спрашивал, зачем в программу на C++ тащить Qt, если ты не собираешься в ней использовать GUI?

там много кода использует исключения.

Ответил здесь.

Ну, например, потому что там много кода использует исключения.

В STL? O'RLY?

Я спрашивал, зачем в программу на C++ тащить Qt, если ты не собираешься в ней использовать GUI?

Есть такая порода людей - Qt-программисты.

In a previously unreported Dec. 11 memo, Michael Gilmore cites “hundreds of unresolved deficiencies” in Block 2B software, which is what the Marines accepted in July when they declared Initial Operating Capability (IOC) last year.

То есть «приняли» работу с сотнями косяков.

Дальше пошла «торговля» с закзачиками:

On the 2B software, the JPO says “all critical must-fix deficiencies were addressed.” It’s up to the Marines, Air Force and Navy decide “whether to fix deficiencies immediately, fix them in later increments, or not fix them at all.”

Риски срыва графиков:

“The F-35 program recognizes there are about four months of potential risk in the 3F testing schedule; however, at this point in time the program is still tracking to a summer 2017 end date for 3F testing,”

ПО софту для поддержки хозяйства:

“(ALIS) continues to struggle in development with deferred requirements, late and incomplete deliveries, high manpower requirements, multiple deficiencies requiring work-arounds, and a complex architecture with likely (but largely untested) cyber deficiencies,” Gilmore wrote.

Ну я имел в виду как раз тот код, который hard realtime - туда весь не time deterministic код нельзя.

То есть «приняли» работу с сотнями косяков.

Сорванных из-за софта дэдлайнов по проекту нет, потерь самолетов или аварий тоже нет. Всё остальное вполне обычно.

Тут почитай: http://aviationweek.com/site-files/aviationweek.com/files/uploads/2016/01/DOT...

Block 3F даже начать вовремя не смогли, а ты говоришь, что сорванных дэдлайнов нет.

Ну и про перспективы проекта там же очень красноречиво все расписано.

ОП, используй rust, там все, что тебе нужно, кроме нормального синтаксиса.

в .NET Core пилят native. Но оно пока не работает. C++-ский выхлоп не компилится. Выхлоп от RuyJIT не работает. Да и вообще сам лет 5 назад пейсал конвертор IL в C++ с подменой internal call методов на свои в c++-либе. В принципе ничего запредельного нет.

Я читал подобный материал несколько лет назад. Ещё раз, обрати внимание на количество ограничений, налагаемое на использования языка: там нет RTTI, исключений и практически все стандартной библиотеки.

Я согласен с тобой. Более того, на мой взгляд, ошибка американских разработчиков авионики в том, что они побоялись использовать средство проектирования более высокого уровня вместо того, чтобы приподняться над Си со своим «урезанным» Си++. Борьба со сложностью ПО была решена лишь частично, а ошибки ручного кодирования остались и даже увеличились с ростом объёма решаемых авионикой задач.
Каким же образом нужно было создавать ПО для авионики нового поколения? Я бы использовал модельно-ориентированный подход с автоматической генерацией исходного кода на Си.
Американцы перерасходовали средств на разработку своего нового истребителя и никак не могут довести его до ума. Вот вам плоды узконаправленного инженерного образования.

Тут почитай

Там 48 страниц. Не мог бы ты сказать, на что конкретно ссылаешься?

Block 3F даже начать вовремя не смогли, а ты говоришь, что сорванных дэдлайнов нет.

«Full Block 3F mission systems development and testing cannot be completed by May 2017» - это? Ну, возможно, они сорвут дэдлайн. Где там о роли софта в этом?

А, отбой... это Bill Sweetman. Haters gonna hate и вот это всё.

Я бы использовал модельно-ориентированный подход с автоматической генерацией исходного кода на Си.

«MATLAB and Simulink Racing Lounge: Embedded Code Generation for Your Vehicle Control Systems»

Ты серьезно?

Это называется soft real time.

И где, в таком случае, проходит граница между «soft real time» и «совсем не real time»?

Ты серьезно?

Да, вполне. «Матлаб» - это лишь образец для понимания подхода для разработки ПО. За те денежные средства, которые уже потрачены на разработку авионики самолёта, можно было написать свою среду моделирования и вырабатывать исходные коды ПО из неё.
Похожим путём разработки своих особых языков программирования (Domain Specific Language DSL) с последующей автоматической выработкой исходного кода под целевое вычислительное устройство и операционную систему уже движутся разработчики ПО из банковской среды: Игорь Ткачёв - Разработка приложений на основе DSL и генерации кода.

Ты серьезно?

Да, вполне

Ясно.

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

фейспалм.жпг

Вот: https://en.wikipedia.org/wiki/Real-time_computing#Criteria_for_real-time_comp...

Похожим путём разработки своих особых языков программирования (Domain Specific Language DSL) с последующей автоматической выработкой исходного кода под целевое вычислительное устройство и операционную систему уже движутся разработчики ПО из банковской среды

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

Где там о роли софта в этом?

Block 3F это и есть софт.

Там 48 страниц. Не мог бы ты сказать, на что конкретно ссылаешься?

Ну посмотри хотябы таблицы на странице 54, там есть колонки Planed и Complrted/Sheduled.

Таблицы составлены для Block 2B и Block 3i, это предыдущие версии Block.

Сроки разработки проваливали систематически, и продолжают это делать.

о есть вполне себе физические ограничения по объёму и энергопотреблению электронной начинки

Как это связано с генерацией кода, которая происходит на машине разработчика?

в Go тоже отключается :)

Не знал. А насколько оно востребовано и «реально применимо»? В D без GC большая часть стандартной библиотеки, насколько я знаю, становится бесполезной.

Слышал, что буржуи для БИНС, используют матлаб с Си генератором, а еще вот: https://github.com/diydrones/ardupilot/blob/master/libraries/AP_NavEKF/AP_Nav... Это как раз на тему авионики.

Как это связано с генерацией кода, которая происходит на машине разработчика?

очень просто: объём и качество кода.

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

Примеры тут: https://github.com/diydrones/ardupilot/tree/master/libraries/AP_NavEKF/Models...

Ну посмотри хотябы таблицы на странице 54, там есть колонки Planed и Complrted/Sheduled

А там сказано что они планировали сделать?
Просто всякие некст-ген истребители — это ж исследовательские проекты. Ну вот стоит там у них задача, например, супер-распознавание вражеских самолётов за 1000км не включая радара, только оптически или каких-нибудь ракет на сверхскоростях или какая-нибудь интеллектуальная система автопилота. Ну вот не получается у них и неизвестно когда получится и получится ли вообще. От языка это не зависит.

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

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

Block 3F это и есть софт.

Нет. Это capability upgrade. Софт является его частью, конечно, конечно, но на советско-российском канцелярите это называется «программно-аппаратный комплекс».

Ну посмотри хотябы таблицы на странице 54, там есть колонки Planed и Complrted/Sheduled.

Смотрю. Это интеграция оружия. Ты правда считаешь, что это чисто программные проблемы?

Просто всякие некст-ген истребители — это ж исследовательские проекты.

Исследовательские проекты это самолеты с названиями X-..., а тут разработка серийного оружия, при том, что опыт создания истребителей 5 поколения там уже есть (F-22, он правда устарел, и детали с производства сняли, но не суть).

Как это связано с генерацией кода, которая происходит на машине разработчика?

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

Исследовательские проекты это самолеты с названиями X-..., тут разработка серийного оружия,

Ха. Это отличается от «настоящих» исследовательских разработок только тем, что есть обоснованная надежда заставить конечный продукт выполнять полезные функции %)

Сейчас это на 99% софт, и не только в СУО, но и в навигации, связи, и т.д, а разгадка проста: SDR, ПСП, кодовое разделение каналов, ФАР.

И во всех статьях по F-35 говорится именно про софтопроблемы.

Сейчас это на 99% софт, и не только в СУО, но и в навигации, связи, и т.д, а разгадка проста: SDR, ПСП, кодовое разделение каналов, ФАР.

Ну, если отнести к софту исходники на Verilog и/или VHDL, то... всё равно 99% не получится.

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

И во всех статьях по F-35 говорится именно про софтопроблемы.

По разным причинам меня это не убеждает.

А насколько оно востребовано и «реально применимо»?

нинасколько, вручную чистить же нельзя :) но отключить можешь..

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

Вот тут не соглашусь. Англичане оказались впереди американцев и уже используют модельно-ориентированный подход в разработке ПО для авионики:
John Russell, BAE Systems - Model-Based Design of Safety-Critical Avionics Systems.
Sandy McCuish, BAE Systems - The Use of MATLAB and Simulink in the Unmanned Air Systems Design Process.
На мой взгляд, всё дело в том, что там где нужна надёжность работы ПО жертвуют частью производительности в обмен на отсутствие неожиданных «вылетов» ПО. Работа в реальном времени в случае модельно-ориентированного подхода к проектированию сохраняется полностью, зато исключаются ошибки ручного кодирования в обмен на избыточность исходного кода.

Ну, если отнести к софту исходники на Verilog и/или VHDL, то... всё равно 99% не получится.

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

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

Я утрирую конечно, но суть в том, что все остальные технологии уже были опробованы, и не раз.

HDL, это тоже софт

А, ну окей. О кстати... а чертежи - это тоже софт?

Я утрирую конечно

Ты утрировал настолько, что выводы стали бессмысленными.

Причем могут пожертвовать ОЧЕНЬ большой частью производительности, как в софт-ПЛК, например.

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

Вот интересно, вы это сами на практике проверяли? Или по публикациям судите?

О кстати... а чертежи - это тоже софт?

Нет.

Ты утрировал настолько, что выводы стали бессмысленными.

Где ты увидел выводы?

а чертежи - это тоже софт?

Нет.

Почему нет?

А прошивки, разработанные в схематике - это софт? Если нет, почему (при том, что ровно аналогичные прошивки, сделанные на VHDL - уже софт)?

Где ты увидел выводы?

Ну, например:

shkolnick-kun> Block 3F это и есть софт.

Это типичная ситуация «производительность в обмен на надежность», в данном случае уместна аналогия про ЯП c ручным управлением памятью и с GC: человек может написать более быстрый код, используя malloc/free, но с GC безопаснее получается.

А прошивки, разработанные в схематике - это софт?

Смотри: http://www.beremiz.org/

Вот тут IDE для ПЛК, там поддерживатеся 5 стандартных языков, три из которых - графические, в том числе LD (релейно-контактных схем), и FB (функциональных блоков, напоминает simulink).

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

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

Ну, например:

shkolnick-kun> Block 3F это и есть софт.

Я уверен, что по человекочасам там большая часть работы - софт.