Обновилась библиотека uthash

Это хипстота какая-то, зачем это вообще в переносимом ассемблере?

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

Минорота, ничего впечатляющего

А смысл гундеть? Просто новая версия стандарта. Приносит полезные плюшки. Казалось бы, бери да пользуйся, но сами разработчики все как один консерваторы. Читал про как в каком-то известном проекте автора заклевали собратья за то что он перешел на с99. Но как-бы пора уже. 18 лет прошло..

В js вон разработчик охоч до новых плюшек, изобретает трансляторы, чтобы уже сейчас вкушать «прекрасный» es7 на «убогом» es5. И это реально мотивирует браузеры быстрее реализовывать новые стандарты

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

Для нормальной работы со строками без кучи не обойтись. С стандартной библиотеке вообще есть сущности (кроме malloc), работающие с кучей? Я вроде не сталкивался. Может в этом дело

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

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

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

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

А C11 просто никакой, ничего принципиально важного. Разве что модель памяти обновили, но кодерам на это пофигу.

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

Это по части крестов, ты попутал.

Да просто хотелось большего и не в той области языка.

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

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

А C11 просто никакой, ничего принципиально важного. Разве что модель памяти обновили, но кодерам на это пофигу.

Согласен по обоим пунктам.

Разве что модель памяти обновили, но кодерам на это пофигу.

Кодерам на всё пофигу, ну на то они и кодеры, а не программисты.

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

становится очевидной необходимость стандартизировать поведение памяти при многопоточности

Мне не становится. Точнее, мне не очевидно, возможно ли его вообще стандартизировать так, чтобы через 30 лет программистам не пришлось ходить по костылям «а так в стандарте написано»?

Не настаиваю на своей правоте, т.к. в консерватории не был, мне только Рабинович напел. Возможно, почитаю с утреца первоисточник, если будет не лень.

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

и это правильно. они защищают С от дураков и проходимцев

А __typeof__ используют только дураки и проходимцы. Тебе уже говорили, что ты поехавшая?

в С никогда не будет макак и говнокодеров

нормальным разработчикам в С всего хватает

...а может, ты из какой-то другой Вселенной?

Ada, Modula, Cyclone, и прочая, и прочая

Бгг. Всё в кучу.

Именно. А ты думаешь [...]

Я думаю, что эта куча говорит о том, что ты не понимаешь, о чем говоришь.

Дай ему на выбор язык А и язык Б - он возьмёт тот, где больше батареек и тредов на SO

...при прочих равных, но прочие никогда не равны, иначе всё было бы на Java - даже небо, даже Аллах.

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

Правда недоумеваешь? Тогда из тебя бы получился отличный член комитета по стандартизации Си.

Я вот, например, тоже весьма смутно понимаю необходимость комплексных чисел и _Bool в стандарте. Если комплексные числа я ещё с некоторым скрипом могу себе объяснить, то _Bool у меня получается объяснить только защитой от #define TRUE (srand(...);rand())

весьма смутно понимаю необходимость комплексных чисел и _Bool в стандарте

Хм. А необходимость комплексных чисел и булевского типа ты понимаешь или тоже нет?

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

Это по части крестов, ты попутал.

Далеко ходить не будем, берем обсуждаемый тут uthash, и что же мы видим:

https://github.com/troydhanson/uthash/blob/master/src/utstring.h

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

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

В общем, важность перехода далеко не столь очевидна.

Но не до очень понимаю зачем они в стандарте

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

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

Так можно про любую фичу сказать из пары тысяч.

потому что комитет решил, что

Вот именно, «что».

Я думаю, что эта куча говорит о том, что ты не понимаешь, о чем говоришь.

Я думаю, что мне виднее, о чем я говорю. Но ты в своём репертуаре, как обычно.

Другие фичи будут в новых версиях стандарта. Если вообще будут. Какой смысл, если большинству хватает мозгов только на си из книги Кернигана&Ритчи.

Хм. А необходимость комплексных чисел и булевского типа ты понимаешь или тоже нет?

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

