567表示合法的c语言长整型常量吗,如果前面加(long)呢?
1、[单选题]下列关于类、包和源文件的描述中,不正确的一项是( )。
2、[单选题]编译一个定义了3个类和10个办法的Java源文件后,会产生多少个字符码文件,扩展名是什么?( )
3、[单选题]下列哪一个语句是合法的?( )
4、[单选题]下列整型的最终静态属性i的定义中,正确的是( )。
一直在完善,从未停歇过,但有些题目可能仍然存在瑕疵,对您造成的不便我们深表歉意!
为方便我们排查错误,请您详细描述本题错误,例如:
简单来说,如果在int, long long之间再插入unsigned int,那么当我们写long long v = -时(注意-落在64位long long的合法范围内),会发现v的值其实是,这显然违背语义(想象一下如果我们写int
Po主关于oct和hex的答案是对的,但其余部分感觉有些问题(也许是我理解错了,请多多指教),我提一些(原谅我手头暂无C编译器,所以下面就先用C++来说明了):
Po主提到了“有符号数”和“无符号数”,这里有个误区:integer和integer literal不是一回事,所有的integer literal都是没有负号、正号这种东西的。
举个例子。因为decimal在C++11下已经不会被解释为unsigned了(和C99类似),所以这里就以hex为例。以下:
在int是32位,long long是64位的新编译器上的输出结果会是:
第四个输出结果,我没有打漏负号哦!为啥会出现这么不科学的结果啊?刚才说了,因为这诡异的integer literal恰好大于int,但又小于unsigned int,所以就被诡异地解释成unsigned int了,然后前面又加了个负号(oh shit)……注意上述6个值都落在long long范围内,这意味着当我们写long long v = xx时,即便xx落在long long范围内v的值也不一定是xx(卧槽标准委员会你赶紧把unsigned都给我扔掉!)……
在int是32位,long long是64位的新编译器上的输出结果会是:
你看不牵涉到unsigned的decimal的结果多科学呀(注:在VS2013上第二个结果会有问题,因为出于兼容性它沿用了C89;g++或clang++不开启C++11也会有问题)!
所以说嘛,C89在int, long之后补上unsigned long并不是个明智的做法。当然那时候没有long long,所以没啥问题。但这明显影响了扩展性啊对不。事实上,C99出来时有一篇paper吐槽过这个地方,具体名称我忘了,大概意思是这样的:
更糟糕的是,现在的标准不仅允许使用int, long和long long,还允许使用扩展类型:
上文来自C++11。要是现行标准用unsigned类型封顶,那在支持扩展类型的机器和不支持扩展类型的机器上就会出现完全不同的结果。
Po主对oct和hex的看法基本是正确的,oct和hex之所以要允许unsigned,是因为使用它们的人很可能假定它们是unsigned的,然后就能去搞位运算什么的,所以标准就留着unsigned。但对于常用的decimal,支持unsigned只是在纯添乱。
我对C/C++的认识只停留在大一水平,在大一学了这两门语言后我基本没再碰过它们,所以如果上面的看法完全错误,那也很正常(对此我只能请求各位看客的原谅,浪费你们的时间了)。还是请大牛
来检查下吧,求轻喷,谢谢!