LINUX.ORG.RU

Опубликован новый стандарт языка C: C11

 , ,


0

8

Международная Огранизация по Стандартизации (ISO) опубликовала новый международный стандарт языка программирования C: ISO/IEC 9899:2011, ранее известный как C1X. Основные изменения:

  • поддержка многопоточности;
  • улучшенная поддержка юникода;
  • обобщенные макросы (type-generic expressions, позволяют статичную перегрузку);
  • анонимные структуры и объединения (упрощают обращение ко вложенным конструкциям);
  • управление выравниванием объектов;
  • статичные утверждения (static assertions);
  • удаление опасной функции gets (в пользу безопасной gets_s);
  • функция quick_exit;
  • спецификатор функции _Noreturn;
  • новый режим эксклюзивного открытия файла.

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

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

Последний черновик стандарта

>>> Подробности

★★★★

Проверено: Shaman007 ()
Последнее исправление: unsigned (всего исправлений: 4)
Ответ на: комментарий от Begemoth

Begemoth

Моя претензия к библиотеке С11 - в том, что она определяет ещё один PThread-подобный API (поправьте если я неправ).

А как еще? Это замена pthread. Которая лучше, т.к. платформеннонезависима.

Pavval ★★★★★
()
Ответ на: комментарий от anonymous

То же, что и от выравнивания,- указывать средствами языка.

Для вычислений - бред, а вот для автоматического конвертирования при присваивании пойдет. З.Ы. Надо на С++ запилить классы uint32_be_t и uint32_le_t. Будет то же самое и с той же производительностью, но без необходимости делать поддержку со стороны языка:)

Pavval ★★★★★
()
Ответ на: комментарий от anonymous

Чем оно лучше Python?

Твой быдлокод будет тормозить гораздо быстрее, чем на Python!

Pavval ★★★★★
()

Меня всегда интересовало, зачем новые ключевые слова обзывают некрасиво: _Noreturn, _Complex, например. Почему не просто noreturn и complex? Типа для совместимости с существующим кодом, где программер мог так обозвать переменные, что ли?

PamidoR
()
Ответ на: комментарий от PamidoR

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

Именно. Это основная проблема расширения языков.

Pavval ★★★★★
()

поддержка многопоточности;
улучшенная поддержка юникода;
статичные утверждения (static assertions);
новый режим эксклюзивного открытия файла.

Это хорошо, остальное не важно. Хотя мне и C89 хватает.

cruxish ★★★★
()
Ответ на: комментарий от PamidoR

Имя noreturn объявлено в хидере. Хочешь использовать красивое имя — подключай. Не хочешь, т.к. оно конфликтует с идентификатором в программе — не подключай. По-моему, такое решение логично.

geekless ★★
()

ООП добавили? Нет? Тогда в топку.

anonymous
()
Ответ на: комментарий от Pavval

при описании низкоуровневых бинарных протоколов было бы весьма удобно. А не как сейчас проверять порядок байтов и кастовать ненужные функции/макросы.

anonymous
()

Pavval, geekless, понятно, спасибо

PamidoR
()
Ответ на: комментарий от anonymous

по ссылке - тотальный бред. Особенно про timedlock. Где автору почудилось точное время срабатывания интересно?

anonymous
()

Вылью свою ложку дёгтя. Практически все внесённые изменения не являются новыми и откуда-то взяты. При этом они не поддерживаются компилятором сейчас и вообще не обязательны, т.е. 90% народа будут писать, как раньше. Тем более они не бюудут поддерживаться для микроконтроллеров. В тех случаях, когда соответствующие изменения более-менее полезны, они оказываются недостаточны или теряется преимущество языка в простоте реализации и скорости работы. Пытаться сделать из C C++, D или Яву, сохраняя обратную совместимость, дело сугубо бестолковое.

Vudod ★★★★★
()
Ответ на: комментарий от PamidoR

Потому что в 21 веке еще остались рудиминтарные язычки, не поддерживающие namespace.

anonymous
()

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

buddhist ★★★★★
()

