青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

sherrylso

C++博客 首頁 新隨筆 聯系 聚合 管理
  18 Posts :: 0 Stories :: 124 Comments :: 0 Trackbacks

        C++之父Bjarne stroustrup曾經說過:不需要了解所有的c++細節,也能夠寫出好的c++程序;不應該注重語言方面的特征,而應該注重軟件設計技術本身。很顯然,我的這篇文章,與這兩句話背道而馳:).的確,我們程序員,不應該把精力放在c++本身語言的特征上,而是應該思考軟件設計技術本身。那么,在我們需要提高對c++理解的同時,是不是我們從下面幾個方面為著眼點
1) 從編譯原理的角度
2) 從技術需求的角度
3) 從軟件設計技術的角度
從以上的幾個角度,來重新審視c++一些晦澀語法,或許,我們能從中獲益。在這里,我要說的是,我們不單單是要記住這些c++語言特性怎么樣的使用,而是應該知道這些語言特性背后隱藏的故事,以便于我們更深層次地理解c++,理解軟件設計。
一、子類通過函數名字隱藏父類函數。
如下例:

class Base
{
public:
 virtual 
void f(int x);
}
;
class Derived: public Base
{
public:
 virtual 
void f(double* pd);
}
;
int main()
{
  Derived
* pd = new Derived();
  pd
->f(10); //compile error!!!
}

         當我們編譯pd->f(10)操作時,編譯器報錯。按照我們常規的理解是:父類的函數void f(int x)與子類的函數void f(double*pd),由于參數類型不同,其函數簽名也是不一樣的,按照這樣的邏輯,在這個類繼承體系中,這兩個函數完全應該是互不隱藏的,我們完全可以認為是符合overloaded規則的兩個函數。
        但是,在c++里,子類通過函數名字隱藏父類函數,而不是通過函數簽名!c++給出的解釋也是合理的:試想一種情況:你使用了別人寫的類庫,繼承其中的某個類,寫了你自己的子類。
如上面的例子,你的子類就是Derived,而類庫中的父類就是Base.當你根本不知道在父類中還有這樣一個f(int x)函數時,在調用子類Derived的f函數時,你犯了錯誤,參數類型傳成了int類型(或者不是你犯的錯誤,編譯器幫你自動轉化為int類型),結果是:程序可以正常運行,但是,執行的結果卻不是你所期望的,是f(int x)調用,而不是你自己的實現:f(double* pd)調用!
         這就是c++為什么通過函數名字隱藏父類函數的原因。
        說到這里,我們需要補充幾句:雖然c++在語言層面上給我們提供了這樣的保證,但是,子類hide父類的函數,這是一個非常不好的設計。從OO的角度出發,應該講求的是Liskov Substitution Principle。即:suntypes must be substitutable fro their base types.很顯然,當hide行為發生時,從接口的角度來講,子類與父類是不能互為替代的。父類的protected or public的方法,應該很自然地由其所有子類所繼承,而不是被隱藏。隱藏行為的發生,相當于在這套繼承體系中開的一個后門。很顯然,C++幫助我們自動隱藏了父類的方法,但是,作為程序開發的我們,應該意識到這一點,也應該避免這樣的設計。
二、c++的per-class allocator語法規則
          在D&E of C++一書中,Stroustrup給出了幾點c++提供per-class allocator的理由,這些理由也是我們使用class level的allocator的原因,所以,有必要我們總結一下:
第一、許多程序應用,需要在運行的過程中,大量地Create和Delete對象。這些對象,諸如:tree nodes,linked list nodes,messages等等。如果在傳統的heap完成這些對象的創建,銷毀,由于大量的內存申請,釋放,勢必會造成內存碎片。這種情況下,我們需要對內存分配進行細粒度的控制。
第二、一些應用需要長時間跑在內存受限的裝置上,這也需要我們對內存分配進行細粒度的控制,而不是無限制地分配,釋放。
主要基于以上的兩點,c++提供了per-class allocator語言支持。
如下例:

