C++ и статическая типизация это прошлый век

Функции с фиксированным количеством параметров и их строгой типизацией — прошлый век, отстой )))))

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

...нормальных языках...

Вы намекаете, что C и C++ уже не нормальные языки, которые ушли в прошлое? А что скажите про ассемблер? :)

будущее за c# и Java, со временем все низкоуровневое уйдет в прошлое, потому что черезчур утомительно кодить.

на чистом ассемблере щас мало кодят, в основном он генерируется компиляторами из c и c++.

Maydan, а как же микроконтроллеры?

большинство современных микроконтроллеров можно программировать на C.

Можно, но есть задачи с которыми C не справиться, да и код на ассемблере гораздо компактнее( если у вас под память программы отведено 1 кб, то невольно задумаешься над размером, и С тут явно не выигрывает ) и быстрее выполняется( 3 — 20 раз чем С ).

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

для кодинга таких узких мест нужно юзать вставки через asm {}, а не писать все в машинных командах. Если кому-то это нравится, то он сам себе мазохист))

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

Пока существуют процессоры, будет существовать и ассемблер.(с)

а теперь напиши тот же код на си и сравни скорость работы твоего варианта и варианта, сгенерированного машиной.

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

и да, известно ли тебе, что производительность кода совсем не прямо пропорциональна его размеру? Очень часто совсем наоборот.

производительность кода совсем не прямо пропорциональна его размеру

Да, известно.

скорость работы твоего варианта и варианта, сгенерированного машиной

Хорошо, сравниваем:

Код, сгенерированный компилятором C:

.CSEG
    .ORG 0x00

__START_OF_CODE:

    RJMP __RESET
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00
    RJMP 0x00

__RESET:
    CLI
    CLR  R30
    OUT  EECR,R30
    OUT  MCUCR,R30

    LDI  R31,0x18
    IN   R26,MCUSR
    CBR  R26,8
    OUT  MCUSR,R26
    OUT  WDTCR,R31
    OUT  WDTCR,R30

    LDI  R24,(14-2)+1
    LDI  R26,2
__CLEAR_REG:
    ST   X+,R30
    DEC  R24
    BRNE __CLEAR_REG

    LDI  R24,__CLEAR_SRAM_SIZE
    LDI  R26,__SRAM_START
__CLEAR_SRAM:
    ST   X+,R30
    DEC  R24
    BRNE __CLEAR_SRAM

    LDI  R30,__GPIOR0_INIT
    OUT  GPIOR0,R30
    OUT  GPIOR1,R30
    OUT  GPIOR2,R30

    LDI  R30,LOW(__SRAM_END-__HEAP_SIZE)
    OUT  SPL,R30

    LDI  R28,LOW(__SRAM_START+__DSTACK_SIZE)

    RJMP _main

    .ESEG
    .ORG 0

    .DSEG
    .ORG 0x80

    .CSEG
    #ifndef __SLEEP_DEFINED__
    #define __SLEEP_DEFINED__
    .EQU __se_bit=0x20
    .EQU __sm_mask=0x50
    .EQU __sm_powerdown=0x10
    .EQU __sm_standby=0x40
    .SET power_ctrl_reg=mcucr
    #endif
    .CSEG
_main:

_0x3:
    LDI  R30,LOW(255)
    RCALL SUBOPT_0x0
    LDI  R30,LOW(0)
    RCALL SUBOPT_0x0
    RJMP _0x3
_0x6:
    RJMP _0x6

    .CSEG
SUBOPT_0x0:
    OUT  0x12,R30
    LDI  R26,LOW(500)
    LDI  R27,HIGH(500)
    RJMP _delay_ms


    .CSEG
_delay_ms:
    adiw r26,0
    breq __delay_ms1
__delay_ms0:
    __DELAY_USW 0x548FA
    wdr
    sbiw r26,1
    brne __delay_ms0
__delay_ms1:
    ret

__END_OF_CODE:

На самом деле перед этим кодом был ещё код, но в основном это были макросы и определения.

И код написанный на ассемблере:

.include "d:\avr\avrasm\appnotes\2313def.inc"

.def     Temp=R16
.def     Temp1=R17
.def     Temp2=R18
.def     Temp3=R19
.def     Temp4=R20

.cseg
.org 0

         ldi Temp,RamEnd
         out SPL,Temp

         ldi Temp,0b11111111
         out DDRB,Temp

main:

         ldi Temp, 0b11111111
         rcall Delay

         ldi Temp, 0
         rcall Delay         

rjmp main

Delay:    out PortB,Temp

          ldi Temp1,0
          ldi Temp2,0
          ldi Temp3,10

Loop:     dec Temp1
          brne Loop

          dec Temp2
          brne Loop

          dec Temp3
          brne Loop

          ret

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

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

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

с какими флагами собирал исходник на C? -O2 и -DNDebug включал? покажи сам сишный код.)

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

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

покажи сам сишный код

Вот:

#include <tiny2313.h>
#include <delay.h>

void main(void)
{
    DDRD = 0xFF;
    while (1)
    {
        PORTD = 0xFF;
        delay_ms ( 500 );
        PORTD = 0;
        delay_ms ( 500 );
    }
}

брос контроллера и очистка памяти в нем

Тем не менее это ненужные действия, мне они не нужны, но компилятор создаёт их.

ты уверен, что эти действия не нужны?

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

с какими флагами собирал свой код?
и что у тебя лежит в .include "d:\avr\avrasm\appnotes\2313def.inc"?

ты уверен, что эти действия не нужны?

Без них же прекрасно работает.

с флагами оптимизации

Уже стоит оптимизация по размеру.

и что у тебя лежит в .include «d:\avr\avrasm\appnotes\2313def.inc»?

Те же макросы и определения, что я пропустил в коде, сгенерированном компилятором(см.выше ).

Без них же прекрасно работает.

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

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

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

писать что-то большое на ассемблере практически лишено смысла

Согласен, но всё же есть случаи, когда без ассемблера не обойтись( например, программирование ядра ОС ).

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

все, что можно сделать на ASM можно сделать и на C.

Не всё, что можно сделать на asm можно сделать на С.

Сможешь сделать такое на С?:

mov sp, offset label
mov ax, 9090h
push ax
;Пусть прерывание 20h - завершение работы программы
int 20h

label:
;тут показываем какое-нибудь сообщение, например "Hello, World!

Как вы думаете, будет ли показано сообщение «Hello, World!»?

ядро, написанное на asm заебешься портировать на другие архитектуры.

ОС семейства UNIX вроде написаны наполовину на С, наполовину на asm, и ничего, вроде нормально везде работают.

linux написан на c полностью. freebsd тоже.. Именно поэтому они так хорошо портируются на новые платформы.

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

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