大濕 Lippman 也犯錯(cuò)？

sonicling

回復(fù) 11# Sevk


    區(qū)別肯定是有的，共性肯定也是有的。就看怎么去看了。

OwnWaterloo

回復(fù) 7# bruceteen

嗯，看到int (*pf)時(shí)無(wú)法確定。
甚至對(duì)int (*pf)( ... )，如果不確定其中的內(nèi)容，依然無(wú)法確定pf是：
1. 函數(shù)指針，返回int， ... 是該函數(shù)的形式參數(shù)
2. 指針，類型int*， ...是構(gòu)造函數(shù)的實(shí)際參數(shù)



直到確定 ... 的內(nèi)容了， 比如：
i) 0
那只能解釋為指針。

ii) 1024 —— 原始例子
也只能解釋為指針。然后1024這一非0整數(shù)常量初始化指針再報(bào)告一個(gè)錯(cuò)誤。

iii) 空 —— 原始后續(xù)例子
可以解釋為兩者：
a) 函數(shù)指針，形式參數(shù)列表為空
b) 指針，實(shí)際參數(shù)列表為空
于是meta-rule決定是a) 而不是b)。 （假設(shè)如果meta-rule決定是b)，那編譯會(huì)成功的，同i)，都是一個(gè)空int指針。）

iv) 前面3個(gè)例子確實(shí)是用腳丫子能想出來(lái)的
更奇葩的例子，人肉分析很容易中招的，也就是Eff STL里面提到的那種類型：

1. 
   
2. typedef int* pint; // 為了可讀性（或者說(shuō)迷惑性）取個(gè)名字
   
3. int (*p0)(pint()); // 可以解釋為用 pint() 產(chǎn)生的臨時(shí)對(duì)象（空指針）作為 p0 這個(gè)int*變量的構(gòu)造函數(shù)的實(shí)際參數(shù)
   
4. 
   
5. int* q = ...;
   
6. int (*p1)(pint(q)); // 可以解釋為用 pint(q) 產(chǎn)生的臨時(shí)對(duì)象（與q相同的指針）作為p1這個(gè)int*變量的構(gòu)造函數(shù)的實(shí)際參數(shù)
   

復(fù)制代碼

但同時(shí)，p0與p1都可以解釋為函數(shù)指針…… 關(guān)鍵點(diǎn)是：

1. 
   
2. void f0(pint f()) {} // 通常寫法
   
3. void f1(pint  ()) {} // 省略參數(shù)名，依然可以，這還不算太意外
   
4. 
   
5. void g0(pint  x ) {} // 通常的寫法
   
6. void g1(pint (x)) {} // 多加一對(duì)括號(hào)，依然可以，囧死
   

復(fù)制代碼

所以p0又可以解釋為函數(shù)指針，返回類型int，形式參數(shù)是一個(gè)省略名字的函數(shù)指針，該函數(shù)指針不接受參數(shù)并返回pint。
而p1可以解釋為函數(shù)指針，返回類型int，形式參數(shù)名是q類型是pint。

最終根據(jù)meta-rule，p0,p1是指針變量（后面的括號(hào)是構(gòu)造函數(shù)的實(shí)際參數(shù)列表）被排除；p0,p1都是函數(shù)指針，后面的括號(hào)都是形式參數(shù)列表。

sonicling

回復(fù) 6# OwnWaterloo


    看了一下Efficient STL里面所說(shuō)的Most Vexing Parse。我覺得他的例子沒(méi)解釋清楚。

list<int> data(istream_iterator<int>(dataFile), // warning! this doesn't do
istream_iterator<int>()); // what you think it does

他是說(shuō)這個(gè)是聲明了一個(gè)函數(shù)，輸入一對(duì)istream_iterator作為參數(shù)，其中前面那個(gè)有名字，后面沒(méi)名字，并返回list。

istream_iterator<int>(dataFile) 可以看作是參數(shù)聲明，而不是當(dāng)作postfix-expression，沒(méi)問(wèn)題，因?yàn)檫@種形式本來(lái)就具有二義性，怎么解釋都不算錯(cuò)。

istream_iterator<int>() 是啥？是省略了參數(shù)名的 istream_iterator<int> 參數(shù)嗎？錯(cuò)！是返回istream_iterator<int>，參數(shù)為空的函數(shù)類型。

parameter-declaration:
    decl-specifier-seq declarator
    decl-specifier-seq declarator = assignment-expression
    decl-specifier-seq abstract-declaratoropt      <-------------- 重點(diǎn)看這一行
    decl-specifier-seq abstract-declaratoropt = assignment-expression

未命名的parameter，形式上只能是decl-specifier-seq （abstract-declarator部分被省去），后面不帶括號(hào)。
如果有括號(hào)，括號(hào)部分應(yīng)該是abstract-declarator

abstract-declarator:
    ptr-operator abstract-declaratoropt
    direct-abstract-declarator
direct-abstract-declarator:
    direct-abstract-declaratoropt ( parameter-declaration-clause ) cv-qualifier-seqopt exception-specificationopt
    direct-abstract-declaratoropt [ constant-expressionopt ]
    ( abstract-declarator )

如果要把空括號(hào)看作是abstract-declarator的話，括號(hào)部分應(yīng)該是  ( parameter-declaration-clause ) ，其中 parameter-declaration-clause 可以接受空，那意義就不僅僅是參數(shù)名被省略，他是一個(gè)沒(méi)有名字的函數(shù)原型聲明！但是函數(shù)原型可以做參數(shù)類型嗎？我沒(méi)試過(guò)，感覺會(huì)有問(wèn)題。


我說(shuō)這些是為了說(shuō)明C++的語(yǔ)法的確是非常復(fù)雜。Lippman 說(shuō)的沒(méi)錯(cuò)，C++的語(yǔ)法解析對(duì)編譯器來(lái)說(shuō)負(fù)擔(dān)巨大。

int abcd(); // 函數(shù)聲明 abcd: {} -> int
int abcd(double); // 函數(shù)聲明 abcd: double -> int
int abcd(double ()); // 函數(shù)聲明 abcd: double (*)() -> int 姑且把函數(shù)原型當(dāng)作函數(shù)指針
int (*abcd)(double()); // 函數(shù)指針聲明 abcd : pointer to (double (*)() -> int)  姑且把函數(shù)原型當(dāng)作函數(shù)指針
int (*abcd)(double(0)); // 指針聲明并初始化 int *abcd = double(0) 有類型轉(zhuǎn)換問(wèn)題
int (*abcd)(double(*)); // 函數(shù)指針聲明 abcd: pointer to (double * -> int)

sonicling

GCC、CLang的語(yǔ)法分析器都是手工寫的遞歸下降分析，對(duì)不同語(yǔ)法成分的分析分散在不同函數(shù)里面�，F(xiàn)在的問(wèn)題是只要輸入序列有輕微差別，整個(gè)序列的意義可能發(fā)生根本性改變。對(duì)編譯器實(shí)現(xiàn)是巨大挑戰(zhàn)。

sonicling

那得把所有函數(shù)名當(dāng)作函數(shù)指針變量來(lái)處理，而不能是隱式轉(zhuǎn)換為函數(shù)指針。