[Arlleex 284]

9 часов назад, dxp сказал:

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

Я думаю это дело привычки. Писать вот так

CANFrame frame;
can_Send(&(frame = (CANFrame){}));

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

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

[girts 22]

1 hour ago, Arlleex said:

я подожду.

Может просто принять это всё как неисправимое зло и подстраиватся?

[Arlleex 284]

Нет.

[AHTOXA 22]

3 часа назад, Arlleex сказал:

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

В плюсах всё это можно даже проще написать:

int32_t can_Send(sCANFrame const& frame)
{
    printf("%d\r\n", frame.id);
    return 1;
}

void test()
{
    can_Send({
        .id     = 11,
        .ext    = 1,
        .rtr    = 1,
        .dlc    = 0,
        .word   = {0u, 1u}
    });
}

Думаю, что и со стеком будет всё нормально.

[Arlleex 284]

1 час назад, AHTOXA сказал:

В плюсах всё это можно даже проще написать:

int32_t can_Send(sCANFrame const& frame)
{
    printf("%d\r\n", frame.id);
    return 1;
}

void test()
{
    can_Send({
        .id     = 11,
        .ext    = 1,
        .rtr    = 1,
        .dlc    = 0,
        .word   = {0u, 1u}
    });
}

Думаю, что и со стеком будет всё нормально.

Угу, в C++ режиме компилится в один стекфрейм. Ожидаемо)