JetBrains seem to have the best IDE for every language I've tried: Rider / IntelliJ / Android Studio / PyCharm / PhpStorm / RubyMine. Never tried CLion though, but given they all share the same base I'd thought it would be of a equally high standard?
Such a naive assumption
Parsing cpp fast and reliably may be significant differentiator between languages
My bad. I naively assumed the successful developer-focued tools company with 25 years experience in parsing programming languages and building IDEs with advanced AST/refactoring tooling, that I've been happily using for 8 years had a great C/C++ story based on my experience of having used 7 of their other IDEs (built from the same platform base), were all best-in-class.
Maybe that's why I ended my thought with a question mark? i.e. So C/C++ developers with experience in both can clarify what makes VS so much better than CLion. Or if they haven't tried CLion that it would be a good alternative on Linux to try given all JetBrains other IDEs are of high quality.
Anyway, Windows has become a pain for normal user but remains fine if you are a company user. The management tools will strip away most if not all the annoyance people are complaining about here. I think Microsoft knows where the money comes from.
Some colleges have switched from years VS to Emacs and after a week won’t look back.
Guys, please. I am all for FOSS, but such delusions can only be harmful, for they prevent from actually improving stuff.
Did you sir ever use debugger in your life?
Emacs has a front end for gdb. Some colleges use other front ends.
What I’m preventing to improve, in your opinion?
I'm new enough that my first debugger experience was Visual Studio, and I currently use IntelliJ IDEs which provide a similar experience. That experience consisting of: setting breakpoints in the gutter of the text editor, visually stepping through my source files line by line when a breakpoint is hit, with a special-purpose pane in the IDE visible, showing the call stack and the state of all local variables (and able to poke at that state any point higher up in the stack by clicking around the debug pane), able to execute small snippets of code manually to make evaluations/calculations based on the current program state.
I'm not so naive to believe that effective debugging tools didn't exist before GUIs became commonplace, but I have a hard time seeing how anything TUI-based can be anywhere near as information-dense and let you poke around at the running program like I do with my GUI-based IDEs.
(Pasting this comment under a few others because I genuinely want to hear how this works in the real world!)
Then „n“ for next line, „s“ for step-in, „fin“ to go to the end of the function
Dprintf for adding dynamically printfs for watching variables
List will show you 10 (default) lines of code around the cursor, bt will show you a backtrace…
I think that covers the basics. As you can see, ist just a keypress mostly for doing anything.
With Emacs you can click on the fringe for setting/deleting breakpoinst.
The bread and butter is really easy, and other than seeing the cursor in the code, there is no advantage. In Emacs you DO see the cursor moving…
Stallman himself wrote it so it lies at the intersection of that camp and the lisp cultists (though Ig they are mostly extinct post-LLM), but they used to have a really strong belief that lisp was the path to AI because of it's homoiconicity.
What should be said in it's favor is that due to its architecture it is crazy extensible and hackable. And the fact that the line between configuration and code is very blurry really encourages you to dive into that.
The choice of lisp also helps ensure user freedom as it's a quite simple language - ensuring that compilers and interpreters are a commodity. You don't like one, pick another. Contrast that with say Rust where if you don't like the official Rust you are shit out of luck. It's also a rolling release deal so you can't even easily stay on an old version.
They go all the time adding hundreds of print(f) of log_* function calls. Often they don’t care to remove them after the fact, as I ask them to, often comes “can/will be useful to detect future bugs”
I’m in the automotive industry, where is known to be a disaster in topic SW. but I think it is also common in other industries. I have seen it in telco already.
While I agree that knowing a debugger is important, and as a leader won’t hire somebody who do not use it, is a fact that many people don’t use it, and are doing ok.
Last but not least, it must be said sometimes you have to go to prints: in fact yesterday I had to, as I was debugging a library with sockets, which would timeout pretty quickly. I used dprintf in gdb, but the advantage to simple prints was not huge.
Well yes, obviously - it's an indespensible tool in any arsenal, I just cannot fathom(as a C++ low level engineer) how someone can be a professional programmer where they are paid for their job and they don't know to use a debugger even to just do a basic pause and step through flow. But then again I don't work with any python programmers, so maybe that's why.
In C etc. printf calls also make all intermediate variables observable in the debugger. You can debug programs where you can't pause it. Etc.
Side note: I have been using msvc in wine for almost 5 years now, so if that works I don't know why the Sony/Nintendo/Xbox toolchain wouldn't.
Have you tried the intellij IDEs? I thought that they were pretty similar in terms of experience, although I have used them for java/dotnet primarily.
I generally use Sublime Text (+ various plugins) for code editing and leave Visual Studio for dwbugging the code or editing GUIs.
Visual Studio is ridiculously overrated, and this is coming from someone that works at Microsoft and forced to use it every day. What really kills me are the insanely complicated and unmodifiable shortcut keys for common tasks. Killing the process is like some finger breaking ctrl+alt+function key nonsense? Seriously wtf? Oh to debug multiple binaries simultaneously in the same solution requires launching multiple instances of the entire IDE? Why??
I'm new enough that my first debugger experience was Visual Studio, and I currently use IntelliJ IDEs which provide a similar experience. That experience consisting of: setting breakpoints in the gutter of the text editor, visually stepping through my source files line by line when a breakpoint is hit, with a special-purpose pane in the IDE visible, showing the call stack and the state of all local variables (and able to poke at that state any point higher up in the stack by clicking around the debug pane), able to execute small snippets of code manually to make evaluations/calculations based on the current program state.
I'm not so naive to believe that effective debugging tools didn't exist before GUIs became commonplace, but I have a hard time seeing how anything TUI-based can be anywhere near as information-dense and let you poke around at the running program like I do with my GUI-based IDEs.
(Pasting this comment under a few others because I genuinely want to hear how this works in the real world!)
Of course setting a gutter breakpoint is easier in an IDE, and that’s irrelevant to my point. OP made this aabout vim/emacs versus VisualStudio as if the former doesn’t have gutter-clicking capabilities. Which is ridiculous
Eh? https://learn.microsoft.com/en-us/visualstudio/debugger/debu...
> complicated and unmodifiable shortcut keys for common tasks. Killing the proces
https://learn.microsoft.com/en-us/visualstudio/ide/identifyi...
Debug.TerminateAll is right there in the list
> No you’re just completely ignorant
Forgive my skepticism
And cmon modify the registry to debug multiple processes? People work together in teams and share a common tooling that ideally tries to minimize the friction required to get work done. Think about that while contrasting the steps required in that article with the alternative of“launch the app a couple more times, then…”
You just set the startup properties on the solution to start the multiple projects. On that page, look for "To set the startup project or multiple projects from solution Properties" (https://learn.microsoft.com/en-us/visualstudio/debugger/debu...)
* "Sometimes, you might need to debug the startup code for an app that is launched by another process. Examples include services and custom setup actions"
Starting multiple copies of the IDE wouldn't handle these scenarios either