2015-04-07 7 views
1

Приложение, над которым я работаю, имеет объект ответного ответа с логическим «одобренным» полем. Я пытаюсь выйти из этого значения в Objective C, но так как нет спецификатора формата для Booleans, я должен прибегнуть к следующему:Почему ни C, ни Objective-C не имеют спецификатора формата для булевых значений?

NSLog("%s", [response approved] ? @"TRUE" : @"FALSE"); 

Хотя это не возможно, я бы предпочел, чтобы сделать что-то вроде следующие:

NSLog("%b", [response approved]); 

... где «% b» - спецификатор формата для логического значения.

После некоторого исследования кажется единодушным consensus в том, что ни C, ни Objective-C не имеют эквивалента спецификатора «% b», и большинство разработчиков заканчивают свой собственный (что-то вроде опции № 1 выше).

Очевидно, что Dennis Ritchie & Co. знал, что они делают, когда они написали C, и я сомневаюсь, что этот недостающий спецификатор формата был случайным. Мне любопытно узнать обоснование этого решения, поэтому я могу объяснить это своей команде (кому тоже интересно).

EDIT: Некоторые ответы ниже предполагают, что это может быть проблемой локализации, то есть «TRUE» и «FALSE» слишком английский конкретного. Но разве это не было бы дилеммой, с которой сталкиваются все языки? то есть не только C и Objective-C? Java и Ruby, среди прочего, способны реализовать логические значения «True» и «False». Не знаю, почему авторы этих язычников не выбрали подобный выбор.

Кроме того, если локализация была проблемой, я ожидал бы, что это повлияет и на другие аспекты языка. Например, возьмите защищенные ключевые слова. C использует английские ключевые слова, такие как «include», «define», «return», «void» и т. Д., И эти ключевые слова, возможно, более сложны для неанглийских ораторов, чем ключевые слова, такие как «true» или «false».

+1

Ваш первый фрагмент кода использует '% s' с строковыми литералами Objective-C (' @ "" '). Либо используйте '% @', либо используйте строковые литералы C. Кроме того, вы можете обернуть выбор строки для логического в встроенной функции: 'static inline NSString * bool_name (BOOL val) {return val? @ "TRUE": @ "FALSE"; } ', а затем' NSLog (@ "% @", bool_name ([одобрено ответом]); '. –

ответ

7

Pure C (обратно в R многообразия K &) фактически не имеет логический типа, который является основной причиной, почему родная printf и кузены не родное булевым спецификатор формата. Выражения могут оцениваться с нулевыми или ненулевыми интегральными значениями, что и интерпретируется в операциях if как ложные или истинные, соответственно в C. (Понимание этого является ключом к пониманию семантики восхитительного !! синтаксиса оператора «bang bang»).

(C99 did add a _Bool type, хотя, если вы используете чистейший C вы вряд ли это нужно;. производные языки и общие платформы уже имеют общие логические типы или определения типов)

BOOL типа является ObjC конструкции, и -[NSString stringWithFormat:]NSLog) просто не имеет дополнительного спецификатора формата, который делает что-то особенное с ним. Это, безусловно, могло бы (в дополнение к %@) и выбрать некоторую разумную строку, чтобы туда попасть; Я не знаю, когда-либо рассматривалась такая вещь, но она все равно меня поражает от других спецификаторов формата. Как вы знаете, правильно ли локализовать или заглавные строки представления «да» или «нет» (или «истина» или «ложь»?) И т. Д.? Никакой другой спецификатор формата не приводит к тому, что библиотека принимает такие решения; все остальные являются точными числами или вставляют строковый результат другого вызова метода. Это кажется обременительным, но вы выбираете, какой текст вам действительно нужен, возможно, самое элегантное решение.

1

Что должно отображать форматирование? 0 & 1?TRUE & FALSE? ДА & НЕТ? -1 и 1? Как насчет других языков?

Нет правильного правильного ответа, поэтому они набросали его разработчику приложения, для которого он станет более четким (и все еще простым) выбором.

+0

Не будет ли это дилеммой, с которой сталкиваются все языки? то есть не только C и Objective-C? Java и Ruby, среди прочего, способны реализовать логические значения «True» и «False». Не знаю, почему авторы этих язычников не выбрали подобный выбор. Кроме того, если локализация была проблемой, я ожидал бы, что это повлияет и на другие аспекты языка. Например, возьмите защищенные ключевые слова. C использует английские ключевые слова, такие как «include», «define», «return», «void» и т. Д., И эти ключевые слова, возможно, более сложны для неанглийских ораторов, чем ключевые слова, такие как «true» или «false». –

+2

@toomanyrichies Разумный вопрос re: Java и Ruby. Re: locales, я бы предположил, что существует различие между фактическими языковыми ключевыми словами («void», «return»), которые существуют и имеют смысл только в источнике, в сравнении со строками, которые библиотека будет использовать во время выполнения, которые пользователь может увидеть , –

0

В начале раннего периода не было числового printf() спецификатора для char, short либо так, как было мало необходимости в нем. Теперь есть "%hhd" и "%hd". Продвигался любой тип, более узкий, чем int/unsigned.

Сегодня, в C, _Bool тип может быть напечатан с "%d".

#include <stdio.h> 
int main(void) { 
    _Bool some_bool = 2; 
    printf("%d\n", some_bool); // prints 1 (or 0 when false) 
    return 0; 
} 

недостающее звено в C является отсутствие спецификатора формата для сканирования в _Bool. Это приводит к различным решениям, таким как следующие, которые не являются удовлетворительными при вводе типа «T» или «false».

_Bool some_bool; 
    int temp; 
    scanf("%d", &temp); 
    some_bool = temp; 

 Смежные вопросы

  • Нет связанных вопросов^_^