編譯器的合理性

㈠ 程序編譯器的體系結構適合使用什麼體系結構

計算機體系結構（ComputerArchitecture）是程序員所看到的計算機的屬性，即概念性結構與功能特性。按照計算機系統的多級層次結構，不同級程序員所看到的計算機具有不同的屬性。
一般來說，低級機器的屬性對於高層機器程序員基本是透明的，通常所說的計算機體系結構主要指機器語言級機器的系統結構。
經典的關於「計算機體系結構（computerarchitecture）」的定義是1964年C.M.Amdahl在介紹IBM360系統時提出的，其具體描述為「計算機體系結構是程序員所看到的計算機的屬性，即概念性結構與功能特性」 。

㈡ 計算機有解釋器為什麼還要有編譯器 明顯是編譯器要快捷於解釋器啊…………

下面這個回答可以參考：

編譯器是把源程序的每一條語句都編譯成機器語言,並保存成二進制文件,這樣運行時計算機可以直接以機器語言來運行此程序,速度很快;
而解釋器則是只在執行程序時,才一條一條的解釋成機器語言給計算機來執行,所以運行速度是不如編譯後的程序運行的快的.
這是因為計算機不能直接認識並執行我們寫的語句,它只能認識機器語言(是二進制的形式)

編譯是將源程序翻譯成可執行的目標代碼，翻譯與執行是分開的；而解釋是對源程序的翻譯與執行一次性完成，不生成可存儲的目標代碼。這只是表象，二者背後的最大區別是：對解釋執行而言，程序運行時的控制權在解釋器而不在用戶程序；對編譯執行而言，運行時的控制權在用戶程序。

解釋具有良好的動態特性和可移植性，比如在解釋執行時可以動態改變變數的類型、對程序進行修改以及在程序中插入良好的調試診斷信息等，而將解釋器移植到不同的系統上，則程序不用改動就可以在移植了解釋器的系統上運行。同時解釋器也有很大的缺點，比如執行效率低，佔用空間大，因為不僅要給用戶程序分配空間，解釋器本身也佔用了寶貴的系統資源。

㈢ c語言編譯器的選擇

