C++

 自從Dennis M.Ritchie於1973年設計並實現C語言以來，電腦程式設計領域已經發生了巨大的變化。以C語言為根基的C++、 Java和C#等物件導向語言相繼誕生，並在各自領域大獲成功。今天，C及其後裔幾乎統治了電腦程式設計世界。可以這麼說，C語言的誕生是現代程式語言 革命的起點，它改變了程式設計語言發展的軌跡，是程式設計語言發展史中的一個裡程碑。 然而，C並不僅僅是其他語言的起點和基礎，否則它早已成

準備寫一個快樂學C++的系列貼子。從程式員的角度寫從動手實作的角度寫從手把手的角度寫：小說廢話多貼圖明天(我很懶，有可能會改在後天吧）我們準備帶領大家從頭學習C++基本語句如果您還沒有建立好學習c++的開發環境，請參考第一課（點這裡查看內容或點這裡查看），   

分享如何學好C++的一點想法及給初學者的建議   江濤 jiangtao [at] tao-studio.net摘要：    根據社區中一些言論的思索，發現一些問題，產生一些想法。並將這些想法分享給C++    初學者。關鍵詞：    C++ 學習方法 分享 誤區0.引言    本文適用於C++初學者。   “媽呀，咋又跑偏了哩！”[小瀋陽]    如果您還是作為C++的初學者或者是“學過幾年C++”卻不得要領，您是否知道，您也存在跑偏了的可能呢？  

本系列文章由zhmxy555編寫，轉載請註明出處。 http://blog.csdn.net/zhmxy555/article/details/7376281作者：毛星雲    郵箱： happylifemxy@qq.com    歡迎郵件交流編程心得"透明動畫”是遊戲中一定會用到的基本技巧，它通過圖案的連續顯示及圖案本身背景的透明化處理，在背景圖上產生出栩栩如生的動畫效果。看過之前筆記的朋友們應該知道，在筆記六裡我們介紹了使位元影像背景透明的方法，在筆記八裡我們講解了使用遊戲迴圈顯示動畫的技巧

本系列文章由zhmxy555編寫，轉載請註明出處。 http://blog.csdn.net/zhmxy555/article/details/7390624作者：毛星雲    郵箱： happylifemxy@qq.com    歡迎郵件交流編程心得相信大家都熟悉《仙劍奇俠傳98柔情版》的人機互動方式，用的僅僅是鍵盤。在那個物質並不充裕的時代，一台配置並不高的電腦，一款名叫《仙劍奇俠傳》的遊戲，卻能承載一代人對夢想的追逐。雖然在這十幾年間，各種新潮的遊戲層出不窮，但是《仙劍奇俠傳98柔情版》，

　　在《基類和衍生類別》中講述了單繼承的基本概念，這節著重講述繼承的具體應用。　　在單繼承中，每個類可以有多個衍生類別，但是每個衍生類別只能有一個基類，從而形成樹形結構。　　成員存取權限的控制　　在《基類和衍生類別》一講中，我們講述了衍生類別和衍生類別的對象對基類成員的存取權限的若干規定，這裡通過一個執行個體進一步討論存取權限的具體控制，然後得出在使用三種繼承方式時的調用方法。//繼承性的public繼承方式的存取權限的例子#include file://定義基類Aclass A{public:

    友元函數與友元類。C++中以關鍵字friend聲明友元關係。友元可以訪問與其有friend關係的類中的私人成員。友元包括友元函數和友元類。1．友元函數如果在本類以外的其它地方定義了一個函數（這個函數可以是不屬於任何類的非成員函數，也可以是其它類的成員函數），在類體中用friend對該函數進行聲明，此函數就稱為本類的友元函數。一個類的友元函數可以訪問這個類中的private成員。1.1將全域函式宣告為友元函數如果要將一個全域函數(call)聲明為本類(Time)的友元函數，則只需要在本類的

轉載自：http://www.cnblogs.com/salomon/archive/2012/06/04/2534787.html最近一直在看STL和Boost，源碼裡邊好多涉及到模板元編程技術，簡單瞭解一下，備忘（Boost Python中的涉及模板元的部分重點關注一下）。範例引入// 主模板template<int N>struct Fib{ enum { Result = Fib<N-1>::Result + Fib<N-2>::Result }

前提 ： 是做開發好還是繼續做外包裡的sub lead好，我不知道，我只知道當我的程式運行起來時我非常有成就感！ 共有4題，這裡先說題目，給大家想一想：1.const在函式宣告時的作用2.解釋一下dynamic_cast3.寫單例模式的代碼4..字串反轉,例子"I am good",期望結果"good am

概述想想我們編輯文檔用的wps，文檔裡文字很多都是重複的，我們不可能為每一個出現的漢字都建立獨立的空間，這樣代價太大，最好的辦法就是共用其中相同的部分，使得需要建立的對象降到最小，這個就是享元模式的核心，即運用共用技術有效地支援大量細粒度的對象。享元對象能做到共用的關鍵是區分內蘊狀態（Internal State）和外蘊狀態（External State）。內蘊狀態是儲存在享元對象內部並且不會隨環境改變而改變。因此內蘊狀態並可以共用。外蘊狀態是隨環境改變而改變的、不可以共用的狀態。享元對象的外蘊

概述作為C++工程師，免不了要管理記憶體，記憶體管理也是C++中的痛點，而智能指標採用引用計數的辦法很方便的幫我們管理了記憶體的使用，極大方便了我們的工作效率。而智能指標的這種用法其實就是代理模式的一種，他幫我們控制了該對象的記憶體使用量。代理模式就是為其他對象提供一種代理來控制對這個對象的訪問。種類和用途Proxy模式根據種類不同，效果也不盡相同：1、遠程（Remote）代理：為一個位於不同的地址空間的對象提供一個局域代表對象。這個不同的地址空間可以是在本機器中，也可是在另一台機器中。遠程代理

概述：     辛辛苦苦了工作了一年，終於可以加薪了，向主管提交了加薪申請，主管一看不得了，自己職權不夠，批不了，主管把申請上交總監，總監發現自己也批不了，申請到了總經理手中，總經理一看，小夥子口氣不小了，有膽識敢申請，先來談下心。預知後事如何，請看下回分解。     這就是典型的職責鏈模式，請求的處理形成了一條鏈，直到有一個對象處理請求。責任鏈模式是一種對象的行為模式。在責任鏈模式裡，很多個物件由每一個對象對其下家的引用而串連起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請

一、下載PDFBox      訪問網址http://sourceforge.net/projects/pdfbox/ (這個絕對是個好網站)二、引用動態連結程式庫    解壓縮下載的PDFBox，找到其中的Bin目錄，需要在項目中添加引用的dll檔案有：    IKVM.GNU.Classpath.dll    PDFBox-0.7.3.dll    FontBox-0.1.0-dev.dll    IKVM.Runtime.dll將以上4個檔案引用到項目中，在檔案中需要引入以下2個命名空間：

概述：       

概述：        在現在的電視機中，我們使用[後一個]和[前一個]按鈕可以很方便的換台，當按下[後一個]按鈕時，將切換到下一個預置的頻道。想象一下在陌生的城市中的旅店中看電視。當改變頻道時，重要的不是幾頻道，而是節目內容。如果對一個頻道的節目不感興趣，那麼可以換下一個頻道，而不需要知道它是幾頻道。       

簡單原廠模式按照設計模式類型分的話是屬於建立型模式，他是原廠模式中最簡單的一種，他不屬於GoF 23中設計模式之一，但是是簡單實用的。他是有一個工廠對象來決定建立哪一種對象的執行個體。實現比較簡單，這裡我只貼出類圖和調用方法：  調用方法：IProduct * simpleFactory::Create(std::string className){if( className == "Ipad")return new Ipad();if(className == "IPhone")return

概述：    假設我們開發一個圖片處理軟體，裡面肯定包括很多相關功能，比如說剪下，旋轉，濾鏡，美化等等，而我們這些功能所要處理的對象是固定的，就是我們所顯示的那張圖片。但是我們不能把所有的功能羅列到一個tab上，雖然這樣處理方便但是不美觀。這是我們可以這樣子：用一個中介者類負責所有功能的初始化和具體執行，我們需要功能時直接調用中介者類即可。   

Factory 方法模式不同於簡單原廠模式的地方在於Factory 方法模式把對象的建立過程放到裡子類裡。這樣工廠父物件和產品父物件一樣，可以是抽象類別或者介面，只定義相應的規範或操作，不涉及具體的建立或實現細節。 其類圖如下： 執行個體代碼為：#pragma onceclass IProduct{public:IProduct(void);virtual ~IProduct(void);};#pragma once#include "iproduct.h"class IPad :public

解決的問題：適配器模式把一個類的介面變換成用戶端所期待的另一種介面，從而使原本介面不匹配而無法在一起工作的兩個類能夠在一起工作。比如說我的hp筆記本，美國產品，人家美國的電壓是110V的，而我們中國的電壓是220V，要在中國能使用，必須找個變壓器轉一下電壓才可以。這個變壓器就是個適配器。適配器模式有類適配器和對象適配器兩種模式，我們將分別討論。類適配器：由圖中可以看出，Adaptee類沒有Request方法，而客戶期待這個方法。為了使客戶能夠使用Adaptee類，提供一個中間環節，即類Adapt

概述：        我們去餐廳吃飯，我們是通過服務員來點菜，具體是誰來做這些菜和他們什麼時候完成的這些菜，其實我們都不知道。抽象之，“菜單要求者”我們和“菜單實現者”廚師，2者之間是松耦合的，我們對這些菜的其他一些請求比如“撤銷，重做”等，我們也不知道是誰在做。其實這就是本文要說的Command模式。