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

天秤座的唐風

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

  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>
            久久精品成人一区二区三区蜜臀| 欧美成人综合一区| 欧美一区二区三区电影在线观看| 蜜臀99久久精品久久久久久软件| 国产精品久久久久婷婷| 欧美一区二视频| 免费亚洲电影在线| 欧美sm极限捆绑bd| 亚洲欧美在线一区| 欧美色图五月天| 一区二区三区 在线观看视| 免费成人在线观看视频| 亚洲女ⅴideoshd黑人| 国产精品久久久久久久久久免费| 黑人中文字幕一区二区三区| 久久综合999| 亚洲综合色在线| 国产精品毛片| 性欧美超级视频| 一本色道久久综合狠狠躁篇的优点 | 久久综合狠狠| 亚洲日韩视频| 欧美激情1区2区| 欧美一区二区三区免费观看| 宅男噜噜噜66一区二区66| 国产精品亚洲精品| 一本久道久久综合狠狠爱| 欧美日韩大片| 久久精品电影| 欧美日韩国产在线播放网站| 久久国产精品久久久久久| 欧美中文字幕在线| 亚洲美女av电影| 日韩视频免费| 久久综合九色99| 欧美高清自拍一区| 欧美亚洲一区二区三区| 欧美专区日韩专区| 午夜在线播放视频欧美| 久久精品盗摄| 亚洲嫩草精品久久| 欧美丝袜一区二区三区| 久久综合给合久久狠狠色| 欧美日韩国产成人在线观看| 久久久久高清| 国产综合精品| 亚洲精品乱码久久久久| 亚洲国产高清自拍| 亚洲日本va午夜在线电影| 亚洲视频免费在线观看| 日韩视频免费在线观看| 久久国产99| 欧美在线一二三| 国产欧美日本| 久久久亚洲人| 亚洲电影第1页| 亚洲第一精品在线| 先锋资源久久| 亚洲精品女av网站| 国产日韩欧美一区二区| 亚洲免费在线播放| 亚洲精品国产精品国自产在线 | 国产精品无码专区在线观看| 亚洲视频在线观看三级| 久久久精品网| 亚洲欧美日韩国产成人| 国产精品一区二区三区四区| 亚洲高清不卡av| 久久se精品一区精品二区| 亚洲国产精品成人一区二区| 欧美三级第一页| 欧美国产精品v| 欧美一乱一性一交一视频| 亚洲美女中出| 国产亚洲精品福利| 国产精品成人在线观看| 欧美精品尤物在线| 可以看av的网站久久看| 欧美影片第一页| 亚洲自拍都市欧美小说| 一本色道久久88精品综合| 欧美激情综合| 亚洲精品美女在线观看播放| 欧美国产在线电影| 亚洲人成毛片在线播放| 亚洲风情在线资源站| 欧美国产一区二区| 亚洲国产欧美精品| aⅴ色国产欧美| 亚洲图片自拍偷拍| 欧美一级久久久| 欧美在线3区| 欧美在线视频免费| 99成人在线| 欧美精品二区| 日韩午夜av| 91久久精品美女高潮| 欧美日韩国产一中文字不卡| 国产一区二区三区在线观看精品| 亚洲综合色激情五月| 国产精品99久久久久久久vr| 欧美日韩精品一区二区三区| 99re6热只有精品免费观看| 欧美国产日韩精品免费观看| 免费91麻豆精品国产自产在线观看| 精品av久久707| 亚洲深夜福利网站| 国产欧美日韩免费看aⅴ视频| 国产日韩精品一区二区浪潮av| 亚洲免费观看高清在线观看| 久久人人爽人人爽爽久久| 亚洲一区3d动漫同人无遮挡| 欧美成ee人免费视频| 国产专区精品视频| 久久久久久久性| 一区二区欧美激情| 久久久五月天| 欧美伊人久久大香线蕉综合69| 亚洲综合色网站| 一区二区三区精品| 久久一区二区三区超碰国产精品| 欧美日韩免费在线视频| 夜夜躁日日躁狠狠久久88av| 亚洲国产欧美精品| 欧美搞黄网站| 亚洲综合日韩在线| 香蕉久久精品日日躁夜夜躁| 国产日韩在线看片| 欧美二区不卡| 国产精品yjizz| 欧美18av| 夜夜嗨av色综合久久久综合网| 亚洲成人中文| 国产精品v片在线观看不卡 | 一本综合精品| 亚洲曰本av电影| 亚洲高清中文字幕| 亚洲一区欧美二区| 最新国产精品拍自在线播放| 久久亚裔精品欧美| 国产一区二区三区黄视频| 亚洲日本视频| 欧美与欧洲交xxxx免费观看| 一区二区三区久久精品| 久久夜色精品国产| 国产精品一区在线观看你懂的| 国产亚洲在线| 亚洲乱码日产精品bd| 亚洲精品1区2区| 欧美成人午夜激情视频| 国产精自产拍久久久久久蜜| 亚洲电影免费在线观看| 亚洲破处大片| 欧美日韩精品一区二区| 亚洲国产精品123| 久久精品国产999大香线蕉| 欧美精品激情blacked18| 最新精品在线| 亚洲最新色图| 欧美大片在线看| 国产午夜精品一区理论片飘花| 亚洲福利视频一区| 亚洲永久免费精品| 久久精品国产亚洲a| 欧美激情国产日韩| 欧美成人在线影院| 亚洲精品久久久久久一区二区| 欧美亚洲系列| 亚洲亚洲精品在线观看 | 欧美11—12娇小xxxx| 欧美国产精品| 日韩视频一区二区| 中日韩高清电影网| 国产免费亚洲高清| 国产日韩在线看片| 久久国产精品久久久久久久久久| 久久久久久一区二区三区| 在线 亚洲欧美在线综合一区| 玖玖玖国产精品| 亚洲深夜福利| 欧美夫妇交换俱乐部在线观看| 亚洲国产精品一区二区www| 欧美电影专区| 亚洲欧美国产视频| 亚洲第一级黄色片| 午夜久久影院| 亚洲理论电影网| 国产一区二区三区免费观看| 老司机精品导航| 小黄鸭视频精品导航| 91久久极品少妇xxxxⅹ软件| 欧美一区二区三区免费观看| 亚洲日本成人网| 国产在线不卡| 日韩视频在线你懂得| 麻豆精品91| 美女诱惑黄网站一区| 久久爱www.| 性久久久久久久久久久久| 日韩一级免费观看|