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

Where there is a dream ,there is hope

  C++博客 :: 首頁 :: 聯系 :: 聚合  :: 管理
  64 Posts :: 0 Stories :: 8 Comments :: 0 Trackbacks

常用鏈接

留言簿(1)

我參與的團隊

搜索

  •  

最新評論

閱讀排行榜

評論排行榜

#

最近看代碼的時候發現不少do {} while(0)的用法,在網上找到了篇比較詳細的文章:
原文鏈接:http://www.cnblogs.com/flying_bat/archive/2008/01/18/1044693.html

1. do...while(0)消除goto語句。
通常,如果在一個函數中開始要分配一些資源,然后在中途執行過程中如果遇到錯誤則退出函數,當然,退出前先釋放資源,我們的代碼可能是這樣:

bool Execute()
{
   
// 分配資源
   int *= new int;
   
bool bOk(true);

   
// 執行并進行錯誤處理
   bOk = func1();
   
if(!bOk) 
   
{
      delete p;   
      p 
= NULL;
      
return false;
   }


   bOk 
= func2();
   
if(!bOk) 
   
{
      delete p;   
      p 
= NULL;
      
return false;
   }


   bOk 
= func3();
   
if(!bOk) 
   
{
      delete p;   
      p 
= NULL;
      
return false;
   }


   
// .

   
// 執行成功,釋放資源并返回
    delete p;   
    p 
= NULL;
    
return true;
   
}

改用do {}while(0)結構后,是這樣:
bool Execute()
{
   
// 分配資源
   int *= new int;

   
bool bOk(true);
   
do
   
{
      
// 執行并進行錯誤處理
      bOk = func1();
      
if(!bOk) break;

      bOk 
= func2();
      
if(!bOk) break;

      bOk 
= func3();
      
if(!bOk) break;

      
// .

   }
while(0);

    
// 釋放資源
    delete p;   
    p 
= NULL;
    
return bOk;
   
}

2 宏定義中的do...while(0)
  如果你是C++程序員,我有理由相信你用過,或者接觸過,至少聽說過MFC, 在MFC的afx.h文件里面, 你會發現很多宏定義都是用了do...while(0)或do...while(false), 比如說:
#define AFXASSUME(cond)       do { bool __afx_condVal=!!(cond); ASSERT(__afx_condVal); __analysis_assume(__afx_condVal); } while(0)
粗看我們就會覺得很奇怪,既然循環里面只執行了一次,我要這個看似多余的do...while(0)有什么意義呢?
當然有!
為了看起來更清晰,這里用一個簡單點的宏來演示:
#define SAFE_DELETE(p) do{ delete p; p = NULL} while(0)
假設這里去掉do...while(0),
#define SAFE_DELETE(p) delete p; p = NULL;
那么以下代碼:
if(NULL != p) SAFE_DELETE(p)
else   ...do sth...

就有兩個問題,
1) 因為if分支后有兩個語句,else分支沒有對應的if,編譯失敗
2) 假設沒有else, SAFE_DELETE中的第二個語句無論if測試是否通過,會永遠執行。
你可能發現,為了避免這兩個問題,我不一定要用這個令人費解的do...while,  我直接用{}括起來就可以了
#define SAFE_DELETE(p) { delete p; p = NULL;}
的確,這樣的話上面的問題是不存在了,但是我想對于C++程序員來講,在每個語句后面加分號是一種約定俗成的習慣,這樣的話,以下代碼:
if(NULL != p) SAFE_DELETE(p);
else   ...do sth...

其else分支就無法通過編譯了(原因同上),所以采用do...while(0)是做好的選擇了。

也許你會說,我們代碼的習慣是在每個判斷后面加上{}, 就不會有這種問題了,也就不需要do...while了,如:
if(...)
{
}
else
{
}

誠然,這是一個好的,應該提倡的編程習慣,但一般這樣的宏都是作為library的一部分出現的,而對于一個library的作者,他所要做的就是讓其庫具有通用性,強壯性,因此他不能有任何對庫的使用者的假設,如其編碼規范,技術水平等。 

posted @ 2010-11-24 09:46 IT菜鳥 閱讀(318) | 評論 (0)編輯 收藏

1.c++ unsigned char
C#中的char是16bits的Unicode字符,而一般C++中的字符則是8位的,所以C++中的“unsigned   char”在C#中要么轉換成char,要么使用Byte類型來代替,前者適用于存放字符型的unsigned   char,后者適用于整數型的unsigned   char。
2.
unsigned int    == nint32
unsigned short== nint16
posted @ 2010-11-24 09:38 IT菜鳥 閱讀(428) | 評論 (0)編輯 收藏

