你可以使用函数指针来伪装它，事实上，我认为理论上可以将c++程序编译成C语言。

然而，将一种范式强加于一种语言，而不是选择一种使用范式的语言，很少有意义。

这本书读起来很有趣。我自己也在思考同样的问题，思考这个问题的好处是:

Trying to imagine how to implement OOP concepts in a non-OOP language helps me understand the strengths of the OOp language (in my case, C++). This helps give me better judgement about whether to use C or C++ for a given type of application -- where the benefits of one out-weighs the other. In my browsing the web for information and opinions on this I found an author who was writing code for an embedded processor and only had a C compiler available: http://www.eetimes.com/discussion/other/4024626/Object-Oriented-C-Creating-Foundation-Classes-Part-1

在他的案例中，用普通C语言分析和调整面向对象的概念是一种有效的追求。他似乎愿意牺牲一些面向对象的概念，因为尝试用C语言实现它们会带来性能开销。

我得到的教训是，是的，在某种程度上它是可以做到的，是的，有一些很好的理由去尝试。

In the end, the machine is twiddling stack pointer bits, making the program counter jump around and calculating memory access operations. From the efficiency standpoint, the fewer of these calculations done by your program, the better... but sometimes we have to pay this tax simply so we can organize our program in a way that makes it least susceptible to human error. The OOP language compiler strives to optimize both aspects. The programmer has to be much more careful implementing these concepts in a language like C.

有几种技术可以使用。最重要的是如何分割项目。我们在项目中使用的接口是在.h文件中声明的，对象的实现是在.c文件中。重要的部分是，所有包含.h文件的模块都只将对象视为void *，而.c文件是唯一知道结构内部的模块。

以FOO类为例:

在。h文件中

#ifndef FOO_H_
#define FOO_H_

...
 typedef struct FOO_type FOO_type;     /* That's all the rest of the program knows about FOO */

/* Declaration of accessors, functions */
FOO_type *FOO_new(void);
void FOO_free(FOO_type *this);
...
void FOO_dosomething(FOO_type *this, param ...):
char *FOO_getName(FOO_type *this, etc);
#endif

C实现文件就像这样。

#include <stdlib.h>
...
#include "FOO.h"

struct FOO_type {
    whatever...
};


FOO_type *FOO_new(void)
{
    FOO_type *this = calloc(1, sizeof (FOO_type));

    ...
    FOO_dosomething(this, );
    return this;
}

因此，我明确地将指针指向该模块的每个函数。c++编译器隐式地完成它，而在C中我们显式地将它写出来。

我真的在我的程序中使用了这个，以确保我的程序不是用c++编译的，而且它在我的语法高亮编辑器中有另一种颜色的良好属性。

FOO_struct的字段可以在一个模块中修改，而另一个模块甚至不需要重新编译就仍然可用。

通过这种风格，我已经处理了OOP(数据封装)的很大一部分优点。通过使用函数指针，甚至可以很容易地实现继承之类的东西，但老实说，它真的很少有用。

是的。事实上，Axel Schreiner免费提供了他的书《ANSI-C中的面向对象编程》，这本书相当全面地涵盖了这个主题。

关于c语言OOP的另一个变化，请参阅http://slkpg.byethost7.com/instance.html。它强调仅使用本机c实现实例数据的可重入性，多重继承使用函数包装器手动完成。保持型号安全。下面是一个小例子:

typedef struct _peeker
{
    log_t     *log;
    symbols_t *sym;
    scanner_t  scan;            // inherited instance
    peek_t     pk;
    int        trace;

    void    (*push) ( SELF *d, symbol_t *symbol );
    short   (*peek) ( SELF *d, int level );
    short   (*get)  ( SELF *d );
    int     (*get_line_number) ( SELF *d );

} peeker_t, SlkToken;

#define push(self,a)            (*self).push(self, a)
#define peek(self,a)            (*self).peek(self, a)
#define get(self)               (*self).get(self)
#define get_line_number(self)   (*self).get_line_number(self)

INSTANCE_METHOD
int
(get_line_number) ( peeker_t *d )
{
    return  d->scan.line_number;
}

PUBLIC
void
InitializePeeker ( peeker_t  *peeker,
                   int        trace,
                   symbols_t *symbols,
                   log_t     *log,
                   list_t    *list )
{
    InitializeScanner ( &peeker->scan, trace, symbols, log, list );
    peeker->log = log;
    peeker->sym = symbols;
    peeker->pk.current = peeker->pk.buffer;
    peeker->pk.count = 0;
    peeker->trace = trace;

    peeker->get_line_number = get_line_number;
    peeker->push = push;
    peeker->get = get;
    peeker->peek = peek;
}

当然这是可能的。这就是所有GTK+和GNOME所基于的框架GObject所做的工作。