Ⅰ 程序代碼正確\但是編譯時顯示一個錯誤\運行不了\除了第一次編寫的可以用\後來其他的都用不好
你的程序中含有不可見的中文字元。
Ⅱ 請問在 Dev C++ 里編寫的 Windows 程序,為什麼原先可以編譯的，但修改了之後再改回來就不能編譯了呢
說明白點，就是你自己編譯並運行後那個運行框沒關閉，就又再編譯。一些編譯器不能打開多個運行框，如：Dev
Ⅲ 用c++編好的程序為什麼保存好了再次打開編譯就會出現問題
首先檢查你的ide環境是不是完備；其次檢查你的操作系統環境是不是兼容；最後檢查你的代碼是不是正確。
Ⅳ 本來這個代碼之前可以運行，後面重裝了C++後就不能運行了，編譯後就有這個問題，求解
VC9編譯的程序在沒有裝過VC9（確切的說是.Net Framework3.5）的機器上運行時，如果提示「由於應用程序配置不正確，應用程序未能啟動。重新安裝應用程序可能會糾正這個問題。」這個錯誤，那 么就說明該程序動態鏈接了VC9的運行時庫，（如果還用到了MFC，那麼可能動態鏈接了VC9的MFC庫，同理還有ATL庫），以及缺少對應的 manifest文件，程序在目標機器上沒有找到這些庫和配置文件，因此導致了這個錯誤。出現這種情況的VC9編譯器可能存在3個版本，接下來分別闡明：
1、沒有打過任何補丁的VS2008
該版本對應的CRT/MFC/ATL庫的版本號為9.0.21022.8，這個版本號在後面 會用到。這個版本的程序部署比較簡單，直接把VC安裝目錄下的redist目錄（C:/Program Files/Microsoft Visual Studio 9.0/VC/redist）中需要的庫以及對應的manifest文件拷貝到執行程序同目錄下，這樣程序到任何機器上都能夠正常運行了。
2、打過SP1補丁的VS2008
打過該補丁後，系統中存在著兩個版本的CRT/MFC/ATL庫，版本號分別為 9.0.21022.8和9.0.30729.1，這導致了manifest文件中記錄的版本號和實際庫的版本號不一致（程序要求它們的版本號一致才能運 行）。這個版本的程序部署需要兩個步驟，首先要使manifest文件中依賴項的版本號與實際庫的版本號一致，均為9.0.30729.1，方法是在工程 設置中增加一個宏定義_BIND_TO_CURRENT_VCLIBS_VERSION，該宏定義於C:/Program Files/Microsoft Visual Studio 9.0/VC/include/crtassem.h文件中，然後重新編譯程序。接下來還是將VC安裝目錄下的redist目錄（C:/Program Files/Microsoft Visual Studio 9.0/VC/redist）中需要的庫以及對應的manifest文件拷貝到執行程序同目錄下，然後修改manifest文件中依賴項的版本號為 9.0.21022.8，這樣使得程序誤以為該目錄下庫的版本號為9.0.21022.8（實際上是9.0.30729.1版本），這樣程序到任何機器上 都能夠正常運行了。
3、打過SP1補丁與SP1 ATL 安全更新 (KB973675)的VS2008
這是最新的更新。在SP1補丁之後，微軟又於近日發布了一個用於智能設備的 Microsoft Visual Studio 2008 Service Pack 1 ATL 安全更新 (KB973675)， 該補丁又將CRT/MFC/ATL庫的版本號升級，為9.0.30729.4148，這次升級比較好，manifest文件與庫的版本號一致了，不像 SP1一樣升級的不徹底。這樣只需要在工程設置中增加一個宏定義_BIND_TO_CURRENT_VCLIBS_VERSION，接下來重新編譯程序， 然後直接把VC安裝目錄下的redist目錄中需要的庫以及對應的manifest文件拷貝到執行程序同目錄下，這樣程序到任何機器上都能夠正常運行了。
順便提一下，如果不想在發布程序時帶上這些庫和manifest文件（如果沒有必要的話），那麼可以採用靜態編譯CRT和MFC，然後把manifest文件添加到資源中，這樣編譯出的程序只要一個exe就可以在任何機器上直接運行了。
參考文章：
1、「應用程序配置不正確，程序無法啟動」的解決方法資料收集：
有的時候，你在Visual C++上面經過好幾個月的辛勤努力，終於將程序編寫完成並且測試完畢，然而當你試圖在客戶的發布機上運行剛寫好的程序時，有可能會碰到類似下面的錯誤，操 作系統告訴你「由於應用程序配置不正確，應用程序未能啟動。重新安裝應用程序可能會糾正這個問題」.
一般情況下，這個問題都是由於程序不能找到所需要的C運行庫（CRT）而引起的。
在Windows XP SP2以後，Windows引入了Side-by-Side執行的概念，這個概念本來是.NET提出來的，但是Windows後來將這個概念集成到操作系統層面上來了。大家都應該知道Dll Hell 的問題，為了解決Dll Hell 的問題，Side-By-Side提出不同版本的dll文件可以同時存在於同一個系統裡面，而且依賴於不同版本dll的應用程序在運行的時候可以使用到它當初被編譯生成的dll。前面的話，有點繞，舉個例子：
1. 假定你編寫了一個C++程序A，是使用MFC 8.0（這個版本是隨著Visual Studio 2005）發布的。
2. 之後你的機器升級了Visual Studio的版本，從2005升級到2008，2008的MFC庫是9.0版本的，這個時候你的操作系統裡面安裝了兩個版本的MFC，分別是8.0和9.0。
3. 你在Visual Studio 2008編寫了另外一個C++程序B，B依賴與MFC 9.0。
4. 如果你運行程序A的話，操作系統會將MFC 8.0載入到A的進程裡面。
5. 如果你這時同時運行程序B，操作系統會將MFC 9.0載入到B的進程裡面。這就是Side-by-side的執行概念。
操作系統之所以能夠這樣做，是因為它在載入程序A和B之前，除了查看PE格式裡面A和B所依 賴的Dll信息，都會查看A和B的manifest文件。Manifest文件保存了Windows可執行文件（包括exe和dll文件）要運行起來的環 境設置信息，文件名一般是可執行文件的文件全名加上.manifest。例如notepad.exe的manifest文件就應該是 notepad.exe.manifest。例外有的程序將manifest文件直接嵌入到可執行文件的資源裡面了，這也就是為什麼有的時候你看不到程序 的manifest文件的原因。通常來說，一個manifest文件的內容如下（test.exe.manifest文件）：
Ⅳ 重新打開一前編譯的文件，就不能再編譯了，出現這個錯誤，怎麼整啊，跪求大佬解救
可能的原因及解決辦法：
1.
已有一個本程序的實例在運行了。只需先關閉運行的實例再編譯就行了。
2.
因代碼中使用了未定義的變數或函數，導致發生了鏈接錯誤。加上變數或函數的定義就行了。
Ⅵ 以前編的fortran程序，現在為什麼不能用
這通常不是由不同的計算機引起的，而是不同的編譯器和操作系統引起的。
每個編譯器對語法的檢查程度不同，對堆棧的分配方式不同。
這個錯誤是堆棧溢出，這通常發生在循環較多的大型程序中，特別是對於遞歸函數調用，或者大型數組應用的程序里。
你可以有兩條途徑解決：
1.減少堆棧的使用。主要通過把固定大小的數組改為可分配數組來解決。
2.增加堆棧的大小。這是一個對編譯器的操作。需要你翻閱你所使用的編譯器的說明書（幫助文檔）來確定具體的操作。
以Compaq Visual Fortran為例：
選Project => Settings => Link => Category: Output =>
Stack allocations
Reserve: 這里填新值（默認為1M，若需要10M，則填10000000）
如果你使用其他的編譯器，你也可以追問，告訴我你的編譯器品牌和版本。我看是否熟悉它。
Ⅶ C語言源代碼編譯一次後，就不能再編譯
你用輸出的二進制運行文件覆蓋了源代碼，改成gcc helloworld.c -o helloworld, （去掉後綴）
-o 表示輸出到
Ⅷ C++,為什麼我的程序能運行 再次編譯卻不行了
編譯的時候提示什麼問題？是不是有錯誤？
應該是你之前已經編譯好了，現在的代碼有問題，你直接運行的話，就是運行之前的程序，再次編譯成功後才會運行現在的程序。
不然就是編譯器的問題吧
Ⅸ 同樣的程序之前可以編譯 然後突然就不能編譯了 還不報錯
都編譯過了，已經有HEX文件，還編譯幹嘛
Ⅹ 易語言調試運行的時候好用，靜態編譯後的程序就不能正常使用
你的源碼能不能上傳一下呢？ 首先您的 串口 你得確定是否正確 然後 確定下 代碼 有沒有調試輸出的代碼 因為調試輸出這些代碼 在編譯的時候 都會去掉的 一般新手 都會很容易無視掉