Контрактов нету :( Или я плохо искал.

A-234 ★★★★★
()
Ответ на: комментарий от unsigned

Вспоминая шаблоны, нужно забывать про «образец прямоты».

Шаблоны кстати весьма прямые, просто видуально синтаксис страшный, как атомная война.

m0rph ★★★★★
()
Ответ на: комментарий от m0rph

Шаблоны кстати весьма прямые

Concepts не хватает

Pavval ★★★★★
()
Ответ на: комментарий от Vudod

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

А в чем трудность поддержки _Align, _Generic, анонимных структур именно для микроконтроллеров?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

Pavval ★★★★★
()
Ответ на: комментарий от tailgunner

tailgunner

Это замена pthread. Которая лучше, т.к. платформеннонезависима.


Но нет pthread_attr_t. Это плохо.

Это печально.

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

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

Для таких существует язык LD из МЭК 61131-3.

Begemoth ★★★★★
()
Ответ на: комментарий от Pavval

Для вычислений - бред, а вот для автоматического конвертирования при присваивании пойдет. З.Ы. Надо на С++ запилить классы uint32_be_t и uint32_le_t. Будет то же самое и с той же производительностью, но без необходимости делать поддержку со стороны языка:)

При чем здесь C++, если речь о другом языке?

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

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

anonymous
()
Ответ на: комментарий от Deleted

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

anonymous
()
Ответ на: комментарий от anonymous

ты не поверишь, но лишь недавно прошли времена, когда код, успешно компилируемый gcc 2.95, не компилировался gcc 3/4. Про то, как gcc 4.5 сразу после выпуска не мог собрать ведро вашего лялехса под ARM, и приходилось держать несколько тулчейнов, я промолчу. Стабильность во все дыры, ёптыть!

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

kranky ★★★★★
()

ОМГ! Я думал оно мертво.

Жаль только что скобочки не сделали опциональными в пользу выделения блоков отступами как в питоне.

Нормальный вброс? :)

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

При чем здесь C++, если речь о другом языке?

Я сказал, что для себя на С++ при необходимости реализую сам.

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

Шаблонами мило разруливается со всей оптимизацией при компиляции.

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

Какой моей логикой? Что ты там выдумывать пошел? Перечитай пост еще раз. И да, #pragma - это и есть поддержка со стороны языка.

Pavval ★★★★★
()
Ответ на: комментарий от true_admin

Жаль только что скобочки не сделали опциональными в пользу выделения блоков отступами как в питоне.

Кстати, если в питоне заменить пробелы на табы, то код будет меньше тормозить?

Pavval ★★★★★
()
Ответ на: комментарий от buddhist

вычисляемого goto

В GNU C ведь есть.

возможности создавать и изменять va_list самому

А передавать массивы указателей не катит?

unsigned ★★★★
() автор топика

C11

Напомнило мне: X11
А они там тонкие тролли

nexfwall ★★★★
()
Ответ на: комментарий от r2d2

r2d2

Питон компилируется в байт-код.

А пробелы - в nop.

Pavval ★★★★★
()
Ответ на: комментарий от bk_

bk_

Разреши и мне тоже, пожалуйста!

И тебе разрешаю.

Pavval ★★★★★
()
Ответ на: комментарий от r2d2

Питон компилируется в байт-код.

Совершенно очевидно, что исходник с табами компилируется быстрее.

tailgunner ★★★★★
()
Ответ на: комментарий от kranky

это не арчепроблемы, это объективная реальность того, что GNU за 30 лет не смогли нормально отладить компилятор.

anonymous
()
Ответ на: комментарий от Pavval

Я сказал, что для себя на С++ при необходимости реализую сам.

Ты можешь для себя на C++ хоть лысого гонять. К сабжу это не относится.

Шаблонами мило разруливается со всей оптимизацией при компиляции.

Очнись уже от C++, какие шаблоны?

И да, #pragma - это и есть поддержка со стороны языка.

Да что ты говоришь-то? Приведи пример переносимого решения с помощью этого костыля.

anonymous
()
Ответ на: комментарий от unsigned

В GNU C ведь есть.

Так то GNU.

передавать массивы указателей не катит?

Не кроссплатформенно, насколько я помню.

buddhist ★★★★★
()
Ответ на: комментарий от Pavval

то код будет меньше тормозить?

Конечно, кода то меньше. Вместо четырёх пробелов всего один таб. Чем длиннее отступы тем больше отрыв в производительности. Мы поэтому перед заливкой кода на сервера sed-ом прогоняем. Сейчас я pep пишу чтобы питон сам замену делал, а то внешние костыли это неудобно. Хотели в меркуриал сделать pre-update hook чтобы оно сразу в сконвертированном виде падало в репозиторий, но из-за того что у некоторых блокнот с табами глючит пришлось от затеи отказаться.

true_admin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.