【商圈 导航 源码】【布尔检索python源码】【热血江湖师徒源码】stl源码剖析 在线

2024-11-25 06:45:33 来源:筹码分布 指标源码 分类:探索

1.STL 源码剖析:sort
2.STL源码剖析9-set、码剖multiset
3.STL源码剖析总结笔记(2):容器(containers)概览
4.[stl 源码分析] std::list::size 时间复杂度

stl源码剖析 在线

STL 源码剖析:sort

       我大抵是析线太闲了。

       更好的码剖阅读体验。

       sort 作为最常用的析线 STL 之一,大多数人对于其了解仅限于快速排序。码剖

       听说其内部实现还包括插入排序和堆排序,析线商圈 导航 源码于是码剖很好奇,决定通过源代码一探究竟。析线

       个人习惯使用 DEV-C++,码剖不知道其他的析线编译器会不会有所不同,现阶段也不是码剖很关心。

       这个文章并不是析线析完之后的总结,而是码剖边剖边写。不免有个人的析线猜测。而且由于本人英语极其差劲,码剖大抵会犯一些憨憨错误。

       源码部分sort

       首先,在 Dev 中输入以下代码:

       然后按住 ctrl,鼠标左键sort,就可以跳转到头文件 stl_algo.h,并可以看到这个:

       注释、模板和函数参数不再解释,布尔检索python源码我们需要关注的是函数体。

       但是,中间那一段没看懂……

       点进去,是一堆看不懂的#define。

       查了一下,感觉这东西不是我这个菜鸡能掌握的。

       有兴趣的 戳这里。

       那么接下来,就应该去到函数__sort 来一探究竟了。

       __sort

       通过同样的方法,继续在stl_algo.h 里找到 __sort 的源代码。

       同样,只看函数体部分。

       一般来说,sort(a,a+n) 是对于区间 [公式] 进行排序,所以排序的前提是 __first != __last。

       如果能排序,那么通过两种方式:

       一部分一部分的看。

       __introsort_loop

       最上边注释的翻译:这是排序例程的帮助程序函数。

       在传参时,除了首尾迭代器和排序方式,热血江湖师徒源码还传了一个std::__lg(__last - __first) * 2,对应 __depth_limit。

       while 表示,当区间长度太小时,不进行排序。

       _S_threshold 是一个由 enum 定义的数,好像是叫枚举类型。

       当__depth_limit 为 [公式] 时,也就是迭代次数较多时,不使用 __introsort_loop,而是使用 __partial_sort(部分排序)。

       然后通过__unguarded_partition_pivot,得到一个奇怪的位置(这个函数的翻译是无防护分区枢轴)。

       然后递归处理这个奇怪的位置到末位置,再更新末位置,继续循环。

       鉴于本人比较好奇无防护分区枢轴是什么,于是先看的__unguarded_partition_pivot。

       __unguarded_partition_pivot

       首先,找到了中间点。

       然后__move_median_to_first(把中间的淘宝怎么发源码数移到第一位)。

       最后返回__unguarded_partition。

       __move_median_to_first

       这里的中间数,并不是数列的中间数,而是三个迭代器的中间值。

       这三个迭代器分别指向:第二个数,中间的数,最后一个数。

       至于为什么取中间的数,暂时还不是很清楚。

       `__unguarded_partition`

       传参传来的序列第二位到最后。

       看着看着,我好像悟了。

       这里应该就是实现快速排序的部分。

       上边的__move_median_to_first 是为了防止特殊数据卡 [公式] 。经过移动的话,第一个位置就不会是最小值,放在左半序列的数也就不会为 [公式] 。

       这样的话,__unguarded_partition 就是快排的主体。

       那么,接下来该去看部分排序了。自动分账系统源码

       __partial_sort

       这里浅显的理解为堆排序,至于具体实现,在stl_heap.h 里,不属于我们的讨论范围。

       (绝对不是因为我懒。)

       这样的话,__introsort_loop 就结束了。下一步就要回到 __sort。

       __final_insertion_sort

       其中某常量为enum { _S_threshold = };。

       其中实现的函数有两个:

       __insertion_sort

       其中的__comp 依然按照默认排序方式 < 来理解。

       _GLIBCXX_MOVE_BACKWARD3

       进入到_GLIBCXX_MOVE_BACKWARD3,是一个神奇的 #define:

       其上就是move_backward:

       上边的注释翻译为:

       __unguarded_linear_insert

       翻译为“无防护线性插入”,应该是指直接插入吧。

       当__last 的值比前边元素的值小的时候,就一直进行交换,最后把 __last 放到对应的位置。

       __unguarded_insertion_sort

       就是直接对区间的每个元素进行插入。

       总结

       到这里,sort 的源代码就剖完了(除了堆的那部分)。

       虽然没怎么看懂,但也理解了,sort 的源码是在快排的基础上,通过堆排序和插入排序来维护时间复杂度的稳定,不至于退化为 [公式] 。

       鬼知道我写这么多是为了干嘛……

