3 ms·
> I'm a game developer mainly writing/reading/debugging C++ on a codebase that's well over a million lines of code. As with most game-dev I'm developing almost
by dan00 8y ago
> I'm a game developer mainly writing/reading/debugging C++ on a codebase that's well over a million lines of code. As with most game-dev I'm developing almost entirely using Visual Studio, and I can't imagine trying to navigate code using a terminal based editor.
I'm working with vim on a ~5 million line C++ code base. Thanks to
rtags[1] I've all I need: auto completion, goto definition, even
semantically correct renaming or finding all locations in code calling
a certain function.
I'm certainly not saying that it's as polished as 'Visual Studio', but
it works pretty well.
If tooling isn't baked into an IDE - which unfortunately is often the case
- then pretty much every editor with some kind of extension
mechanism can take advantage of it.
> Maybe it's just because this is what I'm used to, however I just don't see how some of the tools would even be displayed in a terminal (parallel stacks window, for example) without some horrible ascii node graph.
Yes, most visualization are text based. E.g. for showing the references
for a function rtags uses the Quickfix-window of vim, which pretty much is
just a list with one entry for every reference. I can now jump to every
occurence in the list or even execute an operation on every reference,
like I've removed the last parameter of the function call, and now I'm
defining a vim substitution command for removing the last parameter
and execute it on very item of the Quickfix-window.
Sometimes visualizations are certainly helpful, but I never
found them particular useful for software, because the more complex an
application gets, the less useful the visualizations become. At some point
you're less interested on the class level and more on the system level,
but tools can't that easily detect what are the systems in an application.
[1] https://github.com/Andersbakken/rtags https://github.com/Andersbakken/rtags
- olig15 8y agoCode visualisations I agree aren’t that useful, and if I never have to look at UML style diagrams it’ll be too soon. The visualisations I’m talking about are mostly debugger tools. The parallel stacks view is life saving when you’re trying to figure out a deadlock. Having to scroll around this huge viewport with a cursor would just piss me off. I just can’t see how you could navigate a huge (10x screen width) node graph in a text terminal using vim style commands.
- dan00 8y agoYou certainly wouldn‘t have a node graph like this in vim, because like you are saying, it just doesn‘t work well with text. I had a look at parallel stacks and it looks nice and seems quite helpful. But I have to think, if you have that many threads that might deadlock and it happens often, if your architecture might be the issue. Most of our parallelism is job based. There is a job queue and worker threads are taking jobs from it. So deadlocks are pretty much a non issue for us. I‘m not trying to say that everything you‘re doing is obviously wrong, but the older I get the more suspicious I‘m getting if there‘s a need for „fancy“ debugging tools, because it might mask that there are some more serious issues in the application.
- Const-me 8y ago> Most of our parallelism is job based. There is a job queue and worker threads are taking jobs from it. For a game or similar code that's sometimes too much RAM, and usually too much latency.
- dan00 8y agoThere is a really nice talk of the game developer Naughty Dog about their job system: https://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine https://www.gdcvault.com/play/1022186/Parallelizing-the-Naug...
- jason_slack 8y agoCan you share your vim setup?
- dan00 8y agoRegarding rtags? I am just using the plugin: https://github.com/lyuts/vim-rtags https://github.com/lyuts/vim-rtags.