习惯成自然

原因:当前版本的direct sdk已经将DirectShow分离了，当前版本的sdk没有dxtrans.h文件
解决方法:在include "dxtrans.h"前加上

 

1. #define __IDxtCompositor_INTERFACE_DEFINED__  
2. #define __IDxtAlphaSetter_INTERFACE_DEFINED__  
3. #define __IDxtJpeg_INTERFACE_DEFINED__  
4. #define __IDxtKey_INTERFACE_DEFINED__  

 

并将dxtrans.h注释掉

////////////////////////////////////////////////////////////////////////////////////////////////////////////
//在stdafx.h中的最前面添加
////////////////////////////////////////////////////////////////////////////////////////////////////////////
#ifndef WINVER     // Specifies that the minimum required platform is Windows Vista. 
#define WINVER 0x0500   // Win2k 
#endif

#ifndef _WIN32_WINNT   // Specifies that the minimum required platform is Windows Vista. 
#define _WIN32_WINNT 0x0500  // Win2k 
#endif 

    今天一个同事移植一个代码，需要用到一个库，弄了半天代码移植过来后，好容易可以编译的过了，正开心准备收工，报链接错误了，我一看一堆std::string link error, 弄了半天才发现原来这个库是VS2003编写的，而现在是用VS2008来编译，VS不同版本标准库产生的接口不一致(C++函数编译后函数名产生规则不同)产生的问题吧，叫同事挖出多年前的代码，用2008编译后，没问题了

    在工作中需要显式的调用一个DLL里的函数，用到了AfxLoadLibrary，一直报127错误，用err查说是找不到指定的程序，一开始认为相应目录是没有该DLL，认真查了后发现是有该DLL的，没有DLL时的错误号是126，一下弄不清楚是什么原因，后来想起好像这个DLL依赖另一个DLL，另一个DLL忘记放该目录了，把该DLL放进目录一试，果然没有问题了

    遇到一个工程，用到一个静态链接库，很奇怪项目->属性->链接器->输入->附加依赖项没有写该静态库，项目文件中也没有用到任何

#pragma comment( lib，XXX）， 项目却可以正常启动，查看链接器->命令行却发现这个库已经在命令行里了
/ERRORREPORT:PROMPT XXX.lib,是VS的哪个功能选项让这个项目主动的依赖这个静态库了，答案在这里，首先，工程属性->通用属性->项目依赖项让
该项目依赖静态链接库工程，然后将项目->属性->链接器->常规->链接库项目依赖项选是，那么VS会自动将静态链接库作为附加依赖项了

windows live writer 无法连接blog，弹出错误提示blogConfig为空

从网页上登录blog,在选项-config弹出的页面最下方允许web service. MetaWeblog访问勾上，下方的链接就是

你的MetaWeblog地址

进入单步模式
# fsck -y
# mount -u /
#mount /usr
# ee /etc/rc.conf

HP STL
HP STL是所有其它STL实现版本的根源。它是STL之父Alexander Stepanov在惠普的Palo Alto实验室工作时，和Meng Lee共同完成的，是第一个STL的实现版本（参见1.2节）。这个STL是开放源码的，所以它允许任何人免费使用、复制、修改、发布和销售该软件和相关文档，前提是必须在所有相关文件中加入HP STL的版本信息和授权信息。现在已经很少直接使用这个版本的STL了。

P.J. Plauger STL http://www.dinkumware.com。据称Visual Studio.NET中的Visual C++.NET（即VC7.0），对C++标准的支持有所提高，并且多了以哈希表（hash table）为基础而实现的map容器，multimap容器和set容器。

P. J. Plauger STL属于个人作品，由P. J. Plauger本人实现，是HP STL的一个继承版本，因此在其所有头文件中都含有HP STL的相关声明，同时还有P. J. Plauger本人的版权声明。P. J. Plauger是标准C中stdio库的早期实现者，现在是C/C++ User's Journal的主编，与Microsoft保持着良好的关系。P. J. Plauger STL便是被用于Microsoft的Visual C++中的。在Windows平台下的同类版本中，其性能不错，但是queue组件（队列，一种容器）的效率不理想，同时由于Visual C++对C++语言标准的支持不是很好（至少直到VC6.0为止，还是如此），因此一定程度上影响了P. J. Plauger STL的性能。此外，该版本的源代码可读性较差，你可以在VC的Include子目录下找到所有源文件（比如：C:\Program Files\Microsoft Visual Studio\VC98\Include）。因为不是开放源码的（open source），所以这些源代码是不能修改和销售的，目前P.J. Plauger STL由Dinkumware公司提供相关服务，详情请见

Rouge Wave STL http://www.rougewave.com。遗憾的是该版本已有一段时间没有更新且不完全符合标准。因此在Borland C++ Builder 6.0中，它的地位被另一个STL的实现版本--STLport（见后）取代了。但是考虑到与以前版本的兼容，C++ Builder 6.0还是保留了Rouge Wave STL，只是如果你想查看它的源代码的话，需要在别的目录中才能找到（比如：C:\Program Files\Borland\Cbuilder6\Include\oldstl）。

