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

天秤座的唐風

總會有一個人需要你的分享~!- 唐風 -

  C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
  13 隨筆 :: 0 文章 :: 69 評論 :: 0 Trackbacks

與臨時對象的斗爭(上)

作者:唐風

原載:www.cnblogs.com/liyiwen

C++ 是一門以效率見長的語言(雖然近來越來越多的人“不齒”談及效率,我深以為不然,在某一次的程序編寫中不對效率錙銖必較并不意味意味著我們就不應該追求更多的更好的做法)。總之吧,相比起其它語言,程序員們在使 C++ 的時候會更加有意識地去避免沒有效率的做法。在C++ 的程序中,臨時對象的產生就是損及效率的“惡因”之一,因此也產生出一些意思的技術和優(yōu)化手段,這篇文章里我總結一下最近在這些方面學習的一些收獲:

返回值優(yōu)化(RVO)與具命返回值優(yōu)化(NRVO)

這是一項編譯器做的優(yōu)化,已經是一種很常見的優(yōu)化手段了,放狗搜一下可以找到很多的資料,在 MSDN 里也有相關的說明。

返回值優(yōu)化,顧名思義,就是與返回值有關的優(yōu)化(廢話……),是當函數(shù)是按值返回(而不是引用啊、指針啊)時,為了避免產生不必要的臨時對象以及值拷貝而進行的優(yōu)化。

先看看下面的代碼:

typedef unsigned int UINT32;

class MyCla
{
public:
    MyCla(UINT32 a_size = 10):size(a_size) {
        p = new UINT32[size];        
    }
    MyCla(MyCla const & a_right):size(a_right.size) {
        p = new UINT32[size];
        memcpy(p, a_right.p, size*sizeof(UINT32));
    }
    MyCla const& operator = (MyCla const & a_right) {
        size = a_right.size;
        p = new UINT32[size];
        memcpy(p, a_right.p, size*sizeof(UINT32));
        return *this;
    }
    ~MyCla() {
        delete [] p;
    }
private:
    UINT32 *p;
    UINT32 size;
};

MyCla TestFun() {
    return MyCla();
}

int _tmain(int argc, _TCHAR* argv[])
{
    MyCla a = TestFun();
    
    return 0;
}

TestFun() 函數(shù)返回了一個 MyCla 對象,而且是按值傳遞的。

在沒有任何“優(yōu)化”之前,這段代碼的行為也許是這樣的:return MyCla() 這行代碼中,構造了一個 MyCla 類的臨時的無名對象(姑且叫它t1),接著把 t1 拷貝到另一塊臨時對象 t2(不在棧上),然后函數(shù)保存好 t2 的地址(放在 eax 寄存器中)后返回,TestFun 的棧區(qū)間被“撤消”(這時 t1 也就“沒有”了,t1 的生存域在 TestFun 中,所以被析構了),在 MyCla a = TestFun(); 這一句中,a 利用 t2 的地址,可以找到 t2 進行,接著進行構造。這樣 a 的構造過程就完成了。然后再把 t2 也“干掉”。

可以看到,在這個過程中,t1 和 t2 這兩個臨時的對象的存在實在是很浪費的,占用空間不說,關鍵是他們都只是為a的構造而存在,a構造完了之后生命也就終結了。既然這兩個臨時的對象對于程序員來說根本就“看不到、摸不著”(匿名對象嘛,你怎么引用?),于是編譯器干脆在里面做點手腳,不生成它們!怎么做呢?很簡單,編譯器“偷偷地”在我們寫的fun函數(shù)中增加一個參數(shù) A&,然后把 a 的地址傳進去(注意,這個時候 a 的內存空間已經存在了,但對象還沒有被“構造”,也就是構造函數(shù)還沒有被調用),然后在函數(shù)體內部,直接用 a 來代替原來的“匿名對象”,在函數(shù)體內部就完成 a 的構造。這樣,就省下了兩個臨時變量的開銷。這就是所謂的“返回值優(yōu)化”~!在 VC7 里,按值返回匿名對象時,默認都是這么做。

