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

Я показал противоречия в твоих рассуждениях - ответов нет. Рассуждения на тему «я не это имел ввиду» мимо. Меньше отвечай на отдельные куски сообщений и больше пытайся мыслить в контексте темы - проблем будет меньше.

Лучше бы макроязык выпилили.

Макроязык это инклуды, условия и остальные нужные вещи.

Нет, это всё - совершенно не нужный мусор. От алгола и фортрана до java, дотнетовского сеймейства и раста буквально никто не использует ни прямое включение промежуточных файлов, ни обработку исходников построчным sed’ом.

И то, и другое - это откровенная халтура и архитектурная кривизна.

Все задачи решаемые сишным препроцессором в норме решаются через модули и опции конкретного компилятора. Разумеется, за вычетом унылых потуг на «метапрограммирование» типа BSD’шного list.h, что надо делать через генерики / рефлексию.

Генерики/рефлексия не нужны. Уж лучше кодогенерация.

Потому что как ты иначе реализуешь зависимые от архитектуры типы, например?

Они уже реализованы. У тебя int буквально - зависимый от целевой платформы тип, где-то между 16 и 32-умя битами. Все остальные типы нужно реализовывать в норме точно так же - нет никаких причин реализовывать size_t или ptrdiff_t как-то через жопу.

От алгола и фортрана до java, дотнетовского сеймейства и раста

в норме решаются через модули

В чём отличия между модулями и инклудами?

Ты сначала попробуй ответить на вопрос - чем они схожи.

Как минимум, ты уже начал выдавать одно за альтернативу другого. Альтернатива - это достижение тех же целей другими средствами. Вот цель одна и та же.

И?

И я ответил на твой вопрос «чем схожи». Где ответ про различия?

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

Ты не тренируйся в скорости щитпостинга на лоре, ты тренируйся в понимании слов собеседника.

Ответил. Является.

Но в целом, вариантов тут два - либо у них действительно нет сходств и ты выше пытался сравнивать жопу и палец, либо тебе нечего ответить на мой вопрос и ты пытаешься съехать с темы.

В общем, тебе нужно показывать либо различия модули vs инклуды, либо объясняться, на каком основании ты их сравнивал, если они не имеют никаких сходств.

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

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

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

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

Раст - совершенно бесполезное и никому не нужное поделие. И никакой маркетинг и армия проплаченных троллей этого не изменит.

Безумие — это постоянное повторение одного и того же действия, в еадежде получить другой результат

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

Раст никогда не займёт сколь-нибудь значительную нишу в программировании. В лучшем случае он благополучно сдохнет как PL/1, в худшем, будет болтаться в районе кобола какого чисто из-за того, что сектантам когда-то удалось развести какого-нибудь тупого манагера на написание какой-ниубдь прикладной шняги на расте и теперь это поделие надо как-то поддерживать.

Какой-то лютый батхерт. Причем тут раст-то вообще? Даже плюсы на порядок лучше.

Они уже реализованы.

Неа. Мне нужен uint64_t, а не «что-то между». И таки да, это разный typedef на разных платформах. И да, через ifdef.

Мне нужен uint64_t,

Ну и пользуйся себе на здоровье.

И таки да, это разный typedef на разных платформах. И да, через ifdef.

А вот эта порнография совершенно ни к чему. Компилятор знает, под какую платформу собирается код и как на ней должен выглядеть uint64_t. Зачем тут typedef’ы c ifdef’ами? Какая в них объективная необходимость? Что такого через них надо рассказать компилятору, чего бы компилятор уже не знал?

Естественно, я же перечислил то, чего там нет.

ifdef никак не относится к копипасте

ifdef это в том числе защита от излишней копипасты.

В чём отличия между модулями и инклудами?

Очень тупой вопрос, анон. Модуль парсится один раз. Сишечный инклуд парсится при сборке каждого файла с этим инклудом. И если для сишечки это ещё не так страшно, то в C++ с Тьюринг-полными шаблонами начинается лютый ад и холокост, когда один инклуд может собираться бесконечно долго сам по себе, но тут он будет собираться в каждом месте бесконечно долго. Мелкософт ещё в 2000х для такого костыль с прекомпилируемыми заголовочными файлами сделал.

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

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

