ATL外匯平台

Ⅰ atlmis是一個什麼軟體

銀箭會計系統

從DOS版本的ATLMIS1.0，直到最新的SQL2005版本，我們的視窗版本可適用於不同平台，我們的最新版本－銀箭會計系統是一套功能全面的商業方案，它能在不同 Windows NT, Windows 2000, Windows 2003 Server及Unix平台上操作使用。

Ⅱ VC的MFC和ATL具體是指什麼嘛

MFC,微軟基礎類(Microsoft Foundation Classes),實際上是微軟提供的,用於在C++環境下編寫應用程序的一個框架和引擎,VC++是WinOS下開發人員使用的專業C++ SDK(SDK,Standard SoftWare Develop Kit,專業軟體開發平台),MFC就是掛在它之上的一個輸助軟體開發包,MFC作為與VC++血肉相連的部分(注意C++和VC++的區別:C++是一種程序設計語言,是一種大家都承認的軟體編制的通用規范,而VC++只是一個編譯器,或者說是一種編譯器+源程序編輯器的IDE,WS,PlatForm,這跟Pascal和Dephi的關系一個道理,Pascal是Dephi的語言基礎,Dephi使用Pascal規范來進行Win下應用程序的開發和編譯,卻不同於Basic語言和VB的關系,Basic語言在VB開發出來被應用的年代已經成了Basic語言的新規范,VB新加的Basic語言要素,如面對對象程序設計的要素,是一種性質上的飛躍,使VB既是一個IDE,又成長成一個新的程序設計語言),MFC同BC++集成的VCL一樣是一個非外掛式的軟體包,類庫,只不過MFC類是微軟為VC++專配的..
MFC是Win API與C++的結合,API,即微軟提供的WinOS下應用程序的編程語言介面,是一種軟體編程的規范,但不是一種程序開發語言本身,可以允許用戶使用各種各樣的第三方(如我是一方,微軟是一方,Borland就是第三方)的編程語言來進行對Win OS下應用程序的開發,使這些被開發出來的應用程序能在WinOS下運行,比如VB,VC++,Java,Dehpi編程語言函數本質上全部源於API,因此用它們開發出來的應用程序都能工作在WinOS的消息機制和繪圖里,遵守WinOS作為一個操作系統的內部實現,這其實也是一種必要,微軟如果不提供API,這個世上對Win編程的工作就不會存在,微軟的產品就會迅速從時尚變成垃圾,上面說到MFC是微軟對API函數的專用C++封裝,這種結合一方面讓用戶使用微軟的專業C++ SDK來進行Win下應用程序的開發變得容易,因為MFC是對API的封裝,微軟做了大量的工作,隱藏了好多內節程序開發人員在Win下用C++ & MFC編制軟體時的大量內節,如應用程序實現消息的處理,設備環境繪圖,這種結合是以方便為目的的,必定要付出一定代價(這是微軟的一向作風),因此就造成了MFC對類封裝中的一定程度的的冗餘和迂迴,但這是可以接受的..
最後要明白MFC不只是一個功能單純的界面開發系統,它提供的類絕大部分用來進行界面開發,關聯一個窗口的動作,但它提供的類中有好多類不與一個窗口關聯,即類的作用不是一個界面類,不實現對一個窗口對象的控制(如創建,銷毀),而是一些在WinOS(用MFC編寫的程序絕大部分都在WinOS中運行)中實現內部處理的類,如資料庫的管理類等,學習中最應花費時間的是消息和設備環境,對C++和MFC的學習中最難的部分是指針,C++面向對像程序設計的其它部分,如數據類型,流程式控制制都不難,建議學習數據結構C++版..

一、 什 么 是ATL
---- 1 ．COM 的 發 展 及 其 局 限 性