關於C語言編譯器的選擇(Tc2.0,Tc3.0,Vc6.0等)
我們在學習C語言時通常會面臨C語言編譯器的選擇，事實上C語言編譯器可以分為C和C++兩大類，其中C++是C的超集，均向下支持C。主要的C語言編譯器及特點分別如下:
(1)TC 2.0DOS平台軟體。最經典的C語言編譯器，系統體積小，簡單易學，容易上手，而且很多前人或書籍的程序均基於該編譯器，是學習C語言的首選。不過它不支持滑鼠，但讀者如果掌握幾個快捷鍵，操作時對滑鼠可能就不怎麼需要了，如：F2 存檔 F3 打開程序 Alt+F3在最近打開的文件之間切換 Alt+F5觀察運行結果F9 編譯製作EXE Ctrl+F9編譯並運行Ctrl+Y 刪除當前行 Ctrl+KB定義塊首 Ctrl+KK 定義塊尾 Ctrl+KC復制塊 Ctrl+KY刪除塊Ctrl+KV 移動塊
(2)Tc3.0DOS平台軟體。目前比較不錯的C/C++語言編譯器，支持滑鼠，語法著色，多文檔，錯誤跟蹤也很好，操作與TC2.0有很多類似，TC2.0會用那麼TC3.0也很快會用，缺點是以前很多代碼是用TC2.0設計的，而由於TC3.0語法要求的嚴格性，如要求函數必須定義類型，所以向下存在一定的兼容性問題，所以對於初學者選擇起來很矛盾，建議先學會使用TC2.0,而把TC3.0作為能力的補充和平時工具之用。目前有的教材已經選用該編譯器，不過需要一個較長的調整期，因為很多源代碼需要過渡過來才行，雖然性能上比TC2.0有所提高，但對於初學者沒有質的變化，選擇時需要注意。
(3)VC++ 6.0Windows平台。目前主流的C/C++語言編譯器,包含強大的類和內嵌WinAPI的MFC,具有可視化的編程界面。對於TC等的作品也具有向下兼容的特點，建議讀者選用作為C語言過渡到Windows平台編程的首選工具。當然，作為學習，該系統顯得有點龐大，不過通過入門的學習，調試舊的Tc程序也可以。還有其他的編譯器，例如Win tc、gcc、lcc、BC 3.1等等,事實上，編譯器的選擇不是最重要的，他們都可以完成基本的C語言編譯，不過面向考試的時候，還是根據考試的要求，因為編譯器的編譯結果存在著一定的差別，特別在一些復雜語法的語句編譯上。從目前的形勢看，對於從未學習過計算機程序設計的讀者來說，學習C語言時，建議開始選擇Tc2.0,雖然不能使用滑鼠，但幾個快捷鍵的熟練運用基本上可以解決操作的問題，當然有時間的時候了解使用TC3.0就更好了；對於學習過TC2.0的讀者來說，平時完全可以在TC3.0或VC 6.0下調試程序，但考試的時候如果要求必須在TC2.0下，那最好上機練習時在TC2.0下。當然，使用如記事本等文本編輯器編輯程序，然後用TC來調試也不失為一種好方法。另外，DOS平台的Tc2.0或Tc3.0都存在某些機器運行時鍵盤響應遲緩或停頓的問題，Tc3.0可能這種現象要多一點，這主要是由DOS基本內存的不足造成的。可以安裝水平考試課題組提供的DOS模擬器來解決問題，該模擬器重新劃分更多的內存，效果不錯。
新的類似軟體平台也需要讀者關注，那就是java和Viusal C#,因為從發展的眼光來看，目前軟體設計平台有一定的趨同趨勢。例如：java和C#，都來自於C和C++,都作了不錯的擴展和優化。對於深入學習C語言的同學，未來幾年請務必學習VisualStudio.Net或者Java,因為這二者代表了現在的軟體設計主流。他們的主要特點是：優秀的IDE設計環境，強大的WEB服務設計功能，對C++的優化和擴充，基於虛擬機的運行模式，優秀的面向系統開發，可視化的較為成熟的面向對象的程序設計機制等等.

㈣ 編譯器具體實現中比較巧妙的思想有哪些

這種做法的好處是：
可以作為解釋器性能升級的一個簡單路徑，寫解釋器的代碼而得到初級編譯器的性能。事實上JamVM的解釋器可以配置為多種實現方式：switch-threading、indirect-threading、direct-threading、inline-threading，它們的差別僅在於對opcode的dispatch方式不同；所有實現方式都共享同一份handler代碼。
這種做法的缺點是：
這樣寫得到的「編譯器」無論從代碼組織還是程序思路都還是解釋器的那套，從編譯器的角度看很別扭。它最終實現出來效果跟從編譯器角度出發的template-based JIT一樣，但我覺得後者的思路更直觀，代碼也通常更清晰一些。
這種做法仍然無法跨越位元組碼邊界做任何優化，因為每個opcode對應一個單獨的handler，而這種做法的代碼生成僅僅是把handler拷貝到一起而已。
要在它的基礎之上進一步提高性能可以直接對位元組碼序列做些簡單模式匹配，以便跨越位元組碼邊界做優化。但這樣做通常是自討苦吃，工程上很難持續下去。

㈤ 編譯器本身是如何進行測試的