先看一段宏
#ifdef HSCRIPTDEBUG_EXPORTS
    
#define HSCRIPTDEBUG_API __declspec(dllexport)
#else
    
#define HSCRIPTDEBUG_API __declspec(dllimport)
#endif
 class HSCRIPTDEBUG_API ScriptDebug
 
{
 
public:

   }
;
__declspec(dllexport)用于導出符號,也就是定義該函數的dll;
__declspec(dllimport)用于導入,也就是使用該函數。

因為這個頭文件既要被定義該函數的dll包含,也要被使用該函數的程序包含,當被前者包含時我們希望使用__declspec(dllexport)定義函數,當被后者包含時我們希望使用dllimport。于是我們使用
#ifdef _EXPORTING
#define CLASS_DECLSPEC __declspec(dllexport)
#else
#define CLASS_DECLSPEC __declspec(dllimport)
#endif
這種技巧,在定義該函數的dll中,其編譯選項定義了_EXPORTING而使用該函數的程序則沒有定義。

__declspec(dllimpot)如果要是類中有靜態變量的話,是必須有這個的。


posted @ 2010-11-17 15:38 IT菜鳥 閱讀(305) | 評論 (0)編輯 收藏

原文地址:http://www.comicer.com/stronghorse/water/software/ZipRar.htm



一、目錄表(TOC)與分卷(Volume)

拋開壓縮算法不談,我認為zip、rar在文件格式上最大的差異就在目錄表(Table of Contents,TOC):zip有TOC,而rar沒有。

TOC這個詞其實是從出版界借用過來的,指的就是每一本書正文前面的“目錄”,它的作用地球人都知道:如果想快速找到書中某一內容,可以先查TOC,然后按照TOC指明的頁碼直接翻即可。

在紙質書里TOC是印刷出來的一張表,而在電子文件里則是由結構化數據構成的一張表,它的目的同樣是為了快速定位:如果想找文件中的某一內容,可以先查TOC,知道感興趣的內容在文件的什么位置,直接跳過去就行了。最常見的運用就是avi、rm等多媒體文件:播放的時候經常有人在播放條上點來點去跳著看(即“隨機訪問”),如果沒有TOC,在長達幾百兆的文件里來回定位會慢死。

具體到zip文件里,TOC是放在文件尾部的一張表,里面列出了zip包中每一個文件的屬性(文件名、長度等)和在zip包中的存放位置。如果需要隨機訪問zip包中的某一個文件,只需在TOC里找到這個文件的存放位置,直接跳過去即可。

而RAR文件里則沒有TOC,在文件頭之后所有文件按順序連續存放。

這種差異造成的結果就是:隨機訪問時zip比rar快,而順序訪問時rar比zip快。

所謂隨機訪問,就是前面說過的隨機訪問壓縮包中某個指定的文件。舉一個簡單的例子:一本反編譯或下載到的網頁電子書,有大量HTML、圖像、css、js,然后打成壓縮包。現在要求在不解包的情況下訪問其中的頁面:可以想象,打開每個HTML頁面的時候,它所附帶的圖像、css、js等文件可能隨機分布在整個壓縮包里,如果沒有TOC,查找每個文件的時候都要從頭開始找,將會有多慢。 所以各位可以理解為什么jar包就是標準zip包,而我也只用zip格式保存反編譯出來的電子書、漫畫、PDG書等一切可能需要隨機訪問的東西。

所謂順序訪問,就是將整個壓縮包從頭解到尾。在這方面RAR具有天然的優勢。而且為了節省WinRAR列文件的時間,對于單個RAR我一般都直接通過右鍵菜單解壓縮,很少雙擊壓縮包打開再解壓。解多個RAR時當然都用BatchUnRar。

由于rar的原作者已經去世,造成這種差異的確切原因我相信已不可考,但我個人猜測可能與DOS時代的備份軟件之爭有關:在DOS時代,電腦硬盤不像現在這樣奢侈,20MB就算很大了。這樣的容量用兩盒軟盤 即可備份,備份成本相對數據本身的價值來說非常低廉。因此在DOS時代,很多公司和機構都制定有定期硬盤備份政策,以免因為人為或非人為的因素 (早期硬盤可沒有如今可靠)而造成不可挽回的數據損失。在備份軟件方面,雖然微軟已經隨DOS提供了Backup/Restore工具,但是他們基本不具備數據壓縮能力,因此在壓縮軟件中提供備份功能,就成為DOS時代的一個時尚。由于DOS時代的備份介質多為軟盤,因此壓縮 軟件的備份功能其實就轉化成如今很常見的一個功能:分卷壓縮功能,即按照軟盤容量進行分卷壓縮,然后將分卷壓縮文件備份(Backup)到軟盤,需要的時候再解壓,或恢復(Restore)到硬盤。

