Новое слово в программировании на C: штатное определение количества элементов в массиве

Для Ъ кому лень продираться через капчи и проходить опросы:

• lenof
• lengthof
• countof
• nelemsof
• nelementsof
• extentof

Какие-то все варианты не особо удачные как по мне.

IMHO первый самый удачный.

countof самый удачный.

ну да такое себе, если это с и массивы логичнее было что-то типа arrlen

Да, проголосовал тоже за него.

lenof как-то не по сишному что ли, а lengthof длинно.

Скорее, не слишком очевидна разница между lengthof и sizeof.

Вот интересно, сделают ли выбранное именно ключевым lowercase словом. Осмелятся ли? В теории это сломает некоторый код, где были функции/макросы/переменные и прочее с именами countof в противном случае снова навернут убожество вида _Countof да ещё и с подключением хедера.

Ненужный опрос скрывается за ненужными капчами.

Ах, да, полвека прошло - было ненужно, сейчас тем более - ненужно.

Больше Ленов, Катёв и Настёв в C!

indexenditeratorof
maxindexplusoneof

все вариации на тему length — самое посово нубское ввобжящее в заблуждение и не раскрывающее глубинной сути проблемы

nof

Да, муть. Либо len либо nelem, но таких вариантов нет.

не нужно же

Особо не нужно, но хуже от него не будет. В принципе этот макрос и так в каждой библиотеке определён.

PS проголосовал за countof, но и lengthof считаю приемлемым. Остальные варианты неадекватны.

В смысле «в теории»? Не в теории, а 100% сломает. И не некоторый, а вообще весь код. Поэтому по-любому сделают через _Countof с хедером, это единственный адекватный вариант, никакой другой вариант даже рассмотрению не подлежит.

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

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

Оно закрываться должно -std=c2y флагом, а когда там будущий стандарт станет дефолтным в GCC воды утечёт много. Кажется дефолтный C-стандарт в GCC до сих пор 2017’ый.

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

Ага, и очень элегантно и удобно постоянно дёргать shift/capslock.

nelementsof

Нелеменцофф звучит солидно.

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

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

Хороший способ сделать так, чтобы новый стандарт стал никому не нужен. В C сейчас и так новые стандарты отвратительные, многие откатываются на ANSI C, как более стабильный и понятный стандарт, а ты ещё хочешь это насильно сделать.

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

Ну такое себе, я ненавижу такой стиль, в любом случае в C это не так.

Не знаю как это должно сломать.

Если кто-то задефайнил countof (я за него проголосовал) и компилит это современным компилятором, то найти и пропатчить это – задача нескольких минут.

многие откатываются на ANSI C

Как там на ANSI C с отсутствием однострочных комментариев? Или без flexible array member? Designated initializers? Не говоря уже о restrict и inline.

Я больше проектов вижу юзающих фичи C99. Вот сырой C89, без случайных расширений – это конечно редкость. Может даже более редкость, чем C11, тем более те же часто используемые анонимные структуры и union – это фича C11. Как и static_assert.

Не знаю как это должно сломать.

Из-за распространённости препроцессорной макросни возможно могут появиться очень странные side-эффекты.

Как там на ANSI C с отсутствием однострочных комментариев?

И с невозможностью объявить переменную в произвольном месте (объявления возможны только в начале стекового окна {тут … }.

О, точно, про это забыл. А то я их лично пишу в начале, хотя серьёзной причины для этого нет.

Не в теории, а 100% сломает. И не некоторый, а вообще весь код.

Не думаю что изменение будет серьёзнее -fcommon который отключили и который действительно сломал сборку огромного количества кода проектов. А с этим countof – наверное так, незначительность.

https://github.com/search?q=countof+language%3AC&type=code

Можно прикинуть так сказать.

Ад при портировании где компилятор поддерживает только ANSI C D:

Привет ARM ADS’у древнему

Особенно там отважные, которые объявляют свою макросню нижним подчёркиванием в начале.

Это, если что, UB.

Или Дяде Мише который с MSVC6 код собирает в 2024.

lenofpenis?

Кстати, интересно что нет опции (или я неправильно понял) на _Countof кейвордом, а countof в стандартном хедере. Это в принципе бы работало как _Static_assert кейвордом и static_assert макросней в assert.h в C11. И в C23 _Static_assert теперь задепрекейчен, а static_assert – кейворд.

Новость хорошая, но как бы плохое имя не выбрали бы, у языка с этим бывали проблемы (static). Я бы просто назвал arrsizeof.

ivanof </thread>

Нужно ли оно?

Не нужно.

Станет ли язык Си ещё лучше?

Не станет.

Скорее, не слишком очевидна разница между lengthof и sizeof.

Да тут можно как пример привести размеры одежды, как раз не сильно путано.

...просто назвал arrsizeof.

Длинно слишком.

ну это как sizeof(), только для arr. Логика!

да ещё и с подключением хедера

Как bool/_Bool, норм для начала. А потом можно и убрать через N лет, как bool.

Таким же дядей бывал и я. 😁😁😁

Это ад адов, доложу я вам.

Да нет никакой причины делать это без хедера. В любом C файле этих хедеров и так 50 штук. Будет 51, ничего страшного. Это уже проверенная методика, не первый раз так делают.

Навевает имя переменной.

Поддерживаю.

Как там на ANSI C с отсутствием однострочных комментариев? Или без flexible array member? Designated initializers? Не говоря уже о restrict и inline.

Всё это не нужно. Свистоперделки в чистом виде.

Я бы просто назвал arrsizeof

42 файла на github.

И схоже с линуксовым ARRAY_SIZE.

З.Ы.: arraysizeof ~ 500 файлов на github.

Нужно, если будет верно работать с pointer decay. Т. е. давать ошибку компиляции в случае void f(int a[10]);

Опять будет какой-нибудь _ублюдок?

Если исходить из частоты использования на github. extentof побеждает с один единственным использованием в файле ncbi_socket.c, и то в другом значении.