Ну может не знает кто про разные нэймспейсы(или компиляторы не переваривают)

Как первое

_t

Для информации: POSIX, вроде, резервирует этот суффикс для себя. Но я тоже его использую.

_s для структуры чтобы не конфликтовало, _t для типа. Вроде как современные компиляторы сжирают и с одинаковым названием, а c++ не требует typedef, но так уже сложилось

_s для структуры чтобы не конфликтовало

Ни разу такого не видел. Всегда _t

Именование типов с пробелами - это один из худших приемов в составе Си. Писатели стандартов со мной согласны и новые типы вводят без пробелов. Лично мне нет абсолютно никакой разницы, будет ли структура анонимна или обозвана - я предпочту всегда использовать однословный псевдоним. Да, в линуксе принято использовать всегда пробельные типы, вроде «struct device» и «unsigned long», так что если вы работаете с линуксом и пахомом, то у вас нет особого выбора - вам придется страдать. Хотя, даже там есть отщепенцы:
https://elixir.bootlin.com/linux/v3.6/source/tools/perf/util/types.h#L10

это один из худших приемов в составе Си

Это вообще мелочь по сравнению с бедной стдлиб и неоднозначностями в стандартах

1. Конструкции с анонимной структурой typedef struct { ... } name_t; укачивают многие утилиты работающие с отладочной информацией.

2. Конструкции с одним именем typedef struct name_t { ... } name_t; нередко укачивают утилиты навигации по исходному коду.

   Особенно плохо при forward-декларации структуры typedef struct name_t name_t; /* бла-бла-бла, много строк */ struct name_t { ... };. Многие навигаторы и IDE видят только typedef, напрочь забывая про определение самой структуры.

это один из худших приемов в составе Си

Это вообще мелочь по сравнению с бедной стдлиб и неоднозначностями в стандартах

Вообще не понимаю аргумента по поводу бедности стандартной библиотеки. При чем тут она к языку? Вот проблема нуль-терминированных строк - намного более и серьезная, и из языка ее не так просто убрать, потому что нуль-терминированные строковые константы намертво приколочены к компилятору.

Неоднозначности? Размеры целых чисел/символов, или что? По сравнению с C++ стандарты Си просто нервно курят в сторонке.

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

🔯 в чем смысл делать так ★ в чем смысл делать так_s постфиксить_t? ★ ✡️

Конструкции с анонимной структурой typedef struct { ... } name_t; укачивают многие утилиты работающие с отладочной информацией.
Конструкции с одним именем typedef struct name_t { ... } name_t; нередко укачивают утилиты навигации по исходному коду.
Особенно плохо при forward-декларации структуры

Да, для Си нельзя написать эффективный парсер. Потому целый ряд утилит срезает углы, получая проблемы. Лучше всего работает софт, использующий компилятор для парсенья, вроде основанных на clang или той же Visual Studio (последняя компилирует код без кодогенерации с целью навигации и выдачи ошибок).

Обычно пишу так

typedef struct
{
   ....
}name_t;

Пока что проблем с этим не встречал.

Но в чём практический смысл задавать и _s и _t одновременно просто постфиксы вносят ясность и смягчают уровень былого отвращения к typedef

Почему typedef должен вызывать отвращение?

Я вообще не понимаю, зачем лично вам эти постфиксы. Зато, я понимаю, зачем они писателям библиотек и компиляторов - чтобы короткие идентификаторы, вроде «wchar», не смешались с объявленными в существующем софте. Свой софт я пишу сам, потому когда мне нужна структура точки, то я объявляю «typedef struct {...} point».

t_uint8 t_int64

Как мне кажется такой способ записи усложняет работу с автодополнением, потому что с uint8_t int64_t ты ввёл тип и автодопление за тебя поставит _t, иначе придётся каждый раз тянутся к _

При чем тут она к языку?

Как минимум потому, что приходится искать замену, коих есть в количестве более одной. Неясно, нафига эти сложности

Размеры целых чисел/символов, или что?

Я тебя умоляю. Например, использование _Alignas(T) char[sizeof(T)] для размещения объекта, алиасинг типов наподобие struct h { void* p; } и struct d { void* p; T d[N]; }(с union-ом хотя бы), memory model в многопоточном окружении и подобное.

По сравнению с C++ стандарты Си просто нервно курят в сторонке

Ну да, с std::launder особенно эпично было

Наличие пробела в идентификаторах приводит к тому, что парсер не может полагаться на пробел, как на элемент синтаксиса

Возможно неприятно, но в целом мелочь

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

point_t point

проблема нуль-терминированных строк

Давай-ка поподробнее.

strlen() is O(n)

На, как заказывал

Не вижу ни проблемы, ни сколь-либо неупоротой альтернативы.

Не вижу проблемы

Тогда зачем просил

Давай-ка поподробнее

?

Чтобы узнать, че за проблему он там узрел, и что может послужить альтернативой в 21 веке.

Строковый тип вместо char[]

Как именно предлагаешь хранить/вычислять количество символов? количество байт?

хранить

size_t //количество байт

количество символов?

проход по строке

👍

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

Копирование более чем достаточный пример, ибо самая частая, наверное, операция. А так, выигрыш в любой операции, которой необходимо быстро получить размер стореджа под строку(та же конкатенация). Возможность bound check, исключение ошибок вида «забыли терминатор поставить и указатель побежал хз куда» и пр.

