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

隨筆 - 67  文章 - 171  trackbacks - 0
<2013年4月>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

常用鏈接

留言簿(10)

隨筆分類

隨筆檔案

連接資料

最新隨筆

搜索

  •  

最新隨筆

最新評論

最近看到了C++/CLI這門新技術,但一直不知道這個東西重要不?應用廣泛不?希望大家指點。順便轉一些東西給大家看!



C++/CLI
  什么是C++/CLI呢?C++當然指的是Bjarne Stroustrup在BELL實驗室發明的C++語言,它實現了運行時取得速度和尺寸最佳化的靜態對象模型,然而它除了堆分配外不支持程序的動態修改,它準許無限地接近底層設備,但在程序運行過程中幾乎無法操作活動類型,也無法操作與程序相關聯的底層結構。Herb Sutter,C++/CLI的主要構造者之一,稱C++是一門“混凝土”式的語言。

  CLI指的是通用語言結構,一種支持動態組件編程模型的多重結構,在許多情況下,這代表了一個與C++對象模型完全顛倒了的模式。一個時實的軟件層,有效地執行系統,在底層操作系統與程序之間運行。操作底層的設備受到一定的限制,操作執行程序中的活動類型及與程序相關聯的下部結構得到了支持。反斜杠(/)代表C++和CLI的捆綁,這個捆綁帶來的細節問題是本文主要討論的問題。

  所以,“什么是C++/CLI”問題的最初、最接近答案是:它是靜態C++對象模型到CLI的動態組件對象編程模型的捆綁。簡而言之,它就是你如何用C++在.NET中編程,而不是C#或Visual Basic.NET。象C#和CLI本身一樣,C++/CLI正在ECMA(歐洲計算機制造商協會)主持下進行標準化,以最終符合ISO標準。

  實時通用語言(CLR)是CLI的微軟版本,它非常適用于微軟的Windows操作系統,相似地,Visual C++2005是C++/CLI的實現。

  作為第二個近似的答案,我認為C++/CLI是.NET編程模式與C++的結合,正如以前將模板與C++結合起來產生的泛型編程。所有這種結合中,企業所擁有的C++的投資以及開發人員使用C++的經驗將得到保存,而這恰恰是使用C++/CLI進行開發的重要基礎。

  學習C++/CLI的方法

  在設計C++/CLI語言中涉及三個方面問題,這同樣貫徹于所有的其他程序開發語言:一是語言級的語法向底層通用類型系統(簡稱CTS)的映射;二是向程序開發人員提供的CLI的底層細節結構的級別選擇;三是超越CLI的直接支持,提供額外的功能性函數的選擇。

  第一條對于所有的CLI語言來說都大致相同,第二條和第三條對于不同的CLI語言來說是不同的,相互區別的。根據你需要解決什么樣的問題,你將選擇這種或那種語言,也有可能混合使用多種CLI語言。學習C++/CLI涉及到了解它在設計過程中的所有這些涉及方面。

  從C++/CLI到CTS的映射?

  使用C++/CLI編程時間了解底層的CTS非常重要。CTS包括以下三種常用類的類型:
  1、多態引用類型,這正是對于所有繼承類所要使用的。
  2、非多態值類型,這用于實時高效的具體類型,例如數值類型。
  3、抽象的接口類型,這用于定義一個操作集,也可以用于實現接口的引用或值類型集合。
  這個設計方面的問題,即將CTS映射到語言內建的數據類型集合,通常同樣貫穿于所有的CLI語言,雖然不同的CLI語言語法不同。所以,在C#中你可能這么寫:

abstract class Shape { ... } // C#

  來定義了一個Shape基類,從該類將導出幾何對象,然而在C++/CLI你將這么寫:

ref class Shape abstract { ... }; // C++/CLI

  上述代碼說明了底層的C++/CLI引用類型。這兩種聲明在內層代表的意思是一樣的。相似地,在C#中你這么寫:

struct Point2D { ... } // C#

  來定義一個具體的Point2D 類,然而在C++/CLI中這么寫:

value class Point2D { ... }; // C++/CLI

  C++/CLI支持的類型集合代表了CTS與本地設備的綜合,這決定了你的語法選擇,例如:

class native {};
value class V {};
ref class R {};
interface class I {};

  CTS也支持與本地列舉類型稍微不同的列舉類類型。當然,對于上述兩者CTS是都支持的。例如:

enum native { fail, pass };
enum class CLIEnum : char { fail, pass};

  相似地,CTS支持它本身的數組類型,并且它再一次將其與本地數組在行為上區分開來。同時,微軟再次為這兩種類型提供了支持。

int native[] = { 1,1,2,3,5,8 };
array<int>^ managed = { 1,1,2,3,5,8 };

  那種認為一種CLI語言比其他CLI語言在向底層的CTS映射中表現的更出色或更完美都是不確切的,相反,每種不同的CLI語言代表著對CTS底層對象模型的不同理解,在下一節你將更清楚地看到這一點。

  CLI的細節

  設計一個CLI語言時第二個必須要考慮的問題是將CLI的底層執行模式融入到語言的細節級別。這種語言用于解決什么問題?這種語言是否有必須的工具來解決這些問題?這種語言可能吸引什么樣的程序開發人員?
  例如,值類型存在于托管堆上,在很多情況下值類型可以看到它們自身的存在。
  1、通過隱含的加箱操作,當一個值類型的實例被分配給一個對象或當一個虛擬的方法通過一個值類型來調用;
  2、當這個值類型被當作應用引用類類型的成員時;
  3、當這個值類型 被當作CLI數組成員時;
  需要指出的是,這種情況下開發人員是否被允許操作值類型的地址是CLI語言設計時必須應該予以考慮的問題。

  存在的問題

  在垃圾收集器掃描緊縮狀態下,位于托管堆上的任何對象非常可能面對重新定位問題。指向對象的指針可以實時跟蹤并修改。開發人員不能自己手動跟蹤,所以,如果你獲許取得一個可能位于托管堆上的值類型的地址時,除了本地指針外,還需要有一個跟蹤形態的指針。

  銷售商考慮的是什么?那就是需要簡單和安全,在語言中直接提供跟蹤一個對象或集合的指針使語言復雜化,沒有這種支持,將減少復雜程度,可資利用的、潛在的程序開發人群可能會增加,此外,準許程序開發人員操作生命短暫的值類型,增加了錯誤產生的可能性,程序開發人員可能有意無意地對內存進行錯誤操作,不支持跟蹤指針,一個潛在的更安全地實時環境產生了。

  另一方面,效率和靈活性也是必須考慮的一個問題,每一次向同一個對象分配值類型時,一個全新的數值加箱操作發生了,準許存取加箱值類型允許在內存中進行更新,這可能在性能上產生了一個非常巨大的進步。沒有跟蹤形態的指針,你無法用指針算法重新聲明一個CLI數組,這意味著CLI數組不能使用標準模板庫進行重新聲明,也不能使用一般的算法。準許操作加箱數值使設計具有更大地靈活性。

  微軟在C++/CLI中選擇地址集合模式來處理托管堆上的值類型。