class X
{
public:
  
void* operator new(size_t sz); //allocate sz bytes
  void  operator delete(void* p) //free p;
}
;

      new操作符函數負責對象X的內存分配。對這樣一個語法規則,我們好奇的是,為什么聲明了一個我們從來都不使用的參數size_t sz.我們的使用語法如下: X* px = new X;
C++也給出了解釋:per-class allocator機制將適用整個類的繼承體系。例如:

class Y: public X //ojects of class Y are also allocated using X::operator new
{
  
//
  
// 
}
;

        對于子類Y,其內存分配函數也是X::operator new()。但是,在這里,內存分配的大小,不應該是sizeof(X),而是sizeof(Y).問題的關鍵在這里:C++通過提供多余的參數size_t sz,而給開發者提供了更大的靈活性,也即:per-class allocator是面向類的繼承體系的內存管理機制,而不單單是面向單個類。
三、Koenig Lookup機制。
        大家對Andrew Koenig應該很熟悉,c++大牛,是AT&T公司Shannon實驗室大規模編程研究部門中的成員,同時他也是C++標準委員會的項目編輯。他擁有超過30年的編程經驗,其中有15年的C++使用經驗。
        Koenig Lookup,就是以Andrew Koenig命名的查找規則。在看這個定義之前,我們先弄清楚函數所在的域的分類,一般來講,分為:
1:類域(函數作為某個類的成員函數(靜態或非靜態))
2:名字空間域
3:全局域(即C++默認的namespace)
        而Koenig Lookup機制,就是當編譯器對無限定域的函數調用進行名字查找時,除了當前名字空間域以外,也會把函數參數類型所處的名字空間加入查找的范圍。
如下例:

#include <iostream>
using namespace std;
namespace Koenig
{
    
class MyArg
    
{
    
public:
         ostream
& print(ostream& out) const
         
{
            out
<<"this is MyArg."<<endl;
         }

    }
;
 
    inline ostream
& operator<<(ostream& out, const MyArg& myArg)
    
{
         
return myArg.print(out);
    }

}

 
int main()
{
    Koenig::MyArg myArg;
    cout
<<myArg;
    
return 0;
}

       如上的代碼,使用operator<<操作符函數,打印對象的狀態,但是函數ostream& operator<<(ostream& out, const MyArg& myArg) 的定義域是處于名字空間Koenig中,為什么編譯器在解析main函數(全局域)里面的operator<<調用時,它能夠正確定位到Koenig名字空間里面的operator<<?這是因為根據Koenig查找規則,編譯器需要把參數類型MyArg所在的名字空間Koenig也加入對ostream& operator<<(ostream& out, const MyArg& myArg) 調用的名字查找范圍中。
       
如果沒有Koenig查找規則,我們就無法直接寫cout<<myArg;,而是需要寫類似Koenig::operator<<(std::cout, myArg); 這樣的代碼(使用完全限定名)。這樣的結果是,即不直觀也不方便。

        其實在C++里,提供了很多類似于Koenig查找規則的機制,以保證程序語法上的簡潔,明了。例如:許多的操作符函數,COPY構造函數。而這些,也是我們寫出專業的C++程序的基本。
未完待續:)

 

 


 

posted on 2007-11-11 14:56 愛上龍卷風 閱讀(4679) 評論(26)  編輯 收藏 引用

Feedback

# re: c++晦澀語法背后的故事(一) 2007-11-11 15:16 lovedday
關于

class Base
{
public:
virtual void f(int x);
};
class Derived: public Base
{
public:
virtual void f(double* pd);
};
int main()
{
Derived* pd = new Derived();
pd->f(10); //compile error!!!
}

很顯然編譯報錯是對的,因為函數原型不一樣,所以不構成overwrite。

既然不構成overwrite,那么你調用的就是Derived中的f函數,編譯器檢查后發現沒有匹配的函數,當然報錯。

