【河源码报6】【文华obv指标源码】【delphi传奇网关源码】libstdc 源码

时间:2024-11-25 03:27:18 来源:源码运行软件 编辑:如何安装指标源码

1.C++ string 源码实现对比
2.lldb 小记和std::string的数据结构图源码阅读
3.什么时候以struct替代class?
4.图文鲲鹏916-ARM64架构源码gcc编译完整记录
5.如何使用oprofile对软件做profiling
6.Linux环境源码安装GCC/CMAKE

libstdc 源码

C++ string 源码实现对比

       标题:C++ string 源码实现对比

       作为游戏客户端开发工程师,作者lucasfan分享了他对不同版本C++ string源码的深入分析,以帮助开发者解决std::string在现网中可能引发的Crash问题。本文将对比libstdc++、腾讯内部的Android和iOS SDK使用的string实现,以及tpstl string,河源码报6涉及内存结构、构造函数和析构方法等关键部分。

       1. libstdc++ string

       Android SDK普遍采用的libstdc++ string以写时拷贝(COW)特性为主,但可能导致性能问题。其内存结构包含指向堆上数据的指针和一个包含长度信息的_Rep对象。构造函数如char*构造器负责内存申请和字符串拷贝,拷贝构造通过_M_grab处理共享与深度拷贝,拷贝赋值操作涉及assign方法。

       2. libc++ string (iOS SDK)

       相比之下,iOS使用了短字符串优化(SSO),内存结构分为长字符串和短字符串模式,通过位标志判断。char*构造器和拷贝构造根据字符串类型执行不同初始化方法,右值拷贝利用转移语义节省内存。

       3. tpstl string (腾讯自研)

       tpstl string简化了STL,使用内存池管理内存,其构造和赋值操作均在内存池上进行,有助于解决跨库问题。

       结论

       理解这些string源码实现有助于开发者定位和解决实际问题。文华obv指标源码作者将继续分享更多案例和调试策略,有兴趣的开发者可加入官方QQ交流群:,获取更多技术分享。

lldb 小记和std::string的数据结构图源码阅读

       在深入理解LLVM和GCC的std::string实现差异时,我们首先从lldb着手,探索其内部工作机制。昨天尝试编译llvm后,今天我们就来研究std::string在lldb中的表现,它与g++的std::string实现有何不同。

       从一个简单的测试程序开始,我们对比了用g++和clang++编译的代码。在g++版本中,字符串s使用了短字符串优化(SSO)的存储方式,"hi"存储在_M_local_buf中。SSO旨在节省内存,通过为短字符串预留固定大小的结构,如长度、容量和指向字符串数组的指针,共字节。

       对于长字符串,例如scow,存储方式不同。尽管_M_local_buf中没有"this is a sunny day",但通过M p找到的delphi传奇网关源码实际字符串地址显示出长字符串的存储策略。这表明在长字符串时,std::string会采用常规的存储方式,即一个指针指向字符串数组。

       接下来,我们需要弄清楚如何判断何时使用SSO。在代码中,我们猜测可能通过某些标志位来区分,但实际观察到的operator[]函数表明,M p始终指向字符串数组,不论字符串长度。这就意味着,无论短长,读取指定位置的字符都遵循相同的逻辑。

       在libstdc++(g++)和libc++(llvm)的实现上,我们发现两者在数据结构上存在差异。例如,libstdc++的std::string使用字节的union,而libc++则为字节。区分长短字符串的方式在libc++中通过检查容量字段的比特位实现,这依赖于机器的字节序。

       附录中,我分享了自己编译LLVM的体验和使用clang++编译程序的CMakeLists.txt设置,供有兴趣的读者参考。

什么时候以struct替代class?java论坛源码查询

       考虑使用struct而非class时,重点在于结构体的C++风格及其特性。与C语言中的结构体不同,C++中的结构体支持模板和大量继承(尽管不使用虚函数)。这些特性在C语言中不存在,因此在C++中使用结构体显得更为自然。

       例如,ut库,一个小巧的C++单元测试库,其源码仅多行,几乎全部使用了结构体。这种选择体现了C++中结构体的灵活性和简洁性。

       以libstdc++为例,即gcc开源项目中的C++标准库,其ranges实现源码同样采用了大量结构体。这些结构体设计简洁,成员变量数量不多,一般只有一两个至三个,且成员变量的私有化并不普遍。因此,在这种情况下,使用类定义反而显得多余。

       综上所述,在C++中,当结构体的气壮山河指标源码成员变量数量不多,且成员变量的私有化不是主要需求时,使用结构体而非类更为合适。结构体的简洁性、模板支持以及与大量继承的结合,使其成为解决特定问题时的优良选择。