上面說的是“返回值優(yōu)化(RVO)”,還有一種“具名返回值優(yōu)化(NRVO)”,是對于按值返回“具名對象”(就是有名字的變量!)時的優(yōu)化手段,其實道理是一樣的,但由于返回的值是具名變量,情況會復雜很多,所以,能執(zhí)行優(yōu)化的條件更苛刻,在下面三種情況下(來自MSDN),NRVO 將一定不起作用:

  1. 不同的返回路徑上返回不同名的對象(比如if XXX 的時候返回x,else的時候返回y)
  2. 引入 EH 狀態(tài)的多個返回路徑(就算所有的路徑上返回的都是同一個具名對象)
  3. 在內聯(lián)asm語句中引用了返回的對象名。

不過就算 NRVO 不能進行,在上面的描述中的 t2 這個臨時變量也不會產生,對于 VC 的 C++ 編譯器來說,只要你寫的程序是把對象按值返回的,它會有兩種做法,來避免 t2 的產生。拿下面這個程序來說明:

MyCla TestFun2() {
    MyCla x(3);
    return x;
}

一種做法是像 RVO一樣,把作為表達式中獲取返回值來進行構造的變量 a 當成一個引用參數(shù)傳入函數(shù)中,然后在返回語句之前,用要返回的那個變量來拷貝構造 a,然后再把這個變量析構,函數(shù)返回原調用點,a 就構造好了。

還有一種方式,是在函數(shù)返回的時候,不析構 x ,而直接把 x 的地址放到 exa 寄存器中,返回調到 TestFun2 的調用點上,這時,a 可以用 exa 中存著的地址來進行構造,a 構造完成之后,再析構原來的變量 x !是的,注意到其實這時,x 的生存域已經超出了 TestFun2,但由于這里 x 所在 TestFun2 的棧雖然已經無效,但是并沒有誰去擦寫這塊存,所以 x 其實還是有效的,當然,一切都在匯編的層面,對于 C++ 語言層面來講是透明的。

嗯,(具名)返回值引用大約就是這么多,在網上和 MSDN 上還能查到更多的例子和解釋,對于在多線程下  (N)RVO 需要注意什么,嗯,我完全沒有多線程的經驗,不敢亂寫誤人子弟……

右值引用與 move 語意

“C++ 中臨時對象對效率產生的影響一直為人所詬病”(網上流傳的說法),NRVO 等手段也只有在一定程度上彌補這個不足(你知道,在很多情況下無法做優(yōu)化)。在 C++98 確定后的十多年時間后,“Cpper神圣”們終于給出了另一個對付它的法寶——右值引用。

對于右值引用,目前我所見過的最好的講解是VC開發(fā)團隊blog中發(fā)布的一篇長文(看這里),在CPP blog上飄飄白云的博主進行了全文翻譯(譯得很棒),建議細讀三遍!理解里面每一個例子~這樣至少你在右值引用的認識上就有了良好的基礎了。(嗯,我只讀了兩遍,下面說的東西有錯誤的話請原諒并指出 :) )

簡單的說,在C++中的左值,就是能取地址的表達式,比如var、++var之類的,右值就不是能取地址的表達式啦,比如常數(shù) 123、x++、x+y等等。

嗯,我們可以看到,右值常常就代表著臨時對象,也就常常意味著“被詬病的浪費……”

比如,z = x + y,這里,翻譯得更“低層”一點,那么這里將是:

temp = x + y
z = temp

這個temp是很尷尬的,不用它將無法實現(xiàn)正確、良好的 operator + 語意,用它就很難避免臨時對象產生的不良開銷。

我們回到上面 RVO 中的程序例子:

MyCla TestFun() {
    return MyCla();
}

看,這里返回的 MyCla(),正是一個右值(我們就給它取個名吧,不然不好稱呼它,嗯,還叫 t1 吧)。在函數(shù)返回后,這個 t1 就被析構,它做的析構動作就是把原來申請的內存還給系統(tǒng)。想想在這之前,a 在干什么?a 在構造的時候向系統(tǒng)申請了一塊內存!一個申請,一個還回,一來一回多費事啊,如果能直接把 t1 擁有的內存給 a ,就不省事了嗎?反正 t1 馬上就要掛了。好,右值引用給了我們這種機會,我們?yōu)?MyCla 實現(xiàn)一個 move 語意的拷貝構造函數(shù)(不知道什么是 move 拷貝構造?回頭看上面鏈接的文章三遍!):