至于后面的解釋個人認為不著調。  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-11 15:25 <a href=http://minidx.com>minidxer</a>
同意lovedday的觀點  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-11 15:25 lovedday
#include <iostream>
using namespace std;
namespace Koenig
{
class MyArg
{
public:
ostream& print(ostream& out) const
{
out<<"this is MyArg."<<endl;
}
};

inline ostream& operator<<(ostream& out, const MyArg& myArg)
{
return myArg.print(out);
}
}

int main()
{
Koenig::MyArg myArg;
cout<<myArg;
return 0;
}

這種代碼基本上屬于濫用運算符重載,實際上C++的不少機制都會導致被濫用,結果就是產生晦澀難懂且充滿bug的垃圾代碼,當然這種代碼做為反面教材還是不錯的,但若是在項目中使用這種代碼,那將是惡夢。
  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-11 15:29 lovedday
個人認為盡量少重載運算符,比如printf就比<<好用,實在沒有什么必要去重載<<,使用函數更好。  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-11 15:34 lovedday
ps,說這些沒別的意思,只是說在實際項目中不應該這么使用運算符重載,當然sherrylso只是為了說明C++語法而編寫這些代碼。  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-11 15:37 lovedday
C++里還有函數重載和參數默認值,實際上這兩個機制是滋生bug的溫床,如果配合多態,將會導致十分難以理解的行為,所以別用函數重載和參數默認值。

看看這個例子,絕對讓你抓狂,猜猜看輸出的i和j值是多少?

#include <stdio.h>

class PARENT
{
public:
virtual int doIt( int v, int av = 10 )
{
return v * v;
}
};

class CHILD : public PARENT
{
public:
int doIt( int v, int av = 20 )
{
return v * av;
}
};

int main()
{
PARENT *p = new CHILD();

int i = p->doIt(3);
printf("i = %d\n", i);

CHILD* q = new CHILD();

int j = q->doIt(3);
printf("j = %d\n", j);

return 0;
}  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-11 16:20 foobar
@lovedday
class Base
{
public:virtual void f(int x);
};
class Derived: public Base
{
public:virtual void f(double* pd);
};
int main()
{
Derived* pd = new Derived();
pd->f(10); //compile error!!!
}

這個例子只有聲明沒有定義,編譯肯定有錯
但是
在c++里,子類通過函數名字隱藏父類函數,而不是通過函數簽名!

這個分析應該沒什么問題
子類確實通過函數名字隱藏了父類的函數
  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-11 16:38 lovedday
在c++里,子類通過函數名字隱藏父類函數,而不是通過函數簽名!

這個分析應該沒什么問題
子類確實通過函數名字隱藏了父類的函數

-------------------------------------------------------

你的這個論斷顯然是錯的。

#include <stdio.h>

class Base
{
public:
virtual void f(int x)
{
printf("call base f function\n");
}
};

class Derived: public Base
{
public:
virtual void f(double pd)
{
printf("call derived f function\n");
}
};

int main()
{
Base* pb = new Derived;
pb->f(10.5);

return 0;
}

輸出:

call base f function  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-11 16:47 foobar
@lovedday
pb是個父類指針,所以調用父類的f

Derived* pb = new Derived;
pb->f(10);
  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-11 17:00 lovedday
@foobar

很懷疑你是不是C++沒學好。  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-11 17:05 lovedday
#include <stdio.h>

class Base
{
public:
virtual void f(int x)
{
printf("call base f function\n");
}
};

class Derived: public Base
{
public:
virtual void f(double pd)
{
printf("call derived f function\n");
}
};

int main()
{
Base* pb = new Derived;
pb->f(10.5);

return 0;
}

輸出:

call base f function

你說只要函數名稱相同子類就可以覆蓋父類函數的行為,但很顯然,這個例子說明了僅函數名稱相同是無法覆蓋的。如果你沒看懂,是不是說明還沒把多態搞清楚?  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-11 17:07 foobar
@lovedday
上面說的不夠確切
你c++學的好,知道多態這個概念,但是c++有很多缺點
樓主的那個例子,你在理解上是有誤的
子類的確實用函數簽名hide了父類的函數
所以你調用f的時候,肯定調用了f(double)

但是用dynamic type的時候,情況就不是這樣了