STL源码剖析9-set、multiset

       STL源码深入研究:set与multiset的内部结构详解

       1. 结论

       在C++标准模板库(STL)中,set和multiset是两种常用的数据结构,它们底层实现依赖于红黑树(rb tree)。set是一种无序的关联容器,不允许有重复元素,而multiset则允许元素重复,但仍然保持插入顺序。

       2. set的实现

       set内部的红黑树使用了stl_function.h中的仿函数模板参数,这个仿函数用于定义元素的比较规则。set类在stl_set.h文件中定义,它通过这个仿函数确保了元素的唯一性,保证了查找、插入和删除操作的高效性。

       3. multiset的特性

       与set不同,multiset在stl_multiset.h中定义,它允许元素重复,这主要通过维护每个元素在树中的多个实例来实现。与set一样,它也依赖红黑树的数据结构,但对元素的比较规则更为宽松,允许基于给定的比较仿函数进行重复元素的插入和查找。

STL源码剖析总结笔记(2):容器(containers)概览

       容器作为STL的重要组成部分,其使用极大地提升了解决问题的效率。深入研究容器内部结构与实现方式,对提升编程技能至关重要。本文将对容器进行概览,分为序列式容器、关联式容器与无序容器三大类。

       容器大致分为序列式容器、关联式容器和无序容器。其中序列式容器侧重于顺序存储,关联式容器则强调元素间的键值关系,而无序容器可以看作关联式容器的一种。

       容器之间的关系可以归纳为:序列式容器为基层,关联式容器则在基层基础上构建了更复杂的数据结构。例如,heap和priority容器以vector作为底层支持,而set和map则采用红黑树作为基础数据结构。此外,还存在一些非标准容器,如slist和以hash开头的容器。在C++ 中,slist更名为了forward-list,而hash开头的容器改名为了unordered开头。

       在容器的实现中,sizeof()函数可能揭示容器的内部大小对比。需要注意的是,尽管在GNU 4.9版本中,一些容器的设计变得复杂,采用了较多的继承结构,但实际上,这些设计在功能上并未带来太大差异。

       熟悉容器的结构后,我们可以从vector入手,探索其内部实现细节。其他容器同样蕴含丰富的学习内容,如在list中,迭代器(iterators)的设计体现了编程的精妙之处;而在set和map中,红黑树的实现展现了数据结构的高效管理。

       本文对容器进行了概览,旨在提供一个全面的视角,后续将对vector、list、set、map等容器进行详细分析,揭示其背后的实现机制与设计原理。

[stl 源码分析] std::list::size 时间复杂度

       在对Linux上C++项目进行性能压测时,一个意外的发现是std::list::size方法的时间复杂度并非预期的高效。原来,这个接口在较低版本的g++(如4.8.2)中是通过循环遍历整个列表来计算大小的,这导致了明显的性能瓶颈。@NagiS的提示揭示了这个问题可能与g++版本有关。

       在功能测试阶段,CPU负载始终居高不下,通过火焰图分析,std::list::size的调用占据了大部分执行时间。火焰图的使用帮助我们深入了解了这一问题。

       查阅相关测试源码(源自cplusplus.com),在较低版本的g++中,std::list通过逐个节点遍历来获取列表长度,这种操作无疑增加了时间复杂度。然而,对于更新的g++版本(如9),如_glibcxx_USE_CXX_ABI宏启用后,list的实现进行了优化。它不再依赖遍历,而是利用成员变量_M_size直接存储列表大小,从而将获取大小的时间复杂度提升到了[公式],显著提高了性能。具体实现细节可在github上找到,如在/usr/include/c++/9/bits/目录下的代码。

本文地址:http://5o.net.cn/news/04c237197624.html 欢迎转发