創(chuàng)建一個渲染目標，顯示后，會有黑底，可以置混合模式讓它透明，但是，我顯示的黑色字體也被過濾掉不顯示了.. 請問還有什么辦法讓渲染目標透明而黑色的文字能正常顯示呢？

不知道樓主還看不看這篇文章，我想請教一個問題，是這樣的，我的模型坐標很大，如何讓模型繞中心軸旋轉呢？因為如果只是Rotatef（angle，0，1，0）這樣的話，模型一旋轉就沒有了。

ggeSprite調(diào)用SetTextureRect設置了顯示區(qū)域，然后如果不SetPosition設置渲染位置的話，顯示出來的效果就變成了拉伸縮放，且顯示區(qū)域也不是設置的Rect，而是原來的大小。不知是不是BUG

當創(chuàng)建引擎時，如果傳入的窗口寬度小于三個控制按鈕(最小鈕+最大鈕+關閉鈕)的寬度會出現(xiàn)一件神奇的事情，您可以測試一下。

@kuyu
有。易語言論壇曾經(jīng)有人發(fā)布過

New version of WTL will be 9.0

Download current build WTL 9.0.4035 (1/4/2014)

天生不支持xp，這是基于什么考慮呢

thanks :D

挺好的，請問博文你這個UML是用啥畫的？

沒有具體測試過，fwrite用于寫結構、二進制數(shù)組，可以參考w.r.stevens在apue(5.9, p145)中關于fwrite的描述。

我照抄了，編譯通不過啊

@飯中淹
這套工具現(xiàn)在對于我更多的是一個學習和試驗，如果希望和別人交流和共同開發(fā)跨平臺（尤其是non-win）的代碼的話，由于需要對依賴庫進行檢測，這個工作可以由autoconf+automake來完成。

In practice, CMake not only lacks a rich platform tests suite, compared to autoconf, it also lacks a lot of features from automake and libtool.

So why should you not switch an autotools-based project over to CMake?