nt main()
{
Base* pb = new Derived;
pb->f(10.5);

return 0;
}

輸出當然是base
但是絕對不是子類有個函數輸出base
而確實調用了父類的函數

  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-11 17:10 foobar
@lovedday
多態是c++的一個特性 但是 c++遠比這個復雜
你看看下面的代碼,希望能明白我的意思

#include <iostream>
class Base
{
public:
virtual void foo() { std::cout << "Base::foo\n"; }
void foo(int) { std::cout << "Base::foo(int)\n"; }
};

class Derived : public Base
{
public:
void foo() { std::cout << "Derived::foo\n"; }
};

int main()
{
Base b;
b.foo(); // Base's foo() is called
b.foo(3); // Base's foo(int) is called
Derived d;
d.foo(); // Derived's foo() is called. The one in Base is hidden
d.foo(3); // error, that function is also hidden
Base &ref = d;
ref.foo(); // Derived's foo() is called. It overrides the Base version
ref.foo(3); // Base's foo(int) is called
}  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-11 17:45 lovedday
@foobar

謝謝,我明白了作者的意思,但實際上正如文章所指出的那樣,這是一個糟糕的設計,實際上這些都導致了含混不清的語義和容易出錯的代碼,所以我說不要去重載函數。

C++的復雜很大一部分原因是因為其糟糕的設計。  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-12 12:50 pzy
我想可以這么總結:
派生類中的函數會override基類中與它具有相同簽名的虛函數,同時會hide基類中所有與它具有相同名稱(而非簽名)的非虛函數。無論如何,派生類函數不會overload基類函數。

lovedday提供的那個例子(參數默認值)的結果實在是匪夷所思,仿佛此時參數默認值也是簽名的一部分。誰能解釋一下啊?  回復  更多評論
  

# re: c++晦澀語法背后的故事(一)[未登錄] 2007-11-14 00:43 romangol
@pzy
下面是對應函數調用的反匯編代碼中重要的幾行
int i = p->doIt(3);
0040133B MOV DWORD PTR SS:[ESP+8],0A ;壓入默認參數10
00401343 MOV DWORD PTR SS:[ESP+4],3 ;壓入調用參數3
0040134E MOV DWORD PTR SS:[ESP],EAX
00401351 MOV EAX,DWORD PTR DS:[EDX]
00401353 CALL EAX

int j = q->doIt(3);
00401389 MOV DWORD PTR SS:[ESP+8],14 ;壓入默認參數20
00401391 MOV DWORD PTR SS:[ESP+4],3 ;壓入調用參數3
00401399 MOV EAX,DWORD PTR SS:[EBP-10]
0040139C MOV DWORD PTR SS:[ESP],EAX
0040139F MOV EAX,DWORD PTR DS:[EDX]
004013A1 CALL EAX

注意到兩個默認參數是在編譯時就已經寫死了,也就是說編譯器在編譯器就為兩個doIt調用分別決議了默認參數,然而在運行期它們卻是通過動態的方式
Call EAX
來運行,實際上在調試中也可以看到它們調用的都是子類的doIt函數(調用地址是相同的)。

我個人的理解是,虛函數的調用是通過虛函數表來完成的,故父類指針可以調用子類的函數,然而默認參數作為對象內存模型的一部分,是分別屬于不同的對象的,故編譯器為父類指針的函數調用還是賦予了父類對象的參數值。

請高手們指教  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-14 00:45 march rabbit
贊~  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-15 22:11 愛上龍卷風
@foobar
非常感謝foobar對本文詳盡的解釋。  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-15 23:00 foobar
@愛上龍卷風

不要感謝foobar,還是感謝google和c++編程思想吧。。。  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-11-16 12:30 pzy
@romangol

哈哈~我不太懂匯編,但應該明白你的意思了:lovedday的例子中,PARENT指針和CHILD指針調用的都是CHILD::doIt(),只不過在調用之前(編譯階段),編譯器已經它們填上默認參數值了,分別是10和20。

