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

天秤座的唐風

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

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

與臨時對象的斗爭(上)

作者:唐風

原載:www.cnblogs.com/liyiwen

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

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

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

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

先看看下面的代碼:

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() 函數返回了一個 MyCla 對象,而且是按值傳遞的。

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

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

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

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

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

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

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

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

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

右值引用與 move 語意

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

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

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

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

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

temp = x + y
z = temp

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

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

MyCla TestFun() {
    return MyCla();
}

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

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

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

那么,對于像:

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

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

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

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

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

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

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

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

總之,右值引用是 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 唐風 閱讀(2814) 評論(15)  編輯 收藏 引用 所屬分類: 語言技術

評論

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

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

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

看看現在還有N多用vc6的人…… 無語……


  回復  更多評論
  

# re: 與臨時對象的斗爭(上) 2009-12-02 22:58 OwnWaterloo
lambda,aotu,decltype這些都是很有用的特性,沒它們有時候真的是相當的不方便……

而且,lambda完全可以很簡單的純手工模擬一個。
這種毫無新意的機械復制的事情,本來就應該交給編譯器去做。
編譯器實現lambda表達式是不需要花什么力氣的。
只是解析可能會出現麻煩……

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

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

  回復  更多評論
  

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

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

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

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

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

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

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

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

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


  回復  更多評論
  

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


  回復  更多評論
  

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

據說vc9有免費的,不含ide。

  回復  更多評論
  

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

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


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


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

  回復  更多評論
  

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

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

這樣算侵權么?

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

  回復  更多評論
  

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

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