https://queue.acm.org/detail.cfm?id=2010365

Как минимум потому, что приходится искать замену, коих есть в количестве более одной. Неясно, нафига эти сложности

У Си есть удивительная возможность - работать без стандартной библиотеки. То есть, она как бы опциональна.

memory model в многопоточном окружении

Засчитываю.

использование _Alignas(T) char[sizeof(T)] для размещения объекта

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

алиасинг типов наподобие struct h { void* p; } и struct d { void* p; T d[N]; }(с union-ом хотя бы)

Не понимаю, о чем речь.

Наличие пробела в идентификаторах приводит к тому, что парсер не может полагаться на пробел, как на элемент синтаксиса

Возможно неприятно, но в целом мелочь

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

point_t point

Неа, «point p1».

проблема нуль-терминированных строк

Давай-ка поподробнее

Что именно поподробнее? Нуль-терминированные строки вшиты в компилятор? Вшиты. Кроме этого, они еще и вшиты в стандартную библиотеку, которая не заставляет, но все же активно подталкивает к их использованию. Конечно, можно сделать свои собственные строки - много кто делал, Plan 9 в том числе. Правда, про широкое распространение альтернативных строк я не слышал. В частности, потому что сторонние библиотеки продолжают линию стандартной библиотеки с нуль-терминированными строками.

Или тебя интересует, почему нуль-терминированные строки - это устаревшая еще в 80-х годах технология? Потому что низкая производительность конкатенции и выборки по индексу, склонность к переполнению буфера.

Как именно предлагаешь хранить/вычислять количество символов? количество байт?

Проблема давным-давно решена в юникодных строках: длина определяется чтением заголовка.

У Си есть удивительная возможность - работать без стандартной библиотеки

Это хорошо, но с другой стороны я хотел бы избежать чего-то подобного(и это ещё кресты, там чуть получше)

_Alignas(T) char[sizeof(T)]

В чем заключается неоднозначность?

Я не нашёл подтверждения того, что

void init(storage_t* s)
{
  type_t t = {};
  memcpy(s, &t, sizeof(type_t));
}

void perform(const storage_t* s)
{
  const type_t* t = (const type_t*)s;
  t->...  //use object of type 'type_t'
}

Простые объявления ведь правильно выравниваются автоматически

Было бы всё так просто... Вообще, на C/C++ нет смысла писать, если не байто*бить, а здесь простыми объявлениями не обойдёшься

struct h { void* p; } и struct d { void* p; T d[N]; }

Не понимаю, о чем речь

Доступ к d::p через указатель на тип h

Я не нашёл подтверждения того, что
void init(storage_t* s)
...
является валидным кодом. С другой стороны - распространённая практика

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

Простые объявления ведь правильно выравниваются автоматически

Было бы всё так просто... Вообще, на C/C++ нет смысла писать, если не байто*бить, а здесь простыми объявлениями не обойдёшься

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

struct h { void* p; } и struct d { void* p; T d[N]; }

Не понимаю, о чем речь

Доступ к d::p через указатель на тип h

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

игра с огнем ...

Размеры здесь ни при чём - с ними сложности нет

Потому что в такой записи я и вовсе не вижу проблемы

struct h { void* p; };
struct d { void* p; float fs[250]; };

void ururu(void)
{
  struct h h = {NULL};
  struct d d = {NULL};
  const struct h* ph = (struct h*)&d;
  ph->p;  //UB?
}

//UB?

Нет, это вполне defined в стандарте.

Подскажи пункт

А ты со случаем, когда одна структура содержит другую, не путаешь? Потому что тут явное нарушение strict aliasing rule.

Да, точно, такой код – UB. Вот статья по теме: https://blog.regehr.org/archives/1307

Там даже пример с аналогичным кодом есть.

С другой стороны - распространённая практика

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

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

Потому что тут явное нарушение strict aliasing rule.

Доступ к void* через lvalue типа void* это уже нарушение strict aliasing rule?

легко валятся на собеседовании вопросом про strict aliasing

Легко валятся всякие самоуверенные недоучки, думающие, что тип выражения E1 в выражениях вида E1.E2 имеет какое-то значение для strict aliasing rule.

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

const struct h* ph = (struct h*)&d;
ph->p; //UB?

Вcё, я понял. Действительно, стандарт формально заявляет UB. Правда, ни один компилятор не выдаст здесь UB фактически. О чем думал комитет - мне не совсем ясно. Может быть, они решили, что слишком уж сложно будет описывать все подводные камни разыменования указателей после превращения указателей на несовместимые типы. При этом, сами-то указатели при условии совместимого выравнивания превращать можно.

Это распространенная практика, потому что большая часть программистов на C ... уровня Iron_bug

Ну конкретно касты вида char* -> struct_type*, выглядят корректными, но не прописанными в стандарт(каст struct_type* -> char* всегда норм)

стандарт написан как будто бы жопой

Дык, почти так и есть - в терминах частных случаев, и нужно по всему документу пробежаться, чтобы тот же strict aliasing понять

Внезапно, да

🤦‍♂️

Хорошее подтверждение тезиса о недоучках(или о C?)

чем вам строки не нравятся ? Это по сути элемент низкоуровневости, т.е. непосредственная особенность языка.