---- 自 從1993 年Microsoft 首 次 公 布 了COM 技 術 以 後，Windows 平 台 上 的 開 發 模 式 發 生 了 巨 大 的 變 化， 以COM 為 基 礎 的 一 系 列 軟 件 組 件 化 技 術 將Windows 編 程 帶 入 了 組 件 化 時 代。 廣 大 開 發 人 員 在 為COM 帶 來 的 軟 件 組 件 化 趨 勢 歡 欣 鼓 舞 的 同 時， 對 於COM 開 發 技 術 的 難 度 和 煩 瑣 的 細 節 也 感 到 極 其 的 不 便。COM 編 程 一 度 被 視 為 一 種 高 不 可 攀 的 技 術， 令 人 望 而 卻 步。 開 發 人 員 希 望 能 夠 有 一 種 方 便 快 捷 的COM 開 發 工 具， 提 高 開 發 效 率， 更 好 地 利 用 這 項 技 術。

---- 針 對 這 種 情 況，Microsoft 公 司 在 推 出COM SDK 以 後， 為 簡 化COM 編 程， 提 高 開 發 效 率， 采 取 了 許 多 方 案， 特 別 是 在MFC（Microsoft Foundation Class） 中 加 入 了 對COM 和OLE 的 支 持。 但 是 隨 著Internet 的 發 展， 分 布 式 的 組 件 技 術 要 求COM 組 件 能 夠 在 網 絡 上 傳 輸， 而 又 盡 量 節 約 寶 貴 的 網 絡 帶 寬 資 源。 采 用MFC 開 發 的COM 組 件 由 於 種 種 限 制 不 能 很 好 地 滿 足 這 種 需 求， 因 此Microsoft 在1995 年 又 推 出 了 一 種 全 新 的COM 開 發 工 具 — —ATL。

---- ATL 是ActiveX Template Library 的 縮 寫， 它 是 一 套C++ 模 板 庫。 使 用ATL 能 夠 快 速 地 開 發 出 高 效、 簡 潔 的 代 碼， 同 時 對COM 組 件 的 開 發 提 供 最 大 限 度 的 代 碼 自 動 生 成 以 及 可 視 化 支 持。 為 了 方 便 使 用， 從Microsoft Visual C++ 5.0 版 本 開 始，Microsoft 把ATL 集 成 到Visual C++ 開 發 環 境 中。1998 年9 月 推 出 的Visual Studio 6.0 集 成 了ATL 3.0 版 本。 目 前，ATL 已 經 成 為Microsoft 標 准 開 發 工 具 中 的 一 個 重 要 成 員， 日 益 受 到C++ 開 發 人 員 的 重 視。

---- ATL 究 竟 給 開 發 人 員 帶 來 了 什 么 樣 的 益 處 呢 ？ 這 要 先 從ATL 產 生 以 前 的COM 開 發 方 式 說 起。

---- 在ATL 產 生 以 前， 開 發COM 組 件 的 方 法 主 要 有 兩 種： 一 是 使 用COM SDK 直 接 開 發COM 組 件， 另 一 種 方 式 是 通 過MFC 提 供 的COM 支 持 來 實 現。

---- 直 接 使 用COM SDK 開 發COM 組 件 是 最 基 本 也 是 最 靈 活 的 方 式。 通 過 使 用Microsoft 提 供 的 開 發 包， 我 們 可 以 直 接 編 寫COM 程 序。 但 是， 這 種 開 發 方 式 的 難 度 和 工 作 量 都 很 大， 一 方 面， 要 求 開 發 者 對 於COM 的 技 術 原 理 具 有 比 較 深 入 的 了 解（ 雖 然 對 技 術 本 身 的 深 刻 理 解 對 使 用 任 何 一 種 工 具 都 是 非 常 有 益 的， 但 對 於COM 這 樣 一 整 套 復 雜 的 技 術 而 言， 在 短 時 間 內 完 全 掌 握 是 很 難 的）； 另 一 方 面， 直 接 使 用COM SDK 要 求 開 發 人 員 自 己 去 實 現COM 應 用 的 每 一 個 細 節， 完 成 大 量 的 重 復 性 工 作。 這 樣 做 的 結 果 是， 不 僅 降 低 了 工 作 效 率， 同 時 也 使 開 發 人 員 不 得 不 把 許 多 精 力 投 入 到 與 應 用 需 求 本 身 無 關 的 技 術 細 節 中。 雖 然 這 種 開 發 方 式 對 於 某 些 特 殊 的 應 用 很 有 必 要， 但 這 種 編 程 方 式 並 不 符 合 組 件 化 程 序 設 計 方 法 所 倡 導 的 可 重 用 性， 因 此， 直 接 采 用COM SDK 不 是 一 種 理 想 的 開 發 方 式。

