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

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

Был я молод и удал, дерзок был, как юный волк. Электроэнергетика. Работа электронного оборудования в режиме 24/7/365.

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

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

И? Это ответ «да, софт» или «нет, не софт»? Договаривай. Например, «неотъемлемое качество софта - то, что он представляется в текстовом виде».

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

«Большая часть» - это сколько, 51%? Кстати, ты не ответил здесь:

shkolnick-kun> Ну посмотри хотябы таблицы на странице 54

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

Был я молод и удал, дерзок был, как юный волк.

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

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

Мои программы как правило с GUI. Что мне делать? Ничего не делать, просто не подходит инструмент, если нет хорошей интеграции с GUI.

Например я использую SystemVerilog и там само собой никакого GUI нет, хотя есть возможности его с гемором но прилепить, но зачем преодолевать гемор с GUI если нужно графическое приложение? Проще отказаться от Mono и любых ЯП без GUI.

И? Это ответ «да, софт» или «нет, не софт»? Договаривай. Например, «неотъемлемое качество софта - то, что он представляется в текстовом виде».

ПМСМ, это ПО ПЛИС, — это софт, и так думают по крайней мере еще в одном месте: http://sdelanounas.ru/blogs/65962/

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

Как ты себе представляешь не софтовые проблемы с интеграцией оружия?

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

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

Элеткрическая часть сделана в САПР, номиналы всех элементов рассчитаны, работа электроники промоделирована, в том числе с учетом разводки ПП и кабелей.

Фотошаблоны и программы сверления получены из САПР, программы размещения компонентов получены из САПР, паяется это все в автоматической печи, которая сладит за температурным профилем.

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

ПМСМ, это ПО ПЛИС, — это софт

Возвращаемся к вопросу о двух эквивалентных прошивках для ПЛИС, одна из которых сделана в схематике, а другая на VHDL.

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

А... так ты считаешь, что всё оружие Штатов разрабатывается как один проект.

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

Как ты себе представляешь не софтовые проблемы с интеграцией оружия?

Подразумевался ответ «да» или «нет»..

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

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

Я уверен, что по человекочасам там большая часть работы - софт. «Большая часть» - это сколько, 51%? Кстати, ты не ответил здесь.

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

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

Ответ на свой вопрос ты можешь прочесть в книге «The Intel. Как Роберт Нойс, Гордон Мур и Энди Гроув создали самую влиятельную компанию в мире». Кратко говоря, сначала основатели «Интела» совместно с инженерами рисовали внутреннее устройство первого микропроцессора на обычном листе ватмана размером на всю стену. Каждая группа инженером подходила и подрисовывала свою часть схемы в виде схемных дискретных логических элементов, стыкуя воедино узел за узлом. На современном производстве файл для изготовления интегральной микросхемы - это программное обеспечение, необходимое для натурного изготовления интегральной схемы, созданного хоть на схемотехническом уровне, хоть на языке описания аппаратуры (HDL - Hardware Description Language). Аналоговые микросхемы создаются подобным образом, используя для производства плоды работы САПРов.

Электроэнергетика. Работа электронного оборудования в режиме 24/7/365.

Какое отношение это имеет к авионике?

В том-то и дело, что если изначально не было общей модели работы всех устройств самолёта

Общая модель самолета, возможно, была. Модели самолета со всем оружием - не было.

Именно поэтому китайцы до сих пор не сделали свой гражданский самолёт уровня «Боинга» или «Эйрбаса»

Да? Ну окей.

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

Глядя на развитие вычислительной техники, я вижу, что она становится всё сложнее.

Ответ на свой вопрос ты можешь прочесть в книге «The Intel. Как Роберт Нойс, Гордон Мур и Энди Гроув создали самую влиятельную компанию в мире».

Это как-то поможет мне понять, что подразумевает под софтом конкретно школьник-кун?

Подходы с автоматической генерацией кода на низкоуровневом языке используются очень давно. Но, насколько мне известно, это применимо для ограниченного количество случаев и не отличается большой гибкостью. Посему языки вроде Ada и C++ до сих пор активнейшим образом используются в разработке mission critical ПО.

Был я молод и удал, дерзок был, как юный волк

Кстати говоря, вот эта оценка:

Сокращены сроки разработки на 6 мес.
Использование модельно-ориентированного проектирования и автоматической генерации кода сократило время разработки приложения до 11 месяцев.

Она как была получена?

Заголовок упорот донельзя.

Какое отношение это имеет к авионике?

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

Она как была получена?

Эмпирическим путём, конечно же.

А не наводит ли на размышления то, что Скотт Мейерсmostly retiring from C++. :-)

то они схожи

Знаете, это напоминает «рыбы покрыты чешуей, поэтому у них блох нет, и вот кстати о блохах...» В таких условиях работает не только электроэнергетика и авионика, но и, например, медицинское оборудование, и управление двигателями и еще куча всего, что попадает под mission critical и safety critical.

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

Эмпирическим путём, конечно же.

Т.е. Вася на C написал что-то подобное 5-ть лет назад за 11 месяцев, а Ваня — в прошлом году за пять месяцев. Следовательно, экономия составила полгода. Так?

I've spent the last quarter century focusing almost exclusively on C++
Stop trying to monitor everything in the world of C++ :-)

Лол :-)

А... так ты считаешь, что всё оружие Штатов разрабатывается как один проект.

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

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

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

В этом смысле rust - маленький шаг на пути к снижению количества ошибок.

Возвращаемся к вопросу о двух эквивалентных прошивках для ПЛИС, одна из которых сделана в схематике, а другая на VHDL.

Оба случая, — ПО, а вот если схема нарисована на бумаге карандашем, — нет.

Кстати, насчет текстовых представлений, не знаю, как в Xilinx, но альтеровские средства разработке сначала приводят все к текстовому (V)HDL, и только потом делают бинарник.

Подразумевался ответ «да» или «нет»..

То, что софт разрабатывается «руками», означает, что подавляющее большинство проблем софтовые, ибо человеку свойственно ошибаться.

можешь хоть один нормальный аргумент привести?

QtCore >> stl

Qt - тулкит для гуйни.

Только в ваших фантазиях

У тебя очень идеалистическое представление о разработке сложных ПАК.

Т.е. Вася на C написал что-то подобное 5-ть лет назад за 11 месяцев, а Ваня — в прошлом году за пять месяцев. Следовательно, экономия составила полгода. Так?

Метод «икспердных оценок же», ОБС по сути.

Знаете, это напоминает «рыбы покрыты чешуей, поэтому у них блох нет, и вот кстати о блохах...» В таких условиях работает не только электроэнергетика и авионика, но и, например, медицинское оборудование, и управление двигателями и еще куча всего, что попадает под mission critical и safety critical.

Правильно! И вот поэтому в таких областях целесообразно использовать специальные инструменты, которые не дадут накосячить, во всяком случае отсекут ошибки по невнимательности.

Кстати, не симулинком единым жив человек. Есть еще всякий SCILAB/ECOS, под который тоже есть генераторы кода.

Я занимаюсь их разработкой, это мой (небольшой) опыт.

У тебя очень идеалистическое представление о разработке сложных ПАК.

Я занимаюсь их разработкой, это мой (небольшой) опыт.

Тогда тебе повезло. Или ты делаешь компоненты, которые потом объединяют в систему другие люди.

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

Вот прямо сейчас одну халтурку по ПО делаю, может новость потом доставлю...

Или ты делаешь компоненты, которые потом объединяют в систему другие люди.

Этим тоже приходилось заниматься.

И да под ПАК я понимаю Программно-аппаратный комплекс, а не Перспектывный авиа ...

И это радует, обсуждение сразу же становится веселым!

Сейчас я управляю проектами в основном

По разработке сложных ПАК?

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

Если не ошибаюсь, генерация по моделям хороша в случаях, когда модели описывают какие-то стабильные и хорошо изученные процессы. Типа делаем замеры температуры каждые 0.1 секунды, если зафиксирована дельта в пределах 3 градусов, то делаем вот это, если в пределах 5 градусов, вот это, если в пределах 10, то вот это, а если больше, то результат замера игнорируем, т.к. это «дребезг» аппаратуры.

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

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

Ну да, в основном CASE - домен специфик программы в духе Simulink/Beremiz/SCICOS/etc.

Зато резко упрощают типовые задачи проектирования софта, и человек с образованием электрика получает возможность писать сложный mission critical hard real time софт.

Меньше косяков с барьерами восприятия между программистом и специалистом по применению опять же.

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

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

Вот какая-нибудь мобильная или даже фиксированная связь, это таки да, там фиг сгенерируешь.

В основном - простых бытовых девайсов, либо промышленных девайсов/ПАК.

Но были времена, когда немного участвовал в разработке связного оборудования...

и человек с образованием электрика получает возможность писать сложный mission critical hard real time софт.

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

Я не про авионику в данном случае говорил. Если же смотреть на авионику - то я давал ссылку на ardupilot, там тоже находят применение генераторы кода, то есть контура управления и все такое рисуется в simulink/scicos, а дальше используется генератор кода.

Понятно, что этим не электрики занимаются, но тоже специалисты по предметной области.

я давал ссылку на ardupilot

Это игрушка.

Не совсем, это система урпавления UAV, рабочая, поддерживает кучу всяких аппаратов, а еще это модель процессов и методов разработки авионики в миниатюре.

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

Это игрушка.

Игрушка — это твой новый блестящий молоток, имхо :) Ты все упоминания про ада будешь выкашивать? Или то что в F35 С++, а в F22 Ada — ого какой секрет: просто интересно. То что треду в целом место в толксах — формальность, уже понятно (конечно, можешь не отвечать, я все сразу про тебя пойму :))

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

А вот я пришёл к выводу, что сегодня выигрывает лишь тот производитель, который ведёт совместную разработку электронной аппаратуры и ПО. Таким образом, получается наиболее продуманное совокупное техническое решение. Например, «Оракл» создал свой новый микропроцессор «М7», внутри которого имеется аппаратный ускоритель работы с базой данных «Оракла», шифрователи и уплотнители данных, работающие «на лету».

Т.е. Вася на C написал что-то подобное 5-ть лет назад за 11 месяцев, а Ваня — в прошлом году за пять месяцев. Следовательно, экономия составила полгода. Так?

Да, всё так. Только Васей и Ваней был я в одном лице (это был мой далеко не первый и уже точно не последний проект).
Я бы даже не на скорости разработки сделал упор, а на времени бесперебойной работы ПО в составе электронного оборудования. Насколько мне известно, со времени выхода статьи до сегодняшнего дня ни одного сбоя ПО не было. Такие дела.

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

Только Васей и Ваней был я в одном лице (это был мой далеко не первый и уже точно не последний проект).

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

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

Вот

Отлично, но если этим руководствоваться, то почти весь софт, особенно взаимодействующий с пользователем, оказывается «soft real-time».

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

Хм... а тут пишут, что всё-таки можно. Кому верить?

Но вообще-то сила Си++ - в шаблонах и вот этом всём.

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

:^))))

так ты почитай какой там способ предлагают.. через cgo

Проекты то типовые, а вот девайсы не стандартные, поэтому каждый последующий быстрее не получается.

Поэтому появляются стандарты типа IEC_61131-3, OSEK/VDX и прочие.

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

что-то кол-во вакансий на позицию hft-девелопера со знанием unix/c++ в забугории делает из твоих слов шуршащие фантики. или hft и low latency это не hard real-time?

или hft и low latency это не hard real-time

Нет, строго говоря, это не hard real-time. В hard real-time системах время отклика гарантированно. В HFT hard real-time не нужен. Никто не умрёт, если ты пропустишь, допустим, 1% событий, или даже потеряешь какой-то маленький процент профита. Такие системы подходят под определение soft real-time.