❶ 100分.Tricks of the Windows Game Programming Gurus的第一個程序的編譯問題. 只要解決問題了分不是問題.
沒有編程經驗 如何做游戲編程
作者：David Astle
經常有人問我，沒有編程經驗的人該如何開始開發游戲。在此之前，我總是一個個的盡力回答。然而，後來提相同問題的人數增長到難以處理的地步。我決定，是時候把我所有的建議寫成文章，作為一個大概。
這篇文章是針對那些想要開發自己游戲，但幾乎沒有編程經驗的人。事實上，我假設讀者沒有任何編程經驗。我主要討論游戲開發的程序和設計方面，而不是藝術性。我也不準備講述如何進入游戲行業(這方面已經有足夠的資料)，而只是讓你逐步的開始開發自己的游戲。最後，我所指出的這條道路也並不能作為唯一的，或是最好的路徑來學習開發游戲，但至少對我和一些人很有用。
選擇一門語言
你要做的第一件事就是選擇一門開發語言。你有很多選擇，包括Basic,Pascal,C,C++,Java,等等。也經常會有人爭論對於初學者那一門語言是最好的。對於這一系列流行語言的討論，你可以參看John Hattan的著作，What Language Do I Use?(我用什麼語言？)
我的建議是以C和C++開始。有些人會說這些語言對初學者來說太高級了，但因為我自己就是學C++，我並不同意這一說法。而且，C/C++是當今使用最廣泛的語言(譯者認為應該是漢語。。。)，所以你可以找到大量學習資料和幫助。你先學C或C++都無所謂，因為只要學了一個，再學另外一個就很容易。但是，如果你先學C++，請保證在學習面向對象編程之前能理解和使用過程編程(等編程熟練再去學習類)。(譯者：C是過程性語言，C++是面向對象語言)
如果你開始學習C/C++,發現太難，那再學一個簡單一點的也沒關系，比如Basic或Pascal。但是我真的認為，如果你堅持努力，而且有好的資料，學C/C++應該沒有太大問題。
你的下一個問題可能會是：「我該怎麼學C/C++?」我很高興你這樣問。最好的辦法是上課。有老師可以回答你的問題，幫助你產生很大進步，編程練習作業也可以保證你能用到所學的東西。
如果你不覺得上課是個好主意，那最好的辦法就是買一些好書。不要花太多時間去選一本什麼「超級寶典」或「萬用全書」，因為你最終可能會買幾本。我建議你去一家書店，然後拿幾本比較入眼的C或C++書看，直到找到一本或幾本你能看懂，並且可以拿來學習的。同時，你可能會想要一些更深入的，或者一些材料，但是你一旦對於這門語言有了一些了解，我相信你應該有自己更好的選擇。
在這里，我有必要花一些時間，來說我看到很多初學者所關心的一個事情，特別是年輕人：沒有錢買書和其他東西。首先，有很多免費資源可以利用，圖書館，Macmillan Computer Publishing(),有成千上百的編程書籍。但是如果你真的想要成為一個好的程序員，還是應該投入一部分資金。應當想方設法(合法的)幫助你弄到一些錢。
網上也有很多C/C++的學習指南。但是我認為那隻能作為補充而不是你自學的主要資源。
選擇正確的編譯器
你寫的程序，或者代碼，是以文本方式儲存的，你甚至可以用記事本寫C/C++程序。但是總需要有東西把他們轉換成為可執行文件。對於C和C++,那就是編譯器。
可用的編譯器有好多種，包括很多免費的。選擇一款自己適合的編譯器很重要，免費的編譯器就有這樣的好處，你可以把它們試個遍，然後從中選擇自己最喜歡的。然而，免費編譯器比起商業版，可能會缺失一些功能和大部分服務。幸運的是，多數商業版編譯器也兼售介紹版或學習版，這要便宜得多，通常功能卻不見得少，唯一的限制是你不能發布用它編譯的程序（短時間內你也根本用不著）。
總之，選擇編譯器取決於你能花多少錢，用什麼操作系統，和為什麼平台開發。如果要為windows開發，我強烈推薦Microsoft Visual C++。他強大的開發環境使得很多事做起來更方便，毫無疑問沒有其他編譯器更適合開發windows應用程序。如果你是個學生，你還可以折價買到。如果你在DOS平台開發，你最好的選擇可能是DJGPP,免費的哦~。
選擇開發平台
盡管最終你很可能為好幾個平台開發,總要先選擇一個來學。當你在學這門語言，還沒有接觸到圖像的時候，你可能會想使用非圖形用戶界面的操作系統，比如DOS,Unix.這樣可以避免接觸高層，比如windows編程，讓你集中精力學習語言本身。
一旦你做好開發游戲的准備，那麼，應該考慮是否改變平台，讓我們來看看每個選項的特徵。
windows：如果你想成為游戲行業的專家，或者如果你想讓許多人來玩你開發的游戲，那麼，這就是你要選擇的平台。因為多數你的用戶使用windows，而且現在我也看不出有什麼改變的跡象。當今大多數的windows游戲都是由一種你可能聽說過技術---DirectX---開發的。你可以DirextX這個庫直接訪問硬體，這意味著你可以開發高性能的游戲。
DOS：DOS過去是占統治地位的游戲平台，但是已經一去不復返了。盡管可能有一些特殊愛好者還在為DOS開發游戲，現在沒有一個為DOS開發的商業游戲，他也將繼續衰落，直到微軟不再支持。如果你只是想開發游戲，還是不要選擇DOS，如果你非要這么做，也不要太久。記住：由於存在大量DOS游戲開發的書，可能還有人辯護從這些書中學習DOS游戲開發。但是，windows游戲開發的書越來越多，那些辯解也變得越來越無力。
Linux:Linux是Unix的一種，由於很多原因後來變得流行，包括穩定性，價格，和反微軟情緒。盡管Linux用戶還是相當少，但是圍繞著他的熱情和不斷增長的市場潛力使其也成為不錯的選擇。
Macintosh:MAC有大量忠實粉絲並不能說明什麼，幾乎每一個和我討論的MAC狂熱者都需要更多更好的游戲。我沒有見過多少MAC游戲開發資源，但我相信還是有的，因此這也是一個選擇。
consoles：console(就是PS,N64,DC等等)的游戲市場十分巨大，當然console游戲開發的前景也不錯。然而以非商業的形式開發console游戲，出於各種原因，在現在似乎行不通。如果你開發console,很可能是在被商業游戲開發組僱用之後。
開始進入主題
現在是時候討論開發游戲了。簡單起見，我假設你選擇用C/C++在windows平台開發，可能你選擇別的，但大多數我說的還是有用的。
首先，甚至在你打算開始開發游戲之前，你必須很好掌握C和C++.你應該懂指針，數組，結構體，函數，可能還有類。如果你精通他們，就可以開始做游戲了。
這篇文章可能不能教會你所有關於開發游戲的東西。幸運的是，也沒有這個必要。這方面有很多書，網上也有很多指南。GameDev.net應該有所有你想要的東西，這里我建議你怎麼開始：
找一本或幾本書。對於windows游戲開發初學者，Tricks of the Windows Game Programming Gurus是個完美的開始。除此之外，還有許多好書.讀透這些書，試試所有的例子，不懂得部分多讀幾遍。
網上指南作為補充。除了弄清書上讀到的，他們還涉及一些書上沒有談及的主題。
向專家尋求幫助。如果你不能在書上或指南找到問題的答案，好好利用我們的論壇和聊天室。那裡有好多專家願意幫助別人。
這並不是要你按照順序執行的，而是可以同時並且不斷的重復執行。
光學習還是不夠的，你必須運用你所學到的。從一個小游戲開始，然後在這個基礎上前進。你可以看一下Geoff Howland's 的著作： How do I Make Games? A Path to Game Development.
開始，自己獨立工作。不要急著加入團隊，那樣只會減緩學習過程。而且一旦你有了自己的幾個游戲，你可以為團隊做出更大的貢獻。
還有關於書，你應該不僅僅看游戲開發的書。為了能夠開發出你看到商店出售的游戲，你應該鑽研比大多數游戲開發書籍更高級的一些主題。有一些可以在網上找到，但你也應該選一些圖形學，人工智慧，網路，物理學等方面的書。計算機科學學位看來唾手可得，但因為你被迫上這些課的時候可能認為他們和游戲開發無關----你錯了！
這里有一些提示很有用
不要只積累知識，用它
你永遠不會知道會理解一些東西知道你是用他們。用你學的東西作些演示。做作書上的練習。
多玩游戲
這樣做會使你做出更好的游戲。而且可以減輕編程的枯燥。
幫助別人
能幫別人的地方盡量幫助別人，教別人的過程中自己會學到更多。
有始有終
不要有這樣的想法：「我能夠完成這個游戲了，但是我又有一個新的想法，那就直接做下一個。」你可以學得更多如果你完成他，你也可以用事實證明你不是只會空談。所以，盡量不要做很大很復雜的游戲，直到你有了一定經驗。
開始吧！你現在可以開始准備QUAKE4了。可能你不是不是很了解，但是至少應該知道如何開始這條道路，找多些資料，加上多年努力工作，他一定會實現！
❷ 關於#include "stdafx.h"的問題，
說實話，以下內容是拷貝來的，簡單點說，stdafx.h文件是作為Visual Studio編譯32位的程序時固定創建的一個頭文件，也就是你可以自己寫一個來用。網上的代碼不可能把這些小地方也拷貝上去。如果不太清楚內容的話可以先新建一個win32 console application 工程，把裡面Visual Studio創建的stdafx.h文件拷貝過來就行了。。。
-------------------------------------------------------
Standard Application Fram Extend
沒有函數庫，只是定義了一些環境參數，使得編譯出來的程序能在32位的操作系統環境下運行。
Windows和MFC的include文件都非常大，即使有一個快速的處理程序，編譯程序也要花費相當長的時間來完成工作。由於每個.CPP文件都包含相同的include文件，為每個.CPP文件都重復處理這些文件就顯得很傻了。
為避免這種浪費，AppWizard和VisualC++編譯程序一起進行工作，如下所示：
◎AppWizard建立了文件stdafx.h，該文件包含了所有當前工程文件需要的MFCinclude文件。且這一文件可以隨被選擇的選項而變化。
◎AppWizard然後就建立stdafx.cpp。這個文件通常都是一樣的。
◎然後AppWizard就建立起工程文件，這樣第一個被編譯的文件就是stdafx.cpp。
◎當VisualC++編譯stdafx.cpp文件時，它將結果保存在一個名為stdafx.pch的文件里。(擴展名pch表示預編譯頭文件。)
◎當VisualC++編譯隨後的每個.cpp文件時，它閱讀並使用它剛生成的.pch文件。VisualC++不再分析Windowsinclude文件，除非你又編緝了stdafx.cpp或stdafx.h。
這個技術很精巧，你不這么認為嗎？(還要說一句，Microsoft並非是首先採用這種技術的公司，Borland才是。)在這個過程中你必須遵守以下規則：
◎你編寫的任何.cpp文件都必須首先包含stdafx.h。
◎如果你有工程文件里的大多數.cpp文件需要.h文件，順便將它們加在stdafx.h(後部)上，然後預編譯stdafx.cpp。
◎由於.pch文件具有大量的符號信息，它是你的工程文件里最大的文件。
如果你的磁碟空間有限，你就希望能將這個你從沒使用過的工程文件中的.pch文件刪除。執行程序時並不需要它們，且隨著工程文件的重新建立，它們也自動地重新建立。
--------------------------------------------
❸ 問幾個c++調試時的錯誤提示
1.編譯器錯誤 C2447
錯誤消息
「{」: 缺少函數標題(是否是老式的形式表？)
在全局范圍內出現左大括弧，但沒有相應的函數頭。
此錯誤可能由舊式 C 語言格式列表引起。
下面的示例生成 C2447：
// C2447.cpp
int c;
{} // C2447
2. 編譯器錯誤 C2181
錯誤消息
沒有匹配 if 的非法 else
每個 else 都必須具有一個與之相匹配的 if。
下面的示例生成 C2181：
// C2181.cpp
int main() {
int i = 0;
else // C2181
i = 1;
}
可能的解決方案：
// C2181b.cpp
int main() {
int i = 0;
if(i)
i = 0;
else
i = 1;
}
3.編譯器錯誤 C2057
錯誤消息
應輸入常數表達式
上下文要求常數表達式，即其值在編譯時已知的表達式。
示例
下面的示例生成 C2057：
// C2057.cpp
int i;
int b[i]; // C2057
int main() {
const int i = 8;
int b[i];
}
C 對常數表達式有限制性更強的規則。下面的示例生成 C2057：
// C2057b.c
#define ArraySize1 10
int main() {
const int ArraySize2 = 10;
int h[ArraySize2]; // C2057
int h[ArraySize1]; // OK
}
4.編譯器錯誤 C2065
錯誤消息
「identifier」: 未聲明的標識符
在可使用變數的類型前必須在聲明中指定它。在可以使用函數前必須在聲明或原型中指定該函數使用的參數。
可能的原因：
您正在用 C 運行庫的調試版本進行編譯，在 for 循環中聲明標准 C++ 庫迭代器變數，然後嘗試在 for 循環范圍外使用該迭代器變數。 用 C 運行庫的調試版本編譯標准 C++ 庫代碼暗指使用 /Zc:forScope。 有關更多信息，請參見調試迭代器支持。
可能正在調用當前不受生成環境支持的 SDK 頭文件中的函數。
省略必要的包含文件，尤其是在定義 VC_EXTRALEAN、WIN32_LEAN_AND_MEAN 或 WIN32_EXTRA_LEAN 時。這些符號從 windows.h 和 afxv_w32.h 中排除了一些頭文件以加快編譯。（在 windows.h 和 afxv_w32.h 中查找排除的頭文件的最新說明。）
標識符名拼寫錯誤。
標識符使用了錯誤的大小寫字母。
字元串常數的後面缺少右引號。
命名空間范圍不正確。例如，若要解析 ANSI C++ 標准庫函數和運算符，則必須用 using 指令指定 std 命名空間。下面的示例未能編譯，因為 using 指令被注釋掉，並且在 std 命名空間中定義了 cout：
❹ 什麼是JIT
准時生產方式（Just In Time簡稱JIT），是日本豐田汽車公司在20世紀60年代實行的一種生產方式，1973年以後，這種方式對豐田公司渡過第一次能源危機起到了突出的作用，後引起其它國家生產企業的重視，並逐漸在歐洲和美國的日資企業及當地企業中推行開來，現在這一方式與源自日本的其它生產、流通方式一起被西方企業稱為「日本化模式」，其中，日本生產、流通企業的物流模式對歐美的物流產生了重要影響，近年來，JIT不僅作為一種生產方式，也作為一種通用管理模式在物流、電子商務等領域得到推行。
在20世紀後半期，整個汽車市場進入了一個市場需求多樣化的新階段，而且對質量的要求也越來越高，隨之給製造業提出的新課題即是，如何有效地組織多品種小批量生產，否則的話，生產過剩所引起的只是設備、人員、非必須費用等一系列的浪費，從而影響到企業的競爭能力以至生存。在這種歷史背景下，1953年，日本豐田公司的副總裁大野耐一綜合了單件生產和批量生產的特點和優點，創造了一種在多品種小批量混合生產條件下高質量、低消耗的生產方式即准時生產。准時制指的是，將必要的零件以必要的數量在必要的時間送到生產線，並且只將所需要的零件、只以所需要的數量、只在正好需要的時間送到生產。這是為適應20世紀60年代消費需要變得多樣化、個性化而建立的一種生產體系及為此生產體系服務的物流體系。
[編輯本段]
【准時制核心思想】
在准時制生產方式倡導以前，世界汽車生產企業包括豐田公司均採取福特式的「總動員生產方式」，即一半時間人員和設備、流水線等待零件，另一半時間等零件一運到，全體人員總動員，緊急生產產品。這種方式造成了生產過程中的物流不合理現象，尤以庫存積壓和短缺為特徵，生產線或者不開機，或者開機後就大量生產，這種模式導致了嚴重的資源浪費。豐田公司的准時制採取的是多品種少批量、短周期的生產方式，實現了消除庫存，優化生產物流，減少浪費目的。
准時生產方式基本思想可概括為「在需要的時候，按需要的量生產所需的產品」，也就是通過生產的計劃和控制及庫存的管理，追求一種無庫存，或庫存達到最小的生產系統。准時生產方式的核心是追求一種無庫存的生產系統，或使庫存達到最小的生產系統。為此而開發了包括「看板」」在內的一系列具體方法，並逐漸形成了一套獨具特色的生產經營體系。
准時制生產方式以准時生產為出發點，首先暴露出生產過量和其他方面的浪費，然後對設備、人員等進行淘汰、調整，達到降低成本、簡化計劃和提高控制的目的。在生產現場控制技術方面，准時制的基本原則是在正確的時間，生產正確數量的零件或產品，即時生產。它將傳統生產過程中前道工序向後道工序送貨，改為後道工序根據「看板」向前道工序取貨，看板系統是准時制生產現場控制技術的核心，但准時制不僅僅是看板管理。
[編輯本段]
【對生產製造的影響】
1．生產流程化
即按生產汽車所需的工序從最後一個工序開始往前推，確定前面一個工序的類別，並依次的恰當安排生產流程，根據流程與每個環節所需庫存數量和時間先後來安排庫存和組織物流。盡量減少物資在生產現場的停滯與搬運，讓物資在生產流程上毫無阻礙地流動。
「在需要的時候，按需要的量生產所需的產品」。對於企業來說，各種產品的產量必須能夠靈活地適應市場需要量的變比。眾所周知，生產過剩會引起人員、設備、庫存費用等一系列的浪費。避免這些浪費的手段就是實施適時適量生產，只在市場需要的時候生產市場需要的產品。
為了實現適時適量生產，首先需要致力於生產的同步化。即工序間不設置倉庫，前一工序的加工結束後，使其立即轉到下一工序去，裝配線與機械加工幾乎平行進行。在鑄造、鍛造、沖壓等必須成批生產的工序，則通過盡量縮短作業更換時間來盡量縮小生產批量。生產的同步化通過「後工序領取」這樣的方法來實現。 「後工序只在需要的時間到前工序領取所需的加工品；前工序中按照被領取的數量和品種進行生產。」這樣，製造工序的最後一道即總裝配線成為生產的出發點，生產計劃只下達給總裝配線，以裝配為起點，在需要的時候，向前工序領取必要的加工品，而前工序提供該加工品後，為了補充生產被領走的量，必向再前道工序領取物料，這樣把各個工序都連接起來，實現同步化生產。
這樣的同步化生產還需通過採取相應的設備配置方法以及人員配置方法來實現。即不能採取通常的按照車、銑、刨等工業專業化的組織形式，而按照產品加工順序來布置設備。這樣也帶來人員配置上的不同作法：彈性配置作業人數。降低勞動費用是降低成本的一個重要方面，達到這一目的的方法是「少人化」。所謂少人化，是指根據生產量的變動，彈性地增減各生產線的作業人數，以及盡量用較少的人力完成較多的生產。這里的關鍵在於能否將生產量減少了的生產線上的作業人員數減下來。具體方法是實施獨特的設備布置，以便能夠在需求減少時，將作業所減少的工時集中起來，以整頓削減人員。但這從作業人員的角度來看，意味著標准作業中的作業內容、范圍、作業組合以及作業順序等的一系列變更。因此為了適應這種變更，作業人員必須是具有多種技能的「多面手」。
2．生產均衡化
生產均衡化是實現適時適量生產的前提條件。所謂生產的均衡化，是指總裝配線在向前工序領取零部件時應均衡地使用各種零部件，生產各種產品。為此在制定生產計劃時就必須加以考慮，然後將其體現於產品生產順序計劃之中。在製造階段，均衡化通過專用設備通用化和制定標准作業來實現。所謂專用設備通用化，是指通過在專用設備上增加一些工夾具的方法使之能夠加工多種不同的產品。標准作業是指將作業節拍內一個作業人員所應擔當的一系列作業內容標准化。
生產中將一周或一日的生產量按分秒時間進行平均，所有生產流程都按此來組織生產，這樣流水線上每個作業環節上單位時間必須完成多少何種作業就有了標準定額，所在環節都按標準定額組織生產，因此要按此生產定額均衡地組織物質的供應、安排物品的流動。因為JIT生產方式的生產是按周或按日平均，所以與傳統的大生產、按批量生產的方式不同，JIT的均衡化生產中無批次生產的概念。
標准化作業是實現均衡化生產和單件生產單件傳送的又一重要前提。豐田公司的標准化作業主要是指每一位多技能作業員所操作的多種不同機床的作業程序，是指在標准周期時間內，把每一位多技能作業員所承擔的一系列的多種作業標准化。豐田公司的標准化作業主要包括三個內容：標准周期時間、標准作業順序、標准在製品存量，它們均用「標准作業組合表」來表示。
3．資源配置合理化
資源配置的合理化是實現降低成本目標的最終途徑，具體指在生產線內外，所有的設備、人員和零部件都得到最合理的調配和分派，在最需要的時候以最及時的方式到位。
從設備而言，設備包括相關模具實現快速裝換調整，例如，豐田公司發明並採用的設備快速裝換調整的方法是SMED法。豐田公司所有大中型設備的裝換調整操作均能夠在10分鍾之內完成，這為「多品種、小批量」的均衡化生產奠定了基礎。
在生產區間，需要設備和原材料的合理放置。快速裝換調整為滿足後工序頻繁領取零部件製品的生產要求和「多品種、小批量」的均衡化生產提供了重要的基礎。但是，這種頗繁領取製品的方式必然增加運輸作業量和運輸成本，特別是如果運輸不便，將會影響准時化生產的順利進行。合理布置設備，特別是U型單元連結而成的「組合U型生產線」，可以大大簡化運輸作業，使得單位時間內零件製品運輸次數增加，但運輸費用並不增加或增加很少，為小批量頻繁運輸和單件生產單件傳送提供了基礎。
人員而言，多技能作業員（或稱「多面手」）是指那些能夠操作多種機床的生產作業工人。多技能作業員是與設備的單元式布置緊密聯系的。在U型生產單元內，由於多種機床緊湊地組合在一起，這就要求並且便於生產作業工人能夠進行多種機床的操作，同時負責多道工序的作業，如一個工人要會同時操作車床、銑床和磨床等。
[編輯本段]
【人力資源准時制方式的必要性】
實現人力資源的准時制至少可以給企業帶來以下3個方面的好處：
1.減少人員維護成本。企業對內部員工不但要長期支付工資、福利等成本，而且要不斷投入培訓費用以提高和維持員工的各項技能。使用准時制人員，雖然可能一次性支出較大，但從長遠觀點看能節省很多成本。
2.不斷吸收外部信息。通過准時制方式隨時吸引外部人才的加入，能加強企業與外部的交流，及時取得各種有價值的信息，尤其是一些技術發展趨勢方面的情況，往往從其他渠道難以得到。
3.集中力量於核心職能。實踐證明，"大而全，小而全"的企業結構是效率低下的，目前出現的虛擬化管理的趨勢，就是要把企業內部的部分職能逐漸分離出來，由社會或其他組織承擔，從而使企業把非核心因素排除在企業組織之外，集中力量於企業的戰略核心環節。我國進行的企業剝離部分社會職能、高校後勤社會化等一系列改革都體現了這種要求。
【人力資源准時制方式的可行性】
在計劃經濟體制下，人力資源管理的准時制方式是絕不可能實現的，但是隨著市場經濟的深入發展，准時制方式已成為可能，並且將發展成為一種常用的重要的方式。
1.隨著人才市場的發展和完善，人員流動性增強，人才素質提高，從而對外部人才的可獲性增強。烽火獵頭認為眾多的獵頭公司、人才中心、咨詢公司等都是可以利用的渠道，通過與這些公司的長期廣泛聯系，企業可以在需要的時候很容易地得到需要的人才，使准時製成為可能。尤其在我國，勞動力資源豐富的特點為企業採用准時制方式提供了資源保障。
2.用人制度的改革為JIT的實施提供方便。企業與個人之間新型的勞動合同關系消除了終身制的種種弊端，使得企業在用人方面擁有更大的主動性和靈活性。通過簽訂勞動合同，企業可以決定員工的聘用、待遇、績效以及辭退等問題，也可以事先確定員工的服務時間，從而保證了准時制的順利實施。
3.從國外經驗看，准時制在人力資源管理中有著廣泛的應用。在國外，早已出現的人才租賃公司為企業聘用准時制人員提供了幫助。據統計，美國約有20％的中小企業都採用人才租賃的方式，而人才租賃正是准時制一種主要方式。
[編輯本段]
【准時制人員的對象】
按照準時制的基本思想，企業中的任何人員都可能成為准時制管理的對象，只要企業出現人員需要，就要做到准時制。根據企業中各類人員的特點和作用，我們可以把准時制管理的對象分為兩大類：
1.企業迫切需要的核心人員。一般來講，企業的核心人員包括決策人員、管理人員、研究開發人員以及業務開發人員等等。這些核心人員決定了企業的綜合競爭力，對於企業的生存和發展起著關鍵性的作用，他們是企業不可或缺的力量。因此，如果需要這部分人員，就必須及時補充，做到Just In Time.比如，由於業務擴展或人事變動，企業急需業務開發人員，人力資源管理部門就應當做到使所需人員及時到位，否則，將影響企業業務的開展。
有人認為，企業核心人員是企業的中堅力量，不應屬於"隨叫隨到"的准時制人員。這是對准時制本質認識不清的結果，准時制要求在需要的時候提供需要的人員，並不涉及這種需要的時間長短。既然出現了對核心人員的需要，就應當使核心人員准時到位。盡管這類人員是企業長期需要的，而且也相對穩定，但其最初加入企業應當是Just In Time.
2.企業暫時需要的人員。這類人員雖然不構成企業的核心力量，但是他們的可獲性將直接影響企業各項工作的順利進行。這類人員可以是一些急需的專門人才，如產品開發人才、項目開發人才，因為這類人才只為特定產品或項目服務，企業沒有必要長期擁有，因此可採用准時制方式臨時僱傭，尤其對於一些中小企業，自身的技術力量不強，不能吸引或保留高層次技術人才，通過准時制方式獲取外部人才將是一種理想的選擇。另外，企業暫時需要的人員也可能是一些臨時性或季節性工作要求的輔助人員，比如偶爾出現的貨物運輸、季節性的工作量增加，都需要使用准時制人員。由於這部分人員類型多、變動頻繁，因此進行准時制開發的工作量相對較大，必須有科學詳盡的准時制人員規劃。
[編輯本段]
【准時制人員的規劃】
准時制技術的一個重要特點就是嚴格的計劃，為了適時地滿足企業對人員的需要，同時又要消除人員的閑置，即不能靠大量"庫存"來滿足變動的需求，必須做好准時制人員的規劃。一般應根據行業的商業周期或季節性規律，科學預計企業業務的發展變化對人員需求的影響，尤其是對臨時需要人員的影響。
規劃中，首先要確定準時制人員可能擔任的工作清單，清單內容包括工作說明，工作所需的技能、知識，工作所需的方法、工具、設備，工作的質量要求，工作所需的培訓時間及鑒定合格的標准等。然後根據工作清單，採取各種方式如提前招聘、租賃、兼職、顧問等，預先約定準時制人員，一旦需要就立即通知他們前來工作。如果是短期人力需求，工作結束後相應的准時制人員也結束臨時聘用。
為保證准時制人員規劃的順利實施，應當建立詳細的人才資源信息庫，記錄所有可以利用的外部人力資源，比如兼職人員、轉換工作中的人士、精力充沛的退休人員、可以租賃的人才、自由職業者等等，並保持與這些人員的長期聯系。人才庫應當包括人員的特點、技能、愛好、聯系方式、薪資要求等方面的信息，以便為企業預約准時制人員提供參考。
在人力資源開發與管理工作中，准時制既是一種技術，更是一種思想。它要求人力資源管理部門著眼於企業實際需要，周密計劃、嚴格控制，既不能出現人員短缺，也不能有人員的閑置，這是一項非常困難而又很有意義的工作。
【准時制人員的供應商管理模式】
准時制對於供應商的管理需求為零庫存計劃，要求供應商生產物料嚴格按照訂單生產，通過這種方式減少供應商的庫存成本及浪費。從整個供應鏈上面體現出「零庫存」的概念。
[編輯本段]
JAVA領域的JIT
JIT Compiler(Just-in-time Compiler) 即時編譯
最早的Java建置方案是由一套轉譯程式（interpreter），將每個Java指令都轉譯成對等的微處理器指令，並根據轉譯後的指令先後次序依序執行，由於一個Java指令可能被轉譯成十幾或數十幾個對等的微處理器指令，這種模式執行的速度相當緩慢。
針對這個問題，業界首先開發出JIT（just in time）編譯器。當Java執行runtime環境時，每遇到一個新的類別（class：類別是Java程式中的功能群組），類別是Java程式中的功能群組－JIT編譯器在此時就會針對這個類別進行編譯（compile）作業。經過編譯後的程式，被優化成相當精簡的原生型指令碼（native code），這種程式的執行速度相當快。花費少許的編譯時間來節省稍後相當長的執行時間，JIT這種設計的確增加不少效率，但是它並未達到最頂尖的效能，因為某些極少執行到的Java指令在編譯時所額外花費的時間可能比轉譯器在執行時的時間還長，針對這些指令而言，整體花費的時間並沒有減少。
基於對JIT的經驗，業界發展出動態編譯器（dynamic compiler），動態編譯器僅針對較常被執行的程式碼進行編譯，其餘部分仍使用轉譯程式來執行。也就是說，動態編譯器會研判是否要編譯每個類別。動態編譯器擁有兩項利器：一是轉譯器，另一則是JIT，它透過智慧機制針對每個類別進行分析，然後決定使用這兩種利器的哪一種來達到最佳化的效果。動態編譯器針對程式的特性或者是讓程式執行幾個循環，再根據結果決定是否編譯這段程式碼。這個決定不見得絕對正確，但從統計數字來看，這個判斷的機制正確的機會相當高。事實上，動態編譯器會根據「歷史資料」做決策，所以程式執行的時間愈長，判斷正確的機率就愈高。以整個結果來看，動態編譯器產生的程式碼執行的速度超越以前的JIT技術，平均速度可提高至50%。
JIT 頁面渲染引擎
JIT 頁面渲染是 COMSHARP CMS 為了實現網站內容即時更新而開發的頁面生成技術，JIT頁面渲染引擎直接從資料庫獲取網站最新內容，瞬間生成頁面輸出給訪問者，並通過 URL 轉寫技術實現純靜態地址。JIT 頁面渲染技術是針對傳統 CMS 生成靜態 HTML 文件而言。傳統 CMS 由於使用腳本代碼模板技術，頁面生成前，需要將資料庫中的頁面內容用外部模板進行解析與渲染，導致嚴重的性能問題，為了解決這個問題，傳統 CMS 一般採用生成 HTML 靜態文件技術，即，在內容創作完成後，對全站的內容執行一個靜態 HTML 文件生成過程，最終，全站內容以靜態 HTML 文件的形式存在。
靜態 HTML 文件技術最顯著的優勢是性能出眾，然而這種技術最嚴重的問題在於，用戶對站點任何修改與更新，必須首先經過一次全站 HTML 文件重新生成過程，然後才能被訪問者看到。根據不同 CMS 產品的性能和站點規模，這個 HTML 生成過程可能長到十幾分鍾到幾十分鍾或更長。也有個別 CMS 產品使用觸發式頁面渲染模式，即內容更新後，並不立即生成 HTML 文件，而是在用戶第一次訪問該頁面時，觸發生成該頁面的 HTML 文件，這種技術的問題在於，用戶第一次訪問被更新頁面的時候，可能經歷非常漫長的等待，因為站點內各個頁面之間並非孤立的，他們可能相互引用，雖然訪問的只是一個頁面，為了對引用頁面同步更新，需要重新生成 HTML 文件的頁面可能有多個。
JIT 頁面渲染如何工作？
下圖，是 COMSHARP CMS JIT 渲染引擎與傳統 CMS 生成 HTML 靜態頁面模式對比。可以看出，JIT 渲染引擎直接將網站最新內容從資料庫渲染給訪問用戶，而傳統 CMS 的站點內容在到達訪問用戶之前，首先要經歷一個 HTML 的轉換過程。
COMSHARP CMS JIT 頁面渲染如何實現毫秒級的渲染速度？
COMSHARP CMS 在頁面渲染的時候，JIT 引擎可以在數十毫秒的時間內容完整整個頁面的生成，這樣就保證用戶訪問的時候，不會因 JIT 渲染造成延遲。事實上，COMSHARP CMS 網站訪問速度只取決於伺服器帶寬，頁面生成過程帶來的延遲可以忽略不計。
我們有兩項技術保證這樣的性能：
編譯級主題模板
COMSHARP CMS 的編譯級主題模板直接內嵌在系統的 DLL 中，主題模板的套用是在運行時（Run Time）完成，這和傳統 CMS 的調用腳本代碼模板解釋運行是截然不同。
調用 .NET 核心函數完成頁面渲染（繞開 ASP.NET Webform 生命周期）
我們知道，.NET 框架內核性能是非常出色的，然而，ASP.NET Webform 卻以效率低下而受到詬病。ASP.NET Webform 效率低下的主要原因，是微軟為了在 Web 上實現類似 Winform 的開發體驗而設計的一套機制，這套機制包含一個完整的 ASP.NET Webform 生命周期，Webform 從接受訪問請求到輸出頁面內容，要經歷一個周期，這個周期的存在是為了讓開發者插入各種處理邏輯，這個 Webform 生命周期的效率並不理想。
為了解決這個問題，COMSHARP CMS 拋棄了 ASP.NET Webform 模式，而是直接調用 .NET 核心函數完成頁面的輸出，繞過 Webform 的生命周期，顯著得提高了 COMSHARP CMS 頁面的生成速度，並將速度提升到毫秒級。
❺ c語言編譯沒有錯誤,連接有錯誤是怎麼回事程序本身沒錯
1、鏈接錯誤也不一定是系統的問題，也有可能是程序的問題。如果編譯有錯的話是不會有鏈接的，鏈接要有obj目標文件，編譯不通過就沒有目標文件。
2、連接錯誤及原因：
編譯器錯誤 C2001 錯誤消息
常數中有換行符
字元串常數不能繼續到第二行，除非進行下列操作：
•用反斜杠結束第一行。
•用一個雙引號結束第一行上的字元串，並在下一行用另一個雙引號開始該字元串。
用 \n 結束第一行是不夠的。
編譯器錯誤 C2002 錯誤消息
無效的寬字元常數
多位元組字元常數是非法的。
通過檢查下面的可能原因進行修復
1.寬字元常數包含的位元組比需要的多。
2.未包括標准頭文件 STDDEF.h。
3.寬字元不能與一般字元串連接。
4.寬字元常數之前必須是字元「L」：
編譯器錯誤 C2003 錯誤消息
應輸入「defined id」
標識符必須跟在預處理器關鍵字之後。
編譯器錯誤 C2004 錯誤消息
應為「defined(id)」
標識符必須出現在預處理器關鍵字之後的括弧中。
也可能由於為 Visual Studio .NET 2003 進行的編譯器一致性工作生成此錯誤：在預處理器指
令中缺少括弧。
如果預處理器指令缺少右括弧，則編譯器將生成一個錯誤。
編譯器錯誤 C2005 錯誤消息
#line 應跟一個行號，卻找到「token」
#line 指令後面必須跟行號。
編譯器錯誤 C2006 錯誤消息
「directive」應輸入文件名，卻找到「token」
諸如 #include 或 #import 等指令需要文件名。若要解決該錯誤，請確保 token 是一個有效
文件名。並且將該文件名放在雙引號或尖括弧中。
編譯器錯誤 C2007 錯誤消息
#define 語法
#define 後未出現標識符。若要解決該錯誤，請使用標識符。
編譯器錯誤 C2008 錯誤消息
「character」: 宏定義中的意外
該字元緊跟在宏名之後。若要解決該錯誤，宏名之後必須有一個空格。
編譯器錯誤 C2009 錯誤消息
宏形式「identifier」重復使用
宏定義的形參表多次使用該標識符。宏的參數列表中的標識符必須是唯一的。
編譯器錯誤 C2010 錯誤消息
「character」: 宏形參表中的意外
該字元在宏定義的形參表中使用不正確。移除該字元以解決該錯誤。
編譯器錯誤 C2011 錯誤消息
「identifier」:「type」類型重定義
該標識符已定義為 type 類型。如果多次將某個類型庫導入同一個文件，也可能生成 C2011
。
編譯器錯誤 C2012 錯誤消息
在「<」之後缺少名稱
#include 指令缺少所需的文件名。
編譯器錯誤 C2013 錯誤消息
缺少「>」
#include 指令缺少右尖括弧。添加右尖括弧以解決該錯誤。
編譯器錯誤 C2014 錯誤消息
預處理器命令必須作為第一個非空白空間啟動
預處理器指令的 # 符號必須是非空白行上的第一個字元。
編譯器錯誤 C2015 錯誤消息
常數中的字元太多
一個字元常數包含的字元多於兩個。標准字元常數只能包含一個字元，長字元常數只能包含兩
個字元。
轉義序列（如 \t）將被轉換為單個字元。
當使用 Microsoft 擴展將字元常數轉換為整數時，也可能發生 C2015。
編譯器錯誤 C2017 錯誤消息
非法的轉義序列
轉義序列（如 \t）出現在字元或字元串常數之外。
當 stringize 運算符與包括轉義序列的字元串一起使用時會發生 C2017。
編譯器錯誤 C2018 錯誤消息
未知字元「hexnumber」
源文件包含一個意外的 ASCII 字元，該字元由其十六進制數標識。若要解決該錯誤，請移除
該字元。
編譯器錯誤 C2019 錯誤消息
應找到預處理器指令，卻找到「character」
該字元跟在 # 符號的後面，但它不是預處理器指令的第一個字母。
編譯器錯誤 C2020 錯誤消息
「member」:「class」成員重定義
從基類或結構繼承的成員被重定義。不能重定義繼承成員，除非它在基類中被聲明為 virtual
。
編譯器錯誤 C2021 錯誤消息
應輸入指數值，而非「character」
用作浮點常數的指數的字元是一個無效數字。確保使用的指數在范圍之內。
編譯器錯誤 C2022 錯誤消息
「number」: 對字元來說太大
字元或字元串常數中跟在反斜杠 (\) 後面的八進制數字太大，不能表示字元。
編譯器錯誤 C2026 錯誤消息
字元串太大，已截斷尾部字元
該字元串的長度超過了 16380 個單位元組字元的**。
連接相鄰字元串之前，字元串的長度不能超過 16380 個單位元組字元。
大約為此長度的一半的 Unicode 字元串也會生成此錯誤。
編譯器錯誤 C2027 錯誤消息
使用了未定義類型「type」
類型只有經過定義才能使用。若要解決該錯誤，請確保在引用類型前已對其進行了完全定義。
有可能聲明一個指向已聲明但未定義的類型的指針。但是 Visual C++ 不允許引用未定義的類
型。
編譯器錯誤 C2028 錯誤消息
結構/聯合成員必須在結構/聯合中
結構或聯合成員必須在結構或聯合內部聲明。
編譯器錯誤 C2030 錯誤消息
「identifier」: 結構/聯合成員重定義
結構或聯合將同一標識符用於多個成員。
編譯器錯誤 C2032 錯誤消息
「identifier」: 函數不能是結構/聯合「structorunion」的成員
該結構或聯合中的一個成員函數在 C++ 中允許使用而在 C 中卻不允許。若要解決該錯誤，請
編譯為 C++ 程序或移除該成員函數。
編譯器錯誤 C2033 錯誤消息
「identifier」: 位域不能有間接定址
該位域被聲明為指針，這是不允許的。
編譯器錯誤 C2034 錯誤消息
「identifier」: 位域類型對於位數太小
該位域聲明中位的數目超過了基類型的大小。
編譯器錯誤 C2036 錯誤消息
「identifier」: 未知的大小
對 identifier 的操作需要數據對象的大小，而該大小無法確定。
編譯器錯誤 C2039 錯誤消息
「identifier1」: 不是「identifier2」的成員
該代碼錯誤調用或引用了結構、類或聯合的成員。
編譯器錯誤 C2040 錯誤消息
「operator」:「identifier1」與「identifier2」的間接定址級別不同
涉及該運算符的表達式具有不一致的間接定址級別。
如果兩個操作數都是算術的或都是非算術的（如數組或指針），則不用更改就可使用它們。如
果一個操作數是算術的，而另一個不是，則算術運算符將轉換為非算術類型。
編譯器錯誤 C2041 錯誤消息
非法的數字「character」(用於基「number」)
指定的字元不是基（如八進制或十六進制）的有效數字。
編譯器錯誤 C2042 錯誤消息
signed/unsigned 關鍵字互相排斥
在單個聲明中使用關鍵字 signed 和 unsigned。
編譯器錯誤 C2043 錯誤消息
非法 break
break 僅在 do、for、while 或 switch 語句中合法。
編譯器錯誤 C2044 錯誤消息
非法 continue
continue 僅在 do、for 或 while 語句中合法。
編譯器錯誤 C2045 錯誤消息
「identifier」: 標簽重定義
該標簽出現在同一函數中的多條語句之前。
編譯器錯誤 C2046 錯誤消息
非法的 case
關鍵字 case 只能出現在 switch 語句中。
編譯器錯誤 C2047 錯誤消息
非法的 default
關鍵字 default 僅能出現在 switch 語句中。
編譯器錯誤 C2048 錯誤消息
默認值多於一個
switch 語句包含多個 default 標簽。刪除其中一個 default 標簽可解決該錯誤。
編譯器錯誤 C2050 錯誤消息
switch 表達式不是整型
switch 表達式計算結果為一個非整數值。若要解決該錯誤，請在 switch 語句中只使用整數
值。
編譯器錯誤 C2051 錯誤消息
case 表達式不是常數
Case 表達式必須是整數常數。
編譯器錯誤 C2052 錯誤消息
「type」: 非法的 case 表達式類型
Case 表達式必須是整數常數。
編譯器錯誤 C2053 錯誤消息
「identifier」: 寬字元串不匹配
寬字元串被分配給了一個不兼容的類型。
編譯器錯誤 C2054 錯誤消息
在「identifier」之後應輸入「(」
該函數標識符用在需要尾部括弧的上下文中。
導致該錯誤的可能原因是省略了復雜初始化上的等號 (=)。
編譯器錯誤 C2055 錯誤消息
應輸入形參表，而不是類型表
函數定義包含參數類型列表而不包含形參表。ANSI C 需要命名的形參，除非它們是 void 或
是省略號 (...)。
編譯器錯誤 C2056 錯誤消息
非法表達式
表達式因前一個錯誤而無效。
編譯器錯誤 C2057 錯誤消息
應輸入常數表達式
上下文要求常數表達式，即其值在編譯時已知的表達式。
編譯器錯誤 C2058 錯誤消息
常數表達式不是整型
該上下文需要整數常數表達式。
編譯器錯誤 C2059 錯誤消息
語法錯誤 :「token」
該標記導致語法錯誤。
若要確定原因，則不僅要檢查在錯誤信息中列出的行，還要檢查該行上面的行。下面的示例對
聲明 j 的行生成了錯誤信息，而該錯誤的真正源卻出現在其上面的行中。
如果對行的檢查沒有獲得有關可能出現的問題的任何線索，則嘗試注釋掉在錯誤信息中列出的
行以及可能出現在該行上面的若干行。
如果該錯誤信息在緊跟 typedef 變數的符號上出現，則檢查該變數是否已在源代碼中定義。
如果符號沒有計算出任何結果（在使用 /Dsymbol= 編譯時可能發生），可能會導致 C2059。
可能收到 C2059 的另一個特定原因是編譯在函數的默認參數中指定了結構的應用程序。參數的
默認值必須是一個表達式。初始值設定項列表（如用於初始化結構的初始值設定項列表）不是表達式。其解決方法是定義一
個執行所需初始化的構造函數。
編譯器錯誤 C2060 錯誤消息
語法錯誤 : 遇到文件結束
至少還需要一個標記。
編譯器錯誤 C2061 錯誤消息
語法錯誤: 標識符「identifier」
編譯器發現了不應在此出現的標識符。請確保在使用 identifier 之前對其進行聲明。
初始值設定項可能括在了括弧中。為避免該問題，請將聲明符括在括弧中或使其成為 typedef
。
在編譯器將表達式作為類模板參數檢測時也可能導致此錯誤；使用 typename 告訴編譯器它是
一個類型。
編譯器錯誤 C2062 錯誤消息
意外的類型「type」
編譯器不需要類型名稱。
編譯器處理構造函數的參數列表中未定義類型的方式也可能導致 C2062。如果編譯器遇到未定
義的（拼錯了嗎？）類型，則它假定構造函數是一個表達式，並發出 C2062。若要解決此錯誤，請只使用構造函數參數列表
中的定義類型。
編譯器錯誤 C2063 錯誤消息
「identifier」: 不是函數
該標識符用作函數，但未聲明為函數。
編譯器錯誤 C2064 錯誤消息
項不會計算為接受「number」個參數的函數
通過表達式調用了函數。該表達式未計算為函數指針。
編譯器錯誤 C2065 錯誤消息
「identifier」: 未聲明的標識符
在可使用變數的類型前必須在聲明中指定它。在可以使用函數前必須在聲明或原型中指定該函
數使用的參數。
可能的原因：
1.您正在用 C 運行庫的調試版本進行編譯，在 for 循環中聲明標准 C++ 庫迭代器變數，然後
嘗試在 for 循環范圍外使用該迭代器變數。 用 C 運行庫的調試版本編譯標准 C++ 庫代碼暗指使用 /Zc:forScope。有關更
多信息，請參見調試迭代器支持。
2.可能正在調用當前不受生成環境支持的 SDK 頭文件中的函數。
3.省略必要的包含文件，尤其是在定義 VC_EXTRALEAN、WIN32_LEAN_AND_MEAN 或
WIN32_EXTRA_LEAN 時。這些符號從 windows.h 和 afxv_w32.h 中排除了一些頭文件以加快編譯。（在 windows.h 和
afxv_w32.h 中查找排除的頭文件的最新說明。）
4.標識符名拼寫錯誤。
5.標識符使用了錯誤的大小寫字母。
6.字元串常數的後面缺少右引號。
7.命名空間范圍不正確。例如，若要解析 ANSI C++ 標准庫函數和運算符，則必須用 using 指
令指定 std 命名空間。下面的示例未能編譯，因為 using 指令被注釋掉，並且在 std 命名空間中定義了 cout：
❻ nat1會降低延遲嗎
設置好了可以降低的。
-網路環境：
我這邊的網路環境，電信189套餐一共送了20條寬頻。其中1條300M下30M上，1條100M下20M上，還有18條是50M下10M上，一條100M對等的聯通，在加上後期拉的2條500M電信對等，所以家裡一共是23條寬頻，都為公網IP。3個電信光貓，1個聯通光貓，若幹路由器，交換機。
-CDN節點共享（閑置流量換錢）：
早期，我網路環境沒這么多，就玩迅雷的紅水晶，再到迅雷路由，再到賺錢寶再到玩客雲，可以說是一路走來。其中一代賺錢寶和賺錢寶pro掛的最久，後來不賺錢，就賣掉了大部分，玩客雲因為網路的限制，留了幾台，大部分搶到就是當倒爺。既然寬頻這么多條，涉及到多線多撥，鐵定上軟路由，選愛快，操作簡便，分流效果都挺好。既然有這么多閑置的帶寬，剛好玩客雲出現了現金，買幾台試下，加上寬頻提速加成，效果不錯，於是就買了20幾台，賺點小錢，畢竟窮。
-開始出現問題：
沒想這玩意是真的能跑，20多台設備上傳流量量速率達到了千兆，我用了幾年的3215U 4口的軟路由，開始不堪重負，100%的幹活，也不知道是不是開繁星導致，反正感覺吃不消，但是上網啥的沒問題，但是過了一陣子，發現當ap的ac88u，wifi開始不穩，會掉線，然後比較難連上。這讓喜歡吃雞的女王大人無法忍受，顯然，挨罵是一定的。一開始以為是86u斷流，用排除法，加上acrh17當ap，問題依舊，看來是就是軟路由的鍋。剛好電信有個500M對等的優惠套餐，果斷辦理，為了不受千兆埠限制，讓電信小哥，再拉一條光纖，此時家裡已經有了4個光貓了，電信3個，聯通1。4口的軟路由埠開始不夠用了。寬頻太多，很容易達到千兆瓶頸，一個光貓1G的帶寬。
-性能不夠硬體來湊
剛好同事需要軟路由，把3215u出了。手頭上還有dq77kb+e3 1265l v2，買個4口網卡當軟路由，年少不懂事，上了淘寶買了i350-t4（寨卡）。不過還好用著沒問題。這下性能應該不會瓶頸了，然而，wifi有時會連不上的問提依舊，看來是愛快的bug了，但是愛快用了好多年了，好多配置都在裡面，如果換固件，調配置，比如ddns，埠轉發，分流啥的，就要弄好久。但是wifi的問題不能不解決，剛好在群里看到有人說愛快，當設備跑多了，就會出現這個情況，上個三層交換機就會解決問題。那就上某魚淘個二手的三層交換機來試試吧。後來看到群里有有人提到nat類型，對提高收益有幫助。於是大致了解了下，給大夥貼下。
-Nat類型
1. Full Cone NAT（簡稱NAT1）：
所有來自同一 個內部Tuple X的請求均被NAT轉換至同一個外部Tuple Y，而不管這些請求是不是屬於同一個應用或者是多個應用的。除此之外，當X-Y的轉換關系建立之後，任意外部主機均可隨時將Y中的地址和埠作為目標地址 和目標埠，向內部主機發送UDP報文，由於對外部請求的來源無任何限制，因此這種方式雖然足夠簡單，但卻不那麼安全。
2. Restricted Cone NAT（簡稱NAT2）：
它是Full Cone的受限版本：所有來自同一個內部Tuple X的請求均被NAT轉換至同一個外部Tuple Y，這與Full Cone相同，但不同的是，只有當內部主機曾經發送過報文給外部主機（假設其IP地址為Z）後，外部主機才能以Y中的信息作為目標地址和目標埠，向內部主機發送UDP請求報文，這意味著，NAT設備只向內轉發（目標地址/埠轉換）那些來自於當前已知的外部主機的UDP報文，從而保障了外部請求來源的安全性。
3. Port Restricted Cone NAT（簡稱NAT3）：
它是Restricted ConeNAT的進一步受限版。只有當內部主機曾經發送過報文給外部主機（假設其IP地址為Z且埠為P）之後，外部主機才能以Y中的信息作為目標地址和目標埠，向內部主機發送UDP報文，同時，其請求報文的源埠必須為P，這一要求進一步強化了對外部報文請求來源的限制，從而較Restrictd Cone更具安全性。
4. Symmetric NAT（簡稱NAT4）：
這是一種比所有Cone NAT都要更為靈活的轉換方式：在Cone NAT中，內部主機的內部Tuple與外部Tuple的轉換映射關系是獨立於內部主機所發出的UDP報文中的目標地址及埠的，即與目標Tuple無關。
上面是我網路出來，反正只要認為nat1是最好的就行，根據我的經驗來說，像愛快，高恪之類的軟路由都是nat4,。Lede可以nat1，而平常普通路由撥號的nat類型為3，刷高恪和openwrt就可以做到nat1。當然只要你路由器做了dmz也是可以變成nat1，但是這個只能指定內網的一個主機，你多台的就不行。那nat1對提高收益有幫助嗎？對此，我還專門做了測試，拿出礦渣newifi3，編譯了對應的openwrt固件，感謝lean大雕的源碼，開始掛上，做為期幾天的測試，結論是確實可以提高收益，而且對p2p游戲下載啥的也有幫助。
-目前支持nat1固件:
openwrt系列，理論能刷的openwrt都可以
k2p高恪固件，
acrh17也可以刷改版梅林實現full cone（感謝大雕的固件，該有的功能都有。）
梅林固件，目前只有新內核才支持，例如ac86u，ax88u。
❼ 如何在 Windows 下編譯 OpenSSL
在Windows下編譯OpenSSL （VS2010使用VC10的cl編譯器）
1、安裝ActivePerl//初始化的時候,需要用到perl解釋器
2、使用VS2010下的Visual Studio 2010 Command Prompt進入控制台模式（這個模式會自動設置各種環境變數）
3、解壓縮openssl的包,進入openssl的目錄
4、perl configure VC-WIN32
盡量在這個目錄下執行該命令，否則找不到Configure文件，或者指定完整的Configure文件路徑。
5、ms\do_ms.bat
在解壓目錄下執行ms\do_ms.bat命令
6、nmake -f ms\ntdll.mak
7、nmake -f ms\nt.mak
編譯後
在openssl解壓目錄下執行，完成編譯後。輸出的文件在out32dll (6), out32 (7)裡面，包括應用程序的可執行文件、lib文件和dll文件
注意：在運行第五步時，cl編譯器會抱怨說.\crypto\des\enc_read.c文件的read是The POSIX name for this item is deprecated（不被推薦的），建議使用_read。呵呵，我可不想將OpenSSL中的所有的read函數修改為_read。再看cl的錯誤代碼error C2220，於是上MSDN上查找：
warning treated as error - no object file generated
/WX tells the compiler to treat all warnings as errors. Since an error occurred, no object or executable file was generated.
是由於設置了/WX選項，將所有的警告都作為錯誤對待，所以。。。
於是打開OpenSSL目錄下的MS目錄下的ntdll.mak文件，將CFLAG的/WX選項去掉，存檔。。。
繼續執行nmake -f ms\ntdll.mak
=================================
一、編譯並安裝OpenSSL
1、按照標准步驟從源代碼編譯安裝OpenSSL
在編譯OpenSSL前，需要正確安裝Perl，因為在編譯OpenSSL時需要使用到該程序。
下載最新版本的Perl然後安裝之。
下載最新版本的OpenSSL
然後將源碼解壓縮到某個目錄（如 C:\openssl-0.9.8j）中。
進入openssl源碼目錄。
cd c:\openssl-1.0.1e
以下為參照該目錄下的文件INSTALL.W32的執行過程：
運行configure：
perl Configure VC-WIN32
創建Makefile文件：
ms\do_ms.bat
編譯動態庫：
nmake -f ms\ntdll.mak
編譯靜態庫：
nmake -f ms\nt.mak
測試動態庫：
nmake -f ms\ntdll.mak test
測試靜態庫：
nmake -f ms\nt.mak test
安裝動態庫：
nmake -f ms\ntdll.mak install
安裝靜態庫：
nmake -f ms\nt.mak install
清除上次動態庫的編譯，以便重新編譯：
nmake -f ms\ntdll.mak clean
清除上次靜態庫的編譯，以便重新編譯：
nmake -f ms\nt.mak clean
2、如果嫌麻煩，不想編譯，可以直接用別人做好的windows OpenSSL 安裝包（我用的是0.9.8j版），
可以下載 OpenSSL for Windows，直接安裝。
P.S. OpenSSL for Windows 的源代碼有一些數據類型和VC6的編譯器不兼容，我發現的不兼容的數據類型如下：
在OpenSSL安裝目錄的下的include/bn.h文件中，將
#define BN_ULLONG unsigned long long
#define BN_ULONG unsigned long long
#define BN_LONG long long
分別修改為：
#define BN_ULLONG ULONGLONG
#define BN_ULONG ULONGLONG
#define BN_LONG LONGLONG
否則，會出現編譯錯誤。
二、使用OpenSSL
在VC中配置使用以上的函數庫：
點擊菜單：Tools -> Options，彈出對話框"Options"，在該對話框中選擇"Directories"標簽。
在"Show directories for:"的"Include files"選項中新增目錄"C:\openssl\include"；
"Library files"選擇中新增目錄"C:\openssl\lib"。
然後在需要鏈接OpenSSL函數庫的工程中加入如下兩句：
#pragma comment(lib, "ssleay32.lib")
#pragma comment(lib, "libeay32.lib")
其作用是將OpenSSL所需的庫導入工程中。
三、問題
我在鏈接OpenSSL的靜態函數庫時遇到類似以下的問題：
Linking...
msvcrt.lib(MSVCRT.dll) : error LNK2005: _strchr already defined in libcmtd.lib(strchr.obj)
...
這是由於OpenSSL的靜態函數庫使用的是了VC的多線程DLL的Release版本，而我的程序使用了多線程靜態鏈接的Release版本。
調整OpenSSL的靜態函數庫使用的庫函數版本即可，調整過程如下：
編輯文件 ms\nt.mak，將該文件第19行
"CFLAG= /MD /Ox /O2 /Ob2 /W3 /WX /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -
D_CRT_NONSTDC_NO_DEPRECATE /Fdout32 -DOPENSSL_NO_CAMELLIA -DOPENSSL_NO_SEED -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_TLSEXT -DOPENSSL_NO_KRB5 -
DOPENSSL_NO_DYNAMIC_ENGINE"
中的"/MD"修改為"/MT"。然後重新編譯安裝OpenSSL即可。
四、附錄：在VC中對C/C++ 運行時庫不同版本編譯指令說明
《在VC中對C/C++ 運行時庫不同版本編譯指令說明》一文中詳細介紹了連接不同版本庫的編譯指令如下：
C Runtime Library：
/MD MSVCRT.LIB 多線程DLL的Release版本
/MDd MSVCRTD.LIB 多線程DLL的Debug版本
/MT LIBCMT.LIB 多線程靜態鏈接的Release版本
/MTd LIBCMTD.LIB 多線程靜態鏈接的Debug版本
/clr MSVCMRT.LIB 託管代碼和非託管代碼混合
/clr:pure MSVCURT.LIB 純託管代碼
C++ Standard Library：
/MD MSVCPRT.LIB 多線程DLL的Release版本
/MDd MSVCPRTD.LIB 多線程DLL的Debug版本
/MT LIBCPMT.LIB 多線程靜態鏈接的Release版本
/MTd LIBCPMTD.LIB 多線程靜態鏈接的Debug版本
===============================================
一 配置編譯參數
配置編譯參數是進行OpenSSL編譯的第一步,這一步可以確定系統的環境,使用什麼編譯器,默認安裝路徑以及其他一些選項.步驟如下:
1.安裝perl:下載ActivePerl-5.8.8.822-MSWin32-x86-280952.msi,然後點擊msi文件進行安裝!
2..配置編譯參數:下載openssl-1.0.1e.tar.gz,解壓.
vc:首先在C:\Program Files\Microsoft Visual Studio .NET 2010\VC10\bin\目錄下執行vcvars32.bat,然後在解壓後的openssl-1.0.1e目錄,執行命令配置編譯參數:perl Configure VC-WIN32
bc:在解壓後的openssl-0.9.8g目錄下執行:perl Configure BC-32
二 生成批處理文件
在使用configure腳本配置好的編譯參數後,就可以使用批處理命令來生成編譯腳本.生成編譯腳本根據採用編譯器的不同通常使用不同的批處理文件.就目前來說,使用vc編譯的時候有三種選擇:do_ms,do_masm和do_nasm來創建一系列編譯腳本文件,即.mak腳本.步驟如下:
vc:在openssl-1.0.1e目錄下,執行命令來批處理文件:do_ms,do_masm和do_nasm
bc:1.下載nsm09839.zip微軟匯編編譯器,解壓,拷貝到c:/windows目錄下,修改名稱為nasmw.exe;2.在openssl-1.0.1e目錄下,執行命令來批處理文件:ms\do_nasm
三 代碼編譯
vc:
完成上面步驟後,可以看到兩個關鍵腳本文件:nt.mak和ntdll.mak.如果我們需要編譯後的OpenSSL庫是支持動態DLL形式的,那麼應該使用ntddll.mak文件進行編譯,這樣編譯完成我們會得到四個與OpenSSL的API庫有關文件:ssleay32.lib,libeay32.lib,ssleay32.dll和libeay32.dll.執行的編譯命令形式如下:nmake -f ms\ntdll.mak
如果不希望以動態庫的形式使用OpenSSL,那麼可以使用nt.mak文件進行編譯.這樣編譯後使用OpenSSL的時候,回直接將代碼鏈接進我們的程序裡面.執行命令如下:nmake -f ms\nt.mak
bc:執行命令來完成代碼編譯:make -f ms\bcb.mak
四 ELSE
1)測試動態庫：
nmake -f ms\ntdll.mak test
測試靜態庫：
nmake -f ms\nt.mak test
安裝動態庫：
nmake -f ms\ntdll.mak install
安裝靜態庫：
nmake -f ms\nt.mak install
清除上次動態庫的編譯，以便重新編譯：
nmake -f ms\ntdll.mak clean
清除上次靜態庫的編譯，以便重新編譯：
nmake -f ms\nt.mak clean
2)使用OpenSSL
在VC中配置使用以上的函數庫：
點擊菜單：Tools -> Options，彈出對話框"Options"，在該對話框中選擇"Directories"標簽。
在"Show directories for:"的"Include files"選項中新增目錄"C:\openssl\include"；"Library files"選擇中新增目錄"C:\openssl\lib"。
然後在需要鏈接OpenSSL函數庫的工程中編譯時加入"libeay32.lib"就可以了。
❽ 有沒有人成功編譯過LEAN大的LEDE
按照錯誤提示，"試圖載入重復的模塊"。
它指出，在文件config_PA_thir.c(或者.asm...，這個你自己看一下)，模塊PA_CONF_FIR就是那個有問題的模塊。
❾ vs2008添加預編譯命令
以預編譯頭文件為Stdafx.h為例：
Qt Creator中很簡單,只需在.pro文件中加入一行PRECOMPILED_HEADER = stdafx.h
VS2008在工程中在Stdafx.h文件上右鍵propertis-Configuration Properties-C/C++-Precompiled Headers-Create/Use Precompiled Header中選擇Create Precompiled Header(/y).
有一點注意的是，在工程Generated Filed中的moc相關文件也需要選上Use Precompiled Header (/Yu).