【有奖讨论】随着 C++11 的巨大变化，谈谈你对新STL的展望

lcofjp

回复 18# shang2010


    不同平台sizeof(int)都不一样，难道要统一？统一有什么意义？

windoze

回复 29# yulihua49

如果你能把数据类型限制在有限的几个种类，用type switch能简单点。
比如：

1. 
   
2. // @SEE: https://github.com/windoze/cxxstuff
   
3. #include <cxutil/variant.hpp>
   
4. 
   
5. typedef cxutil::variant<int,double,std::string> DBVariant;
   
6. 
   
7. struct RDB_set_col_visitor {
   
8.     RDB_insert_visitor(DB_cursor *cursor, String column);
   
9.     int operator()(int x) &&;
   
10.     int operator()(double x) && ;
    
11.     int operator()(const std::string &x) &&;
    
12. };
    
13. 
    
14. DBVariant var(123.45);
    
15. 
    
16. var.apply_visitor(RDB_set_col_visitor(cursor, "some_col"));
    

复制代码

不过你想把一个struct直接映射到一个Row还是没什么好办法。

C++目前完全没有任何办法遍历任意一个struct的成员，所以我在想用clang的compiler plugin写个代码生成器，实现类似Rust的Macro的功能。

shang2010

回复 31# lcofjp


    反正我有个习惯，写好代码后会测试一下再commit

yulihua49

windoze 发表于 2015-07-06 15:57
回复 29# yulihua49

如果你能把数据类型限制在有限的几个种类，用type switch能简单点。

这是你做的？不过还不是ORM，没有逃脱流式访问数据库的宿命。没办法做成JAVA的Hibernate那样的东西？

把结构体映射成数据库行。我已经实现了，它不能反射，我就它写一个说明书，纯C的。
这个“说明书”也可以称为“运行时模版”。它可用于结构的序列化/反序列化，也可以映射数据库。
还可以配合自制的容器，如BB_Tree，Multi_Hash等进行内存数据库管理。
感觉一旦实现了这个映射，就打开了通向世外桃源之路。
所以我希望C++尽快实现对象反射，这是根本性的升级。
有了对象反射，说实在的，STL没啥用。
运行时泛型，比编译时泛型，好得。。。。根本不是一个世界。

windoze

回复 34# yulihua49

反射和TMP……完全不是一种东西么，一个是纯运行时，一个是纯编译时。
这两个东西拿来比谁好谁坏，有点关公战秦琼的赶脚……

yulihua49

windoze 发表于 2015-07-06 20:52
回复 34# yulihua49

反射和TMP……完全不是一种东西么，一个是纯运行时，一个是纯编译时。

STL吧？
STL：任意对象
加入map，检索map，迭代map
ORM：任意表（或SQL）
插入数据库，检索数据库，fetch数据库。

ORM的基础是OM，Object mapping ---- 对象反射。
有了OM，不仅可以ORM，也可以动态对象处理，类似STL的工作，可以运行时处理。
所有STL那些功能，可以建立运行时库，就是框架，像JAVA那样。可以不在编译期处理了----把STL改成运行时。


这个想法的来源，一个哥们看了我的SRM --- Struct Relational Mapping，问我，为什么不弄成STL那样---他极其崇拜STL。
我看了一下STL，感觉完全不是一回事。原因呢，一个是运行时，一个是编译时。
还有，一个是在对象之外处理对象，如把它加入vector,map什么的，一个是在结构（对象）之内处理他的内容。
但是他们也有相似之处，如开头所示。

windoze

回复 36# yulihua49

TMP是指template meta-programming

C++的问题就是完全不能做反射，当然反射其实也不一定完全是运行时的东西，比如说Rust里的serialization就会在编译过程中给需要支持序列号反序列化的struct自动按照成员生成展开的代码，比如：

1. 
   
2. #[derive(Decodable, Encodable)]
   
3. struct S{
   
4.     a: u32,
   
5.     b: double
   
6. }
   

复制代码

Rust会遍历这个S，对a和b分别生成read_struct_field/emit_struct_field，结果就是Rust在编译器解决了绝大多数反射所需的功能，并且生成了一些代码让运行期反射也可用，同时没有Java通过反射进行动态调用的开销。

Clang可以做compiler plugin，也许可以拿来实现类似的功能，我这两天正在看。

yulihua49

windoze 发表于 2015-07-07 14:26
回复 36# yulihua49

TMP是指template meta-programming

类似的东西，有个RTMI？
还有个XDR，但是都不能做SRM。
所以，这个轮子，不能不造。
现在，不管访问什么数据库，我一律SRM，决不再用OCI，PRO*C,CLI  什么的。

http://bbs.chinaunix.net/thread-4153426-1-1.html

陌路巨额投入

1、你是否完整的了解过C++98: 2003 标准下的STL设计和实现，并且对你产生了怎么样的影响?
           说实话，这个没有完整的了解过，以前在做windows驱动开发的时候有过研究，但是现在大部分工作已经是Linux的底层驱动了，对于C++现在只有在周末时候才有研究，不过现在缺少这类书籍。对我的影响：现在在项目设计的时候自己经常会使用泛型实现最为常用的容器，迭代器，和算法。容器为你可以拼命加入同类对象而不必关心其容量大小的东西，除非内存空间已用完，它会自动为你调整空间，使你从底层细节的苦海脱离岀来，用更多的精力去创造更为实用的东西，迭代器为容器的索引，类似语言所定义的指针，然而这东西并不是指针，明显地说，它是精心设计的与各种容器相匹配的众多类的某个类的对象，简单说它是一个类对象，对其进行自增与自减操作与指针的不同是它返回的是逻辑上相连的元素的索引，元素对象可能分散在不同的物理空间，而对指针进行同样的操作只是简单地向前或后移动对象大小个字节的物理地址，并且你没有方法去检测你指针的索引已经脱离对象队列，因此更易产生致命错误。给我们提拱相同算法使用的灵活性。

2、你是否认同在开发同应该尽量使用STL，而不是自信的经常重复造轮子？
           我个人比较认同应该尽量使用STL。因为经常重复造轮子，这在工作之中，虽然这个更快，但是代码的健壮性和可阅读性不好。而且这个的代码的时间和空间复杂度有会有影响，对于实时操作系统会有影响。

3、你对C++11标准下的STL有什么样的期望，新的STL特性目前有使用吗？
          对于新的STL的期望，能够出一些实用简单的类库，方便外部调用，还有容器能够简化。新的STL特性目前有使用过的。这个有研究过的，自己去试验学习的时候使用过。。
        
4、对你来讲STL还有哪些是急需改进的地方。
      一些臃肿不实用的一些类剔除掉，另外将STL是编译器实现速度加快。。

5、对于STL的未来你的预期是什么样的？
     期待一些实用的STL进入C++标准，另外STL也可以继续扩展范围，涵盖更多常用的功能，比如file system，函数调用、增强并行处理功能之类。

yulihua49

陌路巨额投入 发表于 2015-07-11 15:25
1、你是否完整的了解过C++98: 2003 标准下的STL设计和实现，并且对你产生了怎么样的影响?
           说实 ...对于STL的未来你的预期是什么样的？
     期待一些实用的STL进入C++标准，另外STL也可以继续扩展范围，涵盖更多常用的功能，比如file system，函数调用、增强并行处理功能之类。

你没发现需要涵盖关系数据库？我感觉这个最需要了。
数据库泛型。
还有就是序列化／反序列化的工作。