Технически мы готовы встроить словари в эти книжки, но для их производителей, видимо, сейчас более приоритетны другие функции. Будем благодарны, если вы будете спрашивать их о словарях, чтобы они увидели, что для пользователей это важно :)
Да, стоит. Если буду писать про Дальний Восток, обязательно упомяну, спасибо :)
Насколько я помню, в тайском немного не так — точка действительно не используется, а правила постановки пробелов весьма туманны и несколько отличаются от привычного нам разбиения на предложения. Но здесь я не уверен, сам этим не занимался.
Нам не попадался достаточно регулярно вопросительный знак после многоточия. Наверное, пишут, но не слишком часто — как у нас вопросительный знак после восклицательного (несколько выше меня поправили, сказав, что такое вообще-то может быть).
Юникода такого вроде бы нет, по крайней мере здесь его обнаружить не удалось.
Эээ… Вы, кажется, неправильно поняли. Я тут пишу о традициях (что есть в реальных печатных текстах), а не какие правила написаны в «супер-правильных книжках».
Про английский и американский я просто процитировал Линн Трасс, так что можете оспорить её мнение.
Что касается русского, то может быть кавычки-лапки “+” и чем-то некорректны, но такую пару я встречаю существенно чаще, чем лапки нижние.
Там очень удобно — если предложение заканчивается вопроситеьным знаком. то оно начинается с вот такого ¿ перевёрнутого знака вопроса. Аналогично и с восклицательным знаком. Видимо, незаменимо при публичном выступлении, если оратор читает «по бумажке» :)
К сожалению, я сам не специалист в данном вопросе. Насчёт тире разной длины довольно разумно написано у Тёмы Лебедева. Думаю, про пробелы он тоже может рассказать, если захочет.
Да, совершенно верно. Но стандарт говорит об этой ситуации, что поведение не определено.
Другой пример — разыменование нулевого указателя ({int* ptr = 0; *ptr;}). Можно ли сказать о разыменовании нулевого указателя «it isn't just bad taste, it is illegal»? Можно. Стандарт говорит, что при разыменовании нулевого указателя поведение не определено. Если реализация в этом случае сожжет ваш компьютер и потратит все ваши деньги, она все равно будет считаться соответствующей стандарту.
То же самое и с inline функциями. Поведение реализации в этой ситуации не определено. Речь не о том, что тот код правильно написан, речь о том, что эта ситуация в соответствии со стандартом приводит к неопределенному поведению, возможны серьезные проблемы и даже реализация компилятора/линкера, полностью соответствующая стандарту, вас не спасет.
Да. Там говорится «должны выполняться вот эти условия». То условие, что вы подчеркнули, первое в списке. Дальше идут еще несколько условий. В самом конце параграфа говорится «Если определения D удовлетворяют всем этим требованиям, программа должна вести себя так, как если бы сущность D была определена один раз. Если определения D не удовлетворяют этим требованиям, поведение не определено.»
Именно о последнем предложении и говорится в посте. Определения D не удовлетворяют тем требованиям, поэтому поведение не определено.
Это нарушение стандарта, а не ODR. Поскольку inline-функции с одинаковой сигнатурой должны иметь одинаковые реализации в различных единицах трансляции. И то, что пример удачно компилируется, является скорее отступлением компилятором MSVC от стандарта.
Это не нарушение стандарта и не отступление от стандарта. Стандарт говорит, что в этом случае поведение не определено. Соответственно, никаких ограничений не накладывается.
Все попытки «объяснить» неопределенное поведение — пустая трата времени.
Вся кухня с выявлением множественных символов работает только для не-inline функций. К inline функциям эта кухня не применяется. Об этом первые четыре абзаца. Так что да, вы правы насчет множественных символов, межмодульной оптимизации и ключей типа muldefs, но все это не имеет никакого отношения к предмету поста.
Более того, комментарий ниже, в общем полностью справедлив, но не очень полно сформулирован. Если о какой-либо ситуации в стандарте говорится «поведение не определено», то все попытки «объяснить», «доказать» или «обосновать» действия компилятора и поведение программы обречены — в лучшем случае после кропотливого анализа всех исходников конкретного компилятора и C++ runtime вы сможете сделать вывод о конкретной версии компилятора и C++ runtime. Эти выводы будут справедливы только для этой версии. Стоит обновить компилятор или runtime или перейти на другой компилятор — и «анализ» нужно проводить заново. Естественно, код с неопределенным поведением автоматически оказывается непереносимым между разными компиляторами и разными реализациями C++ runtime. Оно того не стоит.
Простое совпадение — в одном заголовке один разработчик написал функцию с какой-то сигнатурой и каким-то именем, в другом другой разработчик — другую функцию с теми же сигнатурой и именем. Это крайне маловероятно, если использовать разумный подход к выбору имен функций, но тем не менее возможно.
Да, /W4 в сочетании c /WX помогает найти кучу проблем. Например, C4930 — такой дефект легко посадить, не так-то просто заметить, а последствия крайне неприятные.
Насколько я помню, в тайском немного не так — точка действительно не используется, а правила постановки пробелов весьма туманны и несколько отличаются от привычного нам разбиения на предложения. Но здесь я не уверен, сам этим не занимался.
Юникода такого вроде бы нет, по крайней мере здесь его обнаружить не удалось.
Что касается русского, то может быть кавычки-лапки “+” и чем-то некорректны, но такую пару я встречаю существенно чаще, чем лапки нижние.
Да, в этом отношении одиночные точка и запятая находятся на особом положении.
Другой пример — разыменование нулевого указателя ({int* ptr = 0; *ptr;}). Можно ли сказать о разыменовании нулевого указателя «it isn't just bad taste, it is illegal»? Можно. Стандарт говорит, что при разыменовании нулевого указателя поведение не определено. Если реализация в этом случае сожжет ваш компьютер и потратит все ваши деньги, она все равно будет считаться соответствующей стандарту.
То же самое и с inline функциями. Поведение реализации в этой ситуации не определено. Речь не о том, что тот код правильно написан, речь о том, что эта ситуация в соответствии со стандартом приводит к неопределенному поведению, возможны серьезные проблемы и даже реализация компилятора/линкера, полностью соответствующая стандарту, вас не спасет.
Именно о последнем предложении и говорится в посте. Определения D не удовлетворяют тем требованиям, поэтому поведение не определено.
Это не нарушение стандарта и не отступление от стандарта. Стандарт говорит, что в этом случае поведение не определено. Соответственно, никаких ограничений не накладывается.
Все попытки «объяснить» неопределенное поведение — пустая трата времени.
Более того, комментарий ниже, в общем полностью справедлив, но не очень полно сформулирован. Если о какой-либо ситуации в стандарте говорится «поведение не определено», то все попытки «объяснить», «доказать» или «обосновать» действия компилятора и поведение программы обречены — в лучшем случае после кропотливого анализа всех исходников конкретного компилятора и C++ runtime вы сможете сделать вывод о конкретной версии компилятора и C++ runtime. Эти выводы будут справедливы только для этой версии. Стоит обновить компилятор или runtime или перейти на другой компилятор — и «анализ» нужно проводить заново. Естественно, код с неопределенным поведением автоматически оказывается непереносимым между разными компиляторами и разными реализациями C++ runtime. Оно того не стоит.