編譯器語法太嚴格

⑴ 編譯器的工作原理

編譯 是從源代碼（通常為高級語言）到能直接被計算機或虛擬機執行的目標代碼（通常為低級語言或機器語言）的翻譯過程。然而，也存在從低級語言到高級語言的編譯器，這類編譯器中用來從由高級語言生成的低級語言代碼重新生成高級語言代碼的又被叫做反編譯器。也有從一種高級語言生成另一種高級語言的編譯器，或者生成一種需要進一步處理的的中間代碼的編譯器（又叫級聯）。
典型的編譯器輸出是由包含入口點的名字和地址， 以及外部調用（到不在這個目標文件中的函數調用）的機器代碼所組成的目標文件。一組目標文件，不必是同一編譯器產生，但使用的編譯器必需採用同樣的輸出格式，可以鏈接在一起並生成可以由用戶直接執行的EXE,
所以我們電腦上的文件都是經過編譯後的文件。

⑵ C語言的編譯器為什麼有許多不同的版本並且在不同的編譯器版本下C語言的語法規則也不盡相同

C的標准本來就有多個版本,目前編譯器採用的標准比較常見的是ANSI C和C99。另外語言標准中也存在未定義行為,留給編譯器實現自己去定義。各種編譯器對標準的實現也未必完全遵守(C還好,C++這種特別復雜的語言就很難做到完全遵守標准了),而且往往還增加一些自己的擴展,預定義宏之類的。這些都給跨編譯器編碼帶來麻煩。不過總體而言C是個比較單純的語言,除非程序員故意,一般搞不出太多給編譯器出難題的花樣。作為長期用C++的程序員,非常羨慕C代碼編譯時那種飛快的速度。
麻煩採納，謝謝!

⑶ 為什麼編譯器需要復雜的語法

新的版本都是基於舊的版本升級過來的，以此來改善編譯器的性能、增加對新平台的支持以及提高競爭能力。不同的編譯器支持的標准語法是一致的(不然沒資格稱C編譯器)，但是每個編譯器自身可以添加額外的語法、庫來擴展語言的表達能力，這就是所謂的xx編譯器擴展。使用語言擴展通常能獲得較高的性能和靈活性，但是損失了跨平台性。不僅僅是編譯器有很多版本，語言本身都有很多版本，目前C語言的版本是C11，下一個版本為C1y。

⑷ 請問編程語法規則，是不是根據不同編譯器來定的

不，一個語言的語法是早就確定好的，它有一個統一標准——例如 ANSI C。
不同編譯器可能有些許不同，比如有的編譯器a=b=c結果很可能不一樣（所以我們很少這么用
但是大體上，一個語言的編譯器得出的結果是一樣的，是根據語法規則做出編譯器而非編譯器確定語法規則。
zhengshu a=0，編譯器肯定不認，理由是沒有這個type；但是你可以通過typedef自定義任意的類型。

int是一種type，而type varlist;是聲明變數的語法（int a; char b;）

你寫了int a=0;那麼這時編譯器做的就是在內存中開出一個能存int數據的空間，然後把0給填進去，再記錄下這塊內存的地址，並記住這個地址叫做a。至於分析代碼什麼的，就是編譯器的事情了。

——以上。

⑸ c程序在書寫時有嚴格的縮進要求否則不能編譯通過

所有的C語言編譯器是沒有這樣的規定的。C語言本身是一種非常靈活的編程語言，包括它的書寫格式和語法表達。C語言每一個語句都是以「；」結束，只要遵循這個原則即可，並沒有強制要求必須以縮進方式編寫程序，也不影響程序的編譯。通常以縮進方式編寫程序是一種比較提倡的好的習慣和做法，有利於對程序的理解和檢查。

⑹ linux下編譯tslib，configure之前都正常，但make後就出現錯誤啦，求解。。

gcc 新版本編譯器對語法檢查嚴格，在源文件 ./tests/ts_calibrate.c 中

// 源文件
// if ((calfile = getenv("TSLIB_CALIBFILE")) != NULL) {
// cal_fd = open (calfile, O_CREAT | O_RDWR);
// } else {
// cal_fd = open ("/etc/pointercal", O_CREAT | O_RDWR);
// }
// 需要更改成如下形式
if ((calfile = getenv("TSLIB_CALIBFILE")) != NULL) {
cal_fd = open (calfile, O_CREAT | O_RDWR, 0777);
} else {
cal_fd = open ("/etc/pointercal", O_CREAT | O_RDWR, 0777);
}保存後重新編譯即可

⑺ delphi編譯器效率高到底是指什麼

