简单的计算器

代码和程序下载










用WTL做的一个小东西，其实是数据结构的作业。WTL来开发这种小东西还是很快的
一个简单的计算器，由于作业是C版本，所以改完了仍然不像C++。
但是可以看到代码减少很多，不需要重造stack。
刚在团队培训的时候听说了一个表达式树，应该用表达式树来做的。
现在要多做些练习，想想未来，看看前面

Source Insight 的文件标签外挂，终于可以用tab了

点击下载
由于不是内置插件机制实现的所以运行Source Insight前要运行这个插件，有点麻烦。
tab有很多可设置的选项，并且支持源代码管理！但是Tab的配色并不好，自己修改一下就可以了
源下载地址见：
TabSiPlus文件标签外挂 for Source Insight

英语课做的一个ppt，宫崎骏

ppt下载
配色和页面布局都花了一些心思，不过内容一般，这个是无音乐版

插件系统-选择GetProcAddress还是Interfaces（原文）

CodeProject上的文章，是外网，可能看起来不方便。
本来是要下Visual Leak Detector才到CodeProject上注册的，后来订阅了 RSS，还不错

Introduction

Plugins are the common way for extending applications. They are usually implemented as DLLs. The host application locates the plugins (either by looking in a predefined folder, or by some sort of registry setting or configuration file) then loads them one by one with LoadLibrary. The plugins are then integrated into the host application and extend it with new functionality.

This article will show how to create a host EXE with multiple plugin DLLs. We'll see how to seamlessly expose any of the host's classes, functions and data as an API to the plugins. There will be some technical challenges that we are going to solve along the way.

We'll use a simple example. The host application host.exe is an image viewer. It implements a plugin framework for adding support for different image file formats (24-bit BMP and 24-bit TGA in this example). The plugins will be DLLs and will have extension .IMP (IMage Parser) to separate them from regular DLLs. Note however that this article is about plugins, not about parsing images. The provided parsers are very basic and for demonstration purpose only.

There are many articles describing how to implement a simple plugin framework. See [1], [2] for example. They usually focus on 2 approaches:

1) The plugin implements a standard (and usually small) set of functions. The host knows the names of the functions and can find the address using GetProcAddress. This doesn't scale well. As the number of functions grows the maintenance gets harder and harder. You can only do so much if you have to manually bind every function by name.

2) The function returned by GetProcAddress is used to pass an interface pointer to the plugin or to obtain an interface pointer from the plugin. The rest of the communications between the host and the plugin is done through that interface. Here's how you do it:

The interface way

Interfaces are base classes where all member functions are public and pure virtual, and there are no data members. For example:

// IImageParser is the interface that all image parsers
// must implement
class IImageParser
{
public:
  // parses the image file and reads it into a HBITMAP
  virtual HBITMAP ParseFile( const char *fname )=0;
  // returns true if the file type is supported
  virtual bool SupportsType( const char *type ) const=0;
};

The actual image parsers inherit from the interface class and implement the pure virtual functions. The BMP plugin can look like this:

// CBMPParser implements the IImageParser interface
class CBMPParser: public IImageParser
{
public:
  virtual HBITMAP ParseFile( const char *fname );
  virtual bool SupportsType( const char *type ) const;

private:
  HBITMAP CreateBitmap( int width, int height, void **data );
};

static CBMPParser g_BMPParser;

// The host calls this function to get access to the
// image parser
extern "C" __declspec(dllexport) IImageParser *GetParser( void )
{
  return &g_BMPParser;
}

The host will use LoadLibrary to load BmpParser.imp, then use GetProcAddress("GetParser") to find the address of the GetParser function, then call it to get the IImageParser pointer.

The host keeps a list of all registered parsers. It adds the pointers returned by GetParser to that list.

When the host needs to parse a BMP file it will call SupportsType(".BMP") for each parser. If SupportsType returns true, the host will call ParseFile with the full file name and will draw the HBITMAP.

For complete sources see the Interface folder in the download file.

