静态反射没啥用，在某个struct的编译环境中，直接使用成员不好吗？为啥要脱裤子放屁？
看22楼，做个公用程序，或者叫做独立于数据的程序，这个程序与他要处理的struct不在一个编译单元，因此它不认识提交的struct，这时才需要反射。
论访问数据库的性能，与JAVA比起来，可不是差一星半点，应该是有数量级的差距，按照27楼的方法。
一般人比较JAVA与C访问数据库的性能，用相同的语句比较，那是差不多，但是用上绑定变量和数组操作，性能就不是JAVA可比的了。
这两个操作，需要多次的枚举每个列名，类型，位置。
如果想做个通用的程序，用于简化编程，就需要动态的反射。
【 在 yuanmo 的大作中提到: 】
: 有静态反射就足够做很多事情了，以前得用大量时间做meta programming用来映射RPC和数据库之类，技巧一大堆，代码一大坨，就实现了一个别的语言内置的功能。
: C++非得纠结那一丢丢可以忽略不计的性能损失，宁可把开发效率降低50%。不可思议。
: 尤其是抛弃C++，用go、python、Typescript之后，回头再看C++，越看越觉得是屎，当年对C++有多熟悉，现在就有多讨厌这坨屎上雕花的奇技淫巧。
: ...................
--
修改:ylh1969 FROM 221.218.61.*
FROM 221.218.61.*

15年了，你见过c的ORM工具吗？
数据库还得访问，屎山还是屎山，我20年前的工作，把屎山封闭在库里，外部的使用，简洁而优雅，至今没有一个工具出现能够取代。这不听说有反射了，挺高兴，结果是静态的，没啥用。
那时JAVA就有hibernate和ibatis。靠的就是运行时反射。
我的工具库就是出于hibernate而胜于它。
【 在 yuanmo 的大作中提到: 】
: 这种都是15年前的思维了，都落后两个时代了。
:
--
修改:ylh1969 FROM 221.218.61.*
FROM 221.218.61.*

你说的也不错，我致力于解决这个矛盾，让运行效率与开发效率都高。
办法就是写框架，完成高效率的C/S/S的客户服务器模型，包括大并发的客户端连接，多进程，多线程，线程池+协程的并行模式，三维连接池管理，管理多个功能各自不同的业务组，每个业务组由相同功能的多个服务器组成，每个服务器有多个连接，每个连接一个线程或进程。每个业务组实现负载均衡和容错以及排队机。在服务端实现了数据库的优雅访问，把高效率数据库访问通常所需要的屎山代码封装在工具库里。同时，包括自愈式数据库连接池，当数据库故障时，服务器不必重启，等数据库恢复了，服务自动恢复。
干了前后30年，也取得一些成效，带过若干个项目组，经过4小时的说明培训，都能顺利使用其基本功能。一周后就能玩出花来。应用程序作为插件，用统一的接口标准插入框架，不必关心什么进程线程协程，也不必关心同步异步，block nonblock。。。
更重要的，框架提供了柔性编程的能力。
当开发一个大型数据库应用项目时，数据结构的改变是经常的。每次改变都要修改屎山代码，都必须rewiew所有的屎山代码，这太痛苦了。框架提供了柔性手段，整个项目所需的数据库表，统一把各个表映射的struct和meta信息放在一个data.cpp里，这个cpp是用工具自动生成的，也算是屎山吧，好在不用人写。当数据结构改变时，重新生成data.cpp即可，没有被涉及到的模块基本不用管。重新编译即可。

以一个10人左右的应用项目组为例，如果没有柔性编程，改变一次数据结构，要review两天，有了柔性编程，只需要十几分钟，数据库管理员修改数据结构后，重新生成data.cpp，然后通知组员重新编译。

【 在 siyuetian 的大作中提到: 】
: 怎么说呢，码农也是人，人会用脚投票。
: 开发效率是很明显的，不考虑ai来写的话，cpp远低于java/python/go之类的，这没啥可说的。
: 性能就很有说到了，高并发叫性能，低延迟也叫性能。cpp可以实现高并发，可能代码远不如其他语言那么优雅，或者直白点，恶心的想死。但是其他语言能实现cpp的低延迟吗？至少java/python/go都证明了他们不行。rust我不熟悉，不评论。
: ...................
--
修改:ylh1969 FROM 221.218.61.*
FROM 221.218.61.*