DOS時代最有名的zip工具是pkzip,出現得比DOS版的RAR早。在分卷壓縮時,pkzip按照zip文件規范,將TOC存放在最后,即存儲在最后一卷,由此帶來如下問題:

1、恢復時,每解壓一張盤,都要先將最后一張盤插進去一次,讀一次TOC。
2、只要最后一張盤上的TOC壞了,就算其它盤都是好的,也不能正常解壓。

這兩個缺點,尤其是第一個缺點實在是太臭名昭著了,因此當時出現了非常強烈的改革呼聲。在這個關鍵時刻,DOS版的RAR出現了:不僅壓縮率比pkzip高(這點在DOS時代非常重要,畢竟軟盤又貴容量又小),而且由于吸取了當時對zip格式的批評,取消了TOC,因此:

1、在恢復分卷壓縮的備份文件時,不需要頻繁插入帶有TOC的分卷,按順序換盤即可。
2、即使某個分卷損壞,也可以跳過,從完好的分卷再開始解壓。

由于這些原因(當然還有其它原因),RAR推出后迅速取得了成功,pkzip在DOS時代就開始流失用戶,到Windows時代基本消聲匿跡。在Windows時代推出的Winzip,則徹底放棄了分卷壓縮功能(zip格式永遠的痛?)。 而從我看到的源自WinRAR的UnRAR源代碼來看,現在WinRAR的解壓思路明顯還是把文件按順序從頭解到尾,看來當年備份/恢復工具之爭的影響,還真是深遠。

二、固實(solid)壓縮方式

在壓縮算法方面,我覺得rar格式最特色的是固實(solid)壓縮方式。WinRAR v3.42的幫助文件中對固實壓縮的說明如下:

固實壓縮文件是 RAR 的一種特殊壓縮方式存儲的壓縮文件,它把壓縮文件中的全部文件都當成一個連續數據流來看待。

這段說明其實揭示了固實壓縮格式能夠提高壓縮比的奧秘:數據壓縮的基礎是“重復”,例如aaaabbb這個字符串,里面就有重復,如果表示為a4b3,看起來是不是變短了?這就是“數據壓縮”。“重復”是一個具有相對意義的概念,在某一范圍內看起來沒有重復,或重復不多的數據,把范圍擴大,說不定就能找到更多重復的數據了,這就是固實壓縮的奧秘。

舉一個簡單的例子:用zip和普通rar壓縮一堆jpg文件,很難壓下去,但是用固實壓縮方式的rar就可以,其原因就在于:jpg文件本身已經是壓縮格式了,單個jpg文件里很難再 找到可利用的重復數據,因此不論是用zip還是普通的rar都很難再壓縮,因為他們都將需要壓縮的文件分隔開來一個一個處理。但是對于固實rar來說,是將 所有需要壓縮的jpg文件當作一個整體來壓縮,這些jpg之間就存在重復的數據,如他們都有相同的文件頭(其中包括各種數據表)等,這就出現了可壓縮的空間。從我看到的資料來看,Flash文件也采用了類似的技術對jpg進行壓縮:如果在Flash文件中使用了多個jpg文件,它們可以共用一個文件頭。

當然天下不會有白吃的午餐,固實壓縮方式在提高壓縮比的同時,也有一些限制,在WinRAR v3.42幫助文件中的說法是:

固實壓縮可增加壓縮性能,特別是在添加大量的小文件的時候,但它也有一些重要的不利因素:

  • 對已存在的固實壓縮文件更新時較慢;
  • 要從固實的壓縮文件解壓單個文件時,它之前的文件都需先經過分析。這造成當從固實的壓縮文件內取出文件時會比一般壓縮文件取出文件慢一些。但是,當從固實的壓縮文件解壓全部的文件時,解壓速度并沒有影響。
  • 如果在固實壓縮文件中的任何文件損壞了,要從損壞的范圍中解壓全部的文件是不可能的。因此,如果固實壓縮文件是保存在例如軟盤等媒介時,推薦你在制作時使用“恢復記錄”。

固實壓縮的適用場合為:

  • 壓縮文件很少更新的時候;
  • 不需要經常從壓縮文件中解壓一個文件或是部分文件的時候;
  • 壓縮效率比壓縮速度更為重要的時候。