編譯器最重要的性質就是保證語義的正確。比如，從高級語言翻譯到機器指令之後，指令必須正確的表達原來程序的意思。所以一般編譯器測試都包含一些源程序，用來覆蓋可能出現的各種情況。基本的原則是：原來程序的結果 = 編譯後機器指令運行的結果。機器指令運行的結果很容易知道，運行一下就知道了。可是原來程序的結果你怎麼知道呢？
為了解決這個「原來程序語義」的問題，最好是寫一個解釋器，准確無誤的表達原來的代碼的語義。所以我們的要求就是：
高級語言解釋器（源程序） = 機器執行（機器代碼）
由於處理器其實就是一個用來執行機器代碼的解釋器，這里有一個很美好的對稱關系：
interp1(L1) = interp2(L2)
另外還有一個問題，就是編譯器一般需要經過多個轉化步驟（叫做 pass）才能最後編譯為機器指令。比如，
L2 = pass1(source)
L3 = pass2(L2)
L4 = pass3(L3)
Ln = passN(Ln-1)
machine_code = codegen(Ln)
由於源程序經過了很多步驟猜得到最後的機器指令，如果你使用上面的公式，就會出現以下一些情況：
1. 知道結果錯了，但是卻不知道到底是哪一個 pass 錯了。
2. 結果沒有錯，但是中間卻有 pass 實際上是錯的。但是由於之前的 pass 把輸入程序的一些結構給「優化」掉了，所以錯的那個 pass 其實沒能得到觸發錯誤的那個數據結構。所以測試沒能發現錯誤。如果以後前面的那個 pass 被修改，錯誤就會暴露出來。這是非常難以發現的潛伏的危險。
為了防止這些情況出現，一些編譯器（比如 Chez Scheme 和 Kent Dybvig 的課程編譯器）使用了對每一個 pass 進行測試的做法。具體的方法就是為每一個中間語言都寫一個解釋器，把這語言的語義完全的表示出來。這樣我們就需要檢查一組等式：
L2 = pass1(source)
高級語言編譯器（源程序） = interp2(L2) // 測試 pass1 的正確性
L3 = pass2(L2)
interp2(L2) = interp3(L3) // 測試 pass2 的正確性
這樣一來我們就能獨立的判斷每一個 pass 的正確性了。
這些是基本的語義測試原理。另外除了語義，可能還有一些「表面」一些的測試，它們看代碼本身，而不只看它的語義。比如尾遞歸優化的測試應該確保輸出程序的尾遞歸得到正確的處理，等等。這些是語義測試檢查不到的，因為尾遞歸沒有正確處理的程序大部分也能輸出正確的結果。
普通的單元測試方法也可以用來測試一些編譯器里的輔助函數，但那些不是編譯器特有的，所以就不講了。
另外，就像所有測試的局限性一樣，你沒法枚舉所有可能出現的輸入，所以以上的測試方法其實也不能保證編譯器的完全正確。

㈥ 編譯器的組成及各部分的功能及作用

1. 詞法分析 詞法分析器根據詞法規則識別出源程序中的各個記號（token），每個記號代表一類單詞（lexeme）。源程序中常見的記號可以歸為幾大類：關鍵字、標識符、字面量和特殊符號。詞法分析器的輸入是源程序，輸出是識別的記號流。詞法分析器的任務是把源文件的字元流轉換成記號流。本質上它查看連續的字元然後把它們識別為「單詞」。 2. 語法分析 語法分析器根據語法規則識別出記號流中的結構（短語、句子），並構造一棵能夠正確反映該結構的語法樹。 3. 語義分析 語義分析器根據語義規則對語法樹中的語法單元進行靜態語義檢查，如果類型檢查和轉換等，其目的在於保證語法正確的結構在語義上也是合法的。 4. 中間代碼生成 中間代碼生成器根據語義分析器的輸出生成中間代碼。中間代碼可以有若干種形式，它們的共同特徵是與具體機器無關。最常用的一種中間代碼是三地址碼，它的一種實現方式是四元式。三地址碼的優點是便於閱讀、便於優化。 5. 中間代碼優化 優化是編譯器的一個重要組成部分，由於編譯器將源程序翻譯成中間代碼的工作是機械的、按固定模式進行的，因此，生成的中間代碼往往在時間和空間上有很大浪費。當需要生成高效目標代碼時，就必須進行優化。 6. 目標代碼生成 目標代碼生成是編譯器的最後一個階段。在生成目標代碼時要考慮以下幾個問題：計算機的系統結構、指令系統、寄存器的分配以及內存的組織等。編譯器生成的目標程序代碼可以有多種形式：匯編語言、可重定位二進制代碼、內存形式。 7 符號表管理 符號表的作用是記錄源程序中符號的必要信息，並加以合理組織，從而在編譯器的各個階段能對它們進行快速、准確的查找和操作。符號表中的某些內容甚至要保留到程序的運行階段。 8 出錯處理用戶編寫的源程序中往往會有一些錯誤，可分為靜態錯誤和動態錯誤兩類。所謂動態錯誤，是指源程序中的邏輯錯誤，它們發生在程序運行的時候，也被稱作動態語義錯誤，如變數取值為零時作為除數，數組元素引用時下標出界等。靜態錯誤又可分為語法錯誤和靜態語義錯誤。語法錯誤是指有關語言結構上的錯誤，如單詞拼寫錯、表達式中缺少操作數、begin和end不匹配等。靜態語義錯誤是指分析源程序時可以發現的語言意義上的錯誤，如加法的兩個操作數中一個是整型變數名，而另一個是數組名等。

