跟以前DAO那套的区别是什么？
从数据库表定义，生成：
1 结构体的定义，
2 注册成员变量的代码 // 一会发个链接
3 带两个静态函数，from(xml*) to(xml*) // 也可以是json或任何其他格式

没有模板的概念，从“代码自动生成”的角度看，更好理解吧。
是你的from/to更高效吗？



【 在 ylh0315 的大作中提到: 】
: 你这个也行。
: 不过，你看58，59楼，
: 模板中的数据结构远比struct丰富，它是按照数据库的数据类型定义的。
: ...................
--
FROM 61.185.187.*

换了一种数据库，你这也方案也得改改生成那部分代码，生成新表的“模板”，对吧？
【 在 ylh0315 的大作中提到: 】
: from和to，是通用工具，放在.so,或.a里。
: 在写这个from和to的时候，你不知道要处理的结构是谁。只知道是void *。所以是泛型程序，不针对任何特定的数据。
: 处理效率也是非常高的。
: ...................
--
FROM 61.185.187.*

明白了，除了根据表定义生成数据结构，带正反序列化到某种指定结构化的文档或数据格式，
你的另一个研究点在于从数据库里拖出一块内存，像解析流一样，或先分行，再把每行分成字段（根据每个成员变量的描述，即字节长度），这样一大块内存（查询结果）就变成了多个C的结构体。

只考虑字节长度是不够的，还要考虑对齐问题。这用C语言来做描述挺合适。我的应用数据库不是重点，没考虑这个。不过好奇，每种数据库查询结果，内存块里各行的各字段，对齐是一样的吗？应该也需要实战调试到稳定吧。

sqlite里，查询结果，访问某行的每一列时，有类似getColumn(i)的操作，我没考虑自己解析二进制流算偏移的问题，不擅长，也不喜欢。看你的描述，这是你“绑定1000行”、提高插入查询速度的关键。

第一范式有意思。规范的表设计不应该嵌套。我这里原始的程序存储不是用数据库，是xml，所以我生成的结构体还要支持嵌套。方案就是让生成的结构体统一继承自某个模板类CRTP<P> + enable_if<std::is_base_of>

听了你的描述，感觉到语言确实会影响人的思维和方案的选定。我弄的那套东西，因为一些原因，还用C#改写了一遍，语言原生支持反射，就太简单了。

【 在 ylh0315 的大作中提到: 】
: C的实现是有什么高级的地方吗？
: 不是成员变量指针，相反，成员是指针类型的，除了char，其他的还处理不了。这个设计是基于关系数据库的第一范式，每个成员都是简单类型。
: 每张表生成一个结构体和模板。不带任何函数。
: ...................
--
修改:DoorWay FROM 61.185.187.*
FROM 61.185.187.*