Для пользователя? Когда пользователя имеют через дыру в очередном IoT чайнике, страдает только пользователь, а его про выбор языка программирования в прошивке никто не спрашивает, и на этикетке эта информация не написана.

Но вообще, ржавый по ембеддеду расползается довольно резво. По крайней мере, в индустриях, где производителя за дыры и баги в софте всё ещё натянут. Как вот здесь: https://www.opennet.ru/opennews/art.shtml?num=62071

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

Естественно, я же перечислил то, чего там нет.

Показания не сходятся. Если «естественно», значит об инклудах ты речи не вёл. Если не вёл - не аргументировал бы этими инклудами свой тезис. А если аргументировал, а сейчас начал рассказывать «я не это имел ввиду» - значит сам запутался, либо пытаешься съехать.

ifdef это в том числе защита от излишней копипасты.

И снова то же самое. Это защита не от того вида копипасты, к которой относятся/решают инклуды. Это защита от копипасты, которая может создаваться уже инклудами.

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

За счёт чего один раз? Подробнее.

то в C++ с Тьюринг-полными шаблонами начинается лютый ад и холокост

Это мимо, потому как является свойством не инклудов, а C++(на самом деле нет, но это типа тема уже иная).

За счёт чего один раз? Подробнее.

За счёт того, что содержимое модуля не копипастится в каждый другой модуль, который его подключает. Так же, как содержимое каждого сишного файла (.c) не копипастится в каждый другой файл с вызовой функции из него.

Это мимо, потому как является свойством не инклудов, а C++(на самом деле нет, но это типа тема уже иная).

Это свойство инклудов в C++.

Очень тупой вопрос, анон.

Поэтому и не отвечено, лол.

И если для сишечки это ещё не так страшно

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

С99 это самый портабельный стандарт Си

long long

Очень портабельно, особенно для 32-битных систем. Компилятор будет вшивать библиотеку длинной арифметики для эмуляции long long.

А зачем настолько большое число? Расстояние от центра Земли до центра Луны 384 467 км, если записать его с точностью до метра, получим 384 467 000. В unsigned long помещается 4 294 967 295, что на порядок больше. Если вы хотите считать большие величины, все равно очень быстро упретесь в длинную арифметику, а если не на столько большие, то вряд ли long long будет лучше long в конкретном случае. Ну и для платформы есть size_t и ptrdiff_t. А заставлять использовать long long — такое себе, у кого-то его аппаратно нет. Тоже, кстати, касается и long, лучше использовать int, чтобы на 16-битных платформах оно работало без эмуляции, поэтому если вы понимаете, что для простого использования хватит и short, лучше писать int, тогда оно будет наиболее оптимально подходить для всех платформ.

Придумайте реальную задачку, где long long будет работать, а просто long не хватит.

Очень портабельно, особенно для 32-битных систем.

Да и срать на них.

чтобы на 16-битных платформах оно работало без эмуляции

А на них срать ещё больше, чем на 32-битные. GCC и шланг такие платформы просто не поддерживают.

Придумайте реальную задачку, где long long будет работать, а просто long не хватит.

Реальная задача: любые операции, где фигурирует размер файла на диске.

Да и срать на них.

А на них срать ещё больше, чем на 32-битные. GCC и шланг такие платформы просто не поддерживают.

Классный переносимый софт получается. А на gcc и clang множество компиляторов не заканчивается. Писать нужный тип данных не сложнее, чем везде писать long long, почему бы не сделать, чтобы программа работала хорошо везде, а не только там, где есть аппаратный long long?

Реальная задача: любые операции, где фигурирует размер файла на диске.

size_t и ptrdiff_t

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

Если в сишку принести модули, получится zig. А zig уже есть.

Очень портабельно, особенно для 32-битных систем.

Реальная задача: любые операции, где фигурирует размер файла на диске.

size_t

