为什么使用递归继承std :: tuple实现不好？ [英] Why is it not good to use recursive inheritance for std::tuple implementations?

问题描述

在这个问题中，Howard Hinnant说， p>

std :: tuple的一些实现使用递归继承。但好的不是。 ; - ）

有人可以说明一下吗？

解决方案

非递归实现具有更好的编译时性能。不管你信不信，在一个大量使用的库设施，如 std :: tuple ，如何实现可以影响（更好或更坏），客户端看到的编译时间。递归实现倾向于产生在递归深度上为线性的编译时间（或者甚至更糟）。

这不仅仅影响元组本身的实例化。 std :: get< I>（tuple）例如对于一个实现将采用线性的编译时间量，对于另一个实现采用恒定的编译时间量。当处理元组的元组时，这种影响可能迅速恶化（或不是）。也就是说递归实现可以导致O（N ^ 2）编译时间，而非递归实现仍然是O（1）。

Fwiw，libc ++实现放置对象按照客户端指定的顺序排序，但使用编译器的空基类优化工具优化空组件的空间。

In this question, Howard Hinnant said

Some implementations of std::tuple use recursive inheritance. But the good ones don't. ;-)

Can someone please shed some light on that?

解决方案

A non-recursive implementation has better compile-time performance. Believe it or not, in a heavily used library facility like std::tuple, how it is implemented can impact (for better or worse), the compile times the client sees. Recursive implementations tend to produce compile times that are linear in the depth of recursion (or can be even worse).

This impacts more than just the instantiation of the tuple itself. std::get<I>(tuple) for example will take a linear amount of compile time for one implementation and a constant amount of compile time for another implementation. This impact can rapidly deteriorate (or not) when dealing with tuples of tuples. I.e. the recursive implementation could result in O(N^2) compile time while the non-recursive implementation is still O(1).

Fwiw, the libc++ implementation lays the objects out in the order specified by the client, but optimizes away space for empty components using the compiler's empty base class optimization facility.

这篇关于为什么使用递归继承std :: tuple实现不好？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！