---- 使 用MFC 提 供 的COM 支 持 開 發COM 應 用 可 以 說 在 使 用COM SDK 基 礎 上 提 高 了 自 動 化 程 度， 縮 短 了 開 發 時 間。MFC 采 用 面 向 對 象 的 方 式 將COM 的 基 本 功 能 封 裝 在 若 干MFC 的C++ 類 中， 開 發 者 通 過 繼 承 這 些 類 得 到COM 支 持 功 能。 為 了 使 派 生 類 方 便 地 獲 得COM 對 象 的 各 種 特 性，MFC 中 有 許 多 預 定 義 宏， 這 些 宏 的 功 能 主 要 是 實 現COM 接 口 的 定 義 和 對 象 的 注 冊 等 通 常 在COM 對 象 中 要 用 到 的 功 能。 開 發 者 可 以 使 用 這 些 宏 來 定 制COM 對 象 的 特 性。

---- 另 外， 在MFC 中 還 提 供 對Automation 和ActiveX Control 的 支 持， 對 於 這 兩 個 方 面，Visual C++ 也 提 供 了 相 應 的AppWizard 和ClassWizard 支 持， 這 種 可 視 化 的 工 具 更 加 方 便 了COM 應 用 的 開 發。

---- MFC 對COM 和OLE 的 支 持 確 實 比 手 工 編 寫COM 程 序 有 了 很 大 的 進 步。 但 是MFC 對COM 的 支 持 還 不 夠 完 善 和 徹 底， 例 如 對COM 接 口 定 義 的IDL 語 言，MFC 並 沒 有 任 何 支 持， 此 外 對 於 近 些 年 來COM 和ActiveX 技 術 的 新 發 展MFC 也 沒 有 提 供 靈 活 的 支 持。 這 是 由MFC 設 計 的 基 本 出 發 點 決 定 的。MFC 被 設 計 成 對Windows 平 台 編 程 開 發 的 面 向 對 象 的 封 裝， 自 然 要 涉 及Windows 編 程 的 方 方 面 面，COM 作 為Windows 平 台 編 程 開 發 的 一 個 部 分 也 得 到MFC 的 支 持， 但 是MFC 對COM 的 支 持 是 以 其 全 局 目 標 為 出 發 點 的， 因 此 對COM 的 支 持 必 然 要 服 從 其 全 局 目 標。 從 這 個 方 面 而 言，MFC 對COM 的 支 持 不 能 很 好 地 滿 足 開 發 者 的 要 求。

---- 隨 著Internet 技 術 的 發 展，Microsoft 將ActiveX 技 術 作 為 其 網 絡 戰 略 的 一 個 重 要 組 成 部 分 大 力 推 廣， 然 而 使 用MFC 開 發 的ActiveX Control， 代 碼 冗 余 量 大， 即 所 謂 的「 肥 代 碼」（Fat Code）， 而 且 必 須 要 依 賴 於MFC 的 運 行 時 刻 庫 才 能 正 確 地 運 行。 雖 然MFC 的 運 行 時 刻 庫 只 有 部 分 功 能 與COM 有 關， 但 是 由 於MFC 的 繼 承 實 現 的 本 質，ActiveX Control 必 須 背 負 運 行 時 刻 庫 這 個 沉 重 的 包 袱。 如 果 采 用 靜 態 連 接MFC 運 行 時 刻 庫 的 方 式， 這 將 使ActiveX Control 代 碼 過 於 龐 大， 在 網 絡 上 傳 輸 時 將 占 據 寶 貴 的 網 絡 帶 寬 資 源； 如 果 采 用 動 態 連 接MFC 運 行 時 刻 庫 的 方 式， 這 將 要 求 瀏 覽 器 一 方 必 須 具 備MFC 的 運 行 時 刻 庫 支 持。 總 之，MFC 對COM 技 術 的 支 持 在 網 絡 應 用 的 環 境 下 也 顯 得 很 不 靈 活。

Ⅲ VC 中的ATL和 MFC喲喲什麼區別

