編譯階段修改註解

Ⅰ 編譯過程分為哪幾個階段各階段的遵循的原則、識別機構、使用的文法編譯原理

編譯原理中的遍概念
編譯階段也常常劃分為兩大步驟，分析步驟和綜合步驟 分析步驟和綜合步驟 分析步驟是指對源程序的分析 －線性分析(詞法分析或掃描) －層次分析(語法分析) －語義分析 綜合步驟是指後端的工作，為目標程序的生成而進行的綜合

你分析過嗎？若按照這種組合方式實現編譯程序，可以設想，某一編譯程序的前端加上相應不同的後 端則可以為不同的機器構成同一個源語言的編譯程序。也可以設想，不同語言編譯的前端生成同一種中間 語言，再使用一個共同的後端，則可為同一機器生成幾個語言的編譯程序。

一個編譯過程可由一遍、兩遍或多遍完成。所謂"遍"，也稱作"趟"，是對源程序或其等價的中間語言程 序從頭到尾掃視並完成規定任務的過程。每一遍掃視可完成上述一個階段或多個階段的工作。例如一遍可 以只完成詞法分析工作；一遍完成詞法分析和語法分析工作；甚至一遍完成整個編譯工作。對於多遍的編 譯程序，第一遍的輸入是用戶書寫的源程序，最後一遍的輸出是目標語言程序，其餘是上一遍的輸出為下 一遍的輸入。

在實際的編譯系統的設計中，編譯的幾個階段的工作究竟應該怎樣組合，即編譯程序究竟分成幾遍， 參考的因素主要是源語言和機器(目標機)的特徵。比如源語言的結構直接影響編譯的遍的劃分；像 PL/1 或 ALGOL 68 那樣的語言，允許名字的說明出現在名字的使用之後，那麼在看到名字之前是不便為包含該名 字的表達式生成代碼的，這種語言的編譯程序至少分成兩遍才容易生成代碼。另外機器的情況，即編譯程 序工作的環境也影響編譯程序的遍數的劃分。遍數多一點，整個編譯程序的邏輯結構可能清晰些，但遍數 多即意味著增加讀寫中間文件的次數，勢必消耗較多時間，一般會比一遍的編譯要慢。

Ⅱ 如何寫一個編譯時註解框架

1、註解

我們日常使用的很多開源庫都有註解的實現，主要有運行時註解和編譯時註解兩種。
運行時註解：主要作用就是得到註解的信息
Retrofit：
調用

@GET("/users/{username}")
User getUser(@Path("username") String username);

定義
@Documented
@Target(METHOD)
@Retention(RUNTIME)
@RestMethod("GET")
public @interface GET {
String value();
}

編譯時註解：主要作用動態生成代碼

Butter Knife

調用
@InjectView(R.id.user)
EditText username;

定義
@Retention(CLASS)
@Target(FIELD)
public @interface InjectView {
int value();
}

2、編譯時註解

要實現編譯時註解需要3步：

1、定義註解（關於註解的定義可以參考下面引用的博客）
import java.lang.annotation.Retention;
import java.lang.annotation.Target;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.ElementType;

@Target({ ElementType.FIELD, ElementType.TYPE })
@Retention(RetentionPolicy.CLASS)
public @interface Seriable
{

}