MyCla(MyCla && a_right):size(a_right.size) {
    p = a_right.p;
    a_right.p = NULL;        
}

當編譯器探知用于構造 a 的是一個右值時,就調用這個 move 構造函數(shù),然后我們在這個函數(shù)里偷梁換柱,把 t1 的資源竊取過來了。這樣,就算不使用 RVO,這個構造的開銷也是非常小的。

那么,對于像:

MyCla TestFun2() {
    MyCla x(3);
    return x;
}

這樣的情況呢?是的,這里的 x 是一個左值,不會調用 move 構造函數(shù)。可是我們知道這個 x 其實馬上也要掛了,它的資源不給白不給啊對不對?所以,我們就想告訴編譯器,您就把它當成個右值吧,怎么告訴它呢?用 std::move 來實現(xiàn)這種 move 語意,像下面這樣:

MyCla TestFun2() {
    MyCla x(3);
    return std::move(x);
}
好啦,這樣又能用上 MyCla 的 move 構造函數(shù)啦。

總結一下,作為右值的臨時對象,其實它的存在就是充當一個傳遞的橋梁,一旦表達式過了這個橋,那么這個臨時對象的存在就沒有意義了,也沒有人能再用到它(因為它是個右值,沒有名字,又不能取地址)。既然如此,一個無人問津的就要“死”的變量,把它擁的的資源搶過來也不算過份吧……。在 C++0x 之前,我們想這么做,但是沒有手段,雖然編譯器能分清楚左值右值,但我們無法通過程序告訴編譯器,如果這是左值,請用這個方法,這個是右值,嘿嘿,那用另一個方法幫我搶它的資源吧……,。到了 C++0x ,我們有手段了,那就是右值引用,這個右值引用可以參與函數(shù)的重載,這樣就給了我們機會,針對左右值分別提供不同的操作方法(函數(shù))讓編譯器幫我們選擇一個合適的。

一般來說,可能需要注意右值引用的地方有:

當我們寫的類里擁有動態(tài)申請的資源時,那么總是應該提供一個move構造函數(shù),這將會帶給很多好處,可以讓這個類的使用者(一般是我們自己函數(shù),或是SDL等庫)利用它來提升效率。

如果我們寫的函數(shù)需要利用傳入的(含有動態(tài)申請資源的)對象參數(shù)來構造新的變量時,我們可以提供右值引用的重載版本,并在構造新對象時使用std::move來竊取臨時對象的資源。

右值引用在泛型編程中也有極為重要的作用(它能實現(xiàn)完美轉發(fā)),但和本文沒多大關系,就不多說了。

總之,右值引用是 C++0x 中非常耀眼的一個新的語言特性,VC2010已經將其列入支持范圍(GCC 本人幾乎沒用過,沒了解,不敢妄言[注{ThanksTo OwnWaterloo}:gcc新版本也支持了。 gcc4.4.0 的stl已經加上對move的支持了])。

從實踐的角度講,它能夠完美地解決 C++ 中長久以來為人們所詬病的臨時對象的效率問題。從語言本身來講,它健全了 C++ 中引用類型在左值右值方面原先的缺陷,從庫的設計者角度講,它給設計者又帶來了一把利器。而對于廣大的庫使用者而言,不動一兵一卒便能獲得“免費”的效率提升。

牛吧!這個特性如此重要如此有用,幾乎可以想見在支持右值的編譯器一旦實用化,就將產生大量的使用右值引用特性代碼和相關的idioms,也可能會遇到和這個相關的bug,一句話,趁早學吧,出來混,總是會碰上的……。

 

(上篇完,下篇將分析 Expression Template 在消除臨時變量中的作用,以及對三種方法進行一個總結)

posted on 2009-12-02 22:11 唐風 閱讀(2829) 評論(15)  編輯 收藏 引用 所屬分類: 語言技術

評論

# re: 與臨時對象的斗爭(上) 2009-12-02 22:50 OwnWaterloo
gcc新版本也支持了。 gcc4.4.0 的stl已經加上對move的支持了。