int ival = 1024;
int^ boxedi = ival;
array<int>^ ia = gcnew array<int>{1,1,2,3,5,8};
interior_ptr<int> begin = &ia[0];
value struct smallInt { int m_ival; ... } si;
pin_ptr<int> ppi = &si.m_ival;

  典型地C++/CLI開發人員是一個復雜的系統程序員,承擔著提供下層內部構造和有組織的應用程序的任務,而這些恰恰是未來商業發展的基礎。C++/CLI開發人員必須兼顧可測量性和可執行性,所以必須在系統的高度級上來看待CLI下層結構。CLI細節水平反映了開發人員的臉色。

  復雜性本身并不代表對質量的否定,人類比單細胞細菌復雜的多,這當然不是一件壞事,然而,當表達一個簡單的概念變的復雜化后,這常常被認為是一件壞事。在C++/CLI中,CLI開發團隊已經試著提供一種精巧的方法來表達方式一個復雜的事情。

  額外增加的功能

  第三個設計方面是特定功能性的語言層,它遠遠超過CLI所提供的直接支持,雖然這可能需要在語言層支持和CLI底層執行模式間建立一個映射。但在某些情況下,這恰恰是不可能的,因為語言無法調節CLI的行為。這種情況的例子就是在基類的構造及析構函數中定義虛函數。根據ISO-C++在這種情況下的語言學,需要用每一個基類的構造和虛構函數重新設置虛擬表,而這是不可能的,因為虛擬表句柄是實時管理的,而不是某一個語言來管理。

  所以,這個設計方面是在完美性和可行性之間的妥協產物,C++/CLI提供的額外功能主要表現在三個方面:

  1、獲取資源的一種形式是對于引用類型的初始化,此外,提供一種自動化工具,用于占用較少資源、所謂的可確定性自動消亡的垃圾收集類型對象。
  2、一種深度拷貝形式的語法與C++拷貝構造函數和拷貝分配操作符相一致,但其并不適用與值類型。
  3、除了最初的一般性CLI機制外,還有對于CTS類型的C++模板直接支持。這些是我第一篇文章中討論的主題。此外,還提供了針對CLI類型的可校驗STL版本。

  讓我們來看一個簡單的例子,一個確定性消亡問題。在垃圾搜集器重新聲明一塊與對象相關聯的內存之前,一個相關的消亡方法,如果存在的話,將被調用。你可以認為這種方法是超級析構函數,因為它與對象的程序生命期無關。這就叫做終結。終結函數是否調用以及什么時間調用都沒有明確規定,這就是垃圾收集器的非確定性終結。

  在動態內存管理的情況下,非確定性終結工作非常好,當可用內存變的越來越少時,垃圾收集器介入并開始著手解決問題。然而,非決定性終結也有工作不好的時候,當一個對象維護一個重要資源,例如一個數據庫連接、鎖定某些類別、或者可能是本地的堆內存。在這種情況下,只要是不需要,應立即釋放資源。目前CLI所支持的解決問題的方法是,對于一個類通過執行IDisposable接口提供的Dispose方法釋放資源。這里的問題是執行Dispose方法需要一個清晰的聲明,所以它也就不可能存在調用。

  最基本的C++中的設計模式是上述的通過初始化來獲取資源,這意味著類使用構造函數來獲取資源,相反,類使用析構函數來釋放資源。這些行為由類對象在生存期內自動管理。

  下面是引用類釋放資源時所做的順序動作:
  1、 首先使用析構函數來封裝所有與釋放類有關的資源時所必須的代碼;
  2、 析構函數自動調用后,結束類對象的生命期。

  對于引用類型來說,CLI沒有類析構函數的概念,所以析構函數不得不映射為在底層執行的其它代碼。此時,在內部,編譯器執行以下操作:
  1、 類讓其基類列表繼承自IDisposable接口;
  2、 析構函數轉換成IDisposable的Dispose方法。

  以上實現了目標的一半,一種實現析構造函數自動調用的方法仍然需要,對于引用類型,一種特殊的基于棧的符號得到支持,也就是說,一個對象的生命期與它的聲明范圍有關。在內部,編譯器將符號轉換為在托管堆上分配引用對象。隨著作用域的終結,編譯器插入一個Dispose方法-用戶定義的析構函數。與對象有關的內存的收回在垃圾收集器的控制下得到執行。

  C++/CLI并不是將C++拓展到一個托管的世界,更確切的說,它代表一個完全綜合的范例,某種程度上就象當初將泛編程模式和多重繼承綜合進該語言一樣。我認為C++/CLI開發小組做了一項非常卓有成效的工作。

  小結

  C++/CLI代表托管和本地編程的結合。在反復過程中,這種綜合已經通過源級相對獨立但又相互平等地組件和二進制元素得到了完成,包括混合模式(本地和CTS類型的源級混合,還有一個本地及CLI對象文件的二進制混合),純模式(本地和CTS類型的源代碼級混合,所有的都被編譯為CLI對象文件),本地分類(可以通過一個特定的打包類來保持CTS類型),和CTS分類(可以保持本地類型為指針)。

  當然,C++/CLI開發人員也可以單獨使用CLI類型來編程,并通過這種方式來提供伺服狀態下的可校驗代碼,例如可以作為SQL Server2005的一個SQL存儲過程。

  現在,還是回到這個問題上來,什么是C++/CLI?它是進行.NET編程模式的最佳切入點。對于C++/CLI,有一個來自C++的遷移路徑,它不僅包含C++的底層基礎,而且也需要C++編程經驗,對于這些,我感到非常滿意。

