程序沒問題，看一下同一個 目錄下 是否有 相同的類名
比如：
你是不有 javac *java ,盡量不要這樣。比如
有個 A.java 內容
public class A{
}
B.java
class A{
}
public class B{
}
就會有問題 應該 javac A.java,
javac B.java
B. C語言程序編譯報錯 redefinition; different basic types
你的part.h裡面是不是也有#include "para.h"?
改下para.h試試
#ifndef PARA_H_
#define PARA_H_
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
typedef struct
{
double box0[3];
double box1[3];
double dt;
int init_step;
int nstep;
} t_para;
void para_read(char *r_name, char *w_name, t_para *para);
#endif
C. 為什麼說低代碼才是程序員的未來
雖然零代碼確實是設計給非專業開發者用的，但其所能支撐的業務場景確實有限，無法真正革新傳統開發模式，替代那些仍需專業開發者參與的復雜業務場景。而狹義上的低代碼卻有潛力做到這一點，因為它天生就是為專業開發者而量身定製的。Gartner最近的一項調研報告顯示，「66%的低代碼開發平台用戶都是企業IT部門的專業開發者」。這充分說明了，專業開發者比平民開發者更需要低代碼。
屏幕前一批穿格子襯衫的同學要發問了：「低代碼都不怎麼寫代碼了，怎麼能算是為我們程序員服務呢？」。雖然程序員討厭重復自己，但重要的事情還是得多說一遍：開發 ≠ 寫代碼。1萬年前蹲在洞穴里的原始人，在用小石子畫遠古圖騰；100年前坐在書桌前的徐志摩，在用鋼筆給林徽因寫情書；而今天趴在屏幕前的很多人，相信都已經開始用上手寫板或iPad塗塗寫寫了。千百年來，人類使用的工具一直在演進，但所從事活動的本質並沒有多大改變。無論是用小石子還是小滑鼠，寫作繪畫的本質都是創造與表達，最終作品的好壞並不取決於當時你手中拿著什麼；同樣地，應用開發的本質是想法和邏輯，最終價值的高低也不取決你實現時是用的純代碼還是低代碼。
而相比純代碼而言，低代碼極有可能成為更好的下一代生產力工具：
減少不必要的工作量
可視化拖拽與參數配置的極簡開發模式，結合模型驅動的代碼自動生成機制，可以消滅絕大部分繁瑣和重復的boilerplate代碼；一站式的部署和運維管理平台，無需自己搭建CI/CD流水線、申請環境資源、配置監控報警；一次搭建同時生成、構建和發布多端應用，免去人工同步維護多個功能重復的端應用；開箱即用的組件庫、模板庫、主題庫、連接器等，讓最大化軟體復用成為可能。總而言之，低代碼能夠讓專業開發者更專注於創新性、有價值、有區分度的工作，而不是把寶貴開發時間都耗費在上面那些不必要兆搜的非業務核心工作上。
強大的平台能力支撐
雖然上面列的技術支撐性工作並不直接產生業務價值，但卻會直接影響業務的性能、成本、穩定性、安全性、可持續發展能力等。有遠見的企業，絕不允許犧牲這些重要指標，來換取短暫的業務加速。低代碼開發平台深知這一點，因此在簡化和屏蔽底層技術細節的同時，也會盡可能把自己所cover的部分做到最好（至少能和純代碼開發方式一樣好），包括但不限於：
現代化的技術架構和實現：現代化的低代碼開發平台，在支撐用戶應用時所選擇的技術架構與實現方案，也會是現代化且符合業界最物猜世佳實踐的，例如，前端基於主流的HTML5/CSS3標准和React框架，後端基於成熟的Java語言、SpringBoot框架和MySQL資料庫，部署環境基於雲原生的Docker鏡像、CI/CD流水線、K8s集群和Service Mesh技術（相關知識可參考《正確入門Service Mesh：起源、發展和現狀》）。
零成本的技術升級和維護：低代碼的高維抽象開發方式，讓應用的核心業務邏輯與底層技術細節解耦。開發者在大部分情況下都不需要關心底層技術選型，同時也無需親自跟進這些技術的版本升級與漏洞修復，免費享受與時俱進的技術紅利和應用安全性提升。即便遇到某些底層技術或工具需要進行更換（比如不再維護的開源項目），開發者也完全不必感知；技術遷移再費勁再難搞，平台自己努力就行，對開發者來說只要服務一直在線，歲月就依然靜好；事後可能還會驚喜地發現，應用訪問突然就變得更快了，彷彿冥冥中自有天助，感激上蒼和低代碼。
一體化生態能力復用
復用（Reuse）是提升軟體開發效率和工程質量的最有效途徑。傳統的代碼開發模式下，開發者可以通過提取公共類/函數、引用共享庫、調用外部API服務、沉澱代碼片段和模板等方式實現復用。在低代碼的世界裡，平台也可以提供對應的多層次多粒度復用手段，比如頁面組件庫、邏輯函數庫、應用模板庫等。
但更重要的是，低代碼平台還可以充分發揮其一體化的生態優勢，提供強用的可復用能力（資產）的發現、集成與共享體系：以頁面組件為例，你可以直接用系統組件，也可以在平台自帶的組件市場上搜索罩肢和引用更合適的組件，還可以自己用代碼開發一個自定義組件並發布到市場中。平台的生態體系越大，積累的可復用能力就越多，應用的開發成本也會越低。
相比而言，雖然傳統代碼世界整體生態更龐大和深厚，但由於各類技術不互通、缺乏統一平台與市場、代碼集成成本高等原因，一直以來都沒有形成有類似規模潛力的生態能力復用體系，導致重復造輪子和低水平重復建設的現象司空見慣，還美名為「新基建」。
說到這里，另一批裹著沖鋒衣頭頂鋥亮的同學也忍不住了：「萬一低代碼真的發展起來了，是不是就不需要那麼多程序員了啊？上有老下有小的，同是碼農身，相煎何太急！」。低代碼雖然是一場應用開發生產力革命，但並不會革掉程序員的飯碗。它去掉的只是難懂的編程語法、繁瑣的技術細節和一切可自動化的重復性工作，並沒有也無法去掉應用開發最核心的東西：嚴謹的業務邏輯、巧妙的演算法設計、良好的工程風格等。對於真正的程序員，即使剝去他一層又一層的編程語言和工具熟練度技能外殼，最終剩下的仍然是一個有價值的硬核開發者。
當然，如果你堅持要用純粹的寫代碼方式來改變世界，也不至於失業。要麼，你可以選擇那些低代碼暫時不太適用的領域，比如底層系統驅動、3D游戲引擎、火箭發射程序；或者，你也可以選擇去寫低代碼中那一部分不可或缺的自定義代碼擴展，為平民開發者提供高質量的積木。最後，你也完全可以選擇為低代碼平台本身的底層代碼添磚加瓦。
D. 程序編譯錯誤不知道是什麼原因
不能通編譯過的程序實際上還不是合法的程序，因為它不滿足C語言對於程序的基本要求。
檢查語法錯誤的第一要義：集中力量檢查系統發現的第一個錯誤，弄清並改正它。
在編譯過程中系統發現的錯誤主要有兩類：基本語法錯誤和上下文關系錯誤。這些錯誤都在表面上，可以直接看得見。也是比較容易弄清，比較容易解決的。關鍵是需要熟悉C語言的語法規定和有關上下文關系的規定，按照這些規定檢查程序正文，看看存在什麼問題。
編譯中系統發現錯誤都能指出錯誤的位置。不同系統在這方面的能力有差異，在錯誤定位的准確性方面有所不同。有的系統只能指明發現錯誤的行，有的系統還能夠指明行內位置。
一般說，系統指明的位置未必是真實錯誤出現的位置。通常情況是錯誤出現在前，而系統發現錯誤在後，因為它檢查到實際錯誤之後的某個地方，才能確認出了問題，因此報出錯誤信息。要確認第一個錯誤的原因，應該從系統指明的位置開始，在那裡檢查，並從那裡開始向前檢查。
系統的錯誤信息中都包含一段文字，說明它所認定的錯誤原因。應該仔細閱讀這段文字，通常它提供了有關錯誤的重要線索。但也應該理解，錯誤信息未必准確，有時錯誤確實存在，但系統對錯誤的解釋也可能不對。也就是說，在查找錯誤時，既要重視系統提供的錯誤信息，又不應為系統的錯誤信息所束縛。
發現了問題，要想清楚錯誤的真正原因，然後再修改。不要蠻干。在這時的最大誘惑就是想趕快改，看看錯誤會不會消失。但是蠻乾的結果搏胡常常是原來的錯誤沒有弄好，又搞出了新的錯誤。
另一個值得注意的地方：程序中的一個語法錯誤常常導致編譯系統產生許多錯誤信息。如果你改正了程序中一個或幾個錯誤，下面的弄不清楚了，那麼就應該重新編譯。改正一處常常能消去許多錯誤信息行。
解決語法錯誤
常見語法錯誤：
1）缺少語句、聲明、定義結束的分號。
2）某種括弧不配對。C語言中括弧性質的東西很多，列舉如下：
( ), [ ], { }, ' ', " ", /* */
在不同位置的括弧不配對可能引起許多不同的錯誤信息。
3）關鍵字拼寫錯誤。
較難認定的典型錯誤：
1）宏定義造成的錯誤。這種東西不能在源程序文件中直接看到，是在宏替換之後出現的。常見的能引起語法錯誤的宏定義錯誤：宏定義中有不配對的括弧，宏定鍵轎義最後加了不該有的分號，……
解決上下文關系錯誤
1）變數沒有定義。產生這個問題的原因除了變數確實沒有大意外，還可能是變數的拼寫錯誤，變數的作用域問題（在不能使用某個變數的地方想去用那個變數）。
2）變數重復定義。例如在同一個作用稿銀肆域里用同樣名字定義了兩個變數，函數的局部變數與參數重名等。
3）函數的重復定義。可能是用同一個名字定義了兩個不同的函數。或者是寫出的函數原型在類型上與該函數的定義不相符。有時沒有原型而直接寫函數調用也可能導致這種錯誤信息，因為編譯程序在遇到函數調用而沒有看到函數原型或函數定義時，將給函數假定一個默認原型。如果後來見到的函數定義與假定不符，就會報告函數重復定義錯誤。
4）變數類型與有關運算對運算對象或者函數對參數的要求不符。例如有些運算（如 %）要求整數參數，而你用的是某種浮點數。
5）有些類型之間不能互相轉換。例如你定義了一個結構變數，而後要用它給整數賦值。系統容許的轉換包括：數值類型之間的轉換，整數和指針之間的轉換，指針之間的轉換。其餘轉換（無論是隱含的，還是寫出強制）都不允許。參見《C語言程序設計》（K&R）197-199頁。
如何看待編譯警告
當編譯程序發現程序中某個地方有疑問，可能有問題時就會給出一個警告信息。警告信息可能意味著程序中隱含的大錯誤，也可能確實沒有問題。對於警告的正確處理方式應該是：盡可能地消除之。對於編譯程序給出的每個警告都應該仔細分析，看看是否真的有問題。只有那些確實無問題的警告才能放下不管。
注意：經驗表明，警告常常意味著嚴重的隱含錯誤。
常見警告：
1）（局部自動）變數沒有初始化就使用。如果對局部指針變數出現這種情況，後果不堪設想。對於一般局部自動變數，沒有初始化就使用它的值也不會是有意義的。
2）在條件語句或循環語句的條件中寫了賦值。大部分情況是誤將 == （等於判斷）寫成 = 了。這是很常見的程序錯誤，有些編譯程序對這種情況提出警告。
E. java類重復的問題，編譯時總說"類重復",怎麼修改
變數名重復了，
int grade,s;
char grade;
兩個grade變數