Булев тип практически бесполезен в условиях полного ахалай-махалай-имплисит-каста. Он никаких новых возможностей программистам не открывает. Старый добрый typedef int bool задачу вполне решал. Я не говорю, что typedef int bool - это хорошее решение. Но оно работает, его хватает.

Правда недоумеваешь? Тогда из тебя бы получился отличный член комитета по стандартизации Си.

Из меня получился бы плохой член комитета по стандартизации Си.

В первую очередь я бы добавил в язык best practices из существующих компиляторов. Тот самый typeof, statement expressions. Возможно, locally declared labels. Это дало бы возможность писать более продвинутые макросы.

Во вторую - возможность явным образом ломать существующую в си систему правил эквивалентности типов. Что-то типа:

__typespec double length_t; /* length_t больше не приводится ни во что автоматически */
__typespec enum {
  foo_that,
  foo_this
} foo_t; /* foo_t больше не приводится ни во что автоматически */

void f()
{
    length_t l;
    double d;
    int i;
    ...

    if (l == d) ... /* ошибка */
    i = 1 + l; /* ошибка */
    i = 1 + (int) l; /* работает */

    foo_t foo;

    foo = 0; /* ошибка */
    foo = foo_that; /* работает */
    i += foo; /* ошибка */
    i += (int) foo; /* работает */
}

В третью - добавил бы calling convention, явным образом передающую в функцию количество аргументов на стеке. Костыли с

#define ARG_COUNT2(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14, _15, _16, _, ...) _
#define ARG_COUNT(...) ARG_COUNT2(__VA_ARGS__, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1)

#define s0_join(allocator, separator, ...) s0_join_internal(allocator, separator, ARG_COUNT(__VA_ARGS__), __VA_ARGS__)

хоть и решают задачу, но уже подзадолбали.

В четвертых - Functions to Perform Arithmetic with Overflow Checking.

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

И сделать возможность красиво кодировать эффективные типонезависимые алгоритмы. В первом приближении было бы достаточно чего-то наподобие static inline функций, но с более вольной трактовкой аргументов. В uthash, как вы заметили, действительно, этой проблемы не стоит, т.к. бОльшая часть кода не связана с типом данных, и можно было бы и обычными static inline вместо макросов обойтись. Для небольших алгоритмов типа работы со списками и макросы подходят отлично (sys/queue.h). Но вот немаленькие алгоритмы типа бинарного поиска в массиве хотелось бы реализовывать не полностью на макросах. Хотя бы для возможности человеческой отладки.

а ты не задумывался, что в 90% библиотек строки просто не нужны? все системные и околосистемные вещи их не используют. максимум - вывод в лог ошибок (константные строки). и то не всегда, потому что коды ошибки вполне сгодятся. так что строки - это сахар, который в языке именно что не нужен. а для тех, кто работает с юзер левелом, есть библиотеки.

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

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

а на какой-то архитектуре этого в принципе может не быть.

Подскажите такие архитектуры и почему на них нет хотя бы c99?

Очень прискорбно наблюдать, как ты день ото дня стремительно глупеешь. У тебя кешлайн 64 байта, а каждый только HASH_ADD_KEYPTR инлайнит полтора килобайта, если ручками в отдельные функции все операции не заворачивать. В крестах ведь похожая проблема, что шаблоны своим тупым кодовысиранием порождают тонны холодного кода (банальный пример).

Подскажите такие архитектуры и почему на них нет хотя бы c99?

Пальцем в небо и откидывая всякий Embedded: CUDA? Вроде там были какие-то затыки с этим стандартом. Реализован он не полностью.

Ну и да, MS Visual Studio у которого с c99 достаточно сложные отношения. А следовательно, если библиотека ориентируется на кросс-платформенность и на возможность компиляции в «экосистеме» MS Windows, то будет выбрано понятно что.

Поддерживает частично: http://stackoverflow.com/a/28118893

Всё необходимое есть.

Вот и я читая проповедь Iron_Bug'а про «разные архитектуры» постоянно думаю, а не про любимую ли венду он говорит на самом деле

Хм, а VLA, оказывается, в C99 появились, а не в C11. Что-то у меня провалы в памяти.

