- 主题:Linux C++开发已经切到Visual Studio 2022，感觉还可以
起因是vscode、clion、gdb等在linux下调试c++代码经常无视断点飞掉，断不下来。调试体验很差。
后改为visual studio + visual gdb，断点和单步都很稳定，
但有些不爽的问题，诸如工程的目录树中只能显示工程中的.cpp、不能显示.h等。
现改为visual studio 2022 + vax（visual assist x），试了一下还可以，暂时没发现拦路的大问题。
优点就是断点稳定，变量的值查看方便，还能使用vax的intellisense和语法着色。
坑或者不便的地方：
1、不能导入linux上现有的cmake工程，只能把clone到windows上的linux cmake工程目录自动同步到linux。
而visual gdb是可以直接打开linux上的cmake工程的。
2、windows上的符号链接同步到linux的问题。工程里最好不要有符号链接。
3、工具栏上选择linux-gcc-debug配置的下拉框，有时根本不显示出来。
4、要以root调试linux程序的话，需要以root登录ssh，或者将调试器设置为一个bash脚本，然后脚本里用sudo执行gdb。而visual gdb里直接打个勾就能用root。
--
FROM 123.118.191.*
那就改造工程，哈哈
其实不需要跨平台，只是把linux的cmake工程git clone到windows下，然后用vs2022的open folder菜单就能打开工程。不是cmake类型的工程的话，那麻烦点
vs2022这个从win -> linux的同步可能更方便点，选择不同的ssh connection就能从windows把同一份代码同步到不同的linux机器。
刚开始有些卡，不知道是不是第三方库的头文件太多导致vax或者vs2022自己的intellisense解析开销大。
最开始在main()上设置断点断不下来，在launch.vs.json里加了stopOnEntry才断下来。
【 在 stub 的大作中提到: 】
: 如果工程不支持跨平台呢
--
FROM 123.118.191.*
我对eclipse没啥好感，java搞的一个巨无霸，慢
我最喜欢vax的着色风格，比微软自家的好看太多，外加windows上的consolas字体渲染，舒服
【 在 BrendanEich 的大作中提到: 】
: eclipse不好用吗？
: 我一直用这个
--
FROM 123.118.191.*
应该是gdb的问题，因为直接用gdb调试也会有那种无视断点跑飞的问题。
而且我是自己编译的最新版本的gdb，也如此。
还有就是在某个函数的最后一行用step over也跑飞，得用step into, 但是step into很容易进到库函数里转圈半天，非预期，体验也差。qtcreator我以前用时也有这个问题。可能是gdb的这个设计和MS家的调试器不同，所以感觉怪异。
但是vs和visual gdb用gdb去调试，F10单步断点却很稳，奇怪。难道这两个调用的gdb命令不同？gdb单步就那两个命令。vs2022对调试有log功能，可以记录和调试器之间的详细交互命令，估计也是为了定位问题的。
vs2022这个我确定是显式指定的gdb，因为我在launch.vs.json里指定了gdb server后它报错说在linux上没找到gdb server，又改回gdb。
visual gdb不知道是用的gdb server还是gdb，如果vs2022没什么大问题，暂时弃用visual gdb了，留着备用。
【 在 hgoldfish 的大作中提到: 】
: 这个好像是 gdb 的 BUG？我用 QtCreator 搭配 gdb 也经常出问题。
: 不过目前最好的开源 C++ IDE 可能还真是 QtCreator. 而且也支持在 Windows 里面开发，布署到 Linux 设备里面调试。但是不太清楚是怎么做的。
--
FROM 123.118.191.*
查了一下qtcreator一样的，ssh + gdb/gdb server
https://doc.qt.io/qtcreator/creator-developing-generic-linux.html
vs2022现在走sftp同步文件不稳定，经常出现超时错误，优先用rsync合适
【 在 hgoldfish 的大作中提到: 】
: 这个好像是 gdb 的 BUG？我用 QtCreator 搭配 gdb 也经常出问题。
: 不过目前最好的开源 C++ IDE 可能还真是 QtCreator. 而且也支持在 Windows 里面开发，布署到 Linux 设备里面调试。但是不太清楚是怎么做的。
:
--
FROM 123.118.191.*
那是cygwin干的事情
【 在 stub 的大作中提到: 】
: 了解了，其实程序还是跑在Linux上，我以为在windows上跑呢，比如系统调用是win系统调用。
--
FROM 123.118.191.*
有linux console，这个窗口里下拉框可以选择本地的powershell窗口，cmd窗口，也可以选择远程的ssh窗口。
vs2022有时会自动重启自身，估计复杂工程触发了bug。
它的sftp文件同步是经常timeout，用它带的rsync更合适，默认也是用rsync。
vs应该"借鉴"了vscode的很多功能，包括那些json配置
【 在 mvtec 的大作中提到: 】
: visual studio 有没有
: remote ssh
: 没有remote ssh我觉得好麻烦啊
--
修改:z16166 FROM 123.118.191.*
FROM 123.118.191.*
visual gdb还有些其他问题：
1、很多窗口不能自行指定字体大小，看着费眼。它论坛上客服说都能自适应调整大小，所以没做这个设置界面。
2、当前cpp的outline窗口有时半天都没内容，不知是网络同步问题，还是它的intellisense用的clang parser问题。
3、ctrl + F不能在当前cpp里搜到任何东西。不知是bug还是破解问题。
4、intellisense的符号跳转，和调试时的step info/step over，能否进入编译器、os自带的头文件的问题。这个不管vs还是visualgdb应该都需要做一些目录设置，我记得以前用visualgdb时设置了没搞定。
vs2022再搞稳定点，就更好了：
1、它的sftp很容易超时出错。不过可以不用sftp，这个不是问题。
2、有时整个vs会重启。
3、不能自动goto source code，而是在汇编代码里打转。要手动选择source code窗口切过去。
4、汇编代码里显示的符号没有经过c++filt之类的demangle。
vs2019也有对应的功能，也可以试试。
vs还有个好处，所有窗口都是可以拆出来的，这样有些窗口可以拖到副显示器上看。
【 在 speedboy2998 的大作中提到: 】
: 我们之前也用 VISUAL GDB，但是感觉还是没有在 WINDOWS 下直接调试那么丝滑。
: 因为我们的产品是跨平台的，同时支持 LINUX 和 WINDOWS, 所以我现在是 VS2022+VAX，在 WINDOWS 上调试。99.5% 的情况下不需要到 LINUX 下去调试，剩下的 0.5% 基本也可以用日志搞定。VISUAL GDB 已经彻底扔掉了。
:
--
修改:z16166 FROM 123.118.191.*
FROM 123.118.191.*
我vscode的啥插件也没装，除了c++的那些MS标准插件
【 在 nsyncxyz 的大作中提到: 】
: 一般是安装了其他软件导致的，安装opencv的debug插件OpenImageDebugger就导致我经常断不下来，以前一直好的。
--
FROM 61.48.130.*
这个应该和具体的C++代码没关系，可能和编译器什么的有关系，我用的musl的g++。
由于这个调试的烦人问题，我弃用vscode调试C++好久了。
vs2022远程调试linux c++也有bug，主要是
1、按F5开始调试时报gdb相关的错误(有两种类型的错误），debug菜单里选择terminate all，然后重来个一两次就能OK，所以能忍受。
2、程序运行起来后再设置源码断点时，有时很卡，要过一会儿才能设置上，或者卡住。不是很频繁出现，也能忍受。在程序运行之前设置好源码断点没问题。
【 在 OrderPhoenix 的大作中提到: 】
: 能给出个复现无视断点的例子么？
--
FROM 61.48.130.*