by Josh Klint
I forgot, in case you are dual-booting the 2 OS's on a single drive and you want to remove the Linux partition and regain the empty space for Windows there's an application called EasyBCD that helps you doing the task and rebuilds your Windows MBR nice and easy, there's a videotut here:
Interesting progress Josh. The approach of using separate drives for different OS's seems like a life-saver (at first) but once you get Kernel updates on your Linux distro it will re-write your Grub and generate a dual-boot screen (happened to me). However, this new grub will be written on the Linux drive and the windows boot info (and its MBR) will remain intact, so given the case you can still use the bios to boot straight from the Windows drive, or if you need to reinstall linux you can unplug your windows drive and format/install Linux without any worries of "contaminating" your windows drive with harmful boot info.
The only time I've had any issues was with when I did manual partitioning and decided to try GPT in place of MBR - this caused windows to not recognize the disc halfway through the boot.
ymmv ofc, but if all else fails maybe your local LUG is still throwing install fests?
I actually had to write makefiles for Android, and I auto-generated my own with the little language/compiler I made myself.
Thanks for the input guys, I will definitely check out Valgrind.
It's true that if your programming experience has always been done in an IDE, the idea of having a separate program for text editing and debugging is hard to comprehend.
It may even shock you that the opposite is also true. I'm not alone in saying that I'd rather not work in an IDE, if given the choice. I don't want to depend on IDE project management; they're usually platform-dependent and always inferior to stand-alone build systems.
But then, I'm one of those persons who actually care about how (and why) things work. That being said, I also realize that there are other types of programmer who have very successful careers without ever knowing that there is a compiler and a linker that do the work behind the scenes.
It's very hard to find a middle ground for those two types of people. For none of them will want to compromise, and for good reasons. Why should one or the other be less productive?
In the case of GDB, somebody coming from an IDE background cannot realize how powerful it is, because the learning curve is so steep, and that's a shame. But for those who've been using it for years, they cannot work without it. For them, an IDE feels like a toy, not a tool.
If you're willing to spend some time, I'd say that putting some effort in using GDB will be very rewarding. But if all you want is a Microsoft Visual Studio or Eclipse replacement, then you'd better abandon right now. Some will get close, but you'll never be satisfied.
Sure, you can pin your hopes that one project or the other will get there eventually. But why not try the other workflow? It's certainly better than constantly being dissatisfied with inferior copies of your preferred IDE.
Josh, I also was Code::Blocks user, but I found QtCreator much better for my current C++ usage. it also integrates with valgrind, that analysis tool mentioned by Anton. about GDB, I think it might be more of an issue of how Code::Blocks integrates with it.
There's also this tool: http://codef00.com/projects#debugger
GDB is not associated with Code::Blocks. Code::Blocks has added support for GDB; extent of that support relies fully upon them.
Nemiver is a pretty good GDB stand-alone UI. GDB people themselves don't concern with a UI, that is true - they concern with making their debugger work well and be integratable into other software. Qt Creator, Nemiver and even Visual Studio (http://visualgdb.com) integrate GDB into themselves.
ohh i made it into your post.
@ Herik Danielsson. Yes i solved it but not like i expected it.
I really think the main problem was because the installation of Linux saved the bootloader on all installed harddrives. And for some reason windows didn't even wanted to save its own bootloader again on one drive. No repair, no reinstall nothing worked. I could finaly reinstall when i removed all harddrives except the main drive with windows 8 on it.
I wouldn't call me a pc noob i even used linux a long time ago already and i had dualboot back then which worked flawless. However i think that was windows xp and i probably had only one harddrive.
Now i can dual boot with choosing the default boot-drive on boot (can do it quickly with a F-Key while booting which is probably a feature of my BIOS). either one which has GRUB on it or one with the windows bootloader.
The right-click trick in Code::Blocks certainly helps. Thank for the tip.
Just go to google.com and type in "grub messes up" and you can see there is a systemic problem. If a user's first experience with Linux is having it make their Windows installation unusable, that person will never come back.
The Wubi installer for Ubuntu is a wonderful trouble-free experience, but unfortunately the Ubuntu installation it creates doesn't work well with the Windows file system, which is probably why Canonical no longer recommends it.
Until this is improved, my advice for new users will continue to be to make a completely separate installation with the Windows drive removed, and select a boot drive with BIOS.
As far as the black screen goes, that sounds a lot like the nouveau issues I had with Mint. Did you try the proprietary NVidia drivers?
Also, dual-booting _is_ a solved problem. Two weeks later, that user hasn't even responded with how his Windows installation was messed up, or which install options he used. You can't expect them to have researched the subject at all based on that post.
@Josh Klint. Please don't blame GDB for Code::Blocks' shortcomings.
Did you read this?
Good thread about C++ gdb GUI http://stackoverflow.com/questions/79023/c-gdb-gui
What editor or IDE do code in? Most of the Linux editors and IDEs has GDB integration.
I just use the Code::Blocks interface. I will not use a command-line interface for a debugger.
Listing Python as an added benefit does not impress me; that just tells me the developer's focus is split between two different things, and C++ will not get 100% of their effort and attention.
Linux has some compelling advantages, but we should be realistic about its shortcomings so that they can be identified and fixed. Linux developers told Valve the lack of a good debugger was their number one problem, and now Valve is working to solve the issue.
"When we talk to developers and say, 'if you can pick one thing for Valve to work on the tools side to make Linux a better development target,' they always say we should build a debugger," he said."
gdb definitely allows you to see variables further up the stack, you just need to navigate to those frames with 'up', 'down' or 'frame X' commands. Although I much prefer to use a GUI wrapped around it as found in Qt Creator for example.
Forgot to mention gdb -tui interface, which is allow you to see both assembly and C/C++ code at the same time.
>GDB itself is not a complete debugger;
Thats not true. I'vent heard more powerfull debugger at all. But it is like one of this type of software - which is needed to be configured to show its power. Remember, that gdb also have support for python scripting. See https://github.com/gdbinit/Gdbinit as example of such configuration power. Also, there is another powerful tool - valgrind, which is awesome for finding memory leaks and much more. Moreover, it have embedded gdbserver inside, so on each memory leak/error it can break to give you ability to do research of the stack, memory, etc from your gdb session (see valgrind vgdb and remote gdb debugging).
> GDB itself is not a complete debugger; it shows variables only in the top-most function in the call stack, and does not allow you to examine other functions without manually adding "watches" for specific variables.
Does the "backtrace full" command help at all? You can also limit it to a specific number of frames. Ie, "backtrace full 3"