Ты определись - ты за портабельность на 32-ых системах или нет? Потому что size_t на них тебе для файла не хватит.

Классный переносимый софт получается.

Ага. На основных платформах работает.

А на gcc и clang множество компиляторов не заканчивается.

Есть ещё MSVC, ага. Но там свои тараканы и на совместимость с ним в принципе в 95% случаев посрать, потому что под вендой есть тот же Clang. Прямо с Visual Studio в комплекте идёт. А больше совместимых с последними стандартами компиляторов нет.

Реальная задача: любые операции, где фигурирует размер файла на диске.

size_t и ptrdiff_t

Что size_t и ptrdiff_t? Туда влезут числа больше 2^32? Правда?

Они просто за off_t не шарят. Но там, внезапно, long long.

Можно не долбиться в пердолево и просто взять uint64_t. Но наш поциент презирает C99.

Но там, внезапно, long long.

Там, внезапно, может быть вообще, что угодно - это не специфицировано стандартом. А при _XBS5_LP64_OFF64 / _XBS5_LPBIG_OFFBIG у тебя и в обычном long может быть 64 бита.

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

Может быть что угодно, а по факту long long.

Берёшся доказать этот «факт» для каждой posix-системы прошлого, настоящего и будущего?

Достаточно одной.

posix-системы прошлого

На них просто похрен, потому что новый софт под какой-нибудь говноIRIX никто без постановки на учёт в психдиспансере портировать не станет, а старый и так работает.

настоящего

Их примерно одна штука. Под макось никто в здравом уме на чистом POSIX не пишет, во-первых потому что нахрен не надо – там есть средства лучше, а во-вторых потому что посикс там часто сломан. Баг в select(), из-за чего этот селект просто не работал, держался десятилетие, например.

BSD же просто копируют лялекс сейчас, поэтому насчёт них можно не париться.

и будущего?

Очень опрометчиво считать, что в будущем появятся новые POSIX системы. Я вот скорее во второе пришествие Иисуса Христа готов поверить.

Добавлять в legacy-язык всякий косметический неортогональный сахарок без которого сто лет жили и выжили – нафиг надо? Те кто и в правду заинтересованы в «новом слове» в C-style программировании, давно уже заняты Ziglang’ом. Новое слово это зовётся comptime. С ним по факту и C++ можно сделать ненужным. Вместо его ООП-расширений будет что-то типа GObject, только чистый, без макросов… Ой, оффтоплю уже.

BSD же просто копируют лялекс сейчас

Штаа? BSDы вродь единственные которые пытаются хоть как-то следовать посиксу.

Но вообще, ржавый по ембеддеду расползается довольно резво.

И ссылка на бессмысленный маркетинговый прогон, где про эмбеддед разве что вольвоэлектрички упомянуты. Ты вообще понимаешь, что неустранимые проблемы электричек вообще не в софте? Ну и комбинация замечательная - на всю голову DEI корпорация, хайповые электромобильчики и раст. :) Кстати, в затонувшем поделии OceanGate наверняка тоже на расте что-нибудь было написано. Например драйвер геймпада. Очень безопасный.

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

Бгг. «Сишечный говнокодер» стоит дороже чем растаман.

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

Между прочим, раст угробили именно такие как ты лезущие везде и всюду с отвратительным маркетингом этого никому особо не интересного язычка. Так-то у раста был шанс занять какую-нибудь нишу, если бы создателям удалось продемонстрировать что на нём можно написать что-то новое и полезное, а не переписывать существующее с потерей фич и эффективности исключительно ради переписывания на расте. Кстати, более тупой идеи продвижения языка программирования я никогда не встречал. :)

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

Причем тут раст-то вообще?

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

У них там, видимо, методички по маркетингу такие, типа как у свидетелей Иеговы, реагировать на ключевые слова и начинать агитировать в свою секту.

Я, между прочем совершенно серьёзно. У них натурально есть понятие «Rust evangelism», и даже всякие агрессивные подразделения типа Rust Evangelism Strike Force.

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

Раст является забавным примером того, как даже такую вещь как язык программирования всякие прогрессивные могут превратить в что-то типа гей-парада и БЛМ. Очень забавно наблюдать.

