Advertisement

IDE Suggestions, ditching Code::Blocks

Started by May 26, 2017 03:27 AM
12 comments, last by SibylSystem 7 years, 3 months ago

My system experienced a fan lockup last night and shut down. I wasn't too concerned until I got to work on my game and oh look, apparently code::blocks doesn't back up files and also does not perform atomic saves. main.c is just blank Really glad I wasn't working on one of my commercial projects.

Anyhow, I need a new IDE. Any suggestions? Not really looking forward to downloading Visual Studio Express, and my newest commercial version is 6.0

main.c is just blank

Use Git?

Not really looking forward to downloading Visual Studio Express

It's a big download, but Visual studio community 2015 is really good.

Advertisement

Yeah I've used 4.0 6.0 2005 2008 Professional and 2012? and 2015 Express. I've also used Turbo C++ (circa 93( , LCC code::blocks, and a few others i forget , I just don't have the bandwidth to download VS on my new system or I would. It's metered internet, hoping that will change in the next few weeks. I actually figured out the problem, read only bit somehow got set on the folder, There are only 2 C::B git plugins, and neither one is written for windows or has a downloadable setup.

The nice thing about version control is that you don't need IDE integration for it to work ;-)

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

code::blocks doesn't back up files and also does not perform atomic saves.

While I can't tell what has been going on in your particular case on your dying machine, I can tell with high confidence that neither of these statements is true (I'm the person who wrote the code that does the saving to files somewhat over a decade ago).

Code::Blocks only ever directly "overwrites" a file if the file does not already exist, but that is a non-issue (the write can of course still fail if your CPU dies, but there's not really much you can do about that).

If the file already exists on-disk, Code::Blocks will write to a temporary file and then perform an atomic swap/move (using MoveFileEx under Windows, rename under POSIX).

For people with unreliable/failing systems or power supply, there used to be a save-every-soandsooften plugin as well, it would write the editor's contents to a backup file (not overwriting the original one!) every couple of minutes.

If you are unhappy with Code::Blocks, you may want to give CodeLite a try. It's way less heavyweight than any other alternative (like... 5% the overall size, and 15% the memory requirements of VisualStudio). From what I can tell, it works pretty well, too.

main.c is just blank

Use Git?

Not really looking forward to downloading Visual Studio Express

It's a big download, but Visual studio community 2015 is really good.

2017*

Advertisement

You don't need a new IDE for this, you need to use version control. GitHub provides free repositories for git, *if* they're public, BitBucket provides free private repositories, for git or mercurial, *if* you have a small team (or no team at all). That ought to be enough to get you started.

Not using VCS is irresponsible at this point. It's your development time on the line. One power surge and no IDE in the world will protect you against that.

Still, if you're just shopping around for multi platform IDEs, there is QtCreator (free, Qt-dev oriented but it's a general purpose IDE), KDevelop (free), Gnome Builder (free, in development) and CLion (non-free, but if mentioning "JetBrains" gives you a hard-on like for so many people I've seen, you might like it).

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

(several mentions of "need version control")

That's of course right, everybody needs version control, but version control is somewhat orthogonal to the stated problem. The complaint is that the source file was not saved properly, being truncated.

Version control would be able to restore an earlier version that had been committed, but it would obviously be unable to restore today's lost work (though there exists software which aims, and succeeds moderately well at providing just that, Seagate used to sell self-saving version-controlling USB-disks some years ago).

Depending on what commit "culture" you follow, version control may be very helpful or rather very disappointing in a "computer just died" case. For example, not few organizations have a "all commits must build without error" culture, and very few people or organizations have a "commit after every save" culture. Requiring commits that build is generally a good thing, but it also means you possibly lose not just the last 3 hours of work if your computer dies. Sure, that's still better than a 100% loss, but it's less helpful than one would wish in that situation.

have a "all commits must build without error" culture,

At my last job, the same people who instituted the "all commits must build" policy also commit a dozen times per day.
They commit to private branches and "git rebase --interactive" to clean up their many commits into one before pushing it to the main branch :p

Depending on what commit "culture" you follow
Yeah, after the first "oh I lost the work I haven't commited in the whole day!" event I think it becomes obvious what "culture" should be followed right? Also, as Hodg said, branches. As many as you need.

Also the "organization culture" thing isn't applicable here, guy seems to be working on his own. So it is irrelevant.

They commit to private branches and "git rebase --interactive" to clean up their many commits into one before pushing it to the main branch
Real men merge every single mistake they made, no regrets :D

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

This topic is closed to new replies.

Advertisement