Ось уривок із підручників Java із Sun :
Комутатор працює з
byte,short,charіintпримітивними типами даних. Вона також працює з перерахованими типами (обговорювалися в класах і успадкування) і кілька спеціальних класів, «загорнути» деякі примітивні типи:Character,Byte,Short, іInteger(обговорюваний в об'єкти Simple Data).
Повинна бути поважна причина, чому longпримітивний тип даних заборонено. Хтось знає, що це?
Відповіді:
Я думаю, що певною мірою це було довільне рішення, засноване на типовому використанні комутатора.
По суті, комутатор може бути реалізований двома способами (або, в принципі, комбінацією): для невеликої кількості випадків або тих, значення яких широко розподілені, комутатор, по суті, стає еквівалентом серії ifs для тимчасової змінної ( значення, яке вмикається, має бути оцінене лише один раз). Для помірної кількості випадків, які є більш-менш послідовними за значенням, використовується таблиця перемикачів (інструкція TABLESWITCH на Java), завдяки якій місце для переходу ефективно шукається в таблиці.
Кожен із цих методів в принципі міг використовувати довге значення, а не ціле число. Але я думаю, що це було, мабуть, просто практичне рішення, щоб збалансувати складність набору інструкцій та компілятора з реальною потребою: випадки, коли вам дійсно потрібно перейти на довгий час, є досить рідкісними, щоб прийнятно було переписати як серія операторів IF або обробляти якимось іншим способом (якщо довгі значення, про які йдеться, знаходяться близько один до одного, ви можете у своєму коді Java переключити результат int віднімання найменшого значення).
Оскільки вони не реалізували необхідні інструкції в байт-коді, і ви дійсно не хочете писати стільки випадків, незалежно від того, наскільки ваш код готовий до виробництва ...
[РЕДАГУВАТИ: Витягнуто з коментарів до цієї відповіді, з деякими доповненнями на задньому плані]
Якщо бути точним, 2³² - це багато випадків, і будь-яка програма з методом, достатньо довгим, щоб вмістити більше, ніж це, буде надзвичайно жахливою! Будь-якою мовою. (Найдовша функція, яку я знаю в будь-якому коді будь-якою мовою, - це трохи більше 6k SLOC - так, вона велика switch- і насправді некерована.) Якщо ви справді застрягли в тому, longде ви повинні мати лише intабо менше, тоді у вас є дві реальні альтернативи.
Використовуйте якийсь варіант на тему хеш-функцій, щоб стиснути longфайл до int. Найпростіший, лише для використання, коли ви неправильно помилився з типом, - це просто кастинг! Більш корисним було б зробити це:
(int) ((x&0xFFFFFFFF) ^ ((x >>> 32) & 0xFFFFFFFF))
перед увімкненням результату. Вам доведеться розробити, як трансформувати випадки, на яких ви тестуєте. Але насправді це все ще жахливо, оскільки це не стосується справжньої проблеми багатьох справ.
Набагато кращим рішенням, якщо ви працюєте з дуже великою кількістю випадків, є зміна дизайну на використання Map<Long,Runnable>або чогось подібного, щоб ви шукали, як відправити певне значення. Це дозволяє розділити справи на декілька файлів, що набагато простіше управляти, коли кількість випадків стає більшою, хоча це ускладнює організацію реєстрації хосту задіяних класів реалізації (анотації можуть допомогти, дозволяючи вам автоматично створювати реєстраційний код).
FWIW, я зробив це багато років тому (ми перейшли на нещодавно випущений J2SE 1.2 через проект), будуючи власний механізм байт-коду для моделювання масивно паралельного обладнання (ні, повторне використання JVM не було б придатним через радикально різні моделі значення та виконання), і це надзвичайно спростило код щодо великого, switchщо використовувалася у версії коду C.
Щоб повторити повідомлення про прийняття додому, бажання switchна a long- це ознака того, що або ви неправильно помилилися у вашій програмі, або що ви будуєте систему з такою великою кількістю змін, що вам слід використовувати класи. У будь-якому випадку час для переосмислення.
Map<Long,Runnable>щоб вирішити проблему зовсім по-іншому. :-)
switch? Бажання вибрати з кінцевого набору з того, що багато елементів просто вказує на помилку у фундаментальному дизайні програми. Те, що люди просять про це, означає лише те, що ** вони неправильно розробили свій дизайн .
longкількість рядків, мені конкретно потрібно лише 4. Це випадок, коли мені longвручають, який вказує, на який рядок діє, і мені потрібно робити різні речі, виходячи з того, який це рядок. Думаю, я міг би перейти на int, але це полегшило б мені життя, якби я міг просто switchредагувати змінну. В даний час я просто використовую рядок ifі else ifзамість цього.
longзнака не означає, що ви збираєтеся перевірити всі можливості, так само, як наявність значка intабо a String, не означає, що це теж. Це означає, що у вас є величини, яких може бути декілька, мають великий діапазон . Ви можете перевірити кілька простих випадків і вникнути в defaultрешту. Потрібно робити зміни і касти означає, що ви ризикуєте втратити дані. Підсумок: це неправильне рішення щодо дизайну Java, а не проблема користувача.
Оскільки індекс таблиці пошуку повинен складати 32 біти.
switchне потрібно обов'язково реалізовувати таблицю пошуку.
Довгий, в 32-бітній архітектурі, представлений двома словами . А тепер уявіть, що може статися, якщо через недостатню синхронізацію виконання оператора перемикання спостерігає long з його високими 32 бітами від однієї записи, а 32 низькими - від іншої! Можна спробувати поїхати до .... хтозна куди! В основному десь навмання. Навіть якби обидва записи представляли дійсні випадки для оператора switch, їх смішна комбінація, мабуть, не призвела б ні до першого, ні до другого - або вкрай гірше, це могло б призвести до іншого дійсного, але не пов’язаного між собою випадку!
Принаймні з int (або меншими типами), незалежно від того, наскільки сильно ви зіпсуєте, оператор switch буде принаймні читати значення, яке хтось насправді написав , замість значення "з повітря".
Звичайно, я не знаю фактичної причини (минуло більше 15 років, я так довго не звертав уваги!), Але якщо ви зрозумієте, наскільки небезпечною та непередбачуваною може бути така конструкція, погодьтеся, що це, безумовно, дуже вагома причина, щоб ніколи не вмикати longs (і як передбачалося long -pun - буде 32-бітна машина, ця причина залишатиметься чинною).
ifтакож і результату буде таким же поганим: неправильний результат ~> неправильна гілка взята. Створення довго if- else- ifланцюг замість того , щоб switchфактично призведе до точно такого ж результату.