C++/CLICLI:Common Language Infrastructure)是一門用來代替C++托管擴展(下文使用MC++指代)新的語言規范。重新簡化了C++托管擴展的語法,提供了更好的代碼可讀性。和微軟.NET的其他語言一樣,微軟向ECMA提交了C++/CLI的標準。C++/CLI現在可以在Visual C++ 2005上開發。C++/CLI的部分特性已經申請了專利

1 語法改變

C++/CLI是一門獨立的語言(比如新的關鍵字),而不是像C++托管擴展一樣是C++的超集 (C++托管擴展有一些不標志的關鍵字如__gc和__value)。所以,C++/CLI對于這些語法有較大的改變,尤其是去除了一些意義不明確的關鍵字,增加了一些.NET的特性.

很多不一致的語法,像MC++的不同版本用法的操作符new()被區分開:在C++/CLI,.NET引用類型的創建要使用新的關鍵字gcnew。并且C++/CLI增加了新的泛型概念(與C++ templates相似,但還是有很大的區別)。

1.1 句柄(Handle)

回到MC++,有兩類指針: 用__nogc標識的指針是傳統意義上的C++指針,而用__gc標識的指針為.NET中的引用。但在C++/CLI里,唯一的指針就是傳統意義上的C++指針,而.NET引用類型使用一個“句柄”來獲取,使用新的語法“類名^”代替了MC++的“類名*”。新的句法使得托管和非托管代碼混合開發更加方便;它指明了對象將會被垃圾回收器自動銷毀還是手動銷毀。

范例代碼:

// C++托管擴展
#using <mscorlib.dll>
using namespace System::Collections;
__gc class referencetype
{
protected:
String* stringVar;
int intArr __gc[];
ArrayList* doubleList;
public:
referencetype(String* str,int* pointer,int number) // 哪個是托管的?
{
doubleList = new ArrayList();
System::Console::WriteLine(str->Trim() + number.ToString());
}
};

// C++/CLI
#using <mscorlib.dll>
using namespace System::Collections::Generic;
ref class referencetype
{
protected:
String^ stringVar;
array<int> intArr;
List<double>^ doubleList;
public:
referencetype(String^ str,int* pointer,int number) // 不會再分不清了吧?
{
doubleList = gcnew List<double>();
System::Console::WriteLine(str->Trim() + number);
}
};

1.2 跟蹤引用(Tracking reference)

C++/CLI里的一個“跟蹤引用”也是一個句柄,但它是傳地址而不是傳值。等同于在C#中加了“ref”關鍵字,或Visual Basic .NET的“ByRef”。C++/CLI使用“^%”語法來定義一個跟蹤引用。與傳統C++中的“*&”語法相似。

下面的示例了“跟蹤引用”的使用。如果把“^%”改成“^”(也就是使用普通的句柄),10個字符串將不會被修改,而只會生成那些字符串的副本,這些都是因為那些引用已經不是傳地址而是傳值。

int main()
{
array<String^>^ arr = gcnew array<String^>(10);
int i = 0;

for each(String^% s in arr)
s = gcnew String(i++.ToString());

return 0;
}

上面的代碼示例了用戶如何用C++/CLI做一些其他.NET語言不能做的事情,比如C#就不允許在foreach循環中這樣做。例如foreach(ref string s in arr)在C#中是非法的。


1.3 析構(Finalizer/Destructor)

