- 主题:c++反射提案正式进入标准
哎，，，洋人就是喜欢简单问题复杂化。
实际上，编译器只需要为每个struct输出一个表，说明里边成员的名称，类型，长度，位置，等即可。这个表也占不了多大空间，爱用不用。
我就是为想泛型处理的struct建个表，运行时用起来也挺方便的，效率不低。
自己弄最难的是位置，得猜编译器的心思。
【 在 ae175b1bf388 的大作中提到: 】
: 应该是跨编译单元需要动态反射, 一次编译好的静态反射就行
:
--
修改:ylh1969 FROM 221.218.61.*
FROM 221.218.61.*
静态反射一点用没有。既然还没脱离编译环境，要反射干啥，直接用成员好了。
【 在 ae175b1bf388 的大作中提到: 】
: 应该是跨编译单元需要动态反射, 一次编译好的静态反射就行
:
--
修改:ylh1969 FROM 221.218.61.*
FROM 221.218.61.*
其实很简单，生成一个xxxx_metainfo的信息表就足够了。
【 在 ae175b1bf388 的大作中提到: 】
: 我觉得是代码里用到的类型metainfo编译进去了, 没用到的就省掉了, 可能理解有误
: 静态反射一点用没有。既然还没脱离编译环境，要反射干啥，直接用成员好了。
--
FROM 221.218.61.*
我设想一个算子解决。
metainfo ＊mtp;
mtp=get_metainfo（xxx_struct）；
这是一个算子，不是函数，普通的函数是无法根据struct去寻找其metainfo的。这一步必须由编译器直接处理。
以后，在运行时使用metainfo就随便了。
而且不管C或C++都可以使用。
然后这样使用mtp就可以了：
struct_to_JSON(json,&xxx_struct,mtp);
这个函数是通用函数，与xxx_struct不在一个编译环境，也不认识它,全靠mtp指引。
如果metainfo是公开的，当然也可以由数据库表构建。
【 在 ae175b1bf388 的大作中提到: 】
: 我觉得是代码里用到的类型metainfo编译进去了, 没用到的就省掉了, 可能理解有误
: 静态反射一点用没有。既然还没脱离编译环境，要反射干啥，直接用成员好了。
--
修改:ylh1969 FROM 221.218.61.*
FROM 221.218.61.*
泛型是必须的，尤其是在高性能数据库操作中，但是静态泛型几乎没啥用，需要的是动态泛型，或者叫运行时泛型。
20年前已经搞成了。
高性能数据库操作，主要是两个东西：
绑定变量和批量操作。
这俩都需要多次的枚举相关列，繁琐而易错。设想一组150多列的表完成一组SQL操作，需要多个语句，每个语句好几遍的枚举列名列值列类型，那有多烦人。
每次用一个循环来代替逐列枚举，就需要泛型工具，但是，楼主说的这个静态反射没用。
参见22楼，虽然编译器没有提供meta信息，我们可以自己搞。22楼仅仅举例简单的序列化。在数据库操作中，一个循环遍历meta信息中的所有列，就解决一次枚举。
文中说动态反射运行时开销大，但是比起高性能数据库访问方法带来的益处，这点开销忽略不计。
有了通用的高性能数据库操作工具，任何一个初哥都可以轻松搞定繁杂的大数据应用。
【 在 yuanmo 的大作中提到: 】
: 20年前就该搞的东西，搞了这个哪还需要那些泛型的奇技淫巧屎上雕花。
:
--
修改:ylh1969 FROM 221.218.61.*
FROM 221.218.61.*
多线程并行是C,C++的优势，其它语言在性能上很难与其匹敌。
【 在 butcher 的大作中提到: 】
: 多线程并行，原子操作，
: 各种反人类设计，
: 用起来非常烧脑，
: ...................
--
FROM 221.218.61.*
对。更经常的场景是映射数据库。
【 在 z16166 的大作中提到: 】
: 你这是无知
: C/C++有很大一部分是映射硬件，硬件和OS有这些东西（OS也是映射硬件），而不是C/C++要强行加这些东西
:
--
FROM 221.218.61.*
可以呀，我就是在做这个工作。
【 在 butcher 的大作中提到: 】
: 永远打着性能的旗号，
: 设计的如屎一样。
: 优化设计，
: ...................
--
FROM 221.218.61.*