不时有人在SO上指出char(也就是"字节")不一定是8位.
似乎8位char几乎是通用的.我原本认为,对于主流平台,必须有一个8位char才能确保其在市场上的可行性.
现在和历史上,哪些平台使用的char不是8位,为什么它们与"普通"8位不同？
在编写代码时,考虑跨平台支持(例如,对于通用库而言),对于非8位平台,值得考虑的是什么char？
在过去,我遇到过一些char16位的ADI DSP .我认为DSP是一种利基架构.(然后,当时手工编写的汇编程序很容易击败可用的C编译器可以做的事情,所以我在该平台上没有真正获得C的经验.)
来自C++标准的两个引用,§1.8:
对象是存储区域.
基类子对象可以具有零大小.
我不认为存储区域的大小为零.这意味着某些基类子对象实际上不是对象.这些陈述如何共存？
我正在编写一个编程语言编译器来集成 DSL 和 C/C++。为此，我出于几个原因决定使用 LLVM。
有一个主程序。在这个主程序中，我加载了由 clang 编译的位码文件。可加载的位码文件代表一个简短但完整的编程语言环境，包含 REPL、解析器、链接器和 AST。
到目前为止，我的理解是布尔数据类型在 IR 中表示为 i1。我已经使用 -O3 优化了我的代码，并得到了以下 IR 代码的布尔值（通过使用 llvm-dis 从生成的位码文件中反汇编）：
%"class.tl::contrib::toy::ToyREPL" = type <{ %"class.tl::contrib::toy::InitLanguage"*, i8, [7 x i8] }>
该类是 ToyREPL，它使用另一个类 InitLanguage。奇怪的是，布尔值似乎是由 i8 和 i8 数组呈现的。我实在不明白。
我已经定义了一个Makefile。首先我编译文件。然后我将它们链接到 bc 文件，然后优化并将其与其他一些库链接。
@cd $(BIN)/$(TARGET)/$(2); $(LINK) -o $(1).$(BITCODE_EXT) $(3)
@cd $(BIN)/$(TARGET)/$(2); $(OPT) -O3 $(1).$(BITCODE_EXT) -o $(1).$(OPT_NAME).$(BITCODE_EXT) $(OPTIMIZER_FLAGS)
@$(LINK) -o $(BIN)/$(TARGET)/$(2)/$(1).$(BITCODE_EXT) $(BIN)/$(TARGET)/$(2)/$(1).$(OPT_NAME).bc $(LINK_OPTION) $(4)
编译器标志是：
-v -g -emit-llvm -I$(BOOST_INC_DIR) -std=c++11 -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS
优化器标志是-std-link-opts
链接标志是-v.
ToyREPL 类的相关部分在这里：
class ToyREPL {
private:
InitLanguage …我在设计中需要一个4位 整数,以减少内存使用.在任何版本的c ++中,c ++ 11,c ++ 14都可以用于设计.