也就是說虛函數調用有多態性,而默認參數是靜態的,不存在運行時決策(如你所說,默認參數是在編譯時就已經寫死了)。

這個例子是有意設計成讓PARANT::doIt()與CHILD::doIt()的函數體相同,才有迷惑人的效果。

PS. 由此我進一步理解了C#為什么不支持默認參數值,也不鼓勵在庫中使用公開常量。默認參數值與常量都是在編譯后就“死”的,這個事實的后果是,修改庫后,用戶代碼需要重編譯。  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2007-12-27 22:06 秦歌
頂一下!  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2008-01-07 22:42 abettor.org
大家分析的都很好,學習了!  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2008-07-03 14:12 md6600
C++代碼本來就很明了精簡。 只不過 人比較懶惰,所以越來越簡。就會這樣咯。 寫句注釋嘛 有多難呢111  回復  更多評論
  

# What a joy to find such clear thinikng. Thanks for posting! 2011-05-26 10:20 Mateen
What a joy to find such clear thinikng. Thanks for posting!  回復  更多評論
  

# re: c++晦澀語法背后的故事(一) 2013-02-27 11:10 bluemei
用重寫來彌補一下:
class Base
{
public:
virtual void f(){
TRACE("Base f()\n");
}
virtual void f(int i){
TRACE("Base f(int)\n");
}
};
class Child : public Base
{
public:
virtual void f(){
TRACE("Child f()\n");
}
virtual void f(int i){
__super::f(i);
}
};

