Тут важен сам механизм присваиваивания. Для 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, ошибок сборки, но не помню ни одного случая, чтобы она была полезна
Не знаю на счет исключений, но замена десятичной точки на запятую частенько оказывается неожиданной.
а зачем тебе про это заботиться? ведь стандартные нормальные функции парсинга значений учитывают локаль... и там всегда правильно будет интерпретирован разделитель целой и дробных частей. — разве нет?
Ну, например, gtk внезапно решил поменять локаль. А из-за этого основной ввод-вывод ломается.
а разве ты не можешь сам в своей программе локаль установить?
ведь стандартные нормальные функции парсинга значений учитывают локаль
Дак у файла с конфигом, с которого ветка началась, локаль внутри не определена. Как определить, какую локаль выставлять, чтобы файл корректно распарсить? И, допустим, команда bc игнорит локаль, всегда хочет десятичную точку. С локалью всё хоршо, пока одна программа сама с собой или человеком взаимодействет...
С локалью всё хоршо, пока одна программа сама с собой или человеком взаимодействет...
думается, что как раз наоборот — в пределах одной программы программист сам знает что и как — ему тут не нужно ничено выяснять. А вот в случае, когда взаимодействуешь со «внешним миром» «за пределами программы» — вот тут уже нужны сторонние соглашения — в том числе локаль к таковым и относится.
И, допустим, команда bc игнорит локаль, всегда хочет десятичную точку.
получается тебе нужна локаль, которую хочет bc... тут ничего не поменялось в плане нормальности локали.
Дак у файла с конфигом, с которого ветка началась, локаль внутри не определена. Как определить, какую локаль выставлять, чтобы файл корректно распарсить?
локаль не может быть «неопределённой» — она явно определена в каждом случае, иное дело, что ты можешь по какой либо причине не иметь сведений о таковом, однако это к теме обсуждения не относится как я считаю.
П.С. тут нет никаких «неожиданных мест» снова же — все места очевидные.
а зачем тебе про это заботиться? ведь стандартные нормальные функции парсинга значений учитывают локаль… и там всегда правильно будет интерпретирован разделитель целой и дробных частей. — разве нет?
Если бы «нет», разве стал бы я об этом упоминать? С gtk я знакомился давно, поэтому могу напутать. Кажется, проблема была не с вводом, а с выводом. Десятичный разделитель без спросу сменился с точки на запятую.
а разве ты не можешь сам в своей программе локаль установить?
Примерно так и решилось. Но вопрос-то был не в непреодолимости проблемы, а в «косвенно и неожиданно».
Примерно так и решилось. Но вопрос-то был не в непреодолимости проблемы, а в «косвенно и неожиданно».
так наоборот ожидаемо и прямо. просто ты получается неверно пытался сделать программу, поскольку предполагал ошибочно, что должно и так всё работать, но в стандарте явно сказано иное — что гарантированность правильности это задача программиста в таковом аспекте (поскольку стандарт явно декларирует, что взаимодействие с «внешним миром» «за пределами программы» выходит за его рамки и он предоставляет лишь способ настройки).