Rouge Wave STL是由Rouge Wave公司实现的，也是HP STL的一个继承版本，除了HP STL的相关声明之外，还有Rouge Wave公司的版权声明。同时，它也不是开放源码的，因此无法修改和销售。该版本被Borland C++ Builder所采用，你可以在C++ Builder的Include子目录下找到所有头文件（比如：C:\Program Files\Borland\Cbuilder5\Include）。尽管Rouge Wave STL的性能不是很好，但由于C++ Builder对C++语言标准的支持还算不错，使其表现在一定程度上得以改善。此外，其源代码的可读性较好。可以从如下网站得到更详细的情况介绍：

STLport http://www.stlport.org，可以免费下载其源代码。STLport已经被C/C++技术委员会接受成为工业标准，且在许多平台上都支持。根据测试STLport的效率比VC中的STL要快。比Rouge Wave STL更符合标准，也更容易移植。Borland C++ Builder已经在其6.0版中加入了对STLport的支持，它使用的STLport就是4.5版的，C++ Builder 6.0同时还提供了STLport的使用说明。你可以在C++ Builder的Include\Stlport子目录下找到所有头文件（比如：C:\Program Files\Borland\Cbuilder6\Include\Stlport）。

STLport最初源于俄国人Boris Fomitchev的一个开发项目，主要用于将SGI STL的基本代码移植到其他诸如C++Builder或者是Visual C++这样的主流编译器上。因为SGI STL属于开放源码，所以STLport才有权这样做。目前STLport的最新版本是4.5。可以从如下网站得到更详细的情况介绍：

SGI STL http://www.sgi.com，可以免费下载其源代码。目前的最新版本是3.3。

SGI STL是由Silicon Graphics Computer System, Inc公司实现的，其设计者和编写者包括Alexander Stepanov和Matt Austern，同样它也是HP STL的一个继承版本。它属于开放源码，因此你可以修改和销售它。SGI STL被GCC（linux下的C++编译器）所采用，你可以在GCC的Include子目录下找到所有头文件（比如：C:\cygnus\cygwin-b20\include\g++\include）。由于GCC对C++语言标准的支持很好，SGI STL在linux平台上的性能相当出色。此外，其源代码的可读性也很好。可以从如下网站得到更详细的情况介绍：

本文来自CSDN博客，http://blog.csdn.net/nicole_q/archive/2007/11/04/1866889.aspx

指针的赋值比较简单，但是粗心的话，还是比较容易弄错，小菜我比较粗心，就在一开始看到以下代码的时候，云里雾里的，一下没看明白为什么要用_Iterator_base ** 来实现这个功能。

void __CLR_OR_THIS_CALL _Orphan_me()
    {    // cut ties with parent
    if (_Mycont != 0 && _Mycont->_Myfirstiter != _IGNORE_MYITERLIST)
        {    // adopted, remove self from list
        _Iterator_base **_Pnext =
            (_Iterator_base **)&_Mycont->_Myfirstiter;
        while (*_Pnext != 0 && *_Pnext != this)
            _Pnext = &(*_Pnext)->_Mynextiter;

        if (*_Pnext == 0)
            _DEBUG_ERROR("ITERATOR LIST CORRUPTED!");
        *_Pnext = _Mynextiter;
        _Mycont = 0;
        }
    }

实话说，小弟我琢磨了好一会儿了，才恍然大悟，其实，换个例子相信大家一眼就看出来了

int a = 100;
int b = 200;
int* pA = &a;
int *pB = pA; *pB = 300;
pB = &b; //pA指向的指针肯定是没有变的

以pB为例，与pB对应的有&pB, pB, *pB,三种值，如下

0x0012fee8指pB的地址，这个地址的值是什么呢？？我们再看

因为我们事先知道这个地址下是一个指针，在win32下指针32位,按高高低低原则，则这个地址的值是0x0012ff0c,假如这个地址表示的是一个字节如char,则值就是0x0c,如果两个字节，则0xff0c,如果3个字节(。。。需要字对齐吧)。还是因为我们事先知道这个内存是个指针，他的值是0x0012ff0c，那我们继续看看0x0012ff0c的值是多少

因为知道这个地址是int*指针，所以按int解释这个值就是 0x0000 0064 = 100了,

有了这几个图，那就可以看看 *pB = 300; pB = &b到底改变了啥了

断点先断到*pb = 300后，继续看内存，发现执行好这句后

0x12fee8的值没有变，还是0x12ff0c, 0x12ff0c的值变了，变为0x0000012c了

pB = &b？

 

现在pB内存的值变为0x0012ff00了，而*pB的值就是内存0x0012FF00的值变为 0x000000c8了

好，看图说话到这里了，最后总结一下。初学者，很菜，多关照

class CTest

{

public:

CTest() {std::cout << “hello world from windows write” << std::endl;}

~CTest() {std::cout << “bye from windows write” << std::endl;}

private:

NO_COPY(CTest);

};