C++/CLI的另一個變化就是使用“!類名()”來聲明一個托管類型的“析構方法”(在垃圾回收器回收對象之前的不確定的時間由CLR調用),而原來的“~類名()”是用來定義“傳統的析構函數”(能被用戶自己調用)。另外,下面的例子說明了如何在C++/CLI中托管對象如何自動調用“傳統析構函數”。

在一個典型的.NET程序中(例如直接使用CIL)編程,可以由用戶自己調用的“析構方法”是用實現IDisposable接口,通過編寫Dispose方法來實現顯式釋放資源;而不確定的“析構方法”是通過重載Finalize函數來實現的。

// C++/CLI
ref class MyClass // :IDisposable (編譯器自動實現IDisposable接口)
{
public:
MyClass(); // 構造函數
~MyClass(); // (確定的) 析構函數 (編譯器使用IDisposable.Dispose來實現)
protected:
!MyClass(); // 析構方法 (不確定的) (編譯器通過重載virtual void Finalize來實現)
public:
static void Test()
{
MyClass auto; // 這不是個句柄,它將調用MyClass的默認構造函數
// 使用auto對象
// 函數返回前自動調用auto的析構函數(IDisposable.Dispose,由~MyClass()定義)來釋放資源
// 以上代碼等效于:
MyClass^ user = gcnew MyClass();
try { /* 使用auto對象 */ }
finally { delete user; /* 由編譯器調用auto.Dispose() */ }
}
};

// C#
class MyClass : IDisposable
{
public MyClass() {} // 構造函數
~MyClass() {} // 析構方法 (不確定的) (編譯器通過重載virtual void Finalize來實現),與C++/CLI的!MyClass()等效
public void Dispose() {} // Dispose方法
public static void Test()
{
using(MyClass auto = new MyClass())
{ /* 使用auto對象 */ }
// 因為使用了using句法,編譯器自動調用auto.Dispose()
// 以上代碼等效于:
MyClass user = new MyClass();
try { /* 使用user對象 */ }
finally { user.Dispose(); }
}
}




posted on 2008-07-13 12:29 cpsprogramer 閱讀(3182) 評論(13)  編輯 收藏 引用 所屬分類: VC++

FeedBack:
# re: @轉C++/CLI學習方法 2008-07-13 13:20 zzzzzzzz
樓主呀,不要在C++/Cli上浪費青春了,好好研究一下標準C++吧  回復  更多評論
  
# re: @轉C++/CLI學習方法 2008-07-13 16:12 葉付海的C++
@zzzzzzzz
此話怎么說呢?  回復  更多評論
  
# re: @轉C++/CLI學習方法 2008-07-13 16:31 斯卡
看不懂那  回復  更多評論
  
# re: @轉C++/CLI學習方法 2008-07-13 17:19 夢在天涯
CLIC++在實際的使用中并不多用,就我們的實際開發中唯一要使用這個的地方就是實現C++和C#語言的互調!

作為初學者,我覺的沒有必要研究,精通一門語言就最重要的啊!


CLIC++其實就是C++加C#,實現了既可以調用底層系統API,也可以使用。net framework提供大量的庫。但是以前的2門語言,現在一門要實現,那自然語法什么都有些復雜,也難免有點別扭,所以這也正是很多的C++和C#的開發者都不愿意去學習CLIC++。

以前沒有CLIC++的時候,我們都是從C++轉向C#,現在有了CLIC++以后,如果想要使用。net framework就可以從C++擴展到CLIC++,多了一個選擇!

我的blog上也有一些相關的資料,如果有學習者,歡迎交流與我!~  回復  更多評論
  
# re: @轉C++/CLI學習方法 2008-07-13 18:35 giscn
確實,C++/CLI使用極少,除非要將C++的遺留代碼連到.NET, C++/CLI語言成分非常多,可以看成兩種完全不同的模型的組合,建議要么學C#, 要么學標準C++.   回復  更多評論
  
# re: @轉C++/CLI學習方法 2008-07-14 08:05 紫夜蒼狼
現在只學了C++,還不懂C#,不過覺得要學一下的,,  回復  更多評論
  
