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.
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.
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*
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).
(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.
At my last job, the same people who instituted the "all commits must build" policy also commit a dozen times per day.have a "all commits must build without error" culture,
Depending on what commit "culture" you followYeah, 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 branchReal men merge every single mistake they made, no regrets :D
