【问题标题】:C4838 warning with array initialization of a const char* arrayC4838 警告与 const char* 数组的数组初始化
【发布时间】:2017-08-11 19:26:47
【问题描述】:

对于一个项目,我将着色器编译为二进制数据,然后将它们转换为头文件,该文件将着色器的字节码声明为 const char 数组。

但是,在编译过程中,我收到以下警告:

"从intconst char 的转换需要缩小范围 转换”。

现在我通常知道为什么会发生这种情况,这是因为编译器认为这些值是 int 类型,而实际上它们被声明为 char 类型。

const char base_ps[]={
0x44,0x58,0x42,0x43,0x12 ... etc

将鼠标悬停在这些值上时IntelliSense 还指出这些值被转换为int。例如,对于索引0 处的值,它会列出(int)0x44

有什么解决办法吗?显然,我可以明确地将 (char) 放在每个值之前的任何位置,但是我必须在着色器生成中添加一个额外的步骤来解析头文件。

我也不想抑制警告,但我希望将警告视为错误。对此有何建议?

【问题讨论】:

  • 如果你使用类似const char foo[] = "\x44\x58\x42\x43";的东西,你还会收到警告吗?
  • 另外,'\x44', '\x58', '\x42', '\x43', '\x12'...
  • 嗯,这很奇怪。这可能是警告级别吗?我正在使用 CMake 生成我的项目,但我不确定默认警告级别是什么。在这里它不起作用; rextester.com/IIE43940可能是这样声明的?
  • 另外@NathanOliver 我没有收到警告。就当声明为 0x..

标签: c++ arrays char constants warnings


【解决方案1】:

您可以使用character literal 代替integer literal 来抑制警告。对于字符文字,您可以使用\xNN 形式的escape sequence 来表示由十六进制值定义的字符。看起来像

const char foo[] = "\x44\x58\x42\x43";

const char foo[] = {'\x44', '\x58', '\x42', '\x43'};

它们之间的区别在于,由于第一个是 c 字符串,它会在末尾添加一个空终止符。如果你不想这样,那么你需要使用第二种方法。

【讨论】:

  • 这清楚地说明了为什么它假定它是一个整数。我还不如编写一个解析标题并将所有条目更改为提供的字符文字格式的后期生成步骤。感谢您的帮助!
  • @user3001604 没问题。很高兴能提供帮助。
  • @user3001604 您可能要考虑接受安迪的回答,因为它有您收到警告的真正原因。
  • 再一次,为什么将所有内容都变成字符文字?
  • @user3001604 它默默地禁用它。如果您给它一个大于可表示范围的十六进制值,则允许编译器做任何您想做的事情:[...]八进制或十六进制数字的序列由第一个不是八进制的字符终止数字或十六进制数字,分别。如果字符文字的值超出为 [...] 定义的实现定义范围,则它的值是实现定义的
【解决方案2】:

问题是因为您实际上使用的十六进制值太大而无法存储在 char 中(通常是有符号的,长度为 8 位)。所以最大的正值是 127,或者0x7F。您提供的 like you show here 值包括超过 127 的值,因此您会收到正确的缩小转换警告。

要么使用unsigned char 而不是char,要么使用更小的数字(不大于0x7F)like here

const char deferred_ps[]={
    0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 
    0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
    0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f,
    0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f,
    0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f,
    0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 0x5a, 0x5b, 0x5c, 0x5d, 0x5e, 0x5f,
    0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
    0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7a, 0x7b, 0x7c, 0x7d, 0x7e, 0x7f
};

请注意,如果忽略缩小转换警告,则结果是实现定义的,是不可移植的。

【讨论】:

  • 为什么会有有符号整数溢出?这是 int 和 char 之间的转换,这是 AFAIK 定义的实现。
  • @ftfish:当编译器警告您缩小转换时,这意味着您从一个较大的类型(以位为单位)转换为一个以位为单位的较小的类型。确实,char 是否签名是实现定义的。许多实现选择对其进行签名。因此存在有符号整数溢出的风险。
  • 我知道有一个从 int 到 char 的转换。但是,如果目标是无符号的,或者目标可以保存源值和实现定义,则此转换是明确定义的,否则是未定义的。如需参考,请参阅here。 Quote: 如果目标类型是有符号的,如果源整数可以在目标类型中表示,则值不会改变。否则结果是实现定义的。 (请注意,这与未定义的有符号整数算术溢出不同)。
  • @ftfish:你说得对,标准说的是实现定义的。我已经更新了我的答案。
猜你喜欢
  • 2011-04-18
  • 1970-01-01
  • 1970-01-01
  • 2016-11-21
  • 1970-01-01
  • 2014-08-15
  • 2020-05-12
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多