# re: @轉C++/CLI學習方法 2008-07-14 10:07 mAGICfLYER
CLI不是一種抽象層么,用來提供跨語言的支持,從而讓多種語言可以共用一些庫資源。  回復  更多評論
  
# re: @轉C++/CLI學習方法[未登錄] 2008-07-14 13:16 Avlee
C++/CLI很多時候還是很有用的,特別是在你的.Net項目需要使用一些比較穩定的C++庫,而且這些庫沒有.Net版本的時候。這些情況在一些特殊領域很常見。  回復  更多評論
  
# re: @轉C++/CLI學習方法 2008-07-14 14:06 陳梓瀚(vczh)
@giscn
如果這樣就失去了把c++的庫接入c#的機會了。  回復  更多評論
  
# re: @轉C++/CLI學習方法 2008-07-14 15:51 giscn
@陳梓瀚(vczh)
C#與C++交互并不一定需要C++/CLI, 完全可以通過編譯成DLL來實現,如果C++很熟,又要與C#交互,看看C++/CLI是可以的  回復  更多評論
  
# re: @轉C++/CLI學習方法 2008-07-15 18:23 陳梓瀚(vczh)
這倒是,只是我覺得c#的pinvoke比較鳥  回復  更多評論
  
# re: @轉C++/CLI學習方法 2008-07-16 15:10 葉付海的C++
繼續  回復  更多評論
  
