标识符问题。 算法
一、不能用数字开头 spa
二、不能使用关键字 内存
不能使用关键字很明显是由于禁用,而数字是由于 字符串
若是某一种语言的编译器使用了自顶向下的语法分析,那么为了分析效率,产生式的正交性是必须保证的,那么,这种语言的编译器就不能有两种不一样的语法符合以相同类型的字符开头。 编译器
其实,不是全部语言的变量名,或者更准确的称之为标识符,都不能够以数字开头,在一门很古老的语言LISP中就是能够的。这个问题,@张正雄 同窗给出来了一个之前回答过的答案,可是那个回答中的答案是片面的。
====================================================
我一开始也认为是和歧义有关系,后来知道LISP是容许这样类型的变量的,而后就试图去推导,发现数字开头的标识符并不会产生影响,可以对编译产生影响的只有一种状况。因此,能不能使用数字开头的变量名,取决与分析方法。
我画了上面这个图,若是是自底向上的分析(LR)的话,标识符是否以数字开头,并不会增长算法的复杂度,按照这个状态图一路走过去,走到什么就是什么,数字和标识符彻底能够区分。也就是说,语法彻底能够定义以数字开头的标识符而不产生任何的歧义。
可是,若是采用自顶向下的分析(LL)的话,就不能够了。LL分析为了保证效率,进行无回溯的语法分析,有一个要求,就是对于某一个非终结符的全部产生式,他们的FIRST集必须正交,也就是,他们的开头的符号必须不相同。因此,若是某一种语言的编译器使用了自顶向下的语法分析,那么为了分析效率,产生式的正交性是必须保证的,那么,这种语言的编译器就不能有两种不一样的语法符合以相同类型的字符开头。早期的一些语言,甚至还有标识符的开头不能包含关键字(好比,dodoro可能会是一个非法的标识符,由于开头包含了关键字do)。
如今,咱们知道大部分语言的编译器是使用CLR或者LALR方法进行语法分析的,因此这种影响效率的问题是不存在的。可是,同@倪玉哲 所说的状况,C语言里面相似「2L」这样的长整型当即数的定义可能会产生歧义,是不使用数字开头的标识符的主要缘由。 编译
=============================================================== 效率
常量 变量
字符常量 要用单引号'' 语法
字符串常量用双引号" " 二进制
进制
八进制 0-7 以0开头
十六进制 0x开头,0-9 A-F
数值转换
十进制 728 = 7*10(2) +2*10(1) +8*10(0) =728
二进制转化为 10进制
1 0 1 0 1 1
32 16 8 4 2 1
记住每一个有效位置的数值 当非0的时候能够相加因此 101011 = 32+8+2+1 = 44。
二进制转化为八进制
101111 每三位转为十进制数
101 111
5 7
因此八进制是057
转化为十六进制
0010 1111
2 15
因此16进制是0x2F
一、八进制即每三位个二进制变成10进制,而后在前面加个0
二、十六进制既每四位变为10进制,而后在前面加0x
十进制变为二进制,除以2取余
二进制转化为十进制,乘以2的幂
把6不断除以2,而后从最小的余数拼成110。
负数的二进制取反加1。
以6为例
0000-0000 0000-0000 0000-0000 0000-0110 取反
1111-1111 1111-1111 1111-1111 1111-1001 加1
1111-1111 1111-1111 1111-1111 1111-1010 为-6
内存中1开头的为负数。
byte b = 3
b = b+200; //这个不能经过编译。200默认是int
而若是经过强制转换,会被截断b =(byte) (b+200) = -57