Tedious
First and foremost, your configure.ac script may be large. Porting to CMake can be a time consuming and not so funnny task when it comes to the long tail.
iconv support missing
There are no standard tests for iconv(), neither for finding the compiler flags, nor whether it takes a const pointer.
pkg-config support broken
pkg-config support is reportedly broken as of cmake 2.4 patch 8.
Exported symbols list not implemented
There are no documented ways to specify the list of exported symbols for a shared libraries, so your libraries will unconditionnaly expose all their non-static APIs (libtool can use a flat list or a regular expression).
C99 compiler check missing
There is no built-in support to enable C99 support in the C compiler.
Objective-C flags not supported
You can add flags for the Objective-C compiler, but they propagate to C compilation as well.
Compiler feature checks missing
There are no built-in checks for any of the C99 features, such as variable-sized arrays, restricted pointers, macros with variable number of arguments, etc. nor for GCCisms.
Monolithic installation prefix
There is only one global installation prefix. So the typical Linux distro cannot set the global prefix to /usr while the system configuration (automake's sysconfdir) would be /etc. Very nice for "downstream" Linux packagers...
Installation paths hard-coding
As a consequence of the single prefix, you need to hard-code all paths from the prefix. Instead of ${docdir}, you need to hard-code ${prefix}/share/doc/${package} (${CMAKE_INSTALL_PREFIX}/share/doc/foobar in CMake parliance) and so on and so forth. BSD porters are going to have fun tweaking the paths manually...
Uninstallation not supported
There is sipport for uninstalling. That is a design choice. You'd better never ever try to install a package straight from the build tree, without a proper packaging system.
Installation testsuite not supported
Since there is no uninstallation, there is no of course no distcheck target either. How often did you get your source tarball right from the first attempt before a new release?
No cross-compilation
There is no documented support for cross-compilation. This is scheduled for a future release.
Limited documentation
Compared to autotools, the documentation feels a bit light. At least, there is a wiki, but that cannot replace a good offline reference.
Limited executable renaming
CMake is not quite as powerful as automake (with program-prefix, program-suffix and program-transform-name) when it comes to on-the-fly executable renaming. This little-known feature of automake can be extremely useful when building an operating system distribution with possibly conflicting executable names from different projects. For instance, it is very conveniant along with the Debian alternatives system.
No source tarball packaging
There is no built-in support for making a tarball (make dist). Some Version Control Systems can do it themselves (git does, Subversion does not). This is quite critical a feature for open-source projects.
No source tarball testing
As there is no replacement for make dist, there is no replacement for make distcheck either. From my not-so-humble experience, that is tremendously useful before doing a new release. (NOTE: when I write distcheck, I mean distcheck. I don't mean check which becomes test with CMake)
No gettext integration
Gettext is not supported. Targets for .po and .mo files must be added manually. Nevermind that this is the most widely used localization subsystem in the open-source community.
Awkward feature listing
Whereby ./configure --help gives the list of build option, cmake --help prints the CMake options only. Instead, it seems you have to run cmake in "interactive" mode and answer a question for each and every setting (much like Linux kernel make config).
---------------------------
當然這些問題對于我不是必需的，不過還是等我autotools用一段時間再說:)

三更半夜的上來看一下，這兩天被蹂躪安逸了……

<style type=text/css>
#top a{ border-bottom:1px dashed; color:white; }
#top a:link{ border-bottom:1px dashed; color:white; }
#top a:hover{ border-bottom:1px dashed; color:white; }
#top a:visited{ border-bottom:1px dashed; color:white; }
.post a:link{ border-bottom:1px dashed; color:maroon; }
.post a:hover{ border-bottom:1px dashed; color:maroon; }
.post a:visited{ border-bottom:1px dashed; color:maroon; }
.postbody a{ color:white; background:maroon; }
.postbody a:link{ color:white; background:maroon; }
.postbody a:hover{ color:white; background:maroon; }
.postbody a:visited{ color:white; background:maroon; }
</style>

支持@Eric

@adah
給個鏈接我了解一下DCL被批的原因吧，我承認孤陋寡聞了。

@Peter
對不起，是我自己學藝不精:-)，DOXYFILE_ENCODING只是配置文件的編碼格式而已，而識別中文文檔只需要修改INPUT_ENCODING成EUC-CN即可，OUTPUT_LANGUAGE自然設置成Chinese也不會有問題，因為doxygen采用UTF-8輸出，使用中文輸出不會有亂碼問題。
也就是說，對于你而言，DOXYFILE_ENCODING可以保持UTF-8，只是把INPUT_ENCODING改成EUC-JP（或者你用的其他編碼）即可。

@阿福
沒有，記得一個家伙說過：過分依賴ide是一個不好的習慣。想想在cygwin下裝B就裝到底算了。

@true
看了一下config-win32.h，這個宏前后都不會有影響，不過統(tǒng)一放在前面的話，是一個好的習慣，還是改過來了，3X

重載NEW唯一壞處是線程不安全。

不用線程，只是select輪詢又如何？不見得性能很差。

@葉先生
你給的第一個的例子并不太合適，阻塞實際是指因繼續(xù)執(zhí)行的條件不滿足（事件未到達）而掛起等待，test1實際并未掛起，只是一直在執(zhí)行一個空循環(huán)而已。
test2只是 多了一個DoEvent，如果討論同步還是異步，實際要視DoEvent而定，若DoEvent像你所說，那可以作為異步看待，如果DoEvent阻塞等待事件到來，則成了同步，但這都與你給的循環(huán)沒有關系。

至于你說test1會“卡死”，那是因為單線程的話，需要不停的執(zhí)行循環(huán)，但沒有阻塞，因為循環(huán)一直在跑:)

呵呵，我也同意算上空行和注釋等。

這個不用這么較真兒吧？

麻煩大家“閱讀全文”后回復，謝謝:D

很誘人的功能，先MARK一個，明天好好研究研究:D

