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

西城

指尖代碼,手上年華

聯系 聚合 管理
  20 Posts :: 0 Stories :: 62 Comments :: 0 Trackbacks
這一陣在看CORBA,想找一個優秀的開源實現并不容易。MICO性能太差,沒有考慮,omniORB還好,只是配置著有點麻煩,
Naming Service那部分用了好長時間也沒讓程序成功運行。orbit差不多是所有的實現里面最為高效的一個,因為它是
用C實現的,主要的綁定語言是C和perl。GNOME項目組正在用它。至少從實用性角度看,它要比omniORB好的多。
在看其中的例子時,發現了在一些問題的處理上,C的實現非常高效,而且并不復雜。相比之下,
C++則顯得有點臃腫,效率低下。
第一個問題:類的實現。
C語言里沒有類的概念,而IDL定義的接口則需要實現類似于對象的概念。C中的方法是將類作為方法的前綴,因為我們
最終調用的還是方法,而將類作為函數名的前綴之后,就能保證方法名字的唯一,因為類名是不同的,一個類中的函數
名也是不同的。這樣就大大降低了開銷,所有的一切都是通過函數調用來完成的。
比如
CORBA_ORB類中的resolve_initial_references方法,若參數是“RootPOA”
則C中的實現是
CORBA_ORB_resolve_initial_references(*orb,"RootPOA",ev);
其中第一個參數就是調用此方法(resolve_initial_references)的類,第三個參數就是我所說的第二個問題:異常處理。
C++中引入了throw...catch控制接口和exception類。優點自不待言,缺點卻也不少,效率損失,程序結構的混亂。
在C的大部分函數中,我們可以看到另一種解決方法——額外的參數。
通過附加一個額外的參數來表明錯誤,然后檢測錯誤,這樣的開銷比用throw....catch小的多,而且沒有破壞程序
結構。
C雖然只是一種面向過程的語言,沒有那么多的“高級特性”,但通過各種封裝,在不損失語言的簡潔和高效的同時,
C的實現也是有很多優點的。這也是為什么C總能穩居語言排行榜的第二位的原因。
posted on 2012-03-24 22:55 西城 閱讀(1807) 評論(26)  編輯 收藏 引用 所屬分類: C/C++

Feedback

# re: C和C++在兩個小問題上的對比 2012-03-26 00:27 陳梓瀚(vczh)
你雖然論證了C++編譯時間慢,但是這絲毫不影響運行時效率啊。而且C++封裝層次高,所以你正確使用C++寫一個程序,花的時間要比C少很多,就算加上慢的編譯速度,也是更劃算的。

舉個例子“這樣就大大降低了開銷,所有的一切都是通過函數調用來完成的。
”。沒錯,這有開銷,但這個開銷是在編譯器里面的,最終生成的運行時代碼,還是跟C語言一樣。一次性的東西都不用管它。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比 2012-03-26 10:50 墨魂
@陳梓瀚(vczh)
但從orbit與omniORB的實現來說,我覺得還是C的實現更好,因為你用orbit寫分布式程序時,最終服務器端的大部分代碼都直接有orbit幫你生成,你只用寫你需要實現的功能這一塊就好。但omniORB卻全是要自己手動去寫。運行時代碼是和C一樣,但throw...catch這樣的代碼一直都在程序中,不僅影響程序邏輯,在實現上也比直接傳一個參數低效的多  回復  更多評論
  

# re: C和C++在兩個小問題上的對比 2012-03-26 10:59 zjh
@陳梓瀚(vczh)
正確使用C++寫一個程序,花的時間要比C少很多
正確使用c++比正確使用c,所花費的時間是不可等日耳語的
不敢茍同,c++太復雜了,稍不留神,就有可能出錯,效率低下,只要看看c++出版了那么多書籍就知道了,至今沒有一個編譯器能完全實現標準c++,也說明c++過于復雜
  回復  更多評論
  

# re: C和C++在兩個小問題上的對比[未登錄] 2012-03-26 15:27 陳梓瀚(vczh)
你要是非要拿一個類庫來說,那我也可以說我山寨過一個boost::spirit,那種優美兼高效的parser寫法,C永遠都做不到呢。這有什么意思。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比[未登錄] 2012-03-26 15:29 陳梓瀚(vczh)
@zjh
學習C++是一次性的,而寫C語言程序則是每一次都要做的事情。你這么比較不公平。一個更極端的例子,你花更多的時間去學習haskell,后面每一個程序的尺寸,可能是C語言的1/30,而且健壯性基本不用care因為語言保證了你很難不健壯,性能也不差。這個開發效率高不高,當然是算總的時間,豈能算一個程序的時間?  回復  更多評論
  