㈦ c++各種編譯器有什麼不同，應該不存在哪種編譯器最好的說法吧是不是只要學會用一種編譯器就可以了

每種編輯器適用環境都是不一樣的。對於初學者來說 如果你想學習linux gcc是一個非常不錯的編輯器。。又是開源的。。其他的要依你的編程環境來確定。。標准C的程序編輯器基本都支持的。所以簡單的程序選擇哪一種都差不多，但是如果用到專業的函數 比如itoa 這就是windos 特有的函數了 也就是說只有VC支持

㈧ sizeof(a)++編譯通過,++sizeof(a)報告缺少合法的左值

關鍵是要把sizeof(a)++理解為：sizeof((a)++)，詳情請看後面的分析。

1.要理解sizeof運算符的語法，其實sizeof後面可以直接跟表達式的，
如：sizeof a; // 與sizeof(a);等價
sizeof a+1； // 與sizeof(a+1);等價

2.要理解sizeof後面的表達式到底會不會被編譯程序編譯，並進行真正的計算
其實編譯器只想知道sizeof 後面的表達式的類型（進而知道所佔存儲空間），但是並不會真正的計算後面的表達式。
如：sizeof b=3+1; // 假設b原來為0，則編譯這條語句以後b仍會為0

下面我們分析一下sizeof(a)++; //合法,編譯通過
根據第一條，我們應這樣理解該表達式：sizeof((a)++);即sizeof運算符求的是後面整個表達式((a)++)的類型；
而不能理解為:(sizeof(a))++;，否則4++;也可以通過編譯。
那麼既然把((a)++)看作了整體，為什麼a的值不會加1，可根據第二條解釋：由於整個表達式作為sizeof的參數，所以表達式((a)++)的值根本沒有計算。

對於++sizeof(a);顯然不能通過編譯，這里就不解釋了。

下面我們用一個例子說明以上分析的合理性：

#include<stdio.h>
int main(int arg,char **argc)
{
int a=0,b=0;
sizeof a; // 說明sizeof對於簡單的表達式可以後面不用括弧，佐證論點1

sizeof (b=3+1); // 說明sizeof裡面的表達式並不會計算，佐證論點2
printf("b=%d\n",b);
return 0;
}

程序的輸出結果為：b=0
這說明了sizeof裡面的表達式並不計算，因此樓主的sizeof(a)++;中a的值不變是可以理解的。

㈨ 如何更改c++編譯器設置。

你好，我剛開始也不習慣這個末尾要加空格的警告，因為最初學慣用vc6時沒有這個要求。後來漸漸習慣了，再說這個在末尾加一行空格還可以提醒你檢查下末尾是否完整，挺好的呀。我感覺你沒有必要非要把這個警告去掉，現在好多編譯器都有這個警告，這個設計也有其合理性。
謝謝，望採納。