ATL是ActiveXTemplateLibrary的縮寫，它是一套C++模板庫。使用ATL能夠快速地開發出高效、簡潔的代碼，同時對COM組件的開發提供最大限度的代碼自動生成以及可視化支持。為了方便使用，從MicrosoftVisualC++5.0版本開始，Microsoft把ATL集成到VisualC++開發環境中。1998年9月推出的VisualStudio6.0集成了ATL3.0版本。
在ATL產生以前，開發COM組件的方法主要有兩種：一是使用COMSDK直接開發COM組件，另一種方式是通過MFC提供的COM支持來實現。
直接使用COMSDK開發COM組件是最基本也是最靈活的方式。通過使用Microsoft提供的開發包，我們可以直接編寫COM程序。但是，這種開發方式的難度和工作量都很大，一方面，要求開發者對於COM的技術原理具有比較深入的了解（雖然對技術本身的深刻理解對使用任何一種工具都是非常有益的，但對於COM這樣一整套復雜的技術而言，在短時間內完全掌握是很難的）；另一方面，直接使用COMSDK要求開發人員自己去實現COM應用的每一個細節，完成大量的重復性工作。這樣做的結果是，不僅降低了工作效率，同時也使開發人員不得不把許多精力投入到與應用需求本身無關的技術細節中。雖然這種開發方式對於某些特殊的應用很有必要，但這種編程方式並不符合組件化程序設計方法所倡導的可重用性，因此，直接採用COMSDK不是一種理想的開發方式。
使用MFC提供的COM支持開發COM應用可以說在使用COMSDK基礎上提高了自動化程度，縮短了開發時間。MFC採用面向對象的方式將COM的基本功能封裝在若干MFC的C++類中，開發者通過繼承這些類得到COM支持功能。為了使派生類方便地獲得COM對象的各種特性，MFC中有許多預定義宏，這些宏的功能主要是實現COM介面的定義和對象的注冊等通常在COM對象中要用到的功能。開發者可以使用這些宏來定製COM對象的特性。
隨著Internet技術的發展，Microsoft將ActiveX技術作為其網路戰略的一個重要組成部分大力推廣，然而使用MFC開發的ActiveXControl，代碼冗餘量大，即所謂的「肥代碼」（FatCode），而且必須要依賴於MFC的運行時刻庫才能正確地運行。雖然MFC的運行時刻庫只有部分功能與COM有關，但是由於MFC的繼承實現的本質，ActiveXControl必須背負運行時刻庫這個沉重的包袱。如果採用靜態連接MFC運行時刻庫的方式，這將使ActiveXControl代碼過於龐大，在網路上傳輸時將占據寶貴的網路帶寬資源；如果採用動態連接MFC運行時刻庫的方式，這將要求瀏覽器一方必須具備MFC的運行時刻庫支持。總之，MFC對COM技術的支持在網路應用的環境下也顯得很不靈活。
MFC對COM和OLE的支持確實比手工編寫COM程序有了很大的進步。但是MFC對COM的支持還不夠完善和徹底，例如對COM介面定義的IDL語言，MFC並沒有任何支持，此外對於近些年來COM和ActiveX技術的新發展MFC也沒有提供靈活的支持。這是由MFC設計的基本出發點決定的。MFC被設計成對Windows平台編程開發的面向對象的封裝，自然要涉及Windows編程的方方面面，COM作為Windows平台編程開發的一個部分也得到MFC的支持，但是MFC對COM的支持是以其全局目標為出發點的，因此對COM的支持必然要服從其全局目標。從這個方面而言，MFC對COM的支持不能很好地滿足開發者的要求。

對於程序員來說，還有一個區別就是ATL要求你懂得更多的COM知識，這樣你才能直接使用ATL來編寫COM組件或者控制項，而MFC甚至不要求你知道COM是個什麼東西就能寫出一個ActiveX控制項來了。
此外，如果你編寫的控制項有GUI（圖形用戶界面）的話，你最好使用MFC；如果根本不需要GUI，那最好使用ATL編寫，當然你也可以選擇MFC來編寫不可見的控制項，但是開銷比ATL大，而執行效率卻小於ATL；但是有時候這種差別所帶來影響可以忽略掉的話，那麼我建議你還是用MFC來寫，唯一的理由是它開發起來更簡單，易於調試。如果你是一個COM的門外漢，卻又想使用ATL來編寫控制項，那麼建議你先准備半年時間（保守估計）來學習COM的理論知識