所謂delphi編譯器效率高，一般指的是以下三方面：

1、編譯連接時間短，這一點是其他任何編譯器都無法相比的（一般來說，VC, VB編譯過程所用的時間是Delphi的幾倍），原因很簡單：Pascal語法限制嚴格，用戶必須規范地編碼，省去了編譯器的很多麻煩。

2、編譯出的程序執行速度快，產生的代碼長度短。這一點比VB強，但和VC基本一樣，誰也沒有優勢。不過很多人有誤解，以為Delphi類庫龐大復雜，加一個控制項就要把整個一個源文件全部加進來，代碼長度太大，效率太差。其實真實情況是，擁有眾多VCL控制項類庫，是Delphi的一個獨特之處，VC的MFC庫無法與之相比——MFC有的底層簡單封裝的類，VCL庫都有，但VCL有的上層組件，MFC卻根本沒有。使用VCL上層應用控制項後，代碼長度的確比VC大，不過VC卻沒有這方面的選擇，而VC所用的從底層一磚一瓦地編碼的方式，Delphi完全支持，而且絕對沒任何劣勢，代碼長度也不長（VC的語法復雜，按C程序員一般習慣做的話，代碼長的反而會是VC）。產生誤解的原因，是多數Delphi程序員是應用級的，而VC程序員是底層些的，應用程序員大多不太懂得底層代碼的編寫，只會搬控制項、響應事件，以為底層的東西Delphi做不來。

3、對應用級的程序開發周期短——這也就是Borland一貫吹捧的「快速開發工具」的含義。正因為VCL的存在（封裝了很多界面組件以及通訊、資料庫、internet應用等很多後台功能），對高層應用不再需要一磚一瓦地受累，使開發周期縮短了很多倍。

單純從技術角度說，編譯器效率應該指編譯出的代碼是否短小/運行速度是否快，以及是否能用較少的源代碼高效地實現復雜功能。前一方面Delphi並不比VC差，而比VB強，但並非一騎絕塵；後一方面則的確有一騎絕塵之象。

Delphi的致命缺點，其實不是技術——技術它是領先的，毫無疑問，問題是市場策略和公司實力（Borland只是家小公司），微軟「攜操作系統以令諸侯」，誤導了眾多軟體開發公司，讓它們以為微軟的才正宗和好用，造成了事實上的VB，VC用戶群遠比Borland的龐大，源代碼數量也一樣是C/C++遠遠占優，而Borland的C++ Builder卻開發得太晚難以形成市場優勢。

概括來說，如果你要開發上層應用為主的程序，特別是資料庫方面的程序，那麼Delphi能讓你省不少時間；而若開發底層些的軟體，為能有更多相關代碼可以參考利用，為能容易地招聘到更合適的程序員，以及為了代碼維護方便，都適合用C/C++去做，當然，C++ Builder從技術上說是個不錯的選擇，只是用戶群還太小。

⑻ 為什麼proteus8.6自帶的編譯器只能寫2k的程序,怎麼樣可以設置大一點

proteus自帶編譯器不太好用，語法比較嚴格。最好的還是安裝使用keil編譯器，是標準的C語言語法，且沒有2K限制。

⑼ 編譯器錯誤●怎麼辦

這是兩個截然不同的概念。不是叫做：編譯器錯誤，而是應該叫做：編譯錯誤。如果說真的是編譯器內部本身（例如：C語言編譯器、或者是別的各種編程語言的編譯器）出現了bug 的話，那麼任何人也沒有辦法。只有開發編譯器軟體的軟體開發人員才能夠解決這樣的問題；
如果是在你的源程序中產生的各種編譯錯誤（例如：語法錯誤、語義錯誤等），那麼你只能夠仔細地檢查、編譯、調試你的源程序了。

⑽ C語言的特點有哪些

1. C語言是一個有結構化程序設計、具有變數作用域以及遞歸功能的過程式語言。

2. C語言傳遞參數均是以值傳遞，另外也可以傳遞指針。

3. 不同的變數類型可以用結構體組合在一起。

4. 只有32個保留字，使變數、函數命名有更多彈性。

5. 部份的變數類型可以轉換，例如整型和字元型變數。

6. 通過指針，C語言可以容易的對存儲器進行低級控制。

7. 預編譯處理讓C語言的編譯更具有彈性。

(10)編譯器語法太嚴格擴展閱讀：

C語言是一門面向過程的計算機編程語言，與C++，Java等面向對象的編程語言有所不同。其編譯器主要有Clang、GCC、WIN-TC、SUBLIME、MSVC、Turbo C等。