為什么這樣子不報(bào)錯(cuò)，或者給一個(gè)什么警告也好？

L_kernel

1. #include <stdio.h>
   
2. 
   
3. struct scul_qset {
   
4.         int data;
   
5.         struct scul_qset* next;
   
6. };
   
7. 
   
8. int main()
   
9. {
   
10.         int scul_qset;
    
11.         struct scul_qset scul_qset_instance;
    
12.         return 0;
    
13. }

復(fù)制代碼

int scul_qset; /* 定義一個(gè)和結(jié)構(gòu)標(biāo)識(shí)符相同的變量 */

OwnWaterloo

1. 
   
2. void x(void)
   
3. {
   
4.       struct x { struct x* x; } x;
   
5. x:
   
6.       x.x = &x;
   
7. }
   

復(fù)制代碼

有一種…… "要是吐槽就輸了"的感覺(jué) >_<

nketc

所有這些不在一個(gè)概念域中�；蛘哒f(shuō)不在一個(gè)名字空間中。從編譯器的實(shí)現(xiàn)上說(shuō)他們分屬于不同的符號(hào)表。

OW吐槽啊，俺就稀飯看你吐槽。

OwnWaterloo

回復(fù) 3# nketc

C語(yǔ)言已經(jīng)是這樣子了……  吐也沒(méi)用……

struct x x; 這種代碼倒是經(jīng)常在一些老的書(shū)籍或代碼里看見(jiàn)……  這也就算了……
還不如去吐槽那些盡可能"利用"名字空間將人搞暈的代碼……

nketc

有時(shí)候名字不好起啊。寫(xiě)代碼有不少時(shí)間都花在怎樣給函數(shù)，變量，類型命名上了。nnd有時(shí)候?qū)憸y(cè)試代碼的時(shí)候，直接xxx1，xxx2就上了。

davelv

回復(fù) 5# nketc

同，還有寫(xiě)注釋也花了一些時(shí)間。
但是要論起來(lái)化在設(shè)計(jì)/調(diào)整設(shè)計(jì)上的時(shí)間還是最多的。

OwnWaterloo

回復(fù) 5# nketc

>> 有時(shí)候名字不好起啊。寫(xiě)代碼有不少時(shí)間都花在怎樣給函數(shù)，變量，類型命名上了。
同感……


>> nnd有時(shí)候?qū)憸y(cè)試代碼的時(shí)候，直接xxx1，xxx2就上了。
我有時(shí)候會(huì)出現(xiàn)這種狀況……

1. 
   
2. {
   
3. // ...
   
4.       {
   
5.       // ...
   
6.             {
   
7.             // ...
   
8. 
   
9. // 層次太深
   
10. // 于是這里干脆從頂重新開(kāi)始……
    
11. {
    
12. // ...
    

復(fù)制代碼

估計(jì)會(huì)被很多衛(wèi)道士反對(duì)……
管他呢…… 測(cè)試代碼而已……

nketc

俺沒(méi)寫(xiě)過(guò)啥復(fù)雜的算法，注釋一般比較簡(jiǎn)略。好的命名和排版啥的本身就是注釋
當(dāng)然寫(xiě)算法就另當(dāng)別論了。

ps-----------
1）看別人代碼犯困
2）寫(xiě)代碼精神
3）查bug，帶勁。

OwnWaterloo

回復(fù) 1# L_kernel

無(wú)論是好是壞…… C語(yǔ)言已經(jīng)成這個(gè)樣子了……
趁著首頁(yè)還在， 還是正經(jīng)回復(fù)一下吧……


同一個(gè)名字/標(biāo)識(shí)符，可以指代不同的東西 —— 無(wú)論是否應(yīng)該這樣編寫(xiě)代碼 —— 這個(gè)應(yīng)該是蠻常見(jiàn)的。比如：

1. 
   
2. void f(void)
   
3. {
   
4.                           /* ^ */     /* ^ */
   
5.       int x,y;            /* | */     /* | */
   
6.                           /* A */     /*   */
   
7.                           /* | */     /*   */
   
8.                           /* v */     /*   */
   
9. 
   
10.       {                   /* ^ */     /*   */
    
11.             double x,z;   /* | */     /*   */
    
12.                           /* B */     /* C */
    
13.                           /* | */     /*   */
    
14.       }                   /* v */     /*   */
    
15. 
    
16.                           /* ^ */     /*   */
    
17.                           /* | */     /*   */
    
18.                           /* A */     /*   */
    
19.                           /* | */     /* | */
    
20.                           /* v */     /* v */
    
21. }
    

復(fù)制代碼

在C范圍內(nèi)， y 指代那個(gè) int 變量。
在（兩個(gè)）A范圍內(nèi)， x 指代那個(gè) int 變量
而中間的B范圍內(nèi)， x 指代那個(gè)double變量。 z指代另一個(gè)double變量。

這是通過(guò)名字出現(xiàn)的位置決定名字指代物。


而 struct x x; 是另一種情況。
是通過(guò)名字的種類/作用決定名字的指代物。

1. 
   
2. struct    /* 有了 struct "前綴" 后續(xù)的 */
   
3.        x  /* 就是指一個(gè) tag 而不是別的東西 */
   
4.           /* 之后的 */
   
5.        x  /* 就是一個(gè)普通標(biāo)識(shí)符 */
   
6.        ;  /* 兩者不會(huì)沖突 */
   
7. 
   
8. x :       /* x 指 label 同樣不會(huì)沖突 */
   

復(fù)制代碼

PS：
對(duì) lable 是函數(shù)作用域而不是塊作用域感到驚訝的同學(xué)，可以問(wèn)問(wèn)使用js的同學(xué)是什么感受……
對(duì) C語(yǔ)言區(qū)分ordinary/member/tag/label 感到驚訝的同學(xué)，可以參考lisp-1與lisp-2之間爭(zhēng)論。

L_kernel

回復(fù)  L_kernel

無(wú)論是好是壞…… C語(yǔ)言已經(jīng)成這個(gè)樣子了……
趁著首頁(yè)還在， 還是正經(jīng)回復(fù)一下吧…… ...
OwnWaterloo 發(fā)表于 2011-10-30 01:14

感謝回復(fù)。說(shuō)得這么多。困擾我的正是這種
struct x x {};的情況。名字空間這個(gè)倒不是我發(fā)帖子的目的，不好意思，帖的代碼很爛。