• <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>
            隨筆 - 67  文章 - 171  trackbacks - 0
            <2014年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            常用鏈接

            留言簿(10)

            隨筆分類

            隨筆檔案

            連接資料

            最新隨筆

            搜索

            •  

            最新隨筆

            最新評論

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



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

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

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

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

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

              學習C++/CLI的方法

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

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

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

              使用C++/CLI編程時間了解底層的CTS非常重要。CTS包括以下三種常用類的類型:
              1、多態(tài)引用類型,這正是對于所有繼承類所要使用的。
              2、非多態(tài)值類型,這用于實時高效的具體類型,例如數(shù)值類型。
              3、抽象的接口類型,這用于定義一個操作集,也可以用于實現(xiàn)接口的引用或值類型集合。
              這個設計方面的問題,即將CTS映射到語言內建的數(shù)據(jù)類型集合,通常同樣貫穿于所有的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支持它本身的數(shù)組類型,并且它再一次將其與本地數(shù)組在行為上區(qū)分開來。同時,微軟再次為這兩種類型提供了支持。

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

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

              CLI的細節(jié)

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

              存在的問題

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

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

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

              微軟在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開發(fā)人員是一個復雜的系統(tǒng)程序員,承擔著提供下層內部構造和有組織的應用程序的任務,而這些恰恰是未來商業(yè)發(fā)展的基礎。C++/CLI開發(fā)人員必須兼顧可測量性和可執(zhí)行性,所以必須在系統(tǒng)的高度級上來看待CLI下層結構。CLI細節(jié)水平反映了開發(fā)人員的臉色。

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

              額外增加的功能

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

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

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

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

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

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

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

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

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

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

              小結

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

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

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

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

            1 語法改變

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

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

            1.1 句柄(Handle)

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

            范例代碼:

            // 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使用“^%”語法來定義一個跟蹤引用。與傳統(tǒng)C++中的“*&”語法相似。

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

            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循環(huán)中這樣做。例如foreach(ref string s in arr)在C#中是非法的。


            1.3 析構(Finalizer/Destructor)

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

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

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

            // C#
            class MyClass : IDisposable
            {
            public MyClass() {} // 構造函數(shù)
            ~MyClass() {} // 析構方法 (不確定的) (編譯器通過重載virtual void Finalize來實現(xiàn)),與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 閱讀(3161) 評論(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++在實際的使用中并不多用,就我們的實際開發(fā)中唯一要使用這個的地方就是實現(xiàn)C++和C#語言的互調!

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


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

            以前沒有CLIC++的時候,我們都是從C++轉向C#,現(xiàn)在有了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 紫夜蒼狼
            現(xiàn)在只學了C++,還不懂C#,不過覺得要學一下的,,  回復  更多評論
              
            # re: @轉C++/CLI學習方法 2008-07-14 10:07 mAGICfLYER
            CLI不是一種抽象層么,用來提供跨語言的支持,從而讓多種語言可以共用一些庫資源。  回復  更多評論
              
            # re: @轉C++/CLI學習方法[未登錄] 2008-07-14 13:16 Avlee
            C++/CLI很多時候還是很有用的,特別是在你的.Net項目需要使用一些比較穩(wěn)定的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來實現(xiàn),如果C++很熟,又要與C#交互,看看C++/CLI是可以的  回復  更多評論
              
            # re: @轉C++/CLI學習方法 2008-07-15 18:23 陳梓瀚(vczh)
            這倒是,只是我覺得c#的pinvoke比較鳥  回復  更多評論
              
            # re: @轉C++/CLI學習方法 2008-07-16 15:10 葉付海的C++
            繼續(xù)  回復  更多評論
              
            # re: @轉C++/CLI學習方法[未登錄] 2009-07-02 10:45 
            很有必要的.比如我做電機控制,客戶要求酷的界面,用C#肯定不行,C#沒有調用硬件端口的函數(shù).用MFC做界面又是不可選.而且一個好消息啊,C++/CLI可以調用WPF啊...享受混合編程吧...哈哈  回復  更多評論
              
            久久综合精品国产二区无码| 久久人人爽人人爽人人片AV麻豆| 亚洲欧美一区二区三区久久| 亚洲国产综合久久天堂| 婷婷久久综合九色综合九七| 伊人久久大香线蕉精品不卡 | 99久久99久久精品国产片果冻| 一级做a爰片久久毛片看看| 久久综合给合久久狠狠狠97色| 欧美激情精品久久久久| 久久这里的只有是精品23| 久久精品中文无码资源站| 欧美精品福利视频一区二区三区久久久精品| 亚洲精品无码久久久久AV麻豆| 奇米综合四色77777久久| 久久久这里有精品中文字幕| 97久久婷婷五月综合色d啪蜜芽| 热re99久久精品国产99热| 欧美黑人激情性久久| 久久有码中文字幕| 久久综合丁香激情久久| 久久精品亚洲日本波多野结衣| 亚洲成av人片不卡无码久久| 久久精品国产欧美日韩99热| 精品精品国产自在久久高清| 国产精久久一区二区三区| 伊人久久精品无码二区麻豆| 香蕉久久夜色精品国产小说| 久久久久99精品成人片直播| 偷偷做久久久久网站| 精品久久人人妻人人做精品| 久久精品国产69国产精品亚洲| 性做久久久久久久| 午夜人妻久久久久久久久| 久久精品卫校国产小美女| 狠狠色丁香婷婷久久综合| 青春久久| 久久人人爽人人爽人人片AV东京热 | 久久亚洲精品成人AV| 久久亚洲春色中文字幕久久久| 久久婷婷五月综合国产尤物app|