If you do end up using Xcode, be aware that if you open plain .c files outside of an Xcode project then it'll autosave any changes you make, so make a backup of any files if you're just playing around. When you close an "unsaved" file it'll ask whether you want to save it, but no matter whether you say yes or no it'll save it anyway.Does Xcode have too many frills?
I don't understand. If you make changes in Xcode then don't you want Xcode to save the changes? And why would you edit files that you don't want to save?If you do end up using Xcode, be aware that if you open plain .c files outside of an Xcode project then it'll autosave any changes you make, so make a backup of any files if you're just playing around. When you close an "unsaved" file it'll ask whether you want to save it, but no matter whether you say yes or no it'll save it anyway.
If the bug doesn't affect your workflow then that's fine. I was just alerting Frank O to its existence.
Yeah, for me it was something like "I'll just refactor this function... save... edit... edit... oh wait, that's not going to work... close... don't save... reopen... hey where did my original version go?!".It's a good thing to be aware of. But anything that would require meaningful effort to redo really should be under git version control anyway so I don't think it's that big a deal. But good to be pointed out; It can still definitely throw you off.
I mean you can always run lldb outside of Xcode. Its TUI is even rather nice. You can also get GDB to work nicely but it is not as straightforward as it used to be. But if it's a simple situation where I don't want to whip out a big tool like Xcode I'll definitely just run lldb from the Terminal. You can also configure the VSCode debugging suite to use lldb as its backend and use that. Or CLion - Lots of Debugger options that don't involve XcodeFor debugging, Xcode is your only realistic option. You'll likely need to install it anyway for the compilers and headers, but you can just use it as a debugger.
Hehe yeah it can definitely catch you off guard. But git reset --hard is your friend thereYeah, for me it was something like "I'll just refactor this function... save... edit... edit... oh wait, that's not going to work... close... don't save... reopen... hey where did my original version go?!".
I've never had any luck getting lldb/gdb to be as intuitively usable as a graphical debugger. You can use them in a pinch, but the CLI's are like looking through a tunnel. The TUIs are a step in the right direction, but the last time I tried them, they were half-baked and almost useful, but not quite there. I think the clang TUI took away the command line or something like that, forcing you to constantly flip in and out of TUI mode.I mean you can always run lldb outside of Xcode.
This "feature" also exists in Preview, which has bitten me a few times. All I wanted was to temporarily markup an image, but Preview helpfully saved my changes without asking me after I quit the program. And when you reopen the file to fix the mess, the application claims complete innocence by presenting an empty undo stack.Yeah, for me it was something like "I'll just refactor this function... save... edit... edit... oh wait, that's not going to work... close... don't save... reopen... hey where did my original version go?!".
That's an annoying "feature", as opposed to Xcode's behaviour which is a bug: It does ask whether you want to save, but saves anyway regardless of which option you pick.This "feature" also exists in Preview, which has bitten me a few times. All I wanted was to temporarily markup an image, but Preview helpfully saved my changes without asking me after I quit the program.
I've never had any luck getting lldb/gdb to be as intuitively usable as a graphical debugger. You can use them in a pinch, but the CLI's are like looking through a tunnel. The TUIs are a step in the right direction, but the last time I tried them, they were half-baked and almost useful, but not quite there. I think the clang TUI took away the command line or something like that, forcing you to constantly flip in and out of TUI mode.
Not to say Xcode's frontend to lldb is spectacular - it suffers from slow single steps and watch window updates sometimes - but I haven't found anything better. Also, I don't know if Xcode's problems stem from lldb or Xcode itself; probably a bit of both.
I've had bad experiences with Eclipse in the past, and I haven't used CLion or VSCode to comment, though I suspect they are Xcode-like, except non-native. I don't know of any product that is just a fast and clean debugger.
Not exactly necessary for OP, but Xcode surprisingly has special view and Metal debugging capabilities, and they tend to work. These can be quite useful in the right situations, and I'd be surprised if the 3rd-party debuggers had these features.
If you do end up using Xcode, be aware that if you open plain .c files outside of an Xcode project then it'll autosave any changes you make, so make a backup of any files if you're just playing around. When you close an "unsaved" file it'll ask whether you want to save it, but no matter whether you say yes or no it'll save it anyway.