The base class doesn't really have to be pure interface. Technically the constraint here is that all members have to be accessible through the object's pointer. So you can have:
- pure virtual member functions (they are accessed indirectly through the virtual table)
- data members (they are accessed through the object's pointer directly)
- inline member functions (they are not technically accessed through the pointer, but their code is instantiated a second time in the plugin)
That leaves non-inline and static member functions. The plugin cannot access such functions from the host and the host cannot access such functions from the plugin. Unfortunately in a large application such functions can be the majority of the code.

For example all image parsers need the CreateBitmap function. It makes sense for it to be declared in the base class and implemented on the host side. Otherwise each parser DLL will have a copy of that function.

Another limitation of this approach is that you cannot expose any global data or global functions from the host to the plugins.

So how can we improve this?

Split the host into DLL and EXE

Take a look at the USER32 module. It has 2 parts – user32.dll and user32.lib. The real code and data is in the DLL, and the LIB just provides placeholder functions that call into the DLL. The best part is that all this happens automatically. You link with user32.lib and automatically gain access to all functionality in user32.dll.

MFC goes a step further – it exposes whole classes that you can use directly or inherit. They do not have the limitations of the pure interface classes we discussed above.

We can do the same thing. Any base functionality you want to provide to the plugins can be put in a single DLL. Use the /IMPLIB linker option to create the corresponding LIB file. The plugins can then link with that library, and all exported functionality will be available to them. You can split the code between the DLL and the EXE any way you wish. In the extreme case shown in the sources the EXE only contains a one line WinMain function whose only job is to start the DLL.

Any global data, functions, classes, or member functions you wish to export must be marked as __declspec(dllexport) when compiling the DLL and as __declspec(dllimport) when compiling the plugins. A common trick is to use a macro:

#ifdef COMPILE_HOST
// when the host is compiling
#define HOSTAPI __declspec(dllexport)
#else
// when the plugins are compiling
#define HOSTAPI __declspec(dllimport)
#endif

Add COMPILE_HOST to the defines of the DLL project, but not to the plugin projects.

On the host DLL side:

// CImageParser is the base class that all image parsers
// must inherit
class CImageParser
{
public:
  // adds the parser to the parsers list
  HOSTAPI CImageParser( void );
  // parses the image file and reads it into a HBITMAP
  virtual HBITMAP ParseFile( const char *fname )=0;
  // returns true if the file type is supported
  virtual bool SupportsType( const char *type ) const=0;

protected:
  HOSTAPI HBITMAP CreateBitmap( int width, int height,
      void **data );
};

Now the base class is not constrained of being just an interface. We are able to add more of the base functionality there. CreateBitmap will be shared between all parsers.

This time instead of the host calling a function to get the parser and add it to the list, that part is taken over by the constructor of CImageParser. When the parser object is created its constructor will automatically update the list. The host doesn't need to use GetProcAddress to see what parser is in each DLL any more.

On the plugin side:

// CBMPParser inherits from CImageParser
class CBMPParser: public CImageParser
{
public:
  virtual HBITMAP ParseFile( const char *fname );
  virtual bool SupportsType( const char *type ) const;
};

static CBMPParser g_BMPParser;

When g_BMPParser is created its constructor CBMPParser() will be called. That constructor (implemented on the plugin side) will call the constructor of the base class CImageParser() (implemented on the host side). That's possible because the base constructor is marked as HOSTAPI.

For complete sources see the DLL+EXE folder in the download file.

Wait, it gets even better:

Combine the host DLL and the host EXE

Usually an import library is created only when making DLLs. It is a little known trick that import library can be created even for EXEs. In Visual C++ 6 the /IMPLIB option is not available directly for EXEs as it is for DLLs. You have to add it manually to the edit box at the bottom of the Link properties. In Visual Studio 2003 it is available in the Linker\Advanced section, you just have to set its value to $(IntDir)/Host.lib.

So there you go. You have a host EXE, a number of plugin DLLs, and you can share any function, class or global data in the host with all plugins. There is no need to use GetProcAddress at all, ever, since the plugins can register themselves with the host's data structures.

For complete sources see the EXE folder in the download file.

........ incomplete

插件系统-选择GetProcAddress还是Interfaces（译）

插件系统-选择GetProcAddress还是Interfaces（译）
原文：
Plugin System – an alternative to GetProcAddress and interfaces
代码下载

[介绍]
有很多文章描述如何实现一个简单的插件框架，比如后面的链接[1]和[2]。通常有两种方法
(1)插件实现一组标准的（并且通常是小的）函数（方法）。宿主（host)知道这些函数的名字，并且可以通过使用GetProcAddress函数获得这些函数的地址。这并不合适，随着函数数量的增长，维护变得越来越困难。你必须手动通过函数名绑定函数，这样你就不得不做很多工作。
(2)GetProcAddress所返回的函数被用来传递接口指针（Interface Pointer）给插件或者从插件里获取接口指针。剩下的宿主和插件的通信通过接口完成。下面是一个例子

我们将使用一个简单的例子。宿主程序是一个图片查看器。它实现了一个插件框架来增加对不同图片格式的支持（在这个例子中就是24-bit的BMP图象和24-bit的TGA(Targa)图象）。插件将被实现为DLLs并且将有.imp的扩展名以便和普通dll文件区分开来了.注意，尽管如此，可是这篇文章是关于插件的，而不是关于图象解解析器的。这里所提供的解析器非常基础并且只是用来说明的。


[使用接口的方法]
接口是所有函数都是公共的并且纯虚的基类，并且没有没有数据成员。比如
// IImageParser is the interface that all image parsers
// must implement
class IImageParser
{
public:
// parses the image file and reads it into a HBITMAP
virtual HBITMAP ParseFile( const char *fname )=0;
// returns true if the file type is supported
virtual bool SupportsType( const char *type ) const=0;
};

实际的图象解析器必须继承自接口类并且实现纯虚函数。BMP文件解析器可能是这个样子。

// CBMPParser implements the IImageParser interface
class CBMPParser: public IImageParser
{
public:
virtual HBITMAP ParseFile( const char *fname );
virtual bool SupportsType( const char *type ) const;

private:
HBITMAP CreateBitmap( int width, int height, void **data );
};