簡單地說,ATL在網路應用普及的今天,開發效果(簡潔\高效)要比MFC好.但我本人覺得MFC也不差!我一直在用MFC做事!

Ⅳ MFC、ATL、COM是否還有發展空間

C#和MFC不是一種東西，不能比較。
.Net框架最初的設計是用來替換MFC作為面向對象的API封裝，不過API爆炸性增長之後這個目標變得不太現實，因為類庫大小已經有人開始抱怨了，不可能再加入太多API的封裝類。新的API很多都是基於COM的，在使用上MFC和ATL具有優勢。

Ⅳ c++中的ATL是用來干什麼的

ATL是一個產生C++/COM代碼的框架，就如同C語言是一個產生匯編代碼的框架
ATL又不同於MFC，它完全面向COM組件，其技術路線也不同於MFC，MFC使用的是C++中的繼承、封裝、嵌套等常規技術，而ATL使用了C++中模板、多繼承等高級技術，甚至還用到了STL。所以學習和使用ATL要求我們必須熟悉這些C++高級特性。另一方面，ATL結構完全針對COM中的諸多規范，這就要求使用人員必須非常了解COM規范，才有可能真正把ATL用好。
對於COM應用的開發，ATL無疑是首選的工具，與MFC相比，ATL的規模還不算大，但是從上述的介紹可以看出，ATL涉及到了COM的方方面面。 實際上，ATL的內容還要多得多，比如OLE DB的支持、MTS的支持等。

Ⅵ 什麼是TL幣

CTL：Citadel Network是一個去中心化的P2P加密網站，用戶通過發送代幣進行經濟交易。Citadel主要有兩個部分——Citadel Network，基於區塊鏈加密安全基礎設施，用於用戶間的CTL代幣的經濟交易；Citadel平台，是一個多元化，靈活的全球化生態系統，為用戶提供貨幣交易，身份識別和電子商務等服務。
MTL：
Metal是一種基於區塊鏈技術，用來證明用戶處理付款確認的，使用MTL代幣進行獎勵，類似於比特幣的數字貨幣。Metal擁有一個友好的用戶界面的產品，就像Venmo、Square、PayPal。Metal作為一個支付工具，比特幣或其他的數字貨幣都適用。雖然世界上還有很多小企業更願意接受現金，然而無現金是未來趨勢，拒絕接受數字貨幣或信用卡支付會落後於這個社會。簡單的說，Metal只針對企業提供數字貨幣新服務，數字貨幣都有共同的特點，特別是在隱私保護上。為了使數字支付方式進入現實世界，一些傳統銀行機構也在利用區塊鏈技術，Metal預計這樣做將讓消費者在購買商品時節省4%-5%。
XTL：Stellite是一種現代化的、安全的、去中心化的開源式加密貨幣，由社區驅動，為日常設備提供用戶友好的區塊鏈工具。Stellite是首個將IPFS和ZeroNet與區塊鏈相連的加密貨幣，所有數據都是私有的。
ATL：
Atlant是一個可定製的去中心化系統，建立在以太坊DAO協議基礎上。代幣是這個平台的核心，簡稱「ATL」。 ATL代幣本質上是Atlant平台的會員憑證，它能夠給予代幣擁有者以下權利: 通過Atlant平台，用戶可以列出他們資產的所有屬性。該平台允許業主和開發者通過創建自定義的智能合約來對財產進行代幣化，從而進行財產(部分或全部)出售或吸引投資。標的的股份規模最初擬定為資產的7%，以後將由ATL代幣持有人投票決定。在成功的眾籌後，通過第三方託管的代幣的一部分將被按比例分配給ATL代幣持有人。 在與承租人的P2P租賃交易完成後，將收取一筆小費用的傭金。這些傭金被分配給ATL代幣持有人。這個費用的大小由ATL代幣持有者投票來決定。 通過投票可以決定有關資產的各種行為:平台上市決策、上市費用批准、律師事務所選擇、管理公司選擇(財產代幣化)、租金批准、租賃費用批准等。 在Atlant的框架內，通過仲裁機構的評級系統，持幣人能夠在P2P租賃服務中成為仲裁解決方案的仲裁人，他們能夠通過這種途徑賺取額外收入。被第三方託管的保管資金於是就被分配給來執行仲裁的ATL幣持有人。 擁有平台內的影響力。代幣持有人擁有提議，投票表決權，能協助平台的進一步發展，以提高全球房地產的效率，並促進Atlant的全球化推廣和增長。

