про Си надо говорить так: танки, самолеты, поезда, корабли, электростанции, литы, вертолеты, спутники, ракеты, холодильники, стиральные машины, автомобили, медицинские приборы, станки - ВСЁ СУКА НА Си
1. Буль в 1 байт? Выравнивание отменили? Какой будет сайзоф структуры из буля и инта именно в таком порядке? 2. Глобальный и статический конст высчитывается ровно один раз. И попадает либо в образ в секцию инициализированных данных, либо размазывается по коду, если там был макрос. В плюсах, кстати, констекспр не гарантирует компайлтайм, только очень старается. И если конста инициализируется вызовом функции, то флагвиуки компилятору, если вся цепочка там не констекспр. Очередная перекладка на компилятор задачи думать что, зачем и как пишется. 3. Атомики это не компилятор, это рантайм. Не новое ключевое слово, а пачка атомарных функций. Если писать совсем голый код, то можно и без рантайма обойтись. Да, не будет работать ввод-вывод, аллок/фри и прочее. Но иногда надо, чтоб избежать зависимостей и подгрузки dll/so. Во времена повального использования aslr это не так критично, но все же. 4. Кейс без брейка выглядит разумно, пока не припрет воткнуть кейс в середину другого кейса. Си так может. Нужно это примерно раз в 100 лет, но нужно. 5. Ифдеф сиплюсплюс в чистом си коде? Эмммм, зачем? Нужны плюсы - го на плюсы. 6. Про стародавний метод объявления ф-ций, там еще и локальные переменные в томже месте заваривать надо было, как в классическом паскале. Этим никто не пользовался, кмк, уже в 90е. Во времена Борландовского диалекта ТурбоСи 2 уже можно было так не делать. И структуры иначе нужно было объявлять, непременно с тайпдефом и тэгом. Тоже отменили? 7. А где nullptr_t nullptr? Это важная штука. Если, наконец, прибьют неявное приведение пойнтеров к инту, будет неплохо. Хоть c приведением и удобно, но небезопасно. Разве что платформозависимые типы вроде uintptr_t. 8. Неинтовые енумы, и много чего еще. 9. elifdef/elifndef.. Вердикт: можно было бы подробнее.
Мало фичей. Было бы интересно функции в структуры добавить. Можно еще, например тип byte ввести. Потдержку многопоточности ключевыми словами. Впрочем о чем это я....
фиг с ними с функциями в структурах, можно указателями обойтись, а вот конструкторы/деструкторы для структур было бы класно заиметь, глядишь и до RAII дошли бы... И да, я не хочу из Си сделать С++, но конструирование структур через конструкторы и удаление с деструктором было бы очень класной фичей, методы и прочее добавлять не нужно.
@@nerlihmax4555 на самом деле очень странно, что в низкоуровневом языке, расчитанном для работы с железом, нет поддержки многопоточности, ведь почти всё железо низкоуровнево работает многопоточно. ЦПУ наверно единственное, что работает в одном потоке, вернее работало, а сейчас все ЦПУ тоже многоядерные.
@@ВладиславГришин-ш7ш архитектура здесь ни при чём. На си по-прежнему очень тяжело программировать. Стандартная библиотека не растёт. Насколько я знаю не было и нет хотя бы подобия менеджера пакетов. В сам язык не мешало бы добавить сахара.
опять про менеджер пакетов. да нет никаких проблем со сборками если используется cmake + vcpkg. в чем проблема то собрать и проинсталлировать все пакеты ? или автоматом скачать пред компилированые пакеты для x86-64 используя vcpkg?
про Си надо говорить так: танки, самолеты, поезда, корабли, электростанции, литы, вертолеты, спутники, ракеты, холодильники, стиральные машины, автомобили, медицинские приборы, станки - ВСЁ СУКА НА Си
кстати gcc перешел на C++. нак что не все фундаментальные программы / фреймворки написаны на Си
1. Буль в 1 байт? Выравнивание отменили? Какой будет сайзоф структуры из буля и инта именно в таком порядке?
2. Глобальный и статический конст высчитывается ровно один раз. И попадает либо в образ в секцию инициализированных данных, либо размазывается по коду, если там был макрос. В плюсах, кстати, констекспр не гарантирует компайлтайм, только очень старается. И если конста инициализируется вызовом функции, то флагвиуки компилятору, если вся цепочка там не констекспр. Очередная перекладка на компилятор задачи думать что, зачем и как пишется.
3. Атомики это не компилятор, это рантайм. Не новое ключевое слово, а пачка атомарных функций. Если писать совсем голый код, то можно и без рантайма обойтись. Да, не будет работать ввод-вывод, аллок/фри и прочее. Но иногда надо, чтоб избежать зависимостей и подгрузки dll/so. Во времена повального использования aslr это не так критично, но все же.
4. Кейс без брейка выглядит разумно, пока не припрет воткнуть кейс в середину другого кейса. Си так может. Нужно это примерно раз в 100 лет, но нужно.
5. Ифдеф сиплюсплюс в чистом си коде? Эмммм, зачем? Нужны плюсы - го на плюсы.
6. Про стародавний метод объявления ф-ций, там еще и локальные переменные в томже месте заваривать надо было, как в классическом паскале. Этим никто не пользовался, кмк, уже в 90е. Во времена Борландовского диалекта ТурбоСи 2 уже можно было так не делать. И структуры иначе нужно было объявлять, непременно с тайпдефом и тэгом. Тоже отменили?
7. А где nullptr_t nullptr? Это важная штука. Если, наконец, прибьют неявное приведение пойнтеров к инту, будет неплохо. Хоть c приведением и удобно, но небезопасно. Разве что платформозависимые типы вроде uintptr_t.
8. Неинтовые енумы, и много чего еще.
9. elifdef/elifndef..
Вердикт: можно было бы подробнее.
Мало фичей. Было бы интересно функции в структуры добавить. Можно еще, например тип byte ввести. Потдержку многопоточности ключевыми словами. Впрочем о чем это я....
В структуры можно поместить указатели на функции. Чем чар не устраивает?
фиг с ними с функциями в структурах, можно указателями обойтись, а вот конструкторы/деструкторы для структур было бы класно заиметь, глядишь и до RAII дошли бы...
И да, я не хочу из Си сделать С++, но конструирование структур через конструкторы и удаление с деструктором было бы очень класной фичей, методы и прочее добавлять не нужно.
Многопоточность в низкоуровневом языке рассчитанном для работы с железом - это смело
@@nerlihmax4555 Си - универсальный язык. И кто ещё, как не он должен уметь в многопоток. Другое дело, должно ли это быть частью стандартной либы)
@@nerlihmax4555 на самом деле очень странно, что в низкоуровневом языке, расчитанном для работы с железом, нет поддержки многопоточности, ведь почти всё железо низкоуровнево работает многопоточно. ЦПУ наверно единственное, что работает в одном потоке, вернее работало, а сейчас все ЦПУ тоже многоядерные.
не догнал - чем pthread плох? зачем атомики?
быстрее отклик. он же обратил внимание что с pthread была видимая задержка при запуске.
0:48 -- конечно же нет -- написана может быть на си, но не работает...
Хороший обзор. Печально видеть что язык за 10 лет развивается меньше чем современные трендовые языки за год.
А разве не это от него и нужно?
А минусы будут?
почему это печаль? архитектура компов разве сильно изменилась за 10 лет?
@@ВладиславГришин-ш7ш архитектура здесь ни при чём. На си по-прежнему очень тяжело программировать. Стандартная библиотека не растёт. Насколько я знаю не было и нет хотя бы подобия менеджера пакетов. В сам язык не мешало бы добавить сахара.
опять про менеджер пакетов. да нет никаких проблем со сборками если используется cmake + vcpkg. в чем проблема то собрать и проинсталлировать все пакеты ? или автоматом скачать пред компилированые пакеты для x86-64 используя vcpkg?
bleed light theme 🤕