# re: @轉C++/CLI學習方法[未登錄] 2009-07-02 10:45 
很有必要的.比如我做電機控制,客戶要求酷的界面,用C#肯定不行,C#沒有調用硬件端口的函數.用MFC做界面又是不可選.而且一個好消息啊,C++/CLI可以調用WPF啊...享受混合編程吧...哈哈  回復  更多評論
  
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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精品国产| 亚洲永久在线| 午夜精品福利电影| 一本大道久久精品懂色aⅴ| 国产欧美一区二区三区国产幕精品 | 亚洲国产精品久久| 国产一区清纯| 欧美日韩天天操| 在线日韩成人| 亚洲激情中文1区| 亚洲电影免费观看高清完整版在线观看 | 野花国产精品入口| 一区二区三区我不卡| 国产综合欧美| 亚洲美女中文字幕| 久久综合伊人| 亚洲精品欧美日韩专区| 亚洲人成人一区二区在线观看| 亚洲人成在线观看| 亚洲精品影院| 亚洲成人在线视频播放| 伊人久久久大香线蕉综合直播 | 一区二区三区国产精品| 亚洲激情影视| 亚洲国产精品视频一区| 亚洲国产精品一区| 99re6这里只有精品视频在线观看| 麻豆精品在线播放| 99视频有精品| 一区二区三区 在线观看视频| 亚洲国产精品一区二区www| 亚洲欧美在线观看| 欧美成人中文| 亚洲综合视频1区| 国产亚洲欧美激情| 欧美一区二区私人影院日本| 91久久亚洲| 欧美日韩精品欧美日韩精品| 国产精品亚洲综合| 亚洲欧美成人一区二区在线电影| 午夜一级在线看亚洲| 亚洲色图在线视频| 欧美黑人国产人伦爽爽爽| 久久久爽爽爽美女图片| 国内视频精品| 久久久久久综合| 中日韩在线视频| 99亚洲一区二区| 性做久久久久久免费观看欧美| 欧美日韩伦理在线免费| 亚洲第一在线综合在线| 亚洲午夜av| 欧美亚男人的天堂| 亚洲影视在线| 久久人人97超碰国产公开结果| 亚洲电影在线免费观看| 免费一区二区三区| 麻豆成人综合网| 亚洲精选中文字幕| 久久国产夜色精品鲁鲁99| 亚洲黄网站在线观看| 欧美日韩一级大片网址| 久久久久www| 欧美大片va欧美在线播放| 久久国产精品99久久久久久老狼| 欧美成人激情视频免费观看| 在线一区观看| 欧美激情精品久久久久久变态| 99视频精品全部免费在线| 亚洲午夜精品视频| 黄色成人片子| 久久久久青草大香线综合精品| 一区二区三区 在线观看视频 | 亚洲综合成人在线| 亚洲成人在线免费| 久久久夜夜夜| 欧美日韩亚洲一区二区| 玖玖精品视频| 136国产福利精品导航| 亚洲免费婷婷| 欧美影视一区| 国产三级精品三级| 亚洲激情二区| 狼人天天伊人久久| 欧美成人免费在线| 亚洲国产清纯| 欧美精品色综合| 免费不卡在线观看| 欧美另类视频| 国产在线拍揄自揄视频不卡99| 亚洲午夜精品| 午夜精品一区二区三区在线视| 国产精品久久久久免费a∨| 久久女同互慰一区二区三区| 久久久人成影片一区二区三区观看 | 久久综合伊人77777蜜臀| 免费观看久久久4p| 国产在线观看91精品一区| 亚洲欧美日韩国产一区二区三区 | 午夜精品免费| 麻豆成人小视频| 午夜精品久久久久久久久久久| 国产一区二区三区av电影 | 亚洲精品美女在线观看| 国产精品嫩草99av在线| 美女成人午夜| 国产伦精品一区二区三区视频黑人 | 国产精品日韩二区| 免费试看一区| 欧美二区在线| 亚洲国产精品成人va在线观看| 国产精品久久看| 欧美老女人xx| 久久久青草婷婷精品综合日韩 | 日韩视频在线一区二区| 伊人天天综合| 午夜在线播放视频欧美| 一区二区激情视频| 老司机精品久久| 久久精品三级| 国产欧美一区视频| 亚洲深夜影院| 亚洲午夜精品久久| 欧美精品高清视频| 欧美11—12娇小xxxx| 亚洲视频1区2区| 日韩午夜在线观看视频| 久久精品国产亚洲一区二区三区| 国产精品99久久久久久久vr | 亚洲国产成人久久综合一区| 午夜精品一区二区三区电影天堂| 中文精品99久久国产香蕉| 欧美成人午夜免费视在线看片 | 99香蕉国产精品偷在线观看| 亚洲国产国产亚洲一二三| 久久久蜜桃精品| 久久久久久久久久久久久久一区| 国产精品一区二区在线观看网站| 9l国产精品久久久久麻豆| 亚洲毛片在线免费观看| 国产毛片精品国产一区二区三区| 黑人巨大精品欧美一区二区| 新67194成人永久网站| 久久国产99| 又紧又大又爽精品一区二区| 久久精品一区二区三区不卡牛牛| 久久米奇亚洲| 亚洲高清自拍| 久热这里只精品99re8久| 久热国产精品视频| 亚洲欧洲免费视频| 欧美日韩精品一区| 亚洲一区日韩| 亚洲狼人综合| 久久国产精品免费一区| 亚洲一级一区| 久久高清一区| 玖玖视频精品| 精久久久久久| 欧美 日韩 国产精品免费观看| 在线视频国产日韩| 久久视频在线免费观看| 亚洲日本无吗高清不卡| 麻豆国产精品777777在线| 在线视频精品一| 欧美日韩在线免费视频| 亚洲一区久久久| 久久在线免费观看视频| 亚洲精品女av网站| 国产精品久久久一区麻豆最新章节| 亚洲免费在线观看视频| 免费观看成人鲁鲁鲁鲁鲁视频| 一本久久精品一区二区| 狠狠色噜噜狠狠色综合久| 欧美久久电影| 久久久九九九九| 亚洲精品少妇网址| 久久久午夜电影| 99热在线精品观看| 国产女主播一区| 久久麻豆一区二区| 99精品视频免费在线观看| 裸体女人亚洲精品一区| 亚洲婷婷综合色高清在线| 在线观看视频一区| 国产精品视频观看| 免费在线欧美黄色| 亚洲影院在线| 亚洲老板91色精品久久| 一区二区三区产品免费精品久久75 | 亚洲欧洲在线免费| 国产免费成人在线视频| 欧美黑人国产人伦爽爽爽|