Ⅶ ATL的什麼是ATL

自從1993年Microsoft首次公布了COM技術以後，Windows平台上的開發模式發生了巨大的變化，以COM為基礎的一系列軟體組件化技術將Windows編程帶入了組件化時代。廣大的開發人員在為COM帶來的軟體組件化趨勢歡欣鼓舞的同時，對於COM開發技術的難度和煩瑣的細節也感到極其的不便。COM編程一度被視為一種高不可攀的技術，令人望而卻步。開發人員希望能夠有一種方便快捷的COM開發工具，提高開發效率，更好地利用這項技術。
針對這種情況，Microsoft公司在推出COM SDK以後，為簡化COM編程，提高開發效率，採取了許多方案，特別是在MFC（Microsoft Foundation Class）中加入了對COM和OLE的支持。但是隨著Internet的發展，分布式的組件技術要求COM組件能夠在網路上傳輸，而又盡量節約寶貴的網路帶寬資源。採用MFC開發的COM組件由於種種限制不能很好地滿足這種需求，因此Microsoft在1995年又推出了一種全新的COM開發工具ATL。
ATL是ActiveX Template Library 的縮寫，它是一套C++模板庫。使用ATL能夠快速地開發出高效、簡潔的代碼（Effective and Slim code），同時對COM組件的開發提供最大限度的代碼自動生成以及可視化支持。為了方便使用，從MicrosoftVisual C++5.0版本開始，Microsoft把ATL集成到Visual C++開發環境中。1998年9月推出的Visual Studio 6.0 集成了ATL 3.0版本。ATL已經成為Microsoft標准開發工具中的一個重要成員，日益受到C++開發人員的重視。
ATL究竟給開發人員帶來了什麼樣的益處呢？這還要先從ATL產生以前的COM開發方式說起。
在ATL產生以前，開發COM組件的方法主要有兩種：一是使用COM SDK直接開發COM組件，另一種方式是通過MFC提供的COM支持來實現。
直接使用COM SDK開發COM組件是最基本也是最靈活的方式。通過使用Microsoft提供的開發包，我們可以直接編寫COM程序。但是，這種開發方式的難度和工作量都很大，一方面，要求開發者對於COM的技術原理具有比較深入的了解（雖然對技術本身的深刻理解對使用任何一種工具都是非常有益的，但對於COM這樣一整套復雜的技術而言，在短時間內完全掌握是很難的），另一方面，直接使用COM SDK要求開發人員自己去實現COM應用的每一個細節，完成大量的重復性工作。這樣做的結果是，不僅降低了工作效率，同時也使開發人員不得不把許多精力投入到與應用需求本身無關的技術細節中。雖然這種開發方式對於某些特殊的應用很有必要，但這種編程方式並不符合組件化程序設計方法所倡導的可重用性，因此，直接採用COM SDK不是一種理想的開發方式。
使用MFC提供的COM支持開發COM應用可以說在使用COM SDK基礎上提高了自動化程度，縮短了開發時間。MFC採用面向對象的方式將COM的基本功能封裝在若干MFC的C++類中，開發者通過繼承這些類得到COM支持功能。為了使派生類方便地獲得COM對象的各種特性，MFC中有許多預定義宏，這些宏的功能主要是實現COM介面的定義和對象的注冊等通常在COM對象中要用到的功能。開發者可以使用這些宏來定製COM對象的特性。
另外，在MFC中還提供對Automation和 ActiveX Control的支持，對於這兩個方面，Visual C++也提供了相應的AppWizard和ClassWizard支持，這種可視化的工具更加方便了COM應用的開發。
MFC對COM和OLE 的支持確實比手工編寫COM程序有了很大的進步。但是MFC對COM的支持是不夠完善和徹底的，例如對COM介面定義的IDL語言，MFC並沒有任何支持，此外對於近些年來COM和ActiveX技術的新發展MFC也沒有提供靈活的支持。這是由MFC設計的基本出發點決定的。MFC被設計成對Windows平台編程開發的面向對象的封裝，自然要涉及Windows編程的方方面面，COM作為Windows平台編程開發的一個部分也得到MFC的支持，但是MFC對COM的支持是以其全局目標為出發點的，因此對COM 的支持必然要服從其全局目標。從這個方面而言，MFC對COM的支持不能很好的滿足開發者的要求。
隨著Internet技術的發展，Microsoft將ActiveX技術作為其網路戰略的一個重要組成部分大力推廣，然而使用MFC開發的ActiveX Control，代碼冗餘量大（所謂的「肥代碼 Fat Code」），而且必須要依賴於MFC的運行時刻庫才能正確地運行。雖然MFC的運行時刻庫只有部分功能與COM有關，但是由於MFC的繼承實現的本質，ActiveX Control必須背負運行時刻庫這個沉重的包袱。如果採用靜態連接MFC運行時刻庫的方式，這將使ActiveX Control代碼過於龐大，在網路上傳輸時將占據寶貴的網路帶寬資源；如果採用動態連接MFC運行時刻庫的方式，這將要求瀏覽器一方必須具備MFC的運行時刻庫支持。總之MFC對COM技術的支持在網路應用的環境下也顯得很不靈活。
解決上述COM開發方法中的問題正是ATL的基本目標。
首先ATL的基本目標就是使COM應用開發盡可能地自動化，這個基本目標就決定了ATL只面向COM開發提供支持。目標的明確使ATL對COM技術的支持達到淋漓盡致的地步。對COM開發的任何一個環節和過程，ATL都提供支持，並將與COM開發相關的眾多工具集成到一個統一的編程環境中。對於COM/ActiveX的各種應用，ATL也都提供了完善的Wizard支持。所有這些都極大地方便了開發者的使用，使開發者能夠把注意力集中在與應用本身相關的邏輯上。
其次，ATL因其採用了特定的基本實現技術，擺脫了大量冗餘代碼，使用ATL開發出來的COM應用的代碼簡練高效，即所謂的「Slim Code」。ATL在實現上盡可能採用優化技術，甚至在其內部提供了所有C/C++開發的程序所必須具有的C啟動代碼的替代部分。同時ATL產生的代碼在運行時不需要依賴於類似MFC程序所需要的龐大的代碼模塊，包含在最終模塊中的功能是用戶認為最基本和最必須的。這些措施使採用ATL開發的COM組件（包括ActiveX Control)可以在網路環境下實現應用的分布式組件結構。
第三，ATL的各個版本對Microsoft的基於COM的各種新的組件技術如MTS、ASP等都有很好的支持，ATL對新技術的反應速度大大快於MFC。ATL已經成為Microsoft支持COM應用開發的主要開發工具，因此COM技術方面的新進展在很短的時間內都會在ATL中得到反映。這使開發者使用ATL進行COM編程可以得到直接使用COM SDK編程同樣的靈活性和強大的功能。
本文的目的就是希望在有限的篇幅中能夠使讀者對ATL的使用和基本原理有一個初步的了解，為廣大的COM開發人員更好地使用ATL開發起到拋磚引玉的作用。

Ⅷ VC++，MFC，COM和ATL的區別

MFC是vc的一個庫
com是介面吧
atl是容器
在網路上看看吧。
c++是語言
vc++ 是c++編程軟體平台在上面可以使用後三者。

Ⅸ VC 中的ATL是什麼

這種問題直接網路就可以啦。簡單復制一些摘要：
Active Template Library活動模板庫，是一種微軟程序庫，支持利用C++語言編寫ASP代碼以及其它ActiveX程序。通過活動模板庫，可以建立COM組件，然後通過ASP頁面中的腳本對COM對象進行調用。這種COM組件可以包含屬性頁、對話框等等控制項。

簡單的說，就是一套為了開發通用COM組件/控制項 而做的一個開發庫模板平台。