Що зупиняє C від компіляції / інтерпретації / JIT'ed?

Яву часто хвалять за свою дивовижну портативність, яку, я вважаю, є завдяки JVM. Моє запитання полягає в тому, що перешкоджає компілюванню / інтерпретації / JIT'ed .., якщо це так, C також можна написати один раз і змусити його працювати на будь-якому пристрої, який у вас є. але це не популярний механізм обробки програми С.

Які недоліки обробки C таким чином, а також які переваги обробки Java таким чином, а не компіляція до машинного коду, крім переносимості звичайно?

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

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

Що зупиняє C від інтерпретації чи джитінгу? Нічого. Але це не є причиною розвитку С.

Перш за все, варто відзначити, що JVM Sun написаний на C. C - дуже популярна мова, коли потрібна портативність.

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

На практиці це насправді не набагато складніше, ніж жити з обмеженнями, які силами Java на вас. Це здебільшого питання пам’яті про свою витривалість та примітивні розміри, а також використовувати портативні бібліотеки типу GTK + замість бібліотек для платформи.

Ви можете зробити компілятор GTK + target та C, який підтримує віртуальну машину, навіть, можливо, JVM, і отримати існуючий код для роботи з дуже невеликими змінами. Насправді, без збору сміття віртуальна машина С могла б бути набагато простішою. Чому б ти хотів цього зробити?

Зворотний, компілюючи Java до рідного коду, також можливий. Це в основному те, що робить JIT. Чому б ти хотів цього зробити? Я впевнений, що існують проекти для домашніх тварин, щоб зробити це "просто тому", але вони не використовуються серйозно.

Ти сказав:

Яву часто хвалять за свою дивовижну портативність, яку, я вважаю, є завдяки JVM.

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

Як приклад, у Java є два типи "int" (підписане 32-бітове ціле число) і "long" (підписане 64-бітове ціле число). C і C ++ мають "int" (підписаний принаймні 16 біт), "long" (підписаний принаймні 32 біт) і "long long" (підписаний принаймні 64 біт). Це тому, що C повинен працювати на багатьох різних процесорах і дозволяє їм поводитися по-різному.

C міг визначити фіксовані розміри для цих типів. Якби це було, то 36-бітні процесори не могли б реалізувати мову С. І вони справді не можуть реалізувати Java! Тому C дозволив мові працювати з різними комп'ютерами. Неминуче, що це дозволяє створювати код, який не є портативним. Це питання мови.

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

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

Насправді є інтерпретовані версії C , але вони, як правило, використовуються для швидкого експерименту, а не виробничої системи.

Вони не звичайні, бо врешті-решт, навіщо ти страждаєш від усіх С ідіосинкразій, якби не отримати невеликий, швидкий та статичний виконуваний файл?

Теоретично і C, і Java можуть бути компільовані до рідного коду, інтерпретуватися або компілюватися у віртуальну машину.

Технічна причина того, що C не компілюється у віртуальну машину, полягає в тому, що стандартної віртуальної машини C просто немає .

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

Власне, це і робиться. Є основні компілятори, які підтримують компіляцію до LLVM (я знаю, що "Кланг" робить, і я вважаю, що gcc також працює). Цей LLVM може бути JIT'd так само, як код Java збирається в байт-код, який є JIT'd.

Однак те, що робить java "крос-платформою" порівняно з C, це те, що Java має велику бібліотеку виконання, яку перенесли на багато платформ. C явно не дотримується цієї парадигми.

Існують деякі основні відмінності між Java та C. Java ізольована від операційної системи через віртуальну машину Java (JVM). JVM віддаляє операційну систему від програми. Програма java може запитати JVM про шматок пам'яті, а потім JVM запитує ОС для цієї пам'яті. Існує багато спільних технологій для різних платформ / операційних систем. JVM - це те, що дозволяє одній і тій же програмі java працювати на різних платформах.

З C немає ізоляції ОС. Програми C (як правило) працюють безпосередньо над ОС, здійснюючи прямі дзвінки в ОС. Це робить зв'язок програми C з певною операційною системою / платформою. Будь-яка нетривіальна програма збирається телефонувати в операційну систему. Крім того, програми C складаються в машинний код, який є специфічним для обладнання. Скомпільовану програму C для x86 неможливо безпосередньо запустити на процесорі ARM.