# re: C和C++在兩個小問題上的對比 2012-03-26 15:37 墨魂
@陳梓瀚(vczh)
我是從一個類庫開始說,但并不是只是這一個類庫這樣。比如QT和GTK相比,明顯QT的效率要比GTK相比要低的多。我比較的重點只是運行的性能還有就是錯誤處理那一塊的效率,至于你說的那些優美與高效的寫法,如果與同樣的C實現相比,也不一定就見得高效與優美。
  回復  更多評論
  

# re: C和C++在兩個小問題上的對比[未登錄] 2012-03-27 09:12 Chipset
C語法和用法相對比較簡單,C++語法和用法相對復雜,或者說看你會不會用C++罷了。小程序比較快慢沒有意義,上下差不了幾個毫秒,可以看成誤差。我們還是比個比較大的程序吧,你覺得最新的Linux系統顯著比最新的Windows快嗎?前者是C寫的,后者是C++寫的。測試了很多項,都是常用的,除了文件讀寫外(EXT4對NTFS,個人覺得是格式問題),其它項Linux全軍覆沒。在Linux一個網站上比較的Ubantu和Win7,自己谷歌一下吧,我不解釋。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比[未登錄] 2012-03-27 09:43 Chipset
http://www.phoronix.com/scan.php?page=home
這里有很多比較,有硬件的,也有軟件的。
至于你文中提到的C++拋出異常,我真想知道有多大開銷,問題是你拋什么異常,怎么拋異常,怎么處理異常。根據經驗,異常處理會難倒很多C++老手,所以我懷疑你怎么使用異常,會不會很好的使用。
C語言穩居什么排行榜的事情跟效率有關嗎?既然C那么好用為何比排名第一呢?你不覺得你那種論斷荒唐嗎?
至于你提到的圖形庫,GTK+和QT,這玩意怎么比呀。作出的圖形不同的畫質計算量會千差萬別。都是用C寫的界面,GNOME和XFCE速度相差很大,這怎么解釋。即使如此,KDE也未必比Gnome慢哪里去,還在上面那個鏈接,你自己看。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比 2012-03-27 11:53 zjh
@Chipset
誰告訴你windows是用c++編寫的,windows內核也是用c和匯編寫的  回復  更多評論
  

# re: C和C++在兩個小問題上的對比[未登錄] 2012-03-27 12:43 Chipset
唉,我說樓上的那位。Win內核是用C++寫的,少量Intel匯編,你去問微軟的架構師好了,我不解釋。。。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比 2012-03-27 12:53 墨魂
@Chipset
ubuntu并不能代表LINUX,它只是一個類似WINDOWS的傻瓜化的操作系統。
WINDOWS和INTEL的聯盟使得WINDOWS針對x86平臺進行優化,但LINUX沒有這樣的支持,而且linux要支持各種硬件平臺,所以代碼要盡量通用,可移植,當然在某些方面比不過只做x86的windows.  回復  更多評論
  