static CBMPParser g_BMPParser;

// The host calls this function to get access to the
// image parser
extern "C" __declspec(dllexport) IImageParser *GetParser( void )
{
return &g_BMPParser;
}

宿主将使用LoadLibrary函数来载入BmpParser.imp，然后使用GetProcAddress("GetParser")来得到GetParser函数的地址，然后调用它得到IImageParser类的指针。
宿主将保存了注册了的解析器的邻接表(list)，它把GetParser函数返回的指针附加到那个邻接表上去。
当宿主需要解析一个bmp文件的时候，它将调用每个解析器的SupportType(".BMP")。如果返回类型是true,宿主将调用那个解析器并且使用完整文件名调用待解析文件，并将绘制HBITMAP句柄指向的位图。

基类并不真的必须是纯接口。在技术上这里的限制是所有的成员必须可以通过对象指针访问。所以你可以有：
- 纯虚成员函数（它们能通过虚表被间接访问）
- 数据成员（它们可以通过对象的指针直接访问）
- 内联成员函数（技术上它们不能通过指针访问，但是它们的代码又一次在插件里实例化。
这样就剩下了非内联和静态成员函数。插件无法从宿主访问这样的函数，宿主也不能对插件进行这样的操作。不幸的是在一个大型系统之中，这样的函数要占据代码的大部分。

例如所有的图象解析器需要CreateFunction函数。有必要在基类里声明它并且在宿主端实现。否则每个插件都将有一份这个函数的拷贝。
这个方法的另一个限制是你不能由宿主端暴露任何全局成员或者全局函数给插件端。
我们怎么改进呢?

[把宿主分成Dll和Exe]
让我们看一下USER32模块，它有两个部分 - user32.dll 和 user32.lib。真正的代码和数据在dll中，lib仅仅提供调用dll函数的占位函数。最好的事情在于它是自动发生的。当你链接到user32.lib你就自动地获得访问user32.dll函数的权利。（这里翻译的不好）
MFC 实现得更进一步 - 它暴露你能直接使用和继承的整个类。它们没有我们在上面讨论的纯虚接口类的限制。
我们也能做同样的事情。任何你想提供给插件的函数（我私下觉得原文functionality这个词用得不好）都能放在一个单独的Dll里。使用/IMPLIB 链接器选项来创建相应的 LIB 文件。插件能与那个静态库链接，并且所有导出函数都能提供给它们。你能按你喜欢的方式把代码分成Dll 和 Exe。极限情况下，像在代码里演示的那样，Exe 工程里仅仅含有一行WinMain函数，它仅仅用来启动Dll。
任何你想要导出的全局数据，函数，类，或者成员函数必须被标记为 __declspec(dllexport) 在编译插件时。一个常用的技巧是使用宏

#ifdef COMPILE_HOST
// when the host is compiling
#define HOSTAPI __declspec(dllexport)
#else
// when the plugins are compiling
#define HOSTAPI __declspec(dllimport)
#endif

添加宏COMPILE_HOST的定义到Dll工程里，但是不加到插件工程里。

在宿主Dll端：

// CImageParser is the base class that all image parsers
// must inherit
class CImageParser
{
public:
// adds the parser to the parsers list
HOSTAPI CImageParser( void );
// parses the image file and reads it into a HBITMAP
virtual HBITMAP ParseFile( const char *fname )=0;
// returns true if the file type is supported
virtual bool SupportsType( const char *type ) const=0;

protected:
HOSTAPI HBITMAP CreateBitmap( int width, int height,
void **data );
};

现在基类并不仅仅限于一个接口。我们能增加更多基本功能。CreateBitmap函数将被所有解析器共享。
这次不再是宿主调用一个函数来获取解析器并且将它添加到邻接表中，这个功能被CImageParser的构造函数取代。当解析器对象被创建，它的构造函数将自动更新邻接表。宿主不必再使用GetProcAddress函数来看看什么解析器在Dll里。

在插件端：

// CBMPParser inherits from CImageParser
class CBMPParser: public CImageParser
{
public:
virtual HBITMAP ParseFile( const char *fname );
virtual bool SupportsType( const char *type ) const;
};

static CBMPParser g_BMPParser;

当g_BMPParser被创建是它的构造函数 CBMPParser() 将被调用。那个构造函数（在插件端实现）将调用基类的构造函数CImageParser() （在宿主端实现）。那是可能的因为构造函数被标记为HOSTAPI。
等等，还可以变得更好

[把宿主Dll和Exe连接起来]
（这一部分暂时没翻译）

[链接]
[1] Plug-In framework using DLLs by Mohit Khanna
[2] ATL COM Based Addin / Plugin Framework With Dynamic Toolbars and Menus by thomas_tom99

PS.我想，Interface方法，是在第一种方法之上加入了一个间接层。
我现在到没有太强的感觉非内联函数和静态函数会成为这样一个大型系统的主要部分，Interface的派生类中的非内联函数应该只被纯虚接口函数调用，不然就是接口设计有问题了。