2、編寫註解解析器
@SupportedAnnotationTypes("annotation.Seriable")
@SupportedSourceVersion(SourceVersion.RELEASE_6)
public class ViewInjectProcessor extends AbstractProcessor {

@Override
public boolean process(Set annotations,
RoundEnvironment roundEnv) {

for (Element ele : roundEnv.getElementsAnnotatedWith(InjectView.class)) {
if(ele.getKind() == ElementKind.FIELD){
//todo
}

return true;
}

@SupportedAnnotationTypes，定義要支持註解的完整路徑，也可以通過getSupportedAnnotationTypes方法來定義
@Override
public Set getSupportedAnnotationTypes() {
Set types = new LinkedHashSet<>();
types.add(InjectView.class.getCanonicalName());

return types;
}

@SupportedSourceVersion(SourceVersion.RELEASE_6)表示支持的jdk的版本
3、創建制定文件resources/META-INF/services/javax.annotation.processing.Processor，並填寫註解解析器的類路徑，這樣在編譯的時候就能自動找到解析器

看上去實現編譯時註解還是很容易的，但是真要完整的實現一個類似Butter Knife的框架，這還只是開始。
Butter Knife是專注View的注入，在使用註解的類編譯後，查看編譯後的class文件，會發現多出了文件，如：
SimpleActivity$$ViewInjector.java
SimpleActivity$$ViewInjector.java,就是通過編譯時註解動態創建出來的，查看SimpleActivity$$ViewInjector.java的內容
// Generated code from Butter Knife. Do not modify!
package com.example.butterknife;

import android.view.View;

import butterknife.ButterKnife.Finder;

public class SimpleActivity$$ViewInjector {

public static void inject(Finder finder, final com.example.butterknife.SimpleActivity target, Object source) {
View view;
view = finder.findRequiredView(source, 2131230759, "field 'title'");
target.title = (android.widget.TextView) view;
view = finder.findRequiredView(source, 2131230783, "field 'subtitle'");
target.subtitle = (android.widget.TextView) view;
view = finder.findRequiredView(source, 2131230784, "field 'hello', method 'sayHello', and method 'sayGetOffMe'");
target.hello = (android.widget.Button) view;
view.setOnClickListener(
new butterknife.internal.DebouncingOnClickListener() {
@Override
public void doClick(
android.view.View p0
) {
target.sayHello();
}
});
view.setOnLongClickListener(
new android.view.View.OnLongClickListener() {
@Override
public boolean onLongClick(
android.view.View p0
) {
return target.sayGetOffMe();
}
});
view = finder.findRequiredView(source, 2131230785, "field 'listOfThings' and method 'onItemClick'");
target.listOfThings = (android.widget.ListView) view;
((android.widget.AdapterView) view).setOnItemClickListener(
new android.widget.AdapterView.OnItemClickListener() {
@Override
public void onItemClick(
android.widget.AdapterView p0,
android.view.View p1,
int p2,
long p3
) {
target.onItemClick(p2);
}
});
view = finder.findRequiredView(source, 2131230786, "field 'footer'");
target.footer = (android.widget.TextView) view;
}

public static void reset(com.example.butterknife.SimpleActivity target) {
target.title = null;
target.subtitle = null;
target.hello = null;
target.listOfThings = null;
target.footer = null;
}
}

inject方法進行初始化，reset進行釋放。inject都是調用Finder的方法與android系統的findViewById等方法很像，再來看Finder類，只截取部分。

public enum Finder {
public T findRequiredView(Object source, int id, String who) {
T view = findOptionalView(source, id, who);
if (view == null) {
String name = getResourceEntryName(source, id);
throw new IllegalStateException("Required view '"
+ name
+ "' with ID "
+ id
+ " for "
+ who
+ " was not found. If this view is optional add '@Nullable' (fields) or '@Optional'"
+ " (methods) annotation.");
}
return view;
}

public T findOptionalView(Object source, int id, String who) {
View view = findView(source, id);
return castView(view, id, who);
}

@Override protected View findView(Object source, int id) {
return ((View) source).findViewById(id);
}

@SuppressWarnings("unchecked") // That's the point.
public T castView(View view, int id, String who) {
try {
return (T) view;
} catch (ClassCastException e) {
if (who == null) {
throw new AssertionError();
}
String name = getResourceEntryName(view, id);
throw new IllegalStateException("View '"
+ name
+ "' with ID "
+ id
+ " for "
+ who
+ " was of the wrong type. See cause for more info.", e);
}
}

findRequiredView方法實際上就是我們常用findViewById的實現，其動態幫我們添加了這些實現。view注入的原理我們就清楚了。
雖然編譯時創建了這個類，運行的時候如何使用這個類呢，這里我用自己實現的一個類來描述
public class XlViewInjector {

static final Map, AbstractInjector> INJECTORS = new LinkedHashMap, AbstractInjector>();

public static void inject(Activity activity){
AbstractInjector injector = findInjector(activity);
injector.inject(Finder.ACTIVITY, activity, activity);
}

public static void inject(Object target, View view){
AbstractInjector injector = findInjector(target);
injector.inject(Finder.VIEW, target, view);
}

private static AbstractInjector findInjector(Object target){
Class clazz = target.getClass();
AbstractInjector injector = INJECTORS.get(clazz);
if(injector == null){
try{
Class injectorClazz = Class.forName(clazz.getName()+"$$"+ProxyInfo.PROXY);
injector = (AbstractInjector) injectorClazz.newInstance();
INJECTORS.put(clazz, injector);
}catch(Exception e){
e.printStackTrace();
}
}

return injector;
}
}
XlViewInjector與ButterKnife，比如調用時我們都會執行XlViewInjector.inject方法，通過傳入目標類的名稱獲得封裝後的類實例就是SimpleActivity$$ViewInjector.java，再調用它的inject，來初始化各個view。
總結一下整個實現的流程：
1、通過編譯時註解動態創建了一個包裝類，在這個類中已解析了註解，實現了獲取view、設置監聽等代碼。
2、執行時調用XlViewInjector.inject（object）方法，實例化object類對應的包裝類，並執行他的初始化方法inject；
因此我們也能明白為什麼XlViewInjector.inject（object）方法一定要在setContentView之後執行。

3、實現註解框架時的坑

解析有用到android api，因此需要創建Android工程，但是android library並沒有javax的一些功能，
在eclipse環境下，右鍵build-path add library把jdk加進來
在android studio下，需要先創建java Library功能，實現與view無關的解析，再創建一個android library功能引用這個工程並實現餘下的解析。

Ⅲ 程序進行預編譯處理時將每個注釋替換為一個空格是什麼意思，有什麼用

可以這么理解：注釋是為人增加代碼可讀性用的，編譯過程不需要，所以在預處理階段編譯器會去掉方便後續的動作

Ⅳ 問下計算機大神，C語言編譯執行時會自動去掉源代碼的注釋符，那麼這個去掉是有規則的還是無規則的亦或

一般情況下是不會反編譯出來的，但也有例外。
c語言是在預處理階段把所有的注釋全部幹掉的。編譯器不接受任何注釋，會直接報錯。
如果你的IDE能提供一個類似於插件之類的工具，在c程序提交編譯之前自動把你所有的注釋變進程序正文中做成那種由雙引號標識的字元串（例如添加一條語句char * _comm_1="Built on 2013-11-11";），而且之後沒有使用類似於混淆器這樣的防止反編譯的技術，那麼對軟體反匯編後是可以看到它們的。
但是正常情況下別人是不可能直接從軟體反編譯的結果上去找你的程序注釋的。

Ⅳ c語言程序編譯時，注釋部分會參加編譯嗎，會出現在目標程序中嗎

不會的，因為注釋被忽略了。

C語言的原型ALGOL60語言（也稱為A語言）。

1963年，劍橋大學將ALGOL60語言發展成為CPL（CombinedProgrammingLanguage）語言。

1967年，劍橋大學的MatinRichards對CPL語言進行了簡化，於是產生了BCPL語言。

1970年，美國貝爾實驗室的KenThompson將BCPL進行了修改，並為它起了一個有趣的名字「B語言」。意思是將CPL語言煮干，提煉出它的精華。並且他用B語言寫了第一個UNIX操作系統。

Ⅵ Java編譯時註解和運行時註解有什麼區別

重寫，重載，泛型，分別是在運行時還是編譯時執行的

1. 方法重載是在編譯時執行的，因為，在編譯的時候，如果調用了一個重載的方法，那麼編譯時必須確定他調用的方法是哪個。如：

當調用evaluate("hello")時候，我們在編譯時就可以確定他調用的method #1.

2.
方法的重寫是在運行時進行的。這個也常被稱為運行時多態的體現。編譯器是沒有辦法知道它調用的到底是那個方法，相反的，只有在jvm執行過程中，才知曉到底是父子類中的哪個方法被調用了當有如下一個介面的時候，我們是無法確定到底是調用父類還是子類的方法

3.
泛型(類型檢測)，這個發生在編譯時。編譯器會在編譯時對泛型類型進行檢測，並吧他重寫成實際的對象類型(非泛型代碼)，這樣就可以被JVM執行了。這個過程被稱為"類型擦除"。

類型擦除的關鍵在於從泛型類型中清除類型參數的相關信息，並且再必要的時候添加類型檢查和類型轉換的方法。

類型擦除可以簡單的理解為將泛型java代碼轉換為普通java代碼，只不過編譯器更直接點，將泛型java代碼直接轉換成普通java位元組碼。類型擦除的主要過程如下：

1). 將所有的泛型參數用其最左邊界(最頂級的父類型)類型替換。

2). 移除所有的類型參數。

在編譯後變成：

4. 註解。註解即有可能是運行時也有可能是編譯時。

如java中的@Override註解就是典型的編譯時註解，他會在編譯時會檢查一些簡單的如拼寫的錯誤(與父類方法不相同)等

同樣的@Test註解是junit框架的註解，他是一個運行時註解，他可以在運行時動態的配置相關信息如timeout等。

5. 異常。異常即有可能是運行時異常，也有可能是編譯時異常。

RuntimeException是一個用於指示編譯器不需要檢查的異常。RuntimeException
是在jvm運行過程中拋出異常的父類。對於運行時異常是不需要再方法中顯示的捕獲或者處理的。

已檢查的異常是被編譯器在編譯時候已經檢查過的異常，這些異常需要在try/catch塊中處理的異常。

6. AOP. Aspects能夠在編譯時，預編譯時以及運行時使用。

1).
編譯時：當你擁有源碼的時候，AOP編譯器(AspectJ編譯器)能夠編譯源碼並生成編織後的class。這些編織進入的額外功能是在編譯時放進去的。