# re: C和C++在兩個小問題上的對比[未登錄] 2012-03-27 12:54 Chipset
@zjh
順便給你掃盲一下吧。微軟的所有產品(除了.net框架的一部分基類用了C#),其余是一色的C++程序,就連C#編譯器都不例外,當然了,個別地方有點Intel匯編。
若干年前Windows Phone上嘗試了一下用C#寫了個軟鍵盤程序,發現速度太慢,最終只好又退回到C++。DOS是用匯編寫的,從Win95以后,都是C++代碼外加少量匯編。Win2K的代碼泄漏過一次,不知道現在網上是否還能下載到,是用C++寫的,這個能看到。

不要覺得WinAPI是些C代碼就認為Win內核是用C寫的,你可以去問微軟的架構師。。。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比 2012-03-27 12:59 墨魂
@Chipset
KDE的內存占用要比Gnome大很多,這是我自己測得的結果。如果KDE真如你說的那么好,各大發行版為什么都默認的是GNOME而不是KDE,連SUSE在12.1都是。C不是第一,只是因為相對于JAVA來說,C還是太難。愿意學下去的太少。不過3月分的語言排行榜你應該看過,JAVA--17.110%,比上月下滑2.60%,C占
17.087%,上漲1.82%,這總不會是無緣無故的。C++8.074%,下滑0.71%,并不說C++不好,只是有太多自以為是的C++程序員了。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比[未登錄] 2012-03-27 13:31 Chipset
@墨魂
唉,那個排名能說明個啥呀,跟效率沒關系是不是?
其實C++和C速度上沒差別,你可以看下struct和class的內存布局,內存布局都一樣,哪來的速度差別呀。。。
C++唯一慢的地方是虛函數(C沒有),需要查虛表,就一兩條指令的開銷帶來的好處是不言而喻的。。。
至于Gnome和KDE,畫面質量不同,內存和計算量相差那么大,比速度和內存有意思嗎?你咋不拿控制臺給Metro比速度和內存呀。。。
C++是有很多缺點被很多人指責,編譯慢,語法太復雜,新手很容易寫出爛代碼。。。這都是真的,但是不恰恰說明很多人在用C++嗎?否則怎么可能發現這么多問題呢。。。就如同我們天天罵windows一樣,你見過幾個人罵Linux?沒有幾個人用,哪里能發現那么多問題。。。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比[未登錄] 2012-03-27 13:35 Chipset
@墨魂
如果你還要比,我還能給你舉出更多例子說明C++比C快,耗費內存也少,如果有人說C++比C快耗費內存少,我同樣也能舉出很多反面的例子。。。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比 2012-03-27 15:13 zjh
@Chipset
你是不是想說微軟的C編譯器和鏈接器也是c++寫的?,操作系統內核從來也沒有用c++寫過,注意是內核,不是操作系統,windows是微內核。
不巧,我還真有win2k的源代碼,要不要貼上來讓你看看? 先給自己掃盲吧  回復  更多評論
  

# re: C和C++在兩個小問題上的對比[未登錄] 2012-03-27 16:13 Chipset
@zjh
建議你谷歌一下吧,或問微軟的架構師,感覺這玩意沒啥好爭論的。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比[未登錄] 2012-03-27 16:31 Chipset
就說NT吧,不是微(micro)內核,也不是單(monolithic)內核,應該算Hybrid。你可以搜索到NT架構,我也不清楚你說哪一部分。HAL層我估計應該用匯編,據說這些匯編主要來自一個祖籍臺灣人的貢獻(你可以了解一下微軟的歷史,那幾個技術鼻祖)。再上面一層(Kernel mode drivers 和 micro kernel),古老的代碼應該是C寫的,后來改寫的代碼是C++的,再上面也是這樣,古老的代碼是C的,后來的是C++的。其實不僅Windows,Office也是這樣的,最古老的代碼是匯編,后來的用C,C++出現以后所有的新東西都用C++來寫。你不是有win2k代碼嗎,你最好找到我說的那一層看看是不是這樣。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比 2012-03-27 16:48 Chipset
@zjh
這里有個簡要的圖和介紹,我不明白你指代那一部分:
http://en.wikipedia.org/wiki/Architecture_of_Windows_NT

用C++寫操作系統內核不是新聞,用Java寫的都有。。。

這里有用什么語言編寫的介紹:
http://www.lextrait.com/vincent/implementations.html
這里也可以查到:
http://www2.research.att.com/~bs/applications.html
  回復  更多評論
  

# re: C和C++在兩個小問題上的對比 2012-03-27 17:48 墨魂
@Chipset
GNOME和KDE的差別有多大,你如果真的拿命令行和win8的那個什么界面比。我也沒什么可說的。GNOME3.2和KDE4.7是差不多同時的產品,你自己可以去看他們之間究竟是不是有你所說的那么大的差別。

你之前說排名沒用,現在又來說C++有那么多人用,那這又有什么用?我覺得排名里C++不斷下滑是有原因的,你若覺得沒什么問題也罷。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比 2012-03-27 19:19 zjh
@Chipset
你說什么就是什么吧,反正我手里的win2k源代碼不是c++的,難道是盜版?
java寫操作系統,是畢業設計么? 也許等到芯片的計算能力大大提高后,可以吧java虛擬機固化到芯片,就可以用java寫操作系統
摘錄一段代碼
VOID
KiInitSystem (
VOID
)

/*++

Routine Description:

This function initializes architecture independent kernel structures.

Arguments:

None.

Return Value:

None.

--*/

{

ULONG Index;

//
// Initialize dispatcher ready queue listheads.
//

for (Index = 0; Index < MAXIMUM_PRIORITY; Index += 1) {
InitializeListHead(&KiDispatcherReadyListHead[Index]);
}

//
// Initialize bug check callback listhead and spinlock.
//

InitializeListHead(&KeBugCheckCallbackListHead);
KeInitializeSpinLock(&KeBugCheckCallbackLock);

//
// Initialize the timer expiration DPC object.
//

KeInitializeDpc(&KiTimerExpireDpc,
(PKDEFERRED_ROUTINE)KiTimerExpiration, NIL);

//
// Initialize the profile listhead and profile locks
//

KeInitializeSpinLock(&KiProfileLock);
InitializeListHead(&KiProfileListHead);

//
// Initialize the active profile source listhead.
//

InitializeListHead(&KiProfileSourceListHead);

//
// Initialize the timer table, the timer completion listhead, and the
// timer completion DPC.
//

for (Index = 0; Index < TIMER_TABLE_SIZE; Index += 1) {
InitializeListHead(&KiTimerTableListHead[Index]);
}

//
// Initialize the swap event, the process inswap listhead, the
// process outswap listhead, the kernel stack inswap listhead,
// the wait in listhead, and the wait out listhead.
//

KeInitializeEvent(&KiSwapEvent,
SynchronizationEvent,
FALSE);

InitializeListHead(&KiProcessInSwapListHead);
InitializeListHead(&KiProcessOutSwapListHead);
InitializeListHead(&KiStackInSwapListHead);
InitializeListHead(&KiWaitInListHead);
InitializeListHead(&KiWaitOutListHead);

//
// Initialize the system service descriptor table.
//

KeServiceDescriptorTable[0].Base = &KiServiceTable[0];
KeServiceDescriptorTable[0].Count = NULL;
KeServiceDescriptorTable[0].Limit = KiServiceLimit;
#if defined(_IA64_)

//
// The global pointer associated with the table base is
// placed just before the service table.
//

KeServiceDescriptorTable[0].TableBaseGpOffset =
(LONG)(*(KiServiceTable-1) - (ULONG_PTR)KiServiceTable);
#endif
KeServiceDescriptorTable[0].Number = &KiArgumentTable[0];
for (Index = 1; Index < NUMBER_SERVICE_TABLES; Index += 1) {
KeServiceDescriptorTable[Index].Limit = 0;
}

//
// Copy the system service descriptor table to the shadow table
// which is used to record the Win32 system services.
//

RtlCopyMemory(KeServiceDescriptorTableShadow,
KeServiceDescriptorTable,
sizeof(KeServiceDescriptorTable));

//
// Initialize call performance data structures.
//

#if defined(_COLLECT_FLUSH_SINGLE_CALLDATA_)

ExInitializeCallData(&KiFlushSingleCallData);

#endif

#if defined(_COLLECT_SET_EVENT_CALLDATA_)

ExInitializeCallData(&KiSetEventCallData);

#endif

#if defined(_COLLECT_WAIT_SINGLE_CALLDATA_)

ExInitializeCallData(&KiWaitSingleCallData);

#endif

return;
}
  回復  更多評論
  

# re: C和C++在兩個小問題上的對比[未登錄] 2012-03-28 09:20 Chipset
@zjh
Java寫系統還真有,也不是什么畢業設計。你可以谷歌下JNode,除了一點匯編,其它全是用Java寫的。
至于你說把虛擬機固化到芯片里,雖然我沒見哪家這么干,但是我確實聽說有的ARM芯片可以直接執行字節碼。

我們做嵌入式,芯片的計算能力非常有限,內存也跟臺式機沒得比,是很在乎資源消耗的。以前一直認為C++比C慢很多,耗費資源也多,關于C和C++之間的速度差別查閱了很多資料,評測過N次,發現幾乎沒啥差別。

C++的缺點是很明顯的,新手很容易寫出垃圾代碼,速度慢耗費內存多,但優點也很明顯。我們目前做的一個程序大約2百萬行源代碼,C++代碼大約90%以上,C代碼大約5%,還有1%不到的Lua。如果C++的部分也用C來做,你想想源代碼量會有多大,維護起來會有多痛苦...  回復  更多評論
  

# re: C和C++在兩個小問題上的對比[未登錄] 2012-03-28 09:33 Chipset
@墨魂
Gnome和Xfce都用C,但是速度差別那么大怎么解釋?很多事情跟語言關系不大對不對。再舉個例子,Chrome,FireFox,IE都用C++來寫,速度和資源消耗是不是也差別很大?這又怎么解釋?
我再舉個例子吧,MTL聽說過吧,做計算的。做數值計算,C和C++沒法跟Fortran比速度,同樣的算法,速度得差20%,但是MTL開發出來后,尤其4.0以后把Fortran都秒飛了,你能說C++不行?那為啥不用C來做,如果C真的那么快?

任何語言都有優點和缺點,否則某種語言早就一統江湖了。。。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比 2012-03-28 11:17 墨魂
@Chipset
我沒有說過C就一定比C++好,問題都是在庫的設計上,C++的庫設計的不好會有性能損耗,設計的好的話跟C比也會很多優勢。

MTL是很好,但沒有用C來做 就不是說用C不行。只是剛好這個庫用C++來寫了而已。  回復  更多評論
  

# re: C和C++在兩個小問題上的對比[未登錄] 2012-03-28 16:04 Chipset
@墨魂
Gnome和KDE都是應用,Linus Torvalds也在公開場合說過KDE做的很不錯,否則在那個C的世界KDE早死了。

Qt的版本升級很快,看來很多人在用(如果沒幾個人用那還有必要頻繁升級嗎?)再想想Qt商業應用得花錢買版權,如果Qt跟GTK+比真的那么差,誰愿意花錢買不好的東西呢?用免費的GTK+(C)或gtkmm(給C++用)豈不更好?

順便說下zjh貼的那段代碼,我真看不出是C的。C89和C94沒有//的注釋符號,C99的規定是何年月啦,微軟的編譯器哪里能升級那么快?Win2K能趕得上嗎?  回復  更多評論
  

# re: C和C++在兩個小問題上的對比 2012-03-28 16:33 墨魂
@Chipset
QT主要是功能較為豐富,而GTK+主要是做界面。再者KDE出來的比較早,GNOME只是不滿于KDE的設計而成立的。所以單論界面來說,GNOME并不比KDE差,再者KDE設計的太過復雜,并不符合一般用戶的使用習慣,所以GNOME會后來居上。  回復  更多評論
  

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            久久亚洲一区| 亚洲一区二区精品在线| 免费亚洲电影在线| 久久gogo国模裸体人体| 亚洲在线成人精品| 亚洲主播在线观看| 久久男女视频| 欧美女同视频| 国产一区二区三区最好精华液| 好吊一区二区三区| 亚洲午夜未删减在线观看| 性色av一区二区三区在线观看 | 久久亚洲色图| 亚洲精品精选| 久久久久久91香蕉国产| 欧美日韩国产综合视频在线观看中文 | 欧美h视频在线| 欧美精品在线免费播放| 国产精品亚洲片夜色在线| 亚洲美女少妇无套啪啪呻吟| 久久国产精品亚洲va麻豆| 欧美激情亚洲精品| 久久久久国产一区二区三区四区 | 狠狠v欧美v日韩v亚洲ⅴ| 亚洲免费视频中文字幕| 亚洲精品国产无天堂网2021| 久久人91精品久久久久久不卡 | 国产精品激情| 韩国成人理伦片免费播放| 亚洲女女女同性video| 亚洲精品视频免费| 狠狠久久婷婷| 久久疯狂做爰流白浆xx| 亚洲综合日韩在线| 国产乱码精品一区二区三区五月婷| 亚洲一区二区三区精品在线观看| 亚洲国产日韩欧美一区二区三区| 久久精品国产清高在天天线| 国产一区二区黄色| 美女露胸一区二区三区| 美女视频黄 久久| 亚洲精品乱码视频| 一区二区三区四区在线| 夜夜精品视频| 国产亚洲激情| 欧美国产三级| 国产精品成人v| 裸体丰满少妇做受久久99精品| 久久久精品免费视频| 一本色道精品久久一区二区三区 | 亚洲精品一区二区三区蜜桃久| 欧美日韩一区在线| 久久综合久久久久88| 欧美色另类天堂2015| 欧美成人综合| 国产视频欧美| 一本久道久久综合狠狠爱| 亚洲黄色免费| 久久精品亚洲一区二区| 欧美一区二区日韩| 欧美日韩一区二区三区在线看| 欧美va亚洲va国产综合| 国产欧美一区二区三区国产幕精品| 亚洲日本无吗高清不卡| 亚洲黄色成人久久久| 免费不卡亚洲欧美| 欧美福利在线| 亚洲精品一区二区在线观看| 久久精品夜色噜噜亚洲aⅴ| 久久精品日韩一区二区三区| 国产精品男人爽免费视频1| 日韩一区二区精品葵司在线| 一本色道久久加勒比精品| 美国成人毛片| 亚洲精品久久| 欧美亚洲视频在线看网址| 国产欧美日韩视频一区二区| 亚洲欧美网站| 狠狠色丁香婷婷综合| 欧美激情精品久久久久久| 亚洲久久成人| 久久精品国产99精品国产亚洲性色| 国产情侣久久| 欧美激情精品久久久久久| 日韩午夜精品| 欧美成人a视频| 香蕉亚洲视频| 在线视频日本亚洲性| 国产综合视频在线观看| 母乳一区在线观看| 性做久久久久久久久| 亚洲区一区二区三区| 久久精品亚洲精品国产欧美kt∨| 亚洲精品国产精品国自产观看| 欧美色图麻豆| 欧美日本簧片| 另类综合日韩欧美亚洲| 亚洲欧美一区二区激情| 一区二区三区国产精华| 亚洲第一偷拍| 久久中文字幕导航| 裸体一区二区三区| 久久久久久久久伊人| 亚洲欧美日韩在线高清直播| 在线亚洲免费| 一区二区三区.www| 亚洲免费一级电影| 日韩视频在线一区二区三区| 亚洲经典三级| 亚洲美女免费视频| 亚洲视频在线视频| 午夜久久资源| 免费91麻豆精品国产自产在线观看| 午夜久久美女| 久久亚洲欧美| 亚洲第一成人在线| 99国产一区| 性久久久久久| 久久人人97超碰国产公开结果| 欧美电影免费| 宅男精品视频| 老司机精品导航| 国产精品视频久久久| **性色生活片久久毛片| 一区二区成人精品 | 国产精品美女视频网站| 国产乱码精品一区二区三区忘忧草 | 亚洲女性裸体视频| 久久久久久一区二区| 亚洲激情欧美激情| 久久国内精品自在自线400部| 麻豆成人在线观看| 国产一区二区日韩| 亚洲视频一区二区免费在线观看| 免费不卡欧美自拍视频| 亚洲私拍自拍| 国产一区二区日韩精品欧美精品| 午夜亚洲影视| 麻豆精品一区二区av白丝在线| 欧美激情2020午夜免费观看| 国产午夜精品麻豆| 亚洲一区二区三| 亚洲高清av在线| 欧美亚洲一区二区三区| 国产精品国产三级国产专播品爱网 | 国产精品亚洲产品| 亚洲人体偷拍| 国产欧美日本一区二区三区| 亚洲精品少妇30p| 亚洲第一精品福利| 欧美成人情趣视频| 亚洲激情亚洲| 亚洲精品中文在线| 国产精品嫩草影院av蜜臀| 午夜精品在线观看| 久久国产黑丝| 亚洲高清一区二| 亚洲作爱视频| 欧美日韩国产综合在线| 亚洲免费视频成人| 亚洲国产精品悠悠久久琪琪| 开心色5月久久精品| 欧美电影免费网站| 性欧美8khd高清极品| 欧美在线视频一区| 亚洲精品欧美| 欧美在线不卡| 在线视频亚洲| 久久精品国产免费| 亚洲网站视频福利| 欧美一区二区三区的| 亚洲一区中文字幕在线观看| 久久免费视频观看| 欧美在线视频网站| 欧美日韩中文| 亚洲乱码国产乱码精品精天堂| 国产亚洲精品一区二555| 亚洲人成网站在线播| 亚洲国产va精品久久久不卡综合| 99riav1国产精品视频| 亚洲日本va午夜在线电影| 久久综合九色九九| 久久蜜桃av一区精品变态类天堂| 国产精品第一页第二页第三页| 亚洲乱码国产乱码精品精| 在线国产精品一区| 美乳少妇欧美精品| 欧美成人视屏| 一区二区三区免费网站| 欧美区一区二| 一本不卡影院| 欧美亚洲网站| 伊人春色精品| 久久免费黄色| 极品尤物av久久免费看| 久久久人成影片一区二区三区观看| 久久蜜桃精品| 亚洲欧洲一区二区三区久久| 欧美精品久久一区二区| 中文亚洲视频在线|