# re: 與臨時對象的斗爭(上) 2010-03-08 20:50 Jakcie
寫的不錯。
我現在用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久久综合| 欧美大片18| 亚洲一区二区三区中文字幕| 亚洲桃花岛网站| 国产亚洲精品久久久久动| 欧美综合第一页| 久热成人在线视频| 一区二区电影免费观看| 夜夜爽av福利精品导航 | 欧美一区二区视频97| 黄色在线成人| 亚洲日韩欧美视频| 国产精品私人影院| 麻豆91精品| 欧美日韩视频在线第一区| 欧美一区二区三区在线观看| 久久频这里精品99香蕉| 一本色道精品久久一区二区三区| 亚洲一区二区三区高清不卡| 狠狠综合久久av一区二区小说| 亚洲国产精品va| 国产精品老牛| 亚洲二区在线观看| 国产欧美日韩视频一区二区三区 | 精品51国产黑色丝袜高跟鞋| 亚洲激情校园春色| 国产一区二区久久精品| 日韩视频中文字幕| 欲色影视综合吧| 99视频在线观看一区三区| 韩国一区二区三区美女美女秀| 亚洲精品在线三区| 在线播放中文字幕一区| 欧美电影免费观看高清完整版| 99国产麻豆精品| 久久久久久久97| 午夜激情亚洲| 欧美激情一区在线观看| 久久综合导航| 国产亚洲福利社区一区| 在线亚洲精品福利网址导航| 亚洲人成在线观看网站高清| 久久久精品tv| 久久久精品2019中文字幕神马| 欧美三区在线观看| 亚洲人成啪啪网站| 在线观看欧美成人| 久久久国产成人精品| 久久精品国产亚洲高清剧情介绍| 欧美日韩在线视频首页| 亚洲精品久久久久久久久久久久| 亚洲欧洲一区二区在线播放| 免费在线日韩av| 欧美大片免费观看| 在线日韩欧美视频| 久久久久99精品国产片| 久久久www| 狠狠色狠色综合曰曰| 久久成人一区二区| 久久精品国产在热久久| 国产亚洲一二三区| 久久精品九九| 蜜臀av性久久久久蜜臀aⅴ| 韩国一区二区三区在线观看| 久久久www成人免费精品| 免费日韩av片| 亚洲韩国精品一区| 欧美激情欧美激情在线五月| 亚洲精品中文字幕在线| 亚洲深夜激情| 国产精品一区二区在线观看不卡| 亚洲一区二区在| 久久久国产一区二区| 激情综合网激情| 欧美国产丝袜视频| 日韩视频在线一区二区| 亚洲在线一区| 国产一区二区三区网站| 另类成人小视频在线| 亚洲破处大片| 欧美在线黄色| 在线观看亚洲视频啊啊啊啊| 欧美激情久久久久| 亚洲午夜在线观看| 久久久久久午夜| 亚洲精品视频一区二区三区| 国产精品ⅴa在线观看h| 久久精品女人天堂| 亚洲精品一线二线三线无人区| 午夜精品一区二区三区在线播放 | 欧美视频一区二区三区…| 午夜精品视频在线| 欧美激情国产精品| 香蕉久久国产| 亚洲人成久久| 国产欧美日韩不卡| 美女网站在线免费欧美精品| 中文精品视频| 欧美成人亚洲成人日韩成人| 亚洲欧美日韩国产精品| 亚洲电影下载| 国产九区一区在线| 欧美黄色aa电影| 欧美黄色小视频| 香蕉尹人综合在线观看| 亚洲国产一区二区在线| 国产欧美日韩| 欧美视频在线观看视频极品| 久久在线免费观看| 午夜影院日韩| 一区二区三区高清在线| 亚洲高清在线观看| 久久裸体艺术| 久久av一区二区三区| 亚洲精品乱码久久久久久蜜桃91| 国产亚洲综合在线| 国产精品蜜臀在线观看| 欧美国产大片| 蜜桃伊人久久| 久久精品91| 性欧美18~19sex高清播放| 99riav国产精品| 亚洲人成啪啪网站| 欧美激情1区2区| 欧美gay视频| 久久综合五月天婷婷伊人| 久久成人久久爱| 欧美一区二区三区在线观看视频| 中国成人黄色视屏| 一本色道88久久加勒比精品| 亚洲精品黄网在线观看| 亚洲激情在线观看| 亚洲电影在线免费观看| 精品动漫3d一区二区三区免费版| 国产区欧美区日韩区| 国产女人精品视频| 国产日韩欧美a| 国产日韩精品在线观看| 国产主播一区二区三区| 国产真实久久| 在线日韩电影| 亚洲精品国产精品国自产观看浪潮| 亚洲国产成人精品久久| 亚洲国产一区二区a毛片| 亚洲日本成人| 一本大道久久a久久精二百| 亚洲免费观看在线观看| 亚洲免费成人av| 亚洲一区二区免费在线| 午夜久久久久久| 欧美中文字幕| 老色批av在线精品| 亚洲高清自拍| 99视频一区| 新狼窝色av性久久久久久| 久久国产欧美日韩精品| 欧美成人一区二区三区在线观看 | 国产精品福利在线| 国产无一区二区| 亚洲韩国日本中文字幕| 9l国产精品久久久久麻豆| 亚洲欧美日韩国产| 麻豆av福利av久久av| 亚洲精品一区二区在线观看| 亚洲一区二区久久| 久久午夜视频| 欧美性猛交一区二区三区精品| 国产日韩欧美一区二区三区在线观看 | 欧美久久综合| 国产精品一区二区在线观看| 亚洲高清免费视频| 亚洲午夜精品久久| 另类激情亚洲| 在线亚洲欧美| 毛片基地黄久久久久久天堂| 国产精品va在线| 亚洲高清影视| 亚洲欧美日韩精品久久久| 日韩午夜精品| 久久不射中文字幕| 亚洲美女在线观看| 久久视频在线视频| 国产麻豆9l精品三级站| 亚洲日本中文字幕免费在线不卡| 午夜精品久久久久久久99水蜜桃| 欧美激情成人在线| 亚欧成人精品| 国产精品盗摄久久久| 亚洲日韩成人| 久久在线观看视频| 亚洲欧美日本日韩| 欧美日精品一区视频| 亚洲人成网站999久久久综合| 香蕉久久夜色精品国产使用方法| 91久久国产综合久久| 久久久久九九九| 国产视频久久|