图文鲲鹏-ARM架构源码gcc编译完整记录

       以下是关于ARM架构源码gcc编译的详细步骤记录:

       首先,确保已经准备就绪,如果cmake未安装,需要进行安装。检查cmake版本以确认其是否满足需求。

       安装必要的依赖包,如isl、gmp、mpc、mpfr等,检查它们是否已成功安装。

       针对gcc版本过低的问题,需下载并更新到7.3版本。下载并解压gcc7.3的安装包。

       在gcc-7.3.0目录下,确认已下载和安装了所有依赖包。

       利用多核CPU的优势,通过“-j”参数加速编译过程。原先是按照官方文档使用make -j,但速度缓慢,后来调整为make -j以提升效率。

       依次执行编译目录创建、gcc编译、安装以及确认“libstdc++.so”软连接在正确的目录(/usr/lib)。

       编译完成后,通过查看gcc版本来确认安装是否成功。

       以上就是完整的gcc编译安装流程。如果您觉得这些信息对您有所帮助,欢迎分享和关注我们的更新。更多技术内容敬请期待,感谢您的支持!

如何使用oprofile对软件做profiling

       ã€€ã€€å…³äºŽXilinx Zynq-带来的新的系统设计思路,以及Profiling的对象libjpeg,前文已经描述过了,再此不再赘述。

       ã€€ã€€ä¸€. Oprofile简介

       ã€€ã€€Profiling是对不同性能特征的数据的形式化总结或分析,它通常以图形和表的形式出现。它提供为特定的处理器事件收集的采样百分数或数 量,比如cache miss rate、TLB miss rate等等。一般来说,主要目的是为了找出软件中的性能瓶颈,然后有针对性的优化以提升软件的整体性能。

       ã€€ã€€Oprofile 是用于 Linux 的若干种评测和性能监控工具中的一种。它可以工作在不同的体系结构上,包括ARM, PowerPC, MIPS, IA, IA 和 AMD Athlon等等。它的开销很小,从Linux 2.6 版起,它被包含进了Linux内核中。

       ã€€ã€€Oprofile可以收集有关处理器事件的信息,帮助用户识别诸如循环的展开、cache的使用率低、低效的类型转换和冗余操作、错误预测转移 等问题。Oprofile是一种细粒度的工具,可以为指令集或者为函数、系统调用或中断处理例程收集采样。Oprofile 通过取样来工作。使用收集到的评测数据,用户可以很容易地找出性能问题。

       ã€€ã€€é€šè¿‡ç›‘察CPU的hardware events,oprofile可以在运行状态下对整个Linux系统进行profiling。Profiling的对象可以是Linux kernel (包括modules和interrupt handlers), shared libraries或者应用程序。

       ã€€ã€€ä»Ž0.9.8版本开始,oprofile支持Perf_events profiling mode模式。应用程序operf被用来控制profiling过程;而在legacy mode下,是通过opcontrol脚本和oprofiled daemon来完成的。Operf不再象legacy mode那样需要OProfile kernel driver,它直接和Linux Kernel Performance Events Subsystem打交道。使用operf,就可以用普通用户的身份来profiling用户的应用程序了,当然如果需要对整个系统来profiling 的时候还是需要root权限的。

       ã€€ã€€å¦‚果硬件不支持OProfile使用performance counters,OProfile就只能工作在Timer Mode下了。Timer Mode只能在legacy profiling mode下使用,即只能通过opcontrol脚本来控制。

       ã€€ã€€Oprofile的website为:piled (JIT) code

       ã€€ã€€? 可以对整个系统做profiling

       ã€€ã€€? 可以观察CPU内部的细节,例如cache miss rate

       ã€€ã€€? 可以多源代码做annotation

       ã€€ã€€? 可以支持instruction-level的profiling

       ã€€ã€€? 可以生成call-graph profiles

       ã€€ã€€ä¸è¿‡OProfile也不是万能的,它也有自己的局限性:

       ã€€ã€€? 只能在x, ARM, 和PowerPC架构上生成call graph profiles

       ã€€ã€€? 不支持%精确的instruction-level profiling

       ã€€ã€€? 对dynamically compiled (JIT) code profiling的支持还不完善。

       ã€€ã€€æ— è®ºå¦‚何,Oprofile的功能都比gprof要强很多,代价是配置起来会比较麻烦。

       ã€€ã€€äºŒ. 编译Oprofile

       ã€€ã€€é¦–先最好在Linux kernel里面选中Oprofile driver,以获得全面的支持。

       ã€€ã€€ä¸‹è½½Linux kernel Source:从/Xilinx/linux-xlnx 可以下载到Xilinx提供的验证好的内核。如果不方便使用Linux下的git工具,可以单击页面上的releases找到相应的版本下载tar ball。下载的时候最好选tar.gz格式的,而不是zip格式的,因为后者在处理symbol link的时候有可能会出问题。

       ã€€ã€€å› ä¸ºç¬”者使用的是Xilinx Linux pre-built .7,所以这里下载的是linux-xlnx-xilinx-v.7.tar.gz

       ã€€ã€€è§£åŽ‹ç¼©åŽï¼Œç”¨ä»¥ä¸‹å‘½ä»¤è°ƒå‡ºLinux kernel的配置界面:

       ã€€ã€€export ARCH=arm

       ã€€ã€€export CROSS_COMPILE=arm-xilinx-linux-gnueabi-

       ã€€ã€€make xilinx_zynq_defconfig

       ã€€ã€€make xconfig 或者make menuconfig

       ã€€ã€€åœ¨é…ç½®ç•Œé¢ä¸Šå°†ä»¥ä¸‹ä¸¤é¡¹å‹¾ä¸Šï¼š

       ã€€ã€€General setup --->

       ã€€ã€€[*] Profiling support

       ã€€ã€€<*> OProfile system profiling

       ã€€ã€€ç„¶åŽmake uImage即可生成新的uImage,用来替换Xilinx Linux pre-built .7中的Linux kernel image。同时我们也需要vmlinux来检查profiling的结果。

       ã€€ã€€Oprofile需要popt, bfd, liberty库,要在嵌入式单板上使用这些库,需要手工完成交叉编译。

       ã€€ã€€é’ˆå¯¹popt 1.7,用以下命令完成编译:

       ã€€ã€€./configure --prefix=/home/wave/xilinx/oprofileprj/rootfs --host=arm-xilinx-linux-gnueabi --with-kernel-support --disable-nls && make && make install

       ã€€ã€€é’ˆå¯¹binutils 2.,用以下命令完成编译:

       ã€€ã€€./configure --host=arm-xilinx-linux-gnueabi --prefix=/home/wave/xilinx/oprofileprj/rootfs --enable-install-libbfd --enable-install-libiberty --enable-shared && make && make install

       ã€€ã€€ä¸è¿‡--enable-install-libiberty没有效果,所以需要手工把libiberty.a和libiberty.h拷贝到相应的位置。

       ã€€ã€€é’ˆå¯¹oprofile 0.9.9,用以下命令完成编译:

       ã€€ã€€./configure --host=arm-xilinx-linux-gnueabi --prefix=/home/wave/xilinx/oprofileprj/rootfs --with-kernel-support --with-binutils=/home/wave/xilinx/oprofileprj/rootfs && make && make install

       ã€€ã€€é…ç½®è¿‡ç¨‹ç»“束后可能会有以下提示,因为没有打算用GUI和profile JITed code,所以直接忽视之。

       ã€€ã€€config.status: executing libtool commands

       ã€€ã€€Warning: QT version 3 was requested but not found. No GUI will be built.

       ã€€ã€€Warning: The user account 'oprofile:oprofile' does not exist on the system.

       ã€€ã€€To profile JITed code, this special user account must exist.

       ã€€ã€€Please ask your system administrator to add the following user and group:

       ã€€ã€€user name : 'oprofile'

       ã€€ã€€group name: 'oprofile'

       ã€€ã€€The 'oprofile' group must be the default group for the 'oprofile' user.

       ã€€ã€€å°†ç¼–译完成的uImage,vmlinux,oprofile binary,重新编译的没有-pg的libjpeg binary以及tool chain的libc打包放到SD卡中,准备在ZC开发板上尝试profile djpeg。

       ã€€ã€€ä¸‰. 运行Oprofile

       ã€€ã€€æ­£å¸¸å¯åŠ¨åµŒå…¥å¼Linux后,在开发板的console上一次输入以下命令:

       ã€€ã€€mount /dev/mmcblk0p1 /mnt

       ã€€ã€€mkdir -p /home/root/work

       ã€€ã€€cd /home/root/work

       ã€€ã€€tar zxvf /mnt/jpeg-bin-nopg.tar.gz

       ã€€ã€€cd jpeg-bin/bin

       ã€€ã€€cp /mnt/park-x.jpg .

       ã€€ã€€export LD_LIBRARY_PATH=/home/root/work/jpeg-bin/lib

       ã€€ã€€cd /home/root/work

       ã€€ã€€tar zxvf /mnt/rootfs.tar.gz

       ã€€ã€€cd rootfs

       ã€€ã€€chown root:root -R