Даже плюсы на порядок лучше.

Лучше чем что? И для каких задач? Разумеется у каждого популярного ЯП есть свои ниши в которых они чем-то лучше всех остальных. Поэтому они их и заняли.

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

Ты просто не осили, признай уже.

Есть ещё MSVC, ага.

И опять-таки это далеко не все компиляторы С.

Что size_t и ptrdiff_t? Туда влезут числа больше 2^32? Правда?

#include <unistd.h>

ssize_t pread(int fildes, void *buf, size_t nbyte, off_t offset);
ssize_t read(int fildes, void *buf, size_t nbyte); 

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

API libc дает не больше:

#include <stdio.h>

int fseek(FILE *stream, long offset, int whence);
long ftell(FILE *stream);
void rewind(FILE *stream);
int fgetpos(FILE *stream, fpos_t *pos);
int fsetpos(FILE *stream, fpos_t *pos);

P.S. Есть функция POSIX fseako, но она работает со смещением, а не с 64-битными переменными.

Только GObject хранит указатели на функции в «классе», компилятор C++ разворачивает код так, что методы реализуются как функции, которые получают указатель на структуру с данными.

Расстояние от центра Земли до центра Луны 384 467 км, если записать его с точностью до метра, получим 384 467 000. В unsigned long помещается 4 294 967 295, что на порядок больше.

А госдолг США, например, 35.000.000.000$, но деньги надо считать в центах, т.е. 3.500.000.000.000.

Придумайте реальную задачку, где long long будет работать, а просто long не хватит.

Про размер файла вам сказали. 64-бит нужен чтобы получить верхнюю часть умножения, которое в x86 делается одной инструкцией что умножает два 32-бит числа и выдаёт 64-бит результат в edx:eax.

Очень портабельно, особенно для 32-битных систем. Компилятор будет вшивать библиотеку длинной арифметики для эмуляции long long.

Если знать что делаешь, то не будет. Библиотечные вызовы будут использоваться лишь при делениях. При умножениях тупые компиляторы иногда вставляют, когда одной инструкции mul достаточно. Для сложения и вычитания всё делается на месте.

Между прочим все нормальные архитектуры вроде x86 и ARM изначально разработаны так чтобы упростить операции над числами длиннее регистров. За исключением ошибки природы под названием MIPS и новой ошибки под названием RISC-V. Там даже сложение и вычитание длинных чисел делается через одно место, через 4 команды, когда нормальным архитектурам с флагами достаточно двух.

P.S. Есть функция POSIX fseako, но она работает со смещением, а не с 64-битными переменными.

Что такое смещение и как с ним работают?

-D_FILE_OFFSET_BITS=64 и fseeko/ftello будут работать с 64-бит офсетами.

Такие числа считают с помощью длинной арифметики. Вспомни 90-е, когда зарплата простого рабочего могла измеряться миллионами. Никакого unsigned long long не хватит считать их сумму.

За счёт того, что содержимое модуля не копипастится в каждый другой модуль, который его подключает.

Копипастится. Очевидно не весь модуль, а декларации/экспорты.

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

Ну да, работает так же как и модули. Сишный файл(.c) парсится один раз, а инклуды с декларациями копипастятся. Модуль парсится один раз, а декларации/экспорты копипастятся. Где же отличия?

-D_FILE_OFFSET_BITS=64 и fseeko/ftello будут работать с 64-бит офсетами.

Вообще, да. off_t может быть 64-битным. Но даже тут никаких проблем не видно: система гарантирует тип off_t, отсутствие long long никак не мешает использовать off_t для написания переносимого кода. Кстати, работа с файлами такого размера не очень частая операция, если вы пишете программу, которая работает с небольшими файлами, нет смысла замедлять работу программы на x32.

нет смысла замедлять работу программы на x32.

В DOS ведь никто не использовал файлы больше 64КБ чтобы не замедлять код, правда?

В DOS работали x32 программы.

oprrator

Все 6 не c-way и не c++. Я бы предложил №