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

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

ты платформы от архитектур отличаешь?

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

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

А других компилеров нет для тех же железок?

Если что-то специфическое типа Infineon, то нет. Последние годы правда тенденция к переходу на массовые архитектуры типа Cortex-M*

struct entry {
    char *id;             
    UT_hash_handle hh;
};

struct entry *entries = NULL;

void add_entry(struct entry *entry) {
     HASH_ADD_KEYPTR(hh, entries, entry->id, strlen(entry->id), entry);  
}

Как ты думаешь, во что раскроется add_entry? GCC 6.3 -O2 генерит ровно 1183 байта, clang 3.9.1 -O2 даёт 1277. И плюс столько будет на любой другой тип структуры, и плюс столько же будет на вообще каждый HASH_ADD_KEYPTR в коде. И это только добавление, еще есть поиск, удаление и прочее. Смекаешь сколько холодного кода высирается твоими макросами любимыми? И при чём здесь твои миллионы записей, балда, мы про кэш инструкций говорим.

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

По всей видимости, она не знает, что это такое. Судя по лексике типа «маздай», человек ментально застрял где-то году в 95-м, под ДОСом.

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

А они и не против. Вкупе с их неповоротливостью и скептицизмом разработчики таких вещей не видят для себя абсолютно никаких интересных фич, а проблемы совместимости видят. Это как вчерашний тред про тимлида и Boost.

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

Ой, вот тут не надо про Apple и их маркетинговый отказ от Objective-C. Их Foundition'ы это махровейший ObjC времён NeXTSTEP и вряд ли он вообще когда-нибудь будет на Swift переписан. XNU если не ошибаюсь, это тоже c89. Популяризировали они этот Swift для прикладников только. Заслуга Apple лишь в том, что они слезли с GCC и начали работу над Clang/LLVM.

а линуксоиды до сих пор сумлеваются, переходить ли с c89 на c99..

Не Linux'оиды, а создатели библиотек, ядер и прочего, которые могут быть далеко не линуксоидами и ориентируются они всегда на самый старый стандарт, чтобы было надёжнее. Вот как раз у Linux'оидов с новыми стандартами полнейший фарш. Хочешь использовать C11? Вперёд, что тебе мешает? Хочешь потрогать C++17? Да пожалуйста: -std=c++1z и вперёд. Rust под GNU/Linux? Всегда последней версии. Сборка Git? Под винду всегда с задержкой была и т. д.

А других компилеров нет для тех же железок?

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

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

Вот сабжевую библиотеку выше возможно кто-нибудь захочет заюзать на ARMv4T (ARM7TDMI) или на каком-нибудь экзотичном SH-4. При текущей кодовой базе, не думаю что были бы какие-либо сложности. А если бы она была написана на Rust? Идём сюда, смотрим:

https://forge.rust-lang.org/platform-support.html

Нет упоминаний ни о SH-4, ни о ARMv4, даже ARMv5TE в Tier 3 засунули.

на каждый пук дёргать стек

Обновилась библиотека uthash (комментарий)

какая, в жопу, венда?

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

Ок. Убедили)

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

Или разработчики начинали эти проекты в ранние 90-е, а теперь они старые и им лень учить новый стандарт)

Вот как раз у Linux'оидов с новыми стандартами полнейший фарш

Со стандартами фарш. А вот с линуксоидами, судя по этой ветке, всё плохо. Воротят нос от нового Си

Смекаешь сколько холодного кода высирается твоими макросами любимыми?

Я уже спрашивал и еще раз повторю: а какие достойные альтернативы? Шаблоны и дженерики раскроются точно так же.

тем более неприятно такое слышать от женщины.

Это не женщина, это царь сишки!

Нет упоминаний ни о SH-4, ни о ARMv4, даже ARMv5TE в Tier 3 засунули.

Справедливости ради, чтобы делать новый проект(а какой ещё будет использовать rust) на ARMv4T или даже на ARMv5TE надо быть особо духовно одарённым. Как минимум потому что тот же Cortex-A7 дешевле и интереснее чем тот же ARMv5TE, которые даже Marvell(а ещё кто-то их сейчас делает?) объявляет EOL.

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