2). 預編譯時：織入過程有時候也叫二進制織入，它是用來織入到哪些已經存在的class文件或者jar中的。

3). 運行時：當被織入的對象已經被載入如jvm中後，可以動態的織入到這些類中一些信息。

7. 繼承：繼承是編譯時執行的，它是靜態的。這個過程編譯後就已經確定

8. 代理(delegate)：也稱動態代理，是在運行時執行。

Ⅶ C語言文件的編譯與執行的四個階段並分別描述

開發C程序有四個步驟：編輯、編譯、連接和運行。

任何一個體系結構處理器上都可以使用C語言程序，只要該體系結構處理器有相應的C語言編譯器和庫，那麼C源代碼就可以編譯並連接到目標二進制文件上運行。

1、預處理：導入源程序並保存（C文件）。

2、編譯：將源程序轉換為目標文件（Obj文件）。

3、鏈接：將目標文件生成為可執行文件（EXE文件）。

4、運行：執行，獲取運行結果的EXE文件。

(7)編譯階段修改註解擴展閱讀：

將C語言代碼分為程序的幾個階段：

1、首先，源代碼文件測試。以及相關的頭文件，比如stdio。H、由預處理器CPP預處理為．I文件。預編譯的。文件不包含任何宏定義，因為所有宏都已展開，並且包含的文件已插入。我歸檔。

2、編譯過程是對預處理文件進行詞法分析、語法分析、語義分析和優化，生成相應的匯編代碼文件。這個過程往往是整個程序的核心部分，也是最復雜的部分之一。

3、匯編程序不直接輸出可執行文件，而是輸出目標文件。匯編程序可以調用LD來生成可以運行的可執行程序。也就是說，您需要鏈接大量的文件才能獲得「a.out」，即最終的可執行文件。

4、在鏈接過程中，需要重新調整其他目標文件中定義的函數調用指令，而其他目標文件中定義的變數也存在同樣的問題。