Тут важен сам механизм присваиваивания. Для C оно будет выглядеть так же. И для char тоже. Ты по сути скажи что-то лучше. А то нашёл тоже, к чему докопаться, смехота.
не надо так писать, даже если это валидное выражение.
#define SET_A(a, b, c) ((__builtin_types_compatible_p(typeof(a), char*) && (a)) ? (*(char*)(a) = c) : (b = c))
не претендую ни на что, но все-таки понятнее вашего и ф-цию не надо новую писать, и b все-таки не в пустую присваивается значение, но это gnu99, не C99.
А в C11 уже добавили полноценную стандартную проверку типов.
но вообще, такую вещь удобнее и логичнее оформить как ф-цию, тогда проверки пройдут автоматически, но тогда мы вернемся к первому моему утверждению - «не стоит так писать»
хотя нет — поулчается всё так и есть — оно rvalue там: «the result is the value of the second or third operand (whichever is evaluated), converted to the type described subsequently in this subclause.110) 110)A conditional expression does not yield an lvalue.»
Зато локалевые костыли в printf всё равно жрут боольшую часть производительности. Но локали в форматере не нужны, ими всё же должны заниматься специализированные библиотеки
Но локали в форматере не нужны, ими всё же должны заниматься специализированные библиотеки
что тут подразумевается под «форматером»? можно ли тут формализовать «нужновость» локали, а так же определить критериальностности отнесения к таковому? что значит «специализированные библиотеки», можно ли это формализовать, а так же определить критериальностности отнесения к таковому? чем std::locale не является достаточно специализированной?
Что-то что форматирует строки по шаблону. Т.к эти функции используются для технических строк, а не полноценного юзеринтерфейса, поддержка локалей здесь будет излишним усложнением. Например, если в текстовом конфиге внезапно вместо точки вылезет запятая для floating point, он станет непереносимым между локалями
можно ли тут формализовать «нужновость» локали, а так же определить критериальностности отнесения к таковому
Довольно сложный вопрос. Я, например, не вижу смысла в существовании codepage-локалей в современности, когда везде есть utf-8/utf-32, а стандартная библиотека (во всяком случае Си) хоть и поддерживает локализацию, но скорее наиболее неожиданными для программиста путями. Но в случаях, когда локализация нужна, обычно локализируют и строки. В таким случае нам нужен gettext для локализации сообщений, ui тулкиты со встроенной локализацией, если мы работаем с gui/tui, unicode-утилиты для получения количества печатных символов, а не сырых кодпоинтов/байтов, если поставлена такая задача (что само по себе спорный вопрос т.к может не быть чёткого разделения для некоторых символов). А sprintf, который будет форматировать логи и технический вывод этим всем нагружать просто бессмысленно
std::locale
Пока что эта штука принесла мне кучу проблем вроде выкидывания исключений в неожиданных местах, поломок старых libc, ошибок сборки, но не помню ни одного случая, чтобы она была полезна