標識符問題。 算法
一、不能用數字開頭 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