bcc編譯
Ⅰ 不同語言的程序編譯之後一樣嗎
肯定不是一模一樣的
但是運行的結果是一樣的
只要你的高級語言的演算法和實現細節是一樣的
能反編譯，但只能到匯編語言，不可能到高級語言
因為機器碼和匯編是一一對應的
但是，不同的高級語言有可能對應相同的低級語言
所以不能翻譯成高級語言
所謂的0
和
1
其實是有電流，無電流的意思
因為電子計算機實際上是一個復雜的電路
Ⅱ GCC/G++，ICC，Clang，MSVC，BCC，這些編譯器都不好用，到底什麼時候才有一個像樣的編譯器啊！
好用的標準是什麼？
這個編譯器，一般只在初學的時候會手動調用一下。
用IDE如Visual Studio時基本感覺不到。
再就是使用make/cmake/msbuild等構建工具了
Ⅲ 如何使用C++Builder編譯Delphi使用Obj文件
一直以來，Delphi 都可以用命令行 dcc32 ProjectName.dpr 對項目進行編譯鏈接，非常方便，Delphi對項目文件的參數配置處理的很簡單，便於閱讀處理起來也很直觀，編譯的中間文件也很簡單(dcu,dcp)。
而C++Builder就沒那麼幸運了，因為包含了C++的特徵，各種編譯的中間文件：lib,obj,res,map,tds。後來新版又增加了一些預編譯文件：ilc,ild,ilf,...,pch,#00,...等等等等，各種搜索路徑(Include Path,Library Path,Browse Path...)，要是用bcc32及ilink32手工進行編譯鏈接，命令的參數都足夠寫上大半天。幸好，在舊版C++Builder中，如果要用命令行編譯BCB項目，只要將bpr文件轉換為mak文件，再使用make命令進行編譯鏈接也比較方便，不需要過多的處理：
[plain] view plainprint?
bpr2mak -oProject1.mak Project1.bpr
make -fProject1.mak
自從Delphi/C++Builder開始使用 MSBuild* 編譯系統後(好像是RAD Studio 2006開始，具體忘記了)，Delphi項目在保存為dpr的同時，也會保存一份dproj的項目文件，dpr依舊沿用舊格式，dproj 則以MSBuild規范以XML格式保存，除了可以用舊方式命令行編譯dpr外，也可以用：
[plain] view plainprint?
msbuild.exe /t:Rebuild /p:Config=Debug ProjectName.dproj
進行編譯，但msbuild必須設定一些環境變數，RAD Studio自帶了一個命令行工具已經做好了這些，其實就是設定了以下幾個環境變數($(BDS)in svars.bat)：
[plain] view plainprint?
@SET BDS=C:EmbarcaderoRAD Studio7.0
@SET BDSCOMMONDIR=C:UsersPublicDocumentsRAD Studio7.0
@SET FrameworkDir=C:WindowsMicrosoft.NETFrameworkv2.0.50727
@SET FrameworkVersion=v2.0.50727
@SET FrameworkSDKDir=
@SET PATH=%FrameworkDir%;%FrameworkSDKDir%;%PATH%
@SET LANGDIR=EN
C++Builder則又更杯具了一些，bpr2mak.exe工具已經沒有了，所以只能採用MSBuild進行命令行編譯。更加杯具的是，隨著Delphi和BCB被多次轉賣收購，新版本的發布似乎總會有各種各樣的Bug，比如手頭的RAD Studio 2009進行命令行編譯，Delphi正常，BCB則報出超過100個錯誤，類似如下：
[plain] view plainprint?
C:EmbarcaderoRAD Studio7.0BinCodeGear.Cpp.Targets(2175,3): error : Error: Unresolved external '__fastcall Strhlpr::UnicodeFree(System::UnicodeString&)' referenced from C:EMBARCADERORAD STUDIO7.0LIBDEBUGVCLE.LIB|ustring
C:EmbarcaderoRAD Studio7.0BinCodeGear.Cpp.Targets(2175,3): error : Error: Unresolved external 'Typinfo::BooleanIdents' referenced from C:EMBARCADERORAD STUDIO7.0LIBDEBUGVCLE.LIB|vclinit
檢查了一下發現編譯過程(bcc32.exe)沒有問題，只是在ilink32.exe鏈接過程中報錯，在IDE中打開此項目進行編譯，查看Message->Output窗口，比較兩者的ilink32命令行參數，發現兩者有兩個地方有明顯差異，一個是IDE生成的命令中沒有類似 C:EmbarcaderoRAD Studio7.0libENdebug 的路徑(指的是EN這個目錄，去除上面rsvars.bat中的@SET LANGDIR=EN 就可以避免產生這樣的搜索路徑) ，但是雖然這個目錄不存在，也應該不至於導致出錯。第二個差異是缺少了rtl.bpi和vcl.bpi的附加obj參數，解決辦法是在$(BDS)in目錄中找到 CodeGear.Cpp.Targets 文件，用記事本打開，搜索字元「memmgr.lib「，在前面加上"rtl.bpi;vcl.bpi" (用;分隔，不含引號)，一共有兩處要修改。或者查找 "c0w32"，在後面加上 "rtl.bpi;vcl.bpi"，只有一處修改 —— 因為IDE的命令行中 rtl.bpi vcl.bpi是在c0w32和memmgr.lib中間的。—— （注意：在XE2中，加在c0w32後面已經不管用了，編譯會報另一個錯誤VCL.BPIW.OBJ不存在，Targets文件有很大變化，可能參數的位置變動過了，導致與其他參數混在一起，所以還是加到memmgr.lib處更加合理）。
一些組件包比如DevExpress的Package，沒有dproj或者cproj 項目文件，只能通過IDE進行轉換，但坑爹的是bpk在好幾個版本以前(CRS 2007?)已經不支持bpk項目，根本打不開也談不上轉換了，但它其實是一個make文件，可惜用make命令編譯還是要出錯，不想去研究了。總之，BCB永遠活在Delphi的陰影下。
Ⅳ c語言的編譯器是不是都一樣
不一樣，支持的語言特性不同，編譯出的代碼效率不同。當然，還有就是編譯出的程序在不同的系統上跑的。比較好的c編譯器就是gcc和vc了。這兩是x86上用的最多的c編譯器還有像Intel的ICC也不錯，優化很好。
Ⅳ GCC/G++，ICC，Clang，MSVC，BCC等C/C++編譯器有什麼特長和不足
clang編譯速度快，但是貌似編譯結果運行相對會慢。功能更新一般也比較快。
g++編譯速度比clang慢，編譯結果運行貌似比clang快。功能更新稍慢。
vc這幾年沒編譯過大工程，感覺上編譯速度在clang和g++之間。以過去的經驗g++和vc編譯結果運行速度差不多。功能更新上就是一坨屎。但是在Windows上寫點正經東西你可能不得不用它，相對的你也只能在Windows上用它。
icc很久沒用過，過去印象編譯速度很慢，運行速度最快但是感覺有點得不償失。最大的問題是這東西要錢，前三個都是免費的。
bcc直接無視就好了。
Ⅵ 編譯原理正規式轉正規文法問題
正規式：a(a丨b)*
正規集：就是表示必須以終結符a開始，後面可以出現若干個a或b（包括0）的連續的串
這個題目是7個一起的
不是7道題，s為開始文法，後面都是連著的
Ⅶ 是不是每個語言有每個語言的編譯器
c語言的編譯器有多種，功能基本一致，但是也稍有差別。例如，對某些語句的解釋不同，導致程序運算的結果不同。
1、建議初學者使用turbo
c2作業編輯器比較好，而且turbo
c2在網路上有很多免費版是；
2、vc++編輯器也可以；
3、還有bcc
developer，不過這個編輯器目前只有日語版本，網路上很少看到。