與前面說的“隨機訪問”對應,固實壓縮的RAR文件可能是世界上最不適合隨機訪問的:如果需要訪問固實RAR包中的某個文件,就要從文件頭開始解壓,一直解到這個文件。

三、安全性

這里的安全性包含幾個方面的含義:文件系統安全性、密碼保護安全性和文件數據安全性。

由于制訂zip格式規范的時候操作系統本身的文件安全性還沒有引起足夠的重視,因此zip格式只記錄最基本的文件屬性,包括只讀屬性等,沒有其它附加的安全屬性。

rar格式剛推出的時候,文件系統的安全性只能參照DOS,和zip差不多。但是rar畢竟是一種封閉的格式,想怎么改作者一個人說了就算,因此當Windows中出現NTFS,并且引入擴展的文件系統安全屬性時,rar也積極跟進,所以現在應該說rar格式在這方面比zip強 。

在zip和rar格式中均提供了密碼保護功能,但是密碼保護的安全強度不同。

zip由于格式開放、代碼開源,因此zip密碼破解軟件出現得比較早,也比較多。初期以暴力破解為主,威脅不大,真正對zip密碼安全的致命一擊是known plain text(已知明文)攻擊法:如果知道加密zip文件中某段內容(密文,ciphertext)解密后的真正內容(明文,plain text),就可以反推出zip加密口令。在這種攻擊方法的威脅,及某些國家的法律對密碼技術的限制下, 著名開源組織zlib宣布永久放棄對加密zip的支持,詳見zlib網站上的相關說明(不過在zlib發行的源代碼里仔細找找,還是能找到原來的加/解密相關代碼)。

記得rar剛推出的時候也和zip一樣,雖然不能列出加密文件中的文件內容,但可以列出加密文件中的文件名。后來大概也是被known plain text攻擊法嚇到了,增加了一個“加密文件名”選項,干脆連加密rar文件里有哪些文件都看不見,讓攻擊者想猜明文都無從猜起。

rar格式比zip晚推出,在安全方面吸取了足夠的教訓,因此采用的是美國國家標準與技術局(National Institute of Standard and Technology, NIST)推薦的、目前公認安全程度比較高的AES對稱加密算法 ,密鑰長度128位。在ASE被攻破以前(NIST認為30年內無法攻破),大家都只能在暴力法上兜圈子,所以密碼安全性應該說比zip高。對此WinRAR 3.42的幫助文件是這樣描述的:

ZIP 格式使用私有加密算法。 RAR 壓縮文件使用更強大的 AES-128 標準加密。如果你需要加密重要的信息,選擇 RAR 壓縮文件格式會比較好一些。為了確實的安全性,密碼長度請最少要 8 個字符。不要使用任何語言的單詞作為密碼,最好是任意的隨機組合字符和數字,并且要注意密碼的大小寫。請記住,如果你遺失你的密碼,你將無法取出加密的文件,就算是 WinRAR 的作者本身也無法解壓加密過的文件。

在數據安全性方面,RAR格式本身支持一種特殊的附加信息類型,叫做“恢復記錄”。如果RAR文件有恢復記錄,在介質物理損壞或其它原因造成數據丟失時,WinRAR可以按照“恢復記錄”嘗試對數據進行修復。而zip格式無恢復記錄,因此在數據安全性方面應該說比RAR弱。

雖然RAR文件本身支持恢復記錄,但是在WinRAR里此選項缺省是關閉的,而打開后會導致壓縮出來的RAR文件體積增加(增加的百分比與設置有關),可能會令某些人感到不習慣(我就親眼見到有人在論壇上抱怨為什么壓出來的RAR文件會如此龐大),所以這個功能基本上形同虛設。

四、開放性

開放性的對比很明顯:zip格式不僅文件格式完全公開,而且有專門的開源組織提供操作源代碼,跨平臺使用也沒有多大限制;rar格式完全保密,作者只提供解壓所需源代碼,不提供壓縮所需源代碼 ,跨平臺使用有點麻煩。

zip開源組織中,最出名的是zlibInfoZip,二者各有側重:zlib偏重對內存緩沖區的壓縮,因此被png等開源組織用做內部壓縮算法,連java的jar程序內核都來自zlib,打出來的jar包自然也是一個標準的zip文件;InfoZip偏重對文件的操作 (包括口令保護),應用似乎不如zlib廣泛,但我個人覺得其實它還是滿好用的,前提是需要對它的源代碼進行一些必要的修改。