*

       ã€€ã€€cp -R bin/* /usr/bin

       ã€€ã€€cp -R lib/* /lib

       ã€€ã€€cp /bin/which /usr/bin

       ã€€ã€€cp /bin/dirname /usr/bin

       ã€€ã€€mkdir -p /home/wave/xilinx/oprofileprj/rootfs/share

       ã€€ã€€cp -R ./rootfs/* /home/wave/xilinx/oprofileprj/rootfs

       ã€€ã€€cd /home/root/work

       ã€€ã€€tar zxvf /mnt/libc.tar.gz

       ã€€ã€€cp ./lib/libstdc*.* /lib

       ã€€ã€€mkdir -p /home/wave/xilinx/libjpeg

       ã€€ã€€cd /home/wave/xilinx/libjpeg

       ã€€ã€€tar zxvf /mnt/jpeg-9.tar.gz

       ã€€ã€€cp /mnt/vmlinux /home/root/work

       ã€€ã€€cd /home/root/work/jpeg-bin/bin

       ã€€ã€€opcontrol --init

       ã€€ã€€opcontrol --vmlinux=/home/root/work/vmlinux

       ã€€ã€€opcontrol --setup --event=CPU_CYCLES:::0:1 --session-dir=/home/root/

       ã€€ã€€operf --vmlinux /home/root/work/vmlinux ./djpeg -bmp park-x.jpg > result.bmp

       ã€€ã€€opreport -l ./djpeg

       ã€€ã€€å®Œæˆè¿™ä¸€æ­¥åŽï¼Œæˆ‘们就可以看到profiling的结果了,在笔者的平台上看到的内容的主要部分如下:

       ã€€ã€€root@zynq:~/work/jpeg-bin/bin# opreport -l ./djpeg

       ã€€ã€€Using /home/root/work/jpeg-bin/bin/oprofile_data/samples/ for samples directory.

       ã€€ã€€CPU: ARM Cortex-A9, speed MHz (estimated)

       ã€€ã€€Counted CPU_CYCLES events (CPU cycle) with a unit mask of 0x (No unit mask) count

       ã€€ã€€samples % image name symbol name

       ã€€ã€€ . libc-2..so /lib/libc-2..so

       ã€€ã€€ 7. libjpeg.so.9.0.0 ycc_rgb_convert

       ã€€ã€€ 7. libjpeg.so.9.0.0 jpeg_idct_x

       ã€€ã€€ 7. libjpeg.so.9.0.0 decode_mcu

       ã€€ã€€ 6. libjpeg.so.9.0.0 jpeg_idct_islow

       ã€€ã€€ 6. djpeg finish_output_bmp

       ã€€ã€€ 2. libjpeg.so.9.0.0 jpeg_fill_bit_buffer

       ã€€ã€€ 1. djpeg put_pixel_rows

       ã€€ã€€ 0. vmlinux __copy_from_user

       ã€€ã€€ 0. libjpeg.so.9.0.0 decompress_onepass

       ã€€ã€€ 0. libjpeg.so.9.0.0 jpeg_huff_decode

       ã€€ã€€ 0. vmlinux get_page_from_freelist

       ã€€ã€€ 0. vmlinux __memzero

       ã€€ã€€ 0. vmlinux __copy_to_user_std

       ã€€ã€€ 0. vmlinux _raw_spin_unlock_irqrestore

       ã€€ã€€ 0. vmlinux do_page_fault

       ã€€ã€€ 0. vmlinux __generic_file_aio_write

       ã€€ã€€ 0. vmlinux _raw_spin_unlock_irq

       ã€€ã€€ 0. vmlinux free_hot_cold_page

       ã€€ã€€ 0. vmlinux vector_swi

       ã€€ã€€ 0. vmlinux handle_pte_fault

       ã€€ã€€ä»Žç»“果中我们可以看到libjpeg.so.9.0.0, djpeg和vmlinux中的symbol name已经可以被正确的解析出来了,和gprof的结果基本一致。相比gprof,oprofile可以在更大的范围内完成profiling。

       ã€€ã€€æˆ‘们还可以用以下命令观察源代码中特定行的执行时间,进一步缩小优化的范围,达到事半功倍的效果。

       ã€€ã€€opannotate --source ./djpeg > opannotate.txt

       ã€€ã€€å››. 小结

       ã€€ã€€é€šè¿‡å®žéªŒï¼Œæˆ‘们可以看到Oprofile可以提供更丰富的profiling结果,可以更好的帮助开发者找到瓶颈,通过有针对性的优化提升软件 性能;profiling的结果也可以帮助开发者将性能瓶颈代码通过Xilinx HLS工具用硬件加速器来实现,从而为进一步提升整个嵌入式系统的性能打开了大门。

Linux环境源码安装GCC/CMAKE

       为了在Linux环境下源码安装GCC和CMAKE,我们需要遵循详细的步骤和策略。对于GCC源码,我们可以从GitHub-gcc-mirror/gcc获取4.4.6版本。接下来,进入下载后的GCC源代码目录。

       在配置和编译GCC时,首先应该明确指定安装的目录,避免冲突。可能在配置脚本时遇到错误,这时候需要解决依赖项问题。分别安装MPFR、MPC和任何其他必要的依赖库。对于GCC8.3及以上版本,内部集成脚本能够简便地获取这些依赖库。

       安装库路径后,再次执行配置文件,加入库路径参数,确保安装的每个步骤顺利进行。配置完成后,整个GCC安装过程即宣告成功。

       为了测试GCC是否正确安装,遵循指导进行验证。

       CMake的安装同样关键,可以通过直接指定需要的GCC版本来简化安装流程。在CMake命令行参数中指定GCC路径也是可行的。

       在运行GCC4.4.6编译的程序时,可能存在系统路径问题,这是因为我们选择的是不替换安装方式。因此,需要额外操作,确保所需的库被正确添加到路径中。

       遇到GCC多版本引起的ABI兼容问题时,如果编译链接过程中遇到“undefined reference to"“std::__cxx ***””错误,这提示可能是C++ ABI问题。处理方法是,针对GCC5.1之前版本发布的libstdc++中新增的ABI,通过添加定义-D_GLIBCXX_USE_CXX_ABI=0来解决该问题。

       对于GDB版本的问题,特别在GCC.1的使用中,要求C++的编译器,导致了旧版本GDB启动出现Segment Fault。解决办法是升级GDB版本。

       附录中提供了一些额外资源,例如Mingw下载,适用于位和位Windows的最新版x_-win-sjlj;CMake下载链接以及GCC的GitHub地址等。遵循这些资源和提示,能够帮助用户顺畅进行Linux环境下的GCC和CMAKE的源码安装与配置。

c++protected继承和private继承是不是没用的废物?

       既然你所统计的项目里出现了 private 继承和 protected 继承,这不正说明确实有他们的用武之地吗?

       让我们来康康 C++ 代码的标杆——STL 的源码,是怎么做的:

       先来康 GCC 自带的 libstdc++ 的实现:

       vector, list, deque, forward_list, unordered_(multi)set/map 的底层都有用到 protected 或 private 继承。

       比如 vector 会空基类压缩优化技术,这只能用继承实现,而使用组合时就没有压缩的效果。

       考察下面代码,这是对 vector 压缩 allocator 字段原理的简化实现:

       如果 vector 直接 public 继承自 allocator,根据类型兼容原则,在指针和引用语义下,子类同时也可被视作是父类。那 vector 也能被当做 allocator 用了?这会引发语义混乱。

       而改成 private 或 protected 继承就不会了:

       这时候编译器会报错,这阻止了上面的情况发生。这样的例子比比皆是。

       还有 tuple 对空类字段的压缩,也采用了这个手法。

       2)既然谈到了 tuple,我们就来考察一下 tuple。

       这次我不亲手写代码了,就百度一下,随手找找一篇博客现场打脸好啦。

       百度搜“std::tuple 实现”,第一篇博客用常规思路来实现 tuple,即:取到第一个模板参数后,作为一个数据成员,然后递归继承 tuple。这份实现没有用到空类成员压缩优化,不过没关系,反正这个优化也不是强制的。

       但是,如果使用 public 继承,类型兼容原则会导致 tuple 是 tuple 的子类,那么就可以当父类去用。这将引发大坑,比如接收二元组参数的函数接收到的居然是一个三元组。这种低质量的库在业务代码里是不可用的。

       总结一下,protected private 继承能暴露问题,避免不当使用时的隐患;空基类优化的需求使得必须用继承实现,而 public 继承会产生奇怪的语义,这决定了 protected private 继承在模板库中很有用。

       业务代码在使用继承时,往往只是为了利用多态性,而模板库在设计时会考虑到所有场景,所以 protected private 继承在模板库中用得多,在业务代码中用得少。

       最后,private protected 继承虽然在实践中用得相对较少,但他们绝不是像 vector, auto_ptr 这样的实在是非常拉垮的设计。他们在模板编程中十分有用!

copyright © 2016 powered by 皮皮网   sitemap