У мене є ці дві маленькі програми:

С

#include <stdio.h>
int main()
{
    if (5) {
        printf("true\n");
    }
    else {
        printf("false\n");
    }

    return 0;
}

Java

class type_system {
   public static void main(String args[]) {
       if (5) {
           System.out.println("true");
       }
       else {
           System.out.println("false");
       }
   }
}

яке повідомляє про помилку:

type_system.java:4: error: incompatible types: int cannot be converted to boolean
       if (5) {
           ^
1 error

Моє розуміння

Поки що я зрозумів цей приклад як демонстрацію систем різних типів. C набирається слабкіше і дозволяє переходити від int до boolean без помилок. Java сильніше набирається і не працює, оскільки не допускається неявна розмова.

Тому моє запитання: Де я неправильно зрозумів речі?

Чого я не шукаю

Моє запитання не пов'язане з поганим стилем кодування. Я знаю, що це погано, але мене цікавить, чому C це дозволяє, а Java - ні. Тому мене цікавить система типу мови, зокрема її міцність.

1. C і Java - різні мови

Те, що вони поводяться по-різному, не повинно бути дивовижним.

2. C не здійснює перетворення з intнаbool

Як це могло? У C навіть не було справжнього boolтипу, до якого слід перетворитись до 1999 року . C був створений на початку 1970-х років, і ifбув його частиною до того, як він був навіть C, ще тоді, коли це була лише серія модифікацій B ¹ .

ifNOPмайже 30 років не був просто ін. Він безпосередньо діяв на числових значеннях. Багатослівність у стандарті C ( PDF-посилання ), навіть через десятиліття після введення bools до C, все ще вказує на поведінку if(p 148) та ?:(p 100), використовуючи терміни "нерівні 0" та "рівне 0" ", а не булеві терміни" правда "чи" помилка "чи щось подібне.

Зручно, ...

3. ... цифри просто стають те, на що працюють інструкції процесора.

JZі JNZє вашою базовою інструкцією по збірці x86 для умовного розгалуження. Абревіатури - " J ump, якщо Z ero" та " J ump, якщо N ot Z ero". Еквівалентами для PDP-11, звідки походить C, є BEQ(" B ranch, якщо EQ ual") та BNE(" B ranch, якщо N ot E qual").

Ці інструкції перевіряють, чи призвела попередня операція до нуля чи ні, і стрибають (чи ні) відповідно.

4. У Java набагато більший акцент на безпеці, ніж у С коли-небудь ²

І, маючи на увазі безпеку, вони вирішили, що обмеження ifна booleans коштує витрат (як впровадження такого обмеження, так і пов'язані з цим можливості).

^{1. У} B взагалі немає типів. Мови складання, як правило, ні. І все-таки B та мови монтажу вдається впоратися з розгалуженням просто чудово.

^2. Слова Денніса Річі, коли описував заплановані модифікації B, які стали C (наголос мій):

... здавалося, що для введення символів і байтових адрес та підготовки до обладнання, що працює з плаваючою комою, потрібно було ввести схему набору тексту. Інші питання, зокрема безпека та перевірка інтерфейсу, не здавались настільки важливими, як потім.

C 2011 Інтернет Проект

6.8.4.1 У ifзаяві

Обмеження

1 Контролююче вираз ifзаяви має скалярний тип.

Семантика

2 В обох формах перший підзаголовок виконується, якщо вираз порівнюється з неоднаковим до 0. У elseформі другий підзаголовок виконується, якщо вираз порівнюється з рівним 0. Якщо перший підзаголовок буде досягнуто за допомогою мітки, другий підзаголовок є не виконується.

3 An elseпов'язується з лексично найближчим попереднім, якщо це дозволено синтаксисом.

Зауважте, що цей пункт вказує лише на те, що керуючий вираз повинен мати скалярний тип ( char/ short/ int/ long/ тощо), а не конкретно булевий тип. Гілка виконується, якщо керуючий вираз має ненульове значення.

Порівняйте це з

Специфікація мови Java SE 8

14.9 ifЗаява заяву дозволяє умовне виконання оператора або умовний вибір двох операторів, виконуючи один або інший , але не обидва.

if

    IfThenStatement :
        якщо ( вираз ) заяву

    IfThenElseStatement :
        якщо ( Expression ) StatementNoShortIf інше заяву

    IfThenElseStatementNoShortIf :
        if ( Вираз ) ЗаявуNoShortIf else StatementNoShortIf

Вираз повинен мати тип booleanабо Boolean, інакше відбувається помилка часу компіляції.

Java, OTOH, спеціально вимагає, щоб керуючий вираз у ifоператорі мав булевий тип.

Отже, мова не йде про слабке проти сильного введення тексту, а про те, що кожне відповідне визначення мови визначає як дійсний керуючий вираз.

Редагувати

Щодо того, чому мови відрізняються в цьому конкретному відношенні, кілька моментів:

1. C був похідним від B, що був "безтиповою" мовою - в основному все було від 32 до 36 біт слова (залежно від обладнання), і всі арифметичні операції були цілими операціями. Система типу С була зафіксована трохи за раз, так що ...

2. C не мав чіткого булевого типу до мовної версії 1999 року. C просто дотримувався конвенції B про використання нуля для подання falseта не нуля для подання true.

3. Java поставила дату C на добру пару десятиліть і була розроблена спеціально для усунення деяких недоліків C та C ++. Безперечно, посилення обмеження на те, що може бути контрольним виразом у ifвиписці, було частиною цього.

4. Немає підстав сподіватися, що будь-які дві мови програмування будуть робити те саме. Навіть мови, настільки тісно пов'язані, як C та C ++, розходяться цікавими способами, наприклад, у вас можуть бути легальні програми C, які не є законними програмами C ++, або є легальними програмами C ++, але з різною семантикою тощо.

Багато відповідей, схоже, націлені на вираження вбудованого призначення, яке знаходиться в умовному виразі. (Хоча це відомий вид потенційного підводного шару, в цьому випадку він не є джерелом повідомлення про помилку Java.)

Можливо, це пов'язано з тим, що ОП не опублікувало фактичне повідомлення про помилку, а ^карета вказує безпосередньо на =оператора призначення.

Однак компілятор вказує на те, =що саме оператор виробляє остаточне значення (і, отже, кінцевий тип) виразу, яке умовне бачить.

Він скаржиться на тестування не булевого значення із таким видом помилок:

помилка: несумісні типи: int не може бути перетворений в булевий

Тестування цілих чисел, хоча іноді зручно, вважається потенційним підводним каменем, якого уникають дизайнери Java. Зрештою, у Java є справжній бульовий тип даних , якого немає ( C не має) .

Це також стосується тестових покажчиків C на null / non-null через if (p) ...і if (!p) ..., що Java аналогічно не дозволяє, замість цього вимагає явного оператора порівняння для отримання необхідного булевого.

несумісні типи: int не може бути перетворений у логічний

Мене цікавить, чому C це дозволяє, а Java ні. Тому мене цікавить система типу мови, зокрема її міцність.

До вашого питання є дві частини:

Чому Java не конвертувати intв boolean?

Це зводиться до того, що Java має бути максимально чітким. Це дуже статично, дуже "в обличчя" зі своєю системою типів. Речі, які автоматично передаються на іншій мові, на Java не такі. Ви також повинні писати int a=(int)0.5. Перетворення floatна intвтрачає інформацію; такий же, як перетворення intв booleanі, таким чином, буде схильним до помилок. Крім того, їм довелося б вказати багато комбінацій. Звичайно, такі речі здаються очевидними, але вони мали намір помилитися на стороні обережності.

О, і порівняно з іншими мовами, Java була надзвичайно точною у своїй специфікації, оскільки байт-код був не просто внутрішньою деталлю реалізації. Вони повинні були б точно вказати будь-які взаємодії. Величезне починання.

Чому ifне приймає інші типи, ніж boolean?

ifцілком можна було б визначити, щоб дозволити інші типи, ніж boolean. Він може мати визначення, яке говорить про те, що таке рівнозначне:

• true
• int != 0
• String з .length>0
• Будь-яка інша посилання на об'єкт, яка не є null(а не має Booleanзначення false).
• Або навіть: будь-яка інша посилання на об'єкт, яка не є nullі чий метод Object.check_if(придуманий мною саме для цього випадку) повертає true.

Вони не зробили; реальної потреби в цьому не було, і вони хотіли, щоб це було якомога міцнішим, статичним, прозорим, легким для читання тощо. Без неявних ознак. Крім того, реалізація була б досить складною, я впевнений, що потрібно перевіряти кожне значення для всіх можливих випадків, тому продуктивність, можливо, також відігравала невеликий фактор (Java раніше була слоухау на комп’ютерах того дня; пам’ятайте, що там не було компіляторів JIT з першими випусками, принаймні, не на комп’ютерах, якими я користувався тоді).

Більш глибока причина

Більш глибокою причиною може бути той факт, що у Java є свої примітивні типи, отже, її система типів розбита між об'єктами та примітивами. Можливо, якби вони цього уникали, то все вийшло б інакше. З правилами, наведеними в попередньому розділі, вони повинні були б чітко визначити правдивість кожного примітиву (оскільки примітиви не мають суперкласу, і nullдля примітивів немає чітко визначеного ). Це швидко перетвориться на кошмар.

Прогноз

Ну, і врешті-решт, можливо, це просто вподобання мовних дизайнерів. Кожна мова, здається, крутиться там по-своєму ...

Наприклад, у Рубі немає примітивних типів. Все, буквально все, є об’єктом. Вони дуже просто переконуються, що кожен об'єкт має певний метод.

Рубі все-таки шукає правдивість на всіх видах предметів, на які можна кинути. Цікаво, що він досі не має booleanтипу (бо не має примітивів), іBoolean класу він також не має . Якщо ви запитаєте, який клас trueмає значення (зручно доступне true.class), ви отримуєте TrueClass. Цей клас насправді має методи, а саме 4 оператори для booleans ( | & ^ ==). Тут ifвраховується його значення фальси, якщо і тільки якщо воно є falseабо nil( nullРубі). Все інше правда. Отже, 0або ""обидва вірні.

Для них було б тривіально створити метод, Object#truthy?який можна було б реалізувати для будь-якого класу та повернути індивідуальну правдивість. Наприклад, String#truthy?могло б бути реалізовано так, що це стосується не порожніх рядків чи чогось іншого. Вони цього не зробили, навіть незважаючи на те, що Рубі - це антитеза Java у більшості департаментів (динамічне введення качок з міксином, повторне відкриття класів та все таке).

Що може дивувати програміста Perl, який звик $value <> 0 || length($value)>0 || defined($value)бути правдивим. І так далі.

Введіть SQL з його умовою, що nullвсередині будь-якого виразу автоматично робиться помилковим, незважаючи ні на що. Отже (null==null) = false. В Ruby (nil==nil) = true. Щасливі часи.

Окрім інших тонких відповідей, я хотів би поговорити про послідовність між мовами.

Коли ми думаємо про математично чисте твердження if, ми розуміємо, що умова може бути істинною, або хибною, ніякого іншого значення. Кожна основна мова програмування поважає цей математичний ідеал; якщо ви надаєте булеву справжню / хибну величину if-оператору, то ви можете сподіватися, що ви побачите послідовну, інтуїтивну поведінку весь час.

Все йде нормально. Це те, що реалізує Java, і лише те, що реалізує Java.

Інші мови намагаються наблизити зручності для не булевих значень. Наприклад:

• Припустимо n, ціле число. Тепер визначте if (n)стенограму для if (n != 0).
• Припустимо, xце число з плаваючою комою. Тепер визначте if (x)стенограму для if (x != 0 && !isNaN(x)).
• Припустимо p, це тип вказівника. Тепер визначте if (p)стенограму для if (p != null).
• Припустимо s, це рядковий тип. Тепер визначте, if (s)що буде if (s != null && s != "").
• Припустимо a, це тип масиву. Тепер визначте, if (a)що буде if (a != null && a.length > 0).

Ця ідея надання коротких стендів if-тестів здається гарною на поверхні ... поки ви не зіткнетеся з відмінностями в дизайні та думках:

• if (0)трактується як помилкове в C, Python, JavaScript; але трактували як Рубі.
• if ([]) трактується як помилковий в Python, але правда в JavaScript.

У кожної мови є свої вагомі причини, що стосуються виразів так чи інакше. (Так , наприклад, тільки falsy значення в Ruby , є falseі nil, отже , 0є truthy.)

Java прийняла чіткий дизайн, щоб змусити вас надавати булеве значення if-оператору. Якщо ви поспішно перевели код з C / Ruby / Python на Java, ви не можете залишити будь-який розслаблений if-тест незмінним; потрібно виписати умову явно на Java. Виділення хвилини для паузи та думки може врятувати вас від неохайних помилок.

Ну, кожен скалярний тип у С, вказівник, булевий (з С99), число (з плаваючою комою чи ні) та перерахування (за рахунок прямого відображення на числа) має "природне" значення фальси, тому це досить добре для будь-якого умовного вираження .

У Java теж є (навіть якщо вказівники Java називаються посиланнями і сильно обмежені), але вона ввела автобокс в Java 5.0, що заплутує води неприйнятно. Також Java-програмісти підкреслюють внутрішнє значення набору тексту більше.

Однією помилкою, яка породила дискусію щодо обмеження умовних виразів булевим типом, є помилка написання завдання, де було призначено порівняння, яка вирішується не обмеженням типу умовних виразів взагалі , а забороною використання голого призначення-виразу за його цінністю.

Будь-який сучасний компілятор C або C ++ обробляє це легко, подаючи попередження або помилку для таких сумнівних конструкцій, якщо їх запитують.
У тих випадках, коли це саме те, що було призначено, додавання дужок допомагає.

Підводячи підсумок, обмеження на булеві (і коробковий еквівалент у Java) виглядає як невдала спроба скласти клас помилок, спричинених вибором =для компіляції помилок компіляції.

Моє запитання не пов'язане з поганим стилем кодування. Я знаю його погано, але я втручався в те, чому C це дозволяє, а java ні.

Двома з цілей дизайну Java були:

1. Дозвольте розробнику зосередитись на бізнес-проблемі. Роблять простіші і менш схильні до помилок, наприклад, збирання сміття, щоб розробникам не потрібно було зосереджуватися на витоках пам'яті.

2. Переносний між платформами, наприклад, працювати на будь-якому комп'ютері з будь-яким процесором.

Відомо, що використання завдання як виразу спричиняє багато помилок через помилки друку, тому в цілі №1 вище заборонено спосіб, яким ви намагаєтесь його використовувати.

Крім того, висновок про те, що будь-яке ненулеве значення = істинне і будь-яке нульове значення = хибне, не обов’язково є портативним (так, вірите чи ні, деякі системи трактують 0 як істинне, а 1 - як хибне ), тому під ціллю №2 вище не допускається неявно . Зрозуміло, ви можете відігравати явну роль.

Як приклад, що роблять інші мови: Swift вимагає вираження типу, який підтримує протокол "BooleanType", а це означає, що він повинен мати метод "boolValue". Тип "bool" очевидно підтримує цей протокол, і ви можете створити власні типи, що підтримують його. Типи цілих чисел не підтримують цей протокол.

У старих версіях мови додаткові типи підтримували "BooleanType", щоб ви могли написати "if x" замість "if x! = Nil". Що зроблено за допомогою "необов'язкового bool" дуже заплутано. Необов'язковий bool має значення nil, false або true, і "якщо b" не виконується, якщо b було нульовим, а виконується, якщо b є true або false. Це більше не дозволено.

І, здається, є один хлопець, який справді не любить відкривати вам кругозір ...