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，不过这个编辑器目前只有日语版本，网络上很少看到。