Ну есть «разная архитектура» - это Visual Studio 6.0 из 1998-го года, то всё объяснимо.

Можно и Turbo C где-нибудь откопать. Чтож теперь из-за этого новыми стандартами не пользоваться

Standard library support has also been updated and is mostly complete in MSVC 14.0 (Visual Studio 2015).

Это всё, конечно, хорошо. Вот только появилось совсем-совсем недавно. Когда тонна кросс-платформенных сишных библиотек, была уже написана. Вот взять, SDL и SDL2, к примеру. Популярны они даже и винде.

А что за беда с си в эмбеде? Абсолютно все компиляторы застряли на 89 стандарте?

Прикольная IDE под DOS, кстати, была. А потом, помню, на Borland C++ Builder 4 приложения на VCL делал, до сих пор где-то в компе исходники валяются. Эх, молодость %-)

Кстати, а вот это не решает проблемы VS?

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

Я знаю. Но время-то идёт, для новых проектов открываются новые возможности. А то так можно и до 2100 года на ANSI C писать.

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

Ну ты всё-таки не сравнивай Vitamin C / Turbo C, про который уже все забыли, со современной гегемонией MS VS. А потому, если библиотеке нужна огромнейшая десктопная аудитория (пример с SDL/SDL2), то они и не будут пользоваться фичами из новых стандартов. Даже если их через >15 лет в новых инструментах и реализуют. При этом остаются ведь старые.

Вон, MS VS 15, насколько мне известно, не работает на Win7, а сидящих на этой ОС игрунов и разработчиков игр всё ещё огромное количество. Так что они даже дёргаться не будут.

https://www.visualstudio.com/en-us/productinfo/vs2015-sysrequirements-vs

Я вот помню, был какой-то постоянный плач на форумах по поводу новых студий, что дескать, не работают они на Windows 7. Не всё так однозначно :)

http://amx-x.ru/viewtopic.php?f=8&t=34903

http://ru.stackoverflow.com/a/460701

Возможно, они добавили поддержку W7 потом, когда поняли, что ещё куча народу сидит на этой ОС и идти в светлое будущее отказывается.

Я не особо слежу за миром MS Windows и их инструментов, так что могу путаться. Но в любом случае, ты же понимаешь, что вот эти все SDL, Python, PHP, Apache, nginx и т. д., в общем всё то, что написано на C и кросс-компилируется по MS Windows в одночасье не перейдёт полностью на C99.

А что за беда с си в эмбеде? Абсолютно все компиляторы застряли на 89 стандарте?

Emdedded гораздо неповоротливее Desktop'а. А потому там зоопарк компиляторов и встретить что-то вроде:

$ cat main.c 
inline int max(int a, int b) {
        return a > b ? a : b;
}

int main() {}

$ ad/armcc -c main.c 
"main.c", line 1: Error: C2225W: declaration lacks type/storage-class (assuming 'int'): 'inline'
"main.c", line 1: Error: C2285E: expected ';' or ',' - inserted ';' before 'int'
main.c: 0 warnings, 2 errors, 0 serious errors

$ ad/armcpp -h 2>&1 >/dev/null | head -2
ARM C++ Compiler, ADS1.2 [Build 848]
Software supplied by: Team-EFA

Вполне нормально. Но есть и положительные случаи, например, всем известные часы Pebble Watch. Там C99 во все поля было. По-крайней мере в тех примерах, в которые я заглядывал.

http://stackoverflow.com/questions/26949319/what-does-this-dot-syntax-mean-in...

То-есть, с ваших слов ситуация такая: майкрософт неохотно развивает си, и поэтому SDL, Python, PHP, Apache, nginx и иже с ними застряли в 80-х.

А LLVM под винду есть, но никому не нужен..

Остается лишь повторить комент из темы про swift. Эпл уже успела создать улучшенный Си (ObjectC), отказаться от него и популяризировать современный язык (swift), а линуксоиды до сих пор сумлеваются, переходить ли с c89 на c99..

«Идите в ж***, а я пошел домой. Вы в ж***, а я домой» (с)