Child *p=new Child();
p->f();
p->f(10);  回復  更多評論
  

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            亚洲高清精品中出| 亚洲亚洲精品三区日韩精品在线视频| 亚洲一区中文| 亚洲宅男天堂在线观看无病毒| 欧美色另类天堂2015| 亚洲免费在线| 久久国产夜色精品鲁鲁99| 精品成人乱色一区二区| 亚洲风情在线资源站| 欧美二区视频| 欧美一级在线视频| 久久中文久久字幕| 亚洲伊人一本大道中文字幕| 亚洲欧美日韩精品久久亚洲区| 极品日韩久久| 日韩视频免费看| 国产一二三精品| 亚洲黄一区二区| 国产一级久久| 亚洲毛片播放| 经典三级久久| 亚洲深爱激情| 亚洲经典视频在线观看| 亚洲无吗在线| 国产免费成人av| 欧美成人久久| 国产精品男人爽免费视频1| 久久一二三区| 国产精品视频导航| 国内精品久久久久久影视8 | 欧美啪啪一区| 久久免费视频一区| 国产精品v欧美精品v日本精品动漫| 久久久久久久国产| 欧美午夜不卡在线观看免费| 久热re这里精品视频在线6| 欧美日韩在线播放三区四区| 欧美成人亚洲成人日韩成人| 国产精品免费小视频| 亚洲欧洲一区二区三区| 亚洲一级黄色| 噜噜噜在线观看免费视频日韩| 欧美电影免费| 免费亚洲一区| 国产自产在线视频一区| 一区二区三区四区蜜桃| 亚洲三级毛片| 欧美v日韩v国产v| 免播放器亚洲| 伊人久久大香线蕉综合热线| 欧美亚洲视频一区二区| 亚洲女人小视频在线观看| 欧美绝品在线观看成人午夜影视| 欧美激情性爽国产精品17p| 激情综合中文娱乐网| 久久精品国产999大香线蕉| 久久高清福利视频| 国产亚洲人成a一在线v站 | 亚洲高清在线视频| 在线看片日韩| 麻豆成人综合网| 欧美v国产在线一区二区三区| 狠狠色香婷婷久久亚洲精品| 欧美一区国产在线| 久久天堂国产精品| 在线观看亚洲一区| 裸体丰满少妇做受久久99精品| 麻豆精品精品国产自在97香蕉| 激情欧美一区| 六十路精品视频| 亚洲黄色视屏| 亚洲一级电影| 国产一区久久| 美日韩精品免费观看视频| 亚洲国产高清高潮精品美女| 亚洲精品字幕| 国产精品天美传媒入口| 欧美中文字幕精品| 亚洲大片在线观看| 亚洲一区精品电影| 国产日韩欧美在线| 麻豆精品视频在线| 99re66热这里只有精品3直播| 亚洲欧美成人精品| 激情欧美国产欧美| 欧美激情一区二区三区高清视频| 妖精成人www高清在线观看| 欧美在线观看视频一区二区三区| 极品尤物av久久免费看| 欧美成人一区二区| 亚洲男人的天堂在线观看| 免费欧美日韩| 亚洲免费人成在线视频观看| 国产在线高清精品| 欧美成人午夜| 午夜在线成人av| 亚洲国产精品一区在线观看不卡| 亚洲一区二区三区色| 在线精品一区二区| 国产精品xxxxx| 蜜桃久久av一区| 亚洲一区在线观看视频| 亚洲国产婷婷香蕉久久久久久99 | 亚洲精选中文字幕| 日韩视频精品在线| 最新国产成人av网站网址麻豆| 在线亚洲自拍| 亚洲九九九在线观看| 99精品国产在热久久| 亚洲精品影院| 西瓜成人精品人成网站| 亚洲人屁股眼子交8| 亚洲精品视频在线播放| 欧美精品在欧美一区二区少妇| 亚洲欧美另类在线观看| 一区二区电影免费在线观看| 亚洲国产精品一区制服丝袜| 欧美一区二区三区四区在线| 亚洲欧洲精品一区| 欧美一级视频一区二区| 亚洲黄网站黄| 国产精品黄色| 久久久久综合一区二区三区| 欧美专区18| 亚洲三级毛片| 亚洲大片免费看| 欧美三区在线视频| 欧美激情第10页| 欧美午夜不卡在线观看免费| 久久国产免费| 免费在线成人av| 亚洲国产精品嫩草影院| 另类尿喷潮videofree| 欧美亚洲成人免费| 欧美一区网站| 亚洲一区二区动漫| 欧美承认网站| 欧美吻胸吃奶大尺度电影| 国产精品日韩电影| 国产精品视屏| 亚洲激情成人| 欧美大片在线观看| 亚洲一区二区三区四区五区午夜| 中国成人在线视频| 麻豆国产精品va在线观看不卡| 久久www成人_看片免费不卡| 99精品欧美一区| 国产亚洲人成网站在线观看| 在线观看日韩www视频免费 | 欧美大胆成人| 国产欧美日本| 欧美成人一区二区在线| 一本色道久久加勒比精品| 亚洲综合色激情五月| 国产欧美日韩一区二区三区在线观看 | 一区二区三区视频在线| 香蕉视频成人在线观看| 黄色在线成人| 在线观看一区视频| 亚洲精品日韩激情在线电影| 中日韩高清电影网| 欧美亚洲午夜视频在线观看| 久久青青草综合| 91久久精品日日躁夜夜躁欧美 | 亚洲毛片av在线| 国产精品99久久久久久人| 销魂美女一区二区三区视频在线| 久久精品一级爱片| 亚洲高清视频一区二区| 亚洲视频观看| 免费观看成人网| 欧美视频免费在线| 狠狠色香婷婷久久亚洲精品| 亚洲欧洲综合| 午夜久久久久久| 欧美激情精品久久久久久久变态| 夜夜夜久久久| 狼狼综合久久久久综合网| 欧美日韩亚洲另类| 在线观看日韩www视频免费 | 亚洲国产精品va在看黑人| 中文av字幕一区| 免费观看30秒视频久久| 一区二区三区欧美激情| 久久亚洲影院| 国产日韩一区二区三区在线| 日韩一区二区精品| 玖玖在线精品| 亚洲午夜电影网| 欧美激情视频网站| 激情综合视频| 久久福利视频导航| 一区二区三区福利| 欧美成人免费播放| 国产女主播在线一区二区| 9久草视频在线视频精品| 久久资源在线| 欧美一区二区三区播放老司机| 欧美日韩一区在线观看视频| 一区二区三区在线视频观看|