使用GDB的"p variable-name"查看STL容器类，只会显示该容器的一些信息，并不能很友好的显示该容器的内容。使用stl-views.gdb这个脚本可以很好地解决这一问题。下载stl-veiws.gdb文件，将其放到~/目录下，直接将其改名为~/.gdbinit，或者在你已有的.gdbinit文件中用source ~/.stl-views.gdb命令将其包含。这样你就可以用下面的命令显示STL容器类了。

 容器类型 GDB 命令
std::vector<T> pvector stl_variable
std::list<T> plist stl_variable T
std::map<T,T> pmap stl_variable
std::multimap<T,T> pmap stl_variable
std::set<T> pset stl_variable T
std::multiset<T> pset stl_variable
std::deque<T> pdequeue stl_variable
std::stack<T> pstack stl_variable
std::queue<T> pqueue stl_variable
std::priority_queue<T> ppqueue stl_variable
std::bitset<n><td> pbitset stl_variable
std::string pstring stl_variable
std::widestring pwstring stl_variable

举例：

如果你的C++代码中有定义: set<string> s;
则在GDB中可以使用如下命令查看该set的信息与内容：
pset s - 打印该集合s的定义和大小
pset s char* - 打印该集合s的大小以及该集合的所有元素

Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生