并不是所有基類的析構都要virtual的，此例即不需要，因為這兒的析構是trivial的，推薦閱讀lippman的<inside the c++ object model>.

你停太久了……

呵呵，整理的不錯:)

@阿福
這個是成員函數(shù)，所以后面加了；這兒沒有上下文，去掉更好理解了。
前面加是筆誤:)。

@Condor
你說的這個問題我也考慮了，既然被提到，可以查看新一篇：http://m.shnenglu.com/Fox/archive/2008/10/10/63625.html

@sl
我在上面提到“我們說某某操作是非阻塞的，是因為操作結果會通過異步方式返回”，Douglas說的是there is no async processing if without a proper configuring，意思是：

非阻塞之后可以不做異步處理。

但非阻塞和異步仍然是緊密聯(lián)系而非區(qū)別非常大。
Douglas這本書我手頭現(xiàn)在沒有:(，翻了一下adv. pro. in UNIX，沒有看到詳細說明:(。

@LOGOS
你說的對，但如果說“非阻塞的東西不一定會給你回調(diào)通知”，那么這時候在所阻塞和非阻塞也就沒有意義了，既然不需要回調(diào)/事件通知或其他任何形式的回饋，也就沒有阻塞的意義了，就是普通調(diào)用，無所謂阻塞不阻塞了，對吧？

select在等待時間timeout>0的情況下是阻塞的，這時才有你所說的同步。
如果timeout==0，才是非阻塞的，有無數(shù)據(jù)都是立即返回，自然沒有同步問題。

非常感謝

比如發(fā)送緩沖區(qū)中一段數(shù)據(jù)（一個整型數(shù)：0x0A0B0C0D），最合適的發(fā)送方式當是從低址到高址順序發(fā)送，接受也將是順序接收到0A,0B,0C,0D這樣，big-endian正是這種順序。

空格，呵呵，謝謝提醒！:D

構造失敗主要是指new失敗，所以前面也有說不要讓構造函數(shù)做太復雜的事情，可以專門用一個Init去做，拋不拋異常，用哪個版本的new，關鍵在于對象構造失敗之后，使用的時候如果不做檢測會造成代碼崩潰，即使檢測出構造失敗，也無法繼續(xù)執(zhí)行，還是要像處理異常一樣解決問題。

stl之所以會將所有實體的定義和實現(xiàn)置于std命名空間下，正是為了避免出現(xiàn)命名沖突（string\map\vector\list等等），如果使用了using或前置聲明之類，效果等同于將其納入當前命名空間，所以說會導致不明確的行為，命名沖突、不可移植，不知道你同意否？

恩，看過這個指南之后，感覺是因為Google的項目中大多沒有使用高級C++特性，所以對于很多特性都是盡量避免使用，對于自己開發(fā)的項目制定一個自己的風格，大家一起遵循，也基本是從軟件工程的角度，我比較贊成在底層模塊中使用，上層邏輯可以少用即可。

@LOGOS
事實上，在沒有dump的時候，我都是從日志找bug的。

我日......你

這一點在下一篇C++特性中有對禁止使用C++異常的說明，不僅僅是針對構造函數(shù)，是針對整個coding。
不管怎么說，都只是一種編程約束，有利必有弊，感覺更多是從軟件工程的角度給出的約束。

Fn = (phi^n)/(5^(1/2)), phi = 1/2(1+(5^(1/2))).
——計算機程序設計藝術. 第一卷. sec. 1.2.8

我對小波的了解也只是皮毛，是不是變換層數(shù)少了的原因呢？
瞎猜的。

但絕不是小波變換的一點瑕疵；）多半是重構時的問題。

Oh, my God...
哦，俄滴聖啊...

Sorry,我以為都必須放在首頁#--"
謝謝提醒；）

是的，debian是GNU的一款Linux，ubuntu據(jù)說就是基于debian的。我也是剛開始用，主要是為了學習一下Linux的使用;)

為什么我的評論沒了？？強烈抗議！！

看來，這一塊的東西，我又可以偷偷懶，直接請教你了；）