沒有右值引用,也可以消除很多臨時變量,只是編程很復雜……
需要使用一些proxy,用來"記錄""操作與操作數(shù)",僅僅是"記錄"。
只有當出現(xiàn)操作的"接收者"時,操作才被真正執(zhí)行,直接在接收者上進行操作了。

當然,有move更好,本來就應該是這樣,對立馬就要消亡的對象,盜取一些資源是很合理的……
只是不知道c++0x要什么時候才能流行起來……

看看現(xiàn)在還有N多用vc6的人…… 無語……


  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2009-12-02 22:58 OwnWaterloo
lambda,aotu,decltype這些都是很有用的特性,沒它們有時候真的是相當?shù)牟环奖恪?br>
而且,lambda完全可以很簡單的純手工模擬一個。
這種毫無新意的機械復制的事情,本來就應該交給編譯器去做。
編譯器實現(xiàn)lambda表達式是不需要花什么力氣的。
只是解析可能會出現(xiàn)麻煩……

auto、decltype更是容易。
其實編譯器已經實現(xiàn)了它們,只是沒有暴露出來而已。

期待c++0x流行啊……

  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2009-12-02 23:17 non
c++0x過于復雜,在大的工程上保守派不敢上。。甚至于stl的都要求少用  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2009-12-02 23:18 唐風
話說 VC6 還真有點像 IE6 ,擁有極高的使用率,但又不能完全支持“標準”,呵呵,不過 VC6 可以原諒,畢竟開發(fā)的時候 C++ 標準還沒出臺嘛……

唉,托 D 版的福,我可是每發(fā)布一個新版本就立即升級的,呵呵,不過在公司做項目又沒辦法了,得聽公司技術決策者的,呵,而我們公司那個大牛,MS 習慣 VC6 ……。

我也很期待 C++0x 呢,對 C++ 很有感情,哈哈

對于
【沒有右值引用,也可以消除很多臨時變量,只是編程很復雜……】
是啊,但通過這些途徑,完成了一些“目標”之后仍然會覺得心中有缺憾,不能用最優(yōu)雅的方式解決問題的時候總會不舒服,
就像 Expression Template 被開發(fā)出來,我想也是人們想有效率,又想直觀的結果吧……

PS:
您還真是快啊~~我這才發(fā)布,你就來了。神仙~  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2009-12-02 23:29 唐風
@non
是有聽這么說的。
不過我總覺得:不鼓勵或是要求禁用 STL 的組織,肯定得要有牛人實現(xiàn)一套更合適于他們工程的基本類庫,也許他們只是不想要通用的 STL 實現(xiàn),但 STL 做的那些事,始終還是需要有“人”來做的。
  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2009-12-02 23:51 OwnWaterloo
@唐風
DB是什么???

對那些保守黨,就任由他們去吧……
讓他們在自己的世界里自娛自樂,一次又一次的發(fā)明那屬于自己心中完美輪子。
都復用別人的,他們還怎么好開口向老板要錢啊?
一定要說:stl對我們的項目都是不適合的! —— 以顯得自己的項目很牛逼。
然后追加:所以我們自行開發(fā)了xxx! —— 以顯得自己很牛逼。


  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2009-12-03 00:06 唐風
@OwnWaterloo
呃,不好意思,我是想說“盜版”,呵呵
回想,DB 確實容易聯(lián)想成 DataBase,那這句話就不好理解了……
It's my fault :)


  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2009-12-03 00:27 OwnWaterloo
@唐風
機器上的vs2005和2008是學校給的…… 據(jù)說有個什么政策,學校每年只用付3000元就可以使用大量的正版軟件。
不過…… 我已經畢業(yè)了…… 機器上的還沒刪…… 繼續(xù)用著……
還去下了一個vc10精簡版…… 這肯定是D版了……

據(jù)說vc9有免費的,不含ide。

  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2009-12-03 13:36 空明流轉
@OwnWaterloo
從2003開始,VS就有Express Edition了,不過僅用于開發(fā)非商業(yè)授權的軟件。  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2009-12-03 16:33 OwnWaterloo
@空明流轉
嗯,謝謝~


