Що відрізняється між "написанням конкретного JRE для кожної платформи" для розробників Java та "написанням компілятора C ++ для кожної платформи" для C ++?
Що відрізняється між "написанням конкретного JRE для кожної платформи" для розробників Java та "написанням компілятора C ++ для кожної платформи" для C ++?
Відповіді:
Java компілюється після запуску в будь-якому місці. C ++ - це написання одного разу компіляція в будь-якому місці.
"написання конкретного JRE для кожної платформи" - це не те, що ви робите кожен раз. Перенесення JRE на нову платформу - це те, що вам потрібно зробити лише один раз. Це завдання, як правило, виконується основним обслуговувачем / розробниками програми та / або платформи. Дуже багато факторів можуть зігратись при вирішенні питання про те, хто і як буде переноситися JRE. Крім усього іншого, це залежить від ліцензованої версії, опублікованої під ним (я чую, що Java є відкритим кодом, тому, мабуть, хтось міг би це зробити). Смішний анекдот, Стів Джобс зробив велику справу про те, що не хотів піклуватися про перенесення Java на Mac близько року тому.
Справа не в тому, як або хто портує JRE, а в тому, що колись він переноситься, кожен додаток Java тепер теоретично повинен легко працювати на новій машині. У цьому сенсі JRE утворює шар абстракції, повністю приховуючи машину, дозволяючи легко переносити.
Однак реальність не завжди така, як така. Я не піду, як називати портативність "міфом", але це правда, що це не так ідеально. Наприклад, у Java є пакет, який називається, JNIякий дозволяє надсилати натільні дзвінки, обходячи JRE, таким чином запобігаючи ідеальну безперебійну переносимість, як любителі Java називати "Пишіть, як тільки запустіть всюди".
Як зазначалося в коментарях, підхід C ++ до портативності відрізняється. З одного боку, це компільована мова, і ці двійкові файли майже завжди є специфічними для платформи. Тож виконувані файли c ++ ніколи не будуть портативними (на відміну від Java). З іншого боку, перенесення компілятора іноді може бути достатньо. Спільнота виявила, що, перенісши компілятор, а також деякі основні бібліотеки мови, вихідні коди (а не бінарні файли) можуть бути переносними.
Однак C ++ широко використовується в таких критичних системах, як компілятори, ядра, системи в режимі реального часу, вбудовані системи ... Існує "низький рівень" аспекту C ++, який неможливо не помітити, якщо говорити про портативність.
Це не лише мова - це бібліотеки.
І Java, і C ++ забезпечують бібліотеки між платформами. Java забезпечує більш багатий набір.
Різниця полягає в тому, що Java працюватиме на будь-якій платформі без перекомпіляції. Наявність компілятора C ++ для кожної платформи зовсім не однакова.
Усі відповіді, що починаються з "Різниця - це ...", або що-небудь дуже схоже, в основному неправильні (вибачте, але таке життя). Дійсно є дві окремі відмінності між ними.
Одне (про що було сказано багато) полягає в тому, що складена програма Java може (або, щонайменше, повинна) працювати на будь-якій відповідній реалізації Java, тому навіть після її складання ви все одно можете переміщати програму Java з однієї платформи на іншу без повторного компіляції. . C ++ (принаймні зазвичай) вимагає перекомпіляції для кожної цільової платформи.
Інша полягає в тому, що Java (принаймні, намагається) запевнити, що всі правильно написані Java будуть портативними. Принаймні теоретично, ви не повинні мати можливість писати будь-який код, який не є портативним.
C ++ дозволяє робити дуже багато речей, які не є портативними. Стандарт C ++ містить "попередження" про багато речей, які не є портативними (наприклад, говорять про те, що ви отримаєте певну реалізацію поведінку або невизначену поведінку), але це не обов'язково намагатися взагалі не заважати вам робити їх. . Наприклад, якщо ви хочете написати операційну систему для обладнання, яке використовує шину PCI, вам, ймовірно, потрібно буде прочитати / записати пам'ять конфігурації PCI. Це, очевидно, не може бути портативним для систем без шини PCI, але якщо ви пишете операційну систему для апаратного забезпечення з шиною PCI, це дуже необхідно. C ++ дозволяє це, хоча він, очевидно, не буде портативним.
Ви неправильно зрозуміли приміщення. Програми Java дуже портативні, оскільки JVM забезпечує стандартну поведінку, гарантовано однакову. Програми C ++ мають менш стандартизоване середовище, наближене до фактичного обладнання, тому програма повинна вміти обробляти різні деталі платформи - наприклад, розмір int, вирівнювання слів тощо тощо тощо.
Сам JVM не дуже портативний. Перенести високоефективний JVM на іншу платформу або архітектуру процесора - це геркулесова задача.
Різниця полягає в тому, що програми Java (це не абревіатура) можуть бути розповсюджені у формі, яку можна запустити на будь-якому комп’ютері зі встановленим JVM, але C ++ зазвичай розповсюджується як вихідний код, який дуже непривітний для користувачів, або як купа різних бінарних файлів для різних платформ.
Однією з причин, яку Java вважають переносною, є те, що вона має конкретні правила того, як арифметичні вирази повинні бути оцінені, і забороняє реалізаціям оцінювати їх будь-яким іншим способом, навіть коли оцінювання їх відповідно до мандатів вимагатиме повільнішого коду, ніж більш точне їх оцінювання. мода.
Наприклад, дано
long thing1(int x) {
return (x+1)-1L;
}
double thing2(int x, float y) {
return x/y;
}Значення thing1(2147483647)та thing2(1123456700,11234567.0f)повинні бути -2147483649L та 99.9999923706054688 відповідно, навіть якщо арифметично правильні значення становитимуть 2147483647L та 100.0, і хоча на деяких платформах код для генерування числово-неправильних результатів буде повільніше, ніж код для створення правильних результати (на деяких 64-бітних платформах для примусової поведінки загортання після (x + 1) потрібна буде додаткова інструкція, а на платформі 8x87, змушуючи округлювати значення 1123456700 до значення floatзнадобиться додаткова інструкція порівняно з просто завантаженням безпосередньо в регістр розширеної точності).
(int)першого прикладу (x+1)в першому прикладі до floatпараметра другого прикладу x, але явно я не створив мову .
Обсяг роботи для опорних інструментів дійсно схожий, різниця полягає в іншому. Після того, як програма C ++ була скомпільована для платформи, її потрібно скомпілювати ще раз, якщо ви хочете використовувати її на іншій платформі. Однак, коли програма java складена, ви можете перемістити її на будь-яку іншу платформу із середовищем виконання, не потребуючи її перекомпіляції.
Відповідаючи на заголовок "Чи портативність є міфом?", Замість "Що краще в портативності, Java або C ++", я скажу, що часткова портативність можлива, але повна портативність - це міф.
Я наполягаю на тому, що я наполягаю, і це стосується цього питання, це те, що розробники вже не працюють лише з простою мовою програмування, але з повноцінними рамками програмування.
І ці рамки включають бібліотеки, бази даних, графічні інтерфейси.
Яка мова програмування або яка програма програмування є більш портативною?
Ну, це залежить від того, який у вас додаток. намагається досягти.
Річ у тому, що "ти" не пишеш JRE, ти пишеш код Java, який працює на будь-якому JRE. «Ви» писати код C ++ , які можуть вимагати зміни від вас , перш ніж він буде компілювати на іншій платформі.
Багато людей забувають або не беруть до уваги реальність Java, коли кажуть, що "це 100% портативний" або фрази на зразок цього.
Насправді всі основні корпорації / програмний дім мали принаймні 1 домашню реалізацію Java з пов'язаним з нею JRE у недавньому минулому, а деякі досі підтримують її, наприклад, Microsoft, IBM і Apple, наприклад, всі мали власну версію Java, що відображає їх власні ідеї та думки про те, куди має йти галузь та така мова.
Як це для "портативних"? JRE де завгодно.
І це не зважаючи на те, що робило Sun / Oracle.
Прикладом того, чому Java-код не дуже далекий від C та C ++ з точки зору переносимості, - це графічні інтерфейси та графічні сервери, Apple мала нестандартну реалізацію рамки GUI для власного JRE, як наслідок, було багато головні болі та подвійна робота для всіх, хто хотів створити / поставити графічний інтерфейс, використовуючи Java для машин Apple, і в основному вони були змушені мати справу з Quartz (як це з точки зору "важелів" та мов високого рівня?).
Іноді навіть найпоширеніші слова, що вживаються, насправді не відображають значення, яке люди зазвичай їм надають, для мене термін «переносимість» у світі Java більше схожий на «світогляд» у здоровому розумінні; у комерційному та фінансовому плані для вас є кращий прогноз, якщо ви перейдете на Java, а не на інші мови (принаймні на той час, коли народилася Java), оскільки у вас вже багато роботи зроблено з одного боку (ви отримуєте JRE на будь-що що можна вважати "комп'ютером"), і ваша кодова база, швидше за все, буде портативною, як є, вам потрібно менше ресурсів для порту вашої програми, це все, чи не вказаний ресурс - це гроші, час або робоча сила не має значення, це нижча Поріг порівняно з іншими технологіями, і для чого саме Java, вона знижує цей поріг.
Звичайно, це справедливо, якщо ви приймаєте приміщення Java, що означає віртуальну машину зі збиранням сміття, а це означає, що вона витрачає більше ресурсів, якщо порівнювати з рідними мовами, якщо ви дійсно хочете вичавити максимум із вашого центрального процесора або серверної ферми I не думайте, що ви можете перейняти Java, якщо ви дуже мало ресурсів або ваша компанія насправді мала.
Я все ще мушу знайти єдине нетривіальне додаток Java, яке містить лише 1 версію для кожного рядка коду чи функціональності (він же без будь-яких специфічних для платформи речей), і він на 100% портативний серед усіх основних JRE.