【 在 DoorWay 的大作中提到: 】
: https://eliasdaler.github.io/meta-stuff/
: 照着这个写的，精简后就200行。看他github上的源码更直接。
: 我模仿了他的思路，tuple + index_sequence，前面的函数指针
: ...................

很简单，它这个Member类完全可以与对象类型无关：

template <typename T>
class Member : public IMember {
public:
    Member(size_t offset) : offset(offset) {}

    void fromJson(void* obj, const json& j) const override
    {
        *(T*)((char*)obj+offset) = j;
    }

    json toJson(const void* obj) const override
    {
        return json(*(const T*)((const char*)obj+offset));
    }

private:
    size_t offset;
};

考虑到offset是个常量，你把offset挪到模板参数里也行。
实际上T Class::*底下实际实现就是个offset，但它完全没必要地带了T和Class类型，导致你每个Class都对应一套Member，而它们实际实现是完全一样的，不知道编译器能不能优化掉。

注册这样写：member<typeof(Person::age)>("age", offsetof(Person, age))
当然可以写个宏把typeof和offsetof隐藏掉。

或者我这样问吧，明明对于每个Class，MetaHolder<Class>已经存了Class类型了，为什么里面每个Member还要再存一遍Class类型呢？有什么好处？
Member只需要name, type, offset，这些其实和特定Class无关的。
--
修改:ilovecpp FROM 58.37.58.*
FROM 58.37.58.*

你只要保证自己的实现正确，MetaHolder<Class>里没有错放别的类的Member，类型安全就没有问题。用户接触不到你内部的void*。
序列化里用void*那可太多了。难道我从二进制反序列化int时候就不能*(int*)buf，非得读四个字节出来用位操作拼么？序列化本来就是一个不讲究类型安全的场合。

【 在 DoorWay 的大作中提到: 】
: 但它完全没必要地带了T和Class类型，导致你每个Class都对应一套Member，
: 每个class都对应一套Member，——这点有道理。我看到这种方案时，第一反应也是这。我主要是担心编译慢。在另一处看了类似方案，目前主流都是每个类背后一个tuple。于是就随流了。
: Class类型和void*对比，不能完全说多余。类型安全，不会传错obj。这是除了面向对象，我学cpp排第二的根深蒂固的思想。
: ...................
--
FROM 58.37.58.*

这种错误的概率嘛，我们先问一下，是用户用得不对可以引发类型错误，还是只有你这两百行代码里面的bug可以引发类型错误？应该是只有后者。

我觉得那就无所谓了。这两百行代码里的bug可以引发的错误那可多了去了，不差这个。

你看std::map里面的树节点为什么要擦除掉元素类型，它不怕树里面混进别的类型的元素？不怕的嘛。

【 在 DoorWay 的大作中提到: 】
: *(int*)buf是不可避免的。我从reinterpret_cast这种就可以反证，虽然我从没用过。
: 我说的是把ClassB* obj 传给 ClassA 的Member.FromJson。类的类型错误和属性的属性的类型错误，我认为是两个问题，起码是有距离的两个问题。
: 这种错误多大概率、预防这种错误有多大价值、下多大力气，或者说程序员应该多大程度自律，见仁见智了。老派C程序员可能是古典自由主义，我这种半吊子cpp程序员，可能是新保守主义。:-)
--
修改:ilovecpp FROM 58.37.58.*
FROM 58.37.58.*

你面向用户的接口，比如member函数/宏，可以带Class类型。但你内部实现，比如Member，并不一定要带类型。接口已经保证了类型正确。

std::map同理。接口当然不允许你插入类型不对的元素。但内部比如维护红黑树的代码，并不需要知道元素类型，是实现成非模板普通函数的。

【 在 DoorWay 的大作中提到: 】
: 我的初衷是用户用的不对，编译时能提示。这种不叫类型错误吗？我是不是用错术语了……你说只有后者，我没跟上。
: 接下来就都是请教的时间了。我还是懂得太少了～
:  std::map的树节点擦掉了类型吗，愿闻其详哈。
: ...................
--
FROM 58.37.58.*

哦，是啦。是ClassA::ToJson，ClassB::ToJson这样的。
我需要一点时间，看下为什么我没设计成这样子。而是从了链接的方案，
设计成了一个 free function。而不是类的method。
【 在 ilovecpp 的大作中提到: 】
: 你面向用户的接口，比如member函数/宏，可以带Class类型。但你内部实现，比如Member，并不一定要带类型。接口已经保证了类型正确。
: std::map同理。接口当然不允许你插入类型不对的元素。但内部比如维护红黑树的代码，并不需要知道元素类型，是实现成非模板普通函数的。
--
FROM 124.114.151.*