如果我只是想用VC的編譯器測試一下可移植性。
但并不發(fā)布VC生成的binary。
這樣可以么?


或者,我開發(fā)的東西使用的是new BSD或者LGPL之類的許可證,可以使用VC express么?

  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2009-12-03 16:40 OwnWaterloo
@空明流轉
上面好像沒說清楚…… 我整理一下……

1. 開發(fā)的軟件使用商業(yè)許可證。
發(fā)布的binary使用的是,比如mingw,生成的。
也發(fā)布源代碼。
但發(fā)布前使用VC express作移植性測試。
當然,還包括VC使用的工程文件也會發(fā)布。
有VC授權的人,可以自己使用VC編譯。

這樣算侵權么?

2. 開發(fā)的軟件使用非商業(yè)許可證,比如new BSD或LGPL
發(fā)布源代碼,VC工程文件。侵權么?
發(fā)布VC編譯的binary呢?

  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2009-12-04 12:30 YESHG!
關于這篇的俺的第一篇回復呢?這里是不是會評論失敗?
  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2009-12-06 22:25 唐風
@YESHG!
你也注冊一個博客園(或是cppblog)的帳戶唄
對評論和回復有郵件通知,這個功能挺好用的。  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2010-03-08 20:50 Jakcie
寫的不錯。
我現(xiàn)在用2005。其實VC6,里面Bug還是不少。尤其是MFC里面。2010都出了,至少該用2005吧。
免費版也有IDE,但沒有很多高級功能和資源編輯器。  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2013-02-28 16:51 refugee
MyCla const& operator = (MyCla const & a_right) {
size = a_right.size;
p = new UINT32[size];
memcpy(p, a_right.p, size*sizeof(UINT32));
return *this;
}
這個賦值重載有點問題,一、沒做自賦值檢查;二、沒釋放原有空間,內存泄露(size一致的可以不釋放,也不用new新空間,直接copy);三、返回值是否有必要用const限制,表達式(a=b)=c不能成立,雖然這表達式本身就有點腦殘。  回復  更多評論
  

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            亚洲老板91色精品久久| 亚洲欧美国产视频| 日韩天堂在线观看| 亚洲人www| 亚洲电影免费观看高清完整版| 国产欧美日韩三区| 国产亚洲欧美一区在线观看| 国产女主播一区二区| 国产精品一区二区在线观看不卡 | 亚洲国产欧洲综合997久久| 午夜在线成人av| 欧美一二三区精品| 久久综合电影一区| 亚洲国产日韩欧美| 在线视频欧美一区| 性欧美暴力猛交69hd| 久久久久综合| 欧美另类综合| 国产精品中文字幕欧美| 1024欧美极品| 亚洲色图综合久久| 久久综合色婷婷| 亚洲乱码精品一二三四区日韩在线 | 国产欧美一区二区色老头| 国产三级精品在线不卡| 亚洲国产精品成人va在线观看| 亚洲精品日韩在线观看| 亚洲欧美另类在线| 免费h精品视频在线播放| 亚洲日本成人网| 香蕉av福利精品导航| 免费亚洲一区二区| 国产区在线观看成人精品| 91久久久久久久久| 欧美一区二区三区日韩| 欧美成人乱码一区二区三区| 在线亚洲欧美专区二区| 久久综合网hezyo| **欧美日韩vr在线| 日韩亚洲成人av在线| 亚洲婷婷综合色高清在线| 久久国产精品久久久久久| 欧美激情一区二区三区在线视频观看| 一区二区三区久久网| 噜噜爱69成人精品| 国产在线日韩| 亚洲欧美国产三级| 亚洲精品一区二区三| 久久这里只有| 国产一区在线播放| 国内视频精品| 欧美一区二区三区视频在线| 99爱精品视频| 欧美激情久久久久久| 136国产福利精品导航网址| 欧美一区在线看| 日韩一级片网址| 欧美精品1区| 亚洲伦理在线免费看| 欧美大胆成人| 久久综合伊人77777尤物| 欧美剧在线观看| 亚洲精品视频免费观看| 欧美激情日韩| 欧美国产日韩精品免费观看| 91久久在线| 亚洲电影第1页| 欧美高清在线观看| 99精品视频免费全部在线| 亚洲国产99| 欧美精品亚洲| 亚洲午夜一区二区| 亚洲午夜在线| 国产性天天综合网| 久久综合色播五月| 欧美成人一区二区| 在线中文字幕一区| 亚洲欧美日韩中文视频| 国内精品99| 欧美激情一区二区三区在线视频 | 亚洲天堂男人| 99精品免费视频| 国产精品日韩久久久久| 欧美与欧洲交xxxx免费观看| 久久精品中文字幕一区二区三区| 91久久精品日日躁夜夜躁欧美 | 一区视频在线看| 欧美激情一区二区久久久| 欧美精品v国产精品v日韩精品| 亚洲图片激情小说| 欧美在线播放一区二区| 亚洲欧洲在线视频| 亚洲视频观看| 国产一区二区成人久久免费影院| 国内精品亚洲| 亚洲精品乱码久久久久久久久| 亚洲美女视频网| 国产婷婷色一区二区三区在线| 老司机67194精品线观看| 久久综合色播五月| 亚洲欧美在线另类| 欧美一区二区三区久久精品| 亚洲国产日韩欧美综合久久| 欧美一区二区三区在线| 久久久久99精品国产片| 在线观看欧美日韩国产| 久久久久久久欧美精品| 欧美在线播放一区二区| 亚洲福利视频网站| 最近看过的日韩成人| 欧美三级特黄| 亚洲精一区二区三区| 亚洲欧美视频在线| 亚洲人成网在线播放| 夜夜夜久久久| 精品福利电影| 亚洲精品在线一区二区| 欧美视频福利| 久久在线观看视频| 欧美人与禽猛交乱配| 久久成年人视频| 蜜桃伊人久久| 欧美综合二区| 免费看黄裸体一级大秀欧美| 亚洲夜晚福利在线观看| 久久久国产亚洲精品| 亚洲一区二区免费| 久久综合久久综合这里只有精品| 香蕉久久国产| 欧美成人tv| 久久久久**毛片大全| 欧美三区视频| 欧美国产欧美亚州国产日韩mv天天看完整| 欧美精品久久一区二区| 久久一本综合频道| 欧美精品自拍| 亚洲第一黄色网| 国内外成人免费视频| 欧美韩日高清| 激情综合电影网| 午夜精品视频在线观看| 亚洲视频每日更新| 欧美—级高清免费播放| 久久亚洲一区| 国内视频精品| 久久久久国产精品午夜一区| 久久久久久久久久久久久女国产乱| 国产精品久久久久久久久果冻传媒| 久久久精品免费视频| 亚洲第一在线综合网站| 久久久久久久精| 久久免费99精品久久久久久| 国产日韩专区在线| 欧美在线一级视频| 欧美jizz19性欧美| 亚洲国产成人av好男人在线观看| 欧美中文字幕精品| 久久久久99| 国内精品久久久久久| 国产日韩精品一区二区三区 | 99精品欧美一区二区蜜桃免费| 久久久久亚洲综合| 久久欧美肥婆一二区| 韩国精品一区二区三区| 欧美一级视频免费在线观看| 午夜久久久久久| 国产精品视频免费在线观看| 亚洲午夜久久久久久久久电影网| 亚洲一区欧美| 激情av一区| 蜜桃av一区二区三区| 亚洲人体1000| 国产精品99久久久久久www| 欧美日韩精品一本二本三本| 在线视频亚洲欧美| 久久精精品视频| 狠狠色狠狠色综合日日91app| 久久国产主播| 亚洲国产第一| 99这里只有精品| 国产精品videosex极品| 亚洲一区精品视频| 久久天堂国产精品| 亚洲看片一区| 免费影视亚洲| 亚洲欧美日韩精品久久奇米色影视 | 欧美a一区二区| 亚洲国产日韩欧美一区二区三区| 国产精品久久久一本精品| 午夜精品国产精品大乳美女| 久久乐国产精品| 日韩午夜在线播放| 欧美日韩黄色大片| 久久久精品日韩欧美| 日韩视频一区二区| 另类图片国产| 中文国产成人精品久久一| 欧美欧美全黄| 玖玖玖国产精品| 亚洲网友自拍|