Кто-то из команды neovim нежно назвал MS версию Си c99-redux

Я уже спрашивал и еще раз повторю: а какие достойные альтернативы? Шаблоны и дженерики раскроются точно так же.

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

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

Ну вообще говоря, далеко не везде, где работает С, нужны файлы, например. И вообще в libc очень много нужного для прикладных программ и связи с ОС.

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

Что плохо в том, что сейчас можно писать переносимые прикладные многопоточные юникодные программы?

Создается впечатление, что сейчас стандартизируют в основном то, что давно реализовано расширениями. Хотя и не все)=

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

Раскроются так же, но не там же

Еще раз специально для существ с дефектами восприятия:

template<typename K, typename V>
V* hash_find(const K& key) { ... }

VAL* hash_find(const KEY *k) { ut_hash_find(...) }

Если у меня нет ОС,то мне и работа с файлами, сигналами, errno, локалями не нужна. А может и malloc()/free() и string.h с ctype.h не понадобятся. Или double с float вообще.

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

Никто не мешает продолжать писать на С вообще без стандартной библиотеки.

Никто не мешает под определенные платформы не реализовывать потоки и атомарные операции.

Так что плохого в __typeof__?

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

Я думаю, что мне виднее, о чем я говорю

Конечно. Я-то вижу только то, что написано, а написано там «Ада, Модула и Cyclon - альтернативы Си».

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

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

Это очень необычная практика.

Поэтому какой-то логикой объяснить наличие в языке комплексных - не получится

Как это не получится? Вот логика: на практике комплексные числа нужны так же часто, как и реальные. Моя практика это подтверждает на 100%.

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

Вообще не довод. Си89 тоже работал и его хватало.

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

ВотЪ. Это уже ближе к сути. Теперь представь, что комитет по стандартизации Си - это такие же снобы, как Iron_Bug. Представь, что их культура разработки тупо не включает в себя понятия типовой безопасности. Добавь к этому объективные препятствия вроде того, что как большую часть рынка Си-компиляторов занимает MS, которая в развитии Си не заинтересована вообще. Если ты после этого еще надеешься, что в стандарт протащат что-то нетривиальное - ты обманываешь себя. Си - закостневший труп. Если тебя это не устраивает... move on.

Почему ты сравниваешь шаблон с обычной функцией?

Голосую за этого гиклесса в Комитете! Еще протащи паттерн-матчинг и лямбды, ну и свой препроцессор конечно.

Как это не получится? Вот логика: на практике комплексные числа нужны так же часто, как и реальные. Моя практика это подтверждает на 100%.

Хотелось бы примеров. На мой взгляд, это какая-то:

очень необычная практика.

Почему - потому что, там, где востребованы комплексные числа, скорее всего актуальны более высоуровневые средства изложения алгоритмов, нежели ЯВУ-подобная обёртка над ассемблером.

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

Я бы сказал, что большую часть рынка компиляторов Си++. В экосистеме MS вроде как неактуален Си.

Почему ты сравниваешь шаблон с обычной функцией?

Потому что вызывается не «мифический абстрактный шаблон», а его конкретная реализация. И от разворачивания макроса внутри функции это мало чем отличается.

свистелок и перделок

В следующий раз когда почувствуете непреодолимое желание употребить ЭТО в своей речи посмотрите каким мудаком выглядит человек страдающий подобным недугом, думаю это будет хорошим демотиватором: https://www.youtube.com/watch?v=EaCTXsQEnqY

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

И тут она права.

И тут она права.

Обычно неосиляторы и не пробуют С, но т.к. слышали, что это что-то хакерское, то не рискуют говорить про него плохо.

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

а __typeof__ - просто синтаксический сахар. можно обойтись без него. нет необходимости его тащить в язык.

а __typeof__ - просто синтаксический сахар. можно обойтись без него. нет необходимости его тащить в язык.

В функциях и циклах тоже нет необходимости. Шарашьте все на if-ах и goto.

зачем этот goto-сахар когда есть setjmp

Действительно.

Как-бы-генерик сайд-эффект-безопасные макросы тоже не нужны?

Все руками?

Неужели еще не ясно? Это для макак! Истинные хакеры всё делают руками (гусары, молчать, а впрочем вы правы).