png組織的網頁中有說到png格式的來歷,我覺得也很有意思:做png的一班人,其實原來都是做gif格式的,但是由于Unisys公司開始對gif格式的核心——LZW壓縮算法征收專利費,這幫人怒了,干脆提出png格式:大結構方面還是采用分段結構,但是核心壓縮算法采用開源的zlib,壓縮 效果在多數情況下比gif的LZW更強。由于沒有版權限制,在靜態圖形領域png得到廣泛應用,如果不是及時提出動畫支持并因此在web上大行其道,我估計gif早就死掉了。

RAR的解壓源代碼在其官方網站www.rarlab.com上提供,通常比WinRAR的正式版本晚一點,不過據說是直接從WinRAR的源代碼中摳出來的,所以兼容性應該沒有什么問題。

五、結論

以下觀點純屬個人觀點,僅供參考,不具有如何指導意義:

  • 如果經常需要對壓縮包進行隨機訪問,應該選zip而不是rar。雖然將下載到的rar重新壓縮成zip會麻煩一次,但是以后會減少無數的麻煩。
  • 如果需要分卷壓縮(如某些網站對上傳文件大小有限制),則只能用rar。事實上,這也是我唯一會使用rar格式的場合,其它時候一律zip沒商量。
posted @ 2010-11-16 09:38 IT菜鳥 閱讀(585) | 評論 (0)編輯 收藏

http://monodevelop.com/Developers/Articles/The_Command_System#Menus_and_Toolbars
命令系統
本文闡述了Monodevelop命令系統的工作機制以及開發者如何利用這些優勢來寫自己的插件。

1?;靖拍?/strong>
在闡述Monodevelop命令系統的工作機制之前,我們先要了解兩件事
命令和使用這些命令的菜單和工具條是分開定義的
命令的執行是取決于上下文的,比如說你在文本編輯器中調用delete和在工程目錄樹中調用delete雖然都

是同一條命令,但是執行結果卻是不一樣的。
2。命令定義
命令都是要定義在"/MonoDevelop/Ide/Commands" 這個擴展點下面,如下:

<Command id = "MonoDevelop.Ide.Commands.ProjectCommands.Run"
    defaultHandler 
= "MonoDevelop.Ide.Commands.RunHandler"
    icon 
= "gtk-execute"
    shortcut 
= "F5"
    description 
= "Run"
    _label 
= "Run" />


id:命令的標識,注意:這個id一定要和已存在的枚舉類型的全名(包括命名空間)保持一致。這個枚舉

類型會被用來確定執行那個具體的命令。

defaultHandler:是用來標識執行當前上下文中默認的命令類

icon:在工具條和菜單欄中顯示的圖標

_lable: 在菜單欄上顯示的文本

description:顯示在tooltip上的文字(可選)

shortcut: 命令的快捷鍵

Toggle 命令
是用來在主文本旁邊顯示一個是否觸發狀態的命令,以及顯示工具欄是否激活的標識。這些命令用check

來標識。如下:

<Command id = "MonoDevelop.Ide.Commands.ProjectCommands.IncludeInBuild"
  type 
= "check"
 _label 
= "Build" />

 

如果有多個toggle命令相互排斥,那么你可以用radio類型來標識。
Custom commands 自定義命令
自定義命令用來展示在菜單和工具欄上的自定義的小窗體。如果要使用它,先將type屬性設置為custom然

后在widget標簽中指定相應的小窗體類。如下:

<Command id = "MonoDevelop.Ide.Commands.ProjectCommands.ConfigurationSelector"
    type 
= "custom"
    widget 
= "MonoDevelop.Ide.Gui.ConfigurationComboBox"
    _label 
= "Active Configuration" />

 

Command Arrays 命令組
命令組是用來實現菜單欄中的選擇列表。

<Command id = "MonoDevelop.Ide.Commands.WindowCommands.OpenWindowList"
    defaultHandler 
= "MonoDevelop.Ide.Commands.OpenWindowListHandler"
    type
="radio|array"
    _label 
= "Window List" />


注意:array和check可以同時使用,也可以和radio一起使用。一般來說,命令組用來動態的在菜單和工

具欄上產生命令。

<Command id = "MonoDevelop.Ide.Commands.FileCommands.RecentFileList"
     defaultHandler 
= "MonoDevelop.Ide.Commands.RecentFileListHandler"
     type
="array"
     _label 
= "Recent Files" />

 


3。菜單和工具條

Menus and Toolbars 菜單欄和工具條
菜單欄和工具條用相同的方式來定義。IDE提供了很多擴展點來定義主菜單,主工具條,如下:

CommandItem

Creates an item that will invoke the command identified by the id attribute. If the command

is actually a command array, it will create an item for each element in the command array.

SeparatorItem

ItemSet
創建一個item的字項菜單,它有兩個屬性_label和icon
用在工具欄上,那就是下拉式的

LinkItem
創建打開網絡連接的入口
Creates a menu or toolbar entry that opens a web page in the default web browser. For

example:

 

<LinkItem id = "MonoDevelop" _label = "MonoDevelop" link = "http://www.monodevelop.com" />

 

4。執行命令

執行命令
牢記:命令的執行和命令的上下文息息相關
那什么是上下文呢?上下文就是擁有焦點的窗體,當焦點改變的時候,上下文也隨之而變。命令集就跟著

變為可用或者不可用。
這意味這我們每一個窗體定義命令執行類了嗎?非也,每個widget都有一個command dispathcroute.dang

當調用一個命令的時候,如果具有焦點的widget沒有handler,那么它就會傳遞給route上的下一個對象,

也就是父widget
如下圖所示:

通常,command routes會按照下面這個順序來尋找:
*擁有焦點的widget
*父widget,直到root widget
*全局command Handler,使用這個來注冊:Ide.CommandServices.RegisterGlobalHandler(object)
*default handler:就是配置文件中的defaulterHandler

Implementing command handlers實現

 

[CommandHandler (FileCommands.Save)]
protected void OnSaveFile ()
{
     
// Do the save
}

 

FileCommands.Save是用來標記命令的枚舉值

Managing Command Status 更改命令狀態
打開monodevelop,新建一個文件,發現delete是禁用的,輸入一些字,發現它可用用了,點一些任務列

表,發現它又不可以用了。這是怎么做到的呢?
我們先要理解一件事:命令系統會自動禁用不是該command route上的命令.這是在焦點發生改變的時候發

生的。
如果命令的狀態依附于應用內部的邏輯結構,可用將它加入到一個特殊的Command Update Handler。

 

[CommandUpdateHandler (FileCommands.Save)]
protected void OnUpdateSaveFile (CommandInfo info)
{
    IViewContent content 
= window.ActiveViewContent as IViewContent;
    info.Enabled 
= content.IsDirty;
}

 

這條命令會在命令系統想要知道命令的狀態的時候調用。比如說菜單命令,當菜單要顯示的時候就調用,

工具欄是周期性的調用。

因為命令更新和命令是一體的,所以更新的方法要和執行的方法在一起寫。

在command update handler 中,你可以使用commandinfo對象來改變對象的狀態。但并不限于此,你可以

改變command的所有屬性,比如說描述文字,可見性等等。

Array command handlers

The default command handler

Startup Extension Path
這個特殊的commandhandler會在monodevelop啟動的時候調用的,你需要做兩件事。
首先,將你的class 比如說myhandler加入到啟動的擴展點,修改MonoDevelop.Ide.addin.xml 文件像這

樣:

<Extension path = "/MonoDevelop/Ide/StartupHandlers">
  
<Class class = "MyHandler"/>
</Extension>


接下來,完成這個類的實現

class MyHandler: CommandHandler
{
  
protected override void Run ()
  
{
    Console.Out.WriteLine(
"Hello World!");
  }
  
}

 

 

 

posted @ 2010-11-11 14:45 IT菜鳥 閱讀(962) | 評論 (0)編輯 收藏

     摘要:      轉來的一篇文章,沒找到原作者-------------------       在擔任公司高管的幾年間,我面試過數以百計的各個層面的員工,其中最讓我感到遺憾的一個現象就是很多人有著非常好的素質,甚至有的還是名校的畢業生,因為不懂得去規劃自己的職業,在工作多年后,依然拿著微薄的薪水...  閱讀全文
posted @ 2010-11-02 08:09 IT菜鳥 閱讀(425) | 評論 (0)編輯 收藏

一getchar()

1.

1char c;
2while((c = getchar()) != EOF){
3    putchar(c);
4}

5

輸入值:abc后面跟個回車
本以為屏幕應該顯示
a
a
b
b
c
c

實際上是:
abc
abc

這是因為只有當輸入回車時,系統才認為是輸入完畢

2.上面的代碼還有一個問題
因為EOF是-1,所以c=getchar()這一句會出現問題
所以c應該是int c

二、EOF

只有在新的一行輸入的時候輸入EOF才算是文件結束符
假設輸入:
abc^zqwer
輸出為:
abc

posted @ 2010-11-01 16:07 IT菜鳥 閱讀(265) | 評論 (0)編輯 收藏

1.目錄相關

.指當前目錄 例:~$ ./qq就是啟動當前目錄下的QQ程序

..指上一級目錄 例:~$ ../qq 就是啟動上一級目錄下的QQ程序

~指Home目錄 例如:~$ cd~ 就是回到HOME目錄
posted @ 2010-10-23 19:05 IT菜鳥 閱讀(273) | 評論 (0)編輯 收藏

今天用UBUNTU自帶的工具打開PDF,里面不能正常顯示文字。剛一開始以為是亂碼,仔細一觀察原來是所有的中文沒有顯示,英文都是正常的。折騰了半天終于搞定。原因是沒有安裝相關中文支持。
解決方法如下:

1. sudo apt-get install xpdf-chinese-simplified
2. sudo apt-get install xpdf-chinese-traditional (可選該項)

如果還不能正確顯示中文,可能缺少如下 所示工具包:

1. sudo apt-get install poppler-utils
2. sudo apt-get install poppler-data


本來經過上面兩步,基本就會正常顯示中文字體了,但是我的還是沒有顯示,不過有進步,以前是什么都沒有,現在是一個個的小方塊。GOOGLE后,終于找到了解決方案:修改配置文件。

執行命令:

sudo vi /etc/fonts/conf.d/49-sansserif.conf

打開后,找到這一行:

<edit name="family" mode="append_last"> 

將他下面的一行修改為:
<string>WenQuanYi Micro Hei</string>

WenQuanYi Micro Hei的意思就是:中文字體“文泉驛微米黑”。

再次打開PDF,終于可以正常顯示了。哈哈。


posted @ 2010-10-23 15:09 IT菜鳥 閱讀(994) | 評論 (0)編輯 收藏

1.GCC
UBUNTU自帶GCC,但是GCC還不能編譯文件,因為缺少一些頭文件。這里我們安裝build-essential這個軟件包。安裝了這個軟件包會自動安裝G
++,libc6-dev ,linux-libc-dev,libstdc6-4-1等一些必須的軟件和頭文件的庫。
命令:
sudo apt-get install build-essential

2.VIM
一個強大的文本編輯器(據說。。我也沒用過,大家都說好肯定有好的道理吧)
安裝命令:
sudo apt-get intall vim

3.第一個ubuntu程序
用VIM寫一個文本文件。
vim hello.c

這樣就建立了一個hello.c的程序,并進入編輯模式。
輸入以下代碼:
#include <stdio.h>
int main(void)
{
   printf(
"Hello ,this is my first program in ubuntu");
   
return 0;
}

編輯完畢,輸入:w保存文件。

編譯此文件:
gcc -Wall hello.c -o hello

運行命令:
./hello
屏幕上就會打印出那一行文字了。



posted @ 2010-10-23 13:27 IT菜鳥 閱讀(269) | 評論 (0)編輯 收藏

僅列出標題
共7頁: 1 2 3 4 5 6 7 
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            欧美精品首页| 久久在线精品| 国产亚洲一区二区三区在线观看| 欧美精品久久一区| 欧美剧在线观看| 欧美精品久久一区二区| 欧美另类变人与禽xxxxx| 欧美二区视频| 欧美日韩91| 国产欧美日韩精品一区| 激情久久五月| 99视频一区二区| 亚洲欧美中文日韩v在线观看| 亚洲欧美日韩精品在线| 欧美一区视频| 欧美成人免费播放| 99xxxx成人网| 国产一区999| 欧美一区二区三区免费在线看| 亚洲欧美一区二区激情| 久久精品72免费观看| 欧美xxx成人| 国产精品久久久久毛片大屁完整版| 国产手机视频精品| 日韩视频精品在线观看| 性欧美1819sex性高清| 蜜桃av综合| 亚洲亚洲精品在线观看| 玖玖国产精品视频| 国产精品美女xx| 亚洲国产另类精品专区| 香蕉尹人综合在线观看| 欧美激情亚洲综合一区| 亚洲欧美区自拍先锋| 欧美成人午夜剧场免费观看| 国产免费成人在线视频| 夜色激情一区二区| 免费永久网站黄欧美| 亚洲综合精品自拍| 欧美日韩国产成人| 亚洲片在线观看| 久久视频在线视频| 亚洲欧美久久| 国产精品老牛| 亚洲免费一区二区| 亚洲美女视频| 欧美精品一区二区在线观看| 国语自产精品视频在线看一大j8| 亚洲视频一区| 亚洲精品日韩欧美| 欧美成人中文字幕| 亚洲国产成人久久| 免播放器亚洲一区| 久久精品亚洲精品国产欧美kt∨| 国产精品羞羞答答xxdd| 亚洲一区二区高清| 99在线热播精品免费| 欧美黑人在线播放| 亚洲日本成人网| 亚洲国产视频一区| 久久www免费人成看片高清 | 亚洲黄色高清| 蜜桃av噜噜一区二区三区| 黄色另类av| 免费在线观看日韩欧美| 免费欧美日韩国产三级电影| 亚洲第一色在线| 欧美激情按摩在线| 欧美激情一区二区三区| 99爱精品视频| 日韩写真在线| 国产精品人成在线观看免费 | 亚洲影视在线播放| 欧美一级片在线播放| 久久9热精品视频| 国产亚洲成av人在线观看导航| 亚洲欧美精品一区| 午夜精品久久久久久| 国产一区二区你懂的| 蜜桃av一区| 欧美日韩天堂| 久久av老司机精品网站导航| 欧美一区二区视频观看视频| 精品1区2区3区4区| 亚洲精品韩国| 国产精品丝袜91| 暖暖成人免费视频| 欧美日韩国产美女| 久久激情五月激情| 蜜臀av一级做a爰片久久| 一区二区三区欧美亚洲| 午夜精品影院| 亚洲人成亚洲人成在线观看图片| 日韩一级欧洲| 国内一区二区在线视频观看| 欧美国内亚洲| 国产精品理论片| 免费在线亚洲欧美| 国产精品黄页免费高清在线观看| 久久久久五月天| 欧美日韩三级一区二区| 久久美女艺术照精彩视频福利播放| 免费日韩一区二区| 欧美制服丝袜第一页| 欧美韩日亚洲| 欧美1区2区| 国产一区成人| 夜夜嗨av色一区二区不卡| 在线看片第一页欧美| 亚洲综合另类| 亚洲在线播放| 欧美精品在线看| 免费观看一区| 国产午夜精品一区二区三区视频| 亚洲精品久久视频| 亚洲电影av在线| 欧美伊人久久久久久午夜久久久久| 一区二区成人精品| 欧美电影在线| 欧美激情一区二区三区不卡| 国内免费精品永久在线视频| 一二三区精品| 夜夜嗨av一区二区三区四区| 可以免费看不卡的av网站| 久久精品在线观看| 国产精品亚洲综合天堂夜夜| 夜夜嗨av一区二区三区四区| 亚洲精品国产精品久久清纯直播| 欧美在线播放视频| 久久aⅴ国产欧美74aaa| 国产精品一区二区三区观看| 在线中文字幕一区| 亚洲一区免费看| 欧美日韩免费在线观看| 99热精品在线观看| 亚洲字幕在线观看| 国产精品伦子伦免费视频| 一区二区三区高清在线| 亚洲精品国产精品国产自| 中国亚洲黄色| 欧美日韩国产欧| 99国产精品99久久久久久| aa级大片欧美| 欧美日韩xxxxx| 日韩一区二区免费看| 宅男噜噜噜66一区二区66| 欧美日韩91| 亚洲一区二区在线免费观看| 亚洲欧美日韩在线高清直播| 国产精品午夜在线观看| 久久国产精品一区二区三区| 玖玖在线精品| 亚洲人成网站精品片在线观看| 欧美国产成人精品| 99精品久久免费看蜜臀剧情介绍| 亚洲性感美女99在线| 国产精品欧美日韩一区| 欧美一区二区三区视频免费播放| 久久综合电影一区| 亚洲人成在线观看网站高清| 欧美美女视频| 欧美亚洲在线观看| 亚洲第一精品在线| 亚洲欧美日韩在线高清直播| 精品999成人| 欧美日韩精品久久久| 亚洲欧美制服另类日韩| 欧美大片在线看| 亚洲在线免费视频| 一区二区在线观看视频在线观看| 欧美成人综合网站| 午夜精品久久久| 亚洲激情第一区| 久久精品国产综合| 亚洲卡通欧美制服中文| 国产精品一区二区三区成人| 欧美成人综合在线| 欧美一区激情| aa级大片欧美三级| 麻豆亚洲精品| 欧美亚洲一区二区在线观看| 亚洲黄色成人久久久| 国产精品自拍小视频| 欧美精品一区二区三区久久久竹菊| 亚洲尤物视频网| 亚洲成在人线av| 久久九九99视频| 亚洲一区二区三区激情| 91久久在线播放| 韩国一区二区在线观看| 国产精品高精视频免费| 美日韩丰满少妇在线观看| 亚洲自拍16p| 日韩视频免费观看| 亚洲成人中文| 欧美韩国在线| 美女任你摸久久| 久久精品视频在线播放| 亚洲欧美日本日韩| 一区二区动漫|