Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Frank O

macrumors newbie
Original poster
Apr 7, 2020
27
6
I'm interested in refreshing my C/C++ skills (amateur occasional coder), and would like to pick a simple, no-frills IDE to use on my Mac. Anything that anyone particularly likes?
 

Nermal

Moderator
Staff member
Dec 7, 2002
20,649
4,050
New Zealand
Does Xcode have too many frills?
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.
 

joevt

Contributor
Jun 21, 2012
6,665
4,078
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.
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 I edit text files outside of Xcode and save a change, then Xcode should see the change when I tab back to Xcode.
 

casperes1996

macrumors 604
Jan 26, 2014
7,434
5,578
Horsens, Denmark
If the bug doesn't affect your workflow then that's fine. I was just alerting Frank O to its existence.

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.

Xcode is a rather big tool though. Other good options are VSCode; The extension library is massive and the editor itself is fairly lightweight but very extensible as a result of all those extensions. Then there's CLion; A bit heavier than VSCode (sans extensions that you can fill it up with) but a good editor IMO. And for quick work/Terminal based editing there's the classics; nano, vim, emacs.
 

Nygaard

macrumors member
Dec 7, 2022
47
20
Houston
Your editor of choice + terminal + clang. It gives you everything you need to succeed: a way to write code and a way to compile code. Most decent editors support things like syntax highlighting, auto indentation, etc.

If you don't have a favorite text editor and are willing to invest some time learning the last text editor you'll ever use, go with vim.

For 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.
 

Nermal

Moderator
Staff member
Dec 7, 2002
20,649
4,050
New Zealand
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.
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?!".
 

Analog Kid

macrumors G3
Mar 4, 2003
8,915
11,477
I'll add Code Runner to this list. It's not what I'd consider an IDE, but if you just want to start playing toy code, it gets the job done without a lot of muss or fuss.
 

casperes1996

macrumors 604
Jan 26, 2014
7,434
5,578
Horsens, Denmark
For 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.
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 Xcode
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?!".
Hehe yeah it can definitely catch you off guard. But git reset --hard is your friend there
 

Nygaard

macrumors member
Dec 7, 2022
47
20
Houston
I mean you can always run lldb outside of Xcode.
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.

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?!".
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.
 

Nermal

Moderator
Staff member
Dec 7, 2002
20,649
4,050
New Zealand
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.
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.
 

casperes1996

macrumors 604
Jan 26, 2014
7,434
5,578
Horsens, Denmark
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.

All very fair. I will say that I personally find the TUI from GDB to be absolutely amazing. I used it *a lot* when I wrote my bachelor project (an operating system) and it is really really nice. The TUI from lldb is admittedly a lot less nice, and yes, navigation changes in lldb when you enter the TUI so you no longer have access to the same commands and need to learn a new way of interacting with it in TUI mode (unlike GDB where it is just a presentation mode).

Point was simply that options exist though. I think if you want to do something really quickly on a 20 line C file you just quickly wrote up in nano, just using lldb is preferable to starting up the heavy Xcode. But it is nicer to work with Xcode for anything more substantial. And yeah, it has things like the Metal View debugger which is super nice too (and tooling for SwiftUI and the like as well) so there's that.
 

Frank O

macrumors newbie
Original poster
Apr 7, 2020
27
6
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.

Thanks, good to know. I tried some of the suggested IDEs, as well as others. Almost settled on VSCodium, but had some problems getting the needed extensions set up. So in the end I went with Xcode. Once I got past its basic orientation assuming I'd be writing apps for the Mac or iOS app stores, it seems to be a decent IDE for noodling in C/C++. But I'll keep in mind the tip about how it autosaves changes.
 

CoreFoundation

macrumors newbie
Jan 16, 2023
2
0
It you need simple IDE for experimenting with C++ just to install XCode which is free and well integrated with macOS infrastructure.
All other scenarios requires more work from you actually
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.