Забавные новости 0й-Ti :)

Российская оборонка вроде тоже Аду использует, прямо сейчас для всяких калибров. Интересно, как Ада оптимизирует код, и если проц(STM32 типа) не шибко мощный, а софт довольно требовательный?

 

Ну-давай прикинем про «это всё». Окно реалтайма для механики — это где-то 1мс и возьмём очень-очень хороший средний лаг на операцию в 1нс… вот и получаем на окно не более 100 000 опс. В куче же случаев электроника в реалтайме даже не 10ки мгц. А теперь ещё стоит учесть, что кол-во параметров легко пробивает отметку 100+.

--- Сообщение объединено, 12 ноя 2023 ---

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

--- Сообщение объединено, 12 ноя 2023 ---

в 10нс - 1нс практически недостижим даже на топовых игровых процах

--- Сообщение объединено, 12 ноя 2023 ---

впрочем, 10нс - тоже в разряде фэнтези

 

Ну наверное, примерно той же логикой руководствовались программисты, писавшие код для Therac-25, вроде там ассемблер был...

 

главные предохранители должны быть жестянкой - получается гораздо надёжней и дешевле

 

Просто отключишь рантайм-проверки, если надо экономить на спичках

 

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

 

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

 

Что имеется ввиду, если 1мс / 1нс = 1000 000?

 

ну-стоп, для ускорения кода в си используются указатели на функции, а вот более прогрессивный само-код к реалтайму ниакого отношения не имеет

 

Смотри, метапрограммирование - это такая штука, которая позволяет тебе задать "шаблон" функции (или набора функций, или даже новых типов!), который будет генерироваться по одинаковым правилам для произвольного набора типов.
Например, тебе надо сложить два числа. Для этого в си ты напишешь:

Код (C):

1.  
2. int sum(int a, int b)
3. {
4.     return a + b;
5. }
6.  

Потом понадобилась такая же функция, но для float. Ты скопипастишь эту функцию и заменишь int на float:

Код (C):

1.  
2. float sum(float a, float b)
3. {
4.     return a + b;
5. }
6.  

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

Код (C):

1.  
2. template <typename T>
3. T add(T a, T b)
4. {
5.     return a + b;
6. }
7.  

Ты один раз написал логику функции и можешь применять её для совершенно любых типов, у которых определён оператор "+": то есть, для любых типов, которые можно сложить - не обязательно даже числа.
Для каждого типа, на котором ты вызываешь этот add(), компилятор создаст отдельные экземпляры этой функции, и в бинарнике получится абсолютно то же самое, что ты написал бы на чистом си, только в N раз короче, где N - количество типов, для которых тебе нужна эта функция.

Ты возразишь: в си есть макросы, которые позволяют сделать так:

Код (C):

1.  
2. #define define_add(type)     \
3.     type add(type a, type b) \
4.     {                        \
5.         return a + b;        \
6.     }
7.  
8. // Перечисляем типы, для которых хотим определить эту функцию:
9. define_add(int)
10. define_add(float)
11. ...
12.  

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

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

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

--- Сообщение объединено, 13 ноя 2023 ---

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

Или обёрточные типы, типа Option или Result в расте (и аналогичные в C++), когда у тебя функция может вернуть или объект, или ошибку:

Код (Rust):

1.  
2. fn func() -> Option<int> {
3.     if condition() {
4.         Some(123)
5.     } else {
6.         None
7.     }
8. }
9.  
10. fn main() {
11.     if let Some(result) = func() {
12.         println!("{result}");
13.     }
14. }
15.  

То же самое в си:

Код (C):

1.  
2. int func(int* result)
3. {
4.     if (condition())
5.     {
6.         *result = 123;
7.         return 1; // Почему в си нет bool? x_x
8.     }
9.     else
10.     {
11.         return 0;
12.     }
13. }
14.  
15. int main()
16. {
17.     result = 0;
18.     int status = func(&result);
19.     if (status)
20.     {
21.         printf("%i\n", result);
22.     }
23. }
24.  

В итоге и код длиннее, и можно забыть проверить status, и result живёт в области видимости, независимо от status.
Да ещё и bool’ов нет (ладно, в новых си есть), из-за чего в куче сишных либ статус возвращают в int’ах, а ты сиди и гадай, что там она возвращает.

 

В идеале делать макросы для макросов, вот там и начинается настоящее метапрограммирование и нэгэнтропия.

Макросы для макросов экономят длину кода, если вы код на бересте пишите.
Останется ценный материал для одежды из березовой коры.

 

Понял, шаблоны не нужны, выбрасываем)

 

Можно оставить если хочется сохранить интригу для тех кто будет читать ваш говнокод)

 

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

 

>>Шаблоны и полноценные классы различной областью видимости это несомненный плюс плюсов - и в чем конкретно эта "несомненность"? О производительности кода речи не было.

>>Шаблоны легко позволяют к примеру писать универсальные контейнеры типа хеш таблиц и т.п. - ну позволяют, и позвлоляют. Молодцы. В чем "несомненность" вашего субьективного мнения?

 

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

То же самое насчёт шаблонов: ты можешь писать обобщённый код вместо копипасты. Его легко поддерживать (правки надо только делать только в одном месте), шаблоны работают по довольно простым правилам.
А если говорить не про C++, то в других языках есть дженерики: это почти то же самое, что шаблоны, только ты можешь делать с обобщённым типом только то, что явно описал интерфейсами, которым должен соответствовать этот тип.
Хорошая ли это фича? Вроде и в ней нет причин сомневаться.

 

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

 

Так а я у тебя спрашиваю, мы же в